search for: virtqueue_kick

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent servicing the virtqueue notify in the host. The virtqueue_kick() function is modified to know about locking because it change...

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent servicing the virtqueue notify in the host. The virtqueue_kick() function is modified to know about locking because it change...

Current error handling of virtqueue_kick() was wrong in two places: - The skb were freed immediately when virtqueue_kick() fail during xmit. This may lead double free since the skb was not detached from the virtqueue. - try_fill_recv() returns false when virtqueue_kick() fail. This will lead unnecessary rescheduling of refill work....

Current error handling of virtqueue_kick() was wrong in two places: - The skb were freed immediately when virtqueue_kick() fail during xmit. This may lead double free since the skb was not detached from the virtqueue. - try_fill_recv() returns false when virtqueue_kick() fail. This will lead unnecessary rescheduling of refill work....

This patch allows virtio-blk to release its block queue lock while kicking the host. This improves scalability on SMP guests who would otherwise spin on the lock while another vCPU is kicking the host. This approach can be used for other virtio devices too. It simply splits the virtqueue_kick() operation into a prepare step which requires that the lock be held and the actual notify step which may be performed without the lock. Existing virtio drivers may continue to use the virtqueue_kick() interface which now does the prepare and notify steps internally. I am sending this out as RFC b...

This patch allows virtio-blk to release its block queue lock while kicking the host. This improves scalability on SMP guests who would otherwise spin on the lock while another vCPU is kicking the host. This approach can be used for other virtio devices too. It simply splits the virtqueue_kick() operation into a prepare step which requires that the lock be held and the actual notify step which may be performed without the lock. Existing virtio drivers may continue to use the virtqueue_kick() interface which now does the prepare and notify steps internally. I am sending this out as RFC b...

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....

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....

...om 11fd997d724f520ca628615e7ffbfd7901c40b62 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> Date: Fri, 6 Feb 2015 13:28:38 +0900 Subject: [PATCH] virtio: Avoid possible kernel panic if DEBUG is enabled. The virtqueue_add() calls START_USE() upon entry. The virtqueue_kick() is called if vq->num_added == (1 << 16) - 1 before calling END_USE(). The virtqueue_kick_prepare() called via virtqueue_kick() calls START_USE() upon entry, and will call panic() if DEBUG is enabled. Move this virtqueue_kick() call to after END_USE() call. Signed-off-by: Tetsuo Handa &l...

...om 11fd997d724f520ca628615e7ffbfd7901c40b62 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> Date: Fri, 6 Feb 2015 13:28:38 +0900 Subject: [PATCH] virtio: Avoid possible kernel panic if DEBUG is enabled. The virtqueue_add() calls START_USE() upon entry. The virtqueue_kick() is called if vq->num_added == (1 << 16) - 1 before calling END_USE(). The virtqueue_kick_prepare() called via virtqueue_kick() calls START_USE() upon entry, and will call panic() if DEBUG is enabled. Move this virtqueue_kick() call to after END_USE() call. Signed-off-by: Tetsuo Handa &l...

.../virtio-rng.c @@ -46,7 +46,7 @@ static void register_buffer(u8 *buf, siz sg_init_one(&sg, buf, size); /* There should always be room for one buffer. */ - if (virtqueue_add_buf(vq, &sg, 0, 1, buf) < 0) + if (virtqueue_add_buf(vq, &sg, 0, 1, buf, GFP_KERNEL) < 0) BUG(); virtqueue_kick(vq); diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -391,7 +391,7 @@ static int add_inbuf(struct virtqueue *v sg_init_one(sg, buf->buf, buf->size); - ret = virtqueue_add_buf(vq, sg, 0,...

.../virtio-rng.c @@ -46,7 +46,7 @@ static void register_buffer(u8 *buf, siz sg_init_one(&sg, buf, size); /* There should always be room for one buffer. */ - if (virtqueue_add_buf(vq, &sg, 0, 1, buf) < 0) + if (virtqueue_add_buf(vq, &sg, 0, 1, buf, GFP_KERNEL) < 0) BUG(); virtqueue_kick(vq); diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -391,7 +391,7 @@ static int add_inbuf(struct virtqueue *v sg_init_one(sg, buf->buf, buf->size); - ret = virtqueue_add_buf(vq, sg, 0,...

...queues. Here are the details of the error. A hang (loop) occurs when a machine check is handled on System z due to a vlan device removal. A loop spinning for a response for final IO in virtnet_send_command() will never complete successfully because of a previous unsuccessfull host kick operation (virtqueue_kick()). Patch [1] changes the guest->host notification API. A potential error returned by the host during notify() should not be ignored, but used in order to reflect the error back to the affected virtqueue. Patch [2] changes virtqueue_kick() and virtqueue_notify() to return a bool depending on...

...queues. Here are the details of the error. A hang (loop) occurs when a machine check is handled on System z due to a vlan device removal. A loop spinning for a response for final IO in virtnet_send_command() will never complete successfully because of a previous unsuccessfull host kick operation (virtqueue_kick()). Patch [1] changes the guest->host notification API. A potential error returned by the host during notify() should not be ignored, but used in order to reflect the error back to the affected virtqueue. Patch [2] changes virtqueue_kick() and virtqueue_notify() to return a bool depending on...

A virtio driver does virtqueue_add_buf() multiple times before finally calling virtqueue_kick(); previously we only exposed the added buffers in the virtqueue_kick() call. This means we don't need a memory barrier in virtqueue_add_buf(), but it reduces concurrency as the device (ie. host) can't see the buffers until the kick. Signed-off-by: Rusty Russell <rusty at rustcorp.com....

A virtio driver does virtqueue_add_buf() multiple times before finally calling virtqueue_kick(); previously we only exposed the added buffers in the virtqueue_kick() call. This means we don't need a memory barrier in virtqueue_add_buf(), but it reduces concurrency as the device (ie. host) can't see the buffers until the kick. Signed-off-by: Rusty Russell <rusty at rustcorp.com....

...re likely stuck with it now, so this layer just adds complexity and overhead. Further, the need to pass vq twice to each call (as in dev->vq->vq_ops->kick(dev->vq) ) adds potential for cut and paste errors. This patchset does the following: - add inline wrappers converting the above to virtqueue_kick(dev->vq) - convert all users to this API - remove vq_ops indirection, implementing virtqueue_xx directly in virtio_ring Note that if we ever want to add another vring implementation, we'll only need to revert the last patch in the series, devices won't have to change. -- MST Micha...

...re likely stuck with it now, so this layer just adds complexity and overhead. Further, the need to pass vq twice to each call (as in dev->vq->vq_ops->kick(dev->vq) ) adds potential for cut and paste errors. This patchset does the following: - add inline wrappers converting the above to virtqueue_kick(dev->vq) - convert all users to this API - remove vq_ops indirection, implementing virtqueue_xx directly in virtio_ring Note that if we ever want to add another vring implementation, we'll only need to revert the last patch in the series, devices won't have to change. -- MST Micha...

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 a...

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 a...