RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, April 16, 2023 4:44 PM
> 
> On Sun, Apr 16, 2023 at 01:41:55PM +0000, Parav Pandit wrote:
> > > From: virtio-comment@lists.oasis-open.org
> > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
> > > Tsirkin
> > > Sent: Friday, April 14, 2023 2:57 AM
> >
> > > Do you refer to the trick Jason proposed where BAR0 is memory but
> > > otherwise matches legacy BAR0 exactly? Is this your preferred solution at
> this point then?
> >
> > We look at it again.
> > Above solution can work reliably only for a very small number of PF and that
> too with very special hardware circuitry due to the reset flow.
> >
> > Therefore, for virtualization below interface is preferred.
> > a. For transitional device legacy configuration register transport
> > over AQ,
> 
> I don't get what this has to do with transitional ...
> 
Typically, in current wordings, transitional is the device that supports legacy interface.
So, it doesn't have to be for the transitional.

I just wanted to highlight that a PCI VF device with its parent PCI PF device can transport the legacy interface commands.

> > Notification to utilize transitional device notification area of the BAR.
> 
> The vq transport does something like this, no?
> 
Notifications over a queuing interface unlikely can be a performant interface because one is configuration task and other is data path task.

> > b. Non legacy interface of transitional and non-transitional PCI device to
> access direct PCI device without mediation.
> 
> So VF can either be accessed through AQ of PF, or through direct mapping?
Right. VF to access legacy registers using AQ of PF and continue non-legacy registers using direct mapping as done today.