Inside hvix64: the guest execution engine

Guest execution in hvix64.exe spans several objects: the partition, a scheduled virtual processor, its active virtual trust level, and the logical processor executing it. The scheduler connects those objects to a selected virtual-machine control structure (VMCS), while assembly entry and exit paths transfer the processor state that VMX leaves to software.

This analysis reconstructs that execution path in build 10.0.26100.9444. It follows VMCS ownership and launch state, host and guest segment state, native and enlightened field access, interrupt dispatch, and the transition between VTL contexts. This is the second part of a series; the first part covers the partition object’s lifetime and access checks beneath this execution model.

Three implementation details connect these paths. VMCS selection includes explicit processor ownership tracking. Interrupts delivered through the host IDT and external-interrupt VM exits can feed the same per-processor queue. VTL isolation combines a selectable execution context within each VP with separately managed memory protections.

Target binary and methodology

The target is hvix64.exe version 10.0.26100.9444, an Intel x64 Hyper-⁠V image of 2,057,688 bytes, with preferred image base 0xFFFFF80000000000. The analysis uses IDA 9.4 and Hex-Rays.

cf5af317f300b7da25f37d5dc6ca75bff91b6b868d89f337d23ec1773340ce8a

All code addresses below are RVAs. Structure offsets are relative to the named base object and apply to this build. Recovered names such as HvpScheduleVp_ContextSwitch and _HV_PCR are analyst annotations; the associated behavior is established from instructions, field accesses and callers.

Assembly listings are shortened transcriptions. C listings are reduced reconstructions with descriptive local names, with omissions identified in the surrounding text. The findings are based on static analysis. Runtime backend selection, configuration-dependent allocation counts and completion of cross-processor operations remain outside the verified scope.

Partition, VP, VTL and logical processor

Four identities determine the execution context:

VMX operates on logical processors, including separate hardware threads on a physical core. VMX root operation is the hypervisor’s execution environment. The Windows root partition’s kernel executes as a guest under that hypervisor and has its own processor state.

Example placement of a context on an LP. The diagram does not specify allocation counts or permanent processor affinity.

The inspected hypervisor paths access the current execution context through GS: gs:[0] supplies the per-processor record, gs:[0x358] the current VP, and gs:[0x360] the current partition. The partition-ID query handler described in the partition analysis uses the same current-partition pointer.

The VP links this processor-local state to the active VTL context and its VMCS software record:

These offsets describe software records surrounding the opaque hardware VMCS region. In particular, record offset 0x188 stores the backing address used for VMCS selection; architectural VMCS-field encodings belong to a separate interface.

VMCS selection and processor ownership

HvpScheduleVp_ContextSwitch, at 0x216F00, updates the processor’s current VP and partition and selects the associated VMCS state. Its selection condition checks both whether the VP changed and whether the selected VMCS record’s owner identifier matches the processor identifier at PCR + 0x8.

The relevant portion reduces to:

trust = *(void **)((unsigned char *)vp + 0x3C0);
state = *(void **)((unsigned char *)trust + 0x13E8);

if (vp != currentVp || state->Owner != processor->Identifier) {
    processor->CurrentVp = vp;                  // PCR + 0x358
    processor->CurrentPartition = vp->Owner;    // PCR + 0x360
    SelectVmcs(trust);
    ReconcileProcessorState(vp, trust);
}

SelectVmcs and ReconcileProcessorState are descriptive names for portions of this function. The full path also handles MSRs, debug state, accounting and configuration-dependent state.

On the native VMX branch, selection reaches VMPTRLD using the address at the selected software record’s 0x188. A related helper at 0x216E98 writes the current processor identifier into state + 0x120. Together, these accesses establish explicit processor ownership tracking and a selection path that accounts for the record’s current owner.

The ordinary VMCS initialization path at 0x351898 zeroes a 4 KiB backing region, initializes its revision identifier from VMX capability data on the native branch, and sets up host and guest controls. It also supports the enlightened interface described below. Other helpers select an embedded default record or an additional descriptor. The inspected paths establish the relationship between these records, but leave the complete allocation count dependent on configuration and additional allocation paths.

Intel requires an active VMCS to belong to only one LP at a time. Moving it to another LP requires clearing it on the previous processor before loading it on the destination. This architectural constraint provides the context for hvix64’s owner identifier and reselection logic. See the SDM, Volume 3C, §27.11.1 (order number 326019-093, September 2026).

Per-processor VMXON state

HvVmxOn, at 0x340A60, enters VMX operation using a pointer held in the processor record. After feature-control setup and setting CR4.VMXE, it executes:

