<!--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-52:5"><code>qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_sys_msi_sent \ -trace riscv_iommu_flt \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_msi_cfg_wr_fault.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 the IOMMU sends one of its own interrupts in MSI mode (IGS = MSI), it writes msi_data to the configured msi_addr_x. If that write takes an access fault, the IOMMU must report an "IOMMU MSI write access fault" (cause = 273), with TTYP = 0 and iotval = msi_addr_x. The model captures the write result but only passes it to a trace; no cause-273 fault record is produced. ## Steps to reproduce 1. [iommu_msi_cfg_wr_fault.c](/uploads/bf62e62a99c78745473e5e94cbd3e56f/iommu_msi_cfg_wr_fault.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_msi_cfg_wr_fault.elf](/uploads/ca5e03b76b6949ead9467bb64c92116f/iommu_msi_cfg_wr_fault.elf) ``` qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_sys_msi_sent \ -trace riscv_iommu_flt \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_msi_cfg_wr_fault.elf ``` ## Additional information The guest program (`tests/iommu_msi_cfg_wr_fault.c`): 1. Enables the IOMMU and the fault queue (FQEN + FIE) and selects MSI interrupt generation (fctl.WSI = 0). 2. Programs the IOMMU MSI config table (at register offset 0x300) entry 0 (the default fault-queue interrupt vector) with an unmapped MSI address (0x40_0000_0000), unmasked. 3. Issues a DMA from the EDU device, which has no DC registered, producing a "DDT entry not valid" fault. With FIE set and MSI mode, the IOMMU sends an MSI to the bad address; that write faults. 4. Scans the fault queue for a cause-273 record. ## Expected behaviour (per spec) The RISC-V IOMMU Architecture Specification, Section 6, MSI configuration registers msi_addr_x / msi_data_x / msi_vec_ctl_x, states: > "If an access fault is detected on a MSI write using msi_addr_x, then the IOMMU reports a "IOMMU MSI write access fault" (cause 273) fault, with TTYP set to 0 and iotval set to the value of msi_addr_x." Accordingly, the failed IOMMU MSI write must add a fault record with CAUSE = 273, TTYP = 0, and iotval = the MSI address (0x40_0000_0000). ## Observed behaviour ``` fctl (WSI cleared, MSI mode) = 0x00000000 MSI config vec0 addr = 0x0000004000000000 (unmapped) Fault queue scan entry CAUSE=0x00000102 TTYP=0x00000002 iotval=0x0000000000000000 BUG: no cause-273 record; the failed IOMMU MSI write was not reported. Check riscv_iommu_sys_msi_sent trace: result != MEMTX_OK but ignored. ``` The fault queue contains only the trigger fault (258, DDT entry not valid). The `riscv_iommu_sys_msi_sent` trace shows the IOMMU MSI write failed: ``` riscv_iommu_sys_msi_sent MSI sent to vector 0 msi_addr 0x4000000000 msi_data 0x1234 result 2 ``` `result 2` is MEMTX_DECODE_ERROR (the write to the unmapped address failed), but no cause-273 fault record was produced. ## Source location `hw/riscv/riscv-iommu-sys.c`, `riscv_iommu_sysdev_send_MSI()`: ```c address_space_stl_le(&address_space_memory, msi_addr, msi_data, MEMTXATTRS_UNSPECIFIED, &result); trace_riscv_iommu_sys_msi_sent(vector, msi_addr, msi_data, result); ``` The `result` of the MSI write is captured and passed only to the trace. When `result != MEMTX_OK`, the spec requires the IOMMU to enqueue an "IOMMU MSI write access fault" record (cause 273, TTYP = 0, iotval = msi_addr). No such record is produced. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->