About Hypervisor Cheats, Part 5: Advanced I/O, GPU, CXL, and Trusted Device Boundaries

Part 4 followed CPU-side state across current roots, views, exits, and timers. Part 5 follows the same idea into devices, where requesters, mappings, queues, fences, and trusted links can all change independently.

Scope

Part 4 followed per-vCPU state, EPT/NPT views, exits, interrupts, timers, nested virtualization, and secure-memory boundaries. Part 5 follows requests that leave the CPU and pass through an IOMMU, device queue, GPU scheduler, CXL decoder, trusted link, or virtual-device backend.

“Below the OS, so it can read memory” is no longer precise once modern I/O enters the picture. Every request comes from a particular requester. It may carry a PASID, reuse an ATS-cached translation, fault through PRI, complete through a queue, synchronize through a fence, or cross a protected TEE-I/O link. Reset, rebinding, invalidation, migration, and teardown can preserve a familiar numeric identifier while changing what it refers to.

The article begins with SR-IOV, SIOV, SVA, PASID, ATS, PRI, ENQCMD, IOMMUFD, and interrupt delivery. Two CPU sections remain here because device work depends on CPU state: a catastrophic VM transition can destroy the per-core context that submitted or observed a request, while XState controls the register and protection state carried across that transition. The later sections follow GPU and accelerator work into fences and frames, then cover CXL routing, trusted device assignment, and paravirtual backends.

Most cheats do not need CXL, TEE-I/O, or a paravirtual device. These mechanisms matter because they show where acquisition, translation, synchronization, and delivery can move. A process handle may give way to a VMM, assigned device, host backend, or accelerator queue. CPU page tables may give way to an IOMMU domain, PASID-bound SVA path, GPUVA space, or CXL decoder route. An in-process overlay may move to a host compositor, capture path, companion display, stream, or virtual input path.

Moving the work changes where it runs, not the need to deliver a result. A PASID-tagged descriptor, DMA completion, GPU fence, CXL-backed page, or TDISP-protected transaction becomes useful to a cheat only when it reaches a current game object, frame, decision, or input event.

A hypervisor-assisted radar reader provides the running example:

VMM tracks the current game process and address space
  -> device or host path reads or transforms selected state
  -> GPU, capture, stream, or companion path delivers the view
  -> player reacts through normal or synthetic input

Part 4 asked whether a CPU-side sample belonged to the right process, view, and frame. Here the questions move outward: which address space the device used, whether its cached translation was current, whether an interrupt belonged to the completed descriptor, whether a GPU fence reached the displayed frame, whether the inspected range included CXL-backed pages, and whether trusted I/O changed plaintext visibility or the transaction itself.

---

Advanced I/O Virtualization: SR-IOV, SIOV, SVA, PASID, ATS, PRI, and ENQCMD

Device access is not one primitive named “DMA.” Modern platforms split it into device identity, address-space identity, translation lookup, translation caching, recoverable faults, queue submission, interrupt delivery, and sometimes trusted-device state.

These mechanisms let a device-facing path operate closer to a target process than old physical-address DMA. SVA associates device work with a process address space. PASID carries an address-space tag in the PCIe transaction, ATS lets the device cache translations, and PRI turns some missing translations into recoverable page requests. To identify the bytes that a command produced, the record still needs the process, queue, translation entry, descriptor, and completion.

The minimum model keeps each I/O stage separate:

function or device interface
  -> requester ID: bus/device/function, PF, VF, or assignable device interface
  -> optional PASID: process address-space tag carried in PCIe TLPs
  -> DMA-remapping context: root/context/scalable-mode tables or AMD IOMMU equivalent
  -> optional device translation cache: ATS ATC or device-side TLB
  -> optional recoverable fault path: PRI page request and response
  -> interrupt path: MSI/MSI-X through interrupt remapping
  -> host, guest, or confidential-VM memory context

Each marker identifies one stage. A live PASID selects an address-space binding. ENQCMD acceptance records submission, a PRI response records translation recovery, and a completion records device or queue progress. Resolve that completion through the current process page before assigning it to a game object.

Translation Caches, PRI, and Invalidation Order

Translation tables and translation caches do not update together. CPU TLB invalidation, IOMMU IOTLB invalidation, and device ATC invalidation are different actions. A CPU page-table update can be correct while the device still holds a stale ATS translation. A queued invalidation may remain pending while a device queue contains older work. A PRI page request can recover a missing translation after the page has stopped holding the game object under discussion.

Follow invalidation in execution order. A CPU translation, IOMMU translation, device translation cache, and interrupt route are separate pieces of state, so a single “flushed” sentence is usually too vague:

State	Required runtime detail	Failure if absent
IOMMU mapping	domain, context, PASID/RID, page-table root or equivalent mapping object	the mapping is not tied to the request
IOMMU IOTLB	IOMMU translation-cache entry, domain, PASID/RID target, invalidation type and completion	the IOMMU may still use an older translation
device ATC	ATS enablement, endpoint identity, PASID/RID target, ATC entry lifetime, device-side invalidation or drain	the endpoint may still use an older ATS translation
queued invalidation	descriptor type, target domain, PASID or device, completion wait or fence	invalidation completion remains unobserved
PRI recovery	page request, fault address, PASID/RID, response, retry or failure path	the page request is not tied to the retried transaction
later transaction	mapping generation, invalidation completion, device drain, CPU reread or another memory comparison	the device may have used an older translation or descriptor

The ordering is concrete:

accepted work descriptor
  -> requester identity and PASID/RID binding used by that descriptor
  -> IOMMU mapping selected for the request
  -> IOTLB or device ATC entry actually consumed
  -> PRI request and response if the access faulted
  -> completed invalidation and device drain where required
  -> completion, interrupt, or memory comparison for that work item
  -> current process page and game object

Without that chain, the captured fields describe only the device’s translation configuration. Timing must also line up for a current-process read: the mapping may be current while the device cache, queue descriptor, PRI response, or completion interrupt still belongs to an older transaction.

A completed page response says that software handled that request group. The retried transaction may still fail, use a mapping that changed again, or reach a page whose object lifetime ended before the retry.

In Intel VT-d, the recoverable-fault path is centered on a Page Request Queue and a Page Group Response descriptor submitted through the queued-invalidation interface. The generic phrase “page response” should not erase the group index, PASID presence rule, queue head/tail state, or ordering requirement.

Linux has another layer of vocabulary. The generic IOMMU fault interface carries flags, an optional PASID, a page-request group index, requested permissions, a fault address, and private device data in struct iommu_fault_page_request; its response object carries the PASID, group index, and a response code such as success, invalid request, or failure. IOMMUFD then exposes a separate IOMMUFD_FAULT queue object for HWPT page faults using PRI, so a userspace VMM can poll and respond to those events.

Those are three different layers: architecture descriptor, kernel fault abstraction, and userspace VMM/API delivery.

PRI, PRS, PPR, Page Request, and page-response records are interpretable only when the native fields remain visible:

Protocol field	Direct meaning	Record limit
page-request queue or PPR log	a device-originated recoverable translation request reached the IOMMU/driver path	game relevance of the requested page
request group index	several page requests may be grouped for one response decision	completion of the original descriptor
PASID-present and response-needs-PASID state	whether the OS interface requires the response to carry the same PASID as the request	process identity behind the numeric PASID
requested permissions and address	requested read/write/execute-like access and reported fault address	completed memory effect
page group response or kernel page response code	success, invalid request, failure, or retry decision	consumption of current object bytes
queue overflow, timeout, drain, or abort	the fault path lost, delayed, or terminated request processing	subsequent device activity
IOMMUFD fault queue fd	userspace can observe and respond to HWPT I/O page faults through the IOMMUFD API	endpoint-local logic or a player cue

Under PRI/PRS/PPR, a successful response may mean only that software populated the translation and authorized the device to retry.

For a DMA-hybrid cheat, these features improve address-space precision. PASID/SVA can associate device work with a process address space, ATS avoids repeated IOMMU walks, and PRI can recover a missing translation. They also introduce new failure modes: stale ATC state, incomplete queued invalidation, PASID mismatch, descriptor replay, reset without drain, or a PRI response for a page that no longer backs the semantic object.

Interrupt Delivery Is Not Completion

Interrupt remapping describes how an MSI/MSI-X or I/O APIC message is isolated, translated, routed, or posted. It carries no confirmation that the associated DMA completed, that the descriptor used the current PASID, or that any result reached the player. Treat the interrupt as notification until the same queue and descriptor identify the completed transaction.

In a DMA hybrid, an interrupt often arrives before software can check the memory effect. The detailed VT-d, posted-interrupt, AVIC, and guest-delivery discussion follows the SIOV lifecycle so that requester identity, IRTE state, queue completion, and output remain adjacent.

What These Primitives Change for a Hypervisor Cheat

Advanced I/O virtualization adds identifiers and caches rather than one stronger form of DMA. SR-IOV gives a VF its requester identity but leaves PF policy and reset above it. SIOV scales assignable interfaces through PASID-granular contexts. SVA and ENQCMD can associate work with a process address space. ATS adds the device ATC, PRI adds recoverable faults, interrupt remapping adds a separate delivery route, and IOMMUFD exposes page-table and fault objects to userspace. Each mechanism is useful only with the specific requester, mapping, queue, and completion that used it.

ENQCMD, IA32_PASID, and Submission Lifetime

ENQCMD and IA32_PASID deserve a separate lifecycle model because they make “device work used a process address space” a timed statement rather than a static capability statement. Linux x86 SVA documentation describes a process-level PASID allocated when an SVA-capable device is opened or bound, lazy loading of the thread-scoped IA32_PASID MSR on first ENQCMD use, a first-use #GP path when the MSR has not yet been initialized on that logical processor, fork/exec removal of the PASID when the address space changes, clone inheritance when the address space is shared, and lazy cleanup on unbind or address-space exit.

That lifecycle matters because a sampled PASID value, a mapped device portal, and a completed device command can come from different bindings or requests.

An SVA/ENQCMD trace passes through the following states before it can support more than a device-address-space observation:

State	Meaning	What must be observed	Failure class
PASID assigned to an address space	the OS assigned a PASID after a device open/bind path	process mm, device file or binding, PASID allocation trace	PASID belongs to an older or different address space
submission portal mapped	a user mapping can submit work to a device workqueue	mapped portal, hardware workqueue identity, device, permissions	portal identity is confused with command execution
IA32_PASID loaded for a thread	the thread’s PASID state is loaded on the current logical processor for ENQCMD tagging	thread identity, destination CPU after migration, XSAVE supervisor-state handling, first-use #GP if applicable	sampled thread never submitted the work
ENQCMD accepted	the instruction submitted a descriptor with non-posted acceptance semantics	descriptor identity, portal, PASID value, acceptance status, retry path	accepted descriptor is mistaken for completed DMA
ATS/PRI translation serviced	the device obtained or recovered translations for the tagged address space	ATS request, ATC state, PRI request/response if faulted, IOMMU/PASID entry, invalidation completion	stale ATC entry or failed PRI path treated as fresh memory
device effect confirmed	the work item produced a specific memory, completion, or interrupt effect	command completion, device drain, memory comparator, interrupt route, reset/retry state	completion is attributed to the wrong descriptor or process

The process address space, thread MSR, work queue, and translation service change independently. They must refer to the same operation before the trace shows more than work submitted in an address space:

Lifetime	Advanced by	Why it matters
address space	fork, exec, clone with shared or non-shared address space, mm teardown, SVA bind/unbind	the numeric PASID can be reused after the binding changes
thread and MSR state	first-use #GP, lazy IA32_PASID load, migration to another logical CPU, context switch, XSAVE supervisor-state save/restore	CPU migration changes where the thread state must be loaded, not the process/device binding itself
work queue	portal map/unmap, descriptor write, ENQCMD acceptance or retry, queue drain, reset	accepted work is not completed work, and a stale descriptor can outlive the mapping it used
translation service	ATS lookup, ATC fill, queued invalidation, PRI request/response, mmu-notifier propagation	process page-table currentness is not device translation currentness

IA32_PASID identifies the thread’s address-space tag. ENQCMD acceptance identifies submission, a PRI response identifies translation service, and an interrupt identifies notification. Process-memory attribution comes from matching the completed descriptor to the current page and object.

Virtualization makes the name PASID ambiguous across layers. Linux SVA documentation uses IA32_PASID as the thread-scoped process tag for ENQCMD submission, while Intel Scalable IOV material uses PASID-granular translation to distinguish address domains for ADIs and VDEVs. In a VM path, the device-visible request can refer to a guest virtual address space, a guest physical address space, a host I/O virtual address space, or a nested translation function, depending on how the VMM, vIOMMU, physical IOMMU, and device composition module are wired. A numeric PASID is meaningful only beside the address space, requester, and binding that assigned it.

Layer	Context that must be named	What makes it current	Unsafe shortcut
Linux process SVA	process mm, thread IA32_PASID, device binding	PASID allocation, first-use #GP or loaded MSR, portal mapping, mmu-notifier invalidation	PASID number is treated as a global process id
Guest SVA	guest process address space, guest PASID view, guest driver and workqueue	guest bind path, vIOMMU view, accepted descriptor, guest-visible completion	guest PASID is mistaken for a host IOMMU transaction
Host IOMMU	physical RID, PASID entry, scalable-mode table, domain or nested translation root	IOMMU table state, invalidation completion, fault or PRI response, requester id	host IOMMU entry is treated as game object semantics
ADI or VDEV composition	assignable device interface, VDCM, virtual device identity	ADI allocation, VDEV composition, direct-path vs intercepted-path split, reset/fault generation	virtual interface identity is treated as process-native access
Device-side cache	ATC entry, device TLB, queue context, completion route	ATS lookup, ATC invalidation, PRI response, queue drain, completion or interrupt	accepted descriptor is treated as fresh bytes

In a VM, record which layer allocated each PASID. The guest tag and host IOMMU PASID may name different address spaces, and IA32_PASID identifies neither the device interface nor the completed descriptor. Resolve the completion through the guest and host translations before attaching it to the current process page.

Intel DSA/IDXD shows how many objects sit between an SVA-capable accelerator and a process byte. Linux SVA documentation uses DSA to explain iommu_sva_bind_device(), PASID allocation, mmu_notifier()-driven device-TLB synchronization, and ATS/PRI participation. Intel’s DSA user guide separately names the platform and driver prerequisites for user-space memory: VT-d, Intel IOMMU scalable-mode/SVM support, the idxd driver, and either dedicated or shared work queues.

The device and idxd driver identify the accelerator and its kernel driver. Scalable-mode and SVM enablement make process-address-space translation available, but the individual request still needs the target mm and current translations. Queue mode changes submission semantics as well. A shared work queue accepts PASID-tagged descriptors from multiple clients, while a dedicated queue partitions work and may use MOVDIR64B with descriptor-supplied PASID semantics rather than the thread IA32_PASID behavior of ENQCMD.

Completion, fault, retry, block-on-fault, and software fallback then decide what actually ran. A high-level library call may stall, fall back, or complete on hardware. Following one DSA request requires the work-queue mode and client, descriptor, translation, completion or fault, process page, game object, and delivery route.

IOMMUFD PASIDs and Lost Events

The current Linux IOMMUFD uAPI exposes HWPT_PAGING, HWPT_NESTED, vIOMMU, vDEVICE, vEVENTQ, HW_QUEUE, and a PASID-capable HWPT allocation flag. The flag requests a domain that may attach to any PASID on a device; the attachment operation supplies the PASID and device identity elsewhere. The overview also notes that the ordinary device-to-IOAS path still supports at most one IOAS per device. Working PASID attachments depend on the uAPI path, IOMMU driver, VFIO backend, and device.

IOMMU_HWPT_ALLOC_PASID marks the allocated domain as PASID-capable. The actual PASID and attachment identity are supplied elsewhere. Successful allocation leaves two questions open: which PASID was attached, and whether the endpoint issued a request through that domain. Runtime probing must also distinguish ENOTTY, which means the ioctl is unknown, from EOPNOTSUPP, which means the command is understood but that mode is unavailable.

Object or field	Direct meaning	Still required before claiming a device used a process address space
IOAS	userspace-managed IOVA-to-memory map	bound device, active HWPT, current mapping, and transaction
HWPT_PAGING	hardware paging domain, either an unmanaged stage 1 or nesting parent stage 2	compatible device attachment and current invalidation state
HWPT_NESTED	userspace-managed nested stage-1 page table attached to a nesting parent	guest address space, stage-1 invalidation, and physical request
IOMMU_HWPT_ALLOC_PASID	request for an HWPT domain that may be attached at PASID granularity	the PASID value, device attachment, and request carrying that PASID
vIOMMU and vDEVICE	virtualized IOMMU slice and the device identity presented through it	physical requester, translated address, and completion
VFIO_IOAS_CHANGE_PROCESS	transfer of pinned-memory accounting under the documented constraints	association with subsequent DMA or game semantics

Event delivery uses two different queues. IOMMUFD_FAULT is the PRI-backed page-fault queue for an HWPT; userspace can poll requests and return page responses. vEVENTQ belongs to a vIOMMU and carries nested-translation or hardware-specific events, explicitly excluding the I/O page faults delivered through IOMMUFD_FAULT. A monitor attached to one queue misses events assigned to the other.

Each vEVENTQ record has a sequence index in [0, INT_MAX]; the value after INT_MAX wraps to zero. Loss is detected from a wrap-aware delta greater than one. If loss occurs at the tail and no later event can reveal the gap, the queue appends an IOMMU_VEVENTQ_FLAG_LOST_EVENTS header. The queue can also overflow at veventq_depth. A no-event result needs the queue type, vIOMMU and vDEVICE ids, wrap-aware sequence range, depth, loss flag, and a live reader.

IOMMUFD exposes the objects needed to construct a guest/device translation path, but the objects alone do not describe a running request. Tying one request to process memory requires the running kernel, accepted ioctls, backend capabilities, device attachment, completed invalidations, fault handling, and final request to agree.

Hardware Queues Move the Trap Boundary

IOMMUFD also defines IOMMUFD_OBJ_HW_QUEUE. It represents a vIOMMU-associated queue that the IOMMU hardware can read or write directly in guest-owned queue memory. The VMM receives an MMIO mapping description and can map the queue controls into the guest, allowing the guest to drive that queue without a VM exit or hypercall on every operation.

That changes where observation is possible. With an emulated queue, the VMM naturally sees control updates as traps or hypercalls. With a hardware queue, the control path can move into shared guest memory and MMIO, while faults and queue-specific events arrive through separate objects. The current public documentation names NVIDIA Tegra241 CMDQV as the concrete queue type; it should not be generalized into a ubiquitous x86 endpoint feature.

An HW_QUEUE record identifies queue allocation and guest-visible control state. Endpoint DMA, the process page named by an entry, and consumption of a game object are later steps. They require the vIOMMU, queue index, nesting_parent_iova, mapped MMIO range, hardware producer or consumer, event path, and completed transaction in one lifecycle.

Dynamic Memory Without PRI

PRI was designed so a device can raise an I/O page fault instead of requiring every guest page to remain pinned. It is architecturally clean, but NICs and storage devices have not adopted it broadly. The OSDI 2025 VIO work demonstrates another design point: observe the guest’s virtio available queue, inspect the I/O physical addresses before passthrough, prepare the corresponding mappings in software, and switch between an intercepted VIO path and direct passthrough as load changes.

This approach moves the page-fault decision out of the endpoint. The device can continue on a direct path after software has made the buffers safe to access, while the shadow available queue and IOPA-snooping path retain enough control to avoid device-generated I/O page faults. The design targets cloud virtualization rather than gaming systems. It also demonstrates dynamic guest memory without PRI when software inspects the submission queue before passthrough.

Dynamic device access can occur without PRI traffic. A virtio or vhost data-plane interposer may have seen the offered buffers before the physical device did. The relevant chain becomes guest descriptor -> shadow queue observation -> mapping preparation -> passthrough request -> direct interrupt, with a recorded mode switch between the intercepted and direct paths. Only after those objects are tied to the target process and game state does the mechanism become cheat-relevant.

What an IOMMUFD Access Object Represents

IOMMUFD documentation draws a sharp distinction around iommufd_access. It is a kernel driver’s path into an IOAS, not a DMA transaction. The helpers can pin pages under an IOVA or copy bytes to or from an IOVA-backed range, and the caller is responsible for stopping access and unpinning at the end of the lifetime.

That is a CPU or kernel-side path through the IOAS object graph. A physical requester, PASID-tagged TLP, ATS lookup, PRI request, ATC entry, completed descriptor, or completion interrupt is not part of that operation.

This distinction matters because IOAS access can look like a convenient byte-acquisition path in hosted VMI or device-assignment work. An access object may pin IOAS-backed pages or copy bytes through a kernel-mediated path. Even if the same IOAS is attached to a device, that CPU-side access is not a device request. A device statement also needs the requester, DMA direction, PASID if present, translation and cache state, descriptor, and completion.

SIOV ADIs, Shared Work Queues, and Reset Drain

SIOV and ADI language needs a stricter reset and interrupt model than a classic VF-only description. In the Intel SIOV technical model, software-visible work can be directed through scalable device or interface abstractions and PASID-scoped contexts, but those abstractions do not all carry the same identity.

A memory transaction can carry requester and PASID context. A submitted descriptor can belong to a shared work queue or portal.

An interrupt can report device or queue progress without identifying the PASID used by the memory transaction. An ADI reset can require the device to complete or abort outstanding DMA reads, DMA writes, ATS requests, and PRS/page-request activity before the reset boundary is safe to cross.

RID/PASID identity, assignable-interface state, shared-work-queue state, and reset-drain completion advance independently. An ADI may exist without a current PASID binding. A queue may accept a descriptor without completing its memory effect. An interrupt may report progress without naming that descriptor. Reset may drain or abort old work; resolve the mapping and queue again afterward.

The reset boundary is especially important for stale-state analysis. A device can be correctly assigned and still have translations, descriptors, PRS responses, interrupts, or posted completions left from the previous assignment. Treat reset as a new transaction generation unless the trace follows the pre-reset descriptor, outstanding DMA and ATS/PRS requests, generated completions, reset or abort, cache and queue invalidation, and the first post-reset descriptor through a fresh translation and completion.

Queue assignment, PASID binding, reset, and interrupt delivery can change independently. The same descriptor may move to another shared work queue or PASID, and an interrupt may arrive without that descriptor. An ADI reset can also leave an old queue identifier in telemetry. Only matching work, translation, and completion generations identify the transaction.

If it follows only the interrupt route, the trace says where notification traveled. If it follows only the reset, it says when the ADI lifetime changed.

Posted Interrupts and Completion Ordering

Interrupt remapping deserves its own analytical boundary because a device interrupt is not a device memory transaction. DMA remapping answers where a device memory request may go. Interrupt remapping answers how an interrupt message from a device or I/O APIC source is isolated, translated, routed, or posted to a destination. Completion queues, MSI/MSI-X messages, interrupt-remapping entries, posted-interrupt descriptors, guest APIC state, and Windows ISR/DPC execution are different clocks. Seeing any one of them is not enough to say that the device read game memory or that the player received a cue.

The source material describes those mechanisms independently. Intel VT-d defines interrupt remapping and interrupt posting as functions distinct from DMA translation.

Xen’s VT-d posted-interrupt design gives us concrete implementation terms. An interrupt source carries an identity and remapping index. Its interrupt-remap-table entry can point to a posted-interrupt descriptor, which holds a request bitmap and notification fields. The notification destination changes as the vCPU is scheduled. QEMU exposes the corresponding emulated-vIOMMU controls: intel-iommu and amd-iommu have explicit intremap options, AMD vIOMMU interrupt remapping depends on irqchip mode, and x2APIC can require extended interrupt-remapping table support.

AMD’s public IOMMU overview likewise separates DMA remapping from interrupt remapping. It even describes passthrough configurations that retain interrupt remapping while I/O remapping is disabled. An interrupt trace can establish the route and delivery state, but payload, target address, process association, and game meaning come from other records.

A complete interrupt record links the source, remapping policy, virtual delivery route, completed device transaction, and player-facing result. MSI/MSI-X, IOAPIC, IRTE, posted-interrupt, AVIC/GA, and vIOMMU state describe different stages of what may look like one signal.

