Affected area
Kernel
Hardware/BSP vendor
Not applicable / Other
Architecture
RISC-V
Describe problem solved by the proposed feature
On the RISC-V port, every context switch saves and restores the full FPU
state unconditionally, even for threads that never touch it. There is also
no support for the Vector (RVV) extension at all. Vector registers are not
part of the thread context right now, so any thread using V instructions
would have its state silently corrupted by a context switch. Both gaps are
noted in #10722.
Describe your preferred solution
Make extension state save and restore lazy instead of unconditional, using
the mstatus.FS and mstatus.VS dirty bits the hardware already provides.
- Only save and restore FP state when a thread has actually used it since
its last switch (FS dirty bit), instead of doing it on every switch.
- Add RVV 1.0 vector register state to the thread context, saved and
restored the same lazy way using the VS bit, behind an RT_USING_RVV
Kconfig option so boards without V are not affected.
- Add tests on qemu-virt64-riscv with vector using threads mixed with
plain threads to catch any state corruption.
- Benchmark context switch cost before and after.
I want to keep the scope to a single hart for now. SMP correctness, full
RVA23 compliance, and a generic extension discovery API can be natural
follow ups later, so this stays achievable as an OSPP 2026 project.
This is a project idea I want to propose for OSPP 2026, along with this
solution. Happy to hear if this is useful to the community or if someone
is already working on something similar.
Describe possible alternatives
No response
Affected area
Kernel
Hardware/BSP vendor
Not applicable / Other
Architecture
RISC-V
Describe problem solved by the proposed feature
On the RISC-V port, every context switch saves and restores the full FPU
state unconditionally, even for threads that never touch it. There is also
no support for the Vector (RVV) extension at all. Vector registers are not
part of the thread context right now, so any thread using V instructions
would have its state silently corrupted by a context switch. Both gaps are
noted in #10722.
Describe your preferred solution
Make extension state save and restore lazy instead of unconditional, using
the mstatus.FS and mstatus.VS dirty bits the hardware already provides.
its last switch (FS dirty bit), instead of doing it on every switch.
restored the same lazy way using the VS bit, behind an RT_USING_RVV
Kconfig option so boards without V are not affected.
plain threads to catch any state corruption.
I want to keep the scope to a single hart for now. SMP correctness, full
RVA23 compliance, and a generic extension discovery API can be natural
follow ups later, so this stays achievable as an OSPP 2026 project.
This is a project idea I want to propose for OSPP 2026, along with this
solution. Happy to hear if this is useful to the community or if someone
is already working on something similar.
Describe possible alternatives
No response