<!--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-51:5"><code>qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_flt \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_msi_fault_record.elf </code></pre> <h2 id="user-content-emulatedvirtualized-environment" data-sourcepos="53:1-53: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="55:1-63:28"> <li data-sourcepos="55:1-57:41"> <p data-sourcepos="55:3-55: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 an MSI translation faults (e.g. the MSI PTE is not valid), the IOMMU writes a fault record with `iotval = 0` and `iotval2 = 0`. The address that faulted (the MSI address) is available inside the MSI translation routine but is passed as 0. ## Steps to reproduce 1. [iommu_msi_fault_record.c](/uploads/5ad7ce2634ef8db523701182a4e3d37f/iommu_msi_fault_record.c) 2. Built with: `riscv64-unknown-elf-gcc -march=rv64gc -mabi=lp64 -mcmodel=medany -nostartfiles -nostdlib` 3. [iommu_msi_fault_record.elf](/uploads/b14cc3f6c68d1f1d63dd02a8ced59500/iommu_msi_fault_record.elf) ``` qemu-system-riscv64 \ -M virt,iommu-sys=on,aia=aplic-imsic \ -cpu rv64,smstateen=true \ -m 8G \ -trace riscv_iommu_flt \ -nographic \ -device edu,dma_mask=0xFFFFFFFFFFFFFFFF \ -bios bin/iommu_msi_fault_record.elf ``` ## Additional information The guest program (`tests/iommu_msi_fault_record.c`): 1. Registers a DC with MSI Flat mode (pattern = gppn_for_msi) and leaves the MSI PTE invalid (V = 0). 2. Maps gva_msi to the MSI guest physical page; programs the EDU device MSI message address to `gva_msi + 0x40` and triggers the MSI. 3. Reads the fault record produced by the MSI-translation fault. ## Expected behaviour (per spec) The fault record should record the faulting MSI address in `iotval` (and any spec-defined value in `iotval2`), as for other transaction faults. Spec references: - RISC-V IOMMU Architecture Specification, Section 4.2, fault record: "If the TTYP is a transaction with an IOVA, the IOVA is reported in iotval." (An MSI write is an inbound transaction with an IOVA; cause 262 "MSI PTE not valid" is listed in Table 13, Fault record CAUSE field encodings.) ## Observed behaviour ``` MSI device address (IOVA) = 0x0000000000400040 Fault record CAUSE = 0x00000106 (MSI PTE not valid) TTYP = 0x00000003 DID = 0x00000008 PV = 0x00000001 iotval = 0x0000000000000000 iotval2 = 0x0000000000000000 BUG: iotval and iotval2 are both 0 for the MSI fault; the faulting address is not recorded (unlike every other fault type). ``` `riscv_iommu_flt` trace (iova reported as 0): ``` riscv_iommu_flt (null): fault 0000:01.0 reason: 0x80d00000106 iova: 0x0 ``` The CAUSE (262) and DID (8) are correct, but `iotval` and `iotval2` are both 0; the faulting MSI address is not recorded. ## Source location In `hw/riscv/riscv-iommu.c`, `riscv_iommu_msi_write()` error path, literal `0, 0` is passed as `iotval`/`iotval2` to `riscv_iommu_report_fault()`. ## Notes - All MSI fault causes routed through this `err:` path (261 MSI PTE load access fault, 262 MSI PTE not valid, 263 MSI PTE misconfigured, 270 MSI PT corrupted, 273 MSI write fault) are affected. <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->