From: Ethan Zhao <etzhao1900@gmail.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
rafael@kernel.org, lenb@kernel.org, bhelgaas@google.com,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
patches@lists.linux.dev, pjaroszynski@nvidia.com,
vsethi@nvidia.com, helgaas@kernel.org, baolu.lu@linux.intel.com
Subject: Re: [PATCH RFC v2 0/4] Disable ATS via iommu during PCI resets
Date: Thu, 31 Jul 2025 09:10:59 +0800 [thread overview]
Message-ID: <f6fedc6c-9f3a-4ffe-adb1-38b4f1632647@gmail.com> (raw)
In-Reply-To: <20250729125953.GH36037@nvidia.com>
On 7/29/2025 8:59 PM, Jason Gunthorpe wrote:
> On Tue, Jul 29, 2025 at 02:16:43PM +0800, Ethan Zhao wrote:
>>
>>
>> On 7/28/2025 12:20 AM, Jason Gunthorpe wrote:
>>> On Sun, Jul 27, 2025 at 08:48:26PM +0800, Ethan Zhao wrote:
>>>
>>>> At least, we can do some attempt in DPC and Hot-plug driver, and then
>>>> push the hardware specification update to provide pre-reset notification for
>>>> DPC & hotplug. does it make sense ?
>>>
>>> I think DPC is a different case..
>> More complex and practical case.
>
> I'm not sure about that, we do FLRs all the time as a normal part of
> VFIO and VMM operations. DPC is pretty rare, IMHO.
DPC reset could be triggered by simply accessing its control bit, that
is boring, while data corruption hardware issue is really rare. >
>>> If we get a DPC we should also push the iommu into blocking, disable
>>> ATS and abandon any outstanding ATC invalidations as part of
>>> recovering from the DPC. Once everythings is cleaned up we can set the
>> Yup, even pure software resets, there might be ATC invalidation pending
>> (in software queue or HW queue).
>
> The design of this patch series will require the iommu driver to wait
> for the in-flight ATC invalidations during the blocking domain
I see there is pci_wait_for_pending_transaction() before the blocking
domain attachment.> attach. So for the SW initiated resets there should
not be pending ATC
> invalidations when the FLR is triggered.
>
> We have been talking about DPC internally, and I think it will need a
> related, but different flow since DPC can unavoidably trigger ATC
> invalidation timeouts/failures and we must sensibly handle them in the
There is race window for software to handle.
And for DPC containing data corruption as priority, seems not rational
to issue notification to software and then do resetting. alternative
way might be async modal support in iommu ATC invalidation path ?
Thanks,
Ethan > driver.
>
> Jason
next prev parent reply other threads:[~2025-07-31 1:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-28 7:42 Nicolin Chen
2025-06-28 7:42 ` [PATCH RFC v2 1/4] iommu: Lock group->mutex in iommu_deferred_attach Nicolin Chen
2025-07-04 15:22 ` Jason Gunthorpe
2025-06-28 7:42 ` [PATCH RFC v2 2/4] iommu: Pass in gdev to __iommu_device_set_domain Nicolin Chen
2025-07-04 15:23 ` Jason Gunthorpe
2025-06-28 7:42 ` [PATCH RFC v2 3/4] iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset_done() Nicolin Chen
2025-06-28 13:28 ` Baolu Lu
2025-06-30 12:38 ` Jason Gunthorpe
2025-06-30 17:29 ` Nicolin Chen
2025-06-30 22:49 ` Jason Gunthorpe
2025-07-04 15:43 ` Jason Gunthorpe
2025-07-22 21:58 ` Nicolin Chen
2025-07-23 2:21 ` Baolu Lu
2025-07-23 2:53 ` Nicolin Chen
2025-07-27 16:25 ` Jason Gunthorpe
2025-07-28 19:07 ` Nicolin Chen
2025-07-29 13:02 ` Jason Gunthorpe
2025-06-28 7:42 ` [PATCH RFC v2 4/4] pci: Suspend iommu function prior to resetting a device Nicolin Chen
2025-07-24 6:50 ` [PATCH RFC v2 0/4] Disable ATS via iommu during PCI resets Ethan Zhao
2025-07-25 16:41 ` Nicolin Chen
2025-07-27 12:48 ` Ethan Zhao
2025-07-27 16:20 ` Jason Gunthorpe
2025-07-29 6:16 ` Ethan Zhao
2025-07-29 12:59 ` Jason Gunthorpe
2025-07-31 1:10 ` Ethan Zhao [this message]
2025-07-31 13:47 ` 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=f6fedc6c-9f3a-4ffe-adb1-38b4f1632647@gmail.com \
--to=etzhao1900@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.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
all inboxes | Powered by JetHome®