OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] Re: [virtio] [PATCH] virtio: clarify feature negotiation


On Tue, Jan 25, 2022 at 03:57:30PM +0100, Cornelia Huck wrote:
> On Mon, Jan 24 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > It's true. However, that's a generic rule and specific devices
> > can differ. and if you look at specific instances, you will
> > see that they typically require that the feature is negotiated.
> > For example:
> >
> > \item If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated,
> >   \field{blk_size} can be read to determine the optimal sector size
> >   for the driver to use.
> >
> > so a driver reading blk_size before FEATURES_OK is actually using
> > an undocumented aspect of the behaviour.
> >
> > compare this to MTU:
> >
> > \item[VIRTIO_NET_F_MTU(3)] Device maximum MTU reporting is supported. If
> >     offered by the device, device advises driver about the value of
> >     its maximum MTU. If negotiated, the driver uses \field{mtu} as
> >     the maximum MTU value.
> >
> > from which it's clear that it can be read even if not
> > negotiated.
> >
> > So from that point of view, we are actually relaxing the requirements,
> > and yes we'll need to carefully go over each instance of
> > "offered".
> > I thought I did, but now I did a quick grep again and I found instances
> > in virtio-iommu.tex and virtio-gpio.tex
> > Both of these are new, so I think we can just fix them to "negotiated".
> 
> Considering this, should we actually add any requirements as to when
> fields are valid? The device may present a value that is always valid if
> it offers the corresponding feature, or that value may change depending
> on what is actually negotiated by the driver. Maybe a statement that the
> actual validity of a field's value before negotiation is device type
> dependant?

Yes, that makes sense.

-- 
MST



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]