[PATCH] virtio: clarify feature negotiation

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

On Wed, Jan 26 2022, Jean-Philippe Brucker <> 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.