Re: [RFC PATCH 06/12] virtio: add a device memory buffer region allocator

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

On Mon, Aug 10, 2026 at 07:57:13AM +0000, Graf (AWS), Alexander wrote:
> 
> On 10.08.26 00:38, Michael S. Tsirkin wrote:
> > On Sun, Aug 09, 2026 at 06:20:04PM +0000, Alexander Graf wrote:
> >> In preparation to support VIRTIO_F_DMB, create a mechanism to allocate
> >> and map memory from the Device Memory Buffer (DMB). The DMB is a shared
> >> memory region a device exposes and owns. A device that negotiates the
> >> feature expects its virtqueues and all the buffers we hand it to live in
> >> that region, and every address we publish to it is a byte offset into
> >> the region.
> >>
> >> Add virtio_dmb_init(), which locates the region by the shared memory id
> >> the device reports and builds a page-granular allocator over it, and
> >> virtio_dmb_destroy() to tear that down. Add virtio_dmb_map_ops, a struct
> >> virtio_map_ops implementation that hands out allocations from that
> >> allocator as region offsets: alloc() places a virtqueue area in the
> >> region, map_page() copies a buffer that lives elsewhere into it and
> >> copies it back on unmap. The map operations reach that allocator through
> >> a new dmb member of union virtio_map.
> >>
> >> The shared memory id is transport specific, so add a get_dmb_shm_id()
> >> callback to struct virtio_config_ops for a transport to report it. A
> >> transport that does not implement it must not accept VIRTIO_F_DMB. Add
> >> CONFIG_VIRTIO_DMB to enable this support. It defaults to y, and a kernel
> >> that will never meet such a device can turn it off to leave the
> >> allocator and its bookkeeping out.
> >>
> >> Link: https://lore.kernel.org/virtio-comment/20260804161202.38619-1-graf@amazon.com/
> >> Assisted-by: Kiro:claude-opus-5 checkpatch sparse
> >> Signed-off-by: Alexander Graf <graf@amazon.com>
> >
> >
> >
> >> ---
> >>   drivers/virtio/Kconfig        |   15 +
> >>   drivers/virtio/Makefile       |    3 +-
> >>   drivers/virtio/virtio_dmb.c   | 1317 +++++++++++++++++++++++++++++++++
> >>   drivers/virtio/virtio_dmb.h   |   28 +
> >>   include/linux/virtio.h        |    3 +
> >>   include/linux/virtio_config.h |    8 +
> >
> > Really >1000 lines to implement a virtio specific allocator?
> >
> > Can't we start e.g. with gen alloc and maybe xarray if you
> > need some metadata?
> >
> >
> > I guess virtio sync is annoying, it gets handle + offset is that the
> > issue? We can fix them though. Or let's just not support them. There
> > were there for premapped originally but now it uses page pool.
> >
> > Maybe I will send a patch to drop sync completely.
> 
> 
> I started off with gen_alloc. And then over time it slowly morphed into 
> what you're seeing here when I ran into issues with multi-queue 
> allocations (split the buffer by VQ pair so that we don't run into lock 
> contention) and zero-copy vsock transfers (by keeping DMB buffers 
> statically allocated).
> 
> I agree that it's a bit much for the initial post. How about I revert 
> back to the gen_alloc variant and we look at the optimizations as 
> follow-up? Since everything is guest driven, we can play with them as 
> much as we like in future improvements.
> 
> 
> Alex

Indeed. Or improve gen alloc)

-- 
MST