The Depths of Windows Virtualization (Part 1) — Where Is Your Windows Actually Running? The Hypervisor and Partitions

Open System Information (msinfo32) on Windows 11 and you will often see “Running” in the “Virtualization-based security” field — even on a machine where you have never created a VM.

What that means is the following fact. On that PC, the host Windows itself is already running on top of a hypervisor. “Virtualization” is no longer a technology only for people who create VMs in Hyper-V Manager. On Windows 11, virtualization-based security (VBS) is enabled by default on configurations that meet the conditions — a clean install on compatible hardware, for example¹ — and both WSL2 and Windows Sandbox are built on the same Windows hypervisor. Under the Windows you use every day, there is already one more layer of software.

This series, “The Depths of Windows Virtualization”, follows what happens in that layer, starting from the foundations.

“The Depths of Windows Virtualization” — All 3 Parts

1. Part 1 (this article): The Hypervisor and Partitions
   We follow where the host Windows ends up running when you enable Hyper-V.
2. Part 2: Memory Even the Kernel Cannot See — VBS, HVCI, and Credential Guard
   We follow where Windows puts secrets that neither an administrator nor the kernel can read.
3. Part 3: Virtual Machines That Boot in Seconds — WSL2, Windows Sandbox, and Containers
   We follow, from how memory and images are shared, why WSL2 and Sandbox are light even though a full VM is heavy.

The question Part 1 answers is just one.

When you enable Hyper-V, where does the host Windows end up running?

Intended readers are developers and operators who use Hyper-V, WSL2, or Windows Sandbox and want to understand from the mechanism up what is running underneath. Prerequisites are x64 Windows 10/11 or current Windows Server (the discussion of rings, VT-x/AMD-V, and EPT/RVI in this article assumes x64; Arm64 uses a different mechanism such as exception levels). Required background is about the distinction between kernel mode and user mode; you do not need VM operations experience or hypervisor-development knowledge. The difficulty is intermediate. We cover the concept of CPU virtualization extensions, but we do not go into instruction-set details.

1. The Bottom Line First

When people hear Hyper-V, they may picture “VM-running software that sits on top of Windows”. The actual structure is the reverse.

From the moment you enable Hyper-V and reboot, it is the hypervisor that controls the physical CPUs and memory, and the host Windows runs on top of it as the first, privileged partition — the “root partition”.

A hypervisor is a thin software layer that sits between the hardware and the OS, creates isolated execution environments called “partitions”, and mediates access to the hardware.² The one the host Windows goes into is the root partition; the ones VMs go into are child partitions. The root partition is treated specially (it has direct access to physical devices and holds the management stack), but in the sense that it does not directly control the physical CPUs, it stands in the same position as a child partition.

flowchart TB
    accTitle: Overall structure after Hyper-V is enabled
    accDescr: The hypervisor sits directly on the physical hardware, and above it sit the root partition that holds the host Windows and the child partitions that hold VMs
    hw["Physical hardware"] --> hv["Hypervisor"]
    hv --> root["Root partition (host Windows)"]
    hv --> child1["Child partitions (VMs)"]
    root -.-> stack["Holds the virtualization management stack and device drivers"]

Figure 1: Hyper-V is not “VM software on top of Windows” but a layer that goes underneath Windows, and the host OS itself runs inside the root partition.

You might think, “If it doesn’t feel any different after I enable it, has such a major inversion really taken place?” It has. That is exactly why this structure usually goes unnoticed. In this article we take this single diagram apart along three axes: CPU, memory, and device I/O.

2. From the CPU — One More Privilege Below the Rings

2.1. A Recap of Ring Protection

x64 CPUs have privilege levels (rings), and Windows runs kernel mode at ring 0 and user mode at ring 3. Applications cannot touch hardware directly because privileged instructions cannot be executed from ring 3.

So how do you safely house multiple OS kernels, each running at ring 0, on the same physical CPU? Every kernel is written on the assumption that “I control the CPU”. Give ring 0 to all of them and they collide; withhold it and they will not run.

flowchart TB
    accTitle: The problem of multiple OS kernels demanding ring 0
    accDescr: Both the host and guest kernels are written assuming full authority at ring 0, so the traditional ring ladder alone cannot house them safely on the same physical CPU
    k1["Host kernel (assumes ring 0)"] --> want["Demands control of the physical CPU"]
    k2["Guest kernel (assumes ring 0)"] --> want
    want --> conflict["The traditional rings cannot reconcile this"]
    conflict --> need["A mediator above ring 0 is required"]

