VALIDATION / NEGATIVE TESTING
Break the assumption. Test the recovery.
Presence, permissions, invalid encodings, lost notifications and stopped engines—the failure paths deserve the same care as a successful translation.
Negative testing is where validation earns its keep. These examples, built on the site's emulated IOMMU, show how to isolate a trigger, check the error evidence, confirm that forbidden work did not happen, and recover without hiding the original failure. Section 1’s method needs no background; the fault list after it assumes the Translation lab.
What claims does this page make? 3 points
- Spec rule: the ten commands (AMD 48882 §2.4), the log restart sequences and the Arm CMDQ/GERROR protocol are required behaviour in the cited specifications.
- Platform assumption: whether a given reserved bit or invalid entry is detected, and how long a cache keeps an invalid entry, varies by IOMMU implementation.
- Teaching model: injected hardware aborts, eight-slot rings and the stale-cache snapshot are fixtures of this site, not real poison or real hardware.
One injection. A precise expectation.
- Establish the baseline: record the request, device/PASID, capabilities, mapping, cache state and enabled logging.
- Change one condition: identify the exact bit, descriptor, command or injected transport failure.
- Check both outcomes: inspect the event/status and prove that rejected work copied no bytes or did not complete.
- Repair and retry: publishing a fix, invalidating cached state, observing completion and retrying are separate milestones.
A hardware-access failure is a synthetic injected condition here. Setting a reserved bit does not create a memory poison error. A full log is also not the same as a full command queue.
1 / Inject a mapping or device error
The baseline has SNP/SEV-TIO off, DTE.I=1, SATSSup=0 and CXLMemAttrSup=0. This fixture reuses the DMA lab’s walker and byte-copy model, with selected raw-field checks in front of it. Change read/write or compare an untranslated request with ATS. Repairing the backing entry deliberately leaves the cached test snapshot stale until the invalidation step, except for a guest write denial: AMD §2.2.7.3 requires a fresh guest-table walk after one, so that retry succeeds without invalidation.
No request has run.
Run the selected request.
Select a changed field to inspect its bit and source.
Inspect original, backing and cached words
Cache lifetime is deterministic in this fixture; real hardware need not retain a particular invalid entry. The named raw-field checks are a selected subset. Hardware-abort cases inject a failure outcome, not real poison. Ordinary DMA uses a 16-byte payload; ATS never copies that payload.
Download the reusable negative-test module · Open the main DMA lab and C++ export
2 / Commands, ownership and recovery
All ten commands from AMD 48882 §2.4 are available in the command fixture. Event, PPR and GA logs expose their producer/consumer and recovery actions. Each selection retains its state. The B-log selections represent a selected bank in an isolated fixture; they do not create extra physical engines or implement autoswap.
Commands execute serially in this fixture. COMPLETION_WAIT uses notification (i=1); prefetch uses a valid mapped GPA; PPR response uses one synthetic work-item identity; RESET_VMMIO uses VCmd=1 / All=0. INSERT_GUEST_EVENT consumes two slots. These are semantic command records, not a complete packed-command encoder.
Attempt a pointer write
Try a misaligned offset, a hardware-owned pointer, or a Head advance beyond available records. These controls reject unsafe software writes; they do not invent a hardware exception for behaviour the architecture does not guarantee to detect.
Inspect execution and error evidence
Eight slots make wrapping visible; this is not a legal hardware allocation. Diagnostic records are collected separately from the selected ring, so this fixture does not model failures of its diagnostic sink. Interrupt notification is assumed enabled. Record-written flags and overflow-triggered interrupts are distinct; GA overflow alone creates no fresh GA interrupt.
Download the reusable buffer model · Buffer registers, command sequencing and GA decoder
3 / Error families and scenario checklist
Use the checklist to choose a trigger, expected evidence and recovery. “Reference” scenarios require facilities beyond this executable subset. Capability-specific and hardware tests must be adapted to the target platform.
Event codes: the event-specific Figure
66 / Table 68 define EVENT_COUNTER_ZERO as 0xA;
§§2.5.12–15 define the subsequent feature-specific records. This page
uses those specific definitions. An event code must always be
decoded within its record family.
4 / Evidence that recovery really worked
For an illegal command or command-read hardware error: preserve the event and offending command, wait for CmdBufRun=0, clear CmdBufEn, repair backing/entries or pointer configuration while stopped, then re-enable. Hardware can have prefetched ahead; the current Head alone does not always identify the offending command.
For event/PPR/GA overflow: preserve available records, make space, observe the log’s stopped state, disable its logging control, adjust allocation/pointers as necessary, clear that log’s overflow bit using W1C, and re-enable. Do not replay lost requests blindly. Reconcile outstanding PRI work or guest pending interrupts with their owners.
Acknowledgment is not repair. Clearing a notification does not drain a ring; draining does not restore permissions; restoring a PTE does not invalidate a cached translation; invalidation does not retry a descriptor; reading a GA entry does not perform guest EOI.
Check the successful retry and the absence of unintended writes. For a cross-page transfer, preserve completed bytes from earlier valid segments and assert zero bytes from the rejected segment. Test both read and write, ATS and untranslated paths, and repeated cycles—not just one injected error followed by a reset.
5 / Arm SMMU is an IOMMU architecture
The comparison is AMD IOMMU versus Arm SMMUv3. SMMU is not a competing category outside IOMMUs. The protection problem is similar; the descriptors, event formats and recovery protocols differ.
Do not port the AMD W1C/re-enable routine into Arm CMDQ recovery. Arm reports command errors using CMDQ_CONS.ERR (CERROR_*) and GERROR/GERRORN; its global error acknowledgment is a matching-bit protocol. Its queue index/wrap arithmetic and event-overflow acknowledgment also differ from AMD Head/Tail byte offsets.
Read the checked fault and recovery comparison. It includes the conditional detection of reserved command fields, CMDQ restart, EVTQ overflow and stalled-event preservation.
Sources and executable boundaries
- AMD IOMMU 48882 rev 3.11: Tables 7, 16–18, 42–55; §§2.4–2.7; §2.5.16 validation/reporting; MMIO control, status and pointer definitions. Publisher PDF.
- Arm IHI 0070 H.a: §§3.5, 4.1.3, 7.1, 7.4–7.5 and the CMDQ/GERROR register definitions.
- Linux AMD driver and SMMUv3 driver for implementation cross-checks.
All injections operate on synthetic browser data. No real MMIO, DMA, poisoned memory, SNP/RMP state or employer validation code is accessed. The C++ export belongs to the main DMA model; these additional negative and buffer fixtures are reusable JavaScript modules with automated tests included in the source update. They are not a complete hardware emulator or a whole-spec conformance claim.