-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify PTE fault exception priority, and add into instruction pages #485
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think this is unambiguous, and can be implemented easily in Sail, and I can't see any reason why it would be hard to implement in designs. Just one minor typo.
Signed-off-by: Tariq Kurd <[email protected]>
Signed-off-by: Tariq Kurd <[email protected]>
|
||
If a store page fault is caused by a CHERI <<cheri_pte_ext,PTE>> fault, then set bit zero of <<mtval2>> to 1 and all other bits to 0, otherwise set all bits to zero. | ||
NOTE: Reporting both allows the software the choice about which action to take first, for example a write to a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This confuses me. Load-side revocation will never do any sweeping on stores, so value 2 isn't useful, it will be treated the same as 1. As for loads, yes, sweeping occurs there, but there's nothing else really to do if both faults occur (for non-tag-dependent implementations) over and above just a CHERI PTE fault, and if your implementation is tag-dependent then the RISC-V page fault and CHERI PTE fault are strictly serial so it's impossible to have both at once.
Fixes #484