Re: [PATCH rc v4 3/4] iommu/arm-smmu-v3: Mark STE EATS safe when computing the update sequence

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Jan 02, 2026 at 06:22:45PM +0000, Mostafa Saleh wrote:

> Looking at the code in arm-smmu-v3-iommufd and iommufd/device.c, it
> seems ATS enable will only change at attach.
> Looking into arm_smmu_attach_commit(), I see the ATC is invalidated
> after the STE is installed, which means that userspace can transiently
> observe the old domain ATC. I think that's fine at the moment because
> when binding to a VFIO driver, it will attach to an empty domain.

Yeah, it is a bit confusing..

The PCI ATS flag in the config space must exclusively be controlled by
the IOMMU driver. We must not allow the PCI device to turn on ATS
while the IOMMU driver is not synchronized and able to issue flushes,
otherwise we can have cache inconsistencies.

This goes both ways, we can't allow the hypervisor to turn on ATS
unless the VM is aware and is issuing flushes for its S1, and we can't
have the VM turn on ATS unless the hypervisor is aware and issuing
flushes for its S2.

Thus, for a VM the vPCI config space for ATS is ignored by HW, and the
VM controls ATS ONLY through the vSTE EATS bit.

Only once the VM enables EATS do we get to turn on the PCI config
space ATS.

All the detail I explains before holds because all the ATS switching
logic in the drvier is designed to ensure no invalidations are lost,
regardless of what two domains are being switched between. At worst
you get a transient moment during switching when the ATC hold a page
that is either new/old domain - but that is resolved before the domain
switch completes.

AMD folks, this whole explanation in this thread applies to the AMD
driver too, it currently has wrong ATS for virtualization, and fixing
it means make it work like ARM.. It will need to be fixed to complete
the VIOMMU work.

Jason