Interrupt stage	Native records	Route or delivery fact	Record limit
interrupt source inventory	requester id, IOAPIC pin or MSI/MSI-X table, vector/message address/data, device function, queue or completion source	the possible source is narrowed	device memory transaction
remapping enablement	VT-d/AMD IOMMU interrupt-remapping capability, active root/context or IVRS/DMAR table, vIOMMU option, irqchip mode	the active remapping policy is identified	confirmed isolation or delivery
IRTE or equivalent entry	remapping index, source id validation, destination, vector, delivery mode, trigger mode, present/valid state, x2APIC or extended-destination support	the programmed interrupt route is known	completed work or fresh bytes
posted-interrupt path	posted-interrupt descriptor address, PIR bit, virtual vector, ON/SN/NV/NDST-like notification fields, vCPU scheduling interval	the virtual delivery route is known	guest handler ran or device work completed
guest delivery	guest APIC IRR/ISR, virtual interrupt injection, ISR/DPC or driver callback, completion queue read, interrupt coalescing policy	guest handling is observed	semantic game object or player cue
transaction correlation	descriptor/work item, DMA direction, IOMMU translation freshness, device completion, memory target, process page, object lifetime	the interrupt is tied to one device transaction	player-visible advantage
delivery-to-behavior relation	overlay/cue/input route, frame/tick alignment, replay/server consequence	possible relation between the cue and later action	standalone interrupt detection

“An interrupt arrived” is too weak to establish a current route. The source and remapping entry must come from the same configuration, and the destination or posted-interrupt descriptor must match the current vCPU. A memory effect also requires the matching completion or queue generation. Player-visible behavior requires the guest handler or output path as well.

A trace may establish the interrupt source, remapping policy, or an IRTE or posted-interrupt route while leaving the active destination, guest delivery, work descriptor, and memory effect unknown. Only the matching handler and completion records can connect that route to device work; without them, the result is an interrupt-path observation rather than a game event.

CPU State Behind I/O: Catastrophic VM Transitions

Device assignment, PASID state, posted interrupts, GPU queues, CXL routes, and trusted-device mappings all depend on CPU state that survives launch, reset, resume, and processor hot-add. Rare lifecycle transitions are where that dependency tends to break first.

Normal VM-exits are not the only lifecycle events that matter. Keep routine exits, failed VM entries, failed VM instructions, catastrophic VMX aborts, SVM invalid-state exits, machine checks, triple faults, shutdown state, INIT/SIPI sequencing, CPU hotplug, and power-state transitions separate. Late-launch and boot-stage models are especially sensitive because every logical processor must enter the same configured virtualization run before device state can be trusted.

Rare lifecycle transitions leave very different state from an ordinary runtime VM exit:

Class	Meaning	Resulting limit
VM-instruction failure	VMXON, VMPTRLD, VMLAUNCH, VMRESUME, VMREAD, VMWRITE, INVEPT, or INVVPID reports failure by architectural status	establishes instruction-level failure, not guest execution impact by itself
VM-entry failure	entry checks fail or host/guest state cannot be accepted	establishes that the processor did not enter the intended guest interval
ordinary VM-exit	a guest-to-host transition occurred and reported a defined exit reason and payload	supports event analysis if payload and control state are current
VMX abort	processor terminates VMX operation abnormally and writes a nonzero architecturally defined abort-reason value to the VMCS abort indicator	catastrophic transition marker, not a normal exit payload
SVM invalid state or shutdown path	VMRUN fails, guest state is invalid, or guest reaches shutdown/triple-fault behavior	must be tied to VMCB generation, save-state, and a system reset or crash record
machine check or fatal hardware error	CPU reports a machine check exception or MCE-class hardware error outside the ordinary virtualization event model	cannot be treated as cheat-specific without platform error telemetry
INIT/SIPI or CPU hotplug	processor lifecycle changes after boot or after virtualization is active	tests per-core closure and late-launch completeness
sleep, hibernate, resume, microcode, or firmware change	platform state changes across power or update boundaries	tests whether control objects, translations, timers, and device assignments were revalidated

Intel places the 32-bit VMX-abort indicator after the VMCS revision identifier. Software initializes it to zero; the processor writes a defined nonzero reason when a VMX abort occurs. The field is distinct from VM-exit reason, VM-instruction error, and VM-entry failure status, and one recorded reason cannot enumerate every condition that may have contributed to the abort. A useful transition record also needs the VMCS region, logical processor, reset or crash point, machine-check context where applicable, and the first later sample after VMX operation is re-established.

The phrase VM-exit failure is ambiguous. Intel architecture defines ordinary VM-exit reasons for completed exits, VM-instruction errors for failed VMX instructions, VM-entry failure reporting for failed entries, and VMX-abort state for severe problems such as failures encountered during a VM exit. Those are different failure classes. Until the transition path is known, the direct result is a catastrophic transition with an unresolved cause, not another exit reason.

Machine checks require the same distinction. Intel VMX treats a machine-check event during VM entry as a branch in the transition state machine, not as a universal VM-exit payload. Depending on when the condition is recognized and which MCE state is active, the processor may handle it before entry, after entry completes, or as a machine-check VM-entry failure. A nearby WHEA or MCE row remains a platform-error record. Interpreting it requires CR4.MCE, the attempted transition, guest versus host context, the crash or WHEA record, and the first usable sample after the event. It cannot substitute for an ordinary exit payload or a VMX abort.

The sources are layered as well. Intel VMX documentation defines VMX transitions, VMCS state, VM-instruction status, VM-entry failure, VM-exit payloads, and the VMCS abort indicator. AMD SVM documentation defines VMRUN/VMEXIT, VMCB control and save state, exit payloads, invalid guest state, and SVM reset or shutdown paths. Microsoft WHEA documentation covers hardware-error reporting, MCE/MCA records, ETW and system-log surfaces, and firmware or PSHED participation. Windows processor documentation covers OS-visible topology and hot add. Do not blend those vocabularies. Phrases such as “VM-exit failed,” “triple fault,” or “MCE during VMX” remain ambiguous until the native transition, logical processor, retained fields, reset boundary, and guest or host context are named.

Memory events and processor-lifecycle failures require different treatment. A normal EPT violation or NPF can be replayed as a memory event. A VMX abort, triple fault, failed entry, or MCE-class row cannot. To connect one of those failures to cheat execution, the record must identify the logical processor that owned the game workload and show that the transition changed the active SLAT view, interrupt or timer path, or memory-read path used by the monitor. A clean post-reset, post-resume, or post-hotplug state cannot reconstruct the pre-fault VMM unless the trace retains the earlier control object and the first usable post-event sample. Until memory, process, and game state are reconstructed, the record is limited to processor lifecycle, an unattributed catastrophic transition, or the later per-core state.

A cheat-focused description often says “the hypervisor must run on every core.” That sentence is true but too shallow. Every online processor needs matching VMXON or VM_HSAVE state and its own control object. None may remain in pre-launch, post-abort, INIT-wait, hotplug, or resume-reinitialization state, and the interrupt, timer, TLB, and device-invalidation policy must cover every processor that can execute game or probe code.

A benign lifecycle edge is the best control here. A failed VM entry must not become a hidden-cheat event, one offline processor must not stand in for all-core coverage, and a resume reinitialization gap must not be merged with a later EPT event unless both belong to the same transition sequence.

Comparing Rare Transitions

Catastrophic lifecycle records become useful only when steady state can be compared with the transition. The analysis must identify the component that changed, the state that was invalidated, and what survived.

Transition	State that must be re-bound	Common overstatement	Useful control
failed VMLAUNCH or VMRESUME	VMCS pointer, launch state, guest-state validity, VM-instruction error, entry-failure metadata	failed entry is treated as runtime control	replay a legal negative-control entry failure and confirm that the report says only that VM entry failed
VMX abort during exit transition	current VMCS identity, abort indicator, host-state load path, reset/crash boundary, first coherent post-abort sample	abort indicator is treated as a normal exit reason	corrupt only a lab control tuple or emulate host-state failure; process-memory state must remain unclaimed
SVM invalid VMCB or shutdown	VMCB physical identity, clean-bit state, save-state fields, EXITCODE, shutdown/reset record	invalid state is attributed to hidden memory manipulation	replay invalid-state and normal NPF paths side by side and require distinct results
MCE or WHEA-class platform error	MCA bank, corrected or uncorrected class, component, host/guest context, microcode and firmware revision	hardware error becomes cheat attribution	compare with a legitimate virtualization negative control under the same workload and power state
triple fault or guest shutdown	guest activity state, IDT/GDT/page-state context, reset vector, reset extent, crash dump or reset trace	guest reset is treated as endpoint stealth	establish whether the reset was guest-only, VM-only, or platform-wide before attributing it to a game process
INIT/SIPI or AP startup	APIC state, SIPI vector, AP startup code path, per-core VMX/SVM state, interrupt mask and timer state	newly started core is assumed covered by old VMCS/VMCB state	add or reinitialize one processor in a lab and verify that coverage is per-core, not global
CPU hot-add or offline	online processor set, processor-change notification, per-core control object, TLB and interrupt coverage	a newly online CPU is assumed to inherit another CPU’s VMCS/VMCB state	initialize the added processor and record its own control and translation state before scheduling the workload there
core parking or unparking	scheduler targeting and the set of already-online CPUs used by the workload	parking is treated as CPU removal or a VMX/SVM reset	move the workload onto an unparked CPU and verify that it was already included in per-core coverage
sleep, hibernate, or resume	firmware wake event, microcode state, VMXON/SVME state, VMCS/VMCB reload, EPT/NPT root, timers, device assignment	pre-sleep control state is reused after resume	reconstruct the memory view after resume and require a fresh control-state snapshot

This matrix is deliberately asymmetric. A benign transition can contradict a broad statement even when it cannot identify an attacker. If a report says a hidden hypervisor observed all game memory, one hot-added or resumed processor with no post-transition VMCS/VMCB state breaks the word “all.” If a report says a split view persisted across a match, sleep/resume or a microcode change requires a new translation-freshness trace. Catastrophic states are more than crash diagnostics because they limit the continuity that can be reconstructed. Each transition leaves different state behind. A failed entry contains no guest-executed interval unless a later trace shows that execution resumed. A VMX abort leaves an abort marker, not a normal exit payload. WHEA reports a hardware error, not intent. A hotplug callback reports an OS topology event, not per-core VMX/SVM state. A resume event is only a platform transition marker until control objects, translations, timers, and device assignments are rebound. If any of those objects was not restored, the analysis stops at that transition.

Recovery After Late Launch and Boot-Time Launch

Late-launch and boot-stage models fail differently at lifecycle edges. A late-launch model begins after Windows has already established scheduler, interrupt, timer, memory-manager, device, and security state. Its hardest lifecycle invariant is lossless capture and per-core conversion. A boot-stage model begins early enough to avoid live conversion, but its hardest lifecycle invariant is surviving every later platform transition without leaving an impossible boot, firmware, or recovery state.

Model	Lifecycle invariant	What breaks it	Consequence
late-launch thin hypervisor	every online logical processor receives its own VMX/SVM control state before game or probe code can execute there	CPU hot-add, NMI/MCE window, INIT/SIPI, or scheduler migration to an online CPU omitted during conversion	per-core coverage must be checked after hot-add and must include CPUs that were parked during launch
late-launch with legitimate Hyper-V/VBS present	nesting layer, root partition, VTL, enlightened state, and platform security state remain coherent	pre-existing hypervisor control, direct virtual flush, eVMCS/eVMCB clean fields, secure-kernel transitions	“below Windows” wording must identify whether it is below VTL0, below a guest, or inside an L1/L2 execution model
boot-stage or UEFI-adjacent hypervisor	boot measurement, memory map, ACPI, AP startup, sleep/resume, crash dump, and recovery paths tell one platform state	firmware update, Secure Launch/DRTM, hibernation, recovery boot, AP bring-up, device re-enumeration	runtime stealth cannot be stated without boot-chain measurements and recovery traces
hosted or Type-2 VMI	host/guest lifecycle, pause/resume, snapshot, device reset, and time base remain distinguishable	VM snapshot restore, host suspend, vCPU migration, GPU/device reset, host clock discontinuity	endpoint equivalence remains unproven if those lifecycle events cannot be correlated

Steady-state observations and rare-transition records answer different questions. A steady-state run stops before resume, hotplug, crash recovery, or device reset. VMX abort, entry failure, and MCE records identify their native transition classes rather than a cheat. Windows core parking changes scheduler targeting while leaving the logical processor and its virtualization state intact. Hot-add and offline are the processor-lifecycle boundaries here.

Cold boot, warm reboot, sleep/resume, hibernation, processor addition, guest reset, and device reset each create a new continuity boundary. A legitimate Hyper-V or VBS system provides the baseline behavior for transitions that are normal under Windows virtualization. Steady-state observations do not cover any of those boundaries.

Late-launch and boot-stage recovery fail at different handoffs. After late launch, every online processor needs a valid per-core VMCS or VMCB, current EPT or NPT roots, refreshed VPID or ASID state, and coherent timer, interrupt, and device mappings. A boot-stage VMM must restore the same runtime state while also remaining consistent with AP startup, firmware wake, recovery boot, and boot measurements. In either design, “survived resume” is too vague. The first post-resume frame matters only after processor state, translations, timers, interrupts, device assignments, and the game address space have all been rebuilt or checked.

What Survives a Catastrophic Transition

Catastrophic-transition records are often collected after the state that mattered has already vanished. A dump, WHEA row, reset log, VMCS abort indicator, or processor-change notification may be real and still be too late to reconstruct the pre-fault control path. Ask which pre-fault object and transition the record preserves, and which post-fault event first confirms the new state.

Preserve the last good sample, failure marker, destructive or lossy transition, and first usable sample after re-entry or reset. Each retained record covers only one part of that history. A VMCS abort indicator records an abort, WHEA records a hardware error, a processor-add notification records topology, and a crash dump preserves the state selected by the OS after failure. A clean reboot or later game frame describes the new run, not the interval that was lost.

Ordering the Transition Timeline

The word “failure” hides several different architectural transitions. First place the record on the actual timeline, then ask whether it describes guest execution, host handling, reset, or postmortem observation. Intel VMX, AMD SVM, Windows WHEA, and Windows processor-change callbacks each cover a different part of that timeline.

Ordering point	Native record or field family	What can be stated	What must not be inferred
before VMX/SVM operation	VMXON/SVME enablement, capability MSRs, VMXON region or VM_HSAVE state	the processor was prepared, or preparation failed, for virtualization operation	a guest ran or a hidden layer observed memory
VM instruction or VMRUN attempt	Intel VMfailInvalid/VMfailValid and VM-instruction error; AMD invalid VMCB or #VMEXIT(INVALID) class	the transition input was rejected or accepted by a named architecture path	runtime interception or guest-side fault handling
VM-entry consumption	VM-entry controls, guest/host state, MSR-load list, entry-failure indicator, failing MSR index where available	the processor did or did not enter the intended guest interval	any guest instruction retired when the entry failed
guest-executed interval	ordinary VM-exit reason or AMD EXITCODE, qualification or EXITINFO, interruption and vectoring fields	the guest reached a defined exit path with native payload	that the exit payload already describes a process or game event
exit-to-host transition	host-state load, VMCS abort indicator, VMX abort value, AMD shutdown path, crash/reset trace	the transition out of guest execution became catastrophic or unrecoverable	a normal exit reason, a completed handler, or actor intent
platform hardware-error path	WHEA LLHEH, MCA/MCE trace, PSHED data, event log or persisted trace	hardware or firmware reported a platform-health event	malicious cause or hidden-hypervisor attribution
processor topology change	KeRegisterProcessorChangeCallback start/complete/failure state, active-processor enumeration	Windows observed a processor-add lifecycle and per-processor resources may need rebinding	that VMX/SVM state was established on the new processor
first coherent post-transition sample	post-reset control object, processor set, translation root, timer and device generation	a new run exists after the destructive boundary	continuity across the missing interval

The timeline also prevents vendor terms from being promoted too early. A failed VMLAUNCH may populate VMX information fields without ever starting guest execution. A nonzero VMCS abort indicator needs the last valid VMCS identity and a first post-abort sample. A WHEA trace needs its component, severity, firmware or PSHED path, timestamp, and virtualization context. A processor-add callback records topology until the new processor has a per-core control object, interrupt and timer policy, and translation-invalidation coverage.

AMD’s FRED Virtualization specification Rev. 1.10, published in July 2026, illustrates why this ordering matters. It describes FRED-related consistency checks that generate #VMEXIT(INVALID) during VMRUN, while consistency failures during VMEXIT can put the processor into shutdown state. The feature-specific detail should not be generalized to every SVM path. It shows that entry-side rejection and exit-side catastrophe are different result classes even when both are described as failures. Entry failure, ordinary exit, VMX abort, corrected WHEA reporting, fatal machine check, and processor-add start all retain different payloads. An interpretation that treats those records alike is using the catastrophic label instead of the architecture-specific transition.

CPU Hot-Add, WHEA, and Bugchecks

Some catastrophic-lifecycle records come from Windows rather than from the virtualization architecture itself. A processor-change callback, a WHEA trace, and a bug-check callback buffer can all be genuine while describing different points: OS topology, hardware-error reporting, and crash-time driver state. Do not merge them into one hypervisor failure unless the trace identifies the transition that connects them.

The processor-change path is especially easy to overstate. KeRegisterProcessorChangeCallback notifies a driver when a new processor is added to a hardware partition. The notification has a start phase, followed by either complete or failure, and the optional existing-processor enumeration path replays callbacks for processors already active in the partition. A complete notification means the operating system added the processor and made it available for scheduling. Per-core VMCS/VMCB setup, EPTP or NPT roots, APIC virtualization, XState, TLB invalidation, and device assignment remain the monitor’s responsibility. Until those objects are rebound, the callback shows processor topology rather than virtualization coverage.

WHEA has the opposite failure mode. It can preserve a strong platform-health record, but the native chain is hardware-error reporting: an error source, an LLHEH, firmware participation where applicable, PSHED or PSHED plug-in augmentation, a standardized error trace, event-log or ETW exposure, and for some fatal conditions a persisted trace that is surfaced after restart. That chain can contradict clean-continuity wording, especially around MCE, NMI, reset, and firmware paths. It cannot by itself name malicious intent, a hidden hypervisor, a process address space, or a game advantage.

Bug-check callbacks are narrower still. KeRegisterBugCheckCallback registers code that runs while the operating system issues a bug check. Its trace buffer and component string must reside in resident or nonpaged storage because virtual memory may already be unavailable. The callback can reset a device or retain a small resident payload for crash-dump debugging, but it observes crash time rather than live execution. Reconstructing continuity requires a last-good pre-fault sample, the failure marker, the destructive transition, and the first coherent post-transition sample.

Windows documentation makes the boundary sharper. Processor-change notification is a transactional OS callback; monitor initialization on the new processor is a separate event.

The callback runs at PASSIVE_LEVEL; OperationStatus is writable only during KeProcessorAddStartNotify error processing; completion is reported only after the processor has started and is available for scheduling; failure requires rollback of resources allocated during the start phase; and the KE_PROCESSOR_CHANGE_ADD_EXISTING path can replay start and complete callbacks for already active processors before registration returns. The return value of KeRegisterProcessorChangeCallback confirms registration, not successful execution of every callback body that may have run before return.

Callback registration, OS schedulability, and below-OS per-core virtualization rebinding do not share one timestamp. The callback history begins with registration and may replay processors that are already active. An add-start notification is followed by completion or failure; only successful completion makes the processor schedulable. The monitor must then rebind VMX/SVM state, translations, interrupts, and timers on that processor.

WHEA follows a different sequence. The source is not a VM-exit or VM-entry record. Windows discovers hardware error sources, an LLHEH acknowledges, captures, and reports the error, firmware may already have handled part of it, and PSHED can add platform-specific information. Windows then creates a standardized error record that may surface through ETW, the system event log, or a persisted restart trace. Corrected errors, nonfatal uncorrected errors, and fatal uncorrected errors must remain separate. A fatal hardware error can produce a bug check, but the record still describes platform health until its component and severity are tied to the active virtualization context, the samples before and after the transition, and finally the process and game state.

Read each Windows record at the point where it was produced. Add-start means resource preparation has begun; add-complete means Windows can schedule the processor; add-failure means the driver may need to roll back allocations. Existing-processor replay enumerates CPUs that were already active. WHEA distinguishes corrected, uncorrected, and fatal hardware errors, while a bug-check callback preserves only its small resident crash-time payload. None of these records says that the new processor received per-core virtualization state or that a hardware error was malicious.

INIT/SIPI, Wait-for-SIPI, and AP Startup

INIT/SIPI changes one processor’s lifecycle. Machine-wide virtualization state requires a separate record for every processor. A boot-stage or late-launch hypervisor can have a coherent BSP while an AP remains in wait-for-SIPI, has consumed a SIPI vector, is schedulable but lacks a rebound per-core VMCS/VMCB, or has re-entered with stale timer, APIC, TLB, XState, or device-invalidation policy. Claiming all-core coverage requires the startup history of every AP, not a steady-state sample from the BSP.

AP startup proceeds through separate transitions. The table places SIPI delivery, OS schedulability, per-core VMM initialization, and game-process execution on their own clocks:

Clock	Native record	Lifecycle fact	State not yet rebound
processor role	BSP/AP identity, APIC id, processor group, topology generation	a logical processor exists in a named topology role	per-core virtualization state
reset or INIT edge	reset vector, INIT observation, guest activity state, shutdown or wait-for-SIPI state	the processor entered or was modeled as an inactive startup-related state	successful AP startup
SIPI edge	SIPI vector, startup-code run, AP trampoline or firmware path	a startup vector was delivered or modeled	OS schedulability or VMX/SVM initialization
OS topology edge	processor-change callback, active processor set, scheduling availability	Windows can schedule work on the processor after completion	per-core VMCS/VMCB, SLAT, APIC, timer, or XState policy
below-OS rebind	VMXON/VM_HSAVE, current VMCS/VMCB, EPTP or N_CR3, APIC/timer state, invalidation generation	the VMM has a per-core control state for that processor	process, game, or delivery relation

Wait-for-SIPI and shutdown describe guest activity, processor-add completion describes OS topology, and VMX/SVM state belongs to the lower control layer. Their timestamps may be adjacent while still naming different transitions. A BSP trace covers only the bootstrap processor. SIPI delivery precedes AP schedulability, and Windows may schedule that AP before a below-OS monitor restores its per-core state. The restored set must also include the second-stage root, timer and APIC policy, XState policy, and current process context.

VM-Exit Failure and Fatal Host Transitions

The phrase “VM-exit failure” is ambiguous unless it names the architectural condition. Intel VMX has explicit VM-instruction failure and VM-entry failure classes, while ordinary VM exits report a reason and reason-specific payload. There is no routine, symmetric “VM-exit failure” class comparable to VM-entry failure. If a guest-to-host transition cannot complete coherently, the event usually belongs to a different family: VMX abort, host-state load catastrophe, machine check during exit, reset or shutdown, missing post-exit payload, or postmortem-only recovery.

AMD SVM has a different failure shape and should not be described in Intel terms. A VMRUN invalid-state path can produce an invalid-entry-style #VMEXIT, while some feature-specific consistency checks during exit can lead to shutdown instead of an ordinary host-side exit trace. A cross-vendor account should name the attempted transition, the native state that survived, the host state that was or was not loaded, and whether a post-transition sample can still be tied to the earlier guest interval.

Failed VM instructions, failed entries, ordinary exits, aborts, shutdown, and later recovery leave different records. CF/ZF and the VM-instruction error field describe a management-instruction failure. Entry-failure metadata says that the intended guest interval never began. An ordinary exit supplies a reason-specific payload, whereas a nonzero VMCS abort indicator marks a catastrophic transition. MCA/WHEA records identify a platform-health event. SVM invalid-entry and exit-time shutdown paths retain native VMCB and SVM fields rather than Intel VM-entry metadata.

Architectural transition state also differs from data retained by a later observer. Intel VMX lifecycle material can say that software entered VMX operation, attempted a VM entry, reached an ordinary VM exit, or crossed into a VMX-abort/shutdown-style edge.

AMD SVM material can say that a VMRUN input was rejected, that an ordinary #VMEXIT payload exists, or that a feature-specific exit-time consistency path reached shutdown. Windows WHEA can say that a hardware-error reporting chain produced an error trace through LLHEH, firmware, PSHED, ETW, event log, or persistence.

CPU hotplug material can show that topology moved through startup and teardown callbacks. It is useful only when the trace says which facts survived that destructive edge.

