Hi Cédric,
On 6/12/2026 12:56 AM, Cédric Le Goater wrote:
Hello Nathan,
On 6/12/26 03:43, Nathan Chen wrote:
Hi,
This series adds an ATS control property to vfio-pci and wires iommufd
support reporting so vfio-pci can decide whether to expose the ATS PCIe
extended capability to the guest. This series is a follow-up to the
previous patch included in the "hw/arm/smmuv3-accel: Resolve AUTO
properties" series [0].
The new vfio-pci property is:
ats=on|off|auto (default: auto)
Behavior:
- off: always masks ATS from guest view
- on: requires ATS support; fails realize if kernel reports
IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED
- auto: masks ATS only when kernel reports
IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED
To preserve machine compatibility for older machine types, this series
adds:
{ "vfio-pci", "ats", "on" } to hw_compat_11_0.
Please note that no linux-headers sync patch is included in this series
because IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED is already present in
linux-headers/linux/iommufd.h in the current base.
Testing:
Verified ATS capability visibility changes with vfio-pci ats=off/on/auto
on an NVIDIA Grace system:
- ats=on + ATS supported by kernel => propagate ATS extended cap to
guest view
- ats=auto + ATS supported by kernel => propagate ATS extended cap to
guest view
- ats=on + hiod_iommufd_support_ats modified to return false (mimic
kernel-reported unsupported ATS) => realize failure
- ats=auto + hiod_iommufd_support_ats modified to return false (mimic
kernel-reported unsupported ATS) => ATS masked
- ats=off => ATS masked
What about ats=on and no ATS support in the physical device ?
I agree it is a bit of a corner case. A warning would be nice,
it can be addressed as a follow up change.
Right, I had missed that case. I will look into accounting for it in the
next refresh.
Thanks,
Nathan
