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

Open
#11,786 5 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
embedded-iot, operating-systems

Research direction

Start by locating the RISC-V thread context-switch implementation and the qemu-virt64-riscv test setup. Read how existing FPU state is handled, then investigate mstatus.FS and mstatus.VS and the RT_USING_RVV configuration boundary. Done means lazy FP and RVV state handling, mixed vector/plain-thread tests without corruption, and before-and-after context-switch benchmarks for single-hart systems.

Written by the indexing model from the issue text.

Description

Arch: RISC-V enhancement Kernel
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

Dominant language
C
Stars
12.2k
Forks
5.4k
Avg merge
5d 14h
Merged PRs (30d)
48

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from RT-Thread/rt-thread

All issues in RT-Thread/rt-thread

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.