docs/interop/vhost-user.rst

24 message.
61 Message Specification
66 A vhost-user message consists of 3 header fields and a payload.
244 An IOTLB message
263 :type: an 8-bit IOTLB message type:
356 In QEMU the vhost-user message is implemented with the following struct:
385 The communication consists of the *front-end* sending message requests and
386 the *back-end* sending message replies. Most of the requests don't require
414 If *front-end* is unable to send the full message or receives a wrong
461 ``VHOST_USER_SET_VRING_KICK`` or receiving the in-band message
467 In addition, upon receiving a ``VHOST_USER_SET_FEATURES`` message from
504 The max number of queues the back-end supports can be queried with message
509 queue in the sent message to identify a specified queue.
511 The front-end enables queues by sending message ``VHOST_USER_SET_VRING_ENABLE``.
544 ``VHOST_USER_SET_LOG_BASE`` message when the back-end has
569 ``VHOST_USER_SET_LOG_FD`` is an optional message with an eventfd in
612 ``VHOST_USER_SET_DEVICE_STATE_FD`` message.  This message has two
656 closed), it sends the ``VHOST_USER_CHECK_DEVICE_STATE`` message to
665 ``VHOST_USER_SET_MEM_TABLE`` message.  Each region has two base
692 has to be filled with the update message type (2), the I/O virtual
696 ``iotlb`` payload has to be filled with the invalidation message type
705 miss message type (1), the I/O virtual address and the permissions
707 with the access failure message type (4), the I/O virtual address and
712 either front-end sent an update message containing the IOTLB entry
714 the IOTLB miss message is invalid (invalid IOVA or permission).
736 each message) to front-end via ancillary data using this fd communication
1022 the former is necessary for getting a message channel from the back-end
1028 ``VHOST_USER_SET_PROTOCOL_FEATURES`` message that sets the in-band
1057 Front-end message types
1096    support this message even before ``VHOST_USER_SET_FEATURES`` was
1113    this message even before ``VHOST_USER_SET_FEATURES`` was called.
1135    that back-ends either ignore this message, or use it to disable all
1159    reception of this message may the guest start accessing the memory
1172   ``VHOST_USER_SET_LOG_BASE`` message, the size and offset of shared
1173   memory area provided in the message.
1234       covered by this message.
1265   this message isn't necessary as the ring is also started on the
1266   ``VHOST_USER_VRING_KICK`` message, it may however still be used to
1268   message) or to enable polling.
1284   ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message
1285   isn't necessary as the ``VHOST_USER_BACKEND_VRING_CALL`` message can be
1302   ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message
1303   isn't necessary as the ``VHOST_USER_BACKEND_VRING_ERR`` message can be
1305   (which will be preferred over the message).
1382   :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type)
1408   endiannesses and expect this message once (per VQ) during device
1417   When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is
1431   When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is
1496   When ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` is supported, this message
1509   been successfully negotiated, this message is submitted by the front-end to
1521   been successfully negotiated, this message is submitted by the front-end to
1556   feature has been successfully negotiated, this message may be
1570   feature has been successfully negotiated, this message is submitted
1571   by the front-end to the back-end. The back-end should return the message with a
1584   feature has been successfully negotiated, this message is submitted
1585   by the front-end to the back-end. The message payload contains a memory
1590   ``VHOST_USER_REM_MEM_REG`` message, this message is used to set and
1608   feature has been successfully negotiated, this message is submitted
1609   by the front-end to the back-end. The message payload contains a memory
1614   ``VHOST_USER_ADD_MEM_REG`` message, this message is used to set and
1632   successfully negotiated, this message is submitted by the front-end to
1643   successfully negotiated, this message is submitted by the front-end to
1655   in the exporters cache, this message is submitted by the front-end
1686   ``VHOST_USER_SET_DEVICE_STATE_FD`` message.  The back-end may create a
1730 Back-end message types
1733 For this type of message, the request is sent by the back-end and the reply
1738   :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type)
1761   message to the back-end to get the latest content. If
1796   feature has been successfully negotiated, this message may be
1810   feature has been successfully negotiated, this message may be
1824   feature has been successfully negotiated, this message can be submitted
1829   it will send a message to the front-end, which will act as a proxy to the
1842   feature has been successfully negotiated, this message can be submitted
1845   it) will have permission to remove it. Otherwise, the message is ignored.
1858   feature has been successfully negotiated, this message can be submitted
1878 on failure, unless the message already has an explicit reply body.
1885 For the message types that already solicit a reply from the back-end,
1912 != 0. It may also print a message to stderr for further details.