OSPP 2026 idea: Lazy FP/RVV context switching for RISC-V

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.

1. 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.
2. 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.
3. Add tests on qemu-virt64-riscv with vector using threads mixed with plain threads to catch any state corruption.
4. 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