On Mon, Jun 19, 2023 at 05:11:19PM +0000, Parav Pandit wrote:
>
>
> > From: [email protected] <[email protected]> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
