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

["Graf (AWS), Alexander" <graf@amazon.de>]

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