<!--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-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_dbg_tr_size_2mib.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 The register-based debug translation interface (present when capabilities.DBG == 1) returns the result of a translation in tr_response. When the translation range is larger than 4 KiB, tr_response.S (bit 9) must be set and the range size must be encoded in tr_response.PPN using the trailing-ones scheme. The model never sets the S bit and never encodes the size. For a 2 MiB super-page it returns S = 0 and the plain page number, i.e. a 4 KiB-style response, losing the actual translation range size. ## Steps to reproduce ``` 1.[iommu_dbg_tr_size_2mib.c](/uploads/a43f162578661968b067f68d8d4393c7/iommu_dbg_tr_size_2mib.c) ``` 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_dbg_tr_size_2mib.elf](/uploads/63aba6d2a42c6a1c9939f303e67bfbf6/iommu_dbg_tr_size_2mib.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 bin/iommu_dbg_tr_size_2mib.elf ``` ## Additional information The guest program (`tests/iommu_dbg_tr_size_2mib.c`): 1. Confirms capabilities.DBG (bit 31) is 1. 2. Registers a single-stage DC (iohgatp = Bare, iosatp = Sv39, PDTV = 0) and builds a 2 MiB leaf PTE (Sv39 level-1) mapping IOVA 0x200000 to SPA 0x90000000. 3. Drives the debug interface: writes tr_req_iova = 0x200000, writes tr_req_ctl with DID = 8 and go_busy = 1, polls until go_busy clears, then reads tr_response. ## Expected behaviour (per spec) For a 2 MiB translation range the response must be S = 1 with the size encoded in PPN as trailing ones. The test header reproduces the spec encoding table: ``` PPN S Size yyyy....yyyy yyyy yyyy 0 4 KiB yyyy....yyyy yyyy 0111 1 64 KiB yyyy....yyy0 1111 1111 1 2 MiB ``` So a 2 MiB result must have S = 1 and PPN low 8 bits = 0xFF (first 0 at bit 8). Spec references: - RISC-V IOMMU Architecture Specification, Section 6.26, Translation-response (tr_response), S and PPN fields: "S ... Translation range size field, when set to 1 indicates that the translation applies to a range that is larger than 4 KiB and the size of the translation range is encoded in the PPN field." and "If the S bit is 0, then the size of the translation is 4 KiB - a page. If the S bit is 1, then the translation resulted in a superpage, and the size of the superpage is encoded in the PPN itself. If scanning from bit position 0 to bit position 43, the first bit with a value of 0 at position X, then the superpage size is 2^(X+1) \* 4 KiB." ## Observed behaviour ``` capabilities = 0x00000078E2CF4F10 DBG(bit31) = 0x00000001 Built single-stage 2MiB leaf: gva 0x0000000000200000 to spa 0x0000000090000000 tr_response = 0x0000000024000000 fault = 0x00000000 S = 0x00000000 PPN = 0x0000000000090000 PPN low 8 bits = 0x00000000 Expected for a 2MiB range: S = 1, PPN low 8 bits = 0xFF (trailing ones). BUG: 2MiB translation but S bit not set; PPN does not encode the size (no trailing ones); the debug interface reports a 4KiB-style response for a super-page. ``` The base PPN is correct (0x90000 \<\< 12 = 0x90000000), but S = 0 and the low PPN bits are 0, so the response is indistinguishable from a 4 KiB-page translation. ## Root cause In `hw/riscv/riscv-iommu.c`, `riscv_iommu_process_dbg()` success path: ```c iova = iotlb.translated_addr & ~iotlb.addr_mask; iova = set_field(0, RISCV_IOMMU_TR_RESPONSE_PPN, PPN_DOWN(iova)); riscv_iommu_reg_set64(s, RISCV_IOMMU_REG_TR_RESPONSE, iova); ``` It writes only the PPN field. It does not set `RISCV_IOMMU_TR_RESPONSE_S` (bit 9) and does not convert `iotlb.addr_mask` (which is 2 MiB-1 here) into the trailing-ones size encoding in the PPN field. `iotlb.addr_mask` carries the range size from the walk, so the size information is available but discarded. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->