On 10.08.26 00:38, Michael S. Tsirkin wrote:
On Sun, Aug 09, 2026 at 06:20:04PM +0000, Alexander Graf wrote:
quoted
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/ (local)
Assisted-by: Kiro:claude-opus-5 checkpatch sparse
Signed-off-by: Alexander Graf <graf@amazon.com>
quoted
---
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