Figure 2: The ring ladder was built assuming a single OS, so housing multiple kernels needs one more privilege above it.

2.2. Virtualization Extensions — A Mode Reserved for the Hypervisor

The thing that solves this problem is the CPU’s virtualization extensions (Intel VT-x/AMD-V). Hyper-V requires a processor that has this feature.² Virtualization extensions add, on an axis separate from the traditional rings, an “execution mode for the hypervisor” and an “execution mode for guests”. It is a privilege even stronger than ring 0, sometimes nicknamed “ring -1”.

• The guest kernel continues to run at ring 0, as before. No rewrite is required.
• That ring 0, however, is “ring 0 inside guest mode”, and it does not control the physical CPU as a whole.
• When the guest hits a particular operation that requires hypervisor intervention (an instruction configured as an intercept, or an exception or violation), the CPU automatically transfers control to the hypervisor (a VM Exit). When the hypervisor finishes handling it, it returns to the guest (a VM Entry). Ordinary memory accesses pass through with no VM Exit, as long as the SLAT translation succeeds.

Interrupts work the same way. Partitions do not touch physical processors directly; the hypervisor receives interrupts and directs them to each partition.²

flowchart TB
    accTitle: The flow of guest execution and VM Exit
    accDescr: The guest kernel and apps run at ring 0 and ring 3 in guest mode; ordinary memory accesses pass through via SLAT translation, while configured intercepts and exceptions cause a VM Exit that transfers control to the hypervisor, which then returns to the guest via VM Entry
    guest["Running in guest mode (including a ring-0 kernel)"] --> op{"Operation that needs intervention? (configured intercepts/exceptions)"}
    op -->|No| cont["Continue executing as-is"]
    op -->|Yes| exitEv["VM Exit (CPU transfers control)"]
    exitEv --> hvp["Hypervisor handles it"]
    hvp --> entry["Return to the guest via VM Entry"]
    entry --> guest

Figure 3: The guest OS keeps running at ring 0 with no rewrite, and the CPU calls the hypervisor only when needed.

This round trip looks a lot like the flow we followed in the memory series — “enter the kernel on a page fault, then return to the same instruction”. The CPU intercepts control through an exception or transition mechanism, lets a higher-level manager decide, and then returns. In the depths of Windows, this shape appears again and again.

2.3. Type 1 and Type 2 — The Difference Is Where It Sits

Hypervisors are broadly divided into Type 1 (bare-metal), which runs directly on the hardware, and Type 2 (hosted), which runs on top of a host OS. Hyper-V is Type 1.³ VirtualBox and VMware Workstation (when run standalone) are classified as Type 2.

Hearing Type 1, people tend to imagine “a server-only configuration with no host OS”, but Hyper-V is different. The host Windows does not disappear — it “moves house” into the root partition. When you enable Hyper-V and reboot, the hypervisor starts first during boot, and the host Windows then comes up as the root partition on top of it.

