| Message ID | 20240912144432.126717-4-aesteve@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Document SHMEM vhost-user requests | expand |
Albert Esteve <aesteve@redhat.com> writes: > Add GET_SHMEM_CONFIG vhost-user frontend > message to the spec documentation. > > Signed-off-by: Albert Esteve <aesteve@redhat.com> > --- > docs/interop/vhost-user.rst | 39 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) Reviewed-by: Alyssa Ross <hi@alyssa.is>
On Thu, Sep 12, 2024 at 04:44:32PM +0200, Albert Esteve wrote: > Add GET_SHMEM_CONFIG vhost-user frontend > message to the spec documentation. > > Signed-off-by: Albert Esteve <aesteve@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 ec898d2440..fb7b27ce94 100644 > --- a/docs/interop/vhost-user.rst > +++ b/docs/interop/vhost-user.rst > @@ -348,6 +348,19 @@ 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 What is the purpose of this field? Does it indicate the number of mem size elements (i.e. the array can be truncated if there are fewer than 256 elements) or the number of non-zero length elements? > + > +:padding: 32-bit > + > +:mem size: 64-bit size of VIRTIO Shared Memory Region > + > C structure > ----------- > > @@ -372,6 +385,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; > > @@ -1054,6 +1068,7 @@ Protocol features > #define VHOST_USER_PROTOCOL_F_XEN_MMAP 17 > #define VHOST_USER_PROTOCOL_F_SHARED_OBJECT 18 > #define VHOST_USER_PROTOCOL_F_DEVICE_STATE 19 > + #define VHOST_USER_PROTOCOL_F_SHMEM 20 > > Front-end message types > ----------------------- > @@ -1728,6 +1743,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. Back-end will "Back-end will" -> "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 index of the array. The information returned shall "index of the array" -> either "array index" or "index of the array element". > + 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.45.2 >
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index ec898d2440..fb7b27ce94 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -348,6 +348,19 @@ 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: 64-bit size of VIRTIO Shared Memory Region + C structure ----------- @@ -372,6 +385,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; @@ -1054,6 +1068,7 @@ Protocol features #define VHOST_USER_PROTOCOL_F_XEN_MMAP 17 #define VHOST_USER_PROTOCOL_F_SHARED_OBJECT 18 #define VHOST_USER_PROTOCOL_F_DEVICE_STATE 19 + #define VHOST_USER_PROTOCOL_F_SHMEM 20 Front-end message types ----------------------- @@ -1728,6 +1743,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. 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 index of the array. 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 ----------------------
Add GET_SHMEM_CONFIG vhost-user frontend message to the spec documentation. Signed-off-by: Albert Esteve <aesteve@redhat.com> --- docs/interop/vhost-user.rst | 39 +++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)