The source excerpts below are from QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd`. ## Host environment - Operating system: Linux - OS/kernel version: 6.0 - Architecture: x86 - QEMU flavor: `qemu-system-riscv64` - QEMU version: qemu.git `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` ## Emulated/Virtualized environment - Operating system: Bare-metal RISC-V hypervisor test payload - Architecture: RISC-V - Accelerator: `TCG` - Relevant CPU/device configuration: H extension enabled; write odd values to vsepc with C enabled and disabled ## Description of problem ### Background and terminology RISC-V CSRs commonly contain WARL fields: software may write any value, but the implementation must store and read back a legal value. For an exception program counter, bit zero is not a legal stored instruction address and must read as zero. A reserved multi-bit encoding likewise must not be preserved as if it were implemented. ### Affected code path The affected implementation locations are: `target/riscv/tcg/csr.c: write_vsepc()` The ordinary `mepc` and `sepc` accessors apply `get_xepc_mask()` on read and write. The virtual-supervisor `vsepc` accessors store and return the raw value. ### Current source evidence [target/riscv/tcg/csr.c:5298](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/tcg/csr.c#L5298) ```c 5298 | 5299 | static RISCVException read_vsepc(CPURISCVState *env, int csrno, 5300 | target_ulong *val) 5301 | { 5302 | *val = env->vsepc; 5303 | return RISCV_EXCP_NONE; 5304 | } 5305 | 5306 | static RISCVException write_vsepc(CPURISCVState *env, int csrno, 5307 | target_ulong val, uintptr_t ra) 5308 | { 5309 | env->vsepc = val; 5310 | return RISCV_EXCP_NONE; 5311 | } 5312 | 5313 | static RISCVException read_vscause(CPURISCVState *env, int csrno, ``` [target/riscv/tcg/csr.c:3167](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/tcg/csr.c#L3167) ```c 3167 | 3168 | static RISCVException read_mepc(CPURISCVState *env, int csrno, 3169 | target_ulong *val) 3170 | { 3171 | *val = env->mepc & get_xepc_mask(env); 3172 | return RISCV_EXCP_NONE; 3173 | } 3174 | 3175 | static RISCVException write_mepc(CPURISCVState *env, int csrno, 3176 | target_ulong val, uintptr_t ra) 3177 | { 3178 | env->mepc = val & get_xepc_mask(env); 3179 | return RISCV_EXCP_NONE; 3180 | } 3181 | 3182 | static RISCVException read_mcause(CPURISCVState *env, int csrno, 3183 | target_ulong *val) ``` ### Root cause analysis `write_vsepc()` assigns `val` directly to `env->vsepc`, and `read_vsepc()` returns it unchanged. This differs from the shared xEPC WARL rule already implemented for `mepc` and `sepc`: bit zero is always zero, while the treatment of bit one depends on instruction alignment support. The discrepancy is visible to HS-mode software reading the VS trap state even before any VRET path uses the value. The reasoning, step by step: 1. HS-mode software writes an odd address to `vsepc`. 2. QEMU stores bit zero because the write accessor applies no xEPC mask. 3. A subsequent CSR read returns the illegal low bit instead of the WARL-transformed value. 4. Any later control-flow use must mask or mis-handle a value that should never have been observable in that form. ### Worked example and boundary cases Write vsepc=0x80000001 from HS mode and read it back. Bit zero must read as zero regardless of compressed-instruction support. Treat bit one separately because instruction alignment and read masking have different rules. This isolates the readback contract without assuming that a later return necessarily crashes. ### Conditions needed to reach the problem - The H extension exposes `vsepc`. - Software writes or restores an address with bit zero set. - The TCG CSR implementation is used. ### Expected or potential effect - HS-mode observes inconsistent semantics among mepc, sepc, and vsepc. - Migration or debugging can preserve a value that is not legal architectural xEPC state. ### Expected behavior Writes to vsepc must store bit 0 as zero, matching the xepc WARL rule. ## Steps to reproduce The following validation design covers the expected and current-code results. 1. boot a minimal HS-mode payload under qemu-system-riscv64 with H enabled. 2. Write `vsepc` values with bit 0 set and combinations of bit 1 while toggling C support where configurable. 3. Read back `vsepc`, `sepc`, and `mepc` after equivalent writes. 4. Optionally execute VRET from a controlled trap frame and record the resumed PC. Expected result: vsepc applies the same xEPC low-bit WARL transformation as the other exception program counters. Current behavior: The latest source stores and returns the unmasked value. ## Suggested fix direction Use `get_xepc_mask(env)` in the vsepc read/write accessors, matching `mepc` and `sepc`. Audit VRET and migration so there is one canonical representation rather than masking only at a later consumer. The fix should be covered by the following focused regression checks: - CSR readback with odd values. - Compressed-instruction support on and off for bit-one behavior. - VRET control-flow behavior after an odd write. ## References - QEMU source baseline: https://gitlab.com/qemu-project/qemu/-/commit/ff1d2d19d7e24893e2012d879f8e73077e17b9bd ## Additional information - Source baseline: QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` (checked 2026-09-05).