Add GET_SHMEM_CONFIG vhost-user frontend
message to the spec documentation.
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 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
----------------------
--
2.45.2
