[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
From: |
Michael S. Tsirkin |
Date: |
Thu, 5 Oct 2023 13:15:40 -0400 |
On Thu, Oct 05, 2023 at 01:08:52PM -0400, Stefan Hajnoczi wrote:
> On Wed, Oct 04, 2023 at 02:58:57PM +0200, Hanna Czenczek wrote:
> > There is no clearly defined purpose for the virtio status byte in
> > vhost-user: For resetting, we already have RESET_DEVICE; and for virtio
> > feature negotiation, we have [GS]ET_FEATURES. With the REPLY_ACK
> > protocol extension, it is possible for SET_FEATURES to return errors
> > (SET_PROTOCOL_FEATURES may be called before SET_FEATURES).
> >
> > As for implementations, SET_STATUS is not widely implemented. dpdk does
> > implement it, but only uses it to signal feature negotiation failure.
> > While it does log reset requests (SET_STATUS 0) as such, it effectively
> > ignores them, in contrast to RESET_OWNER (which is deprecated, and today
> > means the same thing as RESET_DEVICE).
> >
> > While qemu superficially has support for [GS]ET_STATUS, it does not
> > forward the guest-set status byte, but instead just makes it up
> > internally, and actually completely ignores what the back-end returns,
> > only using it as the template for a subsequent SET_STATUS to add single
> > bits to it. Notably, after setting FEATURES_OK, it never reads it back
> > to see whether the flag is still set, which is the only way in which
> > dpdk uses the status byte.
> >
> > As-is, no front-end or back-end can rely on the other side handling this
> > field in a useful manner, and it also provides no practical use over
> > other mechanisms the vhost-user protocol has, which are more clearly
> > defined. Deprecate it.
> >
> > Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> > ---
> > docs/interop/vhost-user.rst | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
SET_STATUS is the only way to signal failure to acknowledge FEATURES_OK.
The fact current backends never check errors does not mean they never
will. So no, not applying this.
--
MST
- [PATCH v4 0/8] vhost-user: Back-end state migration, Hanna Czenczek, 2023/10/04
- [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS, Hanna Czenczek, 2023/10/04
- Re: [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS, Stefan Hajnoczi, 2023/10/05
- [no subject],
Michael S. Tsirkin <=
- Re: [Virtio-fs] (no subject), Hanna Czenczek, 2023/10/06
- Re: [Virtio-fs] (no subject), Michael S. Tsirkin, 2023/10/06
- Re: [Virtio-fs] (no subject), Hanna Czenczek, 2023/10/06
- Re: [Virtio-fs] (no subject), Michael S. Tsirkin, 2023/10/06
- Re: [Virtio-fs] (no subject), Hanna Czenczek, 2023/10/06
- Re: [Virtio-fs] (no subject), Michael S. Tsirkin, 2023/10/06
- Re: [Virtio-fs] (no subject), Hanna Czenczek, 2023/10/06
- Re: [Virtio-fs] (no subject), Alex Bennée, 2023/10/06
- Re: [Virtio-fs] (no subject), Hanna Czenczek, 2023/10/06
- Re: [Virtio-fs] (no subject), Alex Bennée, 2023/10/06