Follow the request. Test the protection.

1 / What problem does an IOMMU solve?

A device can read and write memory using DMA without asking the CPU to copy each byte. An IOMMU associates that traffic with a device or process context, translates the supplied address when configured to do so, and checks access to the mapped memory. CPU virtual-memory translation is a separate path.

Arm SMMUv3 is an IOMMU architecture. AMD IOMMU and Arm SMMUv3 solve related isolation and translation problems with different descriptors, commands, queues and fault formats. Do not decode one architecture’s entries using the other’s bit definitions.

The Lenovo paper provides a useful Linux introduction and distinguishes DMA translation from pass-through. Device assignment to a VM can still use IOMMU translation; “PCI passthrough” does not mean “no DMA protection.” Its kernel examples and distribution defaults reflect its 2021 publication. Lenovo LP1467 is background reading; this guide uses AMD 48882 rev 3.11 for hardware rules and current kernel documentation for API concepts.

Scroll horizontally to compare every column.

DMA read means the device reads system memory; DMA write means it writes system memory. A NIC’s TX payload is normally read from memory, while RX payload is written to memory. Packet direction alone is a poor label for a permission test.

An enable bit proves configuration state. A correlated fault proves handling of a particular request. A controlled allowed → denied → recovered experiment supports the intended protection behaviour. None alone proves every traffic class is protected.

2 / The structures that decide the request

AMD: DeviceID selects the DTE; PASID can select the guest address space.

Diagrams show the lookup dependencies. On small screens, the same relationships appear as readable stacked steps.

Scroll horizontally to compare every column.

Descriptor validity comes before interpreting dependent fields. “Flip a reserved bit” requires a specific architecture, revision, active format and validity condition. In AMD 3.11, DTE bits 6:4 are conditional CXLMemAttr, not universally reserved.

Detailed AMD entries · Arm formats, granules and queues · GA word decoder

3 / A page boundary is not a DMA-address restriction

A frame base must align to its leaf size. An ordinary request can address any byte inside that frame. In the common 4 KiB-granule examples, a 4 KiB page uses 12 offset bits, 2 MiB uses 21, and 1 GiB uses 30. These are the selected AMD/Arm examples, not all supported architectural sizes.

In a nested walk, check the guest and host stages independently. A guest-table pointer can require a host translation before its entry can be read. Denying that metadata mapping is a different test from denying the final data page. The Translation lab shows both stages and preserves bytes completed before a later segment faults.

Permissions accumulate. A writable leaf does not override a read-only parent. Guest R/W=0 denies a write but can still allow a read; AMD host IR and IW are separate controls. Test absence, format, address size and protection separately before combining violations. Multiple simultaneous errors need an allowed-outcome set, not an invented universal priority.

AMD v1 host levels and Arm levels are numbered differently. Arm also supports other granules and optional descriptor extensions. Use the architecture-specific size table rather than sharing one numeric “level” across backends.

ATS trust boundary: ordinary AMD ATS returns an SPA. For ordinary translated DMA, §2.11 explains that the IOMMU checks authorization to issue translated traffic but does not revalidate that SPA against the original mapping. Secure ATS instead returns a GPA and applies the host translation on translated DMA. An ATS-based negative test must identify which mode is active; this site’s mock ATC provenance guard is stricter than that ordinary-hardware path.

4 / Configure, synchronize, then trust the result

Bring-up is part of the test

1. Discover the responsible IOMMU and requester mapping from firmware topology. Record the device and feature capability profile, address widths and supported table formats.
2. Allocate and initialize the active device/context/page tables and command/log backing. Check alignment, lengths, memory attributes, visibility and lifetime. Program base/pointer state while the relevant engine is stopped.
3. Configure logging and its notification path before relying on errors. AMD §2.3 specifies the control sequence; initialize PPR resources before enabling their use. Arm uses its own queue/configuration controls and CR0/CR0ACK handshake.
4. Attach the correct context, establish mappings and enable supported device-side ATS/PASID/PRI as required by the driver. Do not assume a capability bit alone enables the feature.
5. Prove a controlled valid transfer before introducing a fault. Keep traffic ownership and teardown rules explicit.

Changing a table is not the end of an update

Publishing bytes, invalidating a cache, fetching a command and completing its effects are different milestones. Use the correct DTE/configuration, page, interrupt and device-ATC invalidation scope. Test address, PASID, domain and global scopes as applicable; verify unrelated contexts remain unchanged. §2.4.11 and AMD 48882 Chapter 4 explain ordering and implementation freedom.

AMD command and log recovery uses documented Enable/Run and W1C rules. Arm command errors use CMDQ_CONS.ERR and GERROR/GERRORN; acknowledgment matches bit values. Arm event queue space can become usable before overflow acknowledgment. Compare recovery protocols; do not port the register sequence by renaming fields.

On teardown or power/reset transitions, stop new work, account for in-flight transactions, invalidate as required, and retain backing until it cannot be referenced. Include device reset, repeated stop/restart and delayed acknowledgments in platform tests. This is a validation strategy, not an undocumented universal register recipe.

5 / Show that the intended protection path is active

An error is valuable evidence, but its origin matters. A command-buffer fault proves command handling; it does not by itself prove NIC payload traverses the intended translation. A timeout can be upstream blocking. An unchanged canary is inconclusive if no request was sent.