Destructive edge	Retained native or observer state	Volatile or lost state	Result before replay
VM-instruction failure	flags, current-VMCS validity, VM-instruction error where valid	guest-executed interval and ordinary exit payload	only the management-instruction failure is known
VM-entry failure	entry-failure class, failing field family, MSR-load index where available	retired guest instruction or runtime interception	entry was rejected; no guest interval was established
ordinary VM exit	reason, qualification, interruption/vectoring fields, guest state payload	fatal host-state loss or reset state	the row supports only the ordinary exit payload
VMX abort or host-transition catastrophe	VMCS abort indicator, current VMCS identity if retained, shutdown/reset or crash context	clean host handler execution and reliable ordinary exit payload	only the fatal-transition marker survives
AMD invalid entry or exit-time shutdown	VMCB identity, SVM exit or invalid-state record where valid, shutdown/reset residue	Intel-equivalent VM-entry metadata or ordinary #VMEXIT payload across shutdown	the result stays within the native SVM transition family
MCE/WHEA path	component, severity, error source, LLHEH/firmware/PSHED path, standardized trace	malicious cause, hidden VMM attribution, process address-space meaning	the row supports platform health only
triple fault or shutdown	activity/reset class, IDT/GDT/page-state context if retained, reset extent	live process-memory view and player-action chain	only the reset boundary is known
INIT/SIPI, AP startup, or CPU hotplug	APIC/topology/startup state, callback phase, schedulable processor set	per-core VMX/SVM initialization, SLAT root, timer/APIC, XState, and IOMMU policy	only topology or startup state is known
crash dump or bugcheck callback	OS-selected dump contents, resident callback buffer, component tag	live runtime scheduler, address-space, and device timelines	the observer is postmortem only

A dump without the VMCS abort indicator no longer identifies a VMX abort. A reboot without the WHEA component and severity retains only the reset, while a later clean frame without the last-good pre-fault sample leaves continuity unresolved. Process-memory language cannot survive after the record that tied it to the earlier run has been lost.

Keep each transition in its native class. A failed entry ends before an ordinary guest interval. An ordinary exit supplies a reason-specific payload; a VMX abort supplies an abort marker and leaves clean host-handler execution unresolved. A WHEA row reports a hardware error rather than intent. After shutdown, reconnecting the trace to process memory requires the last valid guest interval, fatal edge, first usable post-transition sample, and a new process mapping and game frame.

A fatal transition can contradict durability, all-core coverage, or persistence. It can also expose a fragile below-OS layer through crash, reset, or recovery paths. The transition itself is not a positive indication of a cheat; attribution still requires a mechanism, an independent control, process-memory replay, game-object semantics, and an observed delivery or behavior effect.

CPU State Behind I/O: Extended Processor State

CPU-submitted device work inherits state from the submitting thread, OS scheduler, and virtual CPU before the device runs it. Autonomous engines, firmware-initiated activity, inbound network work, and peer-to-peer transactions begin elsewhere. For the CPU-submitted path discussed here, stale or misassigned extended state can leave a valid I/O observation attached to the wrong execution context.

The guest is more than general-purpose registers and control registers. XSAVE-managed components include x87/MMX, SSE, AVX, AVX-512, AMX, APX extended GPRs where supported, PKRU, and CET state selected through XCR0 or IA32_XSS. Other state is adjacent but uses a different path: debug registers and debug-control MSRs, PMU and tracing MSRs, LAM controls in paging and VM state, and SGX enclave lifecycle state such as SECS/TCS/SSA and EPCM. A hypervisor must preserve each family through its defined architectural mechanism rather than treating all of it as one XSAVE image.

The XSAVE family, CR4.OSXSAVE, XCR0, IA32_XSS, XGETBV, CPUID leaf 0x0D, XFD, and OS context-switch policy decide which state exists, which state is user-managed, which state is supervisor-managed, and which state can be dynamically enabled per thread.

The relevant test follows one state family from architectural enumeration through platform and microcode capability, hypervisor exposure, OS enablement, and process or thread permission. It then checks the XSAVE layout, actual workload use, save/restore across the named transition, and the first post-transition observation. Architectural state reaches process memory or behavior only after the affected workload consumes it and produces an output.

CPUID leaf 0x0D can describe a component that the OS never enables. Even after XCR0 enables it architecturally, a process may lack permission to use it; supervisor components selected through IA32_XSS may also be absent from an ordinary user-mode context. XFD adds a first-use boundary by allowing the architecture to advertise a component before the OS allocates storage for the current task. Windows and Linux expose these states differently, but both distinguish system support, task permission, materialized state, and actual use. A parser that merges them can turn normal OS policy into apparent stealth, or hide a real save/restore defect behind a feature bit.

Modern XState spans architectural rules and separate OS interfaces. Intel SDM material defines XSAVE, XSAVES, XCR0, IA32_XSS, XFD, CPUID leaf 0x0D, CET, LAM, PKU, and feature-specific layout rules. Windows XState APIs define what the running OS exposes to applications and debuggers: enabled feature masks, context sizing, compaction, and thread-context manipulation. Linux x86 XSTATE documentation defines a different policy surface: CPUID plus XGETBV discovery, supported versus permitted dynamic features, ARCH_REQ_XCOMP_PERM, first-use traps, AMX allocation, and signal-frame size constraints. An XState analysis must name both the architectural rule and the OS interface it observed.

Before a workload can consume an extended-state component, the CPU must enumerate it, firmware and the VMM must expose it, and the guest OS must enable the right user or supervisor mask. The process or thread may then need explicit permission and a first-use allocation. Only after those steps does an XSAVE image have a meaningful format. Standard and compacted images use different offsets, while XSTATE_BV and XCOMP_BV say which areas are valid and how they are packed. The final checks are actual instruction use and save/restore across the transition being tested.

Extended state is easy for a small hypervisor to mishandle and expensive to keep coherent. A minimal below-OS observer may preserve GPRs and page tables while mishandling AVX upper halves, AMX tile data, PKRU, CET state, or pointer-policy context. The reverse mistake is to find one mismatch and attribute it to a cheat. Until the same trace reaches memory, process, engine, delivery, and behavior, the mismatch is only a transition-consistency test.

XState Layout and State Sources

CPUID enumeration, OS enablement, and transition preservation answer different questions. CR4.OSXSAVE makes XGETBV available; XCR0 selects user components; IA32_XSS selects supervisor components for XSAVES/XRSTORS-style flows. XSTATE_BV then marks valid or non-initial areas in a particular image, and XCOMP_BV identifies the packed form. An absent component may be unsupported, disabled, still in its initial state, not yet dirtied, or deferred by XFD.

A hypervisor can expose AVX-512 to an L2 guest while L1 masks it differently from L0. Linux may support AMX but withhold task permission and storage until first use. Windows requires callers to locate variable XState areas rather than assuming fixed offsets. A crash dump can also contain a well-formed image even if the live VM transition failed to preserve that component. Those cases require the CPUID model, guest masks, OS permission state, image format, and serializer that produced the bytes.

XState Components and Adjacent Protection State

The first eight rows, through CET, are XSAVE-managed state families or include XSAVE-managed state. Debug/PMU state, LAM, and SGX appear afterward because they affect execution, pointers, or memory visibility across a VM transition but are not ordinary XSAVE user components.

State family or adjacent mechanism	Enablement and size state	State container	Hypervisor or host failure class	Failure impact
x87 FPU	CPUID, CR0.TS/EM/MP, CR4.OSFXSR, CR4.OSXSAVE, XCR0[0]	x87 control/status/tag, FPU data registers, FIP/FDP where relevant	lazy-FPU confusion, stale exception state, wrong TS/#NM handling	floating-point corruption or exception timing can reveal transition bugs
SSE/XMM	XCR0[1], OSFXSR, XSAVE size/offset	XMM registers and MXCSR	MXCSR or XMM state crosses VM boundary incorrectly	SIMD, crypto, decompression, and scan code can misbehave without a memory hook
AVX/YMM	XCR0[2], XSAVE component layout	YMM upper halves plus SSE lower halves	only lower XMM saved; upper halves stale or zeroed	vector-heavy game/render/probe workloads become differential probes
AVX-512	XCR0[5:7], opmask/ZMM component sizes	opmask, ZMM high 256, high 16 ZMM registers	partial ZMM preservation or wrong compacted-layout replay	feature presence must match OS enablement and observed workload activity
AMX	CPUID AMX support, XCR0 tile bits, XFD and OS dynamic permission where applicable	tile configuration and tile data	huge/dynamic tile state is absent, disabled, or faulted unexpectedly	strong stressor for context-switch, live migration, and nested-state accounting
APX EGPR	APX architectural source, CPUID/APX exposure, XCR0[19] where supported, XSAVE EGPR layout, confidential-VM policy such as TDX XFAM[19] where applicable	XSAVE state component 19 containing R16-R31	a fixed-offset parser confuses the component number with its standard-format offset, or a VMM omits the component during save, restore, or migration	debuggers, context traces, VMM save/restore, and TD migration need the explicit APX EGPR state area
PKRU/MPK	CPUID PKU, CR4.PKE, XCR0[9] where applicable, PKRU sample	per-thread protection-key rights	below-OS read ignores user-mode access restrictions or stale PKRU	memory-access statements need the PKRU value active for that access
CET shadow stack	CPUID CET, CET MSRs, shadow-stack pointer state, OS mitigation policy	user/supervisor shadow-stack and control state	call/return integrity diverges after VM transition	statements about legal execution need CET state and the exception path
debug and branch-trace state	DR0-DR7, IA32_DEBUGCTL, branch-trace or LBR controls exposed by the platform	VMCS/VMCB fields where defined, MSR-load/store lists, or explicit save/restore code	debug controls or branch state leak across vCPUs or disappear on entry/exit	breakpoints and traces refer to the wrong execution context
PMU and sampling state	architectural PMU enumeration, global/fixed-counter controls, event-select MSRs, PEBS or vendor sampling configuration	virtual-PMU state plus VMCS/MSR-list or VMM-managed save/restore	counters or sampling buffers continue under the wrong vCPU or guest	timing and workload measurements become misleading
LAM or pointer tagging policy	CPUID LAM, CR3/CR4 and OS address policy	pointer interpretation, canonicality checks, tag stripping policy	pointer decoder treats tagged pointers as canonical raw pointers	object reconstruction statements need pointer-policy context
SGX-adjacent state	SGX CPUID, EPC/enclave identity, measurement, AEX/ERESUME path	enclave pages and enclave execution metadata	enclave data promoted to ordinary process memory	enclave identity and host visibility remain separate statements

A feature name in CPUID or a dump is only the beginning. Start with architectural enablement and OS policy, including per-thread or per-process permission. Decode the XSAVE layout and valid-state bitmap, cross the transition under test, and make the workload or exception consume the component. Only then can the result be related to process memory, an engine operation, or behavior.

AVX-512 masking in a nested guest, AMX permission denial under stable CPUID, migration before first XState-heavy use, standard/compacted format changes, CPU hot-add with another feature mask, and restore on a narrower XSAVE destination break at different stages. Continuity ends at the first stage that no longer matches.

Interpreting Bytes Under Protection State

Several extended features change what a byte, pointer, or control-flow edge means to the consuming thread. PKRU can deny a data access without changing the PTE translation. CET adds shadow-stack and indirect-branch rules beyond the visible code bytes. LAM changes how high pointer bits are interpreted before paging. SGX places enclave pages behind EPCM and enclave transitions rather than ordinary process access. AMX may be enabled architecturally while XFD and OS permission defer tile-state allocation until first use.

These controls change which bytes and control transfers are valid for the running thread. A below-OS reader can see bytes that PKRU would deny to that thread. A debugger can see an executable page even though CET would reject the inferred branch or return. A high-bit pointer needs the active LAM mode before it can be decoded. An EPC mapping says little about enclave plaintext without enclave identity, measurement or debug state, and the AEX/ERESUME history. Likewise, an AMX first-use #NM needs the permission request, allocation result, instruction family, and later context state before it counts as successful use.

Ordering Access, Control Flow, Pointers, and Enclave Events

PKU/pkeys add a PTE key plus a thread-local permission register. On x86, the Linux pkeys documentation describes four PTE bits selecting one of sixteen keys and a 32-bit PKRU value with access-disable and write-disable bits for each key; those restrictions apply to data access, not instruction fetch. The relevant order is PTE key -> active thread PKRU -> attempted access type -> fault or success, not merely “which page was mapped.” A second-stage reader may see bytes even when the game thread’s active PKRU would deny the access.

CET shadow stack adds control-flow state that changes over a thread’s lifetime. The Linux x86 shadow-stack documentation separates hardware support, kernel configuration, runtime enablement, loader/runtime enablement, per-thread arch_prctl() state, lock state, /proc/$PID/status state, signal-token state, and shadow-stack PTE semantics. CALL and RET interact with a secondary stack, and a mismatch becomes a control-protection event. Deciding whether an edge was legal requires SSP, thread feature state, loader or module policy, the signal or exception path, and the branch or return that consumed it; executable bytes or a return address alone are insufficient.

LAM adds a pointer-decoding mode before ordinary paging. Intel’s SDM places LAM in linear-address pre-processing before canonicality and paging, and notes that CR2 traces the masked linear address for page faults while invalidation instructions such as INVLPG, INVPCID, and INVVPID do not apply LAM to their address operands.

Linux feature flags add an OS-level boundary: hardware can report a feature even when the kernel disables its use at build or boot time and omits it from /proc/cpuinfo. Pointer reconstruction must retain CPU capability, OS enablement, user or supervisor LAM mode, page-table width, canonicality rule, and decoder policy.

A raw high-bit pointer pattern is not an object graph until the active pointer policy is applied.

SGX creates an enclave lifecycle rather than ordinary process-memory continuity. Linux SGX documentation treats EPC as BIOS-reserved physical memory whose pages are associated with enclaves, tracked by EPCM metadata, and inaccessible from outside the enclave except through special construction mechanisms; EPCM permissions are separate from ordinary page-table permissions and can impose additional restrictions.

It also makes lifecycle instability explicit: EPCM entries may be invalidated, for example across power-related events, and software must handle EPCM faults. QEMU/KVM virtual SGX adds a hosted boundary: guest SGX CPUID and virtual EPC base/size are exposed through QEMU/KVM coordination.

An EPC mapping, virtual EPC trace, or enclave process VMA establishes only a possible enclave lifecycle until the trace identifies SECS/TCS/SSA state, measurement or debug policy, the AEX/ERESUME path, EPCM fault state, and an explicit disclosure or delivery path.

Interpret protected bytes, code, pointers, or EPC state in that order. Establish the architectural capability, OS policy, and owning thread or vCPU before looking at the access, control-flow edge, pointer decode, fault result, or enclave transition that consumed the state. Process or engine semantics require the consuming workload; delivery, replay, and server effects require their own timestamped observations.

Identical bytes can produce different outcomes under another PKRU value, CET shadow-stack state, or LAM policy. An EPC range likewise changes meaning when enclave entry, resume, measurement, or EPCM state changes. These policies belong to the consuming access or transition; the byte pattern alone identifies neither a game object nor a delivery path.

Extended-state inconsistencies expose virtualization defects because the CPU, OS, nested VMM, host VMM, and workload must agree on the active state. A mismatch alone identifies only that divergence. A cheat-specific effect requires the affected game thread and vCPU, the XState component that was enabled and consumed, and a resulting change in address calculation, control flow, or state transfer used by the monitor.

Testing Extended-State Preservation

Validation starts with enumeration. CPUID leaf 0x0D identifies a state class and describes the size and layout of its save area. Enablement comes from the matching architectural and OS controls.

OS enablement comes next. CR4.OSXSAVE and XGETBV/XCR0 identify enabled user-state components, while IA32_XSS and the XSAVES/XRSTORS policy cover supervisor state where relevant. Process and thread policy are separate again: Windows distinguishes system-enabled XState, current-thread-enabled XState, and optional process enablement; Linux distinguishes supported, permitted, and guest-permitted dynamic components.

The workload must then execute instructions that consume the component. A test that never touches AMX, AVX-512, PKRU, CET, LAM-sensitive pointer paths, or enclave-adjacent transitions cannot validate their preservation. Finally, the state must survive the boundary under test: VM entry/exit, VMRUN/#VMEXIT, a scheduler switch, NMI/MCE, sleep/resume, CPU hotplug, nested migration, or hosted snapshot.

CPUID enumerates support. OS enablement, task permission, and workload use follow later. A valid XSAVE size or XState mask describes format and enablement; preservation across a transition needs pre- and post-transition state. AMX makes the stages easy to see because tile configuration and tile data are separate components, and the OS may grant permission and allocate the much larger tile-data state only on first use.

A missing tile state can mean unsupported, disabled by the OS, unavailable to that process or thread, not exercised by the workload, faulted on first use, hidden by a nested VMM, or lost across a transition. Those are different results.

Report each XState step separately. CPUID enumerates support; XCR0 enables user-managed components; the OS mask and thread permission make a component available to the task. A saved layout records serialization, while the consuming instruction or exception records use. Transition continuity requires samples from the same vCPU run or scheduler history. A nested mask describes virtual exposure rather than physical host configuration. PKRU, CET, LAM, SGX, and AMX/XFD also need the access, control-flow, enclave, or first-use event that consumed their state before they can be related to game activity.

XState Lifetimes and Optional Features

Current Windows and Linux interfaces make one point clear: XState is not a static “register save area.” Windows exposes a system-enabled XState mask, thread-enabled optional XState, process optional-feature enablement, context-buffer sizing, compaction-mask selection, valid-feature masks after context operations, and feature-location APIs because the layout and liveness of extended state are conditional.

Linux exposes the same class of boundary through x86 XSTATE documentation: applications must combine CPUID with XGETBV; dynamic features such as AMX TILE_DATA can require explicit permission, larger signal-frame planning, first-use trap handling, and separate guest-permission management before the first vCPU is created. These operating-system rules are not side notes.

They are the only way to decide whether a sampled XSAVE area is a live thread state, an initialized-but-unused state, a disabled optional feature, a guest-only permission state, or a parser error.

The Windows APIs deliberately expose different views. GetEnabledXStateFeatures reports the system mask, while GetThreadEnabledXStateFeatures narrows it to optional features enabled for the current thread. EnableProcessOptionalXStateFeatures changes process policy; workload execution supplies the first consuming instruction. Context APIs cover another problem: InitializeContext sizes and aligns a buffer, SetXStateFeaturesMask and GetXStateFeaturesMask select or report valid areas, and LocateXStateFeature finds an area without assuming stable offsets. Kernel callers have separate nesting and save/restore duties through KeSaveExtendedProcessorState and KeRestoreExtendedProcessorState.

The full lifetime is already longer than a feature mask: CPU enumeration, OS enablement through XCR0 or IA32_XSS, process or guest permission, thread or vCPU liveness, materialized context state, workload or fault-path use, and preservation across the transition. Statements about memory or behavior require still more.

XFD needs an event history in addition to the mask field. An IA32_XFD bit can make a component architecturally enabled while still leaving it unmaterialized for the current thread, process, guest, or vCPU run. A first-use #NM remains ambiguous until the report names the instruction family, IA32_XFD_ERR, OS permission result, allocation result, signal or exception delivery, and post-fault XSAVE layout. Without that history, the trace describes dynamic-state configuration rather than extended-state continuity.

XFD, #NM, and Hosted XSAVE Images

XFD changes liveness without changing the feature name. The CPU may enumerate a component and the OS may enable it in XCR0, while IA32_XFD still defers its first use. A later #NM names the component in IA32_XFD_ERR; an initial-state component may remain absent from a signal frame; KVM may serialize the vCPU image regardless. None of those events alone shows that the target game thread consumed the state.

XFD analysis has four checkpoints. OS policy grants process or guest permission. The first-use #NM and IA32_XFD_ERR identify the deferred component, but the handler must still allocate state and re-execute the instruction. XSTATE_BV, XCOMP_BV, signal frames, and context APIs show whether storage materialized. A hosted serializer such as KVM_GET_XSAVE2 records only the KVM vCPU image produced under that kernel’s CPUID layout and KVM_CAP_XSAVE2 size.

Linux documents these lifetimes separately. AMX TILE_DATA can be enabled in XCR0 while first use traps, allowing the kernel to check process permission and allocate a larger task buffer. Dynamic features may be absent from a signal frame while they remain in their initial configuration. Guest dynamic-XSTATE permission is separate from host permission and must be requested before the first vCPU is created. KVM then exposes its serializer: KVM_GET_XSAVE2 is sized by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2), XSAVE component offsets follow host CPUID leaf 0x0D, and KVM_GET_XCRS copies the current vCPU XCRs. The resulting image describes what the host kernel and VMM serialized, not a portable snapshot of endpoint state.

Read each field literally. CPUID leaf 0x0D enumerates components, XCR0 enables their architectural state, and XFD can delay first use. IA32_XFD_ERR identifies the component that faulted, not whether the kernel allocated storage and re-executed the instruction. Guest XCOMP permission is fixed through the KVM guest-permission path, whereas KVM_GET_XSAVE2 serializes a vCPU using the size and layout reported by that KVM instance. Windows optional-XState enablement is policy as well, not execution history.

The decisive boundaries are dynamic permission, first-use allocation, and serializer compatibility. A byte image that decodes under one KVM_CAP_XSAVE2 size or CPUID 0x0D layout need not remain valid under another.

AMX is the cleanest component-level stress case because the feature is split across two named XSTATE components, not one vague “tile state.” Public Intel material names XTILECFG and XTILEDATA; the Linux x86 XSTATE documentation names ARCH_XCOMP_TILECFG as component 17 and ARCH_XCOMP_TILEDATA as component 18, and explains that AMX TILE_DATA can require explicit permission, first-use trapping, larger task XSTATE buffers, and larger signal-frame or alternate-stack planning. Microsoft kernel documentation exposes the same split as XSTATE_MASK_AMX_TILE_CONFIG and XSTATE_MASK_AMX_TILE_DATA in its extended-processor-state save rules. “AMX state was preserved” is too broad unless it names the component, permission decision, layout, and transition.

AMX/XFD object	What it can support	What remains unresolved
XTILECFG / tile configuration	tile palette, rows, columns, and configuration state was representable or saved	tile data existed or workload consumed matrix state
XTILEDATA / tile data	large tile-data component was enabled, allocated, or saved for a specific context	the application had permission, first-use succeeded, or the state survived a VM boundary
Linux ARCH_GET_XCOMP_SUPP	the kernel reports supported dynamic XSTATE components	process permission or task-buffer allocation
Linux ARCH_REQ_XCOMP_PERM for ARCH_XCOMP_TILEDATA	the process requested AMX tile-data permission	current-thread liveness, guest permission, or actual AMX instruction execution
Linux signal-frame/altstack validation	dynamic-state signal-frame size was considered under Linux policy	Windows endpoint behavior or hypervisor preservation
Windows EnableProcessOptionalXStateFeatures	process optional-feature policy changed for current and future threads	specific thread used AMX or a context trace contains non-initial tile state
Windows KeSaveExtendedProcessorState AMX masks	kernel-mode caller saved selected AMX config/data state under a documented mask	user-thread AMX liveness or VM-entry/exit continuity
IA32_XFD_ERR / first-use #NM	a first-use path named the disabled dynamic component	permission grant, allocation, re-execution, or post-transition preservation

For AMX, bind CPUID and XCR0 support for both XTILECFG and XTILEDATA to OS dynamic-feature policy, process or guest permission, and current thread or vCPU liveness. Validate the layout of both components, tile-data allocation, first use or the corresponding fault, and save/restore across the transition before attaching the state to workload memory or behavior.

APX EGPR state requires XCR0[19], the component-19 layout from CPUID leaf 0x0D, and XFAM[19] for a confidential VM when that policy applies. VM-exit Extended Instruction Information is decode metadata; it is not a saved copy of R16-R31. An executed instruction and the exit that reported it are still needed to place that metadata in an execution interval. AVX10 analysis similarly needs the active vector width and XState mask. Without endpoint enumeration, OS and thread enablement, workload use, and samples before and after the transition, the observations remain processor-extension metadata.

Preserving Protection State Across VM Transitions

The earlier interpretation section described what PKRU, CET, LAM, and SGX state means to a consumer. A VMM has a different obligation: it must preserve the right state for the right vCPU or thread across VM entry, VM exit, context switch, migration, snapshot, and resume. PKS adds supervisor key state, CET adds shadow-stack and IBT state, LAM adds an address-decoding mode, and SGX adds enclave transition state. Flattening any of them into ordinary page presence loses the transition being virtualized.

