similar to: [PATCH RESEND] Revert "vhost: fix release path lockdep checks"

This reverts commit ea5d404655ba3b356d0c06d6a3c4f24112124522. In commit 47283bef7ed356629467d1fac61687756e48f254(vhost: move memory pointer to VQs), rcu_ operation has been replaced by mutex, and original issue fixed in sea5d404655 has gone as well, we need to remove the no-longer-used `locked' var by reverting the orignal patch. Signed-off-by: Caspar Zhang <jinli.zjl at

This reverts commit ea5d404655ba3b356d0c06d6a3c4f24112124522. In commit 47283bef7ed356629467d1fac61687756e48f254(vhost: move memory pointer to VQs), rcu_ operation has been replaced by mutex, and original issue fixed in sea5d404655 has gone as well, we need to remove the no-longer-used `locked' var by reverting the orignal patch. Signed-off-by: Caspar Zhang <jinli.zjl at

In commit ea5d404655ba ("vhost: fix release path lockdep checks"), Michael added a flag to check whether we should hold a lock in vhost_dev_cleanup(), however, in commit 47283bef7ed3 ("vhost: move memory pointer to VQs"), RCU operations have been replaced by mutex, we can remove the no-longer-used `locked' parameter now. Signed-off-by: Caspar Zhang <jinli.zjl at

Current pre-sorted memory region array has some limitations for future device IOTLB conversion: 1) need extra work for adding and removing a single region, and it's expected to be slow because of sorting or memory re-allocation. 2) need extra work of removing a large range which may intersect several regions with different size. 3) need trick for a replacement policy like LRU To

On Mon, 18 Jan 2016 10:42:29 +0800 Jason Wang <jasowang at redhat.com> wrote: > Current pre-sorted memory region array has some limitations for future > device IOTLB conversion: > > 1) need extra work for adding and removing a single region, and it's > expected to be slow because of sorting or memory re-allocation. > 2) need extra work of removing a large range

On Fri, Mar 25, 2016 at 10:34:33AM +0800, Jason Wang wrote: > Current pre-sorted memory region array has some limitations for future > device IOTLB conversion: > > 1) need extra work for adding and removing a single region, and it's > expected to be slow because of sorting or memory re-allocation. > 2) need extra work of removing a large range which may intersect >

On Fri, Mar 25, 2016 at 10:34:33AM +0800, Jason Wang wrote: > Current pre-sorted memory region array has some limitations for future > device IOTLB conversion: > > 1) need extra work for adding and removing a single region, and it's > expected to be slow because of sorting or memory re-allocation. > 2) need extra work of removing a large range which may intersect >

On top of 'vhost: Allow device specific fields per vq', we can move device specific fields to device virt queue from vhost virt queue. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/net.c | 164 +++++++++++++++++++++++++++++++++++++++++++------- drivers/vhost/vhost.c | 57 +----------------- drivers/vhost/vhost.h | 22 ------- 3 files changed, 142

On top of 'vhost: Allow device specific fields per vq', we can move device specific fields to device virt queue from vhost virt queue. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/net.c | 164 +++++++++++++++++++++++++++++++++++++++++++------- drivers/vhost/vhost.c | 57 +----------------- drivers/vhost/vhost.h | 22 ------- 3 files changed, 142

Current pre-sorted memory region array has some limitations for future device IOTLB conversion: 1) need extra work for adding and removing a single region, and it's expected to be slow because of sorting or memory re-allocation. 2) need extra work of removing a large range which may intersect several regions with different size. 3) need trick for a replacement policy like LRU To

Current pre-sorted memory region array has some limitations for future device IOTLB conversion: 1) need extra work for adding and removing a single region, and it's expected to be slow because of sorting or memory re-allocation. 2) need extra work of removing a large range which may intersect several regions with different size. 3) need trick for a replacement policy like LRU To

Device lock should be held when releasing a device, and specifically when calling vhost_dev_cleanup(). Otherwise, RCU complains about it: [ 2025.642835] =============================== [ 2025.643838] [ INFO: suspicious RCU usage. ] [ 2025.645182] ------------------------------- [ 2025.645927] drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage! [ 2025.647329] [ 2025.647330]

Device lock should be held when releasing a device, and specifically when calling vhost_dev_cleanup(). Otherwise, RCU complains about it: [ 2025.642835] =============================== [ 2025.643838] [ INFO: suspicious RCU usage. ] [ 2025.645182] ------------------------------- [ 2025.645927] drivers/vhost/vhost.c:475 suspicious rcu_dereference_protected() usage! [ 2025.647329] [ 2025.647330]

What it is: vhost net is a character device that can be used to reduce the number of system calls involved in virtio networking. Existing virtio net code is used in the guest without modification. There's similarity with vringfd, with some differences and reduced scope - uses eventfd for signalling - structures can be moved around in memory at any time (good for migration, bug work-arounds

What it is: vhost net is a character device that can be used to reduce the number of system calls involved in virtio networking. Existing virtio net code is used in the guest without modification. There's similarity with vringfd, with some differences and reduced scope - uses eventfd for signalling - structures can be moved around in memory at any time (good for migration, bug work-arounds

P_STREAM can get more than 4GMb/s for the receive side, and more than 5GMb/= s for the send side. Is it the result from the raw socket or through tap? I want to duplicate such performance with vhost on my side. I can only get = more than 1GMb/s with following conditions: 1) disabled the GRO feature in the host 10G NIC driver 2) vi->big_packet in guest is false 3) MTU is 1500. 4) raw socket, not

P_STREAM can get more than 4GMb/s for the receive side, and more than 5GMb/= s for the send side. Is it the result from the raw socket or through tap? I want to duplicate such performance with vhost on my side. I can only get = more than 1GMb/s with following conditions: 1) disabled the GRO feature in the host 10G NIC driver 2) vi->big_packet in guest is false 3) MTU is 1500. 4) raw socket, not

We don't stop device before reset owner, this means we could try to serve any virtqueue kick before reset dev->worker. This will result a warn since the work was pending at llist during owner resetting. Fix this by stopping device during owner reset. Reported-by: syzbot+eb17c6162478cc50632c at syzkaller.appspotmail.com Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio

What it is: vhost net is a character device that can be used to reduce the number of system calls involved in virtio networking. Existing virtio net code is used in the guest without modification. There's similarity with vringfd, with some differences and reduced scope - uses eventfd for signalling - structures can be moved around in memory at any time (good for migration, bug work-arounds

What it is: vhost net is a character device that can be used to reduce the number of system calls involved in virtio networking. Existing virtio net code is used in the guest without modification. There's similarity with vringfd, with some differences and reduced scope - uses eventfd for signalling - structures can be moved around in memory at any time (good for migration, bug work-arounds