[virtio-comment] Re: [virtio-dev] Re: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jun 19, 2023 at 05:11:19PM +0000, Parav Pandit wrote:
> 
> 
> > From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> > Behalf Of Michael S. Tsirkin
> > Sent: Monday, June 19, 2023 1:04 PM
> 
> > On Tue, Jun 13, 2023 at 08:30:15PM +0300, Parav Pandit wrote:
> > > +Even though virtqueue driver notifications can be communicated
> > > +through administration virtqueue, if the group member device support
> > > +such notifications using a memory-mapped operation, such driver
> > > +notifications are sent using a group member device defined notification
> > region.
> > 
> > I still feel we should support sending notifications to owner at least optionally.
> > For example:
> >
> Let's not please keep discussing this yet again.
> I won't be able to.
> We have captured this alternative already in the cover letter in the alternatives section.
> 
> This optional capability can be added when there is a _real_ implementation by some hw.
>  
> > 
> > \begin{lstlisting}
> > struct virtio_pci_owner_legacy_notify_cap {
> >         struct virtio_pci_cap cap;
> >         le32 notify_off_multiplier; /* Multiplier for member id. */ }; \end{lstlisting}
> > 
> > \field{notify_off_multiplier} is combined with the \field{member id} to derive
> > an address within a BAR.
> > 
> > \begin{lstlisting}
> >         cap.offset + member_id * notify_off_multiplier \end{lstlisting}
> > 
> > 
> > 
> > We also need, as part of theory of operation, text that reads something like
> > "accessing the member device legacy interface using one of XYZ commands has
> > the same effect as accessing it using the legacy interface".
> > 
> Ack. I will add this.
> 
> > 
> > 
> > Also, do all VFs support legacy interface with these commands or none at all?
> >
> Right.
>  
> > 
> > Also these devices will use non-transitional ID but they in fact do have a legacy
> > interface so using this definition they are transitional devices. Maybe we need
> > to add when we describe the device ID text like "non transitional devices and
> > transitional devices utilizing commands XYZ" ...?
> 
> Transitional device has specific meaning, I am not sure we should muddy it.



To simplify transition from these earlier draft interfaces,
a device MAY implement:

\begin{description}
\item[Transitional Device]
        a device supporting both drivers conforming to this
        specification, and allowing legacy drivers.
\end{description}


I agree it can be read this way. The issue is a lot of text
in the spec just assumes that "has legacy interface == transitional
device".



For example:
When using the legacy interface the driver MAY access 
the device-specific configuration region using any width accesses, and
a transitional device MUST present driver with the same results as
when accessed using the ``natural'' access method (i.e.
32-bit accesses for 32-bit fields, etc).


If we break the assumption we need to audit the spec for this
assumption and again, I really would rather not.




-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/