Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v2 6/7] iommu/vt-d: Add page request draining support | Date | Fri, 17 Apr 2020 02:27:49 +0000 |
| |
> From: Lu Baolu <baolu.lu@linux.intel.com> > 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
| |