mov     r10, gs:0
; Feature-control setup omitted.
mov     rax, cr4
bts     rax, 0Dh
mov     cr4, rax
vmxon   qword ptr [r10+29F58h]

The VMXON region belongs to the logical processor’s VMX setup. The VMCS backing address is selected separately through the VP’s execution context, giving the two allocations distinct roles in the entry path.

Launch state belongs to the selected VMCS

The entry loop uses a byte at VMCS software record + 0x127 to choose between launch and resume. A helper at 0x21F1F0 resets it to zero and, when backing VMCS storage is present, executes VMCLEAR on the address at +0x188.

The byte therefore tracks launch state for the selected VMCS. Clearing the VMCS and resetting the byte prepares that record for a subsequent VMLAUNCH.

The entry and exit loop

The central assembly loop is labeled HvpVmxRunGuestLoop, at 0x3A8000. It spans guest entry and a VM-exit landing point selected through the VMCS host RIP. That hardware transition connects blocks that a conventional call/return graph does not capture.

The loop calls the housekeeping helper at 0x35D330 and HvpVmxPrepareVmEntry at 0x35C180. It restores guest register state from a software transfer area, then reaches the launch-state decision:

xor     eax, eax
mov     edx, 1
cmpxchg [r9+127h], dl
; Guest-register loads follow, without changing the decision's flags.
; r9 here initially identifies the selected VMCS software record.
jz      first_entry

vmresume
jmp     entry_failed
first_entry:
vmlaunch
jmp     entry_failed

The VMPTRLD instruction chooses the current VMCS; VMLAUNCH and VMRESUME enter the guest described by it. A normal VM exit does not return to the instruction following VMLAUNCH. It loads the host state programmed into the VMCS.

For the main path, the host RIP is 0x3A843D, inside this same loop. There the assembly saves guest GPRs and XMM transfer state, obtains the exit reason, and handles the external-interrupt case before calling the main C-level exit handler:

0x35C180  Prepare entry state
0x3A8308  VMRESUME
0x3A8310  VMLAUNCH
    ... guest execution ...
0x3A843D  Host RIP used by the main VM-exit path
    ... save guest transfer state; read exit reason ...
0x3A78F0  External-interrupt triage, when basic reason == 1
0x3A857D  Call HvVmExitHandler
0x3A8582  Jump back to the entry loop

The assembly loop performs external-interrupt triage before HvVmExitHandler receives control. The exit handler consequently represents only the inner portion of the exit path; the outer assembly code owns the transfer of register state and the first dispatch decision.

Guest GPRs and XMM transfer state are loaded and saved explicitly by the loop. It also clears portions of the transfer storage and scratch registers along the path. Separate helpers handle additional processor state, with the exact sequence depending on the entry backend and enabled features. The complete context transition therefore combines hardware VMCS state with software register management.

HvVmExitHandler, at 0x35E230, and HvpDispatchVmExitByReason, at 0x35D460, connect exit reasons to emulation, hypercall handling, event processing and other workers. The dispatcher’s exception/NMI case reads interruption information and examines the event type before choosing its path. Entry preparation reconciles the resulting state before execution resumes.

Segment registers and the host context

Segment-state management covers the hypervisor’s execution environment and the guest state loaded on VM entry. The two use separate descriptor tables, selectors and base values.

The hypervisor establishes its own tables and GS base

At the image’s startup entry, 0x3A6610, the assembly loads a GDT and IDT, loads data-segment selectors, loads the task register, and programs IA32_GS_BASE:

lgdt    fword ptr [image_base+232C6h]
lidt    fword ptr [image_base+232B6h]
mov     eax, 20h
mov     fs, ax
mov     gs, ax
mov     ds, ax
mov     es, ax
mov     ss, ax
mov     eax, 30h
ltr     ax
; WRMSR IA32_GS_BASE (C0000101h) points at the initial processor record.

The image_base notation identifies image-relative descriptor locations in this shortened listing.

For later VM exits, the helper at 0x3527C8 programs the corresponding VMCS host-state fields. A checking routine at 0x35EE44 compares them with the expected live state. These routines establish the following host-context values:

These selectors describe hvix64’s own descriptor tables. On the native branch, the GS-base field is 0x6C08, the IDTR-base field is 0x6C0E, and host RSP is 0x6C14.

That GS base explains why a VM exit can immediately use gs:[0x358] and gs:[0x360] even if the guest had been using GS for entirely different data. The host’s base is part of the transition state. The selector value alone does not describe the 64-bit GS base.

