On Thu, Apr 07, 2022 at 04:28:03PM +0200, Cornelia Huck wrote: > [sorry about resurrecting an undead thread; I'm trying to collect some > editorial changes] > > On Wed, Jan 26 2022, Jean-Philippe Brucker <jean-phili...@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.
Negotiated is same as accepted, I think it's good as is -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org