Hypervisors

A hypervisor is a program that takes advantage of an architectural quirk in hardware to run emulated software at near-bare-metal speeds, especially with hardware-assisting, this is possible because the processor is designed to execute code in a hierarchy that allows less-privileged software to run almost unmodified. For any instruction in a program that requests more privileges, such as those used by drivers, the hypervisor steps in to emulate the hardware response. But even so running video games still slower than native hardware naturally. There are two types of hypervisors;

1. A bare-metal hypervisor, which is the operating system.
2. A software hypervisor, the ones many are familiar with. They hook into the kernel of an existing operating system (such as Linux or Windows NT) and run alongside the rest of the software on the system.

Hypervisors are the source of the "host" and "guest" terminology since they help clarify the specific "machine" one refers to; the host is the physical hardware and it manages the guests. Most hypervisors try and support the Open Virtualization Format (OVF) to facilitate virtual appliances which are built for a specific purpose (such as running common server software like WordPress or MediaWiki).

See High and low-level emulation page for more information about terms like "hypervisors", "simulators", "compatibility layers", "wrappers", "FPGA" and "software emulators".

Limitations of the Type-1 / Type-2 classification

The traditional distinction between Type-1 (bare-metal) and Type-2 (hosted) hypervisors originates from early virtualization systems, where the separation between hardware, operating system, and hypervisor was clearly defined. In this model, Type-1 hypervisors run directly on the hardware, while Type-2 hypervisors operate as applications within a conventional host operating system.

Modern virtualization technologies often blur this distinction. Several widely used hypervisors integrate deeply into an existing operating system kernel while still operating with characteristics traditionally associated with Type-1 hypervisors. In such cases, the operating system itself effectively assumes the role of the hypervisor, with user-space components providing virtual machine management, device emulation, and administration tools.

Examples of this hybrid approach include kernel-integrated hypervisors such as KVM[1] and Hyper-V, where virtualization functionality executes in kernel mode and directly utilizes hardware virtualization extensions, while a general-purpose operating system remains present for system management and user interaction. Although these systems may appear “hosted” from a user perspective, their execution model and performance characteristics align more closely with bare-metal hypervisors.

As a result, the Type-1 / Type-2 classification should be understood as a conceptual guideline rather than a strict technical rule. Some hypervisors may reasonably be described differently depending on whether the focus is on system architecture, deployment model, or user experience.

Type 2 hypervisors

Name	Platform(s)	Latest version	License	Active
x86
QEMU		11.1.0 qemu-3dfx ($)	GPLv2 (Copyleft)	✓
VMware Workstation Pro		17.6.4 Older versions	Proprietary	✓
VMware Fusion		11.5	Proprietary	✓
Parallels Desktop		18	Proprietary	✓
VirtualBox		7.2.6	GPLv3 (Copyleft)	✓
Virtual PC			Proprietary	✗
ARM
Parallels Desktop		18	Proprietary	✓
UTM		4.7.5	Apache 2.0 (Permissive)	✓
RTM		AppStore	Apache 2.0 (Permissive)	~
VMOS		1.0.63	Proprietary	✓

QEMU

A general-purpose emulator that supports a wide range of hardware for use on a multitude of platforms. Used to be a hypervisor by way of KQEMU but has been deprecated in favor of other systems like KVM (a kernel module for Linux and FreeBSD) and HAXM (which is developed by Intel). QEMU has been used to emulate several non-PC x86 machines like XQEMU/Xemu for the Xbox, and Orbital for the PlayStation 4. The non-specific application of QEMU allows emulators like XQEMU and Orbital to function as hypervisors without having to write custom-made drivers.

VirtualBox

Is open source but it has an extension pack that adds features common on modern standard PCs like USB 2.0, 3.0, PXE boot, and hard drive encryption. It is generally the easiest to set up and get running.

VMware Workstation Pro

Is also available for GNU/Linux, though the Windows version has better 3D support because of its native Direct3D implementation. Free for personal use from now on.[2]

VMware Workstation Player

Formerly VMware Player, it is VMware's free offering but lacks a few features like snapshots.

UTM

