From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>,
<will@kernel.org>, <robin.murphy@arm.com>, <joro@8bytes.org>,
<bhelgaas@google.com>, <praan@google.com>, <kevin.tian@intel.com>,
<kees@kernel.org>, <smostafa@google.com>,
<baolu.lu@linux.intel.com>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<skaestle@nvidia.com>, <mmarrid@nvidia.com>,
<skolothumtho@nvidia.com>, <bbiber@nvidia.com>,
<harsha.v@oss.qualcomm.com>
Subject: Re: [PATCH v3 03/13] iommu/arm-smmu-v3: Drain in-flight fault events on domain detach
Date: Fri, 4 Sep 2026 15:57:14 -0700 [thread overview]
Message-ID: <aptMynoQtAf1Jcr5@nvidia.com> (raw)
In-Reply-To: <20260904140906.GR4157646@nvidia.com>
On Fri, Sep 04, 2026 at 11:09:06AM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron wrote:
> > > Also run the drain for every stall-capable master, even when the departing
> > > attachment did not enable IOPF: such a stall event has to be aborted while
> > > it still resolves to the old attach handle,
>
> That isn't the model for fault handling. The fault is delivered
> unpredictably into either old or new domain. It doesn't matter which
> one.
>
> Domains have to conclude their fault proceessing before they are
> destroyed, and attach to the a non-fault domain has to conclude faults
> before completing the attach.
>
> But there is no requirement to deliver faults to any particular thing.
Edited:
Also run the drain for every stall-capable master, even when the departing
attachment did not enable IOPF. An attachment has to conclude its in-flight
faults before the attach completes, as the incoming domain might not handle
a fault at all.
> > > could pick it up right after the handle swap, mistakenly resuming it as if
> > > it were a valid page fault against a new domain.
> >
> > Useful perhaps to call out if this has been seen in real systems or
> > not. I agree with the analysis but would rather hope drivers are
> > well behaved in ensuring all traffic is done, adn this is hardeninging
> > / handling of naught hardware activity (all good if so!)
>
> There is a firm API contract on the iommu drivers, they cannot
> propogate faults at unexpected times because the consumers cannot deal
> with it.
>
> We don't reason about well behaved drivers at this level because vfio
> cannot be trusted to be well behaved. So any nonsense vfio can trigger
> has to be handled without crashing the kernel.
Added:
This is an API contract, not hardening against odd hardware: a detach may
arrive at any moment from a userspace driver behind VFIO, which cannot be
trusted to quiesce its device first.
Thanks
Nicolin
next prev parent reply other threads:[~2026-09-04 22:57 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 0:33 [PATCH v3 00/13] iommu/arm-smmu-v3: Add PRI support Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 01/13] iommu/arm-smmu-v3: Add arm_smmu_attach_release() Nicolin Chen
2026-09-01 0:46 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 20:16 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 02/13] iommu/arm-smmu-v3: Add Q_POS() macro Nicolin Chen
2026-09-01 0:38 ` sashiko-bot
2026-09-01 0:33 ` [PATCH v3 03/13] iommu/arm-smmu-v3: Drain in-flight fault events on domain detach Nicolin Chen
2026-09-01 0:48 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 14:09 ` Jason Gunthorpe
2026-09-04 22:57 ` Nicolin Chen [this message]
2026-09-08 16:36 ` Jason Gunthorpe
2026-09-08 21:01 ` Nicolin Chen
2026-09-04 21:42 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 04/13] iommu/arm-smmu-v3: Flush in-flight fault work " Nicolin Chen
2026-09-01 0:55 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 0:54 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 05/13] iommu/arm-smmu-v3: Allocate IOPF queue without FEAT_SVA Nicolin Chen
2026-09-01 0:46 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 06/13] iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event Nicolin Chen
2026-09-01 0:53 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 1:15 ` Nicolin Chen
2026-09-09 17:54 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 07/13] iommu/arm-smmu-v3: Disable the queue IRQs before disabling the SMMU Nicolin Chen
2026-09-01 0:55 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 3:24 ` Nicolin Chen
2026-09-09 17:58 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 08/13] iommu/arm-smmu-v3: Disable PRI when no IRQ handler is registered Nicolin Chen
2026-09-01 0:47 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-04 14:15 ` Jason Gunthorpe
2026-09-09 17:59 ` Jonathan Cameron
2026-09-09 19:05 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 09/13] iommu/arm-smmu-v3: Support PRI Page Request in arm_smmu_handle_ppr() Nicolin Chen
2026-09-01 0:50 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 5:08 ` Nicolin Chen
2026-09-09 18:01 ` Jonathan Cameron
2026-09-09 19:09 ` Nicolin Chen
2026-09-01 0:33 ` [PATCH v3 10/13] iommu/arm-smmu-v3: Allocate IOPF queue for ARM_SMMU_FEAT_PRI Nicolin Chen
2026-09-01 0:43 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 11/13] PCI/ATS: Add PRI stubs Nicolin Chen
2026-09-01 0:42 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 12/13] PCI/ATS: Export pci_enable_pri() and pci_reset_pri() Nicolin Chen
2026-09-01 0:44 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-01 0:33 ` [PATCH v3 13/13] iommu/arm-smmu-v3: Enable PRI for PCI device in arm_smmu_probe_device() Nicolin Chen
2026-09-01 0:51 ` sashiko-bot
2026-09-03 19:18 ` Jonathan Cameron
2026-09-05 5:53 ` Nicolin Chen
2026-09-03 19:18 ` [PATCH v3 00/13] iommu/arm-smmu-v3: Add PRI support Jonathan Cameron
2026-09-04 14:10 ` 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=aptMynoQtAf1Jcr5@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=bbiber@nvidia.com \
--cc=bhelgaas@google.com \
--cc=harsha.v@oss.qualcomm.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@oss.qualcomm.com \
--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=linux-pci@vger.kernel.org \
--cc=mmarrid@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=skaestle@nvidia.com \
--cc=skolothumtho@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.