Questions about ATS translation request and ATS Page Request handling
Closed this issue · 6 comments
-
Whether the DTF affects the following logged in the fault queue
ATS [1] translation requests that encounter a configuration error results in a Completer Abort (CA)
response to the requester. The following cause codes belong to this category:
• Instruction access fault (cause = 1)
• Read access fault (cause = 5)
• Write/AMO access fault (cause = 7)
• MSI PTE load access fault (cause = 261)
• MSI PTE misconfigured (cause = 263)
• PDT entry load access fault (cause = 265)
• PDT entry misconfigured (cause = 267) -
Whether the following status cause a fault to log in the fault queue? The conditons where no faults are logged in the fault queue for PCIe ATS "Page Request" messages don't include both the following status
The status is set to Invalid Request if the following faults are encountered:
• ddtp.iommu_mode is Bare
• EN_PRI is set to 0
Whether the DTF affects the following logged in the fault queue
Yes it does. Please also see table 11.
Whether the following status cause a fault to log in the fault queue? The conditons where no faults are logged in the fault queue for PCIe ATS "Page Request" messages don't include both the following status
Yes, they will. Please also see section 4.2 that states "If a fault condition prevents locating a valid device context then the DTF value assumed for reporting such faults is 0."
Yes, they will. Please also see section 4.2 that states "If a fault condition prevents locating a valid device context then the DTF value assumed for reporting such faults is 0."
So what is the cause of each of them?I think that when ddtp.iommu_mode is Bare,report"Transaction type disallowed" (cause = 260);and when EN_PRI is set to 0, report "DDT entry misconfigured" (cause = 259).And the ttyp should be "PCIe Message Request"(ttyp ==9).Is that right?
The cause is 260 for both of these and the transaction type is message request.
I also have another question. For the PRI fault report, the software can get the relevant information through the interruption caused by fip or pip, except when pqen=0 or pqon=0. I can understand why a fault report is not generated to log in fault queue when page-request queue encountered a memory access fault (pqcsr.pqmf == 1) or "Page Request" could not be queued due to the page-request queue being full (pqt == pqh - 1) or had a overflow (pqcsr.pqof == 1). That's because pqof and pqmf themselves generate an interrupt. Why there is no fault report logged in fault queue when pqen==0 or pqon==0?
Why there is no fault report logged in fault queue when pqen==0 or pqon==0?
When software has just disabled the page requests queue then it is not useful to remind software that it has disabled the page request queue.
Thanks for your answer.