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
