Re: iommu/smmu/PCI ATS + TTM unmaps + nouveau best way forward

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jul 01, 2026 at 06:45:11AM +1000, Dave Airlie wrote:
> > Dave could be facing a fabric issue. AFAIK the ATS invalidation that
> > the iommu=strict pushses should fence the fabric so would resolve a
> > missing fabric fence. I suppose if you don't see any evidence of a
> > non-present ATS response explosion with strict then this would be a
> > really good theory.
> 
> It's definitely a fabric issue, the iommu ATS invalidation is what
> "fixes" it, but I'm not figuring out how to flush it from the GPU
> side, and I'm not seeing where the official driver does this either,
> guess I have to keep digging. Maybe Alistair knows something.

Well, as I said the ATS does two things, it fences the fabric and it
will fail DMAs with ATS non-present (which doesn't trigger an iommu
log). If you are confident there are no ATS non-present events inside
the GPU then fabric is the best guess, but most likely the fabric will
clear in microseconds after the last GPU DMA so it would be a pretty
narrow race.

> From the ubuntu kernel this thing ships with:
> https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.14/+bug/2132033
> 
> "Add two more Spark iGPU IDs for the existing iommu quirk "
> 
> diff -u linux-nvidia-6.14-6.14.0/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> linux-nvidia-6.14-6.14.0/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> --- linux-nvidia-6.14-6.14.0/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ linux-nvidia-6.14-6.14.0/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3654,7 +3654,9 @@
>   if (IS_HISI_PTT_DEVICE(pdev))
>   return IOMMU_DOMAIN_IDENTITY;
> 
> - if (pdev->vendor == PCI_VENDOR_ID_NVIDIA && pdev->device == 0x2E12)
> + if (pdev->vendor == PCI_VENDOR_ID_NVIDIA &&
> +    (pdev->device == 0x2E12 || pdev->device == 0x2E2A ||
> +     pdev->device == 0x2E2B))
>   return IOMMU_DOMAIN_DMA;
>   }
> 
> 
> I should probably work out if anything upstream does this or if I can
> mess up the production driver against an upstream kernel.

Latest upstream has this fixed now in a different way, this is about
forcing ATS mode on inside the SMMU driver because spark can't work if
ATS is disabled.

Jason