<!--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 6.17.0-35-generic - OS/kernel version: Linux centos7 6.6.87.2-microsoft-standard-WSL2 #1 - 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:1-52:3"><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_sade_no_hwad.elf </code></pre> <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 The IOMMU model does not advertise hardware A/D-bit update support (capabilities.AMO_HWAD, bit 24, is 0) and has no concept of that capability at all. Despite this, a valid Device Context that sets DC.tc.SADE (Supervisor Access Dirty Enable) or DC.tc.GADE (Guest Access Dirty Enable) is accepted, and transactions translate normally. Per the RISC-V IOMMU specification, when capabilities.AMO_HWAD is 0 a valid DC that sets SADE or GADE is misconfigured, and transactions from the device must be terminated with CAUSE = 259 (DDT entry misconfigured). ## Steps to reproduce 1. [iommu_dc_sade_no_hwad.c](/uploads/04b61fb8936a393edb96bf4f4470279f/iommu_dc_sade_no_hwad.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_dc_sade_no_hwad.elf](/uploads/1822788cad90515adec85045cf08fe8e/iommu_dc_sade_no_hwad.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_sade_no_hwad.elf ``` ## Additional information The guest program (`tests/iommu_dc_sade_no_hwad.c`): 1. Reads the capabilities register and confirms bit 24 (AMO_HWAD) is 0. 2. Registers an otherwise-correct DC with DC.tc.SADE = 1 (G-stage Sv39x4, VS-stage Sv39, PDT = Bare, MSI Flat). 3. Programs valid VS-stage and G-stage page tables and issues two EDU DMA transfers (RAM -\> EDU internal buffer -\> RAM) using guest virtual addresses. ## Expected behaviour (per spec) The first translation should fail. The transaction should be terminated and a fault record with CAUSE = 259 (DDT entry misconfigured) written to the fault queue. Spec references: - RISC-V IOMMU Architecture Specification, Section 3.1.3 (Translation-control fields): "The IOMMU supports the 1 setting of GADE and SADE bits if capabilities.AMO_HWAD is 1. When capabilities.AMO_HWAD is 0, these bits are reserved." - RISC-V IOMMU Architecture Specification, Section 3.1.4 (Device-context configuration checks), condition 18: a DC with DC.tc.V=1 is misconfigured when "capabilities.AMO_HWAD is 0 and DC.tc.SADE or DC.tc.GADE is 1"; in that case the IOMMU must "stop and report "DDT entry misconfigured" (cause = 259)." ## Observed behaviour ``` capabilities = 0x00000078E2CF4F10 capabilities.AMO_HWAD (bit 24) = 0x00000000 ... DC.tc = 0x0000000000000101 (SADE bit 8 = 0x00000001) ... Result DMA moved data (buffers match) : YES Any fault logged (FQT != FQH) : NO BUG: DC.tc.SADE=1 accepted while AMO_HWAD=0. No CAUSE 259 fault; translation succeeded and DMA completed. ``` ## Root cause In `hw/riscv/riscv-iommu.c` (master, commit de5d8bfd61): - There is no `RISCV_IOMMU_CAP_AMO_HWAD` bit defined in `hw/riscv/riscv-iommu-bits.h`. Bit 24 is an unused gap between `RISCV_IOMMU_CAP_MSI_MRIF` (bit 23) and `RISCV_IOMMU_CAP_ATS` (bit 25), so capabilities.AMO_HWAD is always 0. - `riscv_iommu_validate_device_ctx()` performs no check involving DC.tc.GADE / DC.tc.SADE against any capability. - During translation, `riscv_iommu_spa_fetch()` uses SADE/GADE directly to decide whether to perform a hardware A/D update (line 417): ```c ctx->tc & (pass ? RISCV_IOMMU_DC_TC_GADE : RISCV_IOMMU_DC_TC_SADE); ``` This is done unconditionally. ## Notes - The test sets SADE. GADE goes through the same code path with the same missing check, so a DC with GADE = 1 and AMO_HWAD = 0 is expected to be accepted as well. - This test uses page-table entries that already have A = 1 and D = 1, so the observable here is only the missing configuration check (no fault). The model also performs hardware A/D updates whenever SADE/GADE are set regardless of AMO_HWAD; that path would be exercised by clearing A/D in the PTEs. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->