flowchart TB
    accTitle: The difference between Type 1 and Type 2 hypervisors
    accDescr: In Type 2 the host OS sits on the hardware and the hypervisor and VMs sit on the host OS, whereas in Type 1 Hyper-V the hypervisor sits directly on the hardware and the host OS itself goes into the root partition above it
    subgraph t2 ["Type 2 (hosted)"]
        hw2["Hardware"] --> hostos["Host OS"]
        hostos --> hv2["Hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1 (Hyper-V)"]
        hw1["Hardware"] --> hv1["Hypervisor"]
        hv1 --> root1["Root partition (host OS)"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

Figure 4: In Type 2 the hypervisor sits on the host OS, whereas in Type 1 Hyper-V the order is reversed and the host OS itself sits on the layer one step below.

Viewed on a boot timeline, the change that happens when you enable it looks like this.

flowchart TB
    accTitle: Boot order after Hyper-V is enabled
    accDescr: After power-on, the hypervisor starts first during boot, the host Windows then comes up as the root partition on top of it, and VMs, VBS, and the like start after that
    poweron["Power on and boot start"] --> bhv["Hypervisor starts first"]
    bhv --> broot["Host Windows starts as the root partition"]
    broot --> blater["VMs, VBS, WSL2, and so on start on top of that"]
    broot -.-> feel["The user's experience is unchanged"]

Figure 5: The reversal of order is already finished before the logon screen appears, and the host OS comes up on the hypervisor from the start.

3. Partitions — The Unit of Isolation

3.1. Roles Only the Root Partition Has

A partition is a logical unit of isolation that the hypervisor provides.² Not every partition is equal, though. There are things only the root partition has.

• Direct access to physical devices. Device drivers for disks, NICs, GPUs, and the like live in the Windows inside the root partition, not in the hypervisor. Hyper-V on Windows Server does have a configuration that assigns a specific PCIe device directly to a child partition (Discrete Device Assignment); in that case the root lets go of that device (this is not available on client Windows).⁴
• The virtualization management stack. VMMS (Virtual Machine Management Service), which governs creating, starting, and stopping VMs, and the per-VM worker process (vmwp.exe) run in user mode in the root partition.⁵ These are part of Hyper-V’s VM management features, so they may be absent on a host where only the hypervisor is running for VBS or WSL2.
• The right to create child partitions. The root partition creates child partitions through the hypercall API (the calling interface into the hypervisor).²

This design has a reason. If you put every device driver into the hypervisor itself, the hypervisor becomes huge and the number of bugs and attack entry points grows. The hypervisor confines itself to the minimal work of mediating CPUs and memory, and leaves the care of devices to the Windows in the root partition. This division of roles is what keeps Hyper-V thin.

flowchart TB
    accTitle: Division of roles between the root partition and child partitions
    accDescr: The root partition holds the virtualization management stack and physical device drivers and creates child partitions via hypercalls; a child partition normally sees only virtual devices, and under Discrete Device Assignment on Windows Server it accesses the assigned device directly
    subgraph rootp ["Root partition"]
        vmms["VMMS and worker processes"]
        drv["Physical device drivers"]
    end
    subgraph childp ["Child partition"]
        gos["Guest OS"]
        vdev["In the usual configuration, only virtual devices are visible"]
    end
    vmms -->|Create and manage via hypercalls| childp
    hv2["Hypervisor (confines itself to mediating CPU and memory)"] --- rootp
    hv2 --- childp

Figure 6: Putting device drivers and the management stack on the root-partition side is what keeps the hypervisor itself thin.

3.2. The World as Seen from a Child Partition

The guest OS in a child partition cannot see physical hardware directly in the usual virtual-device configuration (the only exception is a device assigned via Discrete Device Assignment on Windows Server, as described in the previous section). What it can see are virtual processors, a memory space that appears to be its own, and virtual devices. Requests to virtual devices are forwarded to the root partition via VMBus or the hypervisor.² CPU-time allocation and memory translation via SLAT, on the other hand, are handled directly by the hypervisor without going through the root. What the root mediates is device I/O, not every physical resource.

flowchart TB
    accTitle: The world as seen from a child partition
    accDescr: What the guest OS sees is virtual processors, a memory space private to the partition, and virtual devices; requests to virtual devices are forwarded to the root partition via VMBus and the like, CPU time and memory translation are handled directly by the hypervisor, and in a Discrete Device Assignment configuration on Windows Server only assigned devices are accessed directly
    gos2["Guest OS（child）"] --> vcpu["Virtual processors"]
    gos2 --> rest{"Memory or devices?"}
    rest --> gpa2["Private memory space"]
    rest --> vdev2["Virtual devices"]
    vdev2 --> rootx["Forwarded to the root"]
    rootx -.-> vbus["Via VMBus and the like"]
    gos2 -.-> phys2["Phys CPU, RAM, devices"]
    phys2 -.-> hid["Not visible directly"]
    phys2 -.-> dda2["DDA: assigned devices"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

Figure 7: In the usual virtual-device configuration everything the guest sees is a virtual window and the path to the physical goes through a mediator; only a device assigned via DDA on Windows Server is the exception.

What matters here is that for an app running on the host Windows, this structure is almost transparent. Win32 API calls and page-fault handling are still processed by the Windows kernel inside the root partition, as before. The hypervisor intervenes only when a configured intercept or exception is hit.

4. From Memory — Address Translation Gains One More Level

4.1. Three Kinds of Address

In Part 1 of the memory series we followed the flow by which a virtual address is translated through the page table into a physical address (“The Moment a Virtual Address Becomes Physical RAM”). In a virtualized environment one more level is added underneath that translation, and there are three kinds of address.

The guest OS translates GVA to GPA with its own page table. The GPA the guest sees, however, is not a real physical address; it is a private memory space dedicated to each partition.² Mapping GPA onto the actual location in RAM (SPA) is the hypervisor’s job.

4.2. SLAT — Two-Level Translation in Hardware

If you do this second-level translation in software alone, the hypervisor has to track every guest page-table update one by one, which is not realistic from a performance standpoint. So the CPU provides a mechanism that walks the second-level translation tables in hardware. That is SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) and AMD RVI are the implementations. Current Hyper-V requires a SLAT-capable 64-bit processor.⁴

flowchart TB
    accTitle: Two-level address translation via SLAT
    accDescr: A guest virtual address is translated to a guest physical address by the guest OS page table, then further translated to a system physical address by SLAT, which the hypervisor manages, and reaches actual RAM
    gva["Guest virtual address (GVA)"] -->|Guest OS page table| gpa["Guest physical address (GPA)"]
    gpa -->|"SLAT (EPT/RVI translation tables)"| spa["System physical address (SPA)"]
    spa --> ram["Physical RAM"]
    gpa -.-> note["A layer the guest merely believes is physical"]

Figure 8: Another translation table, managed by the hypervisor, sits under the guest’s page table, and the CPU walks both in hardware.

SLAT is not a feature that exists only for VM execution efficiency. The VBS we will see in Part 2 uses the property that “you can have a different SLAT translation table per privilege level” as material for a security boundary. The reason you can create memory that even the kernel cannot see is that the hypervisor holds this second-level translation. This becomes a through-line for the whole series, so just remember one point: “the owner of the translation tables is the hypervisor”.

5. From Device I/O — VMBus and Two Kinds of Device

5.1. The Limits of Emulated Devices

The classic way to show a device to a child partition is to fully imitate real hardware (an old IDE controller, for example) in software. Compatibility is high because the guest OS’s inbox drivers work as-is, but a VM Exit occurs every time the guest hits an I/O port, and performance does not scale.

flowchart TB
    accTitle: Why I/O to an emulated device is slow
    accDescr: Every time the guest operates an I/O port, control transfers to the hypervisor side via a VM Exit, the device is imitated in software, and the guest is returned to, so the round trip repeats and is slow
    gio["Guest operates an I/O port"] --> vex["A VM Exit occurs"]
    vex --> emu2["The device is emulated in software"]
    emu2 --> back["Return to the guest via VM Entry"]
    back -->|Repeats on the next port operation| gio

Figure 9: This round trip runs many times behind a single disk access, and the price of compatibility is paid in performance.

5.2. VMBus and VSP/VSC — A Fast Path Designed for Virtualization

So Hyper-V has a “synthetic device” mechanism designed on the assumption of virtualization. There are three characters.²

• VMBus: a logical communication channel between partitions. It provides high-speed inter-partition communication that uses shared memory.³
• VSP (Virtualization Service Provider): a service that resides on the root-partition side, receives device requests from the child, and bridges them to the device/backend stack on the root side. A request may reach a physical device, or it may be handled by a host-side backend such as a virtual disk or a virtual switch.
• VSC (Virtualization Service Consumer): a synthetic device driver that goes into the guest OS on the child-partition side. It sends requests to the VSP over VMBus.

Taking a guest OS storage request as an example, the flow looks like this. The guest app’s WriteFile descends the guest kernel’s I/O stack and, at the bottom, reaches the VSC (instead of real hardware). The VSC puts the request on VMBus and hands it to the VSP in the root partition, and the VSP flows the request into the root-side I/O stack. In a virtual-disk (VHDX) configuration, this write is handled as a write to a VHDX file on the host and eventually reaches the physical disk. This approach is called Enlightened I/O (I/O that is aware of virtualization), and it raises efficiency by bypassing the device-emulation layer.²

flowchart TB
    accTitle: I/O path for a synthetic device
    accDescr: An I/O request from an app in the child partition reaches the VSC through the guest kernel, crosses VMBus to the VSP in the root partition, and on the root-side I/O stack that the VSP bridges into it may reach a real device via a physical device driver, or it may be handled by a host-side backend such as a virtual disk or a virtual switch
    app["App in the child partition"] --> gk["Guest kernel I/O stack"]
    gk --> vsc["VSC (synthetic device driver)"]
    vsc -->|VMBus| vsp["VSP (root-partition side)"]
    vsp --> rio["Root-side I/O stack"]
    rio --> pdrv["Physical device driver"]
    rio --> hb["Host-side backend (virtual disk, virtual switch, and so on)"]
    pdrv --> dev["Physical device"]

Figure 10: With a synthetic device, guest I/O crosses to the root partition over VMBus and, through the root-side stack, reaches a real device or a host-side backend.

In other words, whether a VM’s disk I/O or networking is fast depends not only on the guest side but also on the state of the I/O stack and device drivers on the root-partition side. The reason host-side observation is indispensable when you investigate a VM performance problem is that the path actually goes through the host.

flowchart TB
    accTitle: Emulated devices versus synthetic devices
    accDescr: An emulated device imitates real hardware so inbox guest drivers work but is slow; a synthetic device is a purpose-built driver that assumes VMBus and is fast
    dev2{"Device shown to the child partition"} --> emu["Emulated device"]
    dev2 --> syn["Synthetic device"]
    emu -.-> emuP["Emulates real hardware; compatibility first"]
    emuP -.-> emuC["Needs intervention on every I/O; slow"]
    syn -.-> synP["Designed around VMBus; fast"]
    synP -.-> synC["Requires a matching driver in the guest"]

Figure 11: Of the two kinds of virtual device, emulated devices carry compatibility right after OS install, and synthetic devices carry performance in everyday use.

6. Why This Is Not Someone Else’s Problem, Even If You Never Use a VM

The structure so far may look like “a story for people who stand up VMs”. As the opening said, though, on current Windows the hypervisor is part of everyday life.

• Virtualization-based security (VBS). It uses the Windows hypervisor to create an isolated environment and houses security features there. On Windows 11 it is enabled by default when conditions such as a clean install on compatible hardware are met.¹ Details are in Part 2.
• WSL2. It runs a real Linux kernel inside a lightweight utility VM.⁶
• Windows Sandbox. A disposable Windows environment isolated by the hypervisor.⁷ Both are covered in Part 3.

flowchart TB
    accTitle: Everyday features that sit on the same hypervisor
    accDescr: Not only Hyper-V VMs but also VBS, which is enabled by default on devices that meet conditions such as a clean install, plus WSL2 and Windows Sandbox, are all built on the same Windows hypervisor
    base["Windows hypervisor"] --> f1["Hyper-V VMs"]
    base --> f2["VBS (enabled by default on clean installs and similar)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Why it runs even on PCs that never use a VM"]

Figure 12: There is one foundation, and this figure is where the assumption “virtualization is a story for people who use VMs” falls apart.

One more thing people often step on in practice is coexistence with third-party virtualization software. Because the hypervisor uses the CPU’s virtualization extensions exclusively, in an environment where the Windows hypervisor is running, VirtualBox and the like cannot run in the traditional way (the way that uses the CPU’s virtualization extensions itself). For this, a public API called Windows Hypervisor Platform is provided, and a third-party virtualization stack can run by sitting on top of the Windows hypervisor.⁸ Current VirtualBox/VMware can coexist with WSL2 thanks to this mechanism, but performance and feature differences that come with switching modes are sometimes observed as “after I enabled Hyper-V (or VBS), the virtualization software started behaving differently”.

flowchart TB
    accTitle: Who owns the CPU virtualization extensions, and the path for third-party virtualization software
    accDescr: While the Windows hypervisor is running it exclusively owns the CPU virtualization extensions; third-party virtualization software that supports WHP runs on top of it via the Windows Hypervisor Platform, while implementations that do not support WHP cannot run or are feature-limited
    vt["CPU virtualization extensions (VT-x/AMD-V)"] --> hvon{"Is the Windows hypervisor running?"}
    hvon -->|No| direct["Third-party software can use it directly"]
    hvon -->|Yes| own["The hypervisor has exclusive use"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP-capable third-party software runs on top of it"]
    third -.-> nowhp["Non-capable implementations cannot run, or are limited"]

Figure 13: There is one owner of the virtualization extensions, and the only third-party software that can coexist while the hypervisor is running is software that supports the public API (WHP).

7. See It for Yourself

You can confirm on your own machine whether a hypervisor is running.

First, a check you can run without administrator privileges.

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus returns the VBS running state as a number (2 is “Running”).⁹

One caution. All HypervisorPresent tells you is “whether we are running on top of a hypervisor”; it does not distinguish root from child. If you run it on Windows inside a VM, it still returns True, as a child partition. If it is True on Windows on a physical PC, that Windows is inside the root partition — you read it together with the execution environment.

Next, the classic from a Command Prompt.

systeminfo

Look at “Hyper-V Requirements” at the end of the output. On a machine where the hypervisor is not yet running, the individual requirements — SLAT support, whether virtualization extensions are enabled, and so on — are listed. On a machine where the hypervisor is already running, instead of the requirements you get a single line: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ That one line is therefore a statement that your Windows is running on top of some hypervisor. As with HypervisorPresent, you need to read it as “inside the root partition” on a physical PC, or “as a child partition” inside a VM.

Even if every systeminfo requirement is “Yes”, that only means the hardware side is ready. The Hyper-V feature itself is available on Pro, Enterprise, and Education editions, and is not on Home.¹⁰

In the GUI, check the “Virtualization-based security” row under “System Summary” in msinfo32. Note that “Virtualization: Enabled” in Task Manager’s CPU pane only shows whether virtualization extensions are enabled in firmware, which is separate information from whether a hypervisor is running.

flowchart TB
    accTitle: How to check whether the hypervisor is running
    accDescr: If systeminfo says a hypervisor has been detected you are running on a hypervisor (inside the root partition on a physical PC); if the Hyper-V Requirements list appears it is not running yet so you check every requirement such as SLAT, VM Monitor Mode Extensions, and DEP, but all Yes only means the hardware side is ready and the Hyper-V feature also has an edition requirement
    start2["Run systeminfo"] --> q1{"Requirements field?"}
    q1 -->|Detected| running["Hypervisor is running"]
    running -.-> runN["Inside the root"]
    runN -.-> runN2["on a physical PC"]
    q1 -->|Listed| notyet["Not running yet"]
    notyet --> q2{"All requirements Yes?"}
    q2 -->|All Yes| can["Hardware side is ready"]
    can -.-> ed["Needs Pro / Ent / Edu"]
    q2 -->|Some No| uefi["Check UEFI/BIOS items"]

Figure 14: The “Hyper-V Requirements” field in systeminfo doubles as both a running-state check and a prerequisite check.

8. Three Misreadings to Avoid in Practice

8.1. “We haven’t enabled Hyper-V, so virtualization has nothing to do with our PCs”

Even if you have not enabled the Hyper-V feature (the management tools and the VM execution environment), the Windows hypervisor is running if VBS is enabled. When you investigate a driver compatibility problem, a performance test, or trouble with third-party virtualization software, check HypervisorPresent and the VBS running state — not whether the feature is enabled.

8.2. “Task Manager says ‘Virtualization: Enabled’, so Hyper-V is running”

That display is about the firmware setting (whether VT-x/AMD-V is available). Judge the hypervisor’s running state from “A hypervisor has been detected” in systeminfo. Conversely, if Task Manager says “Disabled”, you cannot enable Hyper-V or WSL2 either, so check the UEFI/BIOS settings first.

flowchart TB
    accTitle: Three checks that are easy to confuse
    accDescr: Task Manager's Virtualization field shows the firmware setting, the Windows Features list shows the install state, and systeminfo or HypervisorPresent shows the running state; each answers a different question
    q3{"Which question?"}
    q3 --> fw{"Firmware or Windows?"}
    q3 --> c3["Is hypervisor running?"]
    fw --> a3["Firmware extensions?"]
    fw --> b3["Hyper-V feature on?"]
    a3 -.-> a3t["Task Manager CPU pane"]
    b3 -.-> b3t["Windows Features UI"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

Figure 15: These are three independent questions, and inferring the other two from any one display is a misreading.

8.3. “If the VM is slow, it is a guest-OS problem”

Synthetic-device I/O crosses VMBus to the VSP in the root partition and goes through the root-side device/backend stack (physical drivers, plus virtual-switch and virtual-disk processing). If you only watch counters inside the guest, you will not find a bottleneck that sits in host-side storage or a NIC. The principle for VM performance problems is to observe from both sides: the guest and the host (the root partition).

9. Summary

• When you enable Hyper-V, the hypervisor runs directly on the hardware and the host Windows runs as the root partition.²
• The guest OS kernel keeps running at ring 0, and only operations configured as intercepts, plus exceptions, are handed to the hypervisor via a VM Exit. Ordinary memory accesses pass through via SLAT translation.
• Only the root partition holds physical device drivers and the virtualization management stack, and it creates child partitions via hypercalls.²
• Memory becomes a two-level translation of GVA→GPA→SPA, and the second level is handled in hardware by SLAT (EPT/RVI). Current Hyper-V requires SLAT.⁴
• Device I/O is dominated by the synthetic-device path VSC→VMBus→VSP, and performance also depends on the host-side I/O stack.²
• On Windows 11, because VBS is enabled by default on devices that meet conditions such as a clean install, it is not unusual for the hypervisor to be running even on a PC that never uses a VM.¹ You can confirm the running state with HypervisorPresent and systeminfo.

The big picture of Part 1 condenses into this one diagram.

flowchart TB
    accTitle: The big picture of Part 1
    accDescr: The hypervisor sits under the root partition and child partitions; CPUs are allocated by scheduling virtual processors (VM Exits only on configured intercepts and exceptions), memory is mediated by two-level SLAT translation, synthetic-device I/O is forwarded over VMBus and handled by the root partition's VSP, and emulated devices and Discrete Device Assignment have other paths
    up["Root + child partitions"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: schedule VPs"]
    hvS --> memS["Memory: SLAT"]
    cpuS -.-> cpuN["VM Exit on intercept"]
    memS -.-> memN["Two-level translation"]
    memS ~~~ devS
    devS["Devices: VMBus I/O"] --> vspS["Root-side VSP handles"]
    devS -.-> devN["Emulated / DDA: other"]

Figure 16: CPU scheduling and memory translation are handled directly by the hypervisor (VM Exits only on intervention), and synthetic-device I/O is mediated by the root partition (the VSP) on the far side of VMBus.

Continued in Part 2, “Memory Even the Kernel Cannot See — VBS, HVCI, and Credential Guard”.

We pick up this article’s through-line — that the hypervisor holds the SLAT translation tables — and follow how Windows creates “memory that neither an administrator nor the kernel can read”.

Related Articles

• The Depths of Windows Memory (Part 1) — The Moment a Virtual Address Becomes Physical RAM: A Page Fault from Start to Finish
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• How to Speed Up App Validation with Windows Sandbox
• Windows Processor Scheduling Settings - Background Services and P/E Cores

Related Consulting Areas

KomuraSoft LLC handles validation-environment design for Windows applications, performance investigations in virtualized environments, and analysis of driver and peripheral compatibility problems.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Migration
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

When you enable Hyper-V, where does the host Windows actually run?

The hypervisor takes direct control of how physical CPUs and memory are allocated, and the host Windows runs inside a special partition called the root partition. Control of physical devices is normally handled by drivers on the root-partition side. The root partition holds the device drivers and the virtualization management stack, but ownership of the physical CPUs belongs to the hypervisor.

Does Task Manager's "Virtualization: Enabled" mean that Hyper-V is running?

No. That display shows whether the CPU's virtualization extensions (Intel VT-x/AMD-V) are enabled in firmware. To see whether a hypervisor is actually running, look for "A hypervisor has been detected" in systeminfo, or check Win32_ComputerSystem.HypervisorPresent.

Why is the hypervisor running even though I have never created a VM?

On Windows 11, virtualization-based security (VBS) is enabled by default on devices that meet the conditions — a clean install on compatible hardware, for example — and VBS is built on the Windows hypervisor. The same is true if you use WSL2 or Windows Sandbox. It is not unusual for the hypervisor to be running with no connection to anyone using VMs.

What is SLAT, and why is it required for Hyper-V?

SLAT (Second Level Address Translation) is the mechanism by which the CPU translates guest physical addresses into actual physical addresses; Intel EPT and AMD RVI are the implementations. Without it the hypervisor would have to maintain the translation tables in software, which is not realistic from a performance standpoint, so current Hyper-V treats it as a hard requirement.

If I enable Hyper-V, will VirtualBox and VMware stop working?

Because the hypervisor uses the CPU's virtualization extensions exclusively, a third-party hypervisor cannot run in the traditional way. Current VirtualBox and VMware, however, have a mode that runs on top of the Windows hypervisor (via the Windows Hypervisor Platform), so recent versions of each can coexist.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.