> 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? > 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.
