RE: vPASID capability for VF

Tian, Kevin
2023-05-11T07:42:57Z

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, May 11, 2023 4:39 AM
>
> On Wed, May 10, 2023 at 02:16:05AM +0000, Tian, Kevin wrote:
>
> > We don't have a control knob to hide/unhide a specific PCI cap
> > today. It's hardcoded with proper virtualization policy in vfio-pci.
> >
> > Following current convention once vfio-pci adds the support for the
> > PASID cap it will be exposed if present (for VF it's the presence in PF).
>
> We probably shouldn't do this - the PASID cap should only exist if the
> VMM is actualy able to handle PASID throughout, and currently no VMM
> does this.
>
> So we can't just have the kernel unconditionally add the cap. There
> needs to be a negotiation with the VMM
>

emmm. if that is the case probably we want to convey the cap to
userspace in a separate interface. I don't think it's a good idea to
give the user inconsistent vconfig layout before and after the user
negotiates.

Probably a device feature? The VMM calls device feature ioctl to
query whether PASID is supported (together with the pasid bits)
and to enable/disable it.

This also allows the user to opt whether it wants to manage PASIDs
itself or go to a simple scheme to get them from the kernel.

The VMM is responsible for finding an offset in vconfig space, e.g.
adopting your suggestion to find a gap between caps and block hidden
registers on a device if vPASID is favored and add quirks otherwise.