[PATCH 6/7] lib: sbi: Rework load/store emulator instruction decoding

[Andrew Jones]

On Wed, Feb 11, 2026 at 02:36:26AM -0800, Bo Gan wrote:
> Hi Andrew,
> 
> On 2/10/26 08:08, Andrew Jones wrote:
> > On Tue, Feb 10, 2026 at 01:40:43AM -0800, Bo Gan wrote:
> > ...
> > > Validation:
> > > The patch is validated to have fixed the issue with test cases running
> > > on a modified version of QEMU that exposes misaligned faults [1], and
> > > a further modified version that removes tinst transformation [2]. The
> > > S-mode OS is a local build of Debian Trixie 6.12 kernel that enables
> > > COMPAT (RV32), and the U-mode test application exercises all integer
> > > and floating-point load/store (RVIFD64/32+RVC64/32) instructions with
> > > all possible imm values. The patch is also tested on real HW (Sifive
> > > P550/ESWIN EIC7700), which only supports RV64. On P550, the same test
> > > was validated both in U mode and VU mode, where the host runs a 6.12
> > > ESWIN vendor kernel that has some ESWIN SoC device driver patches [3]
> > > applied, and the guest runs the exact same Debian Trixie 6.12 kernel
> > > mentioned above.
> > > 
> > > [1] https://github.com/ganboing/qemu/tree/ganboing-misalign
> > > [2] https://github.com/ganboing/qemu/tree/ganboing-misalign-no-tinst
> > > [3] https://github.com/sifiveinc/riscv-linux/tree/rel/kernel-6.12/hifive-premier-p550
> > > 
> > 
> > Hi Bo,
> > 
> > It'd be nice if we could integrate emulation tests into a test suite that
> > gets run frequently in order to catch regressions. We have already started
> > using the kvm-unit-tests[4] framework for SBI testing so adding emulation
> 
> Good to know. I wasn't aware of this project. I'll definitely take a look
> and see if I can upstream the test cases there. I guess it can be utilized
> to test misaligned handler in both M mode OpenSBI and the KVM SBI layer,
> depending on whether host Linux/KVM enables misaligned exc delegation,
> correct?

Yes, and it can also be run directly on hardware without KVM (despite the
testsuites' name) when launching tests from an EFI-capable firmware.

> 
> > tests there would make sense. If special QEMU behavior is needed then we
> > should get cpu properties that enable those behaviors upstreamed so we can
> > turn them on when running the tests.
> 
> I think this is done by others for sure. I was actually inspired by this
> https://lore.kernel.org/all/20241211211933.198792-1-fkonrad@amd.com/
> series by Frederic to hack QEMU. Similar patches have been done by others
> such as Clément mentioned in this series:
> https://lore.kernel.org/all/20250106154847.1100344-1-cleger@rivosinc.com/
> I'd like to hear from folks to understand if there're any roadblocks
> exposing the misaligned fault in QEMU (gated by a config flag), before
> attempting.

I'm in favor of it (QEMU is meant to be a test environment, after all - so
it seems logical to me to want to test multiple configurations), but let's
start a thread on qemu-devel to see what feedback we get.

> 
> Spoiler alert: Linux's misaligned handler seems to be affected by the
> same insn decoding issue where there's no checking of previous XLEN. I'm
> yet to check if Linux is affected by other issues in this patchset, too.
> Once this change is merged in OpenSBI, I'll also be looking into fixing
> Linux and adding my test cases into Linux/selftests as well.

Excellent!

Thanks,
drew

> 
> > 
> > [4] https://gitlab.com/kvm-unit-tests/kvm-unit-tests
> > 
> > Thanks,
> > drew
> 
> Bo