These controls remain separate across a VM transition. PTE permissions and PKRU or PKRS determine whether the access is allowed. CET enablement, SSP, shadow-stack mappings, and IBT determine whether the control-flow edge is legal. LAM and canonical-address policy determine how a pointer is decoded. SGX identity, EPCM, SECS/TCS/SSA, and AEX or ERESUME determine the enclave transition. A VMM that preserves the bytes but loses one of these controls has not preserved the consuming context.

For every protected state above, record both the fields and the event that consumed them. PKRU or PKRS needs a thread or supervisor interval and the access whose permission it controlled. CET needs SSP, enablement, and the branch or exception that consumed it; IBT/ENDBR or /CETCOMPAT alone is policy, while a control-protection fault remains unattributed without the faulting edge. LAM needs the active decode policy when the pointer was interpreted. SGX needs enclave identity and the AEX, ERESUME, or AEX-notify transition; an EPC mapping by itself leaves host or VMM plaintext visibility unresolved.

Migration of a PKRU-bearing thread, VM entry with a live CET shadow stack, restoration of a LAM-tagged pointer, and enclave interruption or resume each exercise a different save path. A lost control value or changed exception path identifies the failed transition more precisely than the bytes alone.

Weak hypervisors, dump parsers, and VMI tools often flatten these features into “memory is present” or “code is executable.” That loses the access rights, control-flow policy, pointer mode, or enclave state that gives the bytes meaning. Connecting the state to a cheat requires the transition that preserved it and the path from that state to a process object, game semantics, delivery, and replay or server consequence.

Context Switches, Migration, and Nested XState

Extended state becomes hardest to reason about when the vCPU or thread moves between schedulers, VMM layers, or machines. A steady-state XSAVE trace can be correct while a context switch, VM entry, VM exit, nested VM transition, suspend or resume, live migration, hosted snapshot, crash dump, or processor hotplug edge loses or reinterprets one component. Check whether the saved representation remained valid across that boundary; listing endpoint support for AVX, AMX, APX, CET, PKU, LAM, or SGX-adjacent state is insufficient.

Each migration-like boundary uses a different serializer. A scheduler context switch preserves an OS-managed thread image. A VMX/SVM transition preserves VMM-managed state. A nested transition adds L0/L1/L2 exposure policy. A hosted snapshot uses the format chosen by the tool or VMM. Live migration applies source-to-destination compatibility rules, while a crash dump retains OS-selected post-fault state. These byte ranges may all resemble XSAVE images, but their formats and lifetimes differ.

To show that extended state persisted across a transition, record the component enumeration, guest or host exposure policy, OS enablement and permission, and a valid pre-transition image. Also record the serializer, destination capability and policy, the post-transition image, and the first workload reuse or fault. Relevance to the process, game, or behavior remains a separate question.

The nested case deserves special caution. L0 can support a component while L1 hides it from L2. L1 can expose a virtual component while L0 serializes it through a different backing format. The guest OS can enable a component that is later rejected or emulated during migration. An enlightened or synthetic path may expose a convenient virtual mask that differs from physical host state. Keep three masks separate: physical host capability, virtual guest exposure, and OS or thread liveness.

For APX and AVX10-era statements, “the ISA is supported” is not a state-continuity result. APX adds R16-R31 as XSAVE state component 19. In the standard XSAVE layout, Intel reuses the 128-byte area formerly assigned to MPX components 3 and 4; in the compacted layout, component 19 follows the compacted-order rules instead. A parser that assumes monotonically increasing component numbers and offsets will misplace APX state. APX also adds a VM-exit Extended Instruction Information field so a VMM can recover full five-bit register identifiers for affected exits. That field is exit metadata, not a saved copy of R16-R31.

AVX10.2 is different again. It versions vector instruction capability, while the enabled XMM, YMM, opmask, and ZMM components carry the live context for the exposed vector width. Linux XSTATE documentation and Windows XState APIs add OS rules around those components; guest, debugger, migration-stream, or game-workload execution requires a separate runtime record. Analysis of APX, AVX10, AMX, and CET needs the exact component mask, layout, serializer, and consuming instruction or exception.

A documented component that was never exposed to the guest remains a source-level fact. Exposure without OS enablement or thread permission is not live state. A valid image with no named serializer, a hosted snapshot with no live-transition comparator, mixed L0/L1/L2 masks, or an incompatible migration destination each break continuity at a different stage. Post-transition reuse or a fault is still required before that state can be attached to a workload, process, or game event.

KVM XSAVE UAPI and Host-Dependent State

Hosted VMI needs an explicit KVM UAPI boundary. KVM can expose vCPU extended state to userspace through KVM_GET_XSAVE, KVM_SET_XSAVE, KVM_GET_XSAVE2, KVM_GET_XCRS, and KVM_SET_XCRS, but those ioctls serialize KVM state; they are not the architectural source of truth by themselves.

The KVM API documents KVM_GET_XSAVE2 under KVM_CAP_XSAVE2 for x86 vCPUs whose XSAVE state may exceed the legacy fixed 4096-byte buffer, and says the required size comes from KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2). The Linux XSTATE documentation separately says dynamically enabled guest state components require guest permission management, and that guest permission is frozen when the first VCPU is created.

Those two interfaces define a hosted-state boundary: userspace can read or write an XSAVE-shaped vCPU image, but the image is meaningful only with the capabilities, guest permissions, vCPU-creation state, XCRs, CPUID leaves, and layout that produced it.

The hosted KVM path adds state sources that do not exist in a bare-metal VMX/SVM explanation:

Hosted component	Native records	Direct KVM meaning	Unresolved endpoint relation
KVM capability state	KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2), kernel version, VM type, architecture	userspace learned the kernel’s required XSAVE buffer size for this KVM context	every dynamic XState component is guest-live
guest permission state	Linux ARCH_GET_XCOMP_GUEST_PERM or ARCH_REQ_XCOMP_GUEST_PERM result, first-vCPU creation point	guest dynamic-state permission was requested or frozen under Linux’s rules	host process permission equals guest vCPU permission
CPUID and XCR state	KVM CPUID model, guest-visible CPUID leaf 0x0D, KVM_GET_XCRS/KVM_SET_XCRS, guest XCR0	virtual CPU exposure and enabled XCR state are known	XSAVE bytes imply the guest OS enabled or used the feature
XSAVE serializer	KVM_GET_XSAVE2 or KVM_SET_XSAVE, buffer size, standard or compacted layout, component valid mask	a userspace-visible vCPU state image existed	live transition continuity, migration success, or workload use
vCPU lifecycle	vCPU fd, creation point, run/pause/snapshot state, migration or restore point	which vCPU run the image belongs to	process thread, game thread, or endpoint-wide state

This is a valuable hosted-VMI test. A QEMU/KVM snapshot can contain valid-looking AMX, AVX-512, APX, PKRU, or CET-related bytes while proving only that KVM userspace serialized a vCPU state image through one kernel/uAPI version.

That image describes hosted serialization only. It cannot tell whether a Windows game endpoint exposed the same feature, a live VM transition preserved it, a migration destination accepted it, or the game workload consumed it. A hosted AMX or APX test instead needs the KVM capability and XSAVE2 size, guest XCOMP permission established before the first vCPU, guest CPUID/XCRS/XSAVE state from one vCPU run, and a workload that consumes the component. Restore or migration also needs destination compatibility. Even then, the result remains specific to the hosted KVM interface rather than a Windows endpoint.

When Extended State Becomes Game-Relevant

Extended-state reasoning most often overreaches at the final step. A feature-heavy workload can exercise a saved-state format, permission path, exception path, or serializer without showing that the game process used it or that a below-OS layer influenced game semantics. The process and game checks remain separate.

Connecting XState, AMX, APX, CET, PKRU, LAM, or SGX to game behavior requires three facts. First, the feature was exposed, enabled, permitted, materialized, and valid. Second, an instruction, exception, first-use event, or transition consumed it. Third, that consumer was a relevant game thread rather than a probe, helper, hosted guest, or unrelated stress workload. A KVM image, AMX first-use fault, APX component-19 bitmap, CET fault, PKRU change, LAM decode, or SGX transition can validate its immediate mechanism while stopping short of the game process.

The research value is still high because game-adjacent workloads make useful negative controls. A below-OS layer that survives scalar code but fails under AVX-512, AMX, APX, CET, PKRU, or LAM pressure has a real continuity defect. That defect affects the game only after the trace reaches the endpoint, target process, game semantics, delivery path, and replay or server behavior. Until then, state exactly where the trace stops: the feature workload, transition serializer, game interval, or extended-state sample.

GPU and Accelerator Virtualization

Reading bytes is not the end of a game cheat. The information must become something a player can use: an overlay, streamed frame, highlighted object, timing hint, or input correction. That makes the frame path part of the mechanism.

GPU virtual addresses, process virtual addresses, resident allocations, completed fences, presented frames, host captures, and guest screenshots come from different subsystems. Treating any two as interchangeable skips the translation, scheduling, or presentation stage between them.

Windows separates graphics allocations, GPUVA translation, scheduling, and presentation. Each layer may be current while a later layer is stale or unobserved. Before correlating a GPU address, resident allocation, completed fence, or captured frame with CPU memory, an overlay, input timing, or match behavior, identify the graphics component that produced it.

game process
  -> user-mode graphics driver and runtime
  -> GPU virtual address and allocation objects
  -> VidMm residency and memory budgeting
  -> VidSch scheduling or hardware scheduling path
  -> command queues, DMA buffers, monitored/native fences, doorbells
  -> composition, capture, remoting, or paravirtualized display path
  -> player-visible frame and input feedback loop

The practical rule is strict. A GPUVA is an address-space fact, not a CPU process-memory fact. VidMm residency describes allocation placement, not frame consumption. HAGS changes scheduler control and latency assumptions, not game semantics. GPU-PV or GPU partitioning changes the host/guest split and resource isolation, not endpoint equivalence. VFIO, mdev, or SR-IOV assignment establishes an assigned or mediated device path only after the IOMMU group, PF/VF or parent driver, reset generation, interrupt route, and DMA mapping are named. A fence or doorbell remains a scheduling event until present, capture, overlay, input, and replay fall within the same game window.

VFIO, mdev, and SR-IOV GPU Assignment

“GPU passthrough” hides the control model exposed by Linux VFIO and mediated devices. VFIO is an IOMMU- and device-agnostic subsystem that gives userspace direct device access inside an IOMMU-protected environment. Isolation depends on the device, IOMMU group, container, interrupt model, DMA mapping, and host driver. With mediated devices, a parent physical-device driver exposes mdev instances for attachment to a VFIO group while continuing to arbitrate the real hardware.

Name the responsible component at each step rather than listing devices. A physical accelerator, PF, VF, mdev instance, VFIO group, and guest graphics object can all exist at the same time while saying different things about isolation, DMA routing, frame production, or endpoint equivalence.

physical accelerator or PF
  -> host driver or PF policy
  -> IOMMU group and ACS/topology boundary
  -> VFIO group
  -> container and IOMMU context
  -> device region, MMIO, DMA mapping, and interrupt notification
  -> guest device model, vGPU, VF, or mediated-device instance
  -> guest frame, completion, or input/cue delivery

Assignment events need timestamps. Linux VFIO documentation makes the IOMMU group the unit of isolation when topology cannot guarantee single-device granularity. Mediated-device documentation adds create, bind, probe, remove, and parent-driver callbacks before a VFIO user reaches a guest frame. These events run on separate timelines:

Clock	Advanced by	What it can support	Invalid shortcut
group viability clock	all devices in the IOMMU group are bound to VFIO or detached from host drivers; topology and ACS constraints are evaluated	the group may be exposed as an isolation unit	single GPU function is isolated
container or iommufd clock	group/device is attached to a container or iommufd context and an IOMMU model is selected	a userspace/VMM translation manager exists	process address space or game-memory mapping
region and MMIO clock	device regions are enumerated, mmap/read/write paths are exposed, BAR-like state is reachable	userspace or guest can touch device registers or regions	DMA freshness, frame completion, or hidden cue delivery
DMA mapping clock	IOVA maps, unmaps, pins, invalidations, dirty tracking, or nested HWPT operations occur	a device address space has been configured	CPU virtual memory or current process bytes
interrupt clock	eventfd, MSI/MSI-X, INTx, or remapped interrupt route is configured and observed	an interrupt route or completion notification exists	GPU command completed or frame was presented
PF/VF clock	PF policy creates, configures, resets, or tears down a VF	VF requester identity and resource slice are current for that PF generation	VF is independent of PF firmware, reset, or resource scheduling
mdev parent clock	parent driver creates/destroys an mdev, exposes supported types, probes/removes vfio_mdev, or unregisters the parent	a mediated-device instance exists under parent-driver arbitration	direct hardware control or bare-metal equivalence
guest graphics clock	guest driver, queue, fence, frame, and capture path observe the assigned or mediated device	the guest graphics path is active	player-visible output, local endpoint equivalence, or server consequence

Read the assignment clocks in dependency order. Group topology constrains isolation. The container or IOMMUFD context then owns regions, interrupts, and DMA mappings, while the PF/VF or mdev parent controls the device lifetime. Guest queues, fences, and frames come later, followed by capture, overlay, input, and replay observations.

The most common mistake is promoting one assignment layer into the next. A VFIO group may contain more than the named function because of topology or ACS limits. A VF remains subject to PF firmware, reset, and resource policy; an mdev remains subject to its parent driver. An eventfd or MSI route identifies interrupt routing rather than command completion. A BAR mapping identifies a mapped resource window rather than DMA or residency. Reset, device loss, mdev recreation, or host-driver reload can also invalidate an earlier assignment before the observed frame. A real VFIO group, VF, or mediated device establishes device exposure. Follow graphics and delivery separately.

GPU-PV and VFIO describe different control models. Under WDDM GPU paravirtualization, the guest retains familiar D3D runtime and KMT surfaces, while the virtual render device and host perform the effective VidMm and VidSch work. VFIO and mdev provide Linux assignment and mediation interfaces, and SR-IOV adds PF/VF function state. A complete assigned-GPU path proceeds from driver binding and IOMMU isolation through DMA mappings, interrupts, reset state, the guest graphics driver, a completed frame, and finally the host or guest output route. An observation from one model cannot fill a missing stage in another.

IOMMU-group or container changes alter assignment without altering game memory. VF or mediated-device reset changes the device lifetime, while a capture-route change leaves VFIO assignment untouched. Direct SR-IOV and mdev also divide control differently between the PF and parent driver. If a visible effect cannot be tied to those control points, it belongs to device exposure or hosted graphics rather than the claimed mechanism.

WDDM, GPUVA, Scheduling, and Delivery

For a cheat, ESP and input assistance live or die on frame-time alignment. A read from tick N, a camera matrix from tick N+1, a GPU frame from tick N+2, and an input event delivered after composition do not form a clean “saw and reacted” path. GPU state has its own lifetime and sources; it is not a passive reflection of CPU memory.

The Windows graphics path has at least five distinct components. D3D and the UMD construct commands and manage application resources. Dxgkrnl is the kernel graphics boundary. VidMm manages GPU virtual addresses, residency, budgets, paging, and segments. VidSch or the hardware scheduler selects and preempts work. DWM, hardware planes, capture APIs, remoting, and streams determine which observer receives pixels. GPUVA may remain stable while residency or VRAM placement changes. Submission precedes presentation, and one screenshot covers only one display observer.

WDDM 2.0 introduced GPU virtual addressing so that a process owns a GPUVA space and each allocation can keep a stable GPUVA for its lifetime. The allocation handle and GPUVA remain distinct identifiers. Neither establishes a CPU process-memory relationship, and VidMm can change physical residency, segment placement, paging state, aperture mappings, or eviction state while the GPUVA remains constant.

process graphics object
  -> D3D runtime and UMD allocation identity
  -> GPUVA in the process GPU address space
  -> VidMm allocation, segment, residency, and budget state
  -> GpuMmu page tables or logical DMA mapping where applicable
  -> command buffer or user-mode submission queue reference
  -> fence, monitored fence, native fence, or completion point
  -> presentation/composition/capture observer

The graphics path rules out three shortcuts. A doorbell or hardware queue records submission notification, not presentation. A monitored or native fence records a synchronization value or wait/signal relation, not a visible frame. Desktop Duplication, Windows Graphics Capture, a stream, or a host capture frame records what one observer received, not necessarily the player’s display or the guest’s render source. HAGS and user-mode submission change scheduler control and latency. GPU-PV moves VidMm and VidSch work across the host/guest boundary. Neither grants access to game memory or identifies what the player knew.

A queue record shows submission, and a fence can show synchronization or completion. Presentation comes later. The observer table below follows the path from graphics resource to the frame seen by one capture or display endpoint; input and replay remain later events.

Resource identity, addressability, residency, submission, synchronization, presentation, observation, and behavior are separate states. In particular, Microsoft’s pfnMakeResidentCb documentation distinguishes immediate S_OK residency from E_PENDING, which requires the driver to wait for the paging fence before submitting work that references the allocation.

State	Runtime detail	Direct reading	Stops before
graphics object	process, runtime object, allocation/open event, handle or resource identity	the graphics resource exists	only a GPU label remains
GPUVA	process GPUVA space, assigned GPUVA, allocation lifetime, page granularity	GPU addressability exists in that process GPUVA space	GPUVA without its backing allocation
residency requested or pending	VidMm allocation, MakeResident call, E_PENDING, paging queue, PagingFenceValue	the allocation was added to the residency requirement list but paging was not finished	GPU access before the paging fence completes
residency complete	S_OK, or the paging fence signaled after E_PENDING, with no later eviction or reset	the allocation was accessible to the GPU at that point	later residency, command completion, or presentation
submission	command queue, DMA buffer, hardware queue, user-mode submission capability, queue id	work was submitted or queued	submission without completion
doorbell	doorbell model, connection status, CPUVA state, queue identity, ring or notification event	the queue was notified of available work	notification without completion
fence	progress fence, fence object, monitored/native fence value, signal/wait operation	a synchronization or completion edge existed	completion without a frame
presentation	swap-chain present, DWM/MPO/compositor state, VM/remote display path, frame timestamp	a frame entered the presentation path	presentation without capture
capture observer	Desktop Duplication, Windows Graphics Capture, stream/capture-card, pointer/dirty/move metadata, protected-content behavior	one observer saw or missed the output	that observer is not necessarily the player’s view
delivery aligned with behavior	output time, input time, replay/server consequence, ordinary-source controls	delivery and a later action share a measured time window	causal influence without a control comparison

Each stage has its own clock. CPU reads follow CPU time and game ticks or frames. GPU queues record submission, scheduling, and fence updates. DWM and capture APIs use compositor or capture-frame time. Remote or VM output adds host, guest, and network delay. Correlation requires a documented conversion, uncertainty bound, and ordering rule. Forcing every event onto one timestamp discards the order needed to argue causality.

For GPU-PV or vGPU, add the host boundary because scheduling, copying, encoding, remoting, or presentation may have moved outside the guest even though the guest-side graphics vocabulary still looks familiar. Without this boundary, a clean guest trace can be mistaken for a statement about the endpoint display.

guest D3D/UMD
  -> guest WDDM object and GPUVA
  -> paravirtualized or virtual render device
  -> host graphics partition, PF/VF/mdev/PV policy, or remoting path
  -> host scheduler, fence, copy, encode, or presentation path
  -> guest-visible frame, host-visible frame, or player-visible stream

Overlay delay, capture-route changes, HAGS or GPU-PV mode changes, and a guest-to-host observer move each affect a different part of the frame path. Queue completion without presentation is the simplest counterexample: it preserves command activity while removing the visible frame. GPUVA, residency, submission, fence completion, presentation, and capture must all refer to the same output.

Synchronizing these timestamps is difficult because CPU, GPU, host, guest, compositor, capture, replay, and server clocks can all be internally correct while referring to different frames. Record each conversion and preserve the uncertainty of the first cross-clock alignment. Plausible timing alone leaves the graphics route unidentified.

At minimum, retain four timed groups: CPU memory with the game tick; GPU submission, scheduler, and fence completion; compositor or capture with the displayed or streamed frame; and input arrival with the server or replay tick. Each correlation needs its clock source, timestamp uncertainty, and method. A field name without those values documents an intended relation rather than a measured one.

For ESP or input assistance, state which clocks were synchronized and which were only inferred. GPU traces can expose useful contradictions: an overlay may appear in host capture but not guest capture, a fence may complete before the relevant present, a stream may carry augmented output without a guest-local overlay, or input may arrive after the frame that allegedly caused it. These remain delivery facts until they are tied to process memory and current game state.

From GPU Work to the Displayed Frame

As checked in July 2026, Microsoft’s WDDM 3.2 user-mode work submission documentation still marks the render/compute path as prerelease. It supplements the traditional kernel submission path and remains separate from presentation. Doorbells can be connected, disconnected, redirected to a dummy page, retried, or aborted across power and device-loss transitions; a fence value can be shared by CPU and GPU participants without identifying the frame eventually shown to the player.

GPUVA identifies a GPU address space. A doorbell marks submission and lifecycle state, while a native fence marks synchronization. Native-fence logs expose part of the scheduler’s view. Presentation and composition then establish the frame route; capture identifies one observer; input and server replay connect the frame to an action and game consequence.

Overlay, ESP, capture, streaming, and input-assistance analysis follows that delivery sequence. Start with a game-semantic snapshot and the graphics resource or overlay object that consumes it. Tie that object to its GPUVA and residency, queue or doorbell submission, fence or completion, and the corresponding present or composition frame. The actual capture or display observer comes next, followed by the input or decision and its server or replay consequence. A graphics trace reaches a player-visible advantage only when all of those events fall within a compatible game window.

GPU Faults, TDR, Device Removal, and Reset

The ordinary submission-to-frame sequence is not enough at failure boundaries. WDDM Timeout Detection and Recovery breaks the old graphics run: the scheduler detects work that cannot complete or be preempted within the timeout window, the recovery path calls into the display miniport, the driver must reinitialize and stop touching hardware during reset, VidMm can purge video-memory allocations, and the application may need to release and recreate its Direct3D device and objects after device removal. Pre-reset allocation handles, GPUVAs, residency state, fences, doorbells, and capture frames cannot be reused afterward without reconstruction.

Treat GPU recovery as a state-changing transition, not a log footnote. A TDR, device-removed event, reset, VF reset, mdev recreation, GPU-PV recovery, or suspend/resume edge can invalidate the object that made an earlier GPUVA, fence, capture, or frame observation meaningful.

pre_reset_frame_or_work
  -> scheduler_preemption_or_timeout_detection
  -> choose_engine_process_or_adapter_recovery_scope
  -> reset_only_the_affected_engine_context_or_adapter
  -> purge_or_recreate_only_the_state_invalidated_by_that_scope
  -> report_device_or_context_loss_to_the_application_when_applicable
  -> submit_new_work_and_establish_a_new_presented_frame

The reset boundary has several lifetimes, and they can restart at different times. VidMm may purge or remap allocations; hardware queues, doorbells, and fences may be recreated; swap chains, DWM surfaces, hardware planes, and capture targets may move to new objects. GPU-PV adds host objects and guest-to-host translations that can be rebound while the guest appears to continue. A post-reset frame cannot inherit pre-reset address, queue, fence, or capture state without an explicit reconstruction.

Reset correlation is more than a “device recovered” sentence. Carry a result across the edge only after matching the pre-reset allocation, queue, and fence to the chosen recovery level and then finding the post-reset allocation, queue, and fence. Presentation or capture and the input or server time must also be re-established.

Failure boundary	Native graphics record	Overreach	Retained state
scheduler preemption timeout	a GPU task exceeded the scheduler’s completion/preemption window	the task produced the stated frame or cue	GPU timeout only
adapter TDR recovery	graphics stack reset, driver reinitialization, possible VidMm purge, and a recovery diagnostic	pre-reset allocations, GPUVAs, fences, and frames remain continuous	the old graphics run ends
engine timeout or process block	a limited engine/process recovery path affected a faulting process or engine	treating an engine/process reset as adapter-wide or player-visible	only the affected engine or process is identified
device removed or context lost	application-visible graphics-device loss or recreation obligation	old D3D objects, handles, queues, or fences still authorize post-reset frames	the old device-object lifetime ends
DRED auto-breadcrumbs	outstanding command-list or command-queue neighborhood before device removal	exact failing draw, visible overlay, or cheat mechanism	only the command neighborhood is known
DRED page-fault output	GPUVA plus active or recently freed allocations associated with it	CPU process byte, game object, or player knowledge	GPUVA without a CPU-process mapping
GPU-PV host event or handle translation	host-side KMD/Dxgkrnl mediation relates a guest object to a host object	guest handle identity equals host allocation identity	a guest-event proxy only
native-fence log row before reset	a wait/signal execution or unblock fact existed for a HWQueue generation	post-reset presentation or input causality	the fence log belongs to the pre-reset queue

