Skip to content
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

Clarification about access to a physical address which is higher than the maximal supported physical address #1774

Open
leBsky opened this issue Dec 14, 2024 · 1 comment

Comments

@leBsky
Copy link

leBsky commented Dec 14, 2024

Assuming we have a RISC-V CPU whose maximal supported physical address is 0xff_ffff_ffff (i.e. the maximal supported physical address is 40 bit)
Then what is the behavibor when the following condition occurs, the Spec seems not give a clear definition.

  1. M mode or MMU disabled, jump instruction or load/store instruction which accesses to an address higher than the maximal supported physical address, for example, jump to physical address 0xffff_ffff_fffff. Should it raise an exception? If yes, which exception?
  2. S/U mode and MMU enabled, the pte[53:10] PPN filed is 0xfff_ffff_ffff. That is, page table walk finds a pte which has ppn is higher than maximal physical address 28 bits(40-12). Should it raise an exception? If yes, which exception?
@leBsky leBsky changed the title Clarification about access to physical address which is higher than the maximal supported physical address Clarification about access to a physical address which is higher than the maximal supported physical address Dec 14, 2024
@pdonahue-ventana
Copy link
Contributor

It sounds like your implementation has a PMA region with no read/write/execute access (previously called a vacant PMA region) starting at address 0x10000000000. Accessing that region will cause a PMA violation which will manifest as an access-fault exception (or possibly a bus-error interrupt) as described in the PMA section of the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants