On Fri, Jan 16, 2026 at 2:04 PM Albert Esteve <[email protected]> wrote: > > On Fri, Jan 16, 2026 at 12:15 PM Michael S. Tsirkin <[email protected]> wrote: > > > > On Fri, Jan 16, 2026 at 11:20:25AM +0100, Albert Esteve wrote: > > > On Tue, Nov 11, 2025 at 10:11 AM Albert Esteve <[email protected]> wrote: > > > > > > > > Add GET_SHMEM_CONFIG vhost-user frontend > > > > message to the spec documentation. > > > > > > > > Reviewed-by: Alyssa Ross <[email protected]> > > > > Reviewed-by: Stefan Hajnoczi <[email protected]> > > > > Signed-off-by: Albert Esteve <[email protected]> > > > > --- > > > > docs/interop/vhost-user.rst | 39 +++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 39 insertions(+) > > > > > > > > diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst > > > > index 6c1d66d7d3..6a1ecd7f48 100644 > > > > --- a/docs/interop/vhost-user.rst > > > > +++ b/docs/interop/vhost-user.rst > > > > @@ -371,6 +371,20 @@ MMAP request > > > > - 0: Pages are mapped read-only > > > > - 1: Pages are mapped read-write > > > > > > > > +VIRTIO Shared Memory Region configuration > > > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > + > > > > ++-------------+---------+------------+----+--------------+ > > > > +| num regions | padding | mem size 0 | .. | mem size 255 | > > > > ++-------------+---------+------------+----+--------------+ > > > > + > > > > +:num regions: a 32-bit number of regions > > > > + > > > > +:padding: 32-bit > > > > + > > > > +:mem size: contains ``num regions`` 64-bit fields representing the > > > > size of each > > > > + VIRTIO Shared Memory Region > > > > + > > > > > > When implementing this for rust-vmm, the mem size came up a bit > > > confusing. In the last patch (7/7) of this series, the implementation > > > uses `num regions` as a count for the number of valid regions (thus > > > accounting for gaps in the shmem region mapping). Thus, `mem size` has > > > this confusing statement saying that it containers `num regions` > > > fields. It should say it contains 256 fields (it is only sent once > > > during initialization, so no need to save bytes here), with only `num > > > regions` that are valid (i.e., greater than 0). Maybe it could even > > > discard the `num regions` field, and send only the full array. > > > Thoughts? > > > > Let's discuss the exact wording here. > > I'm not sure why would we need this padding sending unused fields > > though. Waste no, need not? > > What about something like this: > > +:mem size: an array of 256 64-bit fields representing the size of each > + VIRTIO Shared Memory Region. ``num regions`` specifies the > + number of valid regions (non-zero size). The array index > + corresponds to the shared memory ID (shmid).
Just to be clear, I'd favour this change, which only entails a minor clarification on these lines. The rest of the series, including implementation and structures, remain unchanged. > > If you are suggesting removing the num regions+padding field, then the > description could be further simplified to: > > +:mem size: an array of 256 64-bit fields representing the size of each > + VIRTIO Shared Memory Region. The array index corresponds > + to the shared memory ID (shmid). > > > > > > > > > As much as I wanted this series merged, this deserves a clarification. > > > So I can either send a new version of the series or split the last > > > three patches into a different series. Hopefully it only requires one > > > more version though. > > > > > > > > > > C structure > > > > ----------- > > > > > > > > @@ -397,6 +411,7 @@ In QEMU the vhost-user message is implemented with > > > > the following struct: > > > > VhostUserShared object; > > > > VhostUserTransferDeviceState transfer_state; > > > > VhostUserMMap mmap; > > > > + VhostUserShMemConfig shmem; > > > > }; > > > > } QEMU_PACKED VhostUserMsg; > > > > > > > > @@ -1761,6 +1776,30 @@ Front-end message types > > > > Using this function requires prior negotiation of the > > > > ``VHOST_USER_PROTOCOL_F_DEVICE_STATE`` feature. > > > > > > > > +``VHOST_USER_GET_SHMEM_CONFIG`` > > > > + :id: 44 > > > > + :equivalent ioctl: N/A > > > > + :request payload: N/A > > > > + :reply payload: ``struct VhostUserShMemConfig`` > > > > + > > > > + When the ``VHOST_USER_PROTOCOL_F_SHMEM`` protocol feature has been > > > > + successfully negotiated, this message can be submitted by the > > > > front-end > > > > + to gather the VIRTIO Shared Memory Region configuration. The > > > > back-end will > > > > + respond with the number of VIRTIO Shared Memory Regions it requires, > > > > and > > > > + each shared memory region size in an array. The shared memory IDs are > > > > + represented by the array index. The information returned shall comply > > > > + with the following rules: > > > > + > > > > + * The shared information will remain valid and unchanged for the > > > > entire > > > > + lifetime of the connection. > > > > + > > > > + * The Shared Memory Region size must be a multiple of the page size > > > > + supported by mmap(2). > > > > + > > > > + * The size may be 0 if the region is unused. This can happen when the > > > > + device does not support an optional feature but does support a > > > > feature > > > > + that uses a higher shmid. > > > > + > > > > Back-end message types > > > > ---------------------- > > > > > > > > -- > > > > 2.49.0 > > > > > >
