<!--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: Linux x86_64 - OS/kernel version: Linux centos7 6.6.87.2-microsoft-standard-WSL2 - Architecture: x86 - QEMU flavor: qemu-system-riscv64 - QEMU version: v11.0.0-1713-gde5d8bfd61\`, reported version 11.0.50 - 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-51:5"><code>qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_dma \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_g_stage_pte_u0.elf </code></pre> <h2 id="user-content-emulatedvirtualized-environment" data-sourcepos="53:1-53: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="55:1-63:28"> <li data-sourcepos="55:1-57:41"> <p data-sourcepos="55:3-55: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 The IOMMU translation walk does not check the U bit in second-stage (G-stage) leaf PTEs. A G-stage leaf PTE with U = 0 is accepted, the address translates correctly, and the DMA completes with no fault. ## Steps to reproduce 1. [iommu_g_stage_pte_u0.c](/uploads/11b896665185c48b45e8b731095417e2/iommu_g_stage_pte_u0.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_g_stage_pte_u0.elf](/uploads/a74b3e300ea24dd794052526518bfda4/iommu_g_stage_pte_u0.elf) ``` qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_dma \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_g_stage_pte_u0.elf ``` ## Additional information The guest program (`tests/iommu_g_stage_pte_u0.c`): 1. Registers a DC (G-stage Sv39x4, VS-stage Sv39) and builds a correct two-stage mapping for the source and destination buffers. 2. Keeps the VS-stage (first-stage) leaf PTEs at U = 1, and sets the G-stage (second-stage) leaf PTEs to U = 0. 3. Issues EDU DMA (RAM -\> EDU -\> RAM). ## Expected behaviour (per spec) Each access through a G-stage leaf PTE with U = 0 must raise a guest page fault; no data should be moved. Spec references: - RISC-V IOMMU Architecture Specification, Section 3.3 (Process to translate an IOVA): "When checking the U bit in a second-stage PTE, the transaction is treated as not requesting supervisor privilege." - RISC-V Privileged Specification: Section 22.5.1 when checking the U bit, the current privilege mode is always taken to be U-mode; and. ## Observed behaviour ``` src: VS-stage leaf U=1, G-stage leaf U=0 (G-stage PTE=0x00000000200248CF) DMA: RAM to EDU internal buffer DMA: EDU internal buffer to RAM Result DMA moved data (buffers match) : YES Any fault logged : NO BUG: G-stage leaf PTE with U=0 was accepted. No guest page fault; translation succeeded and DMA completed. ``` QEMU `riscv_iommu_dma` trace (translation succeeds despite G-stage U = 0): ``` riscv_iommu_dma (null): translate 0000:01.0 #0 RO 0x100000 -> 0x80092000 riscv_iommu_dma (null): translate 0000:01.0 #0 WR 0x200000 -> 0x80093000 ``` Both accesses translate to the correct SPA, the buffers match, and the fault queue is empty. ## Root cause In `hw/riscv/riscv-iommu.c`, `riscv_iommu_spa_fetch()` leaf-PTE check chain (master, around lines 469-487) checks V, the R/W/X combination, PPN alignment, R/W permission, and A/D, then completes the translation. It never examines `PTE_U` for the second stage, and does not apply the unconditional non-supervisor check required for G-stage U-bit checks. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->