On Mon, Jan 24 2022, "Michael S. Tsirkin" <m...@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? --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org