From: Ethan Zhao <haifeng.zhao@linux.intel.com>
To: Baolu Lu <baolu.lu@linux.intel.com>,
kevin.tian@intel.com, bhelgaas@google.com, dwmw2@infradead.org,
will@kernel.org, robin.murphy@arm.com, lukas@wunner.de
Cc: linux-pci@vger.kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v10 0/5] fix vt-d hard lockup when hotplug ATS capable device
Date: Thu, 18 Jan 2024 10:32:20 +0800 [thread overview]
Message-ID: <f6e57309-be5a-4a84-a280-6ed00a550548@linux.intel.com> (raw)
In-Reply-To: <9cc2010f-269c-4d23-b284-6fe4162f8810@linux.intel.com>
On 1/18/2024 10:26 AM, Ethan Zhao wrote:
>
> On 1/18/2024 8:46 AM, Baolu Lu wrote:
>> On 1/17/24 5:00 PM, Ethan Zhao wrote:
>>> + /*
>>> + * If the ATS invalidation target device is gone this moment
>>> (surprise
>>> + * removed, died, no response) don't try this request again.
>>> this
>>> + * request will not get valid result anymore. but the
>>> request was
>>> + * already submitted to hardware and we predict to get a ITE in
>>> + * followed batch of request, if so, it will get handled then.
>>> + */
>>> + if (target_pdev && !pci_device_is_present(target_pdev))
>>> + return -EINVAL;
>>
>> Again, we should not ignore the error triggered by the current request.
>> Do not leave it to the next one. The WAIT descriptor is a fence. Handle
>> everything within its boundary.
>
> We didn't set fence bit to every ATS invalidation wait descriptor,
>
> only the intel_drain_pasid_prq() queue a drain page requests with FN
>
> sit, but that is not called in hotplug removal path.
So, in fact so far, it doesn't act as a fence except the
intel_drain_pasid_prq() ,
and it never handle everthing within its border.
Thanks,
Ethan
>
>
> Thanks,
>
> Ethan
>
>
>
>>
>> Best regards,
>> baolu
>
prev parent reply other threads:[~2024-01-18 2:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 17:02 [RFC PATCH v10 0/5] fix vt-d hard lockup when hotplug ATS capable device Ethan Zhao
2023-12-28 17:02 ` [RFC PATCH v10 1/5] iommu/vt-d: add pci_dev parameter to qi_submit_sync and refactor callers Ethan Zhao
2024-01-10 4:59 ` Baolu Lu
2024-01-10 7:51 ` Ethan Zhao
2023-12-28 17:02 ` [RFC PATCH v10 2/5] iommu/vt-d: break out ATS Invalidation if target device is gone Ethan Zhao
2024-01-10 5:17 ` Baolu Lu
2024-01-10 8:29 ` Ethan Zhao
2023-12-29 8:18 ` [RFC PATCH v10 0/5] fix vt-d hard lockup when hotplug ATS capable device Tian, Kevin
2023-12-29 9:28 ` Ethan Zhao
2024-01-09 1:24 ` Ethan Zhao
2024-01-15 7:58 ` Ethan Zhao
2024-01-17 3:24 ` Baolu Lu
2024-01-17 5:26 ` Ethan Zhao
2024-01-17 5:38 ` Ethan Zhao
2024-01-17 9:00 ` Ethan Zhao
2024-01-18 0:46 ` Baolu Lu
2024-01-18 2:26 ` Ethan Zhao
2024-01-18 2:32 ` Ethan Zhao [this message]
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=f6e57309-be5a-4a84-a280-6ed00a550548@linux.intel.com \
--to=haifeng.zhao@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--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 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.