A DMA-capable device can issue memory transactions without the CPU copying each payload. On systems with an IOMMU, the address carried by that device transaction does not have to be a host physical address. The IOMMU can translate a device-visible I/O virtual address into a physical page and reject accesses outside the configured mapping.
That translation boundary changes both isolation and data movement. Drivers and operating systems can give a device a constrained address space, while the hardware must maintain translation state close enough to the I/O path to avoid turning every DMA request into a page-table walk.
DMA addresses form a separate address domain
Without address translation in the I/O path, a device commonly needs DMA addresses that correspond to memory locations reachable through the platform interconnect. With an IOMMU enabled, software can instead install mappings from I/O virtual addresses to physical memory.
device DMA request
|
v
I/O virtual address
|
v
IOMMU
|
v
host physical address
|
v
memoryThe device operates on the address it was given. Translation is performed by the platform, not by ordinary CPU load and store instructions.
This separation permits the same physical page to appear at a different device-visible address. It also permits software to withhold mappings for memory that the device must not access.
The exact terminology differs across architectures. Intel documentation commonly uses DMA remapping in VT-d, while Arm systems use an SMMU for comparable I/O translation duties. Their programming models are not identical, so a generic IOMMU description is a systems abstraction rather than one universal register interface.
Isolation depends on the active translation context
An IOMMU does not create isolation merely by being present. Isolation comes from the translation context and page tables selected for a device or requester.
A mapping can grant read access, write access, or other architecture-specific permissions to a range of pages. A DMA transaction outside the permitted translation can generate a fault instead of reaching arbitrary physical memory.
This is important for device assignment. A virtual machine can receive a device while the host configures I/O mappings that restrict DMA to memory belonging to that guest. The CPU’s page tables and the IOMMU’s mappings protect different transaction sources, so both boundaries matter.
Isolation quality also depends on correct requester identification and platform topology. If hardware cannot distinguish requesters at the required boundary, software cannot manufacture finer isolation solely through page-table entries.
Translation caches reduce repeated page-table walks
I/O translation has the same basic locality problem as CPU virtual memory: repeatedly walking page tables for every transaction would add avoidable work. IOMMUs therefore use implementation-specific translation caches.
A cached translation can let later DMA requests reuse a resolved mapping. This improves the common path, but it creates a state-management requirement when software changes or removes a mapping.
mapping installed
|
v
translation cached
|
v
mapping changed
|
v
invalidate stale translation
|
v
new mapping becomes safe to useSoftware must follow the architecture’s invalidation and ordering rules before assuming that an obsolete translation can no longer be used. Removing a page-table entry in memory is not, by itself, a universal guarantee that every cached I/O translation has disappeared.
The cost of invalidation is workload- and implementation-dependent. A fixed latency or throughput penalty cannot be inferred from the presence of an IOMMU alone.
Mapping granularity affects translation pressure
IOMMU page tables commonly support page-sized mappings, and some implementations support larger mapping sizes. Larger mappings can cover more memory with fewer translation entries when alignment, contiguity, permissions, and platform capabilities permit them.
That can reduce page-table depth or translation-cache pressure in suitable cases, but it also coarsens the mapping boundary. A large mapping is not automatically preferable when buffers require fine-grained lifetime or permission control.
Scatter-gather I/O illustrates the opposite case. Physically separate pages can be mapped into a device-visible range so that software and hardware can describe DMA without requiring one physically contiguous allocation. The available arrangement still depends on the device, DMA API, IOMMU implementation, and operating-system policy.
Device-side address translation changes the path
PCI Express devices can support Address Translation Services, or ATS. With ATS, a capable device can request translations and cache translated addresses locally under platform control.
This moves some translation reuse closer to the requester, but it adds coherence obligations for translation state. When a mapping changes, stale device-side translations must be invalidated according to the applicable protocol.
ATS support is therefore not equivalent to bypassing isolation. It is a coordinated translation mechanism whose security and correctness still depend on the IOMMU, device behavior, invalidation protocol, and software configuration.
Related PCIe facilities such as Process Address Space ID can distinguish address spaces associated with transactions on capable systems. These features enable more direct sharing of virtual-address concepts between processes and devices, but support is specific to the device and platform.
Faults expose invalid DMA rather than repairing it silently
An IOMMU can detect transactions that lack a valid translation or violate configured permissions. Platforms can report such faults to system software with requester and address information defined by the architecture.
A fault often indicates a concrete lifetime or configuration problem: a driver may have unmapped a buffer too early, programmed the wrong DMA address, selected an incorrect domain, or allowed a device to continue operating after teardown.
The IOMMU does not make a faulty DMA sequence correct. Its protection value is that an invalid transaction can be blocked and surfaced instead of reaching an unrelated physical page.
Fault handling also is not a universal demand-paging mechanism. Some architectures and devices provide facilities for recoverable page requests, but ordinary DMA faults cannot be assumed to pause and resume transparently.
Bypass modes remove part of the boundary
Platforms can expose identity mappings or translation-bypass modes for selected devices or configurations. In such a mode, the device-visible address can correspond directly to the physical address for the relevant transaction path.
Bypass can remove translation work, but it also removes the protection supplied by translated mappings for that path. Whether bypass is available or appropriate depends on platform policy, trust assumptions, firmware, operating-system configuration, and device requirements.
Performance comparisons must therefore state the actual mode. An enabled IOMMU with cached translations, an identity-mapped domain, and full bypass are distinct configurations even if applications issue the same I/O.
IOMMU behavior sits between driver intent and memory access
The driver arranges buffers and DMA mappings; the device emits transactions; the IOMMU enforces the active translation context; memory receives only transactions that survive that path.
This boundary is useful precisely because it is independent of ordinary CPU address translation. It can constrain autonomous devices, support remapped DMA address spaces, and expose invalid accesses as faults.
Its practical cost is not one constant surcharge. Page-table structure, mapping size, translation locality, invalidation frequency, device-side translation features, platform topology, and implementation details all shape the resulting behavior.