<!--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-1713-gde5d8bfd61) - 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 When `VLE32FF.V` takes a synchronous exception on element 0, QEMU appears to modify the architectural `vl` CSR. The RISC-V Vector specification says that unit-stride fault-only-first loads only take a trap for a synchronous exception on element 0. If element 0 raises an exception, the trap is taken and `vl` is not modified. If an element after element 0 raises an exception, the trap is not taken and `vl` is reduced to the index of the element that would have raised the exception. With the test case below, `vsetvli` first sets `vl = 4`. Then `vle32ff.v` attempts to load element 0 from address `0x1`, which raises a synchronous load access fault in QEMU (`mcause = 5`). Because the exception occurs on element 0, `vl` should remain unchanged. Observed behavior in QEMU: ```text mcause = 5 t2 = 4 a0 = 1 ``` Expected behavior: ```text mcause = 5 t2 = 4 a0 = 4 ``` Here, `t2 = 4` shows that `vsetvli` successfully set `vl = 4`. However, after the element-0 fault, reading `vl` gives `a0 = 1`. This means QEMU shortens `vl` even though the fault occurred on element 0. This appears to be a model/spec-deviation issue in `target/riscv/vector_helper.c`. The fault-only-first path updates `env->vl` too early: ```c if (vl != 0) { env->vl = vl; } ``` If a trap is then taken for element 0, the shortened `vl` has already become architecturally visible. ## Steps to reproduce 1. Build this bare-metal test case: ```asm li t0, 0x1 li t1, 0x4 vsetvli t2, t1, e32, m1, ta, ma vle32ff.v v1, (t0) csrr a0, vl j . ``` 2. Build command used: ```bash riscv64-unknown-elf-gcc \ -march=rv64imafdch_zicfiss_zicbom_zicboz_v_zicsr_zca_zimop_zcmop_zbb_zbs_zkne_zbkb_zabha_zacas_zawrs_zkr_smepmp_zcb_zicond_zba_zknd_zbc_zbkc_zfh_zfbfmin_zfhmin_zfa_zifencei_zvfbfmin_zbkx_zvksed_zvksh_zvknha_zvknhb_zvkg_zvfbfwma_zvbc_zvbb_zvkned_zksed_zksh_zknh_zvkb_zicbop_zicfilp_svinval_zve32f \ -mabi=lp64 \ -mcmodel=medany \ -nostdlib \ -nostartfiles \ -T linker.ld \ code.S machine_to_supervisor.S machine_to_user.S \ -o code.elf ``` 3. Run QEMU with: ```bash qemu-system-riscv64 \ -machine virt \ -m 256M \ -bios none \ -kernel code.elf \ -serial null \ -display none \ -S -s \ -cpu rv64,v=on,smstateen=on,sscofpmf=on,smcsrind=on,sscsrind=on,smaia=on,ssaia=on,ssccfg=on,smcdeleg=on,zicfiss=on,zimop=on,zcmop=on,zaamo=on,zca=on,zbb=on,zbs=on,zkne=on,zbkb=on,zabha=on,zacas=on,zawrs=on,smdbltrp=on,zkr=on,smepmp=on,zcb=on,zicond=on,i=on,m=on,a=on,f=on,d=on,c=on,h=on,zicsr=on,zicbom=on,zicboz=on,zba=on,zknd=on,zbc=on,zbkc=on,zfh=on,zfbfmin=on,zfhmin=on,zfa=on,zifencei=on,zvfbfmin=on,zbkx=on,zvksed=on,zvksh=on,zvknha=on,zvknhb=on,zvkg=on,zvfbfwma=on,zvbc=on,zvbb=on,zvkned=on,zksed=on,zksh=on,zknh=on,zvkb=on,zicbop=on,zicfilp=on,svinval=on,zve32f=on ``` 4. Connect with GDB: ```bash riscv64-unknown-elf-gdb code.elf set pagination off target remote :1234 c Ctrl-C info registers ``` 5. Observe that QEMU reports: ```text mcause = 5 t2 = 4 a0 = 1 ``` Expected result: ```text mcause = 5 t2 = 4 a0 = 4 ``` ## Additional information Specification reference: ```text Unit-stride fault-only-first load instructions execute as a regular load except that they will only take a trap caused by a synchronous exception on element 0. If element 0 raises an exception, vl is not modified, and the trap is taken. If an element > 0 raises an exception, the corresponding trap is not taken, and the vector length vl is reduced to the index of the element that would have raised an exception. ``` Observed behavior: * `vsetvli` sets `vl = 4`, reflected by `t2 = 4`. * `vle32ff.v` faults on element 0. * QEMU takes the trap with `mcause = 5`. * After the trap, `vl` reads back as `1`. Expected behavior: * `vsetvli` sets `vl = 4`. * `vle32ff.v` faults on element 0. * QEMU should take the trap. * `vl` should remain `4`. Suspected source location: * `target/riscv/vector_helper.c` * fault-only-first unit-stride load path Current code appears to update `env->vl` before completing the architecturally visible load behavior: ```c ProbeSuccess: /* load bytes from guest memory */ if (vl != 0) { env->vl = vl; } if (env->vstart < env->vl) { if (vm) { /* Load/store elements in the first page */ if (likely(elems)) { vext_page_ldst_us(env, vd, addr, elems, nf, max_elems, log2_esz, true, mmu_index, ldst_tlb, ldst_host, ra); } /* Load/store elements in the second page */ if (unlikely(env->vstart < env->vl)) { ... elems = env->vl - env->vstart; vext_page_ldst_us(...); } } else { for (i = env->vstart; i < env->vl; i++) { ... ldst_tlb(...); } } } ``` The issue is that `env->vl` can be shortened before the element-0 trap is taken. Since an element-0 exception must leave `vl` unchanged, this shortened value should not become architecturally visible in that case. A possible fix would be to keep the shortened `vl` in a local bound until after all architecturally visible loads have completed, and only write `env->vl` after it is known that the instruction completed without taking an element-0 trap. Possible fix direction: ```c ProbeSuccess: /* * Load bytes from guest memory. When a later element would fault, keep * the new vl in a local bound until all architecturally visible loads * have completed. This prevents an element-0 trap from exposing a * shortened vl, and avoids touching the non-faulting element that caused * the fault-only-first shortening. */ load_vl = vl ? vl : env->vl; if (env->vstart < load_vl) { if (vm) { /* Load/store elements in the first page */ elems = MIN(elems, load_vl - env->vstart); if (likely(elems)) { vext_page_ldst_us(env, vd, addr, elems, nf, max_elems, log2_esz, true, mmu_index, ldst_tlb, ldst_host, ra); } /* Load/store elements in the second page */ if (unlikely(env->vstart < load_vl)) { ... elems = load_vl - env->vstart; vext_page_ldst_us(...); } } else { for (i = env->vstart; i < load_vl; i++) { ... ldst_tlb(...); } } } if (vl != 0) { env->vl = vl; } ``` Real impact: * Severity: Medium. * This corrupts architectural vector state after a fault-only-first vector load traps on element 0. * `vl` is architectural state, so software that inspects vector state after a trap may observe an incorrect vector length. * Fault-only-first loads are intended for vectorizing loops with data-dependent exit conditions, such as scan loops similar to `strlen`. * Software may use `vl` to determine how many elements were successfully processed. * If QEMU incorrectly modifies `vl`, guest software or validation tools may compute the wrong number of processed elements after a trap. * This can cause QEMU to diverge from compliant hardware and weaken emulator-based validation of vector fault-only-first semantics. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->