Add GET_SHMEM_CONFIG vhost-user frontend message to the spec documentation.
Reviewed-by: Alyssa Ross <h...@alyssa.is> Signed-off-by: Albert Esteve <aest...@redhat.com> --- 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 c15d6ac467..96156f1900 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -350,6 +350,20 @@ Device state transfer parameters In the future, additional phases might be added e.g. to allow iterative migration while the device is running. +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 + C structure ----------- @@ -376,6 +390,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; @@ -1733,6 +1748,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.48.1