similar to: [PATCH 5 of 5] virtio: expose added descriptors immediately

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

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

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the

Improves cacheline transfer flow of available ring header. Virtqueues are implemented as a pair of rings, one producer->consumer avail ring and one consumer->producer used ring; preceding the avail ring in memory are two contiguous u16 fields -- avail->flags and avail->idx. A producer posts work by writing to avail->idx and a consumer reads avail->idx. The flags and idx fields

Improves cacheline transfer flow of available ring header. Virtqueues are implemented as a pair of rings, one producer->consumer avail ring and one consumer->producer used ring; preceding the avail ring in memory are two contiguous u16 fields -- avail->flags and avail->idx. A producer posts work by writing to avail->idx and a consumer reads avail->idx. The flags and idx fields

On Wed, Nov 29, 2017 at 09:55:22PM +0800, Wei Wang wrote: > Current virtqueue_add API implementation is based on the scatterlist > struct, which uses kaddr. This is inadequate to all the use case of > vring. For example: > - Some usages don't use IOMMU, in this case the user can directly pass > in a physical address in hand, instead of going through the sg >

On Wed, Nov 29, 2017 at 09:55:22PM +0800, Wei Wang wrote: > Current virtqueue_add API implementation is based on the scatterlist > struct, which uses kaddr. This is inadequate to all the use case of > vring. For example: > - Some usages don't use IOMMU, in this case the user can directly pass > in a physical address in hand, instead of going through the sg >

Current virtqueue_add API implementation is based on the scatterlist struct, which uses kaddr. This is inadequate to all the use case of vring. For example: - Some usages don't use IOMMU, in this case the user can directly pass in a physical address in hand, instead of going through the sg implementation (e.g. the VIRTIO_BALLOON_F_SG feature) - Sometimes, a guest physical page may not have

virtqueue ops were introduced in the hope that we'll have multiple implementations besides virtio_ring, but none have surfaced so far, and given that existing virtio ring is deployed in production we are 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

virtqueue ops were introduced in the hope that we'll have multiple implementations besides virtio_ring, but none have surfaced so far, and given that existing virtio ring is deployed in production we are 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

This adds wrappers to switch between native endian-ness (virtio 0.9) and virtio endian-ness (virtio 1.0). Add new typedefs as well, so that we can check statically that we didn't miss any accesses. All callers simply pass in false (0.9) so no functional change for now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Sending this early so I can get feedback on this style.

This adds wrappers to switch between native endian-ness (virtio 0.9) and virtio endian-ness (virtio 1.0). Add new typedefs as well, so that we can check statically that we didn't miss any accesses. All callers simply pass in false (0.9) so no functional change for now. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Sending this early so I can get feedback on this style.

They're generic concepts, so hoist them. This also avoids accessor functions. This goes even further than Jason Wang's 17bb6d4088 patch ("virtio-ring: move queue_index to vring_virtqueue") which moved the queue_index from the specific transport. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/virtio/virtio_mmio.c | 4 ++--

They're generic concepts, so hoist them. This also avoids accessor functions. This goes even further than Jason Wang's 17bb6d4088 patch ("virtio-ring: move queue_index to vring_virtqueue") which moved the queue_index from the specific transport. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/virtio/virtio_mmio.c | 4 ++--

Changes from v2: added padding between avail idx and flags, and changed virtio to only publish used index when callbacks are enabled. Here's a rewrite of the original patch with a new layout. I haven't tested it yet so no idea how this performs, but I think this addresses the cache bounce issue raised by Avi. Posting for early flames/comments. Generally, the Host end of the virtio ring

Changes from v2: added padding between avail idx and flags, and changed virtio to only publish used index when callbacks are enabled. Here's a rewrite of the original patch with a new layout. I haven't tested it yet so no idea how this performs, but I think this addresses the cache bounce issue raised by Avi. Posting for early flames/comments. Generally, the Host end of the virtio ring

On 2018?02?23? 19:18, Tiwei Bie wrote: > Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> > --- > drivers/virtio/virtio_ring.c | 699 +++++++++++++++++++++++++++++++++++++------ > include/linux/virtio_ring.h | 8 +- > 2 files changed, 618 insertions(+), 89 deletions(-) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index