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 and qemu-riscv64. - QEMU version: qemu-riscv32 11.0.90 built from 5ef0ecc5942ee07bb581cc96a97bbfc0fdf4005c for the runtime matrix; current upstream source c513597761d6fc06690b5b7cf10dfb7ab05815d0 was checked separately. - QEMU command line: ```bash qemu-riscv32 -cpu rv32,xmipscmov=true ./xmipscmov.elf qemu-riscv32 -cpu rv32,xmipscbop=true ./xmips-pref.elf qemu-riscv32 -cpu rv32,xmipslsp=true ./xmips-lwp.elf qemu-riscv32 -cpu rv32,xmipslsp=true ./xmips-swp.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 for the affected cases and RV64 for the positive controls. ## Description of problem `target/riscv/xmips.decode` classifies `ccmov`, `pref`, `lwp`, and `swp` under the RV64 MIPS Extension, but their translators do not enforce the XLEN requirement. As a result, an RV32 CPU accepts these encodings when the corresponding Xmips property is enabled, even though they must remain illegal on RV32. The affected encodings are `0x3e53340b` (`ccmov s0, t1, t0, t2`), `0x0002800b` (`pref 0(t0), 0`), `0x4812c40b` (RV64-only `lwp` pair-load form), and `0x4882d08b` (RV64-only `swp` pair-store form). The `ccmov` witness checks that `s0` receives the expected value, the `pref` witness checks that a sentinel remains unchanged, and the pair-load/store witnesses check the two-word data path. With the corresponding extension disabled, the RV32 witnesses exit 132 as expected. With the extension enabled, the baseline RV32 build exits 0 for all four witnesses; the expected result is exit 132 because the encodings are RV64-only. A patched build changes the four RV32-enabled cases to exit 132 and keeps the RV64-enabled controls at exit 0. The root cause is the missing `REQUIRE_64_OR_128BIT(ctx)` in `trans_ccmov()`, `trans_lwp()`, `trans_swp()`, and `trans_pref()` in `target/riscv/tcg/insn_trans/trans_xmips.c.inc`. The sibling `trans_ldp()` and `trans_sdp()` functions already use this gate. The minimal fix is to add `REQUIRE_64_OR_128BIT(ctx);` to those four translators. This is a legality-only fix and does not claim to validate other Xmips functional semantics. ## Steps to reproduce 1. Build the four static RV32 Linux witnesses with a RISC-V cross compiler; each witness contains the raw instruction word listed above and exits 0 only when the instruction retires with the expected architectural effect. 2. Run `qemu-riscv32 -cpu rv32,xmipscmov=true ./xmipscmov.elf`; the baseline exits 0, while the expected result is exit 132. 3. Repeat with `qemu-riscv32 -cpu rv32,xmipscbop=true ./xmips-pref.elf`, `qemu-riscv32 -cpu rv32,xmipslsp=true ./xmips-lwp.elf`, and `qemu-riscv32 -cpu rv32,xmipslsp=true ./xmips-swp.elf`; each baseline run exits 0 although the expected result is exit 132. 4. Run the same instruction families with the corresponding property disabled to observe the expected exit 132, and run the RV64 controls with the property enabled to observe exit 0. ## Additional information The runtime matrix was collected from a clean upstream QEMU build at 5ef0ecc5942ee07bb581cc96a97bbfc0fdf4005c. Source review against current upstream c513597761d6fc06690b5b7cf10dfb7ab05815d0 still finds the four missing XLEN gates, and the proposed patch applies cleanly there. I am not claiming a fresh runtime matrix for c513597761d6fc06690b5b7cf10dfb7ab05815d0. A read-only search of the QEMU GitLab issue tracker on 2026-09-03 found no matching issue for `xmips`, `ccmov`, `xmipscmov`, `xmipscbop`, `xmipslsp`, `lwp`, or `swp`. 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.