Stefan Hajnoczi <stefa...@redhat.com> writes:
> On Wed, Mar 03, 2021 at 05:01:05PM -0500, Michael S. Tsirkin wrote: >> On Wed, Mar 03, 2021 at 02:50:11PM +0000, Alex Bennée wrote: >> Also, are we sure it's ok to send the messages and then send >> VHOST_USER_SET_FEATURES with VHOST_USER_F_PROTOCOL_FEATURES clear? >> Looks more like a violation to me ... > > Looking again I agree it would be a violation to omit > VHOST_USER_F_PROTOCOL_FEATURES in VHOST_USER_SET_FEATURES. > > Previously I only looked at VHOST_USER_SET_PROTOCOL_FEATURES where the > spec says: > > Only legal if feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` is present in > ``VHOST_USER_GET_FEATURES``. > > So negotiation is *not* necessary for sending > VHOST_USER_SET_PROTOCOL_FEATURES. > > However, I missed that other features *do* require negotiation of > VHOST_USER_F_PROTOCOL_FEATURES according to the spec. For example: > > If ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been negotiated, the > ring is initialized in an enabled state. > > Now I think: > > 1. VHOST_USER_F_PROTOCOL_FEATURES *must* be included > VHOST_USER_SET_FEATURES if the master supports it. So added by the master - still invisible to the guest? > > 2. VHOST_USER_SET_PROTOCOL_FEATURES does not require negotiation, > instead the master just needs to check that > VHOST_USER_F_PROTOCOL_FEATURES is included in the > VHOST_USER_GET_FEATURES reply. It's an exception. OK I'm now thoroughly confused but I guess that's a good thing. However if we make the changes to QEMU to honour this won't we break with existing vhost-user receivers? We'll also need to track the state of a SET_FEATURES has happened and then gate the sending of things like reply_ack requests? -- Alex Bennée