A graphics-recovery event invalidates only the state covered by that recovery level. An engine reset may invalidate affected contexts while leaving other engines runnable; process or device removal reaches farther; adapter-wide TDR requires applications to recreate the Direct3D device and its objects. After reset, re-establish the affected GPUVAs, queues, fences, doorbells, presentation objects, and capture state before relating them to a later frame or input.

Compute and AI Accelerator Work Queues

Accelerator compute and GPU rendering are different paths. A modern Windows endpoint can route compute or inference through DirectML, Windows ML, an ONNX Runtime execution provider, a GPU, an NPU, a CPU fallback path, or a vendor-specific provider selected below the application API. This creates separate work queues, inputs, outputs, and completion state. Access to game memory comes from the input source and mapping; cheat relevance comes from game semantics, cue delivery, input timing, and a server or replay result.

Model it as a compute path, not a graphics shortcut. Input tensors, provider selection, command submission, completion, output interpretation, and cue delivery occur at different stages and times. Writing them explicitly prevents “AI decided” from standing in for a hidden-information path.

semantic input or frame source
  -> model, operator, shader, or work-graph identity
  -> software layer: Windows ML, DirectML, D3D12 compute, vendor EP, or CPU fallback
  -> input tensor, descriptor heap, binding table, or buffer source
  -> GPUVA, device VA, shared buffer, or provider-private allocation
  -> command list, dispatch, work graph, EP invocation, queue, or doorbell
  -> fence, completion callback, provider completion, or CPU readback point
  -> output tensor, score, bounding box, cue, or decision
  -> overlay, side channel, input shaping, or human-facing instruction
  -> server tick, replay tick, or behavior consequence

An accelerator trace stops at its last observed stage: workload, input, submission, completion, interpreted output, delivery, or behavior. Naming a GPU or NPU cannot fill a missing step between them.

Checkpoint	What must be observed	Direct observation	Missing downstream relation
hardware target	adapter or device identity, GPU/NPU/CPU class, DXCore hardware type	the available compute hardware is identified	which software stack selected it
runtime and provider	DirectML, Windows ML, ONNX Runtime execution provider, D3D12 compute path, provider version	the software submission path is identified	which model or workload used it
model or graph identity	ONNX model hash, operator graph, shader, work graph, compute label, and provider version	the submitted workload is identified	input source and execution target
input tensor	input source, tensor/buffer identity, preprocessing time, descriptor and binding source	the workload consumed the recorded input	input without a game-state relation
submission	command list, dispatch, queue, provider invocation, work-graph entry	work was submitted or invoked	compute submission without completion
completion	fence, callback, provider completion, CPU readback, output buffer lifetime	computation completed or produced an output	completion without output semantics
output semantics	score, label, bounding box, policy value, stale-output guard, calibration trace	an inference or compute result was interpreted	output without delivery
delivery	overlay, stream, audio cue, second-display route, input-shaping handoff	a cue or action path was active	delivery without behavior
behavior	player observer, input time, replay/server tick, ordinary-visibility controls	a possible relation between accelerator output and behavior	behavior without a local mechanism

The failure modes differ from a pure memory reader. Preprocessing, batching, and queue delay can make a current input stale by the time the output is used. Provider fallback moves execution among NPU, GPU, and CPU while leaving the application API unchanged; quantization changes representation and may change accuracy, but not the age of the input. Work graphs can also launch later GPU work without a CPU-visible dispatch for every substep. A bounding box may be correct for a captured frame yet wrong for the player’s display after interpolation, streaming delay, or occlusion, and a model may classify a clue an ordinary player could see. These are compute or delivery effects, not indications of hidden-state access.

Provider selection, input source, completion path, output tensor, delivery route, and replay window change independently. A provider fallback, for example, can preserve the model and input while moving execution from an accelerator to the CPU; a delivery change can preserve the output while removing the player-facing cue.

1. Keep the semantic input fixed and switch the provider between NPU, GPU, and CPU where the platform permits it.
2. Keep the model fixed and feed a benign frame source with the same capture timing.
3. Keep dispatch fixed and delay the fence, completion callback, or CPU readback.
4. Keep the output tensor fixed and remove the overlay, audio, stream, or input-shaping route.
5. Keep delivery fixed and shift the server or replay tick window.
6. Substitute an ordinary visible cue and test whether the same behavior model still fires.

An accelerator trace helps when it explains missing process-local telemetry, a host-side decision loop, or a timing contradiction between frame capture, inference, cue delivery, and input. DirectML, Windows ML, NPU presence, GPU compute, and ONNX Runtime are ordinary platform features and should not be treated as cheat markers. The workload, input source, completion time, interpreted output, delivery route, input time, and server or replay consequence must all refer to the same game window.

WDDM Kernel Testing and MCDM Runtime Work

WDDM and MCDM add another accelerator boundary that research harnesses can mistake for application inference. Microsoft documents MCDM as a compute-driver model for GPU, NPU, and other compute resources, with work submitted through command queues, contexts, software queues, hardware queues, DMA buffers, address spaces, and an OS scheduler.

DXCore can enumerate MCDM/WDDM devices that do not expose a Direct3D user-mode driver and can also enumerate hardware types such as GPU, compute accelerator, NPU, and media accelerator. WDDM 3.2 kernel-mode testing adds still another path: Dxgkrnl can validate drivers through kernel-mode thunks, test contexts, test queues, and simple test command buffers without involving the D3D runtime or UMD. The documented testing feature is available only when test signing is enabled.

That path is useful for driver validation and negative controls, but it is not application inference. A kernel-mode test command buffer can show that a KMD, node, queue, address space, DMA-buffer path, or scheduler path responded during a controlled test.

That test covers the driver, node, queue, and scheduler. Application-level attribution needs the game process, selected Windows ML or DirectML provider, input tensor, NPU or GPU output, cue, and later action. A test path can check accelerator continuity; runtime observations supply the workload, its inputs and outputs, delivery, and replay.

Three different software layers produce these records:

Path	Responsible component	Platform or inventory fact	Missing application workload
MCDM architecture path	KMD/UMD pair, context, SW queue, HW queue, DMA buffer, address space, OS scheduler	the compute scheduling and address-space model is identified	DirectML, Windows ML, or game workload executed
DXCore inventory path	adapter factory, adapter list, workload filter, hardware-type attribute, LUID	the adapter or hardware type was enumerated	display capability, provider selection, or hidden-state inference
WDDM kernel-mode test path	test-signing machine, DXGK_FEATURE_KERNEL_MODE_TESTING, TestContext, TestQueue, test command buffer	the driver, node, and queue were exercised without the D3D runtime or UMD	application runtime behavior, provider output, or player-visible cue

DXCore inventory, MCDM scheduling, WDDM kernel-mode testing, and application inference are separate paths. Enumerating an NPU identifies hardware. Creating a test context or completing a test DMA buffer exercises a driver, node, queue, and scheduler. DirectML, Windows ML, or ONNX Runtime use requires its own runtime trace. Even an application output remains incomplete until the cue or action route is observed.

A kernel-mode test queue can complete on the same device and node after the application provider path has disappeared. Test signing, DXCore hardware type, and provider fallback belong to that distinction. Driver validation is not application causality or a player-facing result.

Graphics Observers See Different Stages

The hardest GPU-side error is treating one observer as the whole display path. A game frame, D3D allocation, GPUVA row, fence value, Desktop Duplication frame, Windows Graphics Capture frame, display-affinity value, VMConnect view, stream frame, host overlay, and server replay tick all come from different observation points. They may describe the same user session, but one observer cannot stand in for another unless the correlation is explicit.

The public Windows APIs make this non-equivalence concrete. Desktop Duplication exposes frame-by-frame updates for a specific desktop image through DXGI surfaces, dirty rectangles, move rectangles, pointer metadata, timeout, and access-lost states.

Its dirty and move rectangles are reconstruction hints for one duplicated output, not a universal record of everything shown to the user; if unprocessed updates accumulate, the operating system can coalesce update regions, and pointer shape or position can be separate from the desktop image. Windows Graphics Capture creates a user-selected display or window item, creates a frame pool and session for that item, and produces Direct3D11CaptureFrame objects with ContentSize, Surface, and SystemRelativeTime, where SystemRelativeTime is compositor QPC time.

The frame pool, surface extent, content size, resize, device-lost, and Recreate lifetime matter because old frames can be discarded and the underlying surface size can differ from the useful content region. DwmFlush waits for queued DirectX changes from the calling application to be drawn; the rest of the session rendering batch remains outside that wait.

Display affinity applies to top-level windows owned by the calling process and works through a defined set of OS capture paths while DWM is composing; Microsoft describes it as capture behavior rather than DRM-grade protection. Under GPU-PV, a guest-visible graphics object may depend on host-side Dxgkrnl, VidMm, VidSch, VM bus, VM worker, and remoting state.

Each capture path covers only the surfaces it observes. A clean in-guest screenshot leaves host overlays outside the image.

A Desktop Duplication frame covers one duplicated output; MPO planes, host-side stream overlays, second outputs, capture-card previews, and off-device cues may sit elsewhere. A WGC frame covers its selected item rather than the entire desktop or every remote view.

A display-affinity value records an API-level protection request and its behavior under the tested capture path. Cameras, drivers, host-side capture, and other virtualized displays remain outside that result. A fence or doorbell marks a scheduling edge until it is matched with presentation and player action.

Observer	It can support	It cannot support alone	What must also be observed
D3D resource or GPUVA	application graphics-resource identity and GPU address-space state	CPU process bytes, hidden-game object, or player-visible cue	CPU/device memory mapping, current VidMm state, presentation relation
fence, doorbell, or queue	scheduling, submission, completion, or progress state	presented frame, consumed cue, or input causality	present/composition/capture time and input/replay correlation
DWM or compositor state	composition state for one local desktop interval	every hardware plane, remote stream, host overlay, or second display	plane inventory, capture coverage, player-display route
Desktop Duplication	one output-duplication observer saw a desktop-image frame and metadata	all player-visible surfaces or host-side overlays	output identity, frame metadata, plane/host controls
Windows Graphics Capture	one selected item produced capture frames under session options	full desktop visibility, all windows, or all remoted views	item identity, consent and session settings, route comparison
display affinity	capture-protection setting and tested OS capture-path behavior	DRM-grade secrecy or protection from camera, driver, or host capture	HWND process, DWM state, API coverage test, negative controls
GPU-PV or hosted display	host/guest graphics marshalling was active	bare-metal endpoint equivalence or guest-owned VidMm/VidSch state	host partition, VM worker, remoting, and guest/host capture relation
stream or remote observer	a remote presentation path carried a frame	what appeared on the local monitor or what caused the input	stream timing, operator observer, input route, replay consequence

The result must match the observer’s reach. One observer covers only the frame it saw; host overlays, hardware planes, second outputs, stream UI, external cues, and input causality require separate observations.

Guest and host overlays, Desktop Duplication, WGC, a second output, and a stream-side overlay observe different surfaces even when game memory and camera state are unchanged. Their expected disagreements identify which frame was captured and which display path carried the augmentation.

A GPU trace is most useful when it closes a route. It can expose contradictions between memory, rendering, capture, and input times, and it can refute an overbroad absence statement. Capture, streaming, GPU-PV, WGC, Desktop Duplication, display affinity, or DirectML remains a graphics observation until hidden state, the selected observer, input causality, and replay or server timing are tied together.

Native Fence Logs and Submission Loss

WDDM 3.2 user-mode submission and native GPU fences add useful scheduler detail, but not a new presentation path. Microsoft describes user-mode work submission as still under development for Windows 11 24H2 / WDDM 3.2 and as render/compute oriented. Hardware and drivers that implement it must retain support for the traditional kernel submission path; this is a compatibility requirement, not a statement that every user-mode submission also runs through kernel-mode submission at runtime.

The native-fence log-buffer path is especially useful for timing analysis because it provides a partial scheduler trace that can be correlated with CPU-side timing, but only under tight conditions. Dxgkrnl can allocate dedicated wait and signal log buffers for a hardware queue.

The UMD emits fence wait or signal commands and also programs the GPU to write log payloads when the GPU executes those operations. The log entry carries GPU-side timing such as fence-observed or fence-end timestamps; CPU timestamps are not included and must come from separate queued-event telemetry if present.

The UMD controls log-buffer progression, the GPU can overrun entries, and the OS may need to detect wraparound and fall back to scanning fences.

A native-fence log records more timing context than a plain fence value. Start with adapter and driver support, hardware-queue creation, and the active doorbell mapping, including dummy-page redirection. Then follow the command-buffer wait or signal, the programmed fence payload, GPU execution, the log entry and GPU timestamp, and the interrupt or scan that consumes it. Wraparound and loss accounting belong to this same record. Presentation, capture, input, replay, and server-visible consequences still require observations from those later stages.

Scheduler records become more specific in the following order:

Scheduler observation	Direct meaning	Additional frame or input data needed
user-mode submission capability exists	driver and hardware expose a supported scheduler path	a trace showing that a user-mode queue was active in the match
doorbell size or secondary-doorbell capability exists	doorbell vocabulary is legal for the adapter	an observed queue notification or produced frame
doorbell was connected, disconnected, or mapped to a dummy page	queue-notification lifecycle changed	presentation or hidden-cue trace
native fence value changed	synchronization value advanced	confirmation that the rendered frame reached the player
native-fence log entry exists	GPU-observed wait or signal edge existed	correlated CPU queue time, present time, and server tick
log wraparound or overrun occurred	the scheduler trace may have lost entries or fallen back to scanning	reliably saying that no work occurred
native-fence interrupt fired	the scheduler signaled or rescanned fence progress	the command list and visible result associated with the interrupt
engine-state-change interrupt fired	engine state changed under user-mode submission	overlay, input, or behavior causality

CXL and Fabric-Attached Memory

The phrase “physical memory” becomes ambiguous once fabric-attached memory enters the system. CXL.io carries PCIe-compatible discovery, configuration, MMIO, mailbox, MSI/MSI-X, DOE, IDE, AER, and management traffic. CXL.cache lets a device participate in coherent access to host memory. CXL.mem lets the host access host-managed device memory.

CXL is covered here as an architectural edge case, not as a claim about common game-cheat deployments. It stress-tests the assumption that local physical memory covers every backing store. A process byte may reside in local DRAM, CXL Type-3 memory, a Type-2 device-memory range, an interleaved endpoint set, a DAX mapping, a memory-hotplug block, or a fabric allocation managed outside the CPU socket.

CXL 4.0 was released on November 18, 2025. The announcement names a 128 GT/s link rate, bundled ports, and expanded memory-RAS support, while the specification hub provides an evaluation copy under its access agreement. Linux and QEMU documentation model the implementation objects used below: CFMWS windows, root/switch/endpoint HDM decoders, Type-3 memory devices, regions, DAX exposure, and software-defined routes.

The Linux CXL device-type documentation labels its management note “As of v6.14” and says Linux has no formalized interface there for non-DCD multi-headed memory pools. Its DCD section describes dynamic capacity as Fabric Manager-controlled extents. Resolving a host physical address requires the decoder route and current capacity assignment.

The CXL Consortium page identifies the CXL 4.0 specification and its evaluation copy. A particular endpoint route comes from platform firmware and runtime topology. Linux documentation defines roots, ports, endpoints, memdevs, regions, DAX, HDM decoders, and CFMWS entries, while QEMU documents an emulated Type-2 and Type-3 topology. Those sources describe different systems, so neither Linux objects nor QEMU topology should be projected onto an unexamined Windows endpoint.

CXL Route and Memory Layers

Endpoint discovery, route commit, OS exposure, and process-page placement occur at different times. A visible endpoint covers discovery; a committed decoder covers routing; DAX or System RAM covers OS exposure. The table keeps those stages separate from current game-process placement.

Layer	State it controls	Useful runtime fields	Open question
CXL.io and PCIe layer	enumeration, config space, BARs, mailbox, MSI/MSI-X, AER, DOE, IDE capability	bus/device/function, DVSEC/capability state, mailbox identity, error source	CXL device inventory only
host bridge/root complex	root CXL object, CEDT CHBS, CFMWS windows, host bridge UID	ACPI CEDT/DSDT identity, root decoder, host bridge target list	the root route remains unproven
root decoder	routes a host physical window toward one or more host bridges	CFMWS base/size, interleave members, target list, granularity	CFMWS configuration only
switch or host-bridge decoder	routes an HPA subrange to downstream ports without endpoint translation	switch decoder start/size, downstream targets, interleave settings	a routing decoder only
endpoint decoder	translates host physical address to device physical address for endpoint service	endpoint decoder, DPA resource, DPA start/size, endpoint interleave	HPA-to-DPA translation remains unproven
memory region	binds decoder hierarchy to an I/O memory resource, DAX region, or system-RAM exposure	region resource, DAX/ram mode, NUMA node, online/offline generation	current process-page placement
fabric manager or pooling controller	allocates pooled capacity, switch routes, security state, Dynamic Capacity Device extents, and multi-host assignments	DCD extent generation, capacity transaction, host assignment, switch route	OS acceptance or process use
security overlay	protects or attests link/device/assignment state	IDE stream, DOE/SPDM, TDISP/TDI state, TEE binding	fabric trust remains unresolved

These layers can change independently while the same HPA range remains visible. Enumeration may survive a route rebuild; a region may survive a DAX-to-System-RAM conversion; and a process virtual address may survive page migration. A current process-memory result needs the decoder route, OS exposure mode, current PFN/HPA, and process mapping from one interval.

Decoder Routing and Address Translation

A CXL memory attribution needs a replayable route together with the physical address. The same HPA value can resolve to different backing memory depending on which decoder accepted it, which endpoint translated it, which OS object exposed it, and whether the current process page still maps that backing store.

process virtual address
  -> CPU page-table walk
  -> host physical address
  -> CXL fixed memory window or platform memory map
  -> root decoder route
  -> host bridge or switch decoder route
  -> endpoint decoder translation
  -> device physical address
  -> device memory medium and coherency/security state

CXL route errors do not all mean the same thing. A root-window mismatch, interleave drift, endpoint DPA change, OS-exposure change, stale topology handle, and Fabric Manager movement occur at different points in the route.

Failure	What changed	Address state that remains
CFMWS/HDM size skew	root window and downstream decoder ranges do not cover the same HPA span	root-window skew
platform memory-hole trim	downstream HDM decoders cover an HPA span that the platform root decoder will not route	platform-window trimming remains unresolved
interleave position drift	target order, target position, way count, or granularity changes	the endpoint selected for an address may change
endpoint translation drift	endpoint DPA resource changes while upstream route looks stable	endpoint translation is unproven
firmware-assisted or normalized-address ambiguity	raw HPA needs a platform-specific conversion before it can be matched to endpoint mapping	the conversion rule is required
OS exposure drift	DAX/system-RAM conversion or memory-block state changes under the same HPA	the OS now exposes the range differently
stale topology object	a port, endpoint, memdev, or decoder handle was cached across disable/re-enable or hotplug	the topology handle is stale
fabric-assignment drift	a Fabric Manager or DCD operation moves capacity without replaying the process page	the host or extent assignment changed

For one memory observation, the HPA must resolve through the recorded decoder chain, interleave mapping, endpoint DPA range, and OS exposure state. If any of those changed, resolve the process page again before attributing the byte to the same backing memory.

BIOS, OS, and Hotplug Lifetimes

CXL memory is not surfaced by hardware alone. Firmware and the OS decide whether the range becomes ordinary memory, driver-managed specific-purpose memory, a DAX device, or a failed or stranded range. A below-OS observer may see a plausible HPA range before the OS has accepted it, after the OS has converted it, or after a hotplug or error path has invalidated the previous exposure.

Firmware, the OS, the CXL driver, and fabric management decide when capacity becomes usable memory and when hotplug, poison, address conversion, or dynamic-capacity movement invalidates an earlier mapping.

Lifecycle point	State to preserve	Why the result changes
BIOS/EFI static description	CEDT, SRAT, HMAT, EFI memory map, E820, HPA spaces, host-bridge interleave	defines the root route and whether the OS can build logical CXL objects
EFI_MEMORY_SP or equivalent policy	whether the range is deferred to the CXL driver or exposed to the page allocator during early init	changes whether ordinary memory scanners should see it as normal RAM
firmware-programmed decoder state	firmware-programmed or locked HDM decoders	can make route mutation impossible without platform reset and can strand capacity if validation fails
runtime-programmed region	user/admin/driver-created regions and endpoint commitments	creates a software-defined memory window whose route can change over time
hot add	static CFMWS capacity, resource availability, proximity domain, decoder creation	missing boot-time windows can cap or prevent later device capacity
hot remove	orderly removal of regions, DAX/system-RAM state, driver stacks, poison/error handling	hard removal can cause machine check or SIGBUS-like failure rather than a clean trace
DCD extent allocation	extent identity, volatile/persistent mode, exclusive/shared host set, Fabric Manager transaction, add/release generation	a byte can remain at a plausible HPA while the assigned capacity or host changed
platform address conversion	host-specific HPA/SPA/DPA conversion, especially where normalized addresses are used	a raw HPA may be insufficient on platforms that require firmware assistance

CXL topology changes can invalidate an otherwise correct physical-address lookup. A below-OS observer can resolve the CPU physical address correctly and still select the wrong backing memory after a CXL region conversion, hotplug event, decoder lock, memory-mode change, or platform address-translation change.

Model hotplug and DCD as state changes rather than a capacity flag. Firmware windows, decoder programming, OS regions, DAX or System RAM exposure, dynamic extents, poison state, and process-page placement advance independently. An extent can still exist after its decoder route or host assignment has changed, and a materialized region need not contain the process page being discussed. Hot add, hot remove, and DCD release or reassignment can all change what backs the same-looking HPA.

Fabric management can change the route without changing CPU page tables. CXL memory-pooling material assigns the Fabric Manager to unbinding and rebinding logical devices, reallocating memory, and coordinating managed hot remove across hosts. Linux userspace CXL tooling exposes the same problem: disabling a memdev can invalidate previously returned ports and endpoints, and forced disable can be as destructive as removing memory from a running system. After a fabric-management event, resolve the topology objects, OS exposure, and process page again.

A process virtual address can remain constant while a CXL topology object is invalidated or rebuilt. After a fabric-management event, decoder, endpoint, DCD-extent, and region identities must come from the current topology; cached names describe stale routing rather than the memory currently backing the page.

DAX/System RAM conversion changes OS exposure, another interleave order changes routing, and DCD release/re-add changes the host’s capacity assignment. The same HPA can also resolve through a different decoder after reconfiguration. Rewalk the process page and decoder route after any of those events.

Page Placement, Tiering, and Migration

A correct CXL route reaches the exposed memory range. Locating the workload’s current page also requires the page allocator, NUMA and cpuset policy, reclaim, page migration, and memory-tiering history after that range becomes System RAM.

Linux documentation makes the boundary explicit: CXL Type-3 capacity can become DAX or normal pages through the kernel page allocator; NUMA memory policy controls allocation preference; page migration can move the physical page while preserving the process virtual address; and automatic NUMA balancing with NUMA_BALANCING_MEMORY_TIERING can use page-fault-based sampling to move hot pages toward faster memory. “This process virtual address is backed by CXL” is valid only for the page placement resolved after the latest allocation, migration, or tiering event.

Once CXL capacity becomes System RAM, the decoder no longer decides which process receives a page; the allocator and memory policy do. Replay the route after first touch, reclaim, migration, tiering, or offlining rather than relying on the region-creation state.

virtual address range
  -> VMA or mapping policy
  -> initial allocation node and memory policy
  -> page fault or first-touch allocation
  -> reclaim, demotion, promotion, migration, or tiering decision
  -> current PFN/HPA
  -> CXL or local-DRAM route replay
  -> object, delivery, and behavior join

The virtual address and object pointer can remain stable while the backing page moves. Compare the current PFN and HPA with the CXL route after the most recent placement event.

