Closed zhuotianshu closed 3 months ago
The X permission is granted only if the R permission is also granted.
This is a PCIe rule and not an IOMMU rule. If the device requested say read permission but not execute permission and the translation has both read and execute permission then the permission granted is only read since execute was not requested.
This is a PCIe rule and not an IOMMU rule.
So in my understand, it is necessary to obey this rule in a success response to an ATS translation request? So when translation could not be completed due to a permission check fail (which will cause a page fault), the success response should have R=W=X=0? R=W=0 because that:
When translation could not be completed due to the following causes a Success Response with R and W bits set to 0 is generated.
And X=0 because that:
The X permission is granted only if the R permission is also granted.
Is my understand right?
So when translation could not be completed due to a permission check fail (which will cause a page fault), the success response should have R=W=X=0?
When a translation could be completed but permissions were not available then the available permissions are provided. W cannot be 1 without R being 1 and X cannot be 1 without R being 1. It is possible to thus request a translation with write permissions and not receive W=1 or to request execution permission but not receive X=1. A R=W=0 response occurs when the page table entry is not present and yes when R=W=0, X is also 0.
A R=W=0 response occurs when the page table entry is not present...
Yes I know that, but page faults can also occur when permission checks failed. Suppose that an ATS translation request requests read and write permission, but the page only has read permission, then what will the Success Response look like? Will it be R=1, W=0 or R=W=0? As I understand it, since this request will cause a write page fault (though won't be reported in FQ), R and W bits in the Success Response should be set to 0 according to:
When translation could not be completed due to the following causes a Success Response with R and W bits set to 0 is generated. No faults are logged in the fault queue on these errors. The translated address returned with such completions is UNSPECIFIED. • Instruction page fault (cause = 12) • Read page fault (cause = 13) • Write/AMO page fault (cause = 15) ...
So it seems that when permission check fails, the Success Response is always with R=W=0, and thus X=0?
The key point is "When translation could not be completed". The specific case you highlighted occurs where the translation could not be completed because it was an invalid address. See:
If the translation could be successfully completed but the requested permissions are not present (Execute requested but no execute permission; no-write not requested and no write permission; no read permission) then a Success response is returned with the denied permission (R, W or X) set to 0 and the other permission bits set to the value determined from the page tables. The X permission is granted only if the R permission is also granted.
Got that, thank you very much.
In 2.6. PCIe ATS translation request handling:
The conclusion of https://github.com/riscv-non-isa/riscv-iommu/issues/291 is that, the above description should add a restriction that, if execute permission is not requested, X bit shouldn't be set when using a success response to respond an ATS translation request that the requested permissions are not present.
But in a previous paragraph:
Since an ATS translation request that the requested permissions are not present will cause a page fault, I thought in this situation, R and W bits will always be set to 0. And since "The X permission is granted only if the R permission is also granted.", X bit will also always be set to 0. So it seems no need to change the spec description.