> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, April 30, 2024 1:45 AM > > On Fri, Apr 26, 2024 at 02:13:54PM -0600, Alex Williamson wrote: > > Regarding "if we accept that text file configuration should be > > something the VMM supports", I'm not on board with this yet, so > > applying it to PASID discussion seems premature. > > Sure, I'm just explaining a way this could all fit together. > Thinking more along this direction. I'm not sure how long it will take to standardize such text files and share them across VMMs. We may need a way to move in steps in Qemu to unblock the kernel development toward that end goal, e.g. first accepting a pasid option plus user-specified offset (if offset unspecified then auto-pick one in cap holes). Later when the text file is ready then such per-cap options can be deprecated. This simple way won't fix the migration issue, but at least it's on par with physical caps (i.e. fail the migration if offset mismatched between dest/src) and both will be fixed when the text file model is ready. Then look at what uAPI is required to report the vPASID cap. In earlier discussion it's leaning toward extending GET_HW_INFO in iommufd given both iommu/pci support are required to get PASID working and iommu driver will not report such support until pasid has been enabled in both iommu/pci. With that there is no need to further report PASID in vfio-pci. But there may be other caps which are shared between VF and PF while having nothing to do with the iommu. e.g. the Device Serial Number extended cap (permitted but not recommended in VF). If there is a need to report such cap on VF which doesn't implement it to userspace, a vfio uAPI (device_feature or a new one dedicated to synthetical vcap) appears to be inevitable. So I wonder whether we leave this part untouched until a real demand comes or use vpasid to formalize that uAPI to be forward looking. If in the end such uAPI will exist then it's a bit weird to have PASID escaped (especially when vfio-pci already reports PRI/ATS which have iommu dependency too in vconfig). In concept the Qemu logic will be clearer if any PCI caps (real or synthesized) is always conveyed via vfio-pci while iommufd is for identifying a viommu cap. Thanks Kevin