Coherency, Caching, and Failure Modes

CXL.cache and CXL.mem add coherency and memory semantics, but they do not make every device observation equivalent to a CPU load. CXL.cache provides coherent device access to host-memory cache lines. Address-translation caching remains a separate ATS, IOMMU, or device-TLB function. A host may load or store device memory through CXL.mem; a Type-2 device may combine accelerator semantics with host-managed device memory; and a Type-3 device may present expansion memory that the OS later converts to DAX or system RAM. Each case has a different route to process memory.

CXL.io inventory, CXL.cache coherency, CXL.mem capacity, HDM decode, and fabric management describe different state. Collapsing them turns mailbox visibility into memory visibility, coherency participation into process-object identity, or fabric capacity into hidden-information access.

Protocol role	Typical device class	Direction that matters	Direct reading	Common overreach
CXL.io layer	Type 1, Type 2, Type 3	PCIe-compatible enumeration, configuration, MMIO, mailbox, MSI/MSI-X, AER, DOE, IDE capability, and management path	a CXL-capable endpoint or management path exists	configuration visibility means memory visibility
CXL.cache	Type 1 and Type 2	device-side coherent access to host memory cache lines under the platform coherency domain	a device can participate in coherent host-memory transactions under a declared topology	coherent device access identifies a process object
CXL.mem	Type 2 and Type 3	host load/store access to host-managed device memory through HDM route and OS exposure	host physical address space can be backed by device memory under the active decoder and region state	CXL-backed HPA equals local DRAM or game object memory
Type 2 accelerator memory	Type 2	accelerator combines host-memory coherency and device-local memory semantics	accelerator memory and host coherency both need a route-specific mapping and coherency trace	GPU/accelerator memory is automatically CPU process memory
Type 3 memory expansion or pooling	Type 3	host-managed device memory, volatile or persistent, optionally interleaved or pooled	firmware, the OS, or a fabric manager controls the capacity	hidden endpoint observation

CXL.cache makes a device a coherent participant in host-memory traffic. Device memory comes through CXL.mem on Type-2 or Type-3 devices; the Linux CXL device-type documentation assigns no host-managed device memory to Type-1 devices. The backing store is local DRAM or Type-2/3 CXL.mem. A Type-1 or Type-2 device may separately be a coherent requester or cache holder for host-memory lines.

CXL.mem can place device memory in the host physical address map, but the decoder route, endpoint DPA, OS exposure mode, and current process page still identify the backing path. CXL.io exposes mailbox and capability state rather than that memory path.

Do not collapse every problem into a generic “CXL memory issue.” A decoder mismatch breaks the root-to-endpoint route. Interleave drift changes endpoint attribution. A stale DCD extent or host assignment invalidates capacity attribution. Confusing DAX, pmem, System RAM, and allocator state loses the OS exposure mode. A platform-specific SPA/HPA/DPA conversion can leave the address unresolved, while hot removal, poison, or IDE/TDISP changes belong to lifecycle, RAS, or transport rather than process-memory access.

CXL topology and PCIe link protection change for different reasons. CXL 4.0 defines 128 GT/s links, bundled ports, and memory-RAS enhancements. PCI-SIG IDE and IDE_KM define protected TLP transport, key sources, AEAD lifetime, and ordering constraints. To connect them, identify the endpoint and port topology, bundled-port membership or single-port route, decoder and interleave state, OS exposure and page placement, and any IDE, SPDM, or TDISP transport state. The protected transaction must then reach the process page, object, and delivery path.

A specification describes permitted behavior rather than a particular endpoint. In a bundled topology, each member port still needs its own requester, PASID, ATS-validity, reset, and protected-transaction history. A centralized TSP or IDE control point covers policy, while a reset on one member port can invalidate that port even if the logical device survives. Process page, game object, and delivery route come from later mappings and transactions.

Bundled ports require a cross-port comparison. One member can receive a different IOMMU view while another consumes an ATS result; a single link can reset while the logical device survives; or the decoder/interleave route can be rebuilt without changing the workload. A shared device name is insufficient to identify a common translation or memory view across those cases.

A decoder-route change affects routing, while moving the endpoint DPA resource changes the backing range. DAX/System RAM conversion changes OS exposure, and an IDE/TDISP reset changes link or assignment security rather than page placement.

Poison, Viral State, RAS, and Containment

CXL memory needs separate error-containment state. A range can be routed correctly and still return a poisoned line, trigger a broader viral indication, surface AER or protocol errors, enter scrub or repair handling, or disappear through hot-remove and driver teardown. Those events describe lifecycle and RAS state; they become cheat-relevant only after they are tied to the route, process page, and game state.

Public sources cover different layers of CXL error handling. Microchip’s RAS in CXL Memory Controllers note describes poison and viral as containment mechanisms for corrupt or suspect data, with poison tied to specific data and viral tied to broader failure containment.

Linux CXL documentation models CXL.mem devices as PCI devices with MMIO mailboxes, memdev state, endpoint ports, HDM decoder topology, and OS-owned mailbox command paths. Linux EDAC RAS documentation shows CXL memory drivers participating in scrub, ECS, sparing, PPR, and memory-repair style feature exposure.

QEMU CXL documentation is valuable as an emulation vocabulary source for CXL.io, AER, DOE, IDE, Type-3 memory devices, HDM decoders, and the explicit limitation that QEMU’s overview considers a single-host static configuration and not fabric management. These source families can anchor RAS vocabulary; they cannot by themselves establish hidden game-state access or malicious endpoint behavior.

The RAS path is distinct from the memory route. Poison, viral, AER, scrub, repair, and hot-remove records describe error containment rather than process pages, game objects, or delivery consequences. Until the affected address is resolved through the current route, the record describes only a fault or loss of service.

CXL endpoint or port error source
  -> CXL.io/AER/protocol error or mailbox event
  -> poison, viral, media error, scrub, repair, or hot-remove state
  -> HPA, DPA, endpoint decoder, region, or extent affected
  -> OS containment response: kill, SIGBUS-like fault, machine check, offline, repair, remap, or log
  -> process page and object identity
  -> game tick, delivery, input, or server/replay consequence

An incomplete RAS sequence identifies a hardware or availability event, not intent or gameplay. AER reports transport or protocol errors. Poison names suspect data at a physical or device-memory location, while viral indicates broader containment. Scrub, ECS, sparing, PPR, and repair describe maintenance; hot removal changes availability; machine check or a SIGBUS-like fault records the access failure seen by the CPU or OS. None of those records identifies a game object until the affected address is resolved through the live route and process mapping.

CXL RAS records can explain why a memory read failed, why a page vanished, why a device reset occurred, why a host saw a machine-check path, or why a fabric route became stale. Poison follows a physical or device-memory location and its containment policy, not a game object. To relate the event to game state, resolve the affected HPA through the current decoder and region into the process VMA or DAX mapping, then show that the game or an assigned device accessed that location while the poison or containment state was active.

Cheat-Relevant Meaning

For hypervisor-based cheats, CXL matters in two cases. Both require endpoint topology, the OS memory-policy path, current page placement, and the delivery route. CXL widens the set of possible backing stores beyond local DRAM to device-backed and pooled memory.

First, a DMA or fabric-memory cheat hypothesis must distinguish transport from control. CXL may provide memory expansion, accelerator coherency, memory pooling, or trusted assignment, but the cheat still needs a process root, a current route to bytes, a semantic object, and a delivery path. A CXL range that happens to back process pages is not automatically a hidden-information primitive; it becomes relevant only when the route maps into a game address space and leads to a player-visible advantage.

Second, absence from local DRAM is not absence from memory. In a fabric-memory system, a negative result must name the inspected ranges, represented OS exposure modes, included backing stores, and whether the comparison covered CXL-backed pages. A scanner limited to local DIMMs can be correct about local DRAM and wrong about endpoint or pooled memory.

Fabric Management and Dynamic Capacity

A Fabric Manager action changes fabric resources. CPU page tables, OS page allocation, and game-object identity belong to later software layers. A DCD extent can back a current process page only after the decoder route, OS exposure, page placement, and process mapping line up in time.

Current public material places fabric management outside CPU page-table control. The CXL Consortium resource library supplies the 4.0-family and fabric-management specification context.

Linux device-type documentation describes a DCD as a Type-3 device with allocator-like physical-memory capacity management for a Fabric Manager, and it separates volatile or persistent extents from exclusive or shared host assignment. QEMU’s CXL documentation is intentionally narrower: it documents emulated CXL topology while explicitly ignoring fabric-management aspects by considering a single host and a static configuration.

The public CXL Fabric Manager infrastructure shows what a management trace must record: DCD information, host dynamic-capacity region configuration, extent lists, add requests, and release requests. None of those operations by itself supports the stronger sentence that the OS accepted memory, that a process page landed there, or that a player received hidden information.

Fabric Manager, DCD, memory pooling, multi-host sharing, and dynamic capacity each pass through the runtime management sequence below. It begins with a live management session, then separates extent snapshots, add or release requests, decoder materialization, OS exposure, page replay, and game delivery.

fabric_manager_or_host_management_session
  -> fabric_manager_identity_and_target_host
  -> device_or_logical_device_identity
  -> host_dynamic_capacity_configuration
  -> extent_list_snapshot
  -> add_or_release_transaction_request
  -> device_or_host_capacity_completion
  -> decoder_route_and_region_materialization
  -> dax_or_system_ram_exposure
  -> current_process_page_replay
  -> resolve_current_game_object
  -> correlate_output_with_later_input_or_replay

Fabric Manager state, DCD configuration, extent snapshots, add or release requests, shared-extent policy, QEMU topology, and IDE or TDISP transport all describe different parts of fabric management. A specification identifies the vocabulary; a management interface identifies control capability; an extent snapshot identifies one assignment; completion says a capacity operation finished. OS exposure, current PFN placement, and process use come later. A single-host QEMU topology also cannot stand in for multi-host Fabric Manager behavior.

Local DRAM and CXL System RAM can back the same virtual-address shape, and a DCD extent can move after add or release operations. Route reconstruction must follow the new extent and host assignment. A single-host QEMU topology cannot validate multi-host Fabric Manager behavior even when its decoder objects look similar.

If the report follows the old extent snapshot rather than the current route and page placement, it reflects stale management state. If it follows the current extent but loses the process or game mapping, it describes fabric-capacity assignment rather than cheat operation.

A local-memory view may describe local DRAM correctly while omitting Fabric Manager state, DCD extents, or CXL System-RAM pages. DCD and Fabric Manager state is ordinary on research, cloud, workstation, and memory-pooling systems. State which memory ranges and exposure modes were examined, preserve current page placement, and resolve the route again after fabric-management events.

Shared Memory and Process Isolation

The next CXL research question goes beyond routing a host physical address. It asks who may use a shared disaggregated-memory range after the host is authorized. Recent CXL memory-sharing research makes the gap explicit: conventional virtual memory provides process-level isolation within one host, while CXL fabric policy is usually expressed at host, device, logical-device, extent, or region granularity. A host can be authorized for a remote-memory range without identifying which process could touch each subrange at the time of a game event.

This is a research result, not a deployment statement. A paper or prototype that proposes process-level access control for shared CXL memory can identify a real architectural pressure point: host-level authorization is too coarse for least-privilege process statements. Production gaming endpoints, OS bypass, game-process use of remote extents, and extraction of hidden information remain outside that result. Permission for a host to use fabric memory is not permission for every process on that host.

The isolation sequence separates host authorization from process permission. This distinction is mandatory for shared disaggregated memory because a host, TVM, logical device, extent, or region can be authorized while nothing yet establishes that a specific process or address space could access the alleged subrange. Device identity and host authorization precede extent assignment, OS exposure, page placement, process permission, and a current access. Game objects and delivery come last.

Host-level or TVM-level fabric authorization admits a host or trust domain. Process-memory access requires a finer-grained permission and the current page mapping. A research proposal can show why that isolation is useful while leaving deployment on a particular endpoint unresolved. Host assignment, DAX or System RAM exposure, a proposed permission table, a cache hit, and a revocation event each stop at a different layer.

Host assignment and process permission are independent. A shared extent can remain assigned to one host while process permission changes, and the same permission can persist while the page moves through DAX, System RAM, or NUMA tiering. Host-level authorization identifies an admitted host, not the process that could access a subrange.

Fabric-memory reasoning needs both range coverage and process isolation. State which memory ranges were examined and which component enforced process permission. In ordinary systems that may be the OS page tables and memory manager. Shared disaggregated-memory research systems may add hardware or software permission tables, access-control caches, revocation generations, or TVM/fabric policy. Host-level authorization alone is insufficient to claim game-process access.

Freshness, Replay, and Offloaded Integrity

The next CXL research question is freshness at disaggregated-memory scale. A current fabric route can still return a stale value, replay data from an old extent snapshot, or depend on version metadata whose trust root sits outside the CPU package. Route state, returned data, version metadata, and game-object lifetime can disagree.

Recent CXL freshness research illustrates the pressure point. Toleo frames freshness as a versioning problem for very large CXL-expanded memory pools and proposes trusted smart memory over a secure CXL IDE network as a way to store and protect version metadata without a conventional large Merkle-tree bottleneck. The design separates version storage, the root of trust, version confidentiality, protected-link coverage, and the memory pool itself. Its subject is large pooled memory rather than gaming endpoints, hypervisor reads, DMA acquisition, or local scanning of a current process page. A protected link covers transport. A version check covers the named range and policy. A matching CPU reread compares one route, and a page-table walk identifies the current process mapping. These results cannot be substituted for one another. Object lifetime, semantic decoding, and the later output determine whether the completed transaction carried current game state.

Local DRAM scans, CXL route inventories, trusted-I/O transcripts, and version metadata can all be correct while describing different memory ranges or moments. Connecting them requires a current decoder route, a matching returned value or version check, a current process mapping, the game object, and the later output or behavior.

TEE-I/O, TDX Connect, and Trusted Device Assignment

Trusted I/O controls how a confidential VM identifies a device, accepts an assigned interface, protects PCIe traffic, and authorizes private-memory transactions. Game semantics begin after the payload resolves to a process object.

Trusted I/O is not ordinary device passthrough with a stronger adjective. In a TDX Connect-style model, the CPU/TDX module acts as a TSM, the device contains a DSM, the assigned interface is a TDI, SPDM establishes identity and secure messaging, IDE protects PCIe traffic, IDE_KM manages IDE keys, and TDISP drives the TDI state machine. The important states are protocol and runtime boundaries, not marketing labels.

The public sources cover different layers. PCI-SIG TDISP defines the TVM/device relationship and TDI attach/detach state. DMTF SPDM defines identity, certificates, measurements, and secured messages. Intel TDX Connect places TDI assignment inside TDX, VT-d, and the TDX module, including TD-side validation and private MMIO/DMA acceptance. AMD TIO defines a separate SEV-SNP path through firmware, guest messages, the RMP, and the IOMMU. Linux PCI/TSM exposes bind operations and scoped guest requests through a kernel interface.

Game-process bytes, host plaintext visibility, and player-visible advantage require later observations beyond those source records.

SPDM certificates, measurements, and a secured-session transcript identify a device under the negotiated protocol revision. IDE identifies the protected stream and key generation. The TDISP state machine uses CONFIG_UNLOCKED, CONFIG_LOCKED, RUN, and ERROR. Stop, unbind, detach, and reset are transitions or lifecycle events, not additional TDI states. Only guest validation and accepted MMIO/DMA mappings bring the interface into a confidential guest’s trusted path. A runtime transaction still needs the requester, IOMMU domain, target address, and completion or fault.

Trusted I/O is a state machine, not a device-capability checklist. The sequence below separates identity establishment, configuration lock, TD or TVM acceptance, trusted transactions, and cleanup. A reset, detach, failed bind, insecure-state transition, or TSM failure invalidates some or all of the earlier state. Rekeying is narrower: it changes the IDE keys while the SPDM session or TDI assignment may remain valid.

discover device and TDI
  -> establish SPDM secure session between TSM and DSM
  -> obtain device identity, certificates, measurements, and capabilities
  -> configure TDI while CONFIG_UNLOCKED
  -> lock configuration into CONFIG_LOCKED
  -> obtain and verify interface report
  -> bind TDI to the TD if the TD accepts the device into its TCB
  -> enable trusted MMIO and trusted DMA
  -> run with IDE-protected traffic and IOMMU enforcement
  -> stop, drain, unbind, revoke mappings, destroy keys, or enter ERROR on violation

The management transport usually has its own visible chain:

PCIe DOE extended capability discovered
  -> supported data-object protocols discovered
  -> CMA-SPDM message exchange over DOE
  -> device certificate, identity, measurements, and capabilities retained
  -> IDE_KM establishes selected IDE stream keys
  -> TDISP config/report/lock state is evaluated for a TDI
  -> TD or TVM acceptance binds the device interface to the confidential workload
  -> trusted MMIO, trusted DMA, completion, reset, rekey, or fault lifecycle is observed

Device inventory is the first stage. DOE and SPDM establish transport and session state, CMA adds measurements, IDE_KM configures protected traffic, and TDISP can move a TDI to RUN. A trusted DMA transaction comes later. Each record should retain the stage that produced it.

These states should be read literally. An SPDM transcript identifies a device and secured session. IDE protects selected traffic. CONFIG_LOCKED records locked TDI configuration, while RUN records the TDISP operational state. Neither one says that the confidential guest accepted a private-memory transaction. ERROR, stop, unbind, detach, and reset end or rebuild different parts of the assignment and may invalidate the earlier mappings or keys.

SPDM PQC Negotiation and Hybrid Cryptography

DMTF published SPDM 1.4.1 on July 2, 2026, superseding 1.4.0. Hybrid traditional/PQC support proposed for SPDM 1.5 remains under public feedback through August 31, 2026, not a published endpoint baseline. PCI-SIG’s CMA PQC support ECN defines a separate PCIe capability, libspdm supplies a reference implementation, and QEMU supplies an emulation harness. None substitutes for the algorithm set negotiated by a real requester and responder.

Published capability and negotiated runtime state are different records. SPDM 1.4.1 defines its current algorithm vocabulary, while the SPDM 1.5 hybrid work remains a proposal. The PCIe CMA PQC ECN defines PCIe capability fields where implemented. libspdm and QEMU can exercise those paths in software. Only the requester and responder transcript identifies the algorithms selected for a session, and that transcript still precedes IDE setup, TDI acceptance, and trusted DMA. Larger certificates, signatures, ciphertexts, and transcripts also change latency and buffer sizing without saying anything about the payload’s later use.

Runtime Reset, Rekey, and Fault Handling

TDI RUN, the SPDM session, IDE keys, and guest acceptance have different lifetimes. An IDE rekey starts a new key generation while leaving the SPDM session and TDI assignment in place. Reset, stop, detach, revocation, loss of guest acceptance, or an error transition can invalidate broader state and may require reconnect, reassignment, or fresh guest acceptance. Check later transactions against the component that actually changed.

Linux PCI/TSM Bind, Guest Requests, and Sysfs

Linux PCI/TSM turns the trusted-I/O vocabulary into concrete kernel state. It exposes the connection, whether a function is bound as a TDI for a KVM private-memory context, which request class reached the TSM/DSM path, and where the API prevents a guest request from becoming an arbitrary host or device operation. A game-memory transaction still needs a target address, trusted mapping, requester operation, and completion.

Linux PCI/TSM exposes trusted I/O through several narrow kernel interfaces rather than one all-purpose trust result. Read the implementation in its native order: device-class readiness, connection through SPDM/DOE and optionally IDE, DSM identity and managed-function set, the VFIO/IOMMUFD-initiated bind, the resulting locked, running, or error state, the guest-request class, and result or residue accounting. Disconnect, unbind, or driver teardown ends that lifetime.

Linux PCI/TSM sysfs state, bind results, guest requests, residue, and debug operations remain within that kernel interface; they do not acquire TDISP runtime or payload meaning by association.

Linux PCI/TSM fact	Kernel-visible state	Missing TDISP or payload relation
/tsm/connect is populated	a platform TSM connection exists	TDI bound or trusted transaction
/authenticated with tsm/ directory	connection alias in the TSM namespace	trusted DMA or TD assignment
/authenticated without tsm/ directory	native CMA-SPDM authentication state	TDISP assignment
/tsm/dsm names a DSM	the DSM and managed-function set are identified	payload meaning or access
/tsm/bound is populated	TDI is bound in a TDISP operational state	game memory was touched
pci_tsm_bind() succeeded	device function was bound as a TDI for a KVM private-memory context	bind remains valid after reset/unbind/lifetime break
pci_tsm_guest_req() returned success	guest request was marshaled and handled within a scoped class	trusted payload transaction
positive residue returned	partial input/output accounting exists	semantic success or failure of the guest operation
tsm_code populated	implementation-specific result for guest consumption	host access to payload semantics
debug-write class allowed	privileged out-of-model debug operation may affect device state	normal TDISP behavior

Linux PCI/TSM exposes enough states to test them separately. Compare authenticated with and without the tsm/ namespace, connect without binding, bind without reaching RUN, and break the VFIO driver-bound lifetime. Positive residue and a populated tsm_code also need to remain result-accounting facts rather than being promoted to payload success.

IDE Stream Coverage and Requester Binding

IDE is often described as link encryption, but each stream covers selected traffic. A Selective IDE stream has an index, setup and enable state, keys, and either explicit requester/address associations or a defined default-stream role. TDX Connect uses Selective IDE and describes a shared device default IDE stream for TDI traffic; that default role is not a separate Link IDE stream type.

Linux’s PCI/TSM-facing IDE helpers expose this as partner-port and register state. The implementation allocates stream resources, binds requester and address associations, programs partner ports, enables the stream, and later disables or tears it down. One RID range or address window defines the covered traffic for that stream and key generation. A different requester, path, peer-to-peer transaction, rekey, reset, link-down, or insecure-state transition needs a new coverage check.

At link level, an enabled stream protects PCIe TLP traffic matching a specific requester and address association during one key generation. TDISP assignment, TD acceptance, the trusted DMA target, host plaintext visibility, process memory, and game meaning all sit outside that statement. Intel TDX Connect places IDE inside a larger TDX/VT-d/TDX-module assignment chain. AMD TIO, formerly SEV-TIO, combines it with ASP, IOMMU, root-complex, RMP, SPDM, and TDISP state. PCI-SIG’s public IDE/TDISP overview describes the common link property: TLP confidentiality, integrity, and replay protection rather than payload semantics.

The IDE record needs the stream ID, requester and address range, key generation, setup and enablement state, observed transaction or error, and any reset, rekey, disable, teardown, or insecure-state transition. Capability, stream allocation, key establishment, protected traffic, completion, and error reporting are separate facts. Collapsing them into “encrypted link” loses the fields needed to tell what happened.

IDE record	Link-protection state	Missing transaction or payload relation
IDE capability exists	device or port has IDE vocabulary	an observed protected transaction
stream allocated but not enabled	stream resources are reserved	encrypted runtime traffic
stream enabled without explicit RID/address association	stream enablement is visible, but covered traffic is unknown unless the default-stream role is also recorded	coverage of the target requester or address
IDE_KM key generation observed	keys were active for the recorded generation	continuity of protection for later traffic
secure state later became insecure or link-down	continuity break or link event	uninterrupted trusted DMA
covered protected transaction	selected TLP traffic used the protected stream	TD-private payload or process memory
replay/integrity error	transport-side anomaly	malicious cheat activity

An IDE stream covers its associated RID, protected address window, and active key generation. Traffic outside those bounds uses another protection state. Until a covered transaction reaches the trusted DMA target, the record remains link-level; payload semantics come from the target and consumer.

IDE stream state mainly constrains the route. It can show that a device path was protected, interrupted, rekeyed, or scoped differently from ordinary DMA. It cannot identify the protected bytes as game state, establish that a host observer should have seen plaintext, rule out the path from a clean host capture, or show that a player received a hidden cue. Those later steps require the protected transaction to resolve to a current game-process page and output path.

IDE Ordering, Rebinding, and Completion Tags

IDE protects PCIe TLPs, while higher-level assignment transitions keep their own ordering and lifetime rules. PCI-SIG’s December 2025 IDE vulnerability notice lists forbidden IDE reordering, delayed posted redirection, and completion-timeout redirection. They affect different transaction classes and arise at different points in the transaction lifecycle.

