Feature and Interface Discovery

This section describes how guest software detects the presence of a hypervisor and queries its capabilities, features, and version information using architecture-specific discovery mechanisms.

Feature and Interface Discovery (x64)

Guest software interacts with the hypervisor through a variety of mechanisms. Many of these mirror the traditional mechanisms used by software to interact with the underlying processor. As such, these mechanisms are architecture-specific. On the x64 architecture, the following mechanisms are used:

• CPUID instruction – Used for static feature and version information.
• MSRs (model-specific registers) – Used for status and control values.
• Memory-mapped registers – Used for status and control values.
• Processor interrupts – Used for asynchronous events, notifications and messages.

In addition to these architecture-specific interfaces, the hypervisor provides a simple procedural interface implemented with hypercalls.

Hypervisor Discovery

Before using any hypervisor interfaces, software should first determine whether it’s running within a virtualized environment. On x64 platforms that conform to this specification, this is done by executing the CPUID instruction with an input (EAX) value of 1. Upon execution, code should check bit 31 of register ECX (the “hypervisor present bit”). If this bit is set, a hypervisor is present. In a non-virtualized environment, the bit will be clear.

CPUID.01h.ECX:31 // if set, virtualization present

If the “hypervisor present bit” is set, additional CPUID leafs can be queried for more information about the conformant hypervisor and its capabilities. Two such leaves are guaranteed to be available: 0x40000000 and 0x40000001. Subsequently-numbered leaves may also be available.

Standard Hypervisor CPUID Leaves

When the leaf at 0x40000000 is queried, the hypervisor will return information that provides the maximum hypervisor CPUID leaf number and a vendor ID signature.

If the leaf at 0x40000001 is queried, it will return a value representing a vendor-neutral hypervisor interface identification. This determines the semantics of the leaves from 0x4000002 through 0x400000FF.

These two leaves allow the guest to query the hypervisor vendor ID and interface independently. The vendor ID is provided only for informational and diagnostic purposes. It is recommended that software only base compatibility decisions on the interface signature reported through leaf 0x40000001.

Microsoft Hypervisor CPUID Leaves

On hypervisors conforming to the Microsoft hypervisor CPUID interface, the 0x40000000 and 0x40000001 leaf registers will have the following values.

Hypervisor CPUID Leaf Range - 0x40000000

EAX determines the maximum hypervisor CPUID leaf. EBX-EDX contain the hypervisor vendor ID signature. The vendor ID signature should be used only for reporting and diagnostic purposes.

Hypervisor Vendor-Neutral Interface Identification - 0x40000001

EAX contains the hypervisor interface identification signature. This determines the semantics of the leaves from 0x40000002 through 0x400000FF.

Hypervisors conforming to the “Hv#1” interface also provide at least the following leaves.

Hypervisor System Identity - 0x40000002

Hypervisor Feature Identification - 0x40000003

EAX and EBX indicate which features are available to the partition based upon the current partition privileges.

Implementation Recommendations - 0x40000004

Indicates which behaviors the hypervisor recommends the OS implement for optimal performance.

Hypervisor Implementation Limits - 0x40000005

Describes the scale limits supported in the current hypervisor implementation. If any value is zero, the hypervisor does not expose the corresponding information; otherwise, they have these meanings.

Implementation Hardware Features - 0x40000006

Indicates which hardware-specific features have been detected and are currently in use by the hypervisor.

Nested Hypervisor Feature Identification - 0x40000009

Describes the features exposed to the partition by the hypervisor when running nested. EAX describes access to virtual MSRs. EDX describes access to hypercalls.

Hypervisor Nested Virtualization Features - 0x4000000A

Indicates which nested virtualization optimizations are available to a nested hypervisor.

Versioning

The hypervisor version information is encoded in leaf 0x40000002. Two version numbers are provided: the main version and the service version.

The main version includes a major and minor version number and a build number. These correspond to Microsoft Windows release numbers. The service version describes changes made to the main version.

