Virtio RFC proposes device-owned queue memory for isolation

Alexander Graf has posted an RFC series proposing VIRTIO_F_DMB, a virtio transport feature that lets a device own a dedicated Device Memory Buffer for its virtqueues and the buffers those queues reference.

Today virtio backs queues from guest memory, so a VMM must map that memory. That is awkward for confidential computing, where guest RAM is meant to stay opaque (swiotlb bounce buffering is the usual workaround), and it undermines isolated vhost-user backends by giving them visibility into all of guest RAM. With DMB, the device exposes one shared region that both sides treat as the full memory map they share. Addresses the driver publishes become offsets into that region. Because the change sits in the transport layer, higher-level virtio drivers would keep working unmodified.

Graf argues DMB improves on swiotlb in three ways. It lives in virtio rather than as an OS DMA primitive, so any guest OS that implements the transport can support it, including Windows. Each device gets its own DMA space, so a vhost-user process can be given access only to its DMB region. Hypervisors can also require DMB selectively for less-trusted backends while leaving self-implemented devices on classic semantics, so untrusted devices never see memory belonging to trusted ones.

The series wires modern PCI only so far. Feature bit 44 and the shared-memory id register are provisional pending allocation by the virtio Technical Committee. Accepting the feature is gated on related platform-access and ordering bits, a kernel config option (default on), and virtio 1.0. Supporting code includes a page-granular allocator over the region, mapping ops that bounce foreign buffers in and out, a small reserved slice so an empty queue can still post a first descriptor under pressure, debugfs occupancy counters under the existing virtio debug option, and driver-API documentation.

The proposal was posted as an RFC for review on the relevant kernel development lists.