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 and qemu-riscv64 rebuilt from master d49f87606a1c6e15701b26c1b16c5d7e948ffcb for the runtime matrix; current upstream source c513597761d6fc06690b5b7cf10dfb7ab05815d0 was checked separately. - QEMU command line: ```bash qemu-riscv32 -cpu max,zalasr=true ./lb-aqrl-rd0.elf qemu-riscv64 -cpu max,zalasr=true ./lb-aqrl-rd0.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 `lb.aq`, `lh.aq`, and `lw.aq`; RISC-V RV64 for those forms and `ld.aq`. ## Description of problem With ZALASR enabled, legal load-acquire instructions whose destination is `rd=x0` raise a guest illegal-instruction signal instead of retiring and discarding the loaded value. The affected forms are `lb.aq`, `lh.aq`, and `lw.aq` on RV32, plus `ld.aq` on RV64. The same instructions with `rd=t0` retire normally, and ordinary base-ISA loads to `x0` provide a control showing that a load to `x0` must be accepted. The baseline target witnesses exit 132 three out of three times with `rd=x0`. The patched target witnesses exit 0 three out of three times, while the `rd=t0` controls remain successful. The behavior is inconsistent with the ratified ZALASR specification, which defines these legal load-acquire forms, and with the base-ISA rule that loads targeting `x0` retire while discarding the result. The root cause is in `target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc`: `gen_load_acquire()` obtains the destination with `get_gpr(ctx, a->rd, EXT_NONE)`. For `rd=x0`, that returns the constant-zero TCG value. The subsequent `tcg_gen_qemu_ld_tl()` attempts to write to that constant and the failure surfaces as an illegal-instruction abort in linux-user. The minimal fix is to use `dest_gpr(ctx, a->rd)` in `gen_load_acquire()`. `dest_gpr()` supplies a temporary for `x0`, and the existing `gen_set_gpr()` call then discards the result as required. ## Steps to reproduce 1. Build static RV32 and RV64 Linux witnesses containing `lb.aq`, `lh.aq`, `lw.aq`, and `ld.aq` with `rd=x0`, together with matching `rd=t0` controls. 2. Run `qemu-riscv32 -cpu max,zalasr=true ./lb-aqrl-rd0.elf`; the baseline exits 132, while the expected result is normal retirement with exit 0. 3. Run the matching RV32 `rd=t0` control and the RV64 `rd=x0` witness with `qemu-riscv64 -cpu max,zalasr=true`; the patched result is exit 0 for all forms. 4. Run the corresponding witnesses with the proposed one-line change; all target and control executions complete normally, while the ZALASR-disabled gate continues to reject the instructions. ## Additional information The runtime witnesses and patched matrix were rebuilt and rerun on master d49f87606a1c6e15701b26c1b16c5d7e948ffcb. Source review against current upstream c513597761d6fc06690b5b7cf10dfb7ab05815d0 still finds `get_gpr(ctx, a->rd, EXT_NONE)` in `gen_load_acquire()`, 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/zalasr.html. A read-only search of the QEMU GitLab issue tracker on 2026-09-03 found no matching issue for `zalasr rd0`, `lb.aq x0`, or `zalasr x0`. 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.