Skip to content

Do not ignore hgatp writes with a reserved MODE encoding - #1915

Open
Nadime Barhoumi (nadime15) wants to merge 1 commit into
riscv:masterfrom
nadime15:fix-hgatp-unsupported-mode
Open

Do not ignore hgatp writes with a reserved MODE encoding#1915
Nadime Barhoumi (nadime15) wants to merge 1 commit into
riscv:masterfrom
nadime15:fix-hgatp-unsupported-mode

Conversation

@nadime15

Copy link
Copy Markdown
Collaborator

Per norm:hgatp_mode_warl such a write is not ignored like it is for satp, the fields are WARL, so VMID and PPN take the written values and MODE falls back to Bare (a legal value in this case).

Per `norm:hgatp_mode_warl` such a write is not ignored like it is for
`satp`, the fields are WARL, so VMID and PPN take the written values and
MODE falls back to Bare (a legal value).
@nadime15

Nadime Barhoumi (nadime15) commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator Author

So this PR sets hgatp.MODE to Bare, while Spike keeps the previous value of hgatp.MODE. Both are legal, WARL only says the read has to return a legal value (This is ties back to the issue Jordan Carlin (@jordancarlin) opened (or closed) #1896).

(The PR itself fixes a bug where VMID and PPN should be written no matter if the write to hgatp.MODE was legal or not.)

The question is whether we want a config option so the user can choose, for example to match Spike. The whole function already assumes Bare is always supported, even before this PR we return Bare on an illegal write. Or we could just switch to Spike's behavior.

So there are 3 options, keep it as it is, switch to Spikes default behaviour or introduce a config option that allows BARE OR the prev. value in case of an illegal write.

@github-actions

Copy link
Copy Markdown

Test Results

9 217 tests  ±0   9 217 ✅ ±0   1h 22m 44s ⏱️ - 26m 45s
    1 suites ±0       0 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 0f0c300. ± Comparison against base commit 6f6f2ab.

@pmundkur

Copy link
Copy Markdown
Collaborator

I suggest just following Spike for now and keeping the previous value. We can add options for other behavior later if needed.

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

Successfully merging this pull request may close these issues.

2 participants