<!--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: AlmaLinux 9.7 - OS/kernel version: <!--For POSIX hosts, use `uname -a`--> - Architecture: Linux 5.14.0-611.45.1.el9_7.x86_64 * QEMU flavor: qemu-system-riscv64 - QEMU version: 11.0.2 - QEMU command line: <!--Give the smallest, complete command line that exhibits the problem. </li> </ul> </li> </ul> <p data-sourcepos="39:1-40:62">If you are using libvirt, virsh, or vmm, you can likely find the QEMU command line arguments in /var/log/libvirt/qemu/$GUEST.log.--&gt;</p> <pre data-sourcepos="42:3-44:5"><code>qemu-system-riscv64 -nographic -semihosting -icount shift=1 -machine virt -cpu max,pmu-mask=0xfffffff8 -bios S_scsr-00.elf </code></pre> <h2 id="user-content-emulatedvirtualized-environment" data-sourcepos="46:1-46:35">Emulated/Virtualized environment<a href="#emulatedvirtualized-environment" aria-label="Link to heading 'Emulated/Virtualized environment'" data-heading-content="Emulated/Virtualized environment" class="anchor"></a></h2> <ul data-sourcepos="48:1-56:28"> <li data-sourcepos="48:1-50:41"> <p data-sourcepos="48:3-48:19">Operating system:</p> <!--Windows 10 21H1, Fedora 37, etc.--> - OS/kernel version: <!--For POSIX guests, use `uname -a`.--> - Architecture: <!--x86, ARM, s390x, etc.--> ## Description of problem QEMU does not write a 1 to sie.LCOFIE (sie\[13\]). It claims to support Sscofpmf, so this bit should be writable. The same root bug affects sip, and presumably mie and mip. The test program prints an error showing a 222 instead of the expected 2222 in sie. ``` This log file generated by running: qemu-system-riscv64 -nographic -semihosting -icount shift=1 -machine virt -cpu max,pmu-mask=0xfffffff8 -bios /home/harris/cvw/addins/riscv-arch-test-dh/work/qemu-rv64-max/elfs/priv/S/S_scsr-00.elf RVCP-SUMMARY: TEST FAILED - Test File "S_scsr-00.S" RVCP: DEBUG INFORMATION FOLLOWS RVCP: Test Info: "test: 241; cg: S_scsr_cg; cp: cp_scsr_access; bin: sie_csrrw1" RVCP: Instruction: 0x10461073 RVCP: Approximate address (failure may be slightly after this): 0x0000000080000150 RVCP: Register: x11 RVCP: Bad Value: 0x0000000000000222 RVCP: Expected Value: 0x0000000000002222 RVCP: END OF DEBUG INFORMATION ``` According to Claude, the error was introduced in csr.c on May 13 2026 ``` The cause is in the v11.0.2 source at /opt/riscv/qemu: stable-branch cherry-pick ("target/riscv: Update the local interrupt mask", upstream , May 13 2026) changed LOCAL_INTERRUPTS from ~0x1FFF to ~0xFFFF in target/riscv/csr.c:1774. That macro was aimed at AIA mvien/hvien virtual-interrupt filtering, but it also feeds all_ints, the write mask for mie/mip — so the change collaterally made mie.LCOFIE unwritable, breaking Sscofpmf entirely (overflow interrupts can never be enabled). It's internally inconsistent too: delegable_ints still includes MIP_LCOFIP, which is why mideleg[13] remains writable. I verified the older locally-built v11.0.0 (/home/harris/qemu11/bin/qemu-system-riscv64) returns sie = 0x2222 and passes this check — the failure appeared with the July 2 QEMU upgrade in /opt/riscv. ``` \`\`\` ## Steps to reproduce 1. 2. 3. ## Additional information <!--Attach logs, stack traces, screenshots, etc. Compress the files if necessary. If using libvirt, libvirt logs and XML domain information may be relevant.--> <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->