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

[Parav Pandit <parav@nvidia.com>]

Michael,

> From: Parav Pandit <parav@nvidia.com>
> Sent: Monday, June 19, 2023 2:07 PM
> We don't need to do it now.
> 
> > Current VF capability is kind of ok I guess ...
> >
> Already proposed one?
> 
> > If you want admin command to query then it would need to map in PF
> memory.
> No need.
> It is similar to rest of the configuration access commands.
> 
> > I understand two concerns with this:
> > - you worry that this forces ordering requirements - it's true and I
> >   don't know of a good fix. So if possible use VF BAR by preference?
> > - you worry about wasting physical memory space
> >   this we can fix by sticking VF# in the kick.
> >
> > As an alternative, if we can make the new command able to communicate
> > offset in PCI BAR or in VF BAR or both then I think that's also an
> > acceptable
> 
> A new command proposed was for VF BAR that member driver can ask to its
> group owner driver (like rest of the config commands).
> 

Are you ok with the admin command to query the notification address of the member device bar?

I presented both the proposals. 
We need to conclude this now without keep flipping between two from version to version.

a. v3 with admin command
pros:
1. self-contained via AQ for rest of the control path operations.
2. Can work with future siov device who may want to support legacy
3. Doesn't bake things in low level pci capabilities which is hard to get rid of
4. Able to add new command or new response if some device wants to support this on PF (very unlikely)

b. and v6 with capability extension.
Cons:
1. Does not have above advantages

Pros:
1. Uses existing PCI capability for the extension


> A future command can tell for the PF BAR if needed and some device wants to
> do such extra implementation.
> 
> > compromize:
> > drivers that have trouble mapping VF BAR after querying PF can just
> > map PF BAR. WDYT?
> 
> PF BAR for notification can be done later when there is some device who really
> have the limitation and wants to do that.
> We don't see that additional need as driver notifications are present on the VF
> already as listed in the alternative.