Re: [PATCH v5 4/9] iommufd: Add fault and response message definitions
From: Baolu Lu
Date: Sun May 19 2024 - 23:35:42 EST
On 5/20/24 11:24 AM, Tian, Kevin wrote:
From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Sunday, May 19, 2024 10:38 PM
On 2024/5/15 15:43, Tian, Kevin wrote:
From: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Tuesday, April 30, 2024 10:57 PM
iommu_hwpt_pgfaults represent fault messages that the userspace can
retrieve. Multiple iommu_hwpt_pgfaults might be put in an iopf group,
with the IOMMU_PGFAULT_FLAGS_LAST_PAGE flag set only for the last
iommu_hwpt_pgfault.
Do you envision extending the same structure to report unrecoverable
fault in the future?
I am not envisioning extending this to report unrecoverable faults in
the future. The unrecoverable faults are not always related to a hwpt,
and therefore it's more suitable to route them through a viommu object
which is under discussion in Nicolin's series.
OK, I'll take a look at that series when reaching it in my TODO list. 😊
+ * @length: a hint of how much data the requestor is expecting to fetch.
For
+ * example, if the PRI initiator knows it is going to do a 10MB
+ * transfer, it could fill in 10MB and the OS could pre-fault in
+ * 10MB of IOVA. It's default to 0 if there's no such hint.
This is not clear to me and I don't remember PCIe spec defines such
mechanism.
This came up in a previous discussion. While it's not currently part of
Can you provide a link to that discussion?
https://lore.kernel.org/linux-iommu/20240322170410.GH66976@xxxxxxxx/
the PCI specification and may not be in the future, we'd like to add
this mechanism for potential future advanced device features as it
offers significant optimization benefits.
We design uAPI for real usages. It's a bit weird to introduce a format
for unknown future features w/o an actual user to demonstrate its
correctness.
Best regards,
baolu