Re: [PATCH v3] Add VIRTIO_F_DMB (Device Memory Buffer)

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Aug 06, 2026 at 12:09:04PM -0400, Demi Marie Obenour wrote:
> On 8/4/26 12:12, Alexander Graf wrote:
> > When a transport uses a shared bounce region for virtqueue memory today,
> > that region is global and shared by multiple devices at once. Devices
> > then contend over one small region, so a busy device can starve the
> > others, and one device's emulation cannot be isolated or torn down on its
> > own because its state lives in memory everyone else is using too.
> > 
> > VIRTIO_F_DMB gives each device its own shared memory region, the Device
> > Memory Buffer, that holds that device's virtqueues (Descriptor, Driver
> > and Device Areas) and the buffers the descriptors reference. When the
> > feature is negotiated, every address the driver places in a virtqueue is
> > an offset into that region rather than a physical or bus address, so the
> > device only ever touches memory the driver placed there. Because each
> > device owns its region, its emulation can run in a separate host process
> > and be terminated independently, and devices no longer contend over one
> > shared region.
> > 
> > The device reports the region's shmid through a transport-specific
> > mechanism (dmb_shm_id in the PCI common configuration structure, DMBSHMId
> > on MMIO), so the shmid does not collide with device-specific or future
> > transport-specific shared memory regions. The driver locates the region
> > through the existing Shared Memory Regions facility. VIRTIO_F_DMB refines
> > VIRTIO_F_ACCESS_PLATFORM and is negotiated only together with it.
> > 
> > To provide the confinement guarantee, the device bounds-checks every
> > driver-supplied offset against the region and sets DEVICE_NEEDS_RESET on
> > violation.
> > 
> > The general requirement on shared memory regions forbids a device to
> > expose a region used to control its operation or to stream data, and a
> > Device Memory Buffer is used for both, so it is named as that
> > requirement's exception.
> > 
> > The Device Memory Buffer is memory the driver shares with the device on
> > platforms that distinguish shared from private mappings, and the device
> > provides coherency without cache maintenance by the driver. A device
> > that requires the platform's barriers offers VIRTIO_F_ORDER_PLATFORM,
> > and a driver accepts VIRTIO_F_DMB only together with it. Offset 0 in
> > the region is reserved: a device that predates the feature reads a
> > Descriptor Area address of 0 as a queue that is not in use, as the
> > legacy QueuePFN register states.
> 
> I think this is going to be a prerequisite for strongly isolating
> vhost-user backends (so they can't compromise the frontend)

compromise the frontend how?

> while
> maintaining high performance.  One can use shadow virtqueues, but
> this will add extra round-trips.

At the cost of guest bouncing all data around each time it
moves between devices? Let's say, this is not a fit for
all use-cases. A more universal approach would allow data
in a pool shared by a group of devices.


But I guess at that point, why don't we just invent a virtio iommu
command to describe all this? We don't really need a special device
mode just to limit access to guest memory.



So Alex, now I'd like to know what exactly is the actual use-case,
because if it's not really on-device memory, there are better
ways to do it.



-- 
MST