mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>, <joro@8bytes.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>, <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Joerg Roedel <joerg.roedel@amd.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"Dan Williams" <djbw@kernel.org>, <iommu@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<linux-pci@vger.kernel.org>
Subject: [PATCH v1 0/5] iommu: Keep a device blocked after a failed PCI reset
Date: Tue, 3 Nov 2026 10:33:41 -0800	[thread overview]
Message-ID: <cover.1793729707.git.nicolinc@nvidia.com> (raw)

This series is split from a bigger SMMUv3 series, so that the PCI and the
IOMMU core changes can be reviewed and merged on their own:
https://lore.kernel.org/all/cover.1790188510.git.nicolinc@nvidia.com/
The SMMUv3 ATC invalidation timeout handling in that series will depend on
this series.

pci_dev_reset_iommu_prepare() blocks the IOMMU translation and ATS of a PCI
device before a reset. pci_dev_reset_iommu_done() restores them after the
reset. However, done() is called unconditionally, even when the reset has
failed. A failed reset gives no guarantee that the device cache is clean.
For an ATS-capable device, its ATC might still have stale entries pointing
to the memory pages that the OS has reclaimed. Re-attaching such a device
to its translation domains could corrupt the system memory.

Thus, pass in the reset result to pci_dev_reset_iommu_done(). On a failure,
keep the device blocked until a subsequent reset succeeds. This new policy
applies to every ATS-capable PCI device behind an IOMMU, so no IOMMU driver
needs to opt in.

First, fix two PCI reset issues found along the way. A probe of the reset
capability must not block the IOMMU, as it is only a state query. And the
cxl_reset_bus_function() must not report a "cxl_bus" method that can never
succeed.

Then, convert gdev->blocked from a bool into an enum in the IOMMU core, so
that a failed reset can be told apart from an ongoing reset. Also, pass the
blocked state of a device being removed into iommu_deinit_device(), which
lets the release_domain get the correct old domain.

Note that the PCI reset functions do overload -ENOTTY. It might mean either
"the reset was not attempted" or "this method failed, so try the next one".
The IOMMU core cannot tell these two apart. So, it keeps the device blocked
on -ENOTTY as well, with a FIXME and a warning.

This is on Github:
https://github.com/nicolinc/iommufd/commits/iommu_reset_failure-v1

Changelog
v1:
 * Drop the Assisted-by tags
 * Split from the SMMUv3 series above
 * Carry over the Reviewed-by tags from Baolu and Jason

Nicolin Chen (5):
  PCI: Don't suspend IOMMU when probing reset capability
  PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function()
  iommu: Convert gdev->blocked from bool to enum blocked_reason
  iommu: Pass in gdev's blocked state to iommu_deinit_device()
  iommu: Pass in reset result to pci_dev_reset_iommu_done()

 include/linux/iommu.h  |  5 ++-
 drivers/iommu/iommu.c  | 87 ++++++++++++++++++++++++++++++++++++------
 drivers/pci/pci-acpi.c |  2 +-
 drivers/pci/pci.c      | 37 +++++++++++-------
 drivers/pci/quirks.c   | 13 ++++---
 5 files changed, 111 insertions(+), 33 deletions(-)


base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.43.0


             reply	other threads:[~2026-11-03 18:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 18:33 Nicolin Chen [this message]
2026-11-03 18:33 ` [PATCH v1 1/5] PCI: Don't suspend IOMMU when probing reset capability Nicolin Chen
2026-11-03 18:33 ` [PATCH v1 2/5] PCI/CXL: Probe the underlying bus reset in cxl_reset_bus_function() Nicolin Chen
2026-11-03 18:44   ` Nicolin Chen
2026-11-03 21:02     ` Jonathan Cameron
2026-11-03 18:33 ` [PATCH v1 3/5] iommu: Convert gdev->blocked from bool to enum blocked_reason Nicolin Chen
2026-11-03 18:33 ` [PATCH v1 4/5] iommu: Pass in gdev's blocked state to iommu_deinit_device() Nicolin Chen
2026-11-03 18:33 ` [PATCH v1 5/5] iommu: Pass in reset result to pci_dev_reset_iommu_done() Nicolin Chen
2026-11-03 19:59   ` Nicolin Chen

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=cover.1793729707.git.nicolinc@nvidia.com \
    --to=nicolinc@nvidia.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=djbw@kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®