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: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access


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:


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



Also, do all VFs support legacy interface with these
commands or none at all?


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


-- 
MST



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