From: Jason Gunthorpe <jgg@nvidia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
iommu@lists.linux-foundation.org,
Alistair Popple <apopple@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: iommu/smmu/PCI ATS + TTM unmaps + nouveau best way forward
Date: Tue, 30 Jun 2026 08:51:50 -0300 [thread overview]
Message-ID: <20260630115150.GD7481@nvidia.com> (raw)
In-Reply-To: <8702af7f-47b2-4dcd-bed2-9fa64a8fee9b@amd.com>
On Tue, Jun 30, 2026 at 01:24:57PM +0200, Christian König wrote:
> > Today I finally hit up iommu.strict=1 makes things a lot happier,
> > non-strict IOMMU seems to allow a race between dma_unmap_page and
> > free_page where the unmap goes into the IOMMU flush queue, where the
> > actual unmap are delayed until something triggers a flush later, and
> > the ATS translations stay alive past when they should, and after the
> > page has been allocated by some subsequent user.
>
> Try disabling ATS, that was a common source of problems during HW
> bringup for us in the past.
The spark HW cannot run without ATS.
> > 2. split ttm page unmap/free into two stages, and force an iommu
> > flush/ATS sync operation after the unmap before the free. (I don't
> > think iommu has an interface for this).
>
> Yeah that idea already came up on similar issues as well. I
> certainly wouldn't be opposed to that.
Only for debugging, it is completely wrong to rely on this for
functionality.
> You either have to use memory fences which use the same path as the
> DMA operations itself
Yes, in a PCIe system generally something like the GPU TLB
invalidation command will complete and flush the fabric path to quiet
the DMAs. That won't be true on spark though.
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.
However, the GPU must have another way to inject a fabric fence. The
production driver does not rely on ATS fencing to synchronize memory
operations!
> So far the record for grace periods you need after a TLB flush is 6
> seconds on production HW with up to 10 seconds on engineering
> samples (because of HW bugs).
Yeah, if the HW mechanism to fence the fabric don't work spark would
need similar times to guarentee a fabric drain.
Jason
next prev parent reply other threads:[~2026-06-30 11:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 9:39 iommu/smmu/PCI ATS + TTM unmaps + nouveau best way forward Dave Airlie
2026-06-30 11:24 ` Christian König
2026-06-30 11:51 ` Jason Gunthorpe [this message]
2026-06-30 20:45 ` Dave Airlie
2026-06-30 21:00 ` Dave Airlie
2026-07-01 0:17 ` Jason Gunthorpe
2026-07-01 1:22 ` Alistair Popple
2026-06-30 23:59 ` Jason Gunthorpe
2026-06-30 11:39 ` Jason Gunthorpe
2026-06-30 23:21 ` Matthew Brost
2026-07-01 1:30 ` Alistair Popple
2026-07-01 23:34 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260630115150.GD7481@nvidia.com \
--to=jgg@nvidia.com \
--cc=airlied@gmail.com \
--cc=apopple@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=matthew.brost@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox