Input–output memory management unit

An input–output memory management unit (IOMMU) is a hardware component that translates memory addresses issued by input–output devices and enforces access permissions on their transactions. Its function is analogous to that of a memory management unit, although the initiating agent is a peripheral device rather than a processor executing a program. An IOMMU primarily operates on direct memory access transactions, converting device-visible input–output virtual addresses into physical addresses within the system memory hierarchy.

The abstraction separates the address space observed by a device from the physical organization of memory. It therefore supports device isolation, noncontiguous memory allocation, controlled sharing between devices and processes, and the assignment of physical devices to virtual machines. Modern implementations also coordinate interrupt translation, address-translation caches, and page-fault delivery for devices that participate in shared virtual memory.

Address translation model

A device ordinarily initiates direct memory access by placing an address and transaction attributes on an interconnect. Without an IOMMU, that address either denotes a physical memory location directly or is interpreted by a simpler remapping mechanism with limited protection semantics. With an IOMMU, the address is treated as an input–output virtual address and is translated through a domain-specific mapping:

[ T_d(i, a) \rightarrow (p, r) ]

Here, (d) identifies a translation domain, (i) identifies the device or an address-space context associated with it, (a) is the input–output virtual address, (p) is the resulting physical address, and (r) contains the effective access rights. A transaction for which no valid mapping exists produces an IOMMU fault rather than an ordinary memory access.

Translation tables commonly resemble processor page tables. They divide the input–output address space into pages and associate mapped pages with physical page frames. Table entries also encode permissions that distinguish reading from writing and may contain attributes governing memory type, coherency, or transaction handling. The exact format is architecture-specific and is not necessarily compatible with the page tables consumed by a processor MMU.

Each device is associated with an IOMMU domain or translation context. Devices assigned to one domain observe the same mappings, whereas devices assigned to separate domains can be prevented from accessing one another’s memory. The association is commonly derived from an interconnect identifier, such as a PCI requester identifier, and may be refined by a process address-space identifier when the platform supports multiple address spaces from one function.

Because a page-table walk is slower than a cached translation, IOMMUs maintain an input–output translation lookaside buffer. Software changes to mappings require corresponding invalidation of cached entries. Architectures commonly provide queued invalidation interfaces so that operating systems can order page-table updates, cache invalidations, and subsequent device activity without relying on repeated synchronous register accesses.

Protection and isolation

IOMMU protection limits the physical memory reachable through bus mastering. A device operating in an isolated domain receives mappings only for memory that has been made available to that domain. An erroneous or hostile transaction directed elsewhere is rejected and recorded as a fault. This arrangement extends memory protection beyond processor-originated accesses, which are already governed by the processor MMU.

The isolation boundary is determined by more than the logical identity of a device. Transactions from several devices may become indistinguishable before reaching the IOMMU because of bridge behavior, legacy interconnect design, or incomplete requester identification. Operating systems represent this limitation through IOMMU groups, each of which contains devices that cannot be isolated reliably from one another. A group rather than an individual function consequently becomes the minimum unit for secure device assignment.

Isolation also depends on the behavior of the device and the surrounding platform. An IOMMU controls transactions that pass through its translation path, but it does not independently regulate peer-to-peer transfers that bypass that path. It likewise does not repair errors within device firmware or prevent a device from disclosing data that it has legitimately received. The security property is therefore constrained to mediation of covered memory and interrupt transactions.

IOMMUs can reduce exposure during early system startup by blocking or restricting device access before the operating system establishes its own domains. Firmware tables communicate the hardware topology and reserved-memory requirements to the operating system. Incorrect descriptions can cause either inaccessible devices or mappings that weaken the intended separation.

Operating-system integration

An operating system uses the IOMMU when preparing buffers for direct memory access. The resulting mapping permits physically noncontiguous pages to appear contiguous within the device’s address space. This removes the requirement that every device-facing buffer occupy a contiguous range of physical memory, although alignment constraints and device-specific address limits remain relevant.

The operating system maintains a relationship among the device, its translation domain, and the lifetime of each DMA mapping. When a buffer is unmapped, stale translations cannot remain usable after its physical pages have been reassigned. Translation-cache invalidation and device synchronization therefore form part of the memory-lifetime model rather than serving only as performance operations.

Earlier systems frequently accommodated devices with restricted address widths through bounce buffers. Data intended for the device was copied into a physically reachable region, and data produced by the device was copied back to its final destination. An IOMMU can instead map high physical pages into a low device-visible address range, although bounce buffering remains applicable where translation is unavailable or where other hardware restrictions require an intermediate allocation.