Clients are strongly encouraged to check for hypervisor features by using CPUID leaves 0x40000003 through 0x40000005 rather than by comparing against version ranges.

Feature and Interface Discovery (ARM64)

On the ARM64 architecture, the following mechanisms are used for feature and interface discovery:

• HvRegister queries via HvCallGetVpRegisters – Used for static feature and version information.
• Memory-mapped registers – Used for status and control values.

In addition to these architecture-specific interfaces, the hypervisor provides a simple procedural interface implemented with hypercalls.

Hypervisor Discovery

Before using most hypervisor interfaces, software should first determine whether it's running within a virtualized environment.

On ARM64, guest software can discover the hypervisor using the SMCCC (SMC Calling Convention) standard interface. The discovery is performed using either the HVC or SMC instruction with the function ID 0xC600FF0 in X0 (this corresponds to a 64-bit vendor-specific hypervisor call, VENDOR_HYP_FUNCTION_CODE_UID). The call follows the SMCCC conventions, including an imm16 of 0. The Microsoft hypervisor returns the following values representing GUID 4d32ba58-cd24-4764-8eef-6c7516597024:

Once a hypervisor is detected, guest software can query hypervisor capabilities through synthetic registers using the HvCallGetVpRegisters hypercall. Several key registers can be queried before the Guest OS ID register is set, enabling early discovery of hypervisor features during boot.

Hypervisor Feature Registers

ARM64 platforms query hypervisor information through synthetic registers rather than CPUID instructions. These registers provide equivalent information to their x64 CPUID counterparts and are accessed via HvCallGetVpRegisters. All feature registers return 128-bit values.

Hypervisor System Identity - HvRegisterHypervisorVersion

Returns version information encoded in a 128-bit value. The layout is identical to x64 CPUID leaf 0x40000002, with x64 register values packed into the 128-bit result (EAX in bits 31-0, EBX in bits 63-32, ECX in bits 95-64, EDX in bits 127-96).

Hypervisor Feature Identification - HvRegisterPrivilegesAndFeaturesInfo

Equivalent to x64 CPUID leaf 0x40000003. Indicates which features are available to the partition based upon current partition privileges. Returns a 128-bit value with these fields:

Implementation Recommendations - HvRegisterFeaturesInfo

Equivalent to x64 CPUID leaf 0x40000004. Indicates which behaviors the hypervisor recommends the OS implement for optimal performance. Returns a 128-bit value.

Hypervisor Implementation Limits - HvRegisterImplementationLimitsInfo

Describes the scale limits supported in the current hypervisor implementation. If any value is zero, the hypervisor does not expose the corresponding information. Returns a 128-bit value with a layout identical to x64 CPUID leaf 0x40000005, with x64 register values packed into the 128-bit result (EAX in bits 31-0, EBX in bits 63-32, ECX in bits 95-64, EDX in bits 127-96).

Implementation Hardware Features - HvRegisterHardwareFeaturesInfo

Equivalent to x64 CPUID leaf 0x40000006. Indicates which hardware-specific features have been detected and are currently in use by the hypervisor. Returns a 128-bit value.

Core Performance Monitoring Unit (PMU) Event Types

A baseline set of Arm architecture Core PMU events is available to guest partitions on all ARM64 platforms. Additional Core PMU events are available on Azure Cobalt 100 and Azure Cobalt 200. Event numbers and names follow the Arm architecture PMU event definitions.

Guest software can identify the platform by reading the MIDR_EL1 register and comparing the low 32 bits for exact equality against the values in the following table, without masking the implementer, variant, architecture, part, or revision fields. This is the recommended heuristic for determining whether the additional Core PMU event types are available before accessing them.

In the following table, a checkmark (✓) indicates that the Core PMU event type is supported for guest partitions on the corresponding platform.

Versioning

The hypervisor version information is encoded in HvRegisterHypervisorVersion. The format matches the x64 equivalent.