Re: [PATCH v2 0/4] vfio-pci support pasid attach/detach

[Jason Gunthorpe <jgg@nvidia.com>]

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