On Fri, Aug 02, 2024 at 12:25:28PM -0600, Alex Williamson wrote: > > I envision an extension to vfio device feature or a new vfio uAPI > > for reporting virtual capabilities as augment to the ones filled in > > vconfig space. > > Should ATS and PRI be reported through vfio-pci or should we just turn > them off to be more like PASID? Maybe the issue simply hasn't arisen > yet because we don't have vIOMMU support and with that support QEMU > might need to filter out those capabilities and look elsewhere. > Anyway, iommufd and vfio-pci should not duplicate each other here. ATS and PRI are strictly controlled only by the iommu driver, VFIO must not change them dynamically. Effectively they become set/unset based on what domains are attached through iommufd. PRI is turned on when any fault capable domain is attached, eg the HWPT uses IOMMU_HWPT_FAULT_ID_VALID. I'm not sure I know the full story here how this will work on the qemu side, but I would guess that PRI changes in the virtual config space will result in different nesting domains becoming attached? ATS, at least for SMMUv3, is controlled by a bit in the vSTE from the guest, the virtual PCI config space changes should not be reflected to real HW. There are data integrity/security concerns here. ATS must only be changed as part of a sequence that can flush the cache. Jason
