> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > 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.