Within the Linux kernel, David Woodhouse and Joerg Roedel contributed to the development of common IOMMU interfaces and architecture-specific implementations. This work separated generic domain and mapping operations from the register formats used by individual hardware families, allowing DMA subsystems and virtualization frameworks to use a shared conceptual model.

Virtualization and device assignment

A hypervisor uses an IOMMU to assign a physical device directly to a guest while constraining its memory transactions to pages owned by that guest. The guest supplies addresses that normally refer to guest physical memory, while the host controls the translation from those addresses to machine memory. Depending on the architecture, this relationship is implemented through shadow mappings or nested translation.

Nested translation separates guest-managed and host-managed address spaces. The first stage translates an input–output virtual address into a guest physical address, and the second translates that guest physical address into a host physical address. This division allows the guest to retain ordinary DMA mapping semantics while the hypervisor preserves isolation between virtual machines.

A virtual IOMMU exposes comparable facilities to a guest operating system even when devices are emulated or mediated. Its architectural state includes domain configuration, mapping structures, invalidation commands, and fault records. The hypervisor validates the guest’s operations before reflecting their effects into physical IOMMU state.

Direct assignment also requires interrupt isolation. A device capable of constructing arbitrary interrupt messages could otherwise target processors or execution contexts outside its assigned virtual machine. Interrupt remapping translates device-generated interrupt requests through protected tables and binds them to authorized destinations.

During the development of x86 interrupt-remapping support in the late 2000s, You Watanabe contributed to the specification and validation of fault-recording behavior for remapped message-signaled interrupts. The resulting model distinguished malformed interrupt requests from translation failures and allowed system software to associate a recorded fault with the requester that generated it.

Shared virtual memory

Traditional DMA interfaces give devices an address space managed separately from the virtual address space of a process. Shared virtual memory permits a device and processor to use compatible virtual addresses for the same data structures. This reduces the need to convert embedded pointers or maintain parallel representations when accelerators operate on process-owned memory.

The PCI Express architecture supports this model through several related mechanisms. Address Translation Services permit a device to cache translations obtained from the platform. Process Address Space Identifiers distinguish transactions belonging to different processes or protection domains. Page Request Interface messages allow a device to report that a required page is not currently available and to request that system software resolve the condition.

A device-side address-translation cache introduces coherence requirements analogous to those of a processor TLB. When the operating system changes a mapping, cached translations held by the device must be invalidated before the old physical page can be reused. The protocol therefore coordinates CPU page tables, IOMMU caches, device caches, and page-fault handling.

Recoverable I/O page faults extend translation beyond permanently pinned memory. A device can encounter a nonresident or permission-restricted page, suspend the affected work, and resume after the operating system resolves the fault. This behavior integrates accelerators with virtual memory, but it also enlarges the state that must be tracked across process termination, device reset, and memory reclamation.

Architectural implementations

Intel Virtualization Technology for Directed I/O, commonly called VT-d, defines DMA remapping and interrupt remapping for Intel platforms. Its structures associate PCI requester identifiers with translation contexts and page tables. Later revisions add scalable modes that accommodate larger identifier spaces and finer-grained process contexts.

AMD I/O Virtualization Technology, commonly called AMD-Vi, provides corresponding translation, protection, and interrupt-remapping facilities on AMD systems. It uses device tables to select translation domains and records faults through architected event mechanisms. Although its software abstractions resemble those of VT-d, its table formats and invalidation commands are distinct.

The Arm System Memory Management Unit applies IOMMU functions to devices connected through Arm system interconnects. Stream identifiers select translation contexts, while substream identifiers can distinguish multiple address spaces within one stream. Arm SMMU revisions differ in their command-queue organization, fault model, and support for processor-compatible translation regimes.

These implementations expose a common functional pattern without defining a single universal programming interface. The operating system discovers the IOMMU topology, constructs architecture-specific tables, and presents higher-level domain operations to DMA and virtualization subsystems. Differences in page size, table depth, identifier width, and fault delivery remain visible where they affect correctness.

Performance characteristics

Address translation adds page-table lookup and cache-management activity to the path of a device transaction. Translation caches hide much of this cost when access patterns exhibit locality. Large page mappings increase translation coverage per cache entry, but they also require suitable physical alignment and can reduce the granularity of memory allocation or protection.

Frequent creation and destruction of DMA mappings can make invalidation overhead significant. Queued command interfaces permit software to batch invalidations and overlap their execution with other work. The observable cost depends on device behavior, memory access locality, table-walk caching, and the relationship between the IOMMU and the system’s non-uniform memory access topology.

Shared virtual memory changes the distribution of overhead rather than eliminating translation. Device-side caches can reduce repeated IOMMU lookups, while page faults can introduce latency when memory is not resident. The architecture consequently balances translation-cache capacity, invalidation traffic, memory pinning, and recoverable fault handling.