[PATCH] Add trap-based ISA extension emulation

[Bo Gan]

Hi Benedikt,

On 10/26/25 13:21, Benedikt Freisen wrote:
> This patch series seeks to add trap-based emulation functionality for various ISA extensions relevant to RVA22, RVB23 and RVA23.
> The emulation functionality contained herein has been demonstrated to e.g. allow the VisionFive 2's JH7110 to run software using the RVA22U64 and RVB23U64 profiles, allow the Orange Pi RV2's Ky X1 (a SpacemiT K1 derivative) to run Ubuntu 25.10 (RVA23U64) in a docker container, and allow the Tenstorrent Blackhole's SiFive X280 (Gen. 1) to boot into Ubuntu 25.10.
> 
> The first patch merely fixes the tab alignment in riscv_encoding.h.
> 
> The second patch adds workarounds for decoder bugs in the C906 and C910, where FENCE and FENCE.I instructions with nonzero reserved fields are mistakenly treated as illegal instructions.
> 
> The third patch corrects the typedef of "s8" from "char" to "signed char", because "char" is implicitly unsigned on RISC-V.
> 
> To me, personally, these three look like uncontroversial improvements.
> 
> The fourth patch, the big one, adds the actual ISA extension emulation code.
> For initial consideration, I am hereby submitting it "as-is", mainly to see whether there is even interest in having this kind of functionality in mainline OpenSBI.
> If that turns out to be the case, this patch will need further iterations that, aside from incorporating your feedback, e.g. add configuration options for conditional compilation.
> 
> The fifth patch is included for documentary purposes only, not for merging.
> It contains the section of my fork's README file that explains which extensions can be emulated. The information therein could also go somewhere else.
> 
> 

OpenSBI is a critical RISCV firmware implementation. It's NOT an emulator.
It should strictly follow the spec and focus on correctness, security and
performance. It's not wise to add this kind of single purpose, not spec-
related, very hard to verify correctness (for people other than you) code
to something that everyone relies on. I don't needed it and either do I
want to see my jh7110 crash because of it. I have something similar as you
did, which is to emulate a S mode w/o MMU on the S7 hart of jh7110 such
that I can run linux nommu on it, and I'm perfectly happy maintaining it
as a fork, without polluting the mainline repo. FYI, S7 only has M/U mode
w/o MMU. For stock systems, after boot, S7 spins in OpenSBI doing nothing.

In my vision, part of such "instruction" emulation feature can be done in
userspace as some kind of binary translation layer pre-loaded into
processes as .so library. This can solve issues for apps hard-coded for
ext., w/o probing it first. It'll also be performant.

Side note on jh7110 cache flush:

 From U74 Core Complex Manual:
(ref: https://starfivetech.com/uploads/u74mc_core_complex_manual_21G1.pdf)

  "The custom instructions CFLUSH.D.L1 and CDISCARD.D,L1 only target the
   L1 data cache, and do not impact the L2 cache. The L2 cache controller
   contains flush capability, which performs a clean and invalidate
   operation of a line in the L2 cache. If the targeted line also resides
   in the L1 cache, then it too will be cleaned and invalidated. Section
   13.4.9 describes how to flush the L2 cache."

cflush.d.l1 is not enough. The proper way to flush cache on jh7110 is
through L2 cache controller (MMIO).

Bo