From: Bjorn Helgaas <helgaas@kernel.org>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: joro@8bytes.org, rafael@kernel.org, bhelgaas@google.com,
alex@shazbot.org, jgg@nvidia.com, kevin.tian@intel.com,
will@kernel.org, robin.murphy@arm.com, lenb@kernel.org,
baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
kvm@vger.kernel.org, patches@lists.linux.dev,
pjaroszynski@nvidia.com, vsethi@nvidia.com, etzhao1900@gmail.com
Subject: Re: [PATCH v5 5/5] pci: Suspend iommu function prior to resetting a device
Date: Mon, 17 Nov 2025 16:58:52 -0600 [thread overview]
Message-ID: <20251117225659.GA2536275@bhelgaas> (raw)
In-Reply-To: <a166b07a254d3becfcb0f86e4911af556acbe2a9.1762835355.git.nicolinc@nvidia.com>
On Mon, Nov 10, 2025 at 09:12:55PM -0800, Nicolin Chen wrote:
Run "git log --oneline drivers/pci/pci.c" and match the subject line
style.
> 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.
s/TLPs, while/TLPs while/
> 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.
Include spec revision, e.g., "PCIe r7.0, sec 10.3.1".
> Now iommu_dev_reset_prepare/done() helpers are introduced for this matter.
s/Now ... are introduced for this matter/Add ...helpers/
> Use them in all the existing reset functions, which will attach the device
> to an IOMMU_DOMAIN_BLOCKED during a reset, so as to allow IOMMU driver to:
> - invoke pci_disable_ats() and pci_enable_ats(), if necessary
> - wait for all ATS invalidations to complete
> - stop issuing new ATS invalidations
> - fence any incoming ATS queries
Thanks for addressing this problem.
> +++ b/drivers/pci/pci-acpi.c
> @@ -971,6 +971,7 @@ void pci_set_acpi_fwnode(struct pci_dev *dev)
> int pci_dev_acpi_reset(struct pci_dev *dev, bool probe)
> {
> acpi_handle handle = ACPI_HANDLE(&dev->dev);
> + int ret = 0;
Unnecessary initialization.
> +int pci_reset_iommu_prepare(struct pci_dev *dev)
> +{
> + if (pci_ats_supported(dev))
> + return iommu_dev_reset_prepare(&dev->dev);
Why bother checking pci_ats_supported() here? That could be done
inside iommu_dev_reset_prepare(), since iommu.c already uses
dev_is_pci() and pci_ats_supported() is already exported outside
drivers/pci/.
> +void pci_reset_iommu_done(struct pci_dev *dev)
> +{
> + if (pci_ats_supported(dev))
> + iommu_dev_reset_done(&dev->dev);
And here.
> int pcie_flr(struct pci_dev *dev)
> {
> + int ret = 0;
Unnecessary initialization.
> static int pci_af_flr(struct pci_dev *dev, bool probe)
> {
> + int ret = 0;
Unnecessary initialization.
next prev parent reply other threads:[~2025-11-17 22:58 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-11 5:12 [PATCH v5 0/5] Disable ATS via iommu during PCI resets Nicolin Chen
2025-11-11 5:12 ` [PATCH v5 1/5] iommu: Lock group->mutex in iommu_deferred_attach() Nicolin Chen
2025-11-12 2:47 ` Baolu Lu
2025-11-11 5:12 ` [PATCH v5 2/5] iommu: Tiny domain for iommu_setup_dma_ops() Nicolin Chen
2025-11-12 5:22 ` Baolu Lu
2025-11-14 9:17 ` Tian, Kevin
2025-11-14 9:18 ` Tian, Kevin
2025-11-11 5:12 ` [PATCH v5 3/5] iommu: Add iommu_driver_get_domain_for_dev() helper Nicolin Chen
2025-11-12 5:58 ` Baolu Lu
2025-11-12 17:41 ` Nicolin Chen
2025-11-18 7:02 ` Nicolin Chen
2025-11-19 2:47 ` Baolu Lu
2025-11-19 2:57 ` Nicolin Chen
2025-11-12 8:52 ` kernel test robot
2025-11-14 9:18 ` Tian, Kevin
2025-11-11 5:12 ` [PATCH v5 4/5] iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset_done() Nicolin Chen
2025-11-12 6:18 ` Baolu Lu
2025-11-12 17:43 ` Nicolin Chen
2025-11-14 9:37 ` Tian, Kevin
2025-11-14 18:26 ` Nicolin Chen
2025-11-17 4:59 ` Tian, Kevin
2025-11-17 19:27 ` Nicolin Chen
2025-11-17 23:04 ` Bjorn Helgaas
2025-11-11 5:12 ` [PATCH v5 5/5] pci: Suspend iommu function prior to resetting a device Nicolin Chen
2025-11-14 9:45 ` Tian, Kevin
2025-11-14 18:00 ` Nicolin Chen
2025-11-17 4:52 ` Tian, Kevin
2025-11-17 19:26 ` Nicolin Chen
2025-11-18 0:29 ` Tian, Kevin
2025-11-18 1:42 ` Nicolin Chen
2025-11-18 5:38 ` Baolu Lu
2025-11-18 6:53 ` Nicolin Chen
2025-11-18 7:53 ` Tian, Kevin
2025-11-18 8:17 ` Nicolin Chen
2025-11-17 22:58 ` Bjorn Helgaas [this message]
2025-11-18 8:16 ` 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=20251117225659.GA2536275@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex@shazbot.org \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=etzhao1900@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=pjaroszynski@nvidia.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=vsethi@nvidia.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;
as well as URLs for NNTP newsgroup(s).