In practice the protocol negotiation between vhost master and slave occurs before the final feature negotiation between backend and frontend. This has lead to an inconsistency between the rust-vmm vhost implementation and the libvhost-user library in their approaches to checking if all the requirements for REPLY_ACK processing were met. As this is purely a function of the protocol negotiation and not of interest to the frontend lets make the language clearer about the requirements for a successfully negotiated protocol feature.
Signed-off-by: Alex Bennée <[email protected]> Cc: Jiang Liu <[email protected]> --- docs/interop/vhost-user.rst | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index d6085f7045..3ac221a8c7 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -301,12 +301,22 @@ If *slave* detects some error such as incompatible features, it may also close the connection. This should only happen in exceptional circumstances. Any protocol extensions are gated by protocol feature bits, which -allows full backwards compatibility on both master and slave. As -older slaves don't support negotiating protocol features, a feature +allows full backwards compatibility on both master and slave. As older +slaves don't support negotiating protocol features, a device feature bit was dedicated for this purpose:: #define VHOST_USER_F_PROTOCOL_FEATURES 30 +However as the protocol negotiation something that only occurs between +parts of the backend implementation it is permissible to for the master +to mask the feature bit from the guest. As noted for the +``VHOST_USER_GET_PROTOCOL_FEATURES`` and +``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a +final ``VHOST_USER_SET_FEATURES`` comes from the guest. So the +enabling of protocol features need only require the advertising of the +feature by the slave and the successful get/set protocol features +sequence. + Starting and stopping rings --------------------------- -- 2.20.1 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
