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

Highest bits in Sv39 #136

Closed
janhoogerbrugge opened this issue Nov 20, 2018 · 2 comments
Closed

Highest bits in Sv39 #136

janhoogerbrugge opened this issue Nov 20, 2018 · 2 comments
Assignees

Comments

@janhoogerbrugge
Copy link

janhoogerbrugge commented Nov 20, 2018

The spec says:

Load and store effective addresses, which are 64 bits, must have bits 63–39
all equal to bit 38, or else a page-fault exception will occur.

The code says:

  // check that all bits in the address >= 39 are equal
  if (!((&lsu_ctrl.vaddr[63:39]) == 1'b1 || (|lsu_ctrl.vaddr[63:39]) == 1'b0)) ...

So then the 39 in the code should be 38?

Jan

@zarubaf
Copy link
Contributor

zarubaf commented Nov 20, 2018

Yes you are absolutely right. Unfortunately there is some other issue with this code: Actually we should not test this in machine mode. @msfschaffner has a patch for this and will also include the issue you address. Thanks for bringing this up.

@zarubaf zarubaf added the bug label Nov 20, 2018
@msfschaffner
Copy link
Contributor

Thanks for reporting this. I'll include it in the patch that fixes the page-fault checks.

zarubaf added a commit that referenced this issue Nov 22, 2018
Fix mismatches in virtual address checking logic (this fixes #136).

- Instr/ld/st must only throw access faults when virtual memory translation is enabled
- Correct tested bit slice from [63:39] to [63:38]
- Fixes #136
OttG pushed a commit to OttG/cva6 that referenced this issue Jul 6, 2021
Fix mismatches in virtual address checking logic (this fixes openhwgroup#136).

- Instr/ld/st must only throw access faults when virtual memory translation is enabled
- Correct tested bit slice from [63:39] to [63:38]
- Fixes openhwgroup#136
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

3 participants