What did the device actually send?

Separate the request, the translation and the evidence

A client can advertise PASID support and enable it without sending a PASID on a particular request. First establish what the client actually issued, then evaluate how that request is handled by the selected IOMMU configuration. A fault is useful evidence, but it is not a packet capture.

For each run, keep four records: the intended workload, the observed request, the translation/configuration state, and the result. Include RequesterID or StreamID, PASID/SubstreamID presence separately from its numeric value, address type, Read/Write, byte range, and relevant privilege attributes. Keep an explicit unknown value when capture evidence is missing. A reported zero is not sufficient to distinguish “no PASID” from “PASID 0.”

The PASID trap: three different outcomes

In the selected AMD profile, V=1 and TV=1. Untagged ordinary DMA normally follows host translation. With supported and meaningful GIoV plus active guest translation, the IOMMU supplies effective PASID 0 instead. Explicit tagged traffic uses the observed PASID. Section 2.2.9 requires nonzero explicit PASIDs when mixing that traffic with Guest I/O Protection. Untagged MSI in the 0xFEEx_xxxx range remains an interrupt-remapping request. These distinctions come from 48882 3.11, Table 7 and §2.2.9, not an assumption that every enabled client sends tagged DMA.

Use disjoint owned mappings to distinguish contexts: put a different sentinel in PASID 0 and the expected explicit context. Run a positive control, then the deliberate mismatch. A wrong but valid PASID can succeed; an error-only oracle misses that failure. This is a test-design recipe, not permission to access another process’s memory.

Structures with similar purposes are not interchangeable

Arm material is pinned to IHI 0070 H.a, 6 March 2026. Its document revision does not imply every optional SMMUv3.5 capability is implemented. The executable backend is a non-secure 4 KiB-granule teaching profile; it is not an implementation of all descriptor formats, security states or GIC/ITS.

Design a negative test that identifies the layer

1. Prove submission. Bus mastering, the client descriptor and readiness must permit a request to be issued. A client-side rejection is not proof of IOMMU enforcement.
2. Prove identity and routing. Check the observed requester, PASID presence, AT and target path. A peer path or alias can invalidate the intended isolation test.
3. Establish a positive control. Show that the same owned fixture works with the intended permissions and configuration.
4. Inject one condition. Change presence, permission, identity, descriptor encoding, queue state or interrupt control independently first.
5. Inspect independent observations. Capture bytes changed, returned data, response attributes, event records, status bits and notification delivery separately.
6. Recover causally. Preserve evidence; repair the backing state; publish and invalidate the appropriate caches; observe completion; then issue a new request or use the correct resume protocol.

Repeat the core matrix over Read/Write, tagged/untagged, ordinary/ATS/pretranslated, cold/warm caches, enabled/suppressed reporting, and first/last bytes around a page boundary. Test the Cartesian product selectively according to feature prerequisites: a large number of combinations is not evidence of normative coverage. Keep unsupported, ignored and required-zero fields distinct.

Alignment has three meanings

A translation frame must satisfy its page/block format. A byte address inside that frame may have a nonzero offset. A PCIe Memory Request has its own 4 KiB boundary and DW/byte-enable rules, independent of whether the IOMMU uses a 4 KiB page or a 2 MiB/1 GiB mapping. A descriptor spanning a boundary can be legal when the client splits it into valid requests. The packet planner illustrates contiguous Memory Reads/Writes only; it does not model sparse byte enables, AtomicOps or Completion splitting.

Errors are not always one event per request

AMD Table 44 distinguishes ordinary untranslated accesses from ATS Translation Requests: a translation failure can produce a response with no permissions without the ordinary DMA event. SA/SE controls and available log space also affect observability. Tables 43–55 and the relevant event layout determine the oracle; “any reserved bit gives ILLEGAL_DEV_TABLE_ENTRY” is incorrect.

Arm configuration errors, translation faults and external-abort/global-error paths are separate. For multiple faults, consult H.a §7.3.23 instead of inventing a universal first-error order. Event merging and asynchronous visibility can also defeat a naïve one-request/one-record assertion. The page’s recipes state expected families or permitted outcomes, not guaranteed notification timing.

Queue and recovery traps worth keeping in every plan

Sources: AMD §§2.4–2.7; Arm §§3.5, 3.12.2, 4.1.3–4, 7.4–7.5 and 8.1. The basic Arm model uses a software admission guard for PRIQ-full; the full automatic PRIQ overflow response matrix remains a reference recipe, not an executed feature.

Interrupt negatives need their own evidence

Record interrupt address/data, requester identity, the selected DTE interrupt controls, calculated IRTE index, format and cached/backing state. Test the last valid index and first invalid index, RemapEn=0, applicable reserved fields and interrupt type, table-fetch failure, and capability/enable gates for 128-bit formats. Then test retargeting with the applicable interrupt-table invalidation. Data-TLB invalidation is not a substitute.

An interrupt with a PASID is an AMD Table 44 interrupt-context fault. A Read or non-posted Write to interrupt space instead uses the Table 50 prohibited-access rules. When Guest I/O Protection is enabled, an untagged MSI must still reach the interrupt path. For GA, distinguish a lost log entry from a pending interrupt in the virtual APIC backing page; log consumption is not guest EOI. The raw-records workbench has the packed IRTE exercises.

PCIe scope and outstanding specification work

The AMD and Arm specifications were read directly; the PCIe Base Specification was not. PCIe information here is limited to cited public PCI-SIG FAQs and primary implementation documentation (AMD PG054 and Intel’s 710 Series datasheet). These sources are useful cross-checks, not a claim of compliance with a newer Base revision.

No finite teaching catalogue covers every edge case. The status and source beside each recipe explain what is demonstrated and what remains to be verified.

Sources and revision boundaries

Reviewed 27 September 2026. Supplied AMD 3.11 and Arm H.a PDFs are the normative baselines. Public URLs can change edition. PCIe sources below have the limited scope stated in the guide.

• AMD 48882-PUB 3.11, April 2026
• Arm IHI 0070 H.a, 6 March 2026
• AMD PG054 3.3 · Error Detection (PCIe implementation guidance)
• Intel 710 Series datasheet 4.1 · PCIe request boundaries and limits
• AMD PG054 · Tracking Non-Posted Requests and Inbound Completions
• AMD PG054 · Completion Timeouts
• AMD PG054 · Completer Abort
• PCI-SIG FAQ · PCIe 3.1 §6.20 PASID on Completions
• PCI-SIG PCIe 3.0 FAQ · permitted error classifications