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

On Mon, Aug 10, 2026 at 08:09:19AM +0000, Graf (AWS), Alexander wrote:
> 
> On 10.08.26 07:59, Michael S. Tsirkin wrote:
> > 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.
> 
> 
> Why would we want to use a common pool across multiple devices? All 
> we're creating is more visibility to device backends and more lock 
> contention across multiple consumers, no?

Not sure what "contention" is. I think when you say pool you
mean the allocator. But let me clarify, what I mean
is data coming from device 1 and out to device 2, without
full data copies on the way.

People are already doing this for performance and I like it
when one can pick multiple points on security/performance curve,
not one.

> By keeping everything per-device, we have a super straight forward, 
> simple path that is very easy to reason about.
> 

I'm with you on keeping simple things simple but I'd like to make
complex things possible.

> > 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.
> 
> 
> My main use case is to create a confidential VM which has completely 
> static layout. The entity that backs device emulation (owns the DMB 
> region) is untrusted. The entity that implements the virtio machinery is 
> trusted. Private/shared state of memory should not change at runtime.
> 
> 
> Alex

No problem with that.