Message-ID: <cover.1751096303.git.nicolinc@nvidia.com>
Date: Sat, 28 Jun 2025 00:42:38 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: <jgg@...dia.com>, <joro@...tes.org>, <will@...nel.org>,
	<robin.murphy@....com>, <rafael@...nel.org>, <lenb@...nel.org>,
	<bhelgaas@...gle.com>
CC: <iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
	<linux-acpi@...r.kernel.org>, <linux-pci@...r.kernel.org>,
	<patches@...ts.linux.dev>, <pjaroszynski@...dia.com>, <vsethi@...dia.com>,
	<helgaas@...nel.org>, <baolu.lu@...ux.intel.com>
Subject: [PATCH RFC v2 0/4] Disable ATS via iommu during PCI resets

Hi all,

PCIe permits a device to ignore ATS invalidation TLPs, while processing a
reset. This creates a problem visible to the OS where an ATS invalidation
command will time out: e.g. an SVA domain will have no coordination with a
reset event and can racily issue ATS invalidations to a resetting device.

The OS should do something to mitigate this as we do not want production
systems to be reporting critical ATS failures, especially in a hypervisor
environment. Broadly, OS could arrange to ignore the timeouts, block page
table mutations to prevent invalidations, or disable and block ATS.

The PCIe spec in sec 10.3.1 IMPLEMENTATION NOTE recommends to disable and
block ATS before initiating a Function Level Reset. It also mentions that
other reset methods could have the same vulnerability as well.

Provide a callback from the PCI subsystem that will enclose the reset and
have the iommu core temporarily change all the attached domain to BLOCKED.
After attaching a BLOCKED domain, IOMMU drivers should fence any incoming
ATS queries, synchronously stop issuing new ATS invalidations, and wait
for all ATS invalidations to complete. This can avoid any ATS invaliation
timeouts.

When a device is resetting, any new domain attachment should be deferred,
until the reset is finished. The iommu callback will log the

However, if there is a domain attachment/replacement happening during an
ongoing reset, the ATS might be re-enabled between the two function calls.
Introduce a new pending_reset flag in iommu_group to defer any attachment
during a reset, allowing iommu core to cache the target domains in the SW
level but bypassing the driver. The iommu_dev_reset_done() will re-attach
these soft-attached domains via __iommu_attach_device/set_group_pasid().

Notes:
- This only works for IOMMU drivers that implemented ops->blocked_domain
correctly with pci_disable_ats().
- This only works for IOMMU drivers that will not issue ATS invalidation
requests to the device, after it's docked at ops->blocked_domain.
Driver should fix itself to align with the aforementioned notes.

This is on Github:
https://github.com/nicolinc/iommufd/commits/iommu_dev_reset-rfcv2

Changelog
v2
 * [iommu] Update kdocs, inline comments, and commit logs
 * [iommu] Replace long-holding group->mutex with a pending_reset flag
 * [pci] Abort reset routines if iommu_dev_reset_prepare() fails
 * [pci] Apply the same vulnerability fix to other reset functions
v1
 https://lore.kernel.org/all/cover.1749494161.git.nicolinc@nvidia.com/

Thanks
Nicolin

Nicolin Chen (4):
  iommu: Lock group->mutex in iommu_deferred_attach
  iommu: Pass in gdev to __iommu_device_set_domain
  iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset_done()
  pci: Suspend iommu function prior to resetting a device

 include/linux/iommu.h  |  12 +++
 drivers/iommu/iommu.c  | 180 ++++++++++++++++++++++++++++++++++++++---
 drivers/pci/pci-acpi.c |  21 ++++-
 drivers/pci/pci.c      |  84 +++++++++++++++++--
 drivers/pci/quirks.c   |  27 ++++++-
 5 files changed, 307 insertions(+), 17 deletions(-)

-- 
2.43.0

Powered by blists - more mailing lists