From: Demi Marie Obenour <demiobenour@gmail.com>
To: Alexander Graf <graf@amazon.com>, virtio-comment@lists.linux.dev
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowangio@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3] Add VIRTIO_F_DMB (Device Memory Buffer)
Date: Thu, 6 Aug 2026 12:09:04 -0400 [thread overview]
Message-ID: <044ee495-d958-4c91-9627-da4ce591e737@gmail.com> (raw)
In-Reply-To: <20260804161202.38619-1-graf@amazon.com>
[-- Attachment #1.1: Type: text/plain, Size: 2717 bytes --]
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) while
maintaining high performance. One can use shadow virtqueues, but
this will add extra round-trips.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-08-06 16:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 21:54 [PATCH v2] content: Add VIRTIO_F_DMB (Device Memory Buffer) Alexander Graf
2026-08-04 16:12 ` [PATCH v3] " Alexander Graf
2026-08-06 16:09 ` Demi Marie Obenour [this message]
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=044ee495-d958-4c91-9627-da4ce591e737@gmail.com \
--to=demiobenour@gmail.com \
--cc=graf@amazon.com \
--cc=jasowangio@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox