qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] vhost-user.rst: add clarifying language about protocol ne


From: Alex Bennée
Subject: Re: [PATCH v2] vhost-user.rst: add clarifying language about protocol negotiation
Date: Thu, 04 Mar 2021 18:11:26 +0000
User-agent: mu4e 1.5.8; emacs 28.0.50

Stefan Hajnoczi <stefanha@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]