<!--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/--> [link.ld](/uploads/d9f8ad6490696a5b695a32e265ce3907/link.ld) [minstret_bug.elf](/uploads/e71587200b9d69b7ccb035893417456c/minstret_bug.elf) ## Host environment - Operating system: Linux <!--Windows 10 21H1, Fedora 37, etc.--> - OS/kernel version:22.04.1-Ubuntu <!--For POSIX hosts, use `uname -a`--> - Architecture:x86 <!--x86, ARM, s390x, etc.--> - QEMU flavor:qemu-system-riscv64 <!--qemu-system-x86_64, qemu-aarch64, qemu-img, etc.--> - QEMU version:9.2.0 (v9.2.0) <!--e.g. `qemu-system-x86_64 --version`--> - QEMU command line:./qemu-system-riscv64 -M virt -nographic -bios none -kernel minstret_bug.elf <!--Give the smallest, complete command line that exhibits the problem. </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-x86_64 -M q35 -m 4096 -enable-kvm -hda fedora32.qcow2 </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: - 22.04.1-Ubuntu <!--For POSIX guests, use `uname -a`.--> - Architecture: x86 <!--x86, ARM, s390x, etc.--> ## Description of problem Writing to the `minstret` CSR in M-mode via `csrw minstret, zero` has no effect. The RISC-V Privileged Specification v1.12, Section 3.1.10 states: "The mcycle and minstret CSRs are 64-bit read/write registers." After writing zero and executing 4 nops, csrr reads back 178,470 instead of \~5. Spike (riscv-isa-sim) correctly returns \~5. <!--Describe the problem, including any error/crash messages seen.--> ## Steps to reproduce 1. Build the attached minstret_bug.S with: riscv64-unknown-elf-gcc -nostdlib -nostartfiles -march=rv64gc -mabi=lp64d -T link.ld -o minstret_bug.elf minstret_bug.S 2. Run: qemu-system-riscv64 -M virt -nographic -bios none -kernel minstret_bug.elf -gdb tcp::1234 -S 3. In GDB: set architecture riscv:rv64 target remote :1234 b \*0x80000018 continue info reg a0 4. Observe a0 = 0x2b926 (178470), expected \~5 ## 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.-->