virtio — archive

[PATCH v9 00/10] Introduce device group and device management

From: Jason Wang <[email protected]>
To: [email protected]
Date: Thu, 24 Nov 2022 07:34:00 -0000

On Thu, Nov 24, 2022 at 2:59 PM Michael S. Tsirkin <[email protected]> wrote: > > On Thu, Nov 24, 2022 at 12:33:52PM +0800, Jason Wang wrote: > > On Thu, Nov 24, 2022 at 5:08 AM Michael S. Tsirkin <[email protected]> wrote: > > > > > > Feature negotiation forms the basis of forward compatibility > > > guarantees of virtio but has never been properly documented. > > > Do it now. > > > > > > Suggested-by: Halil Pasic <[email protected]> > > > Signed-off-by: Michael S. Tsirkin <[email protected]> > > > --- > > > content.tex | 42 ++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > > > > diff --git a/content.tex b/content.tex > > > index 3051399..e3203be 100644 > > > --- a/content.tex > > > +++ b/content.tex > > > @@ -114,21 +114,63 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B > > > In particular, new fields in the device configuration space are > > > indicated by offering a new feature bit. > > > > > > +To keep te feature negotiation mechanism extensible, it is important > > > +that devices \em{do not} offer any feature bits that they would not be > > > +able to handle if the driver accepted them (even though drivers are not > > > +supposed to accept them in the first place even if offered, according to > > > +this version of the specification.) > > > > It looks to me if we want to clarify like this, feature negotiation is > > not sufficient. Do we need to do something similar in other basic > > facilities? Generally, we probably need to do this for facilities that > > are similar to features (status, virtqueue size and others). > > I'm not sure about "not sufficient". It's sufficient as long > as you just want to extend features. What triggered this > work is adding a transport specific feature. E.g: For status: Devices do not offer any status bit it would not be able to handle. For virtqueue size: Devices do not offer virtqueue size it would not be able to handle. ? > > > > > Likewise, it is important that > > > +drivers \em{do not} accept feature bits they do not know how to handle > > > +(even though devices are not supposed to offer them in the first place, > > > +according to this version of the specification.) The preferred way for > > > +handling reserved and unexpected features is that the driver ignores > > > +them. > > > > I'm not sure this is the best way or whether we've defined the > > "unexpected features" before. It might be better to say that to accept > > the features that the driver understands. > > So specifically, if feature is documented as pci only and then > down the road we enable it for ccw. Does driver "understand" it? Or not? > It is clearly unexpected. > I am not too worried about using terms we didn't define this is not > part of a conformance statement. > And people seem to get the meaning ;) Ok. Thanks