aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorAlbert Esteve <aesteve@redhat.com>2023-10-02 08:57:05 +0200
committerMichael S. Tsirkin <mst@redhat.com>2023-10-04 18:15:06 -0400
commit160947666276c5b7f6bca4d746bcac2966635d79 (patch)
treee8490108aee8e3dcda1d0a6cdf858f87f4c81de4 /docs
parentfaefdba8474fbc30427a64caa4dcd6df611f5b60 (diff)
downloadqemu-160947666276c5b7f6bca4d746bcac2966635d79.zip
qemu-160947666276c5b7f6bca4d746bcac2966635d79.tar.gz
qemu-160947666276c5b7f6bca4d746bcac2966635d79.tar.bz2
vhost-user: add shared_object msg
Add three new vhost-user protocol `VHOST_USER_BACKEND_SHARED_OBJECT_* messages`. These new messages are sent from vhost-user back-ends to interact with the virtio-dmabuf table in order to add or remove themselves as virtio exporters, or lookup for virtio dma-buf shared objects. The action taken in the front-end depends on the type stored in the virtio shared object hash table. When the table holds a pointer to a vhost backend for a given UUID, the front-end sends a VHOST_USER_GET_SHARED_OBJECT to the backend holding the shared object. The messages can only be sent after successfully negotiating a new VHOST_USER_PROTOCOL_F_SHARED_OBJECT vhost-user protocol feature bit. Finally, refactor code to send response message so that all common parts both for the common REPLY_ACK case, and other data responses, can call it and avoid code repetition. Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-4-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/interop/vhost-user.rst57
1 files changed, 57 insertions, 0 deletions
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 5a070ad..415bb47 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -1440,6 +1440,18 @@ Front-end message types
query the back-end for its device status as defined in the Virtio
specification.
+``VHOST_USER_GET_SHARED_OBJECT``
+ :id: 41
+ :equivalent ioctl: N/A
+ :request payload: ``struct VhostUserShared``
+ :reply payload: dmabuf fd
+
+ When the ``VHOST_USER_PROTOCOL_F_SHARED_OBJECT`` protocol
+ feature has been successfully negotiated, and the UUID is found
+ in the exporters cache, this message is submitted by the front-end
+ to retrieve a given dma-buf fd from a given back-end, determined by
+ the requested UUID. Back-end will reply passing the fd when the operation
+ is successful, or no fd otherwise.
Back-end message types
----------------------
@@ -1528,6 +1540,51 @@ is sent by the front-end.
The state.num field is currently reserved and must be set to 0.
+``VHOST_USER_BACKEND_SHARED_OBJECT_ADD``
+ :id: 6
+ :equivalent ioctl: N/A
+ :request payload: ``struct VhostUserShared``
+ :reply payload: N/A
+
+ When the ``VHOST_USER_PROTOCOL_F_SHARED_OBJECT`` protocol
+ feature has been successfully negotiated, this message can be submitted
+ by the backends to add themselves as exporters to the virtio shared lookup
+ table. The back-end device gets associated with a UUID in the shared table.
+ The back-end is responsible of keeping its own table with exported dma-buf fds.
+ When another back-end tries to import the resource associated with the UUID,
+ it will send a message to the front-end, which will act as a proxy to the
+ exporter back-end. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and
+ the back-end sets the ``VHOST_USER_NEED_REPLY`` flag, the front-end must
+ respond with zero when operation is successfully completed, or non-zero
+ otherwise.
+
+``VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE``
+ :id: 7
+ :equivalent ioctl: N/A
+ :request payload: ``struct VhostUserShared``
+ :reply payload: N/A
+
+ When the ``VHOST_USER_PROTOCOL_F_SHARED_OBJECT`` protocol
+ feature has been successfully negotiated, this message can be submitted
+ by the backend to remove themselves from to the virtio-dmabuf shared
+ table API. The shared table will remove the back-end device associated with
+ the UUID. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and the
+ back-end sets the ``VHOST_USER_NEED_REPLY`` flag, the front-end must respond
+ with zero when operation is successfully completed, or non-zero otherwise.
+
+``VHOST_USER_BACKEND_SHARED_OBJECT_LOOKUP``
+ :id: 8
+ :equivalent ioctl: N/A
+ :request payload: ``struct VhostUserShared``
+ :reply payload: dmabuf fd and ``u64``
+
+ When the ``VHOST_USER_PROTOCOL_F_SHARED_OBJECT`` protocol
+ feature has been successfully negotiated, this message can be submitted
+ by the backends to retrieve a given dma-buf fd from the virtio-dmabuf
+ shared table given a UUID. Frontend will reply passing the fd and a zero
+ when the operation is successful, or non-zero otherwise. Note that if the
+ operation fails, no fd is sent to the backend.
+
.. _reply_ack:
VHOST_USER_PROTOCOL_F_REPLY_ACK