> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, April 24, 2024 8:12 AM > > On Tue, Apr 23, 2024 at 11:47:50PM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Tuesday, April 23, 2024 8:02 PM > > > > > > It feels simpler if the indicates if PASID and ATS can be supported > > > and userspace builds the capability blocks. > > > > this routes back to Alex's original question about using different > > interfaces (a device feature vs. PCI PASID cap) for VF and PF. > > I'm not sure it is different interfaces.. > > The only reason to pass the PF's PASID cap is to give free space to > the VMM. If we are saying that gaps are free space (excluding a list > of bad devices) then we don't acutally need to do that anymore. > > VMM will always create a synthetic PASID cap and kernel will always > suppress a real one. oh you suggest that there won't even be a 1:1 map for PF! kind of continue with the device_feature method as this series does. and it could include all VMM-emulated capabilities which are not enumerated properly from vfio pci config space. this interface only reports the availability/features of a capability but never includes information about offset. If a device implements DVSEC it will be exposed to the VMM. Then suppose the VMM will introduce a new cmd parameter to turn on the emulation of the PASID capability. It's default off so legacy usages can still work. Once the parameter is on then the VMM will emulate the PASID capability by: - Locating a free range according to DVSEC, or, - Locating a free range from gaps between PCI caps, If a device is found not working properly then add a fixed offset for this device. > > An iommufd query will indicate if the vIOMMU can support vPASID on > that device. > > Same for all the troublesome non-physical caps. > > > > There are migration considerations too - the blocks need to be > > > migrated over and end up in the same place as well.. > > > > Can you elaborate what is the problem with the kernel emulating > > the PASID cap in this consideration? > > If the kernel changes the algorithm, say it wants to do PASID, PRI, > something_new then it might change the layout > > We can't just have the kernel decide without also providing a way for > userspace to say what the right layout actually is. :\ > emm that's a good point.
