<!--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 - 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-50:5"><code>qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_g_stage_perm_read_ttype.elf </code></pre> <h2 id="user-content-emulatedvirtualized-environment" data-sourcepos="52:1-52: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="54:1-62:28"> <li data-sourcepos="54:1-56:41"> <p data-sourcepos="54:3-54: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 In a two-stage translation, a read transaction that faults during the second-stage (G-stage) walk is recorded in the fault record with a write access type: CAUSE is 23 (Write/AMO guest-page fault) and TTYP is 3 (Untranslated write/AMO transaction). The transaction is a read, so the record must report CAUSE 21 (Read guest-page fault) and TTYP 2 (Untranslated read transaction). The model overwrites the transaction's access permission with the first-stage leaf PTE's R/W bits before the second-stage walk, so the second-stage fault reports the permission of the page-table entry instead of the read/write type of the transaction. ## Steps to reproduce 1. [iommu_g_stage_perm_read_ttype.c](/uploads/2d504c91ee240df3ebcc6f3a90ba38ab/iommu_g_stage_perm_read_ttype.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_g_stage_perm_read_ttype.elf](/uploads/13fd800f7b4ea1ca806a3df9b66e262a/iommu_g_stage_perm_read_ttype.elf) ``` qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios iommu_g_stage_perm_read_ttype.elf ``` ## Additional information The guest program (`tests/iommu_g_stage_perm_read_ttype.c`): 1. Enables the IOMMU and the fault queue, and installs a device context with two-stage translation (iohgatp Sv39x4, iosatp Sv39). 2. Maps a guest virtual address with a normal VS-stage leaf (R=1, W=1, X=1). 3. Maps the corresponding guest physical address with a G-stage leaf that has an invalid permission encoding (R=0, W=1, X=0), which faults. 4. Issues a read DMA (device reads from RAM into the EDU device). 5. Reads the CAUSE and TTYP fields of the resulting fault record. ## Expected behaviour (per spec) The faulting transaction is a read, so the fault record must report a read access type: CAUSE = 21 (Read guest-page fault) and TTYP = 2 (Untranslated read transaction). Spec references: - RISC-V IOMMU Architecture Specification, fault-record CAUSE values: "21 Read guest-page fault", "23 Write/AMO guest-page fault". - RISC-V IOMMU Architecture Specification, Table 14 (Fault record TTYP field encodings): "The TTYP field reports inbound transaction type." "2 Untranslated read transaction", "3 Untranslated write/AMO transaction". ## Observed behaviour ``` Read DMA: RAM (gva 0x100000) to EDU device Fault record CAUSE = 00000017 TTYP = 00000003 CAUSE access type = write TTYP access type = write BUG: read transaction reported with non-read access type (CAUSE and/or TTYP not read). ``` CAUSE 0x17 is 23 (Write/AMO guest-page fault) and TTYP is 3 (Untranslated write/AMO transaction), although the DMA is a read. ## Source location `hw/riscv/riscv-iommu.c`, `riscv_iommu_spa_fetch()`. When the first-stage (VS-stage) leaf is reached, the access permission is replaced with the leaf PTE's R/W bits: ```c iotlb->perm = (pte & PTE_W) ? ((pte & PTE_R) ? IOMMU_RW : IOMMU_WO) : IOMMU_RO; ``` The translation then continues into the second-stage (G-stage) walk. When that walk faults, the fault cause is derived from `iotlb->perm`: ```c return (iotlb->perm & IOMMU_WO) ? (pass ? RISCV_IOMMU_FQ_CAUSE_WR_FAULT_VS : RISCV_IOMMU_FQ_CAUSE_WR_FAULT_S) : (pass ? RISCV_IOMMU_FQ_CAUSE_RD_FAULT_VS : RISCV_IOMMU_FQ_CAUSE_RD_FAULT_S); ``` and the fault record TTYP is set in `riscv_iommu_report_fault()` from the same `iotlb->perm`: ```c if (iotlb->perm & IOMMU_RW) { ttype = RISCV_IOMMU_FQ_TTYPE_UADDR_WR; } else if (iotlb->perm & IOMMU_RO) { ttype = RISCV_IOMMU_FQ_TTYPE_UADDR_RD; } ``` Because `iotlb->perm` was set to the VS-stage leaf's R/W bits (IOMMU_RW here), both the CAUSE and the TTYP report a write access for a read transaction. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->