<!--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 - OS/kernel version: Linux centos7 6.6.87.2-microsoft-standard-WSL2 - Architecture: x86_64 - 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-52: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_dc_iohgatp_align.elf <p data-sourcepos="52:1-52:13"></code></pre></p> <h2 id="user-content-emulatedvirtualized-environment" data-sourcepos="54:1-54: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="56:1-64:28"> <li data-sourcepos="56:1-58:41"> <p data-sourcepos="56:3-56: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 For the Sv39x4 / Sv48x4 / Sv57x4 G-stage schemes the root page table is 16 KiB and its base (DC.iohgatp.PPN) must be aligned to a 16 KiB boundary (the low 2 bits of the PPN must be zero). The IOMMU model does not check this. A valid DC with iohgatp.MODE != Bare and a 16 KiB-misaligned iohgatp.PPN is accepted, and G-stage translation proceeds using the misaligned root base. Per the RISC-V IOMMU specification a valid DC with a non-Bare iohgatp whose PPN is not aligned to the size of the G-stage root page table is misconfigured, and transactions must be terminated with CAUSE = 259 (DDT entry misconfigured). ## Steps to reproduce 1. [iommu_dc_iohgatp_align.c](/uploads/5c085ccb03ba2a9ebc8b8a59c473aac2/iommu_dc_iohgatp_align.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib`. 3. [iommu_dc_iohgatp_align.elf](/uploads/bafd3f3f92344b6154399ab5968edeb0/iommu_dc_iohgatp_align.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_dc_iohgatp_align.elf ``` ## Additional information he guest program (`tests/iommu_dc_iohgatp_align.c`): 1. Registers a correct DC (G-stage Sv39x4, VS-stage Sv39) and builds valid two-stage mappings for the source and destination buffers. The G-stage root is allocated 16 KiB-aligned, so iohgatp.PPN low 2 bits are 0. 2. Copies the root's first 4 KiB sub-page (entries 0..511) into the second 4 KiB sub-page (entries 512..1023). Every GPA used by the test has a G-stage root index below 512, so a walk that begins one 4 KiB page into the root still finds the correct level-2 pointers. 3. Sets iohgatp.PPN |= 1, so the root base is 4 KiB past the 16 KiB-aligned start (no longer 16 KiB-aligned), and runs EDU DMA in both directions. The sub-page copy means the test does not depend on whether the model uses the misaligned base directly or masks the low PPN bits: in either case a correct implementation must reject the DC before translating. The observable is simply whether CAUSE 259 is raised. ## Expected behaviour (per spec) The transaction should be terminated with a fault record of CAUSE = 259 (DDT entry misconfigured); no data should be moved. Spec references: - RISC-V IOMMU Architecture Specification, Section 3.1.3 (iohgatp field): "The root page table as determined by iohgatp.PPN is 16 KiB and must be aligned to a 16-KiB boundary." - RISC-V IOMMU Architecture Specification, Section 3.1.4 (Device-context configuration checks), condition 17: "DC.iohgatp.MODE is not Bare and the root page table determined by DC.iohgatp.PPN is not aligned to a 16-KiB boundary." is one of the conditions that make a DC with DC.tc.V=1 misconfigured; in that case the IOMMU must "stop and report "DDT entry misconfigured" (cause = 259)." ## Observed behaviour ``` iohgatp.PPN = 0x000000000008009C root_addr = 0x000000008009C000 PPN low2 = 0x00000000 iohgatp.PPN after misalign = 0x000000000008009D PPN low2 = 0x00000001 (not 16 KiB-aligned) ... Result DMA moved data (buffers match) : YES Any fault logged : NO BUG: misaligned (non-16 KiB) iohgatp.PPN was accepted. G-stage translation used the misaligned root and DMA completed; no CAUSE 259. ``` QEMU `riscv_iommu_dma` trace (both translations succeed with the misaligned root): ``` riscv_iommu_dma (null): translate 0000:01.0 #0 RO 0x100000 -> 0x80092000 riscv_iommu_dma (null): translate 0000:01.0 #0 WR 0x200000 -> 0x80093000 ``` ## Root cause In `hw/riscv/riscv-iommu.c` (master, commit de5d8bfd61): - `riscv_iommu_validate_device_ctx()` performs no alignment check on iohgatp.PPN. - In `riscv_iommu_spa_fetch()` the G-stage root base is computed directly from the PPN field with no masking or alignment check (line 403): ```c gatp = PPN_PHYS(get_field(ctx->gatp, RISCV_IOMMU_ATP_PPN_FIELD)); ... base = en_g ? gatp : satp; ``` `PPN_PHYS(x)` is `x << 12`, and `RISCV_IOMMU_ATP_PPN_FIELD` includes the low 2 bits, so a 16 KiB-misaligned PPN is used as-is as the root base. There is no check that the low 2 bits are zero for the Sv\*x4 modes. ## Notes - The 16 KiB root (the "x4" widening) applies to the G-stage schemes (Sv39x4/Sv48x4/Sv57x4). <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->