This report was found with an automated fuzzing/emulation-differential tool and manually triaged against QEMU master c513597761d6fc06690b5b7cf10dfb7ab05815d0. The reproducer and expected outcomes were independently validated before submission. ## Host environment - Operating system: Linux x86_64 Docker execution plane. - OS/kernel version: Linux container; no guest kernel is involved because this uses linux-user QEMU. - Architecture: x86_64 host running RISC-V linux-user QEMU. - QEMU flavor: qemu-riscv32. - QEMU version: qemu-riscv32 rebuilt from master d49f87606a1c6e15701b26c1b16c5d7e948ffcb for the runtime matrix; current upstream source c513597761d6fc06690b5b7cf10dfb7ab05815d0 was checked separately. - QEMU command line: ```bash qemu-riscv32 -cpu rv32i,h=false,zcd=false,zca=true,zcmt=true,zicsr=true ./target_cm_jt_reserved_mode1.elf qemu-riscv32 -cpu rv32i,h=false,zcd=false,zca=true,zcmt=true,zicsr=true ./target_jvt_readback_reserved_mode1.elf ``` ## Emulated/Virtualized environment - Operating system: statically linked Linux ELF under QEMU linux-user. - OS/kernel version: no guest kernel; the witnesses execute directly in linux-user mode. - Architecture: RISC-V RV32 with Zca and Zcmt enabled. ## Description of problem With Zcmt enabled, writing `jvt = base | 1` is accepted by `csrw`, but the read-back retains `mode=1` and a subsequent `cm.jt` raises an illegal-instruction trap. In this QEMU implementation only mode 0 is implemented. The ratified Zc* specification defines `jvt` as an XLEN-bit WARL register with a 64-byte-aligned base and requires the implemented mode to be 0, so a write of `base|1` must be normalized before it is read or used by `cm.jt`. The baseline control with mode 0 exits 42. The baseline `base|1` plus `cm.jt` target exits 132, and the baseline read-back target observes the unnormalized mode and exits 1. The patched target and read-back witnesses exit 42, while disabling Zcmt continues to reject `cm.jt` with exit 132. The root cause is in `target/riscv/tcg/csr.c`: `write_jvt()` stores the raw value into `env->jvt`. The `cm.jt` helper in `target/riscv/tcg/zce_helper.c` reads `JVT_MODE` and raises `RISCV_EXCP_ILLEGAL_INST` for any non-zero mode, so the raw reserved mode is retained instead of being normalized by the WARL write. The minimal fix is `env->jvt = val & JVT_BASE;` in `write_jvt()`. `JVT_BASE` clears the low bits, preserves the aligned base, and forces the only implemented mode to 0. The fix is limited to the CSR write path. ## Steps to reproduce 1. Build static RV32 Linux witnesses for a mode-0 control, a `csrw jvt,base|1` followed by `cm.jt` target, and a `csrw jvt,base|1` read-back target. 2. Run the control and targets with `qemu-riscv32 -cpu rv32i,h=false,zcd=false,zca=true,zcmt=true,zicsr=true`. 3. The baseline control exits 42, the `base|1` plus `cm.jt` target exits 132, and the read-back target exits 1; the expected result for the targets is successful normalized operation with exit 42. 4. Repeat the target with `zcmt=false`; it must remain rejected with exit 132. ## Additional information The runtime witnesses and patched matrix were rebuilt and rerun on master d49f87606a1c6e15701b26c1b16c5d7e948ffcb. Source review against current upstream c513597761d6fc06690b5b7cf10dfb7ab05815d0 still finds `write_jvt()` storing the raw value, and the proposed patch applies cleanly there. I am not claiming a fresh runtime matrix for c513597761d6fc06690b5b7cf10dfb7ab05815d0. The specification reference is https://docs.riscv.org/reference/isa/v20260120/unpriv/zc.html. A read-only search of the QEMU GitLab issue tracker on 2026-09-03 found no matching issue for `zcmt jvt`, `cm.jt`, or `jvt WARL`. This report has no security implications and does not require confidential handling. The related patch will be sent to qemu-devel according to QEMU's patch submission workflow; it is intentionally not attached to this issue.