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

[Cornelia Huck <cohuck@redhat.com>]

[sorry about resurrecting an undead thread; I'm trying to collect some
editorial changes]

On Wed, Jan 26 2022, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:

> On Mon, Jan 24, 2022 at 04:42:35PM -0500, Michael S. Tsirkin wrote:
>> 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".
>> 
>> Jean-Philippe, Viresh, what do you think? Would it be a problem to
>> replace offered with negotiated, and restrict iommu and gpio drivers to
>> access config space after FEATURES_OK?
>
> No problem for iommu. The config space fields domain_range and input_range
> are not useful to the driver before DRIVER_OK. Reading field bypass
> earlier could be useful for debugging, but in that case going a few more
> steps into device initialization wouldn't hurt.

For domain_range and input_range, offered->negotiated looks like the
right thing to do. However, I'm a bit unsure about bypass. We currently
have:

"
An endpoint is in bypass mode if:
\begin{itemize}
  \item the VIRTIO_IOMMU_F_BYPASS_CONFIG feature is offered and:
    \begin{itemize}
      \item config field \field{bypass} is 1 and the endpoint is
        not attached to a domain. This applies even if the driver
        does not accept the VIRTIO_IOMMU_F_BYPASS_CONFIG feature
        and the device initializes field \field{bypass} to 1.

        or
      \item the endpoint is attached to a domain with
        VIRTIO_IOMMU_ATTACH_F_BYPASS.
    \end{itemize}
"

The "This applies even if..." clause refers to "offered, but not
accepted". I assume we want to do offered->negotiated even here, but
wanted to double-check.