Re: [PATCH rc v2] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking

[Pranjal Shrivastava <praan@google.com>]

On Sat, May 09, 2026 at 02:14:51PM -0300, Jason Gunthorpe wrote:
> On Wed, May 06, 2026 at 10:04:38PM +0000, Pranjal Shrivastava wrote:
> 
> > [1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/pci/quirks.c#L5703
> 
> The quirk is broken. It clearly says the device has mis-implemented
> the ATS invalidation message so ATS must *NEVER* be enabled.
> 

I agree that the ATS must never be enable on this device. 

> Thus the quirk should cover the VFs too and also disable ATS there.

I observe the quirk does apply VFs but after the VF's iommu attach
because of how the pci_iov_add_virtfn() is written:

int pci_iov_add_virtfn(...)
{

	...
	pci_device_add(virtfn, virtfn->bus); // <------ This is where the iommu attach happens within device_add()
	rc = pci_iov_sysfs_link(dev, virtfn, id);
	if (rc)
		goto failed1;

	pci_bus_add_device(virtfn); // <---- This is where the quirk gets applied

}

i.e. in pci_device_add it calls pci_fixup_device(pci_fixup_header, dev)
whereas this ATS quirk is of `pci_fixup_final` type & gets applied within
pci_bus_add_device(). 

While, we can move this quirk to be in fixup_early / fixup_header.
I still think we should add checking the PF->ats_cap within 
pci_ats_supported before bailing out happily (return 0) for VFs.

> So I still think my original suggestion is appropriate, fail to probe
> the iommu device if ats prepare fails (serious PCI layer bug, like
> broken quirks) and fail to attach the domain of ats enable fails
> (serious internal kernel malfunction since enable must succeed if
> prepare succeeded)

I’m concerned that refusing to attach a device because it isn't ATS 
capable is bit too aggressive.

Even if pci_enable_ats() fails, the device is still perfectly capable of
performing standard DMA. We should allow the IOMMU attach to succeed but
in a 'Degraded' mode—where ATS is disabled for all it's functions, i.e. 
configured to treat it as a standard non-ATS device.

Thanks,
Praan