Answer: An IOMMU fault means a device attempted DMA, or an interrupt, that its translation tables do not allow. The log names the requester (bus:device.function), read or write, the address and a reason: Intel prints a VT-d fault-reason code, AMD prints flag bits. Usual causes are stale driver addresses, DMA left running, or firmware-reserved memory.
Intel and AMD, old and new kernel formats. Include boot lines such as DMAR: RMRR base: … to check whether faults fall inside firmware-reserved memory.
Samples are synthetic and labelled; they are not hardware captures.
Capture the lines
Faults are rate-limited, so the first burst after boot or after loading a driver is usually the most useful part.
journalctl -k -b | grep -iE 'dmar|amd-vi|io_page_fault|iommu' # this boot
journalctl -k -b -1 | grep -iE 'dmar|amd-vi|io_page_fault' # previous boot
sudo dmesg | grep -iE 'dmar|amd-vi|io_page_fault|iommu' # without a persistent journal
cat /proc/cmdline # iommu=, intel_iommu=, amd_iommu=Then identify the requester with lspci -nnk -s 03:00.0, using the address from the fault line. Intel logs before Linux 7.2 print the requester without its PCI segment; on multi-segment servers, match it against the segment of the IOMMU unit.
Intel fault reasons you will see most
| Reason | Kernel text | Usually means |
|---|---|---|
0x01 / 0x02 | Present bit in root / context entry is clear | No translation set up for this requester: no driver attached yet, the driver detached while DMA continued, or the device used another requester ID (an alias). |
0x04 | Access beyond MGAW | An address wider than the IOMMU translates: a corrupt, truncated or untranslated address. |
0x05 / 0x06 | PTE Write / Read access is not set | The device wrote or read an I/O virtual address that is not mapped for that access. In legacy mode an unmapped page looks the same. |
0x0d | PCE for translation request specifies blocking | The device used ATS while it was not enabled for it. |
0x22 / 0x25 / 0x26 | Interrupt-remapping faults | An interrupt with no remapping entry, a blocked old-style interrupt, or a source-ID mismatch; often firmware IOAPIC/HPET description. |
0x30+ | “SM: …” scalable-mode faults | Scalable mode (PASID-capable) table entries; the kernel text names the entry that failed. |
AMD-Vi IO_PAGE_FAULT flags
| Flags | Bits | Reading |
|---|---|---|
0x0000 | none | Translation not present; read/write direction unavailable |
0x0020 | RW | Translation not present; RW is undefined while PR is clear |
0x0050 / 0x0070 | PR+PE (+RW) | Mapped, but without read or write permission |
0x0008 | I | Interrupt request refused by interrupt remapping |
0x0100 | TR | ATS translation request |
Flag bits follow the IO_PAGE_FAULT event layout in the AMD IOMMU specification (GN 0x001, NX 0x002, US 0x004, I 0x008, PR 0x010, RW 0x020, PE 0x040, RZ 0x080, TR 0x100). domain=0x0000 matters: Linux never gives ID 0 to a translation domain, so a zero domain can indicate no translation domain. When GN is set, this field instead holds a PASID, including PASID zero.
Driver bug, firmware, iommu=pt or VFIO?
Driver or device. Faults from one requester at changing addresses, starting after a driver load, reset or unload, usually mean the device used an address its driver never mapped or had already unmapped. A custom driver that writes CPU physical addresses into descriptors instead of DMA-API addresses faults the same way.
Firmware. Intel RMRR and AMD IVRS unity-map entries declare memory that devices must reach before or outside an OS driver, typically USB legacy emulation and integrated graphics. Faults inside those ranges, faults with domain=0x0000 during boot, interrupt-remapping faults from IOAPIC or HPET IDs, and kernel “[Firmware Bug]” lines point at the DMAR or IVRS table.
iommu=pt. Passthrough gives host-driver devices an identity mapping, so their DMA is not translated and stale addresses stop faulting. The access still happens; you just stop seeing it. It does not change IOMMU groups, and devices assigned to VFIO still get translated domains.
VFIO. For a device bound to vfio-pci, addresses come from the guest or a user-space driver, so look at the guest driver, the VMM memory map, and DMA left running across a VM reset. Check that the device’s group is clean with the IOMMU group checker, and read the device’s AER state with the PCIe Bus Error decoder if the link also logs errors.
Questions
- What does “DMAR: DRHD: handling fault status reg 3” mean?
- DRHD is an Intel IOMMU unit, and the number is its Fault Status register in hex. Value 2 (bit 1) means fault records are pending; bit 0 is Primary Fault Overflow, so 3 means faults were pending and later ones were dropped. The detail is in the “Request device” lines that follow.
- What does “PTE Read access is not set” mean?
- Fault reason 0x06: the device read an I/O virtual address without read permission. In legacy translation mode an unmapped address looks the same, so it usually means a driver gave the device a stale or never-mapped address, or the device kept running DMA after a reset.
- What do AMD-Vi IO_PAGE_FAULT flags mean?
- The flags field is a bit set from the IOMMU event log. 0x010 (PR) marks a present page; 0x040 (PE) marks permission denied when PR is set. PR alone does not establish a permission fault. For a present-page DMA request, 0x020 (RW) selects write versus read; it does not determine direction when PR is clear or the request is an interrupt or translation request. 0x008 marks an interrupt request. flags=0x0000 means translation not present, with read/write direction unavailable.
- Does iommu=pt fix IOMMU faults?
- It hides them for devices used by host drivers: in passthrough their DMA is not translated, so a stale address reaches memory instead of faulting. That swaps a visible fault for a silent memory access. Devices assigned to VFIO still use translated domains, and iommu=pt does not change IOMMU groups.
- Is it a driver bug or a firmware problem?
- Faults that follow a driver load, reset or unload and move between addresses point at the driver. Faults inside an RMRR range, at domain 0x0000 before drivers load, from IOAPIC or HPET requester IDs, or after kernel “[Firmware Bug]” lines point at the firmware DMAR or IVRS tables.
- Why is the requester missing from lspci?
- It can be an alias. Devices behind a PCIe-to-PCI bridge use the bridge’s requester ID, some controllers issue DMA from a phantom function, and IOAPIC or HPET interrupt sources get IDs from firmware.
lspci -tvshows the bridges on the path. - How do IOMMU faults relate to VFIO passthrough?
- For a device bound to vfio-pci, DMA addresses come from the guest or a user-space driver. Faults point at the guest driver, the VMM memory map, or DMA left running across a VM reset. Check the device’s group with the IOMMU group checker first.
Sources and scope
Updated . Decoding runs locally in your browser; the pasted text is not uploaded, stored or logged.
- Intel Virtualization Technology for Directed I/O Architecture Specification, rev. 5.20 (fault-reason encodings)
- AMD I/O Virtualization Technology (IOMMU) Specification, 48882 (event log entries)
- Linux source: drivers/iommu/intel/dmar.c (DMAR fault messages and reason strings)
- Linux source: drivers/iommu/amd/iommu.c (AMD-Vi event messages)
- Linux: x86 IOMMU support and fault reporting
- Linux: kernel parameters (pci=noaer, pcie_aspm, iommu, intel_iommu, amd_iommu)
- Linux: VFIO groups, devices and IOMMUs
Guides that use this tool
- IOMMU groups explained: check, read and fix them for VFIO passthrough
- GPU passthrough on Proxmox with VFIO: the troubleshooting guide
- XDMA vs QDMA: which AMD PCIe DMA IP — and how to run the XDMA driver on Linux
- DMA attacks: how a PCIe or Thunderbolt device could read your crypto wallet’s keys — and how IOMMU stops it