linux.git/include/linux/virtio.h, branch v7.2-rc1

virtio: add missing kernel-doc for map and vmap members

2026-06-10T06:14:01+00:00

Commit bee8c7c24b73 ("virtio: introduce map ops in virtio core") and
commit b16060c5c7d5 ("virtio: introduce virtio_map container union")
added 'map' and 'vmap' members to struct virtio_device but did not
update the kernel-doc comment block. This caused 'make htmldocs' to
emit warnings:

  ./include/linux/virtio.h:188 struct member 'map' not described in 'virtio_device'
  ./include/linux/virtio.h:188 struct member 'vmap' not described in 'virtio_device'

Add the missing entries in struct-declaration order to match the
existing convention in the file. After this patch, 'make htmldocs'
no longer emits these warnings.

Fixes: bee8c7c24b73 ("virtio: introduce map ops in virtio core")
Fixes: b16060c5c7d5 ("virtio: introduce virtio_map container union")
Reported-by: Luis Felipe Hernandez 

Signed-off-by: Christian Fontanez 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260519013321.32511-1-christfontanez@gmail.com>

vduse: return internal vq group struct as map token

2026-01-28T20:32:16+00:00

Return the internal struct that represents the vq group as virtqueue map
token, instead of the device.  This allows the map functions to access
the information per group.

At this moment all the virtqueues share the same vq group, that only
can point to ASID 0.  This change prepares the infrastructure for actual
per-group address space handling

Acked-by: Jason Wang 
Signed-off-by: Eugenio Pérez 
Signed-off-by: Michael S. Tsirkin 
Message-Id: <20260119143306.1818855-5-eperezma@redhat.com>

virtio: add virtqueue_add_inbuf_cache_clean API

2026-01-02T11:22:49+00:00

Add virtqueue_add_inbuf_cache_clean() for passing DMA_ATTR_CPU_CACHE_CLEAN
to virtqueue operations. This suppresses DMA debug cacheline overlap
warnings for buffers where proper cache management is ensured by the
caller.

Message-ID: 
Signed-off-by: Michael S. Tsirkin

virtio: make it self-contained

2025-12-24T13:02:55+00:00

virtio.h uses struct module, add a forward declaration to
make the header self-contained.

Message-ID: <9171b5cac60793eb59ab044c96ee038bf1363bee.1764873799.git.mst@redhat.com>
Acked-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin

virtio: clean up features qword/dword terms

2025-11-27T07:03:07+00:00

virtio pci uses word to mean "16 bits". mmio uses it to mean
"32 bits".

To avoid confusion, let's avoid the term in core virtio
altogether. Just say U64 to mean "64 bit".

Fixes: e7d4c1c5a546 ("virtio: introduce extended features")
Cc: Paolo Abeni 
Acked-by: Jason Wang 
Message-ID: 
Signed-off-by: Michael S. Tsirkin

vduse: switch to use virtio map API instead of DMA API

2025-10-01T11:24:55+00:00

Lacking the support of device specific mapping supported in virtio,
VDUSE must trick the DMA API in order to make virtio-vdpa transport
work. This is done by advertising vDPA device as dma device with a
VDUSE specific dma_ops even if it doesn't do DMA at all.

This will be fixed by this patch. Thanks to the new mapping operations
support by virtio and vDPA. VDUSE can simply switch to advertise its
specific mappings operations to virtio via virtio-vdpa then DMA API is
not needed for VDUSE any more and iova domain could be used as the
mapping token instead.

Signed-off-by: Jason Wang 
Message-Id: <20250924070045.10361-3-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Eugenio Pérez

virtio: introduce map ops in virtio core

2025-10-01T11:24:43+00:00

This patch introduces map operations for virtio device. Virtio used to
use DMA API which is not necessarily the case since some devices
doesn't do DMA. Instead of using tricks and abusing DMA API, let's
simply abstract the current mapping logic into a virtio specific
mapping operations. For the device or transport that doesn't do DMA,
they can implement their own mapping logic without the need to trick
DMA core. In this case the mapping metadata is opaque to the virtio
core that will be passed back to the transport or device specific map
operations. For other devices, DMA API will still be used, so map
token will still be the dma device to minimize the changeset and
performance impact.

The mapping operations are abstracted as a independent structure
instead of reusing virtio_config_ops. This allows the transport can
simply reuse the structure for lower layers like vDPA.

A set of new mapping helpers were introduced for the device that want
to do mapping by themselves.

Signed-off-by: Jason Wang 
Message-Id: <20250821064641.5025-7-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin 
Tested-by: Lei Yang 
Reviewed-by: Eugenio Pérez

virtio: introduce virtio_map container union

2025-10-01T11:24:43+00:00

Following patch will introduce the mapping operations for virtio
device. In order to achieve this, besides the dma device, virtio core
needs to support a transport or device specific mapping metadata as well.
So this patch introduces a union container of a dma device. The idea
is the allow the transport layer to pass device specific mapping
metadata which will be used as a parameter for the virtio mapping
operations. For the transport or device that is using DMA, dma device
is still being used.

Signed-off-by: Jason Wang 
Message-Id: <20250821064641.5025-5-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin 
Tested-by: Lei Yang 
Reviewed-by: Eugenio Pérez

virtio: rename dma helpers

2025-10-01T11:24:43+00:00

Following patch will introduce virtio mapping function to avoid
abusing DMA API for device that doesn't do DMA. To ease the
introduction, this patch rename "dma" to "map" for the current dma
mapping helpers.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Xuan Zhuo 
Signed-off-by: Jason Wang 
Message-Id: <20250821064641.5025-4-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin 
Tested-by: Lei Yang 
Reviewed-by: Eugenio Pérez

virtio_ring: constify virtqueue pointer for DMA helpers

2025-10-01T11:24:43+00:00

This patch constifies the virtqueue pointer for DMA helpers.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Xuan Zhuo 
Reviewed-by: Eugenio Pérez 
Signed-off-by: Jason Wang 
Message-Id: <20250821064641.5025-2-jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin 
Tested-by: Lei Yang 
Reviewed-by: Eugenio Pérez