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? 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 >
