From: Jason Gunthorpe <jgg@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
Kevin Tian <kevin.tian@intel.com>,
Nicolin Chen <nicolinc@nvidia.com>,
robin.murphy@arm.com, joro@8bytes.org, praan@google.com,
mmarrid@nvidia.com, kees@kernel.org,
Alexander.Grest@microsoft.com, smostafa@google.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, bbiber@nvidia.com,
skaestle@nvidia.com
Subject: Re: [PATCH rc] iommu/arm-smmu-v3: Drain in-flight fault handlers
Date: Tue, 24 Mar 2026 11:17:16 -0300 [thread overview]
Message-ID: <20260324141716.GB7340@nvidia.com> (raw)
In-Reply-To: <acKZ0wtfi5R_dHm0@willie-the-truck>
On Tue, Mar 24, 2026 at 02:04:03PM +0000, Will Deacon wrote:
> Sorry, that was sloppy terminology on my part. I'm trying to reason about
> faults that are generated by accesses that were translated with the
> page-tables of the old domain being reported once we think we are using
> the new domain.
It doesn't matter.
If a concurrent fault is resolving on the old domain and it completes
after the STE is in the new domain the device will restart and if the
IOVA is still non-present it will refault. This is normal and fine.
If it is resolving on the new domain and the new domain has a present
PTE so the PRI is spurious then the fault handler should NOP it and
restart the device.
> > The ordering is supposed to be
> > 1) IOMMU HW starts using the new domain
> > 2) iommu_attach_handle_get() returns the new domain
> > 3) IOMMU driver flushes its own IRQs/queues that may be concurrently
> > calling iommu_attach_handle_get()
>
> Does that mean we should kick the evtq thread? I'm not sure what this
> means for the priq.
The locking issue is around iommu_attach_handle_get(), so any
thread/irq concurrently calling that has to be fenced. That's it. We
don't have to expedite or synchronize with concurrent PRI at all.
> I don't think we can rely on the IRQ being taken, though, so presumably
> we have to kick the irq thread manually and see what's actually sitting
> in the event queue after the CMD_SYNC?
Er, I thought the iommu_attach_handle_get() was in a threaded irq? If
it is in a WQ then yeah more is needed.
Jason
next prev parent reply other threads:[~2026-03-24 14:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 0:17 [PATCH rc] iommu/arm-smmu-v3: Drain in-flight fault handlers Nicolin Chen
2026-03-12 13:51 ` Will Deacon
2026-03-12 14:25 ` Jason Gunthorpe
2026-03-24 14:04 ` Will Deacon
2026-03-24 14:17 ` Jason Gunthorpe [this message]
2026-03-24 14:35 ` Will Deacon
2026-03-24 18:53 ` 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=20260324141716.GB7340@nvidia.com \
--to=jgg@nvidia.com \
--cc=Alexander.Grest@microsoft.com \
--cc=baolu.lu@linux.intel.com \
--cc=bbiber@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kees@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarrid@nvidia.com \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=skaestle@nvidia.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.