Geoff Chappell - Software Analyst
The HV_HYPERVISOR_INTERFACE enumeration (formally _HV_HYPERVISOR_INTERFACE) has Microsoft’s names for values that Microsoft recognises for the “Hypervisor vendor-neutral interface identification” that cpuid leaf 0x40000001 produces in the eax register. In Microsoft’s packaging of its hypervisor’s cpuid output, the HV_HYPERVISOR_INTERFACE is the type of the Interface member of the HV_HYPERVISOR_INTERFACE_INFO structure.
The HV_HYPERVISOR_INTERFACE is defined in version 6.0 and higher.
The HV_HYPERVISOR_INTERFACE enumeration is documented in the Windows Driver Kit (WDK) for Windows 7, which was the last to have documentation included. This kit also provides a C-language definition in the HVGDK.H header file. Except that documentation continued to a separately downloadable package for merging into Visual Studio 2012, later kits have neither the documentation nor the header.
The enumeration anyway repackages material that Microsoft documents in the Hypervisor Top-Level Functional Specification (TLFS). If the HV_HYPERVISOR_INTERFACE or its members have become undocumented, it may be just that Microsoft regards their definitions as no more than a convenience for Microsoft’s own programming in the loader and kernel, if not in the hypervisor itself.
Microsoft’s names for the HV_HYPERVISOR_INTERFACE enumeration are known from: the C-language definition in the WDK for Windows 7; from type information in symbol files for the kernel in Windows 8.1 (only); and type information in most versions of CLFSMGMT.LIB for Windows Vista through to the 1903 release of Windows 10. I know of no public source beyond Version 1903.
| Value | Name | Versions |
|---|---|---|
| 0x31237648 ('1#vH') | HvMicrosoftHypervisorInterface | 6.0 and higher |
| 0x766E6258 ('vnbX') | HvMicrosoftXboxNanovisor | 1511 and higher |
The value HvMicrosoftHypervisorInterface is necessary since Windows Vista—and as its only use before Windows 8—if the kernel is to prepare at all for being executed under a hypervisor. Without knowing that the hypervisor has this particular Microsoft interface, the kernel doesn’t proceed even as far as writing its operating system identifier to the Model-Specific Register (MSR) 0x40000000.
In Windows 8, getting HvMicrosoftHypervisorInterface in eax from cpuid leaf 0x40000001 also starts to become what the kernel checks for assurance that cpuid leaves continue to 0x40000002 and beyond. For some purposes, and always in earlier versions, the check is that the 0x80000000 bit in ecx from cpuid leaf 1 means that cpuid leaf 0x40000000 exists and the check for any higher hypervisor leaf is that it’s within the bound provided by eax from leaf 0x40000000. Starting with Windows 8.1, the bounds check is regarded as unnecessary for cpuid leaf 0x40000001 and only if this reveals the HvMicrosoftHypervisorInterface does the kernel trust that hypervisor leaves reach as far as 0x40000005. This appears to be the limit to what’s guaranteed just by the interface. Higher leaves are first meaningful to the kernel for Windows 10 and always require a bounds check.
The first that the kernel is known to recognise any other hypervisor interface than HvMicrosoftHypervisorInterface is the 1607 release of Windows 10, but Microsoft looks to have planned this a little earlier: that Microsoft’s name for this other interface is HvMicrosoftXboxNanovisor is known from type information in CLFSMGMT.LIB from the Software Development Kit as included in the Enterprise WDK for Version 1511.
For most purposes, the Xbox Nanovisor is treated as if it is not a hypervisor. This shows most notably in the adaptation of the admittedly undocumented kernel export HviIsAnyHypervisorPresent, which now answers yes only if the hypervisor that’s present is not the Xbox Nanovisor.