IOMMU Explained: DMA Remapping, VT-d, AMD-Vi, and PCIe Passthrough

Direct Memory Access lets capable devices transfer data to and from system memory without making the CPU copy every byte. An Input-Output Memory Management Unit, or IOMMU, adds address translation and access control to that device-facing path. AMD describes the IOMMU as providing memory remapping services for I/O devices, including address translation and protection for DMA transfers. Intel describes VT-d DMA remapping as independent address translation for DMA from devices.

The useful mental model is that a DMA-capable device can issue an address in an I/O address space, while the IOMMU translates that request before it reaches physical memory. Software controls mappings that define which memory a device is allowed to reach. An access outside the permitted mapping can therefore be blocked or faulted instead of becoming an unrestricted DMA access to host memory.

A CPU memory-management unit translates addresses used by processor execution. An IOMMU performs a related kind of translation for I/O transactions initiated by devices. The two mechanisms solve different address-translation problems even though both can use page-table-like structures and both ultimately control access to physical memory.

That distinction also separates IOMMU support from CPU virtualization instructions. Intel VT-x and AMD-V help virtualize processor execution; Intel VT-d and AMD IOMMU/AMD-Vi concern I/O memory management and device-facing isolation. A PC can therefore expose several firmware virtualization controls because enabling CPU virtualization and enabling I/O virtualization are not necessarily the same setting or capability.

Intel VT-d provides domain-based I/O isolation and DMA remapping. Intel documents device-to-domain mapping in which PCIe bus, device, and function identity is associated with translation structures, allowing DMA requests from assigned devices to be translated into the appropriate host physical addresses. VT-d also defines related capabilities such as interrupt remapping, but interrupt remapping is a distinct function rather than another name for DMA address translation.

AMD documentation likewise describes an IOMMU that provides private I/O address spaces, system-memory access protection, and interrupt remapping. The terminology and architecture details differ between vendors and generations, so “VT-d” and “AMD-Vi” should not be treated as feature-for-feature labels for every implementation. At the practical PC level, both belong to the hardware foundation that an operating system or hypervisor can use to control device DMA.

Direct device assignment gives a guest much closer access to a physical PCIe device than ordinary emulated or paravirtualized I/O. The host must still prevent that assigned device from DMA-accessing memory belonging to the host or another guest. An IOMMU can create the required DMA translation domain so the device sees the addresses intended for its guest while accesses outside that domain remain controlled.

This does not mean that switching on an IOMMU automatically makes every GPU, NIC, storage controller, or other PCIe device suitable for passthrough. The processor and platform must expose the necessary I/O-virtualization capability; firmware must configure and report it correctly; the operating system or hypervisor must support device assignment; and the device and surrounding PCIe topology must provide a usable isolation boundary. Reset behavior, drivers, multifunction devices, bridges, and other platform details can still determine whether a particular assignment works reliably.

Linux VFIO represents devices in IOMMU groups because isolation is not always available at the granularity of one PCIe function. The kernel documentation explains that devices can be affected by topology and by transactions that may not be distinguishable by the IOMMU. As a result, a group represents the set of devices that must be considered together for ownership and isolation.

Group layout is platform-specific. A device appearing in a large group does not prove that the IOMMU is absent, and there is no universal motherboard rule that every slot receives its own group. PCIe bridges and capabilities such as Access Control Services can affect isolation, but forcing a software split does not manufacture hardware isolation that the platform does not actually provide. For passthrough, inspect the real platform topology and groups rather than assuming a layout from the CPU or chipset name.

Single Root I/O Virtualization, or SR-IOV, allows supporting PCIe hardware to expose virtual functions that software can assign or manage separately. That can make one physical device useful to multiple guests, but SR-IOV does not replace DMA isolation. The platform still needs the appropriate I/O memory-management and virtualization path for secure assignment.

PCIe Access Control Services, or ACS, provides controls relevant to transaction routing and isolation through PCIe hierarchy components. ACS can matter when software determines whether devices can be isolated from one another, but its presence is not synonymous with an IOMMU and its absence cannot be summarized as “passthrough impossible” without looking at the actual topology. These layers cooperate; they are not interchangeable checkboxes.

IOMMUs are not only a virtual-machine passthrough feature. Microsoft’s Kernel DMA Protection requirements use an enabled IOMMU—identified as Intel VT-d or AMD-Vi—to block or allow DMA-capable devices according to policy and to perform DMA remapping for compatible drivers. This is an operating-system security use of the same underlying ability to constrain device access to memory.

That does not justify a blanket claim that merely enabling an IOMMU makes every PC secure against every DMA attack. Microsoft’s platform requirements include firmware behavior, PCIe native control, device placement behind the IOMMU, and compatible driver behavior. Security depends on the complete implementation and policy, not just the existence of an IOMMU setting in firmware.

A CPU or chipset specification saying that VT-d or an AMD IOMMU is supported establishes capability, not necessarily active use. Firmware can expose controls for I/O virtualization, and the operating system still has to initialize and use the remapping hardware. Intel also notes that VT-d availability can vary by SKU, so a family name alone is not enough to prove support on every processor and platform combination.

For a passthrough build, verify the exact CPU, motherboard or system firmware, operating system or hypervisor, PCIe topology, target device, and required driver path. For ordinary desktop use, there is usually no reason to infer a universal performance penalty or gain from the IOMMU label alone. Translation modes, workloads, device drivers, platform generation, and software configuration differ too much for a single percentage to be meaningful.

Think of the IOMMU as a policy and translation point on the device side of the memory system. A DMA request originates from an I/O device, the platform associates that request with the relevant translation domain, and the IOMMU either translates it to permitted host physical memory or rejects an invalid access. Virtual machines, device assignment, and DMA-protection features build on that primitive in different ways.

Keeping the layers separate avoids the most common confusion: CPU virtualization does not automatically imply device passthrough; an IOMMU does not imply SR-IOV; ACS does not define the IOMMU; interrupt remapping is related but distinct; and a firmware toggle does not guarantee that an arbitrary PCIe device has a clean assignment boundary. The complete platform and software path determines what can actually be isolated and assigned.