Guest segment descriptors

The guest-side wrappers separately access descriptor state. For example, the inspected CS setters are:

The getter at 0x34EA00 reads the same CS-base field. On the native branch it executes VMREAD; on the enlightened branch it reads the corresponding memory slot. These matching accesses establish that the descriptor’s hidden state is represented separately from its visible selector.

The hypervisor programs the selected guest context’s segment state through its VMCS representation. VM entry loads that state; VM exit restores the host environment described in the earlier table. The visible selector and the descriptor’s base, limit and access rights are distinct components of the transition.

The VP/VTL switch path also explicitly saves and restores IA32_KERNEL_GS_BASE (0xC0000102). This MSR supplies the guest’s kernel-GS swap partner and is managed separately from the host GS base loaded on VM exit.

Native and enlightened VMCS access

The field-access wrappers support two backends: architectural VMCS instructions and a memory interface reached through gs:[0x2C740]. The memory layout and write-side synchronization identify the latter as an enlightened VMCS page.

HvpVmreadExitQualification, at 0x332194, checks bit zero of the global dword at 0xAF150. When clear, it executes a hardware VMREAD of field 0x6400. When set, it reads a qword at offset 0x2D0 of the memory object referenced through GS.

if (EnlightenedVmcsEnabled) {
    *value = *(UINT64 *)((unsigned char *)enlightenedVmcs + 0x2D0);
} else {
    *value = ReadHardwareVmcs(0x6400);
}

The offsets match Microsoft’s published HV_VMX_ENLIGHTENED_VMCS:

The enlightened VMCS is a documented memory interface for nested virtualization. An L1 hypervisor updates the page with ordinary loads and stores, while L0 consumes it for nested execution. Microsoft’s nested-virtualization documentation defines this interface and its clean-field contract. Its offsets describe a public structure, whereas the hardware VMCS region remains opaque. The enlightened branches in the accessors below are taken when hvix64 itself is that L1 hypervisor, running nested under another Hyper-⁠V.

Clean bits describe modified groups

The write-side accessors maintain clean-field groups. The guest-interruptibility setter at 0x32F410 performs the following sequence on its enlightened branch:

mov     rdx, gs:2C740h
mov     eax, [rcx]
btr     dword ptr [rdx+338h], 0Ah
mov     [rdx+310h], eax

Offset 0x338 holds clean-field groups. Bit 10 is the guest-basic group (GUEST_BASIC); clearing it tells the consuming hypervisor that this group changed. The native branch instead writes VMCS field 0x4824.

There are matching examples elsewhere. The host-RSP setter at 0x3407E0 clears clean bit 13 (HOST_POINTER) and writes page offset 0x268, or uses native field 0x6C14. The entry-interruption setter at 0x3323D8 clears bit 5 (CONTROL_EVENT) and writes 0x320, or uses native field 0x4016. The CS setters above clear bit 12 (GUEST_GRP2) before updating their descriptor slots.

A clean bit communicates whether the consuming hypervisor can reuse a field group’s previous values. The producer clears the bit when updating that group. The native exit-qualification wrapper follows a different access pattern: each invocation of its native branch issues VMREAD, with no per-field read-validity check in the inspected wrapper.

Saved exit state and emulated state

Separate paths retain exit information and reconcile emulated register state. The external-interrupt triage routine can obtain interruption information from a saved record at context + 0x48 on an alternate entry path. The RFLAGS helper at 0x229424 reads current RFLAGS through the backend accessor, then conditionally merges selected bits with a software-held value at VTL execution-control record offset 0x118.

These paths serve separate purposes: saved records retain exit information, the RFLAGS helper reconciles emulated state, and the enlightened page exchanges VMCS fields with another hypervisor. Their storage and validity rules must be analyzed independently.

The outer loop constructs its entry record at VP + 0xEC0. Its backend-selection byte at entry record + 0xB1 consequently resides at VP + 0xF71. This field belongs to the embedded entry record; the recovered VP type separately names a field CacheValidFlags at VP + 0xB1. Tracking the base pointer through the loop resolves the apparent overlap and identifies the alternate sources of saved exit information.

The enlightened branches are therefore the L1 side of the interface: hvix64 writes the page and an outer Hyper-⁠V consumes it. When hvix64 is the L0 hypervisor hosting a nested one, it reads that hypervisor’s page instead, which is a different role from the one these accessors implement. VTL switching is an independent relationship within a partition, examined below.

Host IDT and interrupt handlers

hvix64 installs a host IDT and contains executable interrupt and exception handlers. Three parts of the initialization and execution paths establish how that environment is selected:

