Use saved mstatus for FPU/VPU state determination#1330
Merged
aggarg merged 3 commits intoFreeRTOS:mainfrom Nov 3, 2025
Merged
Conversation
According to the RISC-V Privileged Architecture Specification (20211203), writing Initial or Clean to the FS field of mstatus may result in the FS value getting set to Dirty in some implementations. This means we cannot rely on reading back the same FS value after writing to mstatus. Previously, the context restore code would: 1. Write an FS value to mstatus 2. Read mstatus again at a later point 3. Use the read FS value to determine FPU status This change updates the context restore code to use the mstatus value from the saved context instead of re-reading mstatus after writing to it. This required chaning the location of the mstatus slot in the context. Fixes: FreeRTOS#1327 Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
|
RichardBarry
approved these changes
Nov 2, 2025
rawalexe
approved these changes
Nov 3, 2025
DajanaV
pushed a commit
to auroralabs-loci/FreeRTOS-Kernel
that referenced
this pull request
Dec 3, 2025
According to the RISC-V Privileged Architecture Specification (20211203), writing Initial or Clean to the FS field of mstatus may result in the FS value getting set to Dirty in some implementations. This means we cannot rely on reading back the same FS value after writing to mstatus. Previously, the context restore code would: 1. Write an FS value to mstatus 2. Read mstatus again at a later point 3. Use the read FS value to determine FPU status This change updates the context restore code to use the mstatus value from the saved context instead of re-reading mstatus after writing to it. This required chaning the location of the mstatus slot in the context. Fixes: FreeRTOS#1327 Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
2 tasks
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.
Description
According to the RISC-V Privileged Architecture Specification (20211203), writing Initial or Clean to the FS field of
mstatusmay result in the FS value getting set to Dirty in some implementations. This means we cannot rely on reading back the same FS value after writing tomstatus.Previously, the context restore code would:
mstatusmstatusagain at a later pointThis change updates the context restore code to use the
mstatusvalue from the saved context instead of re-readingmstatusafter writing to it. This required changing the location of themstatusslot in the context.Test Steps
Tested using RISC-V_RV32_QEMU_VIRT_GCC demo.
Checklist:
Related Issue
#1327
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.