fix(riscv): set FS before fp restore/clear in switch_to#30
Merged
equation314 merged 1 commit intoarceos-org:mainfrom Mar 23, 2026
Merged
Conversation
Move sstatus::set_fs(next_fp_state.fs) before the restore/clear match so FP instructions are executable when firmware leaves FS=Off.
equation314
approved these changes
Mar 23, 2026
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
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.
Background
When booting downstream StarryOS on riscv64 with RustSBI, the kernel could panic with:
Unhandled trap Exception(IllegalInstruction)stval=0xf2000053The same workload could boot under other firmware setups, indicating a firmware-dependent FP init assumption.
(Downstream context: [bug] 使用RustSBI启动StarryOS失败 Starry-OS/StarryOS#130, fix(riscv64): boot StarryOS with RustSBI on riscv64 without IllegalInstruction trap Starry-OS/StarryOS#131)
Root Cause
In
axcpuRISC-V fp-simd context switching, FP instructions can be executed inrestore/clearpaths whilesstatus.FSis stillOffon some boot paths/harts.When
FS=Off, executing FP instructions (e.g.fld/fmv.d.x) traps asIllegalInstruction.So the issue is not OS entry order itself, but a missing local precondition in the
axcpuFP context switch path.A common trigger is switching from a task that does not use FP (
FS=Off) to one that needs FP state restore/initialization, where FP instructions in the switch path can trap before the next task actually runs.Changes
This PR fixes the issue at the root-cause location in axcpu:
Validation Performed
cargo fmt --all -- --checkpasses.IllegalInstructiontrap in fp-simd switching path.Impact
sstatus.FS=Off.Files Included In This PR
src/riscv/context.rs