<!--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> <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_flt \ -trace riscv_iommu_dma \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_dc_fault_record.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 When a transaction faults during the DDT walk (e.g. "DDT entry not valid"), the fault record is filled with a hardcoded transaction type of UADDR_RD (read) and with iotval = iotval2 = 0. As a result: - a write transaction that faults at the DDT level is reported as a read, and - the faulting IOVA is not recorded (iotval = 0). The CAUSE and DID are correct. ## Steps to reproduce 1. [iommu_dc_fault_record.c](/uploads/bb570ebe29c57d3c20afaa6af280a39c/iommu_dc_fault_record.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_dc_fault_record.elf](/uploads/02bbd207562d2c08e280a18e1901a893/iommu_dc_fault_record.elf) ``` qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_flt \ -trace riscv_iommu_dma \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_dc_fault_record.elf ``` ## Additional information The guest program (`tests/iommu_dc_fault_record.c`): 1. Enables the IOMMU with a 3-level DDT but does NOT register a DC for the EDU device. 2. Issues an EDU -\> RAM (write) DMA to IOVA 0x200000. The DDT walk finds an invalid entry, producing a "DDT entry not valid" fault. 3. Reads and validates the fault record. ## Expected behaviour (per spec) For a write that faults at the DDT level, the fault record TTYP should be UADDR_WR (write), and the faulting IOVA should be recorded in iotval. Spec references: - RISC-V IOMMU Architecture Specification, Section 4.2, Table 14, Fault record TTYP field encodings: "2 Untranslated read transaction" and "3 Untranslated write/AMO transaction". - RISC-V IOMMU Architecture Specification, Section 4.2: "If the TTYP is a transaction with an IOVA, the IOVA is reported in iotval." ## Observed behaviour ``` Device ID = 0x00000008 (no DC registered) Write IOVA = 0x0000000000200000 DMA: EDU to RAM (gva 0x200000), WRITE, expect DDT fault Fault record CAUSE = 0x00000102 (DDT entry not valid) TTYP = 0x00000002 (read) DID = 0x00000008 PV = 0x00000001 iotval = 0x0000000000000000 iotval2 = 0x0000000000000000 Transaction was a WRITE to IOVA 0x0000000000200000 Findings TTYP reports READ for a WRITE transaction (hardcoded UADDR_RD). iotval = 0: the faulting IOVA is not recorded. (DID = 0x00000008, CAUSE = 0x00000102 are set.) ``` `riscv_iommu_dma` and `riscv_iommu_flt` traces (the transaction is a write to 0x200000, but the fault reports iova 0x0): ``` riscv_iommu_dma (null): translate 0000:01.0 #0 WR 0x200000 -> 0x0 riscv_iommu_flt (null): fault 0000:01.0 reason: 0x80900000102 iova: 0x0 ``` So TTYP = read for a write transaction, and iotval = 0. ## Root cause In `hw/riscv/riscv-iommu.c`, `riscv_iommu_ctx()` reports a DDT fault with a fixed transaction type and zero address operands: ```c riscv_iommu_report_fault(s, ctx, RISCV_IOMMU_FQ_TTYPE_UADDR_RD, fault, !!process_id, 0, 0); ``` `RISCV_IOMMU_FQ_TTYPE_UADDR_RD` is passed unconditionally, so the transaction type is always reported as a read regardless of the actual access. `iotval` and `iotval2` are passed as 0, so the faulting IOVA is not recorded. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->