Failure	Transaction property	State that crosses the wrong boundary
forbidden IDE reordering, CVE-2025-9612	protected TLPs still depend on ordering enforcement across the path	an attacker-controlled reorder can violate the order expected by the IDE/TDISP security model under affected conditions
delayed posted redirection, CVE-2025-9614	posted writes have no completion returning to the requester	an old posted write can survive long enough to reach a newly bound security context if the old stream is not drained and re-keyed correctly
completion-timeout redirection, CVE-2025-9613	a non-posted request uses a tag to match its later completion	a timed-out tag can return to the available pool, be reused, and then alias a late completion from the previous request

The second case is a rebinding problem. Suppose a TDI leaves one trusted domain and is assigned to another. The interface state can look current while an old posted write remains in a switch, bridge, or endpoint queue. Teardown must drain the old stream and retire its keys before the new binding becomes active; otherwise the old transaction can cross into the new assignment.

The third case is temporal aliasing. A non-posted request is outstanding until its completion arrives or the request times out. Releasing its tag after a timeout is necessary for forward progress, but the same numeric tag may then identify a new request. A late completion from the old request must not be accepted for the new one. The identity is not merely (Requester ID, Tag). It also includes the request generation, IDE stream and substream, TDI binding generation, timeout or drain state, and completion generation.

PCI-SIG’s March 2026 IDE TLP Reordering Enhancements ECN adds the optional IDE Escort mechanism. It introduces escort messages and new non-posted/completion substream values, tightens ordering rules, adds per-stream control, and extends TDISP policy handling through LOCK_INTERFACE_REQUEST and BIND_P2P_STREAM_REQUEST. The ECN also adds implementation guidance for delayed posted and completion-timeout redirection.

IDE Escort is optional. Record the PCIe and ECN capability level, whether the relevant stream enabled Escort, requester and address association, TDI binding, key generation, outstanding request set, timeout and tag-reuse history, posted-write drain, and completion. A protected TLP confirms transport protection. The remaining lifecycle determines whether that protection continued across reordering or rebinding.

TDX Connect ABI and TDISP Lifecycle

In the Intel TDX Connect Architecture Specification, June 2025, phrases such as “TDI is bound” and “trusted DMA is enabled” refer to different ABI stages. The architecture names feature discovery, I/O-hub enablement, SPDM connection, Selective IDE key management, TDI binding, TD-side validation, MMIO/DMA acceptance, TDI start, and teardown as separate operations.

Generic TDISP messages and Intel TDX-module ABIs form adjacent layers. TDISP locks, reports, starts, and stops the interface and moves it through CONFIG_UNLOCKED, CONFIG_LOCKED, RUN, and ERROR. The TDX module, host VMM, TD guest, and DSM give those transitions Intel-specific meaning. Record the protocol state, module ABI result, TD acceptance, and covered transaction in that order. Game relevance begins after the transaction reaches the process page and output route.

Each TDX Connect ABI exposes one part of the path; trusted transactions, private memory, process memory, and game state require the additional records shown below.

TDX Connect stage	Recorded state	Direct ABI state	Next required record
module support	TDX_FEATURES[TDX_CONNECT], TDX_CONNECT_FEATURES	the module and platform advertise TDX Connect	I/O hub enablement and device connection
I/O hub setup	TDH.IOMMU.SETUP, restricted access to VT-d/IDE/ACS registers	TDX Connect enforcement state	SPDM/IDE device connection
SPDM object and connection	TDH.SPDM.CREATE, TDH.SPDM.CONNECT, SPDM object pages, SPDM_DEVICE_ATTESTATION_INFO	the module holds device identity and attestation state	IDE stream and TDI binding
IDE stream	TDH.IDE.STREAM.KM, Selective IDE stream, keys, RID/address associations, and device default-stream role where used	keys protect the named Selective IDE stream for one generation	TDI report and TD acceptance
TDI bind	TDH.TDI.BIND, TDISP report, CONFIG_LOCKED state, pending MMIO/DMA mappings	the TDI has assignment state in the module	TD validation and mapping acceptance
TD validation and acceptance	TDG.TDI.VALIDATE, TDG.TDI.ACCEPT, device-attestation digest comparison	TD verified the host-delivered device and TDISP transcript and accepted the TDI	MMIO/DMA acceptance and TDI start
MMIO/DMA activation	host-side TDH.MMIO.MAP and TDH.DMAR.ADD, followed by TD-side TDG.MMIO.ACCEPT and TDG.DMAR.ACCEPT	pending mappings became TD-accepted private MMIO and trusted-DMA mappings	requester/address transaction and completion
RUN transition	TDG.TDI.START, TDH.TDI.START, secure TDISP message through DOE mailbox	the TDI reached its operational state	covered transaction, process page, and delivery
unbind/disconnect	TDH.TDI.UNBIND, TDG.TDI.RD, TDH.IDE.STREAM.BLOCK, TDH.SPDM.DISCONNECT, TDH.SPDM.DELETE	teardown or recovery changed the lifecycle	continuity after rebind/rekey/reset

Device assignment and TD attestation are separate protocols with separate state, messages, reports, and verification rules.

TDG.MR.REPORT creates a local TDREPORT from TD state and caller-supplied REPORTDATA. The structure separates a MAC-bearing REPORTMACSTRUCT from TEE_TCB_INFO and TDINFO. TEE_TCB_INFO describes the TDX module and its TCB, including MRSEAM, the measurement of the loaded TDX module, and MRSIGNERSEAM where signer-based identity applies. TDINFO describes the TD itself: MRTD measures the TD build process and initial measured contents, while RTMR[0..3] are extend-only runtime measurement registers used by the TD software stack. REPORTDATA lets the caller bind 64 bytes of application-chosen data, commonly a nonce, public-key hash, or protocol transcript digest, to that report instance.

A TDREPORT is a locally verifiable report protected by the report MAC; it is not yet a remotely verifiable quote. Quote generation packages the relevant TD report body into a signed TD quote through the TDX quoting path. A remote verifier must still validate the quote signature and certification chain, evaluate TCB status, check freshness through bound challenge data, and compare MRSEAM, MRTD, RTMR, attributes, and policy-defined identity fields with expected values. A valid signature authenticates the quote; acceptance of the measurements and the software they describe is a separate policy decision.

Only after appraisal can those objects support a statement that a particular TDX module and TD measurement set matched policy for a fresh challenge. They still do not say that a TDI reached RUN, that an IDE stream protected a specific transaction, that trusted DMA targeted a private page, or that the target page belonged to a game process. In a TDX Connect discussion, the attestation sequence and trusted-device sequence must be correlated explicitly:

fresh TDREPORT and TD quote
  -> TD policy accepts the device and interface report
  -> TDX Connect ABI binds and starts the TDI
  -> trusted MMIO or DMA mapping is accepted
  -> covered requester transaction completes
  -> target GPA resolves to a game-process allocation
  -> the game consumes the data or the result reaches its output path

A valid TD quote can coexist with no trusted-device transaction, and a valid TDISP transcript can coexist with no TD-side policy acceptance. The two become relevant to the same event only after the accepted TDI performs a transaction that resolves to process memory and a later output.

The important non-equivalence is guest acceptance versus host orchestration. The host VMM can orchestrate SPDM message transport and TDX Connect ABI calls, but the TD guest must validate and accept the TDI into its trust boundary before private MMIO/DMA mappings become meaningful for the TD. A malicious, buggy, or incomplete host flow can deliver stale attestation data, fail to complete unbind, leave a report unvalidated, or require the TD to verify interface state with TDG.TDI.RD. Do not promote “VMM issued bind” into “TD-private trusted DMA was accepted” unless the TD-side validation, digest comparison, mapping acceptance, and later transaction are named.

The second distinction is trusted translation versus shared translation. TDX Connect separates trusted DMA translation state controlled by the TDX module from shared DMA state managed by the VMM. It also separates IOTLB, PASID, and context entries associated with TEE-I/O transactions from ordinary transactions. “An IOMMU mapping exists” is too weak. The statement must say whether the mapping is trusted or shared, who programmed it, whether the TD accepted it, whether invalidation completed before page release or TDI unbind, and whether the request carried the trusted transaction attribute that selects the private path. SPDM may remain connected with no IDE stream, IDE may be configured before TDH.TDI.BIND, and a bound TDI may still lack TD-side validation. Accepted mappings without TDH.TDI.START are not an operational device path, while ERROR or unbind invalidates the previous assignment. Each ABI result belongs to the stage that produced it.

What Trusted I/O Still Exposes

Trusted I/O can hide private payload bytes while leaving control and lifecycle signals visible. A host or external observer may still see device inventory, protocol state, resets, interrupt cadence, faults, queue pressure, rekeys, shared-memory traffic, and server-visible effects. Those signals describe the control path; they do not reveal plaintext or intent.

Private and Shared Memory in Trusted I/O

Trusted-device language becomes misleading when it skips the memory target. A trusted DMA or trusted MMIO transaction is not automatically TD-private plaintext, SNP-private plaintext, process memory, game object state, or player knowledge. At that point, all that is known is that a runtime transaction may have occurred. Its meaning depends on which memory path carried the bytes, which confidential-VM component allowed the access, which IOMMU or trusted translation root selected the target, and whether the transaction can be tied to a process, engine object, delivery path, and replay event.

Protocol, transport, assignment, memory, side effects, and game delivery change at different points in the device lifecycle.

Memory or transaction path	Component that permits access	Memory or transaction state	Missing process or game relation
TD-private memory	TD identity, Secure EPT state, PAMT ownership, private HKID or equivalent private attribute, KVM private-memory attribute where used	a private TD memory boundary exists for a named GPA/GFN mapping generation	host plaintext, process object, device transaction, or player cue
SNP-private memory	SNP guest identity, RMP entry, VMPL/ASID context, validated page state, IOMMU RMP check where SEV-TIO applies	an SNP-private access policy exists for a named page and requester context	Intel TDX behavior, host plaintext, or game meaning
shared or bounce memory	GHCI/GHCB shared pages, KVM userspace_addr, shared GPA/GFN attribute, bounce buffer, explicit mediation buffer	bytes were deliberately exposed or mediated through a host-visible path	the same bytes existed in private memory or represented full guest state
trusted transaction	TDI identity, TDISP state, TD or SNP guest acceptance, IDE_KM key generation, trusted MMIO/DMA mapping, IOMMU or trusted translation root, completion or interrupt	a device transaction occurred under the named trusted configuration	payload meaning, process association, or hidden-information delivery
guest-mediated disclosure	GHCI TDG.VP.VMCALL, GHCB/VMGEXIT, guest message, ASP/PSP-mediated command, host-transported SPDM transcript and measurement set	the guest or firmware deliberately exposed selected request/response fields	ordinary host introspection or full-register/full-memory visibility
side effects	interrupt cadence, completion queue, reset, detach, rekey, fault, queue pressure, server/replay consequence	lifecycle or activity only	payload bytes, malicious intent, or game causality

Intel publishes these documents on different tracks. Its documentation hub lists the 2025 TDX Connect architecture and device guide, baselined TDX module architecture and ABI material updated in 2026, and GHCI v2.0 for TDX Connect-related transactions in the community-review section. The base-module ABI applies to its own revision; TDX Connect and GHCI extensions retain their separately published status.

The Linux KVM API separates private guest_memfd backing from shared userspace mappings and uses a private memory attribute to choose the backing for a GFN. The Linux confidential-computing threat model explicitly treats port I/O, MMIO, DMA, PCI configuration, hypercalls, shared memory, and CoCo-specific hypercalls as explicit interfaces rather than raw host visibility.

AMD’s SEV-TIO material describes an ASP, IOMMU, PCIe root complex, SPDM, IDE, TDISP, RMP, and guest-trust path in which devices may access guest private memory only after the guest indicates trust in the device and configuration. These facts are strong enough to justify a private/shared/transaction boundary.

They are not enough to identify a generic cheat, characterize the endpoint, or connect the transaction to gameplay. That requires showing that the device was accepted into the TDX or SEV trust domain, identifying whether the target GPA was private or shared, and recording the exact MMIO or DMA request admitted by the IOMMU together with its completion or fault. Only after that target resolves to a process page and the game consumes the data can the transaction be connected to gameplay.

SPDM, TDISP, and IDE each describe their own protocol layer. The runtime transaction identifies a target, and the memory target determines whether the bytes were private, shared, or mediated. Guest requests expose selected fields. Interrupts, resets, rekeys, and faults expose activity but not the payload. The process page and output route then determine whether the transaction reached game state.

The target may be TD-private memory, explicitly shared memory, or a mediated bounce buffer under the same SPDM, TDISP, and IDE configuration. These paths expose different bytes to the host, so the memory target must be recorded separately from the protocol state.

A cloud or future endpoint can use trusted-device assignment to reduce ordinary host plaintext visibility while still exposing protocol transitions, side effects, guest-mediated state, endpoint activity, and server-visible behavior. A clean host plaintext view describes one observer. Device, guest, operator, and behavior paths require their own observations. TEE-I/O changes the private/shared/transaction boundary; it is neither automatic cheat concealment nor a blanket DMA guarantee.

Comparing TDX Connect with AMD TIO

The shared vocabulary is intentionally similar: TDISP, SPDM, CMA, IDE, IDE_KM, TDI, trusted MMIO, trusted DMA, trusted assignment, and confidential VM. The implementations are not. PCI-SIG TDISP supplies common device-interface protocol vocabulary; Intel TDX Connect and AMD Trusted I/O, listed by AMD as TIO and formerly known as SEV-TIO, place it inside different confidential-VM architectures, firmware paths, guest interfaces, private-memory rules, and attestation systems. “TEE-I/O” without a named vendor implementation says too little about the actual memory path.

The Intel TDX documentation hub and AMD SEV documentation hub, checked in July 2026, publish architecture and interface material rather than a list of consumer gaming deployments. The table identifies the roles defined by each source family:

Family	Primary public source	Architecture-specific components	Memory boundary	Common overreach
PCI-SIG TDISP / IDE / CMA-SPDM	PCI-SIG protocol family and ECNs	TSM/DSM/TDI protocol roles, DOE/CMA/SPDM transport, IDE stream	trusted-device protocol state only	protocol vocabulary is treated as private-memory access
Intel TDX Connect	Intel TDX Connect architecture and device-guide material	TDX module or TSM-side implementation, DSM, TDI, TD acceptance, IDE_KM state	TD private/shared state, Secure EPT/PAMT/HKID relation where cited	Intel behavior is projected onto AMD SEV-SNP
AMD TIO / SEV-TIO	AMD SEV page, SEV-TIO firmware interface Rev. 0.91, SEV-TIO overview paper, SNP/GHCB documents	AMD Secure Processor or ASP/PSP-mediated firmware path, SNP guest, TDISP device state, guest request or bind path	SEV-SNP private/shared state, RMP validation, GHCB-mediated disclosure, guest private address-space binding	AMD behavior is projected onto Intel TDX Connect
ordinary passthrough or VFIO	OS, IOMMU, VFIO, PCIe, and driver documentation	host VMM, IOMMU, PF/VF/mdev, driver, requester identity	host/guest DMA mapping, not CVM private-memory trust by default	passthrough is treated as trusted assignment

Intel TDX Connect needs one more boundary because its name can sound like a universal trusted-I/O umbrella. The June 2025 EAS material defines one revision of Intel’s TDX, VT-d, SPDM, IDE_KM, TDISP, and TDI-assignment architecture.

It should not be used to infer that advanced VT-d, every PCIe security extension, every SVA/PASID/ATS/PRI/SIOV path, or CXL trusted-memory behavior is present. The narrower reading is: “this TDX Connect source family describes Intel’s trusted-device assignment model.” Combining it with SVA, SIOV, ATS translation completions, CXL IDE/TSP, or future PCIe/CXL security features requires a source that defines the combination, a platform that implements it, the negotiated protocol revision, and a transaction tied to the target process and game state.

The same source family treats IOTLB invalidation as an ordered lifecycle rather than a footnote. In the TDX Connect model, trusted DMA entry removal and TD memory management are tied to blocking the relevant DMA-remapping entry, enqueuing IOTLB invalidation through TDX-module mediated interfaces, processing completion, and only then removing the trusted mapping.

The completion shows that trusted-DMA translation had been invalidated as required before the mapping was removed. Payload semantics, process-memory access, host plaintext visibility, and player advantage require separate observations.

For partitioned or nested TD contexts, the trace must name whether L1, L2, the TD, the TDX module, the VMM, or the IOMMU tracked and completed IOTLB invalidation before a page, PASIDTE, CTE, or trusted-DMA root changed.

When TDX Connect appears beside advanced I/O or CXL, keep the TDISP state, TDI binding, CXL route, and trusted transaction separate. A TDX Connect guide supplies Intel’s implementation vocabulary. TDI assignment still precedes TD acceptance and the private or shared target. Secure EPT or MMIOMT acceptance records memory-management state, while TDH.DMAR or TDH.IQ-style completion records trusted-DMA invalidation. L1/L2 partitioning identifies a nested TD context. None of those facts silently adds SVA, SIOV, ATS, or CXL support; that combination needs its own platform and transaction path.

Keeping the Intel and AMD models separate prevents their terms from drifting together. Keep the TDISP transcript but replace TDX Connect with ordinary VFIO, generic TDISP, AMD TIO, or a CXL route. Then restore TDX Connect and omit trusted-DMA invalidation completion or move the target to shared memory. The common protocol words survive; the vendor-specific memory rules do not.

The common protocol layer is separate from the vendor confidential-VM layer. A TDISP transcript records protocol state, while the vendor implementation supplies the TSM or firmware path and its confidential-memory rules. Guest acceptance or a guest request must precede a trusted MMIO or DMA transaction. Side effects and visibility limit what an observer can see; the process-memory mapping and game meaning must still be established separately.

TDX Connect, AMD TIO, generic TDISP, ordinary VFIO, and CXL IDE share protocol terms but not one lifecycle. For either vendor path, retain the measured device, secured management session, IDE stream and key generation, TDI state, guest acceptance, and transaction target. Reset, detach, and faults may invalidate assignment; rekey changes the protected stream keys. Connecting the transaction to a game still requires the target process page, the consuming game state, and the output path from the same interval.

AMD TIO Firmware Commands and Guest Messages

AMD TIO needs its own firmware-command lifecycle, not a translated TDX Connect lifecycle. AMD’s SEV documentation hub lists AMD EPYC 9005 as introducing Trusted I/O via TDISP, formerly SEV-TIO, and publishes the SEV-TIO Firmware Interface Specification Rev. 0.91, dated July 2025, as a technical preview. Applying it to a running system requires matching platform support, firmware revision, successful host commands, guest messages, and the later trusted transaction.

The AMD lifecycle differs from TDX Connect. The ASP executes SEV firmware and serves the TSM role for TDISP-capable devices, while host software orchestrates device resources and firmware commands. The guest uses SEV-TIO request messages to validate attestation objects and MMIO ranges, configure MMIO attributes, and write the Secure Device Table Entry (SDTE) that permits trusted DMA.

The IOMMU enforces RMP checks on DMA using SDTE fields such as guest identity and VMPL. Binding the TDI alone is insufficient: DMA into guest private memory remains blocked until the guest SDTE path authorizes it, and guest MMIO remains blocked until the validation path sets the relevant RMP Validated state for that range.

The AMD-specific sequence maps each firmware command or guest message to the state it directly supports and shows what is still missing for private memory, a device transaction, process memory, or game state.

AMD SEV-TIO stage	Recorded state	Direct firmware or guest state	Next required record
feature and platform initialization	FEATURE_INFO bit, SNP_INIT_EX with TIO_EN, TIO_STATUS, TIO_INIT	the platform and firmware advertise TIO support	device context and SPDM connection
host-donated context buffers	scatter-list address, Firmware page state, TIO_DEV_CREATE, TIO_TDI_CREATE	firmware created the context objects	device connection or TDI bind
device connection	TIO_DEV_CONNECT, SPDM buffers, IDE stream setup, device context state	the TDISP device is connected	fresh measurements and TDI report
TDI binding	TIO_TDI_BIND, TDI context, CONFIG_LOCKED/RUN transition, interface report	firmware bound the TDI to an SNP guest	guest attestation validation, MMIO validation, SDTE write
attestation freshness	TIO_DEV_MEASUREMENTS, TIO_DEV_CERTIFICATES, TIO_TDI_REPORT, TIO_MSG_TDI_INFO_REQ, MEAS_DIGEST_FRESH	guest can compare firmware-retained digests and freshness state	policy acceptance and trusted transaction
MMIO validation	TIO_MSG_MMIO_VALIDATE_REQ, TIO_MSG_MMIO_CONFIG_REQ, interface-report attributes, RMP Validated bit for MMIO	the guest validated the named MMIO range	DMA authorization and runtime use
DMA enablement	TIO_MSG_SDTE_WRITE_REQ, SDTE V bit, VMPL, vTOM, IOMMU RMP check	the TDI is authorized for private-memory DMA under that SDTE	actual descriptor/request/completion and target page
error and fence lifecycle	TIO_TDI_STATUS, ERROR state, host-page-table fault, RMP violation, ASID fence, TIO_ASID_FENCE_CLEAR	trusted-I/O continuity broke or recovery began	rebind, re-attestation, and a new transaction after recovery
teardown and recovery	TIO_TDI_UNBIND, TIO_DEV_DISCONNECT, TIO_TDI_RECLAIM, TIO_DEV_RECLAIM	the old device or TDI context was torn down	continuity across old/new device or TDI context

Host binding and guest enablement are separate. Host software can invoke TIO_TDI_BIND and obtain an interface report, but the guest must still consume the attestation objects, check the firmware-retained digest and freshness state, validate MMIO range attributes, and send the SDTE write request that grants private-memory access to the TDI. Without those guest-side steps, the trace shows a bound interface rather than trusted private-memory DMA. Host-side TIO commands also say nothing by themselves about a game-process page, hidden cue, or player action.

The second distinction is RMP/MMIO validation versus ordinary page validation. The SEV-TIO firmware preview states that ordinary PVALIDATE is not the MMIO validation mechanism for these ranges; the guest uses an SEV-TIO guest message so firmware can check the range and set or clear the relevant Validated bit. Treating MMIO validation as ordinary data-page PVALIDATE, or treating an interface report as confirmation that every BAR and range is private and trusted, is an overstatement. Private-MMIO wording needs the RangeID, guest physical range, interface-report attributes, RMP state, and guest-message generation.

ASID fencing turns a trusted-I/O fault into a continuity break. If a bound TDI causes a host-configuration fault such as a host page-table fault or RMP-check violation, the root complex and IOMMU can block further guest I/O for that ASID until every TDI on the root complex is unbound and the host clears the fence. The event records an AMD TIO ASID fence; payload semantics lie elsewhere.

Reusing the assignment requires unbind, fence clear, rebind, re-attestation, MMIO validation, an SDTE write, and a new transaction generation. AMD’s components do not map one-for-one onto Intel names. TIO_MSG_TDI_INFO_REQ refreshes TDI information, TIO_MSG_SDTE_WRITE_REQ authorizes trusted DMA through the guest SDTE path, and an ASID fence invalidates continuity after a fault. Private-memory access spans the firmware command, guest message, IOMMU decision, RMP check, and resulting transaction rather than one SEV-TIO command.

Protocol Revisions, Keys, and Security Advisories

Trusted-I/O terms refer to distinct protocol states: authentication, attestation, secured messages, IDE streams, TDISP state, GETKEY, AEAD limits, PQC negotiation, and trusted-device assignment. Each describes only its transcript, key generation, negotiated version, or covered transactions. None by itself shows that a trusted transaction reached a target page, that the page belonged to a game process, or that the result reached the player.

Protocol revision status is independent of deployment. DMTF lists SPDM 1.4.1 and Secured Messages 2.0.0 as published baselines for authentication, attestation, key exchange, and protected sessions. The SPDM 1.5 hybrid traditional/PQC material remains under public feedback and is not a published endpoint baseline.

PCI-SIG TDISP defines a trusted-I/O virtualization architecture for establishing a TVM/device trust relationship, securing the interconnect, and attaching or detaching a TDI, building on CMA/SPDM and IDE. PCI-SIG’s IDE_KM GETKEY and AEAD Limit ECN refines key-generation and AEAD-lifetime vocabulary for protected PCIe traffic.

PCI-SIG’s 2025 IDE vulnerability notice addresses protected-stream continuity. Applying it to an endpoint requires topology, ordering, mitigation, and retest coverage; identifying a cheat path or compromised device requires the affected transaction and workload.