UTM is full featured system emulator[3] and virtual machine for Intel and ARM Macs and iOS devices. Under the hood of UTM is QEMU, so it's essentially a frontend for QEMU and it can do everything QEMU does. Windows (virtualized if the guest OS architecture matches that of the host, emulation if host and guest run on different architectures), PowerPC Macs, SPARC Solaris, etc.[4] On Apple Silicon (ARM) Macs virtualization is also available through Apple's own backend (this allows virtualizing current versions of macOS). Does not currently support GPU emulation/virtualization on Windows and therefore lacks support for 3D acceleration (e.g. OpenGL and DirectX)[5] Keep in mind that UTM SE ("slow edition", for iOS devices that haven't been jailbroken) version uses a threaded interpreter which performs better than a traditional interpreter but still slower than JIT used on macOS and jailbroken iOS devices.[6]

Virtual PC

Microsoft's original offering for consumers, originally made by Connectix as commercial software until Microsoft made it a free download in 2006. Support ended with the introduction of Hyper-V but the last version can be downloaded here. Beware that it may cause issues on newer Windows so it's recommended that it's ran on older versions of Windows. As of modern updates of Windows 10 and Windows 11, it is completely impossible to use it. Hyper-V is the official successor, although it lacks support for guests before Windows XP or Windows Server 2003.

VMOS

A program that runs another copy of Android on the current Android system, which would be useful for running multiple copies of the same application simultaneously, running applications that rely on older/newer versions of Android, testing out different Android system variations, or safely executing operations/applications that are likely to harm the system and/or user data.

Type 1 hypervisors

Rather than being installed as a standard program in an operating system, Type 1 hypervisors form the operating system used by a computer. Examples include;

• ESXi (commercial hypervisor by VMware)
• Xen (open-source hypervisor developed for the Linux kernel)
• KVM
• UnRAID (commercial NAS distribution with an integrated hypervisor)
• Hyper-V (commercial hypervisor Microsoft developed for Windows. Requires a Pro, Enterprise, or Education version of Windows 8, 8.1, or 10), also see #Hyper-V Subsets for WHPX and WSL2.
• CHARM (custom type-1 hypervisor designed to run multiple complex devices, peripherals and chipsets on a single, cutting-edge Arm server, allowing to virtualize devices on their native architecture[7])
• m1n1 (bootloader for Asahi Linux, also capable as acting as a hypervisor for Linux or macOS)

Integrations

Many type 2 hypervisors include some sort of additional software that can be installed in a guest. This software listens to the hypervisor and facilitates communication between the guest and host, allowing for features like automatic screen resizing (where the host measures the height and width of the window and sends an optimal size for the guest to resize the display to), clipboard sharing (where anything copied on the host can be pasted in the guest), shared folders (where a directory on the host can be made available for access from a guest using a built-in file server and a direct network connection to the guest), and mouse integration (where the hypervisor emulates an absolute pointing device like a drawing tablet to give the impression that moving the cursor in and out of the machine's display is seamless). Three hypervisors are known to have them;

• VirtualBox Guest Additions
• VMware Tools (and its open-source counterpart, open-vm-tools)
• Parallels Tools
• SPICE Guest Additions (for use with libvirt and/or QEMU on UNIX/Linux hosts)

VFIO

VFIO (short for Virtual Function I/O) is a Linux kernel driver for PCI passthrough. Its appeal is that it works with graphics cards, meaning hypervisors on Linux can bypass graphics emulation for modern Windows games as opposed to having to use compatibility layers and wrappers. The catch is that the system needs;

• An IOMMU (outlined in the VT-d and AMD-Vi specs) with processor and motherboard support

And because the graphics card doesn't get utilized until the guest powers on, that also means;

• A dedicated monitor, a monitor with multiple inputs, and/or a KVM switch (not to be confused with the KVM hypervisor)

If you're using an NVIDIA card, you also need to configure how the graphics card appears to the VM so that NVIDIA's driver doesn't reject the card.

If you're using Windows 10/11 for host OS you can use Hyper-V and GPU-P just like Linux GPU passthrough. jamesstringerparsec's "Easy-GPU-PV" batch script for making GPU Paravirtualization on Windows Hyper-V easier. If you're using Linux based operating system for host OS and aiming for the same purpose, see this guide.

Hyper-V Subsets

WHPX (Windows Hypervisor Platform), is an API framework introduced in Windows 10 to enable third-party applications to leverage Hyper-V’s virtualization capabilities without needing to interact directly with the full Hyper-V stack. It’s essentially a lighter, more accessible interface for developers to create and manage VMs or run emulators using Hyper-V’s underlying technology.

In May 2019, Windows Subsystem for Linux 2/WSL 2 was announced, introducing important changes such as a real Linux kernel, through a subset of Hyper-V features. WSL 2 differs from WSL 1 in that WSL 2 runs inside a managed virtual machine that implements the full Linux kernel (similar to Windows Subsystem for Android/WSA). As a result, WSL 2 is compatible with more Linux binaries than WSL 1, as not all syscalls were implemented in WSL 1. There are even feature requests such as Gamepad support.

Performance impact

Enabling VT-x/AMD-V in the BIOS

Enabling VT-x/AMD-V in the BIOS simply unlocks the CPU's hardware extensions for virtualization. When no hypervisor or virtualization-based features are active, the overhead is effectively zero — modern CPUs handle these extensions efficiently with no measurable impact on everyday tasks, gaming, or benchmarks.

On Windows, Why Disabling Hyper-V / Windows Hypervisor Platform (WHPX) Can Improve Performance

When Hyper-V or related components (such as Virtual Machine Platform or Windows Hypervisor Platform) are enabled, Windows runs as a root partition on top of a lightweight hypervisor (normally, the OS kernel runs at Ring 0, the highest privilege level. With Hyper-V, the hypervisor occupies a higher privilege level, often called Ring -1, forcing the OS to communicate through a translation layer for certain hardware tasks). Even when no virtual machines are running, this can introduce small but measurable overhead in some workloads, including:

• Slight FPS reductions in certain games (commonly 0–5%, workload- and system-dependent)
• Minor increases in memory and interrupt latency
• Performance reductions in synthetic or latency-sensitive benchmarks (occasionally higher in worst-case scenarios)

Features tied to this architecture, such as Core Isolation > Memory Integrity (part of Virtualization-Based Security, or VBS), can introduce additional overhead. On some systems and in CPU-heavy or low-latency games, this may result in noticeable performance losses compared to running without VBS enabled.

For users prioritizing maximum performance and minimal latency, disabling Hyper-V–related features and VBS can recover that edge. These features can be re-enabled if required for specific applications, security requirements, or development workflows.

On Linux, KVM Behavior and Performance Impact

Most Linux distributions include KVM support in the kernel by default. The KVM kernel modules (kvm, kvm_intel, or kvm_amd) may be loaded automatically at boot or on demand, depending on the distribution and system configuration.

When no virtual machines are running:

• The Linux kernel runs directly on bare metal.
• KVM remains dormant and does not insert a persistent hypervisor layer.
• There is no measurable impact on gaming performance, benchmarks, latency, or everyday tasks.

KVM activates hardware virtualization extensions only when a virtual machine process explicitly uses them. This design allows Linux systems to retain full bare-metal performance while still providing instant access to hardware-accelerated virtualization when needed.

Architectural Comparison

Feature	Windows (Hyper-V / VBS Enabled)	Linux (KVM / QEMU)
Architecture Type	Type-1: OS runs in a "Root Partition" on top of the hypervisor.	Hybrid/Native: Kernel stays on bare metal; VMs run as tasks.
OS Privilege Level	OS is "guest-like" (Ring 0 managed by Ring -1).	OS retains direct Ring 0 hardware access.
Idle Overhead	Small but measurable (Instruction latency/VBS checks).	Effectively zero.
Gaming Impact	Potential FPS loss and increased frame-time variance.	No impact on host gaming performance.

Recommendation

• Keep VT-x/AMD-V enabled in the BIOS — it is harmless when unused, introduces no measurable overhead, and keeps virtualization available for occasional use (e.g., emulators, testing, or virtual machines).
• Windows users focused on maximum performance and low latency: consider disabling Hyper-V, Windows Hypervisor Platform, Virtual Machine Platform, and Core Isolation > Memory Integrity if these features are not required. Verify whether VBS is actually enabled, as installed components do not always mean active virtualization.
• Linux users: no action is required for performance reasons. Even if KVM modules are loaded, they remain inactive unless a virtual machine is running and do not affect system performance.

Sandbox and Userspace Emulators

Name	Platform(s)	Latest version	License	Active
PC
Sandboxie-Plus		1.17.9	GPLv3	✓
Sogen		git	GPLv2	✓

Hypervisor issues

Obscure Beta or Experimental Operating Systems

Despite many of the common operating systems including legacy ones such as MS-DOS, OS/2, Novell Netware, etc. are being supported by modern hypervisors, some obscure (e.g. TempleOS) and abandoned (e.g. Chokanji 1~4) beta or experimental (e.g. Windows "Chicago" Beta) operating systems may still fall out of the range and having issues, especially when relying on specific hardware configuration or old quirks that no longer presents in modern PC hardware. Using a low-level IBM-PC emulator to run these operating systems may ease out such problems but its significantly slower performance compared to hardware-assisted Hypervisors.

macOS

There's an ongoing effort to get macOS installations working on hypervisors that run on non-Apple hardware. Such support has historically been low or non-existent since Apple makes no effort to support standard PC hardware. Some people have gotten this to successfully work on KVM/QEMU, with an example/setup guide for Debian/Ubuntu hosts being available here. With macOS 26 Tahoe being the last version to run on x86 CPUs, the future of virtualizing macOS is uncertain.

However, running macOS on hypervisors running on actual Mac hardware is natively supported by hypervisor software like Parallels Desktop or VMware Fusion, and such software is also able to virtualize ARM versions of Windows and Linux.

Sound issues

VMware has sound related issues with some of the legacy guest operating systems like Windows 2000, Windows XP or Windows Vista. According to user reports, sometimes sound stops working OR it become laggy on guest operating system by launching some applications/games. Sometimes audio gets distorted/crackling noise popping.

Reddit thread: Windows XP guest sound laggy

forums.mydigitallife.net: Choppy sound on VMware (affecting 2000/XP/Vista Guests)

Use this fix. (or use older fix)

ISBRendererComm error with 3D Acceleration

ISBRendererComm crash

There was a major change in VMware 16.x in how virtual graphics were handled (sandboxed) and it also added support for DX11 in Windows VMs. But due to these changes users reported lots of crashes lately especially with "3D Acceleration". For more information about these type of errors see this thread.

So use 15.7 or older version until this issue is fixed.

Hyper-V feature conflict issue

Many third-party Type 2 virtualization applications don't work together with Hyper-V feature from 'Control Panel/Windows Features'. These applications might not start virtual machines, or they may fall back to a slower, emulated mode (no VT-x and nested paging etc.) Some reports consider this issue fixed via recent updates and WHP windows feature.[8] See this thread for more information about this issue.

If you have conflict issue, you can try these steps;

1. Disable Hyper-V and Virtual Machine Platform: Go to "Turn Windows features on or off" in the Control Panel and uncheck both the "Hyper-V" and "Virtual Machine Platform" options.
2. Disable Virtualization-Based Security (VBS): In Windows Security, navigate to Device Security -> Core isolation details and turn off Memory Integrity.
3. Run a bcdedit command: Open an elevated Command Prompt or PowerShell and run bcdedit /set hypervisorlaunchtype off. This command ensures that the hypervisor doesn't launch during startup.

or use this batch script;

@echo off
setlocal
echo ----------------------------------------------------------------------------------
echo This script will disable the Hyper-V hypervisor and related platforms on Windows 11.
echo This is necessary for some older third-party hypervisors to work correctly.
echo This script MUST be run with Administrator privileges.
echo ----------------------------------------------------------------------------------
echo.

:: Check for administrator privileges
net session >nul 2>&1
if %errorLevel% neq 0 (
    echo.
    echo ERROR: Please run this script as an Administrator.
    echo.
    pause
    goto :eof
)

echo Disabling Virtual Machine Platform...
Dism /online /Disable-Feature /FeatureName:VirtualMachinePlatform /NoRestart

echo Disabling Hypervisor Platform (WHP)...
Dism /online /Disable-Feature /FeatureName:HypervisorPlatform /NoRestart

echo Disabling Hyper-V and its components...
Dism /online /Disable-Feature /FeatureName:Microsoft-Hyper-V-Hypervisor /NoRestart
Dism /online /Disable-Feature /FeatureName:Microsoft-Hyper-V /NoRestart
Dism /online /Disable-Feature /FeatureName:Containers-DisposableClientVM /NoRestart

echo.
echo Changes have been staged. Please RESTART your computer to apply them.
echo You may be prompted to restart after this script completes.
echo.

pause

Virtualization Detection Mechanisms

Advanced anti-cheat (AC) detection systems, operating at the kernel level, employ sophisticated mechanisms to identify and block virtual machines (VMs) from running unauthorized software. These systems leverage low-level hardware and system checks to detect virtualization environments, including hypervisor signatures, virtualized hardware components, and system timing discrepancies. Additionally, simple evasion techniques, such as manipulating hardware IDs (e.g., CPUID, MAC addresses, or disk serial numbers), are often employed by users attempting to bypass detection. Synthetic Model-Specific Registers (MSRs), where hypervisors like Hyper-V or VMware expose reserved MSR ranges (e.g., 40000000h-400000FFh) that return data instead of triggering a general-protection exception on real hardware. Another approach involves Last Branch Recording (LBR) stack verification, which compares LBR entries before and after a VM-exit (e.g., via CPUID) to detect inconsistencies in branch tracking caused by improper hypervisor handling. Timing-based attacks extend beyond basic discrepancies, such as Instruction Execution Time (IET) divergence using the IA32_APERF MSR to measure differences in execution cycles for VM-exiting instructions, which remain detectable even in optimized hypervisors due to unavoidable overhead. Cache invalidation side-channels, like sequencing WBINVD followed by INVD, exploit emulation flaws where virtual machines fail to simulate real hardware's data loss from caches. Control register (CRn) masking, particularly for VMX enable bits, can reveal virtualization if masked bits allow VMX instructions to execute without proper exceptions. WoW64 descriptor table checks target Windows compatibility mode, detecting hypervisors that mishandle the byte length written by instructions like SIDT or SGDT. Some systems, like EasyAntiCheat, use direct instruction tests such as executing VMREAD at ring 0 to check for untrapped hypervisor behavior or querying the IA32_EFER MSR to verify syscall enable bits. Furthermore, anti-cheats may monitor for debug exceptions with trap flags, invalid XSETBV parameters that could induce crashes in naive emulations, or garbage writes to unimplemented MSRs that fail to inject expected faults.

Modern anti-cheat systems, sandbox detectors, and advanced malware analysis engines utilize a variety of techniques to identify whether they are running inside a virtualized or emulated environment. These techniques operate across multiple layers (kernel, hypervisor, firmware, and microarchitecture) and leverage discrepancies in hardware behavior, instruction handling, and timing precision.

Kernel-Level and Practical Detection Techniques

Hypervisor CPUID Leaf Exposure: Detects virtualization by checking the CPUID instruction’s “hypervisor present” bit (bit 31 of ECX in CPUID leaf 1) or by probing reserved hypervisor leaves (0x40000000–0x40000FFF). Real hardware does not implement these leaves, while hypervisors return identifiable vendor strings (e.g., "VMwareVMware", "Microsoft Hv", "VBoxVBoxVBox").

Synthetic Model-Specific Registers (MSRs): Hypervisors expose synthetic MSRs within the 0x40000000–0x400000FF range. Accessing these on bare metal triggers #GP exceptions, but under a hypervisor, valid data is returned (e.g., Hyper-V, VMware, and KVM implementations).

Timing-Based Detection (IET / TSC Drift): Measures instruction execution time or TSC (timestamp counter) deltas across privileged or VMEXIT-causing instructions (`CPUID`, `IN`, `OUT`, `VMCALL`). Virtualized environments cannot eliminate timing overhead, even with paravirtualized TSC emulation. Advanced variants use the `IA32_APERF` and `IA32_MPERF` MSRs to compare cycle counts at high precision.

Last Branch Recording (LBR) Verification: Compares LBR entries before and after VMEXIT (e.g., a `CPUID` instruction). Hypervisors that fail to preserve or emulate branch history correctly show stack mismatches or truncated records.

Cache Invalidation and Side-Channel Tests: Sequences like `WBINVD` followed by `INVD` detect virtualization flaws. On physical hardware, cache invalidation wipes data; emulated systems often skip or mis-handle cache coherence effects.

Control Register (CRn) Masking Checks: Tests control registers (e.g., CR0, CR4) for virtualization artifacts, especially CR4.VMXE masking. Hypervisors may permit setting VMX-enable bits without producing exceptions, which never occurs on bare metal.

Descriptor Table (GDT/IDT/LDT) Verification: Executes `SGDT`, `SIDT`, and `SLDT` to verify descriptor table bases and limits. Virtualization layers sometimes expose non-native addresses or truncated limits, betraying emulation.

WoW64 Descriptor Table Anomalies: Uses `SIDT` and `SGDT` in WoW64 mode to detect discrepancies in the byte length of descriptor table outputs. Some hypervisors mishandle the 6-byte structure written by these instructions under compatibility layers.

VMX Instruction Behavior: Executes VMX instructions (`VMREAD`, `VMWRITE`, `VMLAUNCH`, or `VMCALL`) from ring 0. On real hardware, these should raise #UD or #GP exceptions if VMX is disabled; untrapped execution or silent success indicates a hypervisor.

IA32_EFER and SYSENTER/SYSCALL Tests: Reads and writes the `IA32_EFER` MSR to confirm proper `SYSCALL`/`SYSRET` enable behavior. Hypervisors that shadow or mask EFER bits may yield inconsistent results when compared against expected CPU capabilities.

Debug Exception and Trap Flag Monitoring: Observes timing and sequence of debug exceptions using single-step tracing and trap flags. Hypervisors often introduce latency between #DB events or miss certain triggers after VMEXIT.

Fault Injection Robustness: Executes intentionally invalid operations (e.g., bad `XSETBV` parameters, garbage MSR writes) and verifies proper fault injection. Poorly emulated environments may fail to raise exceptions or cause inconsistent crashes.

Hardware ID Spoofing Countermeasures: Compares CPUID vendor strings, BIOS serials, MAC addresses, and disk serial numbers against known virtual device signatures (e.g., “VMware”, “VirtualBox”, “QEMU”, “Hyper-V”).

I/O Port Communication Checks: Probes known virtualization I/O ports (e.g., VMware’s 0x5658 “VX” backdoor port) and checks for valid responses. Real hardware always raises #GP exceptions for these ports.

Interrupt Descriptor Table and Task Gate Validation: Verifies proper IDT and TSS gate alignment; some hypervisors emulate interrupts lazily or remap entries inconsistently across CPUs.

Memory Type Range Register (MTRR) Consistency: Reads MTRR settings to confirm caching policy uniformity. Virtualized systems sometimes emulate fixed MTRRs incorrectly, exposing uniform caching across memory regions that differ in real systems.

SMEP/SMAP/UMIP Feature Masking: Checks whether supervisor-mode protections and memory isolation bits behave correctly. Some hypervisors disable or virtualize these features, leaving detectable inconsistencies in CR4 or CPUID feature bits.

Virtual Device Driver Artifacts: Searches the kernel’s driver list or device manager entries for known virtual hardware drivers (e.g., `VBoxGuest.sys`, `vmhgfs.sys`, `vmci.sys`).

Extended Hardware and Firmware-Level Detection Methods

These techniques go beyond common anti-cheat usage and explore microarchitectural, power, and firmware-based detection methods — used in advanced sandbox evasion or security research.

Performance Monitoring Counter (PMC) Divergence: Reads counters (`IA32_PERFEVTSELx`, `IA32_FIXED_CTRx`) before and after privileged instructions. Hypervisors may distort counts due to hidden VMEXITs or emulated events.

CPUID Consistency and Brand String Anomalies: Queries multiple CPUID leaves and compares subleaf outputs. Hypervisors often mask feature bits inconsistently across cores or return altered brand strings.

Timestamp Drift via HPET and TSC Comparison: Measures discrepancies between high-precision event timers (HPET), ACPI PM timers, and TSC readings. Any non-linear drift or quantized step pattern suggests virtual timer scaling.

System Management Mode (SMM) Latency Analysis: Measures interrupt handling delay or SMI entry/exit timing. Virtualization layers often lack accurate SMM emulation, causing measurable latency differences.

Branch Target Buffer (BTB) Pollution: Observes BTB resets or contamination after VMEXITs by measuring branch misprediction penalties. Inconsistent BTB state restoration indicates hypervisor transitions.

Return Stack Buffer (RSB) and Speculative Path Behavior: Detects virtualization through speculative execution anomalies — e.g., RSB underflows, mispredicted returns, or altered speculation recovery patterns.

Translation Lookaside Buffer (TLB) and Paging Structure Verification: Tests page mapping consistency by invalidating and remapping memory. Lazy TLB flushes or global bit misuse expose virtualization latency artifacts.

NUMA and Topology Inconsistencies: Parses ACPI and APIC data for unrealistic CPU numbering or simplified NUMA configurations. Hypervisors often fake CPU topology with uniform latencies.

Thermal and Power (RAPL) Reporting Discrepancies: Reads power management MSRs (e.g., `MSR_PKG_POWER_INFO`, `MSR_PKG_RAPL_POWER_LIMIT`) and compares to expected values. Virtualized CPUs frequently return zeroed or static data.

PCI Enumeration and ACPI Table Artifacts: Scans PCI configuration space and ACPI DSDT/FADT tables for virtualization identifiers or simplified descriptors (“VBOX”, “VMWARE”, “QEMU”).

Firmware and SMBIOS Signature Scans: Examines SMBIOS tables and firmware descriptors for synthetic OEM strings (e.g., “innotek GmbH”, “VMware, Inc.”).

Microcode Revision and MSR Shadowing: Reads microcode revision MSRs (`IA32_BIOS_SIGN_ID`) and checks for logical CPU mismatches. Hypervisors may shadow microcode inconsistently across cores.

Cache Hierarchy and Memory Bandwidth Profiling: Measures L1/L2/L3 cache sizes, associativity, and latency. Virtualized caches often show flattened performance curves or inconsistent cache hierarchy behavior.

I/O Timing and Interrupt Latency Profiling: Benchmarks interrupt service time via APIC or HPET-based timers. VMEXIT scheduling introduces distinct periodic delay patterns.

Firmware Table and ACPI Manipulation Detection: Reads RSDT/XSDT and UEFI tables for incomplete or synthetic entries. Real firmware exposes complete OEM descriptors; virtual ones use generic identifiers.

Power Management and Idle State Emulation: Queries C-state and P-state MSRs to detect static or nonfunctional power scaling. Hypervisors often emulate CPU power states minimally.

Thermal Sensor and MSR Behavior: Accesses temperature MSRs (`IA32_THERM_STATUS`, `IA32_PACKAGE_THERM_STATUS`). Virtual CPUs often report constant or unrealistic readings.

Bus Lock and Atomic Operation Timing: Measures timing on locked instructions (`XCHG`, `CMPXCHG8B`) across cores. Virtualization introduces measurable contention delays during atomic emulation.

Speculative Fault Handling Timing: Tests speculative fault recovery speed with invalid memory accesses. Hypervisors with incomplete speculative state restoration display consistent micro-delay artifacts.

Type-1 Hypervisor and Root Partition Behavior

Root Partition Virtualization: When Hyper-V, Windows Hypervisor Platform, or Virtual Machine Platform is enabled in Windows Features, the Windows kernel itself runs as the "Root Partition" under the Hyper-V hypervisor. This means the main Windows OS is no longer directly on bare metal but operates as a privileged guest managed by the hypervisor. The CPU's VT-x (Intel) or AMD-V (AMD) extensions (Hardware-Assisted Virtualization) allow Hyper-V to take control of all privileged instructions, memory mappings, and system calls. Even the root Windows partition executes VMEXITs for certain privileged operations, making low-level hypervisor detection bits (e.g., CPUID hypervisor bit, synthetic MSRs) observable from the OS itself.

Child Partitions and Containers: Guest VMs, WSL2, Windows Sandbox, and Windows Containers run as child partitions under Hyper-V. The root partition manages these partitions, schedules hardware resources, and exposes paravirtualized interfaces where applicable. This architecture ensures container-like isolation for these workloads while retaining high privileges in the root OS.

Implications for Detection: Many of the techniques listed in Kernel-Level and Extended Hardware sections (e.g., CPUID hypervisor leafs, MSR shadowing, timing discrepancies) will report "virtualized environment" even on a fully updated Windows system with Hyper-V enabled, because the OS itself runs under a Type-1 hypervisor. Tools, anti-cheat systems, or sandbox detectors may detect the presence of Hyper-V even when no additional VMs are running.

See also

Related to Hypervisors;

• Windows 95/98/ME emulators
• Windows NT 5.x emulators
• Windows NT 6.x emulators
• MacOS
• Android emulators

CPUs and Other chips emulation instead of virtualization;

• POS (Pong Consoles) CPUs and Other Chips

External links

• VMware Products Release Tracker
• VirtualBox changelog