1. Allowed control: use test-owned pages and a non-identity mapping A → B. Verify the known payload reaches B, while A and an unrelated guard remain unchanged. For a read, verify exactly what data returns to the device.
2. Denied probe: preserve the requester, context, address, size and access. Revoke the relevant permission/presence, publish and synchronize all applicable caches, then confirm the probe was issued. Observe no bytes from the denied segment.
3. Correlated evidence: match DeviceID/PASID or StreamID/SSID, access, address/stage and test window. Check the correct event, ATS permission response or stall indication, including logging health.
4. Recovery control: restore the intended mapping, synchronize and retry the same probe. Validate successful data movement and no collateral writes. Repeat with read/write, leaf boundaries, other contexts and cache states.

Negative tests should run in a controlled validation environment with owned buffers and a recovery path. Do not revoke live production mappings or inject arbitrary physical addresses to establish these controls.

Try the method as a case: a test passed; find out why.

Interactive evidence checker

This checker evaluates observations you select. It does not inspect your machine or generate real DMA. Unknown stays unknown; a logged event never substitutes for the missing baseline, issuance or data check.

Confounders to eliminate

Scroll horizontally to compare every column.

Run presence, permission and reserved-field injections · Exercise commands, overflow and recovery. The evidence strategy is independent reasoning based on the architecture; it is not a hardware certification test.

6 / Linux: functions configure the path; hardware carries the traffic

The driver establishes a DMA mapping before issuing the device operation. Hardware does not call dma_map_single() for each packet. The returned dma_addr_t is device-facing; it is not a CPU-dereferenceable pointer. Linux DMA mapping guide.

Scroll horizontally to compare every column.

The DMA API reference, VFIO guide and IOMMUFD documentation describe their respective contracts. Function signatures and internal call paths vary with kernel revision; pin the kernel used in a validation report.

// Harness pseudocode: these are responsibilities, not Linux API names.
context = discover_and_record_requester_and_capabilities()
baseline = map_owned_buffer_and_verify_nonidentity_DMA(context)
publish_selected_fault(context)
invalidate_required_caches_and_observe_completion(context)
denied = issue_same_probe_and_capture_data_plus_fault_evidence(context)
repair_publish_invalidate_and_observe_completion(context)
recovered = issue_same_probe_and_verify_owned_target(context)
assert_expected_baseline_denial_and_recovery(baseline, denied, recovered)

Keep four reusable layers: request/observation records; an architecture-specific descriptor and command backend; device traffic generation; and assertions. Reuse page arithmetic and test vocabulary. Keep AMD encoders, Arm encoders, ownership protocols and fault decoders separate.

7 / The specification map: what matters and what to test

This reading map covers the major architectural areas in AMD 48882 Chapters 1–5. It prioritizes engineering decisions and test obligations; it does not replace every register bit, optional-feature rule or implementation requirement.

The idea: the specification is a city, and this map groups its districts by the job they do, in the order one request meets them. Select a district to open its notes below.

1. Set it up before any request

   Firmware and the OS find the IOMMU, build its tables and turn it on.

   Topology and discoveryMMIO capabilities, bases and statusInitialization and table visibilityOS and firmware handoff

2. A request arrives: who is asking, and is it allowed?

   The IOMMU picks the device’s context, walks its tables and checks permissions.

   Normal, bypass and special request pathsMARC apertures (page-table bypass)Device and process contextsPage formats, large pages and shared tablesAccessed/dirty and privilege protections

3. Devices that cache translations or ask for pages

   Some devices keep their own copies or ask the OS for help.

   ATS and PCIe device cachesPRI and PPR responsesCXL memory indication

4. Interrupts

   Device interrupts are checked and steered, including to guests.

   Interrupt remapping and virtual APIC

5. Software and the IOMMU talk

   Commands go in; evidence comes out in the logs.

   Commands and completionError evidence and reportingEvent/PPR dual buffering (Log A/B) and overflow

6. Virtual machines and confidential computing

   Guests get their own IOMMU view, and private memory is fenced off.

   Hardware-accelerated vIOMMUSecure ATS and SNP/RMPSEV-TIO

7. Watch it run

   Counters show what the IOMMU is doing.

   Performance and observability

Open the detailed error-scenario checklist. Each case states whether it is executable, a synthetic injected failure or a platform/reference follow-up.

8 / Revision 3.11 changes the validation assumptions

This guide follows 48882-PUB rev 3.11, April 2026. These changes from rev 3.10 affect tests:

Scroll horizontally to compare every column.

The five listed guest commands are COMPLETION_WAIT, INVALIDATE_DEVTAB_ENTRY, INVALIDATE_IOMMU_PAGES, INVALIDATE_IOTLB_PAGES and COMPLETE_PPR_REQUEST. Do not issue host-only INSERT_GUEST_EVENT or RESET_VMMIO from a guest command buffer.

Decode EVENT_COUNTER_ZERO with its event-specific Figure 66 / Table 68 format, 1010b (0xA), and use §§2.5.12–15 for subsequent records. Similarly, apply the feature-specific sATS rules rather than a broad unconditional reading of Table 7.

Sources and scope

• AMD 48882-PUB rev 3.11, April 2026: 48882_3.11_IOMMU_PUB.pdf, especially Chapters 1–5, Table 7, §§2.4–2.14 and the revision history. AMD's PDF. The PDF is not copied into this site.
• Arm IHI 0070 H.a: SMMUv3 structures, translation stages, commands, queues and error handling. See the Arm companion reference.
• Lenovo LP1467, An Introduction to IOMMU Infrastructure in the Linux Kernel: introductory Linux context, DMA translation versus pass-through and device assignment. Historical examples are not current distribution defaults.
• Linux DMA mapping guide, DMA API, VFIO and IOMMUFD: software contracts and isolation concepts.

The diagrams and explanations are independently authored. Interactive calculations and evidence assessment run locally in the browser. They do not probe a real device, reproduce silicon timing or certify whole-spec conformance. Optional architecture topics are clearly separated from the working AMD teaching subset.