Re: [PATCH] content: enhance device requirements for feature bits

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 8 Jun 2018 19:05:30 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Fri, Jun 08, 2018 at 09:36:17AM +0200, Cornelia Huck wrote:
> > On Fri,  8 Jun 2018 14:59:28 +0800
> > Tiwei Bie <tiwei.bie@intel.com> wrote:
> >   
> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/14
> > > ---
> > >  content.tex | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/content.tex b/content.tex
> > > index f996fad..8374d3f 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -125,6 +125,13 @@ which was not offered.  The device SHOULD accept any valid subset
> > >  of features the driver accepts, otherwise it MUST fail to set the
> > >  FEATURES_OK \field{device status} bit when the driver writes it.
> > >  
> > > +If a device has successfully negotiated a set of features
> > > +at least once (by setting the FEATURES_OK \field{device
> > > +status} bit when the driver writes it), then it SHOULD NOT  
> > 
> > Hm, it's the driver that sets FEATURES_OK, not the device. What about
> > "by succeeding to set"?  
> 
> I think the best terminology we have is
> "accept the FEATURES_OK status bit during device initialization"
> that's from the mmio chapter.

Yes, that sounds better.

> 
> > > +fail re-negotiation of the same set of features after a
> > > +device or system reset.  Failure to do so would interfere
> > > +with the resuming from suspend and error recovery.  
> > 
> > s/the resuming/resuming/
> >   
> > > +
> > >  \subsection{Legacy Interface: A Note on Feature
> > >  Bits}\label{sec:Basic Facilities of a Virtio Device / Feature
> > >  Bits / Legacy Interface: A Note on Feature Bits}