Add the Shvsatpa extension and vsatp mode config options - #1906
Open
Nadime Barhoumi (nadime15) wants to merge 3 commits into
Open
Add the Shvsatpa extension and vsatp mode config options#1906Nadime Barhoumi (nadime15) wants to merge 3 commits into
Nadime Barhoumi (nadime15) wants to merge 3 commits into
Conversation
Nadime Barhoumi (nadime15)
added
the
extension
Adds Shvsatpa along with `extensions.H.vsatp_modes`, mirroring the `hgatp` mode options from riscv#1893. We have satp (Svnn), vsatp (Svnn), and hgatp (SvXnn). The translation modes for satp enforce a dependency. For example, supporting Sv57 without supporting Sv48 is not possible. I can't find anywhere in the spec that explicitly says whether this dependency also applies to vsatp, but I'm pretty sure the same rules apply there. hgatp however, is a bit strange in this regard, because it is allowed to support Sv57x4 without supporting Sv48x4, etc. On top of that, both vsatp and hgatp need to support Bare. So `vsatp` gets the same ordering checks as `satp`, and Bare stays unconditional for it. Keeping Bare unconditional also fixes a regression from riscv#1894. `legalize_satp` is shared between `satp` and `vsatp`, so gating Bare on Svbare applied to `vsatp` too, which according to the spec forbids since `vsatp.MODE` (and `hgatp.MODE`) resets to 0.
Nadime Barhoumi (nadime15)
force-pushed
the
add-extension-shvsatpa
branch
from
August 26, 2026 22:04
534082a to
06b19e9
Compare
Prashanth Mundkur (pmundkur)
approved these changes
Aug 27, 2026
| ]; | ||
| // NOTE: Sv32 is not listed because VSXLEN=XLEN here, hstatus.VSXL is | ||
| // read-only. It could be added if changing VSXL is supported. | ||
| let sv39_supported = currentlyEnabled(Ext_Sv39) & (not(is_vsatp) | sys_vsatp_sv39_supported); |
Collaborator
There was a problem hiding this comment.
Unless I am getting my parentheses mixed up, this doesn't seem right. This currently requires always requires Sv39 to be supported, but I don't think that is required for vsatp. Shouldn't it be the following instead:
Suggested change
| let sv39_supported = currentlyEnabled(Ext_Sv39) & (not(is_vsatp) | sys_vsatp_sv39_supported); | |
| let sv39_supported = (currentlyEnabled(Ext_Sv39) & not(is_vsatp)) | sys_vsatp_sv39_supported; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds Shvsatpa along with
extensions.H.vsatp_modes, mirroring thehgatpmode options from #1893.We have
satp(Svnn),vsatp(Svnn), andhgatp(SvXnn).The translation modes for satp enforce a dependency. For example, supporting Sv57 without supporting Sv48 is not possible. I can't find anywhere in the spec that explicitly says whether this dependency also applies to
vsatp, but I'm pretty sure the same rules apply there.hgatphowever, is a bit strange in this regard, because it is allowed to support Sv57x4 without supporting Sv48x4, etc.On top of that, both
vsatpandhgatpneed to support Bare, since that is their reset value and they are WARL.So
vsatpgets the same ordering checks assatp, and Bare stays unconditional forvsatp. Keeping Bare unconditional also fixes a regression from #1894.legalize_satpis shared betweensatpandvsatp, so gating Bare on Svbare applied tovsatptoo, which according to the spec is incorrect sincevsatp.MODE(andhgatp.MODE) resets to 0.