> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx> > Sent: Monday, May 20, 2024 11:33 AM > > 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 > >>>> > >>>> + * @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/ > We can always extend uAPI for new usages, e.g. having a new flag bit to indicate the additional filed for carrying the number of pages. But requiring the user to handle non-zero length now (though trivial) is unnecessary burden. Do we want the response message to also carry a length field i.e. allowing the user to partially fix the fault?
