The HV_HYPERVISOR_SVM_FEATURES structure (formally _HV_HYPERVISOR_SVM_FEATURES ) collects the flags that a Microsoft-compatible hypervisor’s cpuid leaf 0x40000008 produces in the eax, ebx, ecx and edx registers. SVM stands for Shared Virtual Memory.


The HV_HYPERVISOR_SVM_FEATURES is new for Windows 10.


The kernel is not known to expose this structure or any reading of cpuid leaf 0x40000008 through any interface, documented or not, even in kernel mode.

The kernel’s own known use for cpuid leaf 0x40000008—and only then the 64-bit kernel—is for its answer when called through the SvmGetSystemCapabilities member of a HAL_ENLIGHTENMENT_INFORMATION structure such as gets filled by calling through the HalGetEnlightenmentInformation member of the kernel’s HAL_PRIVATE_DISPATCH which is exported as HalPrivateDispatchTable. The kernel doesn’t read cpuid leaf 0x40000008 unless the SvmFeaturesAvailable flag is set in the HV_X64_HYPERVISOR_FEATURES obtained by reading cpuid leaf 0x40000003.

Documentation Status

The HV_HYPERVISOR_SVM_FEATURES structure is not documented. The hypervisor’s cpuid implementation is documented in the Hypervisor Top-Level Functional Specification (TLFS). What’s offered today, 12th November 2016, as the specification’s most recent version is a PDF that is three years old (version 4.0b, dated August 2013). it extends only to leaf 0x40000006. Revelation of cpuid leaf 0x40000008 apparently had to wait for version 5.0a, dated February 2017. Better late than never, perhaps, but the reality behind the superficially fine words of the Microsoft Open Specification Promise is that the Hyper-V implementation, and presumably Microsoft’s use of it to Microsoft’s advantage for Microsoft’s purposes, runs ahead of the documentation that Microsoft opens for general use.

As for the HV_HYPERVISOR_SVM_FEATURES as Microsoft’s particular expression of the output from cpuid leaf 0x40000008, disclosure by Microsoft is conspicuously thin. The practical equivalent of a C-language definition is published as type information in symbol files, but in the downloadable packages of public symbols for 32-bit and 64-bit Windows 10, type information for HV_HYPERVISOR_SVM_FEATURES appears only in the symbol files for URLMON.DLL. This is a user-mode DLL that originated as a component of Internet Explorer (and still follows Internet Explorer’s version numbering). Well might you wonder what this DLL has to do with the hypervisor such that its symbol files have type information for this structure but the kernel’s don’t! Symbol files for URLMON.DLL starting with Windows 8, both in packages of Windows symbols and when downloaded from Microsoft’s public symbol server, happen to be private symbols. This surely was an oversight, but however this disclosure came about, Microsoft stopped it for Version 1803. That URLMON.DLL knows of the HV_HYPERVISOR_SVM_FEATURES is because some URLMON.DLL source code has a #include for a header named hvgdk_mini.h. Microsoft is known to use his header for its own programming of the Windows kernel but is not known to have ever made it available for use by programmers in general (let alone by the programmers of competing web browsers).

Type information for the HV_HYPERVISOR_SVM_FEATURES turns out to have been also disclosed in the relatively plain sight of two statically linked libraries. I say relatively plain because even experts tend to overlook that libraries can hold type information. Beware anyway that type information in statically linked libraries does not always match the operating system that the library is supposedly intended for. One of the libraries, named CLFSMGMT.LIB, is among the many that are supplied with the Software Development Kit (SDK) for user-mode programming. Type information for the HV_HYPERVISOR_SVM_FEATURES drops out of this library in Version 2004. The other is more obviously related to hypervisors. It is named KDHV.LIB. Microsoft distributes it among the programming samples in the Debugging Tools for Windows. It has type information for the HV_HYPERVISOR_SVM_FEATURES for all versions of Windows 10 at least to the 2004 release.


The HV_HYPERVISOR_SVM_FEATURES is 0x10 bytes in both 32-bit and 64-bit Windows. Offsets and definitions below are from type information in symbol files for URLMON.DLL before Version 1803 and then in KDHV.LIB.

Offset Definition Versions
/*  bit fields, see below  */
10.0 and higher
UINT32 MaxPasidSpaceCount;
10.0 and higher
UINT32 MaxDevicePrqSize;
10.0 and higher
UINT32 Reserved1;
10.0 and higher

All TLFS versions 5.0a, 5.0c and 6.0b, dated variously from 2017 to 2020, have MaxPasidSpaceCount and MaxDevicePrqSize as Reserved. Not only are both defined for the original Windows 10 in 2015, according to symbol files, but they have been meaningful to the kernel in all versions since.

Offset 0x00 (EAX)

Mask Definition Versions
UINT32 SvmSupported : 1;
10.0 and higher
UINT32 Reserved0 : 10;
10.0 and higher
UINT32 MaxPasidSpacePasidCount : 21;
10.0 and higher