OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]