Geoff Chappell, Software Analyst
The HV_VENDOR_AND_MAX_FUNCTION structure collects the information that a hypervisor’s cpuid leaf 0x40000000 produces in the eax, ebx, ecx and edx registers.
The HV_VENDOR_AND_MAX_FUNCTION is defined in Windows 8.1 and higher, having developed from the HvVendorAndMaxFunction member of the HV_CPUID_RESULT union.
The HV_VENDOR_AND_MAX_FUNCTION structure itself is not documented. Its members, having previously been defined in the HV_CPUID_RESULT, are documented in the Windows Driver Kit (WDK) for Windows 7, which also provided a C-language definition in the HVGDK.H header file.
The structure anyway repackages material that Microsoft documents in the Hypervisor Top-Level Functional Specification. If it or its members’ previous definitions have become undocumented, it may be just that Microsoft regards the structure as no more than a convenience for Microsoft’s own programming in the loader and kernel, if not in the hypervisor itself.
The HV_VENDOR_AND_MAX_FUNCTION is 0x10 bytes. Names and definitions below are from the C-language definition in the WDK for Windows 7 and from type information in the symbol files for URLMON.DLL in Windows 8 and higher. Well might you wonder what URLMON.DLL has to do with the hypervisor such that its symbol files have type information for this structure but the kernel’s don’t!
UCHAR VendorName ;
The kernel’s interest is with MaxFunction, which tells which cpuid leaf is the last in the series that begins at 0x40000000. Even after establishing that it is running under a Microsoft-compatible hypervisor, the kernel never queries for cpuid leaf 0x40000006 or higher without checking against what cpuid leaf 0x40000000 produces in eax as MaxFunction.
To establish that the hypervisor is one that the kernel regards as Microsoft-compatible, the kernel relies on cpuid leaf 0x40000001. Microsoft documents that Microsoft’s hypervisors have “Microsoft Hv” as the VendorName.