The published SPDM, secured-message, authorization, PCIe ECN, TDISP, and IDE revisions define what can be negotiated. The endpoint transcript records what the requester and responder selected. Certificates and measurements identify the device. The secured session, IDE_KM state, GETKEY capability, AEAD limit, stream direction, and requester/address association define protected transport. TDI attach/detach, guest acceptance, and bind state define assignment. Trusted MMIO/DMA, queue completion, faults, interrupts, resets, and rekeys describe runtime activity. None of those protocol records contains the process page, game object, or delivery path.

Intel TDX Connect keeps these states separate. The public architecture material ties TEE-I/O transactions to IOMMU enablement, locked and consistent MMIO/DMA decode, root-complex routes, IDE selective streams using IDE_KM over an SPDM session, TD acceptance of a TDI before that TDI can access the TD’s private memory, and specific limitations or non-support notes for some transaction classes.

TDX Connect and AMD TIO/SEV-TIO expose different firmware interfaces, private-address-space assumptions, and attestation models. Their commands, reports, and state fields are not interchangeable.

Intel and AMD share TDISP and IDE terminology but retain distinct IOMMU state, decode rules, TDI acceptance paths, stream coverage, private/shared memory classification, and transaction restrictions. Generic protocol terms cannot substitute for the vendor-specific path. A TEE-I/O investigation can end at a protocol family, a published but unnegotiated revision, a transcript without assignment, a key without defined stream coverage, or a stream without a transaction. Those are different results, not one generic “TEE-I/O unknown” state. Security-advisory coverage and vendor transaction restrictions require separate checks. A trusted transaction reaches game state only after its memory target and delivery path are identified.

Paravirtual ABIs, Hypercalls, and Virtual Device Data Paths

Paravirtual devices add another host/guest data path. Their guest-visible ABIs replace parts of hardware emulation with hypercalls, synthetic MSRs, shared pages, ring buffers, event channels, grant references, virtqueues, vhost backends, vDPA devices, and host-assisted time, interrupt, TLB, or I/O services. Ordinary virtual-device activity can resemble hidden host work, and a hosted cheat can use the same plumbing while remaining limited to the buffers and services that the ABI exposes.

The ABI defines what each event means. A hypercall records invocation of a named guest-visible service; a virtqueue descriptor records a buffer offered under negotiated virtio state; Xen event channels and grant references record notification and capability-scoped sharing; and a VMBus GPADL records a channel-scoped shared-buffer mapping. None of these events identifies a game process or delivery path by itself.

Analyze each paravirtual mechanism through its ABI and data path:

Mechanism	Native object or record	Participating components	Direct reading	Common overreach
Hypercall ABI	VMCALL, VMMCALL, Hyper-V hypercall page, KVM or Xen hypercall ABI	guest and hypervisor ABI endpoints	a guest-visible service call was attempted or completed	hypercall reach becomes process-memory access
Synthetic MSR and shared page	Hyper-V reference TSC page, VP assist page, SynIC SIM/SIEF pages, synthetic timer MSRs	Hyper-V guest ABI	the guest consumed a synthetic time, interrupt, assist, or IPC object	synthetic page bytes become ordinary application memory
VMBus data path	channel offer, ring indices, VMBus packet object and completion state, GPADL, external PFN or MDL mapping	root/child partition plus VSP/VSC endpoint	a channel-scoped virtual-device transaction existed	virtual-device traffic becomes arbitrary host memory access
KVM paravirtual feature	kvmclock, async page fault, steal time, pv EOI, pv TLB flush, pv IPI feature exposure	KVM/QEMU paravirtual ABI	a hosted guest used or was offered a KVM pv optimization	hosted timing becomes endpoint-equivalent bare-metal timing
Virtio queue	feature negotiation, queue size, descriptor table, available ring, used ring, notification suppression, interrupt	guest driver plus device/backend	a buffer was offered, consumed, notified, or completed through a virtqueue	virtqueue buffer becomes game process memory
vhost or vDPA backend	vhost-user socket, vhost kernel backend, vhost-vDPA device, vendor control path	backend process, kernel, or hardware accelerator	virtio data plane was offloaded or accelerated	backend offload becomes invisible to the endpoint
Xen event channel	port, mask, pending bit, upcall, event-channel operation	Xen event fabric	a one-bit notification was signaled and delivered or masked	notification becomes payload or memory mutation
Xen grant table	grant reference, grantee domain, flags, map handle, host/device mapping, transfer state	Xen grant-table mediator	a page-sharing or page-transfer capability existed	grant capability becomes unrestricted memory visibility

These mechanisms do not share one state machine. A hypercall may be synchronous, pvclock exposes shared time data, a grant table conveys a scoped capability, and virtio or VMBus uses queues, rings, and notifications. For the queue-backed paths, the common shape is:

feature_or_capability_negotiation
  -> shared_state_object_created
  -> guest_offers_buffer_or_call
  -> hypervisor_or_backend_consumes_carrier
  -> notification_or_completion_returned
  -> guest_driver_updates_local_state

Start with ABI negotiation: feature bits, version fields, CPUID leaves, device status, the channel offer, or grant-table version. Next confirm that the shared object was active through its MSR bit, ring geometry, event-port binding, grant flags, backend file descriptor, or channel state. Descriptor direction, GPADL access mode, grant flags, IOMMU domain, backend mapping, and the PFN/GFN route identify which side could access the buffer.

Queue order comes from avail/used indices, event pending and mask bits, EOI handling, memory-ordering rules, completion time, and the backend or vCPU run. Reaching process memory then requires the first- and second-stage translations, OS page state, mapping changes, and lost-event accounting. Object lifetime, engine state, delivery, input, and replay place that buffer in current game state.

In a hosted or Type-2 design, acquisition, overlay, input relay, or decision support can run in a host or backend process while the guest sees ordinary paravirtual devices. A malicious virtual-device backend can observe buffers that the guest deliberately shared with it. The symptoms depend on the ABI: changed hypercall cadence needs the caller and service code; pvclock drift needs an independent time source; queue pressure needs the channel, buffer, and backend; an event-channel burst says only that notifications were delivered; a grant or GPADL identifies scoped sharing; and a vhost or vDPA transition identifies a change in the backend data path. None reaches game memory until the shared buffer is mapped back to the current process and its output route.

An ABI record is limited to the state that interface exposes. “A virtqueue completion occurred for queue Q under feature set F” is a virtual-device statement. “A VMBus GPADL mapped a client buffer into a server endpoint” is a channel-scoped shared-memory statement. “A Xen grant reference permitted domain B to map page P from domain A” is a capability-scoped sharing statement. Those records stop before host access to game memory; that conclusion also needs CPU translation, OS page state, object identity, and the delivery path to survive independent replay.

---

Specifications, Models, and Runtime State

Specifications define objects and state machines. A formal model checks a stated property inside its transition system. A trace records what one implementation did. Each answers a different question.

For example, the AMD SEV model cited here reasons about the transitions and observers chosen by its authors. Applying it to another system requires a mapping from target components to modeled states. A design-level TEE model covers its defined transitions rather than endpoint deployment. A property-level abstraction covers one selected property, and model checking covers paths reachable under its constraints. TDX, TEE-I/O, GPU, CXL, and game-process behavior need explicit additions to an SEV-family model. A modeled confidentiality property likewise reaches only its named observers; side channels, debug paths, device DMA, and player knowledge need their own treatment.

Validation Through Controlled Changes

Change one state and check whether the result follows it. Rebind the PASID while leaving the descriptor format unchanged. Move a process page while keeping its virtual address. Present one GPU queue result and discard another. Rebuild a CXL decoder route without changing the process VA. Reset or rekey a TDI between configuration and the next transaction. Each change isolates a different link in the path.

Negative results are equally narrow. No host plaintext under TEE-I/O describes that host observer. No local-DRAM backing describes the scanned ranges. A guest capture without an overlay describes that capture path; host compositors, second displays, capture devices, shared buffers, and server-visible actions require separate checks.

Avoiding Shared Inputs

Two tools are not independent if both read the same incomplete dump, use the same symbol profile, depend on the same VMM callback, or decode the same replay file. Agreement may reflect the shared input rather than the machine.

Two parsers that share a dump, missing pages, symbol table, or profile assumption have checked the same input. Compare them with another acquisition path or a raw-offset read built from an independent profile. A tool event and decoded trace row may also share the VMM backend, pause/rearm policy, timebase, and permission changes; vendor-native fields or a second backend provide a stronger comparison.

The same issue appears across environments. A KVM/QEMU lab event reproduces its configured machine model, memory slot, accelerator, and host scheduler. Matching it to a physical endpoint requires the vendor-native payload from comparable hardware. ETW and a behavior feature may share provider configuration, buffering, decoding, upload, and clock conversion. Preserve the raw ETW payload and align it independently with the server or replay tick.

LibVMI or DRAKVUF can share a Xen event route, profile, permission change, and callback re-entry with the process-byte decoder. A Windows page-state replay, another address walk, and the same process generation test that dependency. Replay and server analysis can likewise share the replay file, visibility labels, parser, and feature extractor; use a server-authoritative tick, connection-specific disclosure rule, and ordinary-source control where available.

Useful comparisons include an independently built parser profile, raw offsets read outside the original plugin, another trace backend, KVM output checked against vendor-native fault fields, and a server-authoritative tick instead of a replay label. The second result is useful only if it can fail independently of the first.

Ordering Rules Across CPU, Device, and Game State

These mechanisms do not form one universal translation path. A CPU load uses CPU page tables and, inside a VM, EPT or NPT. Device DMA uses an IOMMU translation and may also use ATS-cached entries in the device ATC. A GPU command may use a per-process GPUVA mapping. CXL HDM decoders route an HPA toward endpoint DPA. The translation used by each actor must be valid before that actor accesses memory; independent device DMA need not wait for a CPU load.

Names such as PCID, ASID, PASID, and RID select or tag a context. They do not translate an address. The translating structures are the CPU page tables, EPT/NPT, IOMMU page tables, GPU page tables, and CXL decoder hierarchy. Keeping the selector beside the structure matters because the same numeric PASID or RID can refer to a different mapping after unbind, reassignment, or device reset.

IA32_PASID adds another distinction. Linux can load it lazily when a thread first uses ENQCMD on a logical processor. Moving that thread to another CPU changes where the MSR must be loaded while preserving the process-to-device PASID binding. Fork, exec, unbind, and rebinding can change that binding. A useful record separates process mm and PASID allocation from thread-local MSR state and the descriptor that was actually accepted.

Event order still matters. An IOMMU mapping update must be followed by the required IOTLB and device-ATC invalidations before a later descriptor can rely on it. A GPU fence must complete before it can describe finished queue work, and presentation must happen before that work can be tied to a displayed frame. A TDI may reach RUN before any trusted DMA occurs. The table lists the joins needed for the common mixed paths.

Joined mechanisms	Fields that must refer to the same operation	Event that invalidates the join
CPU SLAT and device DMA	process or guest address, first-stage root, EPTP or N_CR3, requester RID/PASID, IOMMU domain, final page	page remap, second-stage change, device reassignment, or incomplete invalidation
PASID/SVA and ENQCMD	process mm, PASID allocation, thread IA32_PASID, portal or work queue, accepted descriptor, completion	exec, unbind, rebinding, descriptor rejection, or process exit; CPU migration only requires thread state to be loaded on the destination CPU
ATS/PRI and IOMMU mapping	requester, PASID, requested address, page response, IOTLB state, ATC entry, invalidation completion	remap or page removal before both IOMMU and device caches are current
GPUVA and process memory	process, allocation, GPUVA, residency, queue, fence, present, displayed or captured frame	eviction, remap, reset, process loss, or a frame that was never presented
GPU-PV or vGPU and host VMI	partition, GPU scheduler, memory manager, host compositor, capture path, input path	partition reset, capture-path change, or host-only overlay not present in the guest frame
CXL.mem and process memory	process VA, current PFN/HPA, CFMWS and HDM route, endpoint DPA, OS exposure mode	migration, DAX/System-RAM conversion, decoder rebuild, hot remove, or DCD reassignment
TEE-I/O and IOMMU	SPDM session, IDE stream and key generation, TDI binding, guest acceptance, trusted mapping, requester transaction, completion	reset, detach, assignment error, mapping removal, or rekey without matching later traffic
VM lifecycle and extended state	per-CPU VMCS/VMCB, VM-entry/exit state, CPUID/XCR0/XSS/XFD state, thread save area	VM abort, resume, CPU migration without state restoration, or unsupported-component fault

Workload attribution comes last. A device completion identifies finished I/O, a GPU fence identifies queue progress, and a CXL route identifies backing memory. None identifies a game object until the resulting address is resolved through the current process mapping and object lifetime. Likewise, a displayed overlay or input event needs its own timestamp before it can be compared with a game tick or server replay.

An advanced design may distribute process context to a CPU hypervisor, memory access to an IOMMU or external device, rendering to a GPU or host compositor, and backing storage to CXL memory. Trusted-I/O can further limit host plaintext. Distribution increases the number of mappings, queues, and clocks that can go stale before the result reaches the player.

Next

Part 6 moves from platform primitives to cheat architecture: where control runs, how memory becomes game objects, how visibility is reconstructed, and how the result reaches the player.

---

Credits

• Yun Wang, Liang Chen, Jie Ji, Xianting Tian, Ben Luo, Zhixiang Wei, Zhibai Huang, Kailiang Xu, Kaihuan Peng, Kaijie Guo, Ning Luo, Guangjian Wang, Shengdong Dai, Yibin Shen, Jiesheng Wu, and Zhengwei Qi for the VIO work on dynamic passthrough without requiring device-side PRI support.
• Dufy Teguia, Louis Duval, Teo Pisenti, Kahina Lazri, Daniel Hagimont, Thomas Pasquier, Renaud Lachaize, and Alain Tchana for the GOODKIT research on live VM introspection.
• Juechu Dong, Jonah Rosenblum, and Satish Narayanasamy for the Toleo work on CXL-based freshness.
• Kaustav Goswami, Sean Peisert, Venkatesh Akella, and Jason Lowe-Power for the Space-Control work on process-level isolation for shared CXL memory.
• Hansika Weerasena, Amitabh Das, and Prabhat Mishra for the formal SEV model and property-verification work.

References

• Intel, Intel 64 and IA-32 Architectures Software Developer’s Manual: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
• Intel, Advanced Performance Extensions Architecture Specification: https://www.intel.com/content/www/us/en/content-details/784266/intel-advanced-performance-extensions-intel-apx-architecture-specification.html
• Intel, Advanced Performance Extensions Software Enabling Introduction: https://cdrdv2-public.intel.com/784265/356112-intel-apx-sw-enabling.pdf
• Intel, Advanced Vector Extensions 10.2 Architecture Specification: https://www.intel.com/content/www/us/en/content-details/913918/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html
• AMD, AMD64 Architecture Programmer’s Manual, Volume 2: System Programming: https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2
• AMD, AMD64 Architecture Programmer’s Manual, Volumes 1-5, Rev. 4.09: https://docs.amd.com/v/u/en-US/40332_4.09_APM_PUB
• AMD, AMD64 Flexible Return and Event Delivery (FRED) Virtualization, Rev. 1.10: https://docs.amd.com/v/u/en-US/69191-PUB
• Hansika Weerasena, Amitabh Das, and Prabhat Mishra, “Formal Verification of Secure Encrypted Virtualization”: https://arxiv.org/abs/2606.01381
• Linux kernel documentation, Shared Virtual Addressing with ENQCMD: https://docs.kernel.org/arch/x86/sva.html
• Linux kernel documentation, IOMMUFD userspace API: https://docs.kernel.org/userspace-api/iommufd.html
• Intel, Scalable I/O Between Accelerators and Host Processors: https://www.intel.com/content/www/us/en/developer/articles/technical/scalable-io-between-accelerators-host-processors.html
• Intel, Data Streaming Accelerator - Unable to Turn On SVA: https://www.intel.com/content/www/us/en/support/articles/000097977/processors/intel-xeon-processors.html
• Yun Wang et al., “To PRI or Not To PRI, That’s the question”: https://www.usenix.org/conference/osdi25/presentation/wang-yun
• Linux kernel documentation, VFIO: https://docs.kernel.org/driver-api/vfio.html
• Linux kernel documentation, VFIO mediated devices: https://docs.kernel.org/driver-api/vfio-mediated-device.html
• Linux kernel documentation, Memory Protection Keys: https://docs.kernel.org/core-api/protection-keys.html
• Linux kernel documentation, CET Shadow Stack: https://docs.kernel.org/arch/x86/shstk.html
• Linux kernel documentation, Software Guard eXtensions: https://docs.kernel.org/arch/x86/sgx.html
• Linux kernel documentation, x86 dynamic XSTATE features: https://docs.kernel.org/arch/x86/xstate.html
• Linux kernel documentation, CPU hotplug: https://docs.kernel.org/core-api/cpu_hotplug.html
• Linux kernel documentation, KVM API: https://docs.kernel.org/virt/kvm/api.html
• Linux kernel documentation, Confidential Computing threat model: https://docs.kernel.org/security/snp-tdx-threat-model.html
• Linux kernel documentation, CXL: https://docs.kernel.org/driver-api/cxl/index.html
• Linux kernel documentation, EDAC Scrub Control: https://docs.kernel.org/edac/scrub.html
• Linux kernel documentation, EDAC Memory Repair Control: https://docs.kernel.org/edac/memory_repair.html
• Linux kernel documentation, PCI/TSM: https://docs.kernel.org/driver-api/pci/tsm.html
• Microsoft, GPU virtual memory in WDDM 2.0: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/gpu-virtual-memory-in-wddm-2-0
• Microsoft, LocateXStateFeature: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-locatexstatefeature
• Microsoft, GetThreadEnabledXStateFeatures: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getthreadenabledxstatefeatures
• Microsoft, EnableProcessOptionalXStateFeatures: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-enableprocessoptionalxstatefeatures
• Microsoft, GPU virtual address: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/gpu-virtual-address
• Microsoft, GpuMmu model: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/gpummu-model
• Microsoft, Native GPU fence objects: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/native-gpu-fence-objects
• Microsoft, User-mode work submission: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/user-mode-work-submission
• Microsoft, WDDM architecture: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-architecture
• Microsoft, Timeout Detection and Recovery: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery
• Microsoft, TDR in Windows 8 and later: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/tdr-changes-in-windows-8
• Microsoft, Desktop Duplication API: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/desktop-duplication-api
• Microsoft, Screen capture with Windows.Graphics.Capture: https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture
• Microsoft, DwmFlush: https://learn.microsoft.com/en-us/windows/win32/api/dwmapi/nf-dwmapi-dwmflush
• Microsoft, SetWindowDisplayAffinity: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowdisplayaffinity
• Microsoft, Microsoft Compute Driver Model architecture: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/mcdm-architecture
• Microsoft, Windows Hardware Error Architecture: https://learn.microsoft.com/en-us/windows-hardware/drivers/whea/
• Microsoft, Processor Groups: https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups
• Microsoft, Kernel DMA Protection: https://learn.microsoft.com/en-us/windows/security/hardware-security/kernel-dma-protection-for-thunderbolt
• Microsoft, Enable DMA remapping for device drivers: https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/enabling-dma-remapping-for-device-drivers
• PCI-SIG, IDE and TDISP overview: https://pcisig.com/blog/ide-and-tdisp-overview-pcie%C2%AE-technology-security-features
• PCI-SIG, PCI Express Base specification status: https://pcisig.com/specification-overview/pci-express-base
• PCI-SIG, PCIe 8.0 Draft 0.5 announcement: https://pcisig.com/blog/pcier-80-specification-draft-05-now-available-track-2560-gts-transfer-speeds-2028
• PCI-SIG, TEE Device Interface Security Protocol ECN: https://pcisig.com/PCI%20Express/ECN/Base/TEEDeviceInterfaceSecurityProtocol
• PCI-SIG, PCIe IDE TLP Reordering Enhancements ECN: https://pcisig.com/PCIExpress/ECN/Base/IDE_TLP_Reordering_Enhancements/Published
• PCI-SIG, PCIe IDE Standard Vulnerabilities: https://pcisig.com/PCIeIDEStandardVulnerabilities
• PCI-SIG, CMA PQC support ECN: https://pcisig.com/PCIExpress/ECN/Base/CMAPQCsupport
• PCI-SIG, IDE_KM GETKEY and AEAD Limit ECN: https://pcisig.com/idekm-getkey-and-aead-limit
• DMTF, SPDM standards page: https://www.dmtf.org/standards/spdm
• DMTF, Security Protocol and Data Model Specification 1.4.1: https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.4.1.pdf
• DMTF, SPDM 1.5 hybrid traditional/PQC feedback request: https://www.dmtf.org/content/help-us-get-spdm-15-right-feedback-requested-plan-hybrid-support-traditional-and-pqc
• DMTF, SPDM Authorization Specification 1.0.0: https://www.dmtf.org/sites/default/files/standards/documents/DSP0289_1.0.0.pdf
• Intel, TDX Connect Architecture Specification: https://cdrdv2-public.intel.com/862706/Intel%20TDX%20Connect%20EAS%20354629%20004.pdf
• Intel, TDX documentation hub: https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/documentation.html
• Intel, Intel TDX Module Base Architecture Specification: https://www.intel.com/content/www/us/en/content-details/853294/intel-trust-domain-extensions-intel-tdx-module-base-architecture-specification.html
• Intel Trust Authority, TDX attestation token claims: https://docs.trustauthority.intel.com/main/articles/articles/ita/concept-attestation-tokens.html
• Intel, Intel TDX Enabling Guide, Infrastructure Setup: https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/02/infrastructure_setup/
• Intel, TEE-I/O validator: https://github.com/intel/tee-io-validator
• AMD, Secure Encrypted Virtualization documentation hub: https://www.amd.com/en/developer/sev.html
• AMD, SEV-TIO Firmware Interface Specification 0.91: https://docs.amd.com/v/u/en-US/58271_0.91
• AMD, SEV-TIO overview paper: https://www.amd.com/content/dam/amd/en/documents/developer/sev-tio-whitepaper.pdf
• CXL Consortium, CXL specification hub: https://computeexpresslink.org/cxl-specification/
• CXL Consortium, CXL 4.0 specification release: https://computeexpresslink.org/wp-content/uploads/2025/11/CXL_4.0-Specification-Release_FINAL_Website-Copy.pdf
• CXL Consortium, CXL memory pooling and sharing: https://computeexpresslink.org/blog/explaining-cxl-memory-pooling-and-sharing-1049/
• Microchip, RAS in CXL Memory Controllers: https://ww1.microchip.com/downloads/aemDocuments/documents/DCS/ProductDocuments/SupportingCollateral/RAS-in-CXL-Memory-Controllers.pdf
• QEMU, SPDM support documentation: https://www.qemu.org/docs/master/specs/spdm.html
• QEMU, CXL documentation: https://www.qemu.org/docs/master/system/devices/cxl.html
• QEMU, system-emulation command reference for Intel and AMD IOMMU models: https://www.qemu.org/docs/master/system/qemu-manpage.html
• Microsoft, Hyper-V Top-Level Functional Specification: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs
• Microsoft, VMBus Kernel Mode Client Library API: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/vmbuskernelmodeclientlibapi/
• OASIS, Virtual I/O Device (VIRTIO) Version 1.3: https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html
• Linux kernel documentation, VDUSE: https://docs.kernel.org/userspace-api/vduse.html
• LibVMI documentation: https://libvmi.com/docs/
• DRAKVUF project documentation: https://drakvuf.com/
• Xen Project, x86-64 public hypercall ABI including event channels and grant tables: https://xenbits.xenproject.org/docs/unstable/hypercall/x86_64/index.html
• Dufy Teguia, Louis Duval, Teo Pisenti, Kahina Lazri, Daniel Hagimont, Thomas Pasquier, Renaud Lachaize, Alain Tchana, “Inside Out: A Paradigm Shift in VM Introspection”: https://www.usenix.org/conference/osdi26/presentation/teguia
• Juechu Dong, Jonah Rosenblum, Satish Narayanasamy, “Toleo: Scaling Freshness to Tera-scale Memory using CXL and PIM”: https://arxiv.org/abs/2410.12749
• Kaustav Goswami, Sean Peisert, Venkatesh Akella, Jason Lowe-Power, “Space-Control: Process-Level Isolation for Sharing CXL-based Disaggregated Memory”: https://arxiv.org/abs/2603.06951