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

[Vivian Wang]

Hi Dave,

Some email procedural stuff first. I'm not sure how you're sending
emails, but it is behaving very weirdly. Your email hasn't got an
In-Reply-To header, and the quoting just shows up. I have received
correctly-threaded emails from your domain though, so I'm guessing your
email server is fine. Please ask your colleagues about this and try to
fix it.

The public-inbox archive seems to be smart enough to figure out a
Subject match, at least, so for anyone getting confused:

https://lore.kernel.org/opensbi/20260311171103.70074-1-dave.patel@riscstar.com/T

On 3/12/26 19:01, dave.patel at riscstar.com wrote:
> Hi,
>
> On , wrote:
>
>> This does not work in Machine mode, where OpenSBI resides.
> The code provided works in Machine mode. It has been tested in an M-mode
> environment where OpenSBI executes using S-mode bare metal app.
>
>> See privileged spec, section "Extension Context Status in mstatus
>> Register": "Machine and Supervisor modes share a single copy of the FS,
>> VS, and XS bits."
> Yes, that is correct. Machine and Supervisor modes share a single copy
> of the FS and VS bits.
>
>> This means that a Supervisor mode program can set sstatus.FS to Dirty,
>> access floating point state, and set sstatus.FS back to Off without
> ?Machine mode software noticing ever.
>
> That is correct. However, in the proposed approach the lazy context
> switch is triggered only when sstatus.FS is Dirty. If sstatus.FS is not
> Dirty, then no save/restore operation is performed.
>
So, the problem is that this is unreliable. A Supervisor mode program
can just:

  li t0, SSTATUS_FS
  csrs sstatus, t0
  fadd fa0, fa0, fa0
  csrc sstatus, t0

And that would change fa0 without trapping while leaving sstatus.FS as Off.

The Supervisor mode software *itself* needs to set sstatus.FS and
sstatus.VS for its own state tracking, so this isn't a contrived
example. For example, Linux clears sstatus.FS and sstatus.VS (i.e. sets
them both to Off) early on entry into kernel mode [1] to disallow use of
them in most kernel code. You can imagine Linux needs to do its own lazy
saving of F and V registers.

If then it traps into Machine mode while in kernel mode, for, e.g., an
SBI call, sstatus.FS and sstatus.VS would not be Dirty, yet the F and V
registers may have been manipulated arbitrarily by User mode before
entering the kernel in Supervisor mode. Then OpenSBI code would
incorrectly assume that saving isn't required.

[1]: https://elixir.bootlin.com/linux/v7.0-rc1/source/arch/riscv/kernel/entry.S#L176

>> See also https://github.com/riscv/riscv-isa-manual/issues/832
>> "Impossible to implement HS-level sstatus.{FS,VS} = Off with
>> software-emulated hypervisor extension?" where I ran into the same
>> problem in a different context.
> Could you please elaborate on how the issue described there applies in
> this context?

That's another aspect of the same issue: Machine mode can't track and
control F and V for Supervisor mode.

>> So basically, lazy saving/restoring F and V in Machine mode with
>> multiple Supervisor mode programs is not a designed feature, and is not
>> possible as the privileged architecture is currently designed. For these
>> use cases non-lazy switching is required.
> Could you provide more details on the limitations you are referring to?
> In particular, it would be helpful to understand whether the concern is
> related to the shared FS/VS state visibility between privilege levels,
> or to some other aspect of the privileged architecture.

It is just the shared access that's the problem.

Vivian "dramforever" Wang