On Wed, 2026-10-21 at 15:10 +0200, Frédéric Pétrot wrote: > On 10/20/26 16:58, Peter Maydell wrote: > > On Fri, 4 Sept 2026 at 06:23, <[email protected]> wrote: > > > > > > From: Frédéric Pétrot <[email protected]> > > > > > > Adding asm tests to check that mstatus and sstatus are updated as > > > expected in an rv128 cpu. > > > > > > Signed-off-by: Frédéric Pétrot > > > <[email protected]> > > > Reviewed-by: Daniel Henrique Barboza > > > <[email protected]> > > > Message-ID: > > > <[email protected]> > > > Signed-off-by: Alistair Francis <[email protected]> > > > > Hi; this test case provokes undefined behaviour which trips the > > clang sanitizer if you run 'make check-tcg' on a build with it > > enabled > > (i.e. configure with "--cc=clang --cxx=clang++ --enable-ubsan"). > > > > Running the test case on its own: > > > > $ > > UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:prin > > t_stacktrace=1 > > ./build/riscv-san-dbg/qemu-system-riscv64 -cpu x-rv128 -M virt > > -display none -serial stdio -semihosting -bios > > ./build/riscv-san-dbg/tests/tcg/riscv64-softmmu-test-rv128- > > sstatus.test > > ../../target/riscv/tcg/pmp.c:572:25: runtime error: shift exponent > > 64 > > is too large for 64-bit type 'target_ulong' (aka 'unsigned long') > > /usr/bin/llvm-symbolizer-18: error: '/memfd:tcg-jit (deleted)': No > > such file or directory > > #0 0x5ab9d5e8b569 in pmpcfg_csr_read > > /home/pm215/qemu/build/riscv-san- > > dbg/../../target/riscv/tcg/pmp.c:572:25 > > #1 0x5ab9d5f91440 in read_pmpcfg > > /home/pm215/qemu/build/riscv-san- > > dbg/../../target/riscv/tcg/csr.c:5588:12 > > #2 0x5ab9d5f79085 in riscv_csrrw_do64 > > /home/pm215/qemu/build/riscv-san- > > dbg/../../target/riscv/tcg/csr.c:5889:15 > > #3 0x5ab9d5f7a274 in riscv_csrrw_i128 > > /home/pm215/qemu/build/riscv-san- > > dbg/../../target/riscv/tcg/csr.c:6046:11 > > #4 0x5ab9d5fb7b11 in helper_csrw_i128 > > /home/pm215/qemu/build/riscv-san- > > dbg/../../target/riscv/tcg/op_helper.c:117:26 > > #5 0x77568c0008ba (/memfd:tcg-jit (deleted)+0x8ba) > > > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior > > ../../target/riscv/tcg/pmp.c:572:25 > > Aborted (core dumped) > > > > What happens is that in pmpcfg_csr_read() we do this: > > > > int pmpcfg_nums = 2 << riscv_cpu_mxl(env); > > > > for (i = 0; i < pmpcfg_nums; i++) { > > val = pmp_read_cfg(env, (reg_index * 4) + i); > > cfg_val |= (val << (i * 8)); > > } > > > > For the x-rv128 CPU pmpcfg_nums comes out as 16, and then > > we try to assemble 16 bytes into an 8-bit target_ulong variable, > > and for bytes 8..15 the shift amount is larger than the > > type, which is UB. > > > > I'm not sure how this is intended to work; could you have > > a look at it, please? > > Outch! > This unfolds a dark side of x-rv128: the absolute minimal csr > support > as of now (hence the x-). > Most csrs can live with 64-bit, but the pmps, [ms]cause, and > probably a > few, others cannot. > In essence, this boils down to introducing the "_i128" version of > these > csrs getter/setter for the instructions, but then it raises later > issues > on implicit accesses done within riscv_cpu_do_interrupt in which > we have > to set the upper bit of [ms]cause. > Here we'll have to check [ms]xl at runtime, I'm afraid. > > I'll send an RFC patch that solves the issue you raised, to see if > this > seems like a proper path to follow for larger csr support.
-ARM people and +RISC-V people What's the status of RV128? When we initially added experimental support there was RV128 mentioned in the spec. It has since been removed and it doesn't seem like anything is happening in terms of more support. There is overhead in keeping it, should we think about removing it? Alistair > > Thanks, > Frédéric > > thanks > > -- PMM