1. Startup at 0x3A6610 executes LIDT with the descriptor at image RVA 0x232B6.
2. Processor setup places an IDT pointer in PCR + 0x440; 0x3527C8 programs it into HOST_IDTR_BASE for subsequent exits.
3. The image contains vector stubs that save state, dispatch or queue work, and return with IRETQ.

The on-disk descriptor specifies a 0xFFF limit and a table at image RVA 0x22000. The stored records contain handler targets and gate metadata. Reconstructing the final live gate layout requires tracing any loader-time transformation, which is outside this analysis. The initialization instructions, host-state fields and handler bodies establish the host interrupt environment independently of that reconstruction.

For a concrete example, the vector-0x20 stub at 0x3B0040 queues the vector through GS and returns:

push    rax
movzx   eax, byte ptr gs:340h
mov     dword ptr gs:308h[rax*4], 20h
inc     eax
mov     gs:340h, eax
; Restore the saved register and remove temporary stack storage.
iretq

The image also contains exception stubs for page fault at 0x3A89C0 and machine check at 0x3A8D80. The 0xFF path at 0x3AF940 returns with IRETQ. Handler complexity varies by vector, from short return paths to exception processing.

External-interrupt VM exits

With the relevant controls enabled, an external interrupt occurring during guest execution can cause a VM exit. The outer loop sees basic reason 1 and invokes HvpTriageExternalInterruptExit, at 0x3A78F0, before the main exit handler.

The routine reads interruption information from the selected backend. The enlightened interface supplies it at 0x2B8; the adjacent slot at 0x2B4 holds the exit reason.

The inspected vector split is:

The 0xDF case refers to an external-interrupt vector; the architectural double-fault exception is vector 8. The queue offsets match those used by the vector-0x20 host stub. Host-IDT delivery and external-interrupt VM exits can therefore converge on the same processor-local storage. The complete queue-drain and device-ownership policies remain outside this trace.

The event’s arrival path determines the initial dispatch mechanism. An external-interrupt VM exit reaches the programmed host RIP and triage routine, while an event delivered through the host IDT reaches a vector stub. The shared queue connects these paths to deferred interrupt processing.

Pending events and guest injection

A queued physical vector does not automatically become a guest interrupt with the same number. Guest delivery involves the selected VP/VTL’s virtual interrupt state and the VM-entry interface.

The dispatcher at 0x35D460 classifies exception/NMI exits using the interruption-info type bits. Type 2 selects the NMI path. In one NMI-window handling branch, it clears execution-control bit 0x400000 (bit 22, NMI-window exiting) before requesting pending-event reevaluation; another configuration can reflect the exit through a different path.

The helper labeled HvpEvaluatePendingInterrupts, at 0x2C93AC, reaches 0x2EF3B0, which updates pending-work flags in the current VTL context. This schedules reevaluation of event delivery; injection is handled through the subsequent entry path.

The virtual-APIC side also starts with the active trust context. HvpEvaluatePendingApicInterrupt, at 0x2FC19C, obtains it through VP + 0x3C0 and invokes a worker using the interrupt-state block at VTL context + 0x80. Its branches inspect pending-event state and update delivery flags or guest interrupt-control state. The active VTL context thus participates directly in the guest interrupt-delivery decision, with configuration-dependent paths through the worker.

The final architectural delivery interface is explicit. HvVmxWriteEntryInterruptionInfo, at 0x3323D8, writes VM-entry field 0x4016, or the equivalent enlightened-page slot. It is called by entry preparation and exit-handling paths. Error-code and instruction-length state have separate accessors.

The NMI path also contains a helper at 0x3A5840 that builds a return frame and ends with IRETQ. Its frame construction and architectural return semantics form part of the hypervisor’s event handling. A complete account of pending-event selection, APIC priority and nested intercepts requires tracing the callers and configuration-specific branches beyond these shared primitives.

VTL switching selects another context within the VP

Microsoft’s VSM description defines VTLs as hierarchical protection contexts with private VP state and memory protections within a partition. The active VTL selects a trust context inside the existing VP and partition.

The corresponding data flow is visible in the binary. HvCallVtlCall, at 0x2931A0, reads the current VTL through VP + 0x3C0, then context offset 0x14, and selects the next higher enabled target. Its candidate bitmap comes from VP + 0x1B0. This agrees with the documented VTL-call operation.

The enabled-target bitmap is specifically at VP + 0x1B0. The recovered type also names a VtlBitmask field at VP + 0x3E0, used by other state-management code. The call path’s field accesses distinguish these two values.

