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/[email protected]/ > >> Assisted-by: Kiro:claude-opus-5 checkpatch sparse > >> Signed-off-by: Alexander Graf <[email protected]> > > > > > > > >> --- > >> 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
