[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]