> From: Lu Baolu <[email protected]> > Sent: Thursday, April 16, 2020 4:38 PM > > Hi Kevin, > > On 2020/4/15 19:10, Tian, Kevin wrote: > > the completion of above sequence ensures that previous queued > > page group responses are sent out and received by the endpoint > > and vice versa all in-fly page requests from the endpoint are queued > > in iommu page request queue. Then comes a problem - you didn't > > wait for completion of those newly-queued requests and their > > responses. > > I thought about this again. > > We do page request draining after PASID table entry gets torn down and > the devTLB gets invalidated. At this point, if any new page request for > this pasid comes in, IOMMU will generate an unrecoverable fault and > response the device with IR (Invalid Request). IOMMU won't put this page > request into the queue. [VT-d spec 7.4.1]
Non-coverable fault implies severe errors, so I don't see why we should allow such thing happen when handling a normal situation. if you look at the start of chapter 7: -- Non-recoverable Faults: Requests that encounter non-recoverable address translation faults are aborted by the remapping hardware, and typically require a reset of the device (such as through a function- level-reset) to recover and re-initialize the device to put it back into service. -- > > Hence, we don't need to worry about the newly-queued requests here. > > Best regards, > Baolu Thanks Kevin _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
