Geoff Chappell - Software Analyst
Windows 10 added to the Windows Kernel Exports a new set of functions whose names have the Hvi prefix. Whether this stands for Hypervisor Interface or Hypervisor Implementation or for something else entirely is unknown from the binary or symbol files or anything else that has yet occurred to me as a likely source of evidence.
These newly exported but undocumented functions are:
Each obtains the results of executing the cpuid instruction. For all but one of the functions with “Get” in their name, each of the functions produces the 16 bytes of output from one cpuid leaf in the hypervisor series that starts at 0x40000000. The other functions, especially those that ask an “Is” question, interpret such output.
Beware of something that always must be borne in mind with using cpuid but which is overlooked by almost everyone who writes about it. Almost all of these functions are compounds in the sense that they get their result by executing cpuid not just once but twice or even thrice. For instance: they first check ecx from cpuid leaf 1 for assurance that some hypervisor is present; they then check cpuid leaf 0x40000001 for whether the hypervisor is Microsoft-compatible and thus has cpuid leaves 0x40000002 to 0x40000005; and only then do they proceed to whichever of these cpuid leaves is wanted for the function’s output. The functions themselves do nothing to arrange that all their executions of cpuid are on the same processor. Call these functions in arbitrary circumstances and you do not know which processor(s) the output was obtained from.
The public symbol file NTKRPAMP.PDB for the original release of Windows 10 shows that these functions have a common source. All got into the kernel from a statically linked library named hvikm.lib at
d:\th.obj.x86fre\minkernel\hvilib\kern\objfre\i386
and into there from an object file named hviintel.obj at
d:\th.obj.x86fre\minkernel\hvilib\kern\objfre\i386
The paths are similar for other releases of WIndows 10. Symbol files for binaries other than the kernel show that there is also an output tree for object files under “user” (as an alternative to “kern”) to build a library named hvium.lib. Either way, the strong suggestion is of compiling a source file named hviintel.c, though perhaps with some other extension, at
d:\th\minkernel\hvilib
Presumably, the hvilib directory has, or is at least anticipated as providing for, other source files that implement the same functions for other processor architectures. These other processors need not have any instruction that corresponds directly to cpuid. The functions present an abstraction of the hypervisor’s implementation of the virtual machine’s processors. More on this point would be found from the binaries and symbol files for, say, a 32-bit or 64bit ARM build of Windows 10: looking into them would likely be informative but is beyond the scope not just of this page but of the whole website.
The hviintel source file and presumably any others that the hvilib directory has for other processors are not particular to the kernel. Indeed, the same “kern” object file that is linked into the kernel through the hvikm library is also linked into a wide range of Microsoft binaries from the EFI boot manager to KERNELBASE.DLL in user mode. Its interest to programmers outside Microsoft is that its functions are exported and are thus available to anyone’s kernel-mode drivers through dynamic linking.
None of the Hvi functions are documented. Moreover, Microsoft seems to have thought better of having ever exported them. Though they are not discontinued as exports, what was exported for the original Windows 10 looks to be all that ever will be. Functions that are known to be have been added—HviIsXboxNanovisorPresent and HviGetIptFeatures, for the 1607 and 1903 releases, respectively—are not exported. Indeed, the first of them exists in most versions only as an inline routine.
Most of the exported functions originated in Windows 8.1 as inline routines. The public symbol files for the Windows 8.1 kernel tell of this explicitly for a few and tell also of some deeper inlining. There is also the strong suggestion that some routines were defined inline for Windows 8.1 but don’t themselves show in the symbol files because they never contributed to the code.