<!--This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, please consult https://www.qemu.org/contribute/security-process/--> ## Host environment - Operating system: Ubuntu 24.04.4 LTS - OS/kernel version: Linux aster-MS-7D31 6.17.0-35-generic #35\~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 19:30:42 UTC 2 x86_64 x86_64 x86_64 GNU/Linux - Architecture: x86_64 - QEMU flavor: qemu-system-riscv64 - QEMU version: QEMU emulator version 11.0.50 (v11.0.0-2337-g60533c6193) Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers - QEMU command line: <!--Give the smallest, complete command line that exhibits the problem. If you are using libvirt, virsh, or vmm, you can likely find the QEMU command line arguments in /var/log/libvirt/qemu/$GUEST.log.--> ``` ./qemu-system-x86_64 -M q35 -m 4096 -enable-kvm -hda fedora32.qcow2 ``` ## Emulated/Virtualized environment - Operating system: <!--Windows 10 21H1, Fedora 37, etc.--> - OS/kernel version: <!--For POSIX guests, use `uname -a`.--> - Architecture: <!--x86, ARM, s390x, etc.--> ## Description of problem Several Svinval-related instructions executed in Virtual User mode should raise a virtual-instruction exception, but QEMU raises an illegal-instruction exception instead. The affected instructions tested are: ```text HINVAL.GVMA SINVAL.VMA SFENCE.INVAL.IR SFENCE.W.INVAL ``` The RISC-V privileged specification requires these cases to raise a virtual-instruction exception in VU-mode. In particular: ```text An attempt to execute HINVAL.VVMA or HINVAL.GVMA in VS-mode or VU-mode, or to execute SINVAL.VMA in VU-mode, raises a virtual-instruction exception. ``` and: ```text Attempting to execute SFENCE.W.INVAL or SFENCE.INVAL.IR in U-mode raises an illegal-instruction exception. Doing so in VU-mode raises a virtual-instruction exception. ``` With the test cases below, the hart is switched from Machine mode into Virtual User mode before executing each instruction. Expected behavior: ```text mcause = 0x16 ``` Observed behavior in QEMU: ```text mcause = 0x2 ``` This means QEMU treats these VU-mode executions as ordinary U-mode illegal instructions instead of reporting the architecturally required virtual-instruction exception. ## Steps to reproduce 1. Build and run the following bare-metal test cases. ```asm call machine_to_virtual_user hinval.gvma x0, x0 # expected mcause = 0x16 ``` ```asm call machine_to_virtual_user sinval.vma x0, x0 # expected mcause = 0x16 ``` ```asm call machine_to_virtual_user sfence.inval.ir # expected mcause = 0x16 ``` ```asm call machine_to_virtual_user sfence.w.inval # expected mcause = 0x16 ``` 2. Build command used: ```bash riscv64-unknown-elf-gcc \ -march=rv64imafdcvh_zicsr_svinval \ -mabi=lp64 \ -mcmodel=medany \ -nostdlib \ -nostartfiles \ -T linker.ld \ code.S machine_to_virtual.S machine_to_virtual_user.S \ -o code.elf ``` The actual local test harness used a longer `-march` string with additional extensions enabled, but the relevant requirements for these tests are the Hypervisor extension and Svinval. 3. Run QEMU with: ```bash qemu-system-riscv64 \ -machine virt \ -m 256M \ -bios none \ -kernel code.elf \ -serial null \ -display none \ -S -s \ -accel tcg \ -cpu rv64,h=on,svinval=on ``` 4. Connect with GDB: ```bash riscv64-unknown-elf-gdb code.elf set pagination off target remote :1234 c Ctrl-C info registers ``` 5. Observed results: ```text call machine_to_virtual_user hinval.gvma x0, x0 priv = 0x4 mcause = 0x2 ``` ```text call machine_to_virtual_user sinval.vma x0, x0 priv = 0x4 mcause = 0x2 ``` ```text call machine_to_virtual_user sfence.inval.ir priv = 0x4 mcause = 0x2 ``` ```text call machine_to_virtual_user sfence.w.inval priv = 0x4 mcause = 0x2 ``` Expected result for each case: ```text mcause = 0x16 ``` In this GDB/QEMU output, `priv = 0x4` corresponds to Virtual User mode. ## Additional information The bare-metal test starts in Machine mode. The helper `machine_to_virtual_user` is part of the test harness. It first switches from M-mode to HS-mode, then uses `hstatus.SPV = 1` and `sret` to enter VU-mode. I verified the helper independently using a VU-mode probe: ```asm call machine_to_virtual_user csrr a0, sstatus ``` This correctly raises a virtual-instruction exception: ```text priv = 0x4 mcause = 0x16 ``` So the tested instructions are executed in VU-mode as intended. <details> <summary>Virtual User mode helper code</summary> ```asm .globl machine_to_virtual_user machine_to_virtual_user: /* Disable guest-stage and VS-stage translation */ csrw hgatp, zero csrw vsatp, zero /* Make sure MRET goes to HS-mode first, not virtual mode */ li t6, 1 << 39 /* mstatus.MPV */ csrrc x0, mstatus, t6 /* Clear MPP */ li t6, 3 << 11 csrrc x0, mstatus, t6 /* Set MPP = S */ li t6, 1 << 11 csrrs x0, mstatus, t6 /* Clear TSR, so SRET is allowed in HS */ li t6, 1 << 22 csrrc x0, mstatus, t6 la t6, hs_to_vu csrw mepc, t6 li t6, 0 mret hs_to_vu: /* Now we are in HS-mode, V=0 */ /* hstatus.SPV = 1, so SRET returns to virtual mode */ li t6, 1 << 7 csrrs x0, hstatus, t6 /* sstatus.SPP = 0, so target nominal mode is U -> VU-mode */ li t6, 1 << 8 csrrc x0, sstatus, t6 la t6, branch_virtual_user csrw sepc, t6 li t6, 0 sret branch_virtual_user: ret ``` </details> The issue appears to be in the Svinval translation path: ```text target/riscv/insn_trans/trans_svinval.c.inc ``` The relevant handlers use the current privilege level check to reject `PRV_U`, but do not distinguish normal U-mode from VU-mode. For example: ```c #define REQUIRE_PRIV_MS(ctx) do { \ if (ctx->priv == PRV_U) { \ return false; \ } \ } while (0) ``` This is correct for normal U-mode, where an illegal-instruction exception is expected. However, in VU-mode, `ctx->priv == PRV_U` while virtualization is also enabled. In that case, the specification requires a virtual-instruction exception, not an illegal-instruction exception. For example, the current `HINVAL.GVMA` path is: ```c static bool trans_hinval_gvma(DisasContext *ctx, arg_hinval_gvma *a) { REQUIRE_SVINVAL(ctx); /* Do the same as hfence.gvma currently */ REQUIRE_EXT(ctx, RVH); REQUIRE_PRIV_MS(ctx); #ifndef CONFIG_USER_ONLY decode_save_opc(ctx, 0); gen_helper_hyp_gvma_tlb_flush(tcg_env); return true; #endif return false; } ``` Similarly, `SINVAL.VMA`, `SFENCE.INVAL.IR`, and `SFENCE.W.INVAL` go through privilege checks that reject `PRV_U` without setting the virtual-instruction exception path for VU-mode. A possible fix direction is to handle `ctx->virt_enabled` before the generic U-mode rejection. For example: ```c static bool require_priv_ms_or_vu_virtual(DisasContext *ctx) { if (ctx->priv == PRV_U) { if (ctx->virt_enabled) { ctx->virt_inst_excp = true; } return false; } return true; } ``` Then the affected Svinval instruction handlers could use this shared check instead of a plain `REQUIRE_PRIV_MS(ctx)`. For example: ```c static bool trans_hinval_gvma(DisasContext *ctx, arg_hinval_gvma *a) { REQUIRE_SVINVAL(ctx); REQUIRE_EXT(ctx, RVH); if (!require_priv_ms_or_vu_virtual(ctx)) { return false; } #ifndef CONFIG_USER_ONLY decode_save_opc(ctx, 0); gen_helper_hyp_gvma_tlb_flush(tcg_env); return true; #endif return false; } ``` and similarly for: ```text trans_sinval_vma() trans_sfence_inval_ir() trans_sfence_w_inval() ``` Real impact: * This is not a direct host-security vulnerability. * However, it is an architectural correctness issue in the RISC-V virtualization behavior. * Conformance tests expecting `mcause = 0x16` for these VU-mode instructions fail under QEMU. * Hypervisor or guest test code may observe an illegal-instruction exception where real hardware should report a virtual-instruction exception. * This can cause guest trap handling, hypervisor diagnostics, or emulator-vs-hardware comparison results to diverge from the RISC-V privileged specification. * The problem is especially visible for test frameworks that validate trap causes precisely, since `mcause = 0x2` and `mcause = 0x16` have different architectural meanings. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->