The switching helper at 0x2AFBC4 compares the requested level with the current one. If they differ, it invokes a save helper at 0x2AFFB0 and a restore helper at 0x2AFD8C. The central part of the restore path is:

target = *(void **)((unsigned char *)vp + 0x148 + 8 * targetVtl);
*(void **)((unsigned char *)vp + 0x3C0) = target;
*((unsigned char *)vp + 0x404) = targetVtl;

vmxContext = (unsigned char *)target + 0x13C0;
SelectControlContext(processor, vmxContext);  // helper at 0x21C8E0

That last helper selects the target’s VMCS backing state on the native path. The VP and its owning partition remain the same identities while the active trust context changes.

The save helper reads IA32_KERNEL_GS_BASE into old VTL context + 0x1420. The selection helper restores that MSR from new execution record + 0x60, the same offset viewed from new VTL context + 0x13C0. It also reconciles STAR, LSTAR and FMASK on an enabled branch.

The matching MSR offsets link the save and restore operations to the VTL execution-control record. A VTL transition consequently updates the active-context pointer, selects the target’s VMCS backing state, and restores processor state held outside the basic segment fields.

HvCallVtlReturn, at 0x293230, performs its own checks and lower-context selection, corresponding to the documented return operation. Its validation path governs the reverse transition before the lower context is selected.

The public model allows an architectural VTL namespace larger than the common VTL0/VTL1 configuration. This binary also contains additional numeric cases in its validation paths. Establishing which of those cases are usable requires tracing the complete configuration and enablement paths.

Memory isolation connects VTLs to SLAT

The processor-state switch is only part of VTL isolation. Guest page tables translate guest virtual addresses into guest physical addresses; the hypervisor’s second-level translation and permission machinery controls what those guest physical accesses may reach. Changing a guest CR3 cannot by itself grant the lower VTL permission to a protected backing page.

HvCallModifyVtlProtectionMask, at 0x28EF80, connects the VTL model to the mapping implementation. The public interface operates on a list of guest physical pages. The inspected implementation validates reserved input fields, resolves the target partition, checks the target VTL and caller relationship, and then reaches the mapping workers.

The traced path is:

HvCallModifyVtlProtectionMask  0x28EF80
    validation / access checks
    0x2DA778
        0x36EB78             GPA iteration with SLAT locking
            0x37276C         Read mapping; derive changed permissions
                0x3837C4     Compare old and proposed mapping
                0x386A24     HvpSlatCommitGpaMapping, if changed

At 0x37276C, the worker reads the current mapping, copies its representation, changes permission data indexed by the target VTL, and compares the proposed mapping with the original before committing. The path uses HvpSlatAcquireGpaLock and HvpSlatReleaseGpaLock around the relevant mapping operations.

Afterward, 0x2DA778 can call a coordination helper at 0x2DBAC0 with a mask derived from (1 << targetVtl) - 1, selecting lower-level contexts. The update path therefore includes both a mapping change and a separate operation coordinating the affected execution contexts.

The complete remote-processor invalidation and completion protocol behind that coordination remains unverified. The traced mapping write establishes where permissions change; determining when every affected processor stops using an old translation requires following the coordination protocol through to its acknowledgements.

Execution flow and remaining research questions

The recovered paths connect the execution model as follows:

1. A scheduled VP identifies its partition and active VTL context.
2. The context identifies selected VMCS backing state; processor ownership and current pointers are reconciled.
3. Host segment, table and stack state describe where an exit will land. Guest state is represented through the native or enlightened interface, with additional software-managed registers alongside it.
4. Entry preparation resolves pending work, then the assembly loop launches or resumes the guest.
5. A VM exit lands in the hypervisor’s programmed host context. The outer loop saves transfer state, triages external interrupts where applicable, and calls the inner exit handler.
6. The exit can lead to emulation, pending-event work, a VTL switch, a mapping change, or another entry. An event delivered through the host IDT is a distinct arrival path.

For analysis across builds, VMXON, VMPTRLD, VMCLEAR, the launch/resume branch, the host-RIP write and the GS-relative accesses provide instruction-level anchors. Native VMCS encodings and the documented enlightened-page layout provide independent checks on the recovered field accessors.

Further runtime analysis is needed to establish backend selection, configuration-specific VMCS allocation, ownership transfer between LPs, interrupt-queue draining and cross-processor acknowledgement of protection updates. Those questions concern the transitions between the structures recovered here: the per-processor record, the VP, its selected VTL context, and the VMCS backing state.