All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <graf@amazon.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowangio@gmail.com>
Cc: nh-open-source@amazon.com,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: [PATCH v2 05/12] virtio: add the VIRTIO_F_DMB feature bit
Date: Tue, 18 Aug 2026 21:14:18 +0000	[thread overview]
Message-ID: <20260818211425.91009-6-graf@amazon.com> (raw)
In-Reply-To: <20260818211425.91009-1-graf@amazon.com>

In preparation to support VIRTIO_F_DMB, define the feature bit. A device
that negotiates it holds its virtqueues and the buffers they reference in
a Device Memory Buffer, a shared memory region the device owns. The data
DMA of such a device is routed through a per-device transparent IOMMU
whose bus address space maps 1:1 onto that region, so every address the
driver places in a virtqueue is an address in that space and the device
can reach nothing the driver has not published there.

Define VIRTIO_F_DMB as 44 and raise VIRTIO_TRANSPORT_F_END to 45, so
virtio_dev_probe() preserves the bit into finalize_features() where a
transport can act on it. VIRTIO_DEVICE_F_MASK derives from the same bound
and moves with it. vdpa reads the bound as VIRTIO_TRANSPORT_F_END + 1
while vring_transport_features() stops below it, so the mask drops bits
43 to 45 from the device_features vdpa reports over netlink, one bit
beyond the last bit a transport can act on.

Define VIRTIO_DMB_MEM_TYPE_COHERENT too. A device reports the memory
type of its region, and this is the one type that says a write by either
side becomes visible to the other with no cache maintenance by the
driver. Every transport reports the same type, so the name belongs here
beside the feature bit and not in the header of one of them.

Link: https://lore.kernel.org/virtio-comment/20260818060255.6853-1-graf@amazon.com/
Assisted-by: Kiro:claude-opus-5 checkpatch sparse
Signed-off-by: Alexander Graf <graf@amazon.com>
---

  - Say bus address space rather than IOVA space

---
 include/uapi/linux/virtio_config.h | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h
index 2445f365bce7..8cfd9436a09e 100644
--- a/include/uapi/linux/virtio_config.h
+++ b/include/uapi/linux/virtio_config.h
@@ -52,7 +52,7 @@
  * rest are per-device feature bits.
  */
 #define VIRTIO_TRANSPORT_F_START	28
-#define VIRTIO_TRANSPORT_F_END		42
+#define VIRTIO_TRANSPORT_F_END		45
 
 #ifndef VIRTIO_CONFIG_NO_LEGACY
 /* Do we get callbacks when the ring is completely used, even if we've
@@ -120,4 +120,26 @@
  */
 #define VIRTIO_F_ADMIN_VQ		41
 
+/*
+ * This feature indicates that the device offers a Device Memory Buffer: a
+ * shared memory region, owned by the device, that holds the virtqueues and
+ * the buffers they reference.  When this feature is negotiated, the data DMA
+ * of the device is routed through a per-device transparent IOMMU whose bus
+ * address space maps 1:1 onto that region, so every address the driver
+ * places in a virtqueue is an address in that space and the device can
+ * reach nothing the driver has not published there.  Interrupts are
+ * unaffected.
+ */
+#define VIRTIO_F_DMB			44
+
+/*
+ * The memory type of a Device Memory Buffer region, as the device reports it.
+ * VIRTIO_DMB_MEM_TYPE_COHERENT means a write by either side becomes visible to
+ * the other with no cache maintenance by the driver.  Every other value is
+ * reserved.  A device reports the type from the moment it offers
+ * VIRTIO_F_DMB, and a driver must not accept the feature unless the type is
+ * one it supports.
+ */
+#define VIRTIO_DMB_MEM_TYPE_COHERENT	0
+
 #endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */

  parent reply	other threads:[~2026-08-18 21:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 21:14 [PATCH v2 00/12] virtio: support devices that own their virtqueue memory Alexander Graf
2026-08-18 21:14 ` [PATCH v2 01/12] virtio_ring: remove the unused map sync API Alexander Graf
2026-08-18 21:14 ` [PATCH v2 02/12] virtio: drop the sync operations from virtio_map_ops Alexander Graf
2026-08-18 21:14 ` [PATCH v2 03/12] vdpa: drop the VIRTIO_DEVICE_F_MASK example value Alexander Graf
2026-08-18 21:14 ` [PATCH v2 04/12] virtio_ring: return -ENOMEM when a packed ring mapping fails Alexander Graf
2026-08-18 21:14 ` Alexander Graf [this message]
2026-08-18 21:14 ` [PATCH v2 06/12] virtio_pci: read the device memory buffer registers Alexander Graf
2026-08-18 21:14 ` [PATCH v2 07/12] virtio_pci: create virtqueues with the device's mapping token Alexander Graf
2026-08-18 21:14 ` [PATCH v2 08/12] virtio: add a device memory buffer region allocator Alexander Graf
2026-08-18 21:14 ` [PATCH v2 09/12] virtio: locate the device memory buffer after feature negotiation Alexander Graf
2026-08-18 21:14 ` [PATCH v2 10/12] virtio: treat VIRTIO_F_DMB as implying VIRTIO_F_ACCESS_PLATFORM Alexander Graf
2026-08-18 21:14 ` [PATCH v2 11/12] virtio_pci: support VIRTIO_F_DMB Alexander Graf
2026-08-18 21:40   ` sashiko-bot
2026-08-18 21:14 ` [PATCH v2 12/12] virtio: expose device memory buffer occupancy over debugfs Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260818211425.91009-6-graf@amazon.com \
    --to=graf@amazon.com \
    --cc=eperezma@redhat.com \
    --cc=jasowangio@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=nh-open-source@amazon.com \
    --cc=pbonzini@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.