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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, June 19, 2023 1:58 PM

> > AQ command on the PF is self-contained and extendible without baking things
> in very low level hw centric pci capabilities, which are hard to get rid of it.
> 
> I worry about systems where there's value in having VF driver map memory
> without talking to PF driver.
Such driver will not be able to use AQ legacy commands anyway.
When such driver arrive, someone, somehow will build self contained device.
And hence, adding such pci capability in that future makes sense.

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

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.