[RFC] OpenSBI: Lazy floating-point and vector context switching

[dave.patel at riscstar.com]

Hi OpenSBI maintainers and community,

I am working on an implementation to support floating-point (FP) and
vector register context management during domain and application
context switches in OpenSBI.

Currently, OpenSBI saves and restores only the integer register
context when handling traps or domain transitions. The FP registers
(f0–f31) and vector registers (v0–v31) are not currently managed by
OpenSBI.

With increasing adoption of the RISC-V vector extension and
floating-point workloads, it becomes important to ensure correct
behavior when S-mode software or trusted applications use these
execution units.

This email proposes an approach to support lazy FP and vector
context switching, aligned with the mechanism described in the
RISC-V privileged specification.

---

## Background

In RISC-V, the `FS` (Floating-point State) and `VS` (Vector State)
fields in `mstatus` / `sstatus` control access to the floating-point
and vector units.

When these fields are set to `Off`, any attempt to execute FP or
vector instructions results in an illegal instruction trap.

This mechanism allows operating systems and firmware to implement
lazy context switching where FP/vector registers are saved or
restored only when they are actually used.

---

## Proposed Design

The design separates responsibilities between OpenSBI and S-mode
software.

1. OpenSBI (M-mode responsibilities)

   * Detect FP or vector instruction traps.
   * Enable the corresponding unit by updating `FS` or `VS`.
   * Return control to S-mode so the instruction can be retried.

   During domain context switches:

   * If `FS == Dirty`, save floating-point state
     (f0–f31, fcsr).
   * If `VS == Dirty`, save vector state
     (v0–v31, vl, vtype, vcsr).
   * If the state is Clean, Initial, or Off, skip saving.

2. S-mode responsibilities

   * Manage FP/vector register context for tasks.
   * Restore state when the task resumes execution.

---

## Trap Handling Overview

```
            +----------------------------+
            |        S-mode App          |
            |  PC, GPRs, FP/VS registers |
            +-------------+--------------+
                          |
                          | Trap / Interrupt
                          v
            +----------------------------+
            |          M-mode            |
            |      Trap Handler Entry    |
            +-------------+--------------+
                          |
            Check mstatus.FS / VS state
                |                     |
            Dirty = Yes           Dirty = No
                |                     |
       Save FP/VS registers       Skip save
                |
                v
        Handle trap in M-mode
                |
                v
           Before mret
                |
       Restore registers if saved
                |
                v
             Execute mret
                |
                v
            Resume S-mode
```

---

## Execution Flow

1. Scheduler performs a context switch and clears `FS` and `VS`.
2. A thread executes an FP or vector instruction.
3. Hardware generates an illegal instruction trap.
4. OpenSBI detects the instruction class and enables the unit.
5. Control returns to S-mode.
6. The instruction is retried successfully.

This approach avoids saving large FP/vector register files during
every context switch, improving performance.

---

## Implementation Outline

The implementation includes:

* Instruction decoding in the illegal instruction handler to detect
  FP instructions (opcodes 0x53, 0x07, 0x27) and vector instructions
  (opcode 0x57).
* Helper routines in OpenSBI to enable FP or vector execution by
  updating `mstatus`.
* S-mode runtime code to store and restore FP/vector contexts.
* Bare-metal tests validating lazy restore behavior.

---

## Testing

Initial testing is planned using QEMU with vector extension support
(rv64gcv).

The test environment contains two S-mode workloads:

1. Floating-point processing
2. Vector processing

Expected behavior:

* The first FP/vector instruction triggers a trap.
* OpenSBI enables the corresponding unit.
* Subsequent instructions execute normally.
* Domain context switches save/restore FP/vector registers when
  required.

---

## Request for Feedback

I would appreciate feedback on:

* Preferred location within the OpenSBI trap framework for
  instruction classification.
* Any existing work related to FP/vector context management that
  should be referenced.

If there is interest, I can follow up with an RFC patch series
implementing this mechanism along with test infrastructure.

Thanks for your time and feedback.

Best regards,
Dave Patel