Displaying 20 results from an estimated 129 matches for "virtqueue_notifi".
Did you mean:
virtqueue_notify
2019 Jul 11
2
[PATCH] drm/virtio: kick vq outside of the vq lock
Replace virtqueue_kick by virtqueue_kick_prepare, which requires
serialization, and virtqueue_notify, which does not. Repurpose the
return values to indicate whether the vq should be notified.
This fixes a lock contention with qemu host. When the guest calls
vibad rtqueue_notify, the qemu vcpu thread exits the guest and waits
for the qemu iothread to perform the MMIO. If the qemu iothread is
2019 Jul 11
2
[PATCH] drm/virtio: kick vq outside of the vq lock
Replace virtqueue_kick by virtqueue_kick_prepare, which requires
serialization, and virtqueue_notify, which does not. Repurpose the
return values to indicate whether the vq should be notified.
This fixes a lock contention with qemu host. When the guest calls
vibad rtqueue_notify, the qemu vcpu thread exits the guest and waits
for the qemu iothread to perform the MMIO. If the qemu iothread is
2013 Oct 22
0
[PATCH RFC 4/7] virtio_blk: use dummy virtqueue_notify() to detect host kick error
Deleting the disk and partitions in virtblk_remove() via del_gendisk() causes
never ending waits when trying to synch dirty inode pages.
A dummy virtqueue_notify() in virtblk_remove() is used to detect a host
notification error, latter occurs when block device was hot-unplugged.
When the dummy host kick failed blk_cleanup_queue() should be invoked
prior to del_gendisk().
Signed-off-by: Heinz
2011 Nov 03
2
[PATCH 3 of 5] virtio: support unlocked queue kick
Based on patch by Christoph for virtio_blk speedup:
Split virtqueue_kick to be able to do the actual notification
outside the lock protecting the virtqueue. This patch was
originally done by Stefan Hajnoczi, but I can't find the
original one anymore and had to recreated it from memory.
Pointers to the original or corrections for the commit message
are welcome.
Signed-off-by: Rusty
2011 Nov 03
2
[PATCH 3 of 5] virtio: support unlocked queue kick
Based on patch by Christoph for virtio_blk speedup:
Split virtqueue_kick to be able to do the actual notification
outside the lock protecting the virtqueue. This patch was
originally done by Stefan Hajnoczi, but I can't find the
original one anymore and had to recreated it from memory.
Pointers to the original or corrections for the commit message
are welcome.
Signed-off-by: Rusty
2019 Jul 11
0
[PATCH] drm/virtio: kick vq outside of the vq lock
Replace virtqueue_kick by virtqueue_kick_prepare, which requires
serialization, and virtqueue_notify, which does not. Repurpose the
return values to indicate whether the vq should be notified.
This fixes a bad spinlock contention when the host is qemu. When
the guest calls virtqueue_notify, the qemu vcpu thread exits the
guest and waits for the qemu iothread to perform the MMIO. If the
qemu
2019 Aug 13
0
[PATCH 2/2] drm/virtio: notify virtqueues without holding spinlock
Split virtqueue_kick() call into virtqueue_kick_prepare(), which
requires serialization, and virtqueue_notify(), which does not. Move
the virtqueue_notify() call out of the critical section protected by the
queue lock. This avoids triggering a vmexit while holding the lock and
thereby fixes a rather bad spinlock contention.
Suggested-by: Chia-I Wu <olvaffe at gmail.com>
Signed-off-by:
2014 May 30
4
[PATCH] block: virtio_blk: don't hold spin lock during world switch
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.
On arm64 quad core VM(qemu-kvm), the patch can increase I/O
performance a lot with VIRTIO_RING_F_EVENT_IDX
2014 May 30
4
[PATCH] block: virtio_blk: don't hold spin lock during world switch
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.
On arm64 quad core VM(qemu-kvm), the patch can increase I/O
performance a lot with VIRTIO_RING_F_EVENT_IDX
2013 Oct 22
9
[PATCH RFC 0/7] virtio: avoid various hang situations during hot-unplug
Hi,
this patch-set tries to solve various hang situations when virtio devices
(network or block) are hot-unplugged from a KVM guest.
On System z there exists no handshake mechanism between host and guest
when a device is hot-unplugged. The device is removed and no further I/O
is possible.
The guest is notified about the hard removal with a CRW machine check.
As per architecture, the host must
2013 Oct 22
9
[PATCH RFC 0/7] virtio: avoid various hang situations during hot-unplug
Hi,
this patch-set tries to solve various hang situations when virtio devices
(network or block) are hot-unplugged from a KVM guest.
On System z there exists no handshake mechanism between host and guest
when a device is hot-unplugged. The device is removed and no further I/O
is possible.
The guest is notified about the hard removal with a CRW machine check.
As per architecture, the host must
2019 Dec 11
0
[PATCH 2/3] virtio-gpu: batch display update commands.
When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.
Add functions to enable/disable notifications to allow that. Use the
new functions for primary plane updates.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h
2019 Dec 12
0
[PATCH v2 2/3] virtio-gpu: batch display update commands.
When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.
Add functions to enable/disable notifications to allow that. Use the
new functions for primary plane updates.
Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h
2013 Oct 24
12
[PATCH V2 RFC 0/9] virtio: fix hang(loop) after hot-unplug vlan
Hi,
this patch-set solves a hang situation when a vlan network device is
hot-unplugged from a KVM guest.
On System z there exists no handshake mechanism between host and guest
when a device is hot-unplugged. The device is removed and no further I/O
is possible.
The guest is notified about the hard removal with a CRW machine check.
As per architecture, the host must repond to any I/O operation
2013 Oct 24
12
[PATCH V2 RFC 0/9] virtio: fix hang(loop) after hot-unplug vlan
Hi,
this patch-set solves a hang situation when a vlan network device is
hot-unplugged from a KVM guest.
On System z there exists no handshake mechanism between host and guest
when a device is hot-unplugged. The device is removed and no further I/O
is possible.
The guest is notified about the hard removal with a CRW machine check.
As per architecture, the host must repond to any I/O operation
2020 Feb 11
1
[PATCH] drm/virtio: rework batching
Drop the virtio_gpu_{disable,enable}_notify(). Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.
Drop notification from command submission. Add virtio_gpu_notify()
calls everywhere instead. This results in more batching because we now
notify only once for a series of commands. We already had that for page
flips,
2020 Feb 12
1
[PATCH v2] drm/virtio: rework batching
Drop the virtio_gpu_{disable,enable}_notify(). Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.
Drop notification from command submission. Add virtio_gpu_notify()
calls everywhere instead. This results in more batching because we now
notify only once for a series of commands. We already had that for page
flips,
2019 Oct 30
0
[PATCH 1/3] virtiofs: Use a common function to send forget
Currently we are duplicating logic to send forgets at two places. Consolidate
the code by calling one helper function.
This also uses virtqueue_add_outbuf() instead of virtqueue_add_sgs(). Former
is simpler to call.
Signed-off-by: Vivek Goyal <vgoyal at redhat.com>
---
fs/fuse/virtio_fs.c | 150 +++++++++++++++++++-------------------------
1 file changed, 63 insertions(+), 87 deletions(-)
2015 Mar 07
4
[PATCH] virtio_rpmsg: set DRIVER_OK before using device
virtio spec requires that all drivers set DRIVER_OK
before using devices. While rpmsg isn't yet
included in the virtio 1 spec, previous spec versions
also required this.
virtio rpmsg violates this rule: is calls kick
before setting DRIVER_OK.
The fix isn't trivial since simply calling virtio_device_ready earlier
would mean we might get an interrupt in parallel with adding buffers.
2015 Mar 07
4
[PATCH] virtio_rpmsg: set DRIVER_OK before using device
virtio spec requires that all drivers set DRIVER_OK
before using devices. While rpmsg isn't yet
included in the virtio 1 spec, previous spec versions
also required this.
virtio rpmsg violates this rule: is calls kick
before setting DRIVER_OK.
The fix isn't trivial since simply calling virtio_device_ready earlier
would mean we might get an interrupt in parallel with adding buffers.