Hyper-V Hypercall (Privileged system call to the hypervisor)

Hyper-V Hypercall is a software interface between the Windows parent partition and the Hyper-V hypervisor. Simply put, it is the only legal way for an operating system to request the hypervisor to perform a sensitive operation that cannot be done directly due to lack of hardware access. Essentially, it is the VMCALL processor instruction wrapped in the winhvr.sys driver, turning a kernel request into a command for the virtual machine supervisor.

The technology activates with every change to a virtual machine state. The virtual infrastructure manager uses hypercalls to start and stop partitions, create checkpoints, and manage synthetic devices. Without hypercalls, dynamic memory cannot work because the guest driver reports memory pressure and the hypervisor redistributes pages via hypercall. Live migration between cluster nodes is entirely built on asynchronous hypercall chains that coordinate virtual processor switching and copying dirty RAM regions without interrupting network sessions.

Typical problems

A frequent issue is synthetic timer failure due to hypercall queue overload on a host with dense virtual machine placement. Another problem is parent partition crash after an incorrect status code is returned when updating shadow page structures in nested virtualization mode. Version incompatibility errors cause guest integration services to fail loading, blocking heartbeat packet exchange. A serious vulnerability is incomplete input parameter validation, allowing malicious code from the guest OS to compromise hypervisor integrity through performance counters.

Operating principle

The hypercall execution mechanism begins with the caller filling a predefined data structure in shared memory. The parent or child operating system kernel loads the required function code and physical addresses of I O pages into general purpose registers, usually RCX, RDX, R8, and R9, and then executes the assembly instruction VMCALL. The processor intercepts this instruction and exits from VMX non root guest mode to the hypervisor root mode, saving the context in the virtual machine control structure. The hypercall dispatcher at ring minus one analyzes the function number, checks whether the calling partition belongs to a trusted group, validates pointers, and translates guest virtual addresses to physical system addresses using EPT nested page tables.

For memory management operations, such as a request to map a GPA page, the hypervisor locks the working set, checks the caller access rights, and atomically modifies second level address translation structures, bypassing the guest memory manager. Asynchronous result forwarding avoids blocking virtual processors: if the operation is lengthy, for example relocating a block during dynamic memory defragmentation, the hypervisor immediately returns control with a pending status code, and upon completion of the background process injects a virtual interrupt into the guest APIC via a synthetic notification vector.

The final stage always includes writing a status code to the RAX register and executing the VMRESUME instruction to continue the virtual processor operation exactly at the instruction following the original VMCALL. A special fast call mode for critical high load paths, such as vSwitch network stack processing, uses direct mapping of physical pages into the parent partition address space, eliminating the overhead of double buffer copying when exchanging data between the guest and the SR-IOV physical adapter.

Hyper-V Hypercall functionality

