A device can write to memory; the IOMMU decides where. Eight experiments ask who tells it what to do, and
what changes when a guest takes a device: how firmware describes the IOMMU, how a program takes a
device, four ways to give a guest a NIC (network card), the one table row that changes, a stranger's Thunderbolt dock,
the default domain Linux picks, SR-IOV requester IDs and the RISC-V IOMMU. Why VFIO refuses a device in
the first place is the previous chapter, IOMMU groups & ACS. Each step runs a
small rule taken from the Linux source or a specification, so the numbers on screen are computed, not
typed.
What claims does this page make? · 3 points
Spec rule: the firmware experiment follows the AMD IOMMU Specification (48882 rev 3.11, section 5.2: IVRS, IVHD, IVMD); the RISC-V step follows the RISC-V IOMMU Architecture Specification (ddtp modes and device directory indexing), and the SR-IOV requester ID step follows the PCIe SR-IOV rules, which this site has not checked against the members-only PCIe text.
Platform assumption: how Linux reacts to those tables, iommufd, VFIO cdev, default domain types, iommu.passthrough and Thunderbolt protection are Linux behaviour that depends on the kernel version and build, not on a specification.
Teaching model: each experiment is a small DOM-free rule set run on made-up devices, with example values such as SR-IOV offset 128 and stride 2.
Experiments
Experiment
What the model holds after that step
This "What if" step ran on its own copy; the panels show that copy.
State
Computed by the model
Notes
Look at your own machine
Read-only commands on a Linux host. They change nothing; treat the
output as private.
for g in /sys/kernel/iommu_groups/*; do echo "group ${g##*/} ($(cat $g/type)):"; ls $g/devices; done
cat /sys/bus/pci/devices/0000:03:00.0/sriov_totalvfs /sys/bus/pci/devices/0000:03:00.0/sriov_numvfs
cat /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection
dmesg | grep -i -E 'iommu|DMAR|AMD-Vi|Default domain|DMA domain'
cat /proc/cmdline
Linux source: drivers/iommu/iommu.c (pci_device_group, REQ_ACS_FLAGS, iommu_get_default_domain_type, iommu_group_store_type), drivers/pci/pci.c (pci_acs_enabled, pci_acs_path_enabled), drivers/pci/iov.c, drivers/iommu/dma-iommu.c (dev_use_swiotlb), drivers/iommu/riscv/, drivers/iommu/amd/init.c and amd/iommu.c (IVRS and IVMD handling); Documentation/ABI/testing/sysfs-kernel-iommu_groups. Read on 1 October 2026 (tree 7.3-rc5); the AMD files (amd/init.c, amd/iommu.c, amd/io_pgtable.c) and the IVRS experiments at v6.18; behaviour from before 6.2 (iommufd), 6.6 (VFIO cdev), 6.11 (pci=config_acs=) and 6.13 (RISC-V driver) is stated with the version where the file first appears.
Lenovo Press LP1467, An Introduction to IOMMU Infrastructure in the Linux Kernel (2021): the emulation, passthrough and IOMMU pass-through comparison and the IVRS overview that prompted the firmware, four-set-ups and device-entry experiments. Cited, not copied; every figure here is our own drawing; its claim that pass-through mode enables direct device access is corrected in the experiment against the kernel source.