1. The VMCALL instruction as the basis of the mechanism. On the x86-64 platform, the VMCALL instruction is used to initiate a hypercall. In the Hyper-V environment, executing VMCALL in a guest context triggers a VM exit, passing control to the hypervisor. The hypervisor dispatches the call, checks the passed parameters against the caller access rights, performs the requested operation, and initiates a VM entry to return control to the guest. This fundamental interaction completely isolates the guest from direct hardware management.
2. Encoding the hypercall number and parameters. A hypercall is identified by a 64 bit value placed in the RCX register (or EDX:EAX for 32 bit mode). The lower 16 bits of this value contain the called function code. Bits 17 through 26 define the size of a variable header in 8 byte blocks. Setting the 16th bit (mask 0x10000) signals the use of a fast calling convention, where parameters are passed not in memory but directly in processor registers.
3. Parameter passing conventions using memory (Slow Hypercall). By default, a buffer in guest physical memory is used to pass input and output data. A pointer to the page with input parameters (GPA) is placed in the RDX register, and a pointer to the page for output parameters is placed in the R8 register. Both pages must be aligned on an 8 byte boundary. This method is mandatory for calls with complex data structures whose size or number exceeds the available register limit of 112 bytes.
4. Conventions for accelerated transfer (Fast Hypercall). If the Fast bit in the hypercall code is set, up to two input parameters are passed in the RDX and R8 registers, replacing the pointers. The operation result is similarly returned via registers. This method minimizes VM exit overhead because the hypervisor does not need to translate guest virtual addresses to access parameters, which is critically important for high frequency service calls such as sending synchronization signals.
5. Extended register transfer via XMM (XMM Fast Hypercall). A subset of hypercalls that require more than two input parameters but no output data supports transfer via volatile XMM registers. In this mode, an input block of up to 112 bytes is loaded into the RDX, R8, and XMM0 XMM5 registers. This approach extends the use of fast calls to operations with more complex semantics while preserving low latency advantages compared to memory accesses.
6. Repetitive hypercalls (Rep Hypercall). For batch processing of similar operations, a repetitive hypercall mechanism is provided. The repetition count is set in bits 32-43 of the call code, and the starting index in bits 48-59. The hypervisor processes the specified range of array elements in a single transaction. A guaranteed limit of 50 microseconds is imposed on executing one batch, after which control is forcibly returned to the guest to prevent long term resource monopolization.
7. Hypercall page. For optimization and security, the hypervisor provides guest systems with a special physical page containing executable trampoline code. This page is mapped into the guest address space and allows VMCALL execution without using undocumented instructions directly. The page address is passed to the guest during initialization via processor registers or ACPI structures, ensuring compatibility when updating hypervisor versions.
8. Trampolines and fixed calls. The standard hypercall page contains several entry points (trampolines). The first performs a direct VMCALL with parameters from registers. Subsequent ones implement calls with fixed numbers (for example, 0x11 for VTL communication and 0x12 for returning to VTL1), modifying RCX before passing control. This architecture ensures that the guest cannot initiate prohibited operations because the entry point strictly determines the number of the called service.
9. Call validation and restrictions. The hypervisor strictly validates input parameters. For SetVpRegisters hypercalls, it checks that reserved bits are zero and architecturally fixed bits are set correctly. Modifying values in read only registers is prohibited and results in an error. Additionally, register write operations have no immediate side effects: the hypervisor does not trigger pipeline synchronization or TLB flush until VM entry.
10. Error handling and return values. Most hypercalls return an HV_STATUS status code. Successful execution is usually encoded as zero (HV_STATUS_SUCCESS). In case of access violation or invalid parameter passing, specific error codes such as HV_STATUS_ACCESS_DENIED or HV_STATUS_INVALID_PARAMETER are returned. The guest operating system must check this status before using hypercall output data.
11. Use for Virtual Trust Level (VTL) communication. In the Virtualization Based Security (VBS) architecture, hypercalls serve as the only legitimate gateway for inter core communication between the zero (normal) and first (secure) trust levels. A call with code 0x11 (ShvlpVtlCall) initiates a switch to the secure kernel, and 0x12 (ShvlpVtlReturn) returns the result. The hypervisor guarantees isolation, eliminating any bypass inter core transitions through shared memory.
12. Processor identification data request. The specialized hypercall HvCallGetVpCpuidValues (code 0x00F4) allows the guest to request synthesized CPUID data for a specific virtual processor. This allows the hypervisor to hide or modify the host hardware capabilities, ensuring compatibility in clusters with heterogeneous hardware. The call uses repetitive semantics to request multiple CPUID leaves in a single operation.
13. ARM64 specifics: SMCCC standard. On ARM64 platforms, calls to the Hyper-V hypervisor are made using the HVC instruction with code 0. Unlike x86-64, the hypercall number is not encoded directly in a register but follows the SMC Calling Convention (SMCCC) standard. Register X0 holds the function identifier (0x46000001), signaling a vendor specific hypercall, while the operation code and parameters are placed in X1, X2, and X3.
14. Non overlapping I O regions. The hypercall interface specification strictly forbids overlapping of physical pages used for input and output parameters. Violation of this rule leads to undefined behavior and potential data corruption. In critical code sections, such as APIC ID translation, drivers must use separate buffers or the standard output page of the current virtual processor.
15. Register context preservation. The Hyper-V calling convention specifies that general purpose registers R9, R10, R11, and the flags register may be arbitrarily changed (clobbered) by the hypervisor during call processing. Therefore, the caller must not rely on the preservation of values in these registers after returning from VMCALL, while the contents of RCX, RDX, and R8 are considered preserved according to input output specifications.
16. Synthetic timers and APIC management. The hypercall interface is not limited to purely control functions. Through Synthetic MSRs and associated hypercalls, the guest interacts with the Hyper-V emulated timer and virtual interrupt controller. This allows optimization of timer event delivery without emulating expensive hardware such as a full APIC or HPET, reducing the number of VM exits.
17. Memory management and address translation. A number of hypercalls are responsible for manipulating GPA pages and virtual TLBs. Calls like HvFlushVirtualAddressList allow the guest kernel to initiate a forced translation cache flush on one or a group of remote virtual processors. This is fundamentally necessary for maintaining memory view coherence in SMP guests without using paravirtual interfaces.

Comparisons

• Hyper-V Hypercall vs VMware Hypercall. Comparison of guest system to hypervisor communication mechanisms. Hyper-V uses the VMCALL instruction and a hypercall page with trampolines for call dispatching, where the call number and parameters are passed through RCX and RDX registers. VMware, in contrast, historically uses the VMMCALL instruction or I O ports (in/out), while modern versions use alternative patching to select the method based on processor capabilities. Architecturally, Hyper-V offers a more unified mechanism with a clear distinction between fast and standard calls.
• Hyper-V Hypercall vs Xen Hypercall. Comparison of hypervisor call approaches in x86 systems. Hyper-V reserves a bit range for its own use, setting the high bit in EAX to prevent conflicts, allowing coexistence with Xen on the same hypervisor. Xen traditionally uses the SYSCALL or SYSENTER instruction for its paravirtualized calls, providing high execution speed through direct transition without complex dispatching logic. Thus, Hyper-V emphasizes coexistence compatibility, while Xen focuses on speed and simplicity.
• Xen Hypercall (Cross-guest call to Xen hypervisor)
• Hyper-V Hypercall vs KVM Hypercall. Comparison of implementation in the context of nested virtualization. In KVM, Hyper-V hypercall support is implemented by emulating the interface for Windows guest systems, including functions such as HvCallFlushGuestPhysicalAddressSpace for TLB invalidation. KVM checks guest calls for compliance with the Hyper-V standard, filtering out invalid requests. The difference is that Hyper-V provides a native interface, while KVM acts as a compatible hypervisor adapting another ABI.
• KVM (Turns the Linux kernel into a hypervisor)
• Hyper-V Fast Hypercall vs Hyper-V Standard Hypercall. Comparison of two modes within the same Hyper-V architecture. The Fast Hypercall differs in that all parameters and return values are placed directly in registers (RCX, RDX, R8, XMM), whereas the standard call requires placing data in a guest physical page (GPA) pointed to by RDX. Fast mode significantly reduces the overhead of emulating memory accesses but imposes a limit on the amount of data transferred, forcing developers to choose between size and performance.
• Hyper-V Hypercall vs MSR Based Interface. Comparison of communication methods for debugging and data transfer. The Hyper-V synthetic debugger interface can work either through MSRs (Model Specific Registers) or through hypercalls. Using MSRs is a faster and preferred method because it avoids VMExit overhead on every poll. However, the hypercall based interface provides greater compatibility in environments where direct MSR access is restricted or unstable, offering a fallback communication path at the cost of reduced performance.
• VMExit (Hypervisor interception of VM control)

OS and driver support

Hyper-V hypercall support in guest operating systems is implemented through a paravirtualization layer, where the Linux kernel identifies the hypervisor via CPUID and uses the hv_do_hypercall interface and its derivatives to perform coordinated calls to the hypervisor. Device drivers such as netvsc or storvsc, as well as specialized components like the paravirtual IOMMU, use the hypercall mechanism to directly address the hypervisor for I O operations, memory management, and DMA translation, using a shared per vCPU memory page conforming to the TLFS specification for argument passing. In Root Partition mode, drivers and VMM management processes can execute privileged hypercalls through specialized devices such as /dev/mshv, allowing them to query partition properties and manage virtual machine states.

Security

Hypercall interface security is based on a strict calling context verification model: the hypervisor allows VMCALL execution only from kernel code with privilege level CPL0, blocking attempts to call from user space, and the hypervisor handler validates the Hypercall Input Value against allowed operation codes. To prevent exploitation of vulnerabilities such as missing ENDBR64 instruction on the hypercall page, the Linux kernel dynamically disables Indirect Branch Tracking (IBT) hardware protection when detecting an incompatible Hyper-V version, preventing critical system crashes due to indirect calls. An additional isolation layer is provided by limiting the set of available hypercalls for guest and child partitions compared to the root partition, and when using passthrough calls, for example via MSHV_ROOT_HVCALL, a strict whitelist of allowed codes is applied, excluding the possibility of executing potentially dangerous operations.

Logging

Hypercall logging is implemented through a breakpoint system embedded directly into the hypervisor handler call chain, allowing researchers to record the full trace of input and output parameters of each call. The research Hypercall Handler Logger (HHL) extends the WinDbg debugger to set software interrupts at the VMCALL handler entry and exit, capturing the Hypercall Input Value, Hypercall Result Value, and general purpose register contents used for both register based and memory based calling models. In a Linux environment, logging is done using standard kernel tracing facilities through tracepoints added to the hv_hvcall_* family wrappers, allowing real time tracking of call codes, input and output array sizes, and operation completion statuses.

Limitations

A fundamental limitation of hypercalls is the data size limit: the TLFS specification and the Linux kernel implementation require that the total size of input and output arguments not exceed one physical page (4 KiB) and be aligned on an 8 byte boundary, which imposes constraints on batch processing and requires batch size calculation on the caller side. Hypercall execution performance is significantly limited by VM Exit/VM Entry context switching overhead, and breakpoint logging slows execution by a factor of 100,000 to 200,000, making this method unsuitable for production environments. Additional architectural limitations include dependence on MSI hardware range encoding and hardcoded parameters such as the standard x86 interrupt range (0xfee00000 - 0xfeefffff), which cannot always be dynamically queried via hypercall.

History and development

The evolution of the Hyper-V hypercall began with the classic paravirtualization model, where synthetic interfaces and hypercalls were used to accelerate guest systems instead of full hardware emulation, similar to the DIAGNOSE concept in IBM VM/CMS, and early versions used Windows Vista extensions for hypervisor integration. The modern stage of development is characterized by the introduction of architecture independent paravirtual IOMMU drivers, which have completely moved device enumeration and IOTLB invalidation to the hypercall interface, abandoning emulated ACPI tables. The latest patch versions for Linux (2024-2025) show a trend toward unifying argument management through the hv_hvcall_* family of functions, support for emulating Virtual Secure Mode (VSM) with hypercall forwarding to KVM user space, and gradual adoption of hardware security features such as IBT and nested translation for DMA.