Глубины виртуализации Windows (часть 1) — где на самом деле работает ваш Windows: гипервизор и разделы

Вы ни разу не создавали виртуальную машину, а в сведениях о системе (msinfo32) в Windows 11 стоит «Безопасность на основе виртуализации: выполняется». Что это значит?

На этом ПК хостовый Windows уже работает поверх гипервизора. В Windows 11 VBS по умолчанию включают на конфигурациях, которые удовлетворяют условиям — например, чистая установка на совместимое оборудование, и эта основа используется, даже если вы никогда не создаёте ВМ.¹ WSL2 и Windows Sandbox пользуются тем же гипервизором Windows.

Часть 1 объясняет где оказывается хостовый Windows, когда включают Hyper-V, через разделение ролей по ЦП, памяти и вводу-выводу устройств. Это выпуск, который сначала выправляет взгляд «ПО виртуальных машин сидит поверх Windows».

«Глубины виртуализации Windows» — все 3 части

Один и тот же гипервизор Windows смотрим в порядке основа → изоляция безопасности → применение к лёгким ВМ.

Предпосылки этой статьи

Как читать эту статью

Карта знаний ниже — список отношений. Если читаете впервые, идите по тексту с главы 1, общая картина.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

1. Сначала вывод

Когда слышат Hyper-V, могут представить «ПО виртуальных машин, которое сидит поверх Windows». Фактическая структура обратная.

С момента, когда вы включаете Hyper-V и перезагружаетесь, физическими ЦП и памятью управляет гипервизор, а хостовый Windows работает поверх него как первый привилегированный раздел — «корневой раздел».

Гипервизор — тонкий программный слой между оборудованием и ОС. Он создаёт изолированные среды выполнения, называемые «разделами», и посредничает доступ к оборудованию.² Хостовый Windows идёт в корневой раздел; ВМ — в дочерние.

Корневой раздел обрабатывают особо (у него прямой доступ к физическим устройствам и стек управления), но в том смысле, что он не управляет физическими ЦП напрямую, он стоит в той же позиции, что и дочерний раздел.

flowchart TB
    accTitle: Общая структура после включения Hyper-V
    accDescr: Гипервизор сидит непосредственно на физическом оборудовании, а над ним — корневой раздел, в котором хостовый Windows, и дочерние разделы, в которых ВМ
    hw["Физическое оборудование"] --> hv["Гипервизор"]
    hv --> root["Корневой раздел (хостовый Windows)"]
    hv --> child1["Дочерние разделы (ВМ)"]
    root -.-> stack["Держит стек управления виртуализацией и драйверы устройств"]

Рис. 1: Hyper-V — не «ПО виртуальных машин поверх Windows», а слой, который уходит под Windows, и хостовая ОС сама работает внутри корневого раздела.

Можно подумать: «До и после включения ничего не чувствуется иначе, неужели такая большая инверсия действительно произошла?» Произошла. Именно поэтому эта структура обычно остаётся незамеченной. В этой статье разбираем одну эту схему с трёх сторон: ЦП, память и ввод-вывод устройств.

2. Со стороны ЦП — ещё одна привилегия ниже колец

В разборе ЦП различаем кольца, которые отделяют ядро от приложений, и режимы выполнения, которые отделяют гипервизор от гостей. Вопрос этого раздела: гостевое ядро тоже работает в кольце 0, так почему нет столкновения?

2.1. Кратко о защите колец

У процессоров x64 есть уровни привилегий (кольца), и Windows работает в режиме ядра в кольце 0, а в пользовательском режиме — в кольце 3. Приложения не могут трогать оборудование напрямую, потому что привилегированные инструкции из кольца 3 выполнять нельзя.

Как тогда безопасно разместить на одном физическом ЦП несколько ядер ОС, каждое из которых работает в кольце 0? Каждое ядро написано из допущения «я управляю ЦП». Дать кольцо 0 всем — они столкнутся; отказать — они не заработают.

flowchart TB
    accTitle: Проблема нескольких ядер ОС, которые требуют кольцо 0
    accDescr: И хостовое, и гостевое ядро написаны из допущения полной власти в кольце 0, поэтому одной классической лестницы колец недостаточно, чтобы безопасно разместить их на одном физическом ЦП
    k1["Хостовое ядро (считает, что кольцо 0)"] --> want["Требует управление физическим ЦП"]
    k2["Гостевое ядро (считает, что кольцо 0)"] --> want
    want --> conflict["Одни классические кольца это не примиряют"]
    conflict --> need["Нужен посредник выше кольца 0"]

Рис. 2: Лестница колец строилась из допущения одной ОС, поэтому нескольким ядрам нужна ещё одна привилегия выше неё.

2.2. Расширения виртуализации — режим, зарезервированный для гипервизора

Эту задачу решают расширения виртуализации ЦП (Intel VT-x/AMD-V). Hyper-V требует процессор с этой функцией.² Расширения виртуализации добавляют на оси, отдельной от классических колец, «режим выполнения для гипервизора» и «режим выполнения для гостей». Это привилегия даже сильнее кольца 0, её иногда называют «кольцо −1».

• Гостевое ядро продолжает работать в кольце 0, как раньше. Переписывать его не нужно.
• Однако это кольцо 0 — «кольцо 0 внутри гостевого режима», и оно не управляет физическим ЦП целиком.
• Когда гость попадает на операцию, которая требует вмешательства гипервизора (инструкция, настроенная как перехват, либо исключение или нарушение), ЦП автоматически передаёт управление гипервизору (VM Exit). Когда гипервизор закончил обработку, он возвращается к гостю (VM Entry). Обычные обращения к памяти проходят напрямую без VM Exit, пока трансляция SLAT успешна.

Прерывания устроены так же. Разделы не трогают физические процессоры напрямую; гипервизор принимает прерывания и направляет их каждому разделу.²

flowchart TB
    accTitle: Поток гостевого выполнения и VM Exit
    accDescr: Гостевое ядро и приложения работают в кольце 0 и кольце 3 в гостевом режиме; обычные обращения к памяти проходят через трансляцию SLAT, а операции, настроенные как перехваты, и исключения вызывают VM Exit, который передаёт управление гипервизору, и тот после обработки возвращается к гостю через VM Entry
    guest["Выполнение в гостевом режиме (включая ядро кольца 0)"] --> op{"Операция, которой нужно вмешательство? (настроенные перехваты/исключения)"}
    op -->|Нет| cont["Продолжать выполнение как есть"]
    op -->|Да| exitEv["VM Exit (ЦП передаёт управление)"]
    exitEv --> hvp["Гипервизор обрабатывает"]
    hvp --> entry["Вернуться к гостю через VM Entry"]
    entry --> guest

Рис. 3: Гостевая ОС продолжает работать в кольце 0 без переписывания, и ЦП вызывает гипервизор только когда нужно.

Этот круговой путь очень похож на поток, который мы разбирали в серии про память: «войти в ядро по ошибке страницы, затем вернуться к той же инструкции». ЦП берёт управление через механизм исключения или перехода, даёт решить менеджеру более высокого уровня и затем возвращается. В глубинах Windows эта форма появляется снова и снова.

2.3. Тип 1 и тип 2 — разница в том, где он сидит

Гипервизоры в целом делят на тип 1 (bare-metal), который работает непосредственно на оборудовании, и тип 2 (hosted), который работает поверх хостовой ОС. Hyper-V — тип 1.³ VirtualBox и VMware Workstation (когда работают самостоятельно) относят к типу 2.

Услышав «тип 1», склонны представить «конфигурацию только для сервера без хостовой ОС», но Hyper-V другой. Хостовый Windows не исчезает; он «переезжает» в корневой раздел. Когда вы включаете Hyper-V и перезагружаетесь, при загрузке сначала стартует гипервизор, а хостовый Windows затем поднимается как корневой раздел поверх него.

flowchart TB
    accTitle: Разница между гипервизорами типа 1 и типа 2
    accDescr: В типе 2 хостовая ОС сидит на оборудовании, а гипервизор и ВМ — на хостовой ОС; в типе 1 Hyper-V гипервизор сидит непосредственно на оборудовании, а хостовая ОС сама уходит в корневой раздел над ним
    subgraph t2 ["Тип 2 (hosted)"]
        hw2["Оборудование"] --> hostos["Хостовая ОС"]
        hostos --> hv2["Гипервизор"]
        hv2 --> vm2["ВМ"]
    end
    subgraph t1 ["Тип 1 (Hyper-V)"]
        hw1["Оборудование"] --> hv1["Гипервизор"]
        hv1 --> root1["Корневой раздел (хостовая ОС)"]
        hv1 --> vm1["ВМ"]
    end
    vm2 ~~~ hw1

Рис. 4: В типе 2 гипервизор сидит на хостовой ОС, а в типе 1 Hyper-V порядок обратный, и хостовая ОС сама сидит на слое на одну ступень ниже.

На шкале времени загрузки изменение, которое происходит при включении, выглядит так.

flowchart TB
    accTitle: Порядок загрузки после включения Hyper-V
    accDescr: После включения питания сначала при загрузке стартует гипервизор, затем хостовый Windows поднимается как корневой раздел поверх него, а ВМ, VBS и прочее стартуют после этого
    poweron["Включение питания и старт загрузки"] --> bhv["Сначала стартует гипервизор"]
    bhv --> broot["Хостовый Windows стартует как корневой раздел"]
    broot --> blater["ВМ, VBS, WSL2 и так далее стартуют поверх этого"]
    broot -.-> feel["Для пользователя ощущения не меняются"]

Рис. 5: Инверсия порядка уже закончена до появления экрана входа, и хостовая ОС с самого начала поднимается на гипервизоре.

3. Разделы — единица изоляции

Приглядимся к разделам, «ящикам» общей картины. Здесь нужно отделить посредничество ЦП и памяти, которым гипервизор занимается напрямую, от ввода-вывода устройств, которым обычно посредничает корневой раздел.

3.1. Роли, которые есть только у корневого раздела

Раздел — логическая единица изоляции, которую даёт гипервизор.² Не все разделы равны. Есть вещи, которые есть только у корневого.

Прямой доступ к физическим устройствам

Драйверы устройств для дисков, NIC, GPU и подобных живут в Windows внутри корневого раздела, а не в гипервизоре. У Hyper-V на Windows Server есть конфигурация, которая назначает конкретное устройство PCIe напрямую дочернему разделу (Discrete Device Assignment); в этом случае корневой отпускает это устройство (на клиентском Windows этого нет).⁴

Стек управления виртуализацией

VMMS (Virtual Machine Management Service), которая управляет созданием, запуском и остановкой ВМ, и рабочий процесс, который стартует на каждую ВМ (vmwp.exe), работают в пользовательском режиме в корневом разделе.⁵ Это часть функций управления ВМ Hyper-V, поэтому их может не быть на хосте, где гипервизор работает только ради VBS или WSL2.

Право создавать дочерние разделы

Корневой раздел создаёт дочерние через API гипервызовов (интерфейс вызова в гипервизор).²

У этой схемы есть причина. Если положить каждый драйвер устройства в сам гипервизор, гипервизор станет огромным, и число ошибок и точек входа атаки вырастет. Гипервизор ограничивает себя минимальной работой посредничества ЦП и памяти и оставляет заботу об устройствах Windows в корневом разделе. Это разделение ролей и держит Hyper-V тонким.

flowchart TB
    accTitle: Разделение ролей между корневым разделом и дочерними
    accDescr: Корневой раздел держит стек управления виртуализацией и драйверы физических устройств и создаёт дочерние разделы через гипервызовы; дочерний раздел в обычной конфигурации видит только виртуальные устройства, а при Discrete Device Assignment на Windows Server обращается к назначенному устройству напрямую
    subgraph rootp ["Корневой раздел"]
        vmms["VMMS и рабочие процессы"]
        drv["Драйверы физических устройств"]
    end
    subgraph childp ["Дочерний раздел"]
        gos["Гостевая ОС"]
        vdev["В обычной конфигурации видны только виртуальные устройства"]
    end
    vmms -->|Создавать и управлять через гипервызовы| childp
    hv2["Гипервизор (ограничивает себя посредничеством ЦП и памяти)"] --- rootp
    hv2 --- childp

Рис. 6: То, что драйверы устройств и стек управления лежат на стороне корневого раздела, и держит сам гипервизор тонким.

3.2. Мир глазами дочернего раздела

Гостевая ОС в дочернем разделе в обычной конфигурации виртуальных устройств не видит физическое оборудование напрямую (единственное исключение — устройство, назначенное через Discrete Device Assignment на Windows Server, как в предыдущем разделе). Что она видит — виртуальные процессоры, пространство памяти, которое кажется своим, и виртуальные устройства. Запросы к виртуальным устройствам пересылаются в корневой раздел через VMBus или гипервизор.²

Распределение процессорного времени и трансляцию памяти через SLAT, напротив, гипервизор ведёт напрямую, не через корневой. Чем посредничает корневой — ввод-вывод устройств, а не каждый физический ресурс.

flowchart TB
    accTitle: Мир глазами дочернего раздела
    accDescr: Что видит гостевая ОС — виртуальные процессоры, пространство памяти, частное для раздела, и виртуальные устройства; запросы к виртуальным устройствам пересылаются в корневой раздел через VMBus и подобное, процессорное время и трансляцию памяти ведёт гипервизор напрямую, а в конфигурации Discrete Device Assignment на Windows Server только назначенные устройства доступны напрямую
    gos2["Гостевая ОС в дочернем разделе"] --> vcpu["Виртуальные процессоры"]
    gos2 --> gpa2["Частное пространство памяти"]
    gos2 --> vdev2["Виртуальные устройства"]
    vdev2 -->|"Через VMBus и подобное"| rootx["Пересылается в корневой раздел"]
    gos2 -.->|Не видно напрямую| phys2["Физические ЦП, ОЗУ и настоящие устройства"]
    phys2 -.-> dda2["В конфигурации DDA (Windows Server) только назначенные устройства доступны напрямую"]
    vcpu ~~~ phys2

Рис. 7: В обычной конфигурации виртуальных устройств всё, что видит гость, — виртуальное окно, и путь к физическому идёт через посредника; только устройство, назначенное через DDA на Windows Server, — исключение.

Здесь важно, что для приложения, работающего на хостовом Windows, эта структура почти прозрачна. Вызовы Win32 API и обработка ошибок страницы по-прежнему обрабатываются ядром Windows внутри корневого раздела, как раньше. Гипервизор вмешивается только когда попадается настроенный перехват или исключение.

4. Со стороны памяти — трансляция адресов получает ещё один уровень

В памяти отделяем адрес, который гость считает «физическим», от фактического места в ОЗУ. Держите в уме порядок GVA → GPA → SPA и кто управляет каждой трансляцией.

4.1. Три вида адреса

В части 1 серии про память мы разбирали поток, которым виртуальный адрес транслируется через таблицу страниц в физический («Момент, когда виртуальный адрес становится физической ОЗУ»). В виртуализованной среде под этой трансляцией добавляется ещё один уровень, и видов адреса три.

Гостевая ОС транслирует GVA в GPA своей таблицей страниц. GPA, который видит гость, однако, не настоящий физический адрес; это частное пространство памяти, выделенное каждому разделу.² Отображение GPA на фактическое место в ОЗУ (SPA) — работа гипервизора.

4.2. SLAT — двухуровневая трансляция в оборудовании

Если эту трансляцию второго уровня делать только программно, гипервизору пришлось бы отслеживать каждое обновление гостевой таблицы страниц по одному, что нереалистично по производительности. Поэтому ЦП даёт механизм, который обходит таблицы трансляции второго уровня аппаратно. Это SLAT (Second Level Address Translation); реализации — Intel EPT (Extended Page Tables) и AMD RVI.

Актуальный Hyper-V требует 64-разрядный процессор с SLAT.⁴

flowchart TB
    accTitle: Двухуровневая трансляция адресов через SLAT
    accDescr: Гостевой виртуальный адрес транслируется в гостевой физический таблицей страниц гостевой ОС, затем дальше транслируется в системный физический адрес SLAT, которым управляет гипервизор, и доходит до фактической ОЗУ
    gva["Гостевой виртуальный адрес (GVA)"] -->|Таблица страниц гостевой ОС| gpa["Гостевой физический адрес (GPA)"]
    gpa -->|"SLAT (таблицы трансляции EPT/RVI)"| spa["Системный физический адрес (SPA)"]
    spa --> ram["Физическая ОЗУ"]
    gpa -.-> note["Слой, который гость лишь считает физическим"]

Рис. 8: Под таблицей страниц гостя сидит ещё одна таблица трансляции, которой управляет гипервизор, и ЦП обходит обе аппаратно.

SLAT — не функция, которая существует только ради эффективности выполнения ВМ. VBS, который мы увидим в части 2, использует свойство «можно иметь разную таблицу трансляции SLAT на каждый уровень привилегий» как материал для границы безопасности. Причина, по которой можно создать память, которую не видит даже ядро, в том, что гипервизор держит эту трансляцию второго уровня. Это сквозная линия всей серии, поэтому запомните одну точку: «менеджер таблиц трансляции — гипервизор».

5. Со стороны ввода-вывода устройств — VMBus и два вида устройств

Ввод-вывод устройств идёт другим путём, чем процессорное время и трансляция памяти. Сравниваем метод, который имитирует настоящее оборудование, с методом, который использует путь, рассчитанный на виртуализацию.

5.1. Пределы эмулируемых устройств

Классический способ показать устройство дочернему разделу — полностью имитировать настоящее оборудование (например, старый контроллер IDE) программно. Совместимость высокая, потому что штатные драйверы гостевой ОС работают как есть, но VM Exit происходит каждый раз, когда гость попадает на порт ввода-вывода, и производительность не масштабируется.

flowchart TB
    accTitle: Почему ввод-вывод к эмулируемому устройству медленный
    accDescr: Каждый раз, когда гость оперирует портом ввода-вывода, управление переходит на сторону гипервизора через VM Exit, устройство имитируется программно, и управление возвращается к гостю, поэтому круговой путь повторяется и медленный
    gio["Гость оперирует портом ввода-вывода"] --> vex["Происходит VM Exit"]
    vex --> emu2["Устройство имитируется программно"]
    emu2 --> back["Вернуться к гостю через VM Entry"]
    back -->|Повторяется на следующей операции с портом| gio

Рис. 9: Этот круговой путь выполняется много раз за одним обращением к диску, и цена совместимости платится производительностью.

5.2. VMBus и VSP/VSC — быстрый путь, рассчитанный на виртуализацию

Поэтому у Hyper-V есть механизм «синтетического устройства», спроектированный из допущения виртуализации. Игроков трое.²

• VMBus: логический канал связи между разделами. Даёт высокоскоростной межраздельный обмен, который использует разделяемую память.³
• VSP (Virtualization Service Provider): служба, которая живёт на стороне корневого раздела, принимает запросы устройств от дочернего и мостит их к стеку устройства/бэкенда на стороне корневого. Запрос может дойти до физического устройства или обрабатываться хостовым бэкендом вроде виртуального диска или виртуального коммутатора.
• VSC (Virtualization Service Consumer): драйвер синтетического устройства, который входит в гостевую ОС на стороне дочернего раздела. Он отправляет запросы VSP по VMBus.

Пример: как WriteFile гостя доходит до хоста

Запрос хранения от гостевой ОС идёт в таком порядке.

1. WriteFile гостевого приложения спускается по стеку ввода-вывода гостевого ядра.
2. Внизу он доходит до VSC вместо настоящего оборудования.
3. VSC кладёт запрос на VMBus и отдаёт его VSP в корневом разделе.
4. VSP проводит запрос в стек ввода-вывода на стороне корневого. В конфигурации виртуального диска (VHDX) он обрабатывается как запись в файл VHDX на хосте и в итоге доходит до физического диска.

Этот подход называют Enlightened I/O (ввод-вывод, который знает о виртуализации), и он повышает эффективность, обходя слой эмуляции устройств.²

flowchart TB
    accTitle: Путь ввода-вывода синтетического устройства
    accDescr: Запрос ввода-вывода от приложения в дочернем разделе доходит до VSC через гостевое ядро, пересекает VMBus к VSP в корневом разделе и в стеке ввода-вывода на стороне корневого, в который VSP мостит, может дойти до настоящего устройства через драйвер физического устройства или обрабатываться хостовым бэкендом вроде виртуального диска или виртуального коммутатора
    app["Приложение в дочернем разделе"] --> gk["Стек ввода-вывода гостевого ядра"]
    gk --> vsc["VSC (драйвер синтетического устройства)"]
    vsc -->|VMBus| vsp["VSP (сторона корневого раздела)"]
    vsp --> rio["Стек ввода-вывода на стороне корневого"]
    rio --> pdrv["Драйвер физического устройства"]
    rio --> hb["Хостовый бэкенд (виртуальный диск, виртуальный коммутатор и так далее)"]
    pdrv --> dev["Физическое устройство"]

Рис. 10: С синтетическим устройством гостевой ввод-вывод пересекает к корневому разделу по VMBus и через стек на стороне корневого доходит до настоящего устройства или хостового бэкенда.

Иными словами, быстр ли дисковый ввод-вывод или сеть ВМ, зависит не только от стороны гостя, но и от состояния стека ввода-вывода и драйверов устройств на стороне корневого раздела. Причина, по которой наблюдение со стороны хоста необходимо, когда расследуете проблему производительности ВМ, в том, что путь действительно идёт через хост.

flowchart TB
    accTitle: Эмулируемые устройства против синтетических
    accDescr: Эмулируемое устройство имитирует настоящее оборудование, поэтому штатные драйверы гостя работают, но оно медленное; синтетическое устройство — драйвер, рассчитанный на VMBus, и оно быстрое
    dev2{"Устройство, показанное дочернему разделу"} --> emu["Эмулируемое устройство"]
    dev2 --> syn["Синтетическое устройство"]
    emu -.-> emuP["Имитирует настоящее оборудование; сначала совместимость"]
    emuP -.-> emuC["Нужно вмешательство на каждый ввод-вывод; медленно"]
    syn -.-> synP["Спроектировано вокруг VMBus; быстро"]
    synP -.-> synC["Требует соответствующего драйвера в госте"]

Рис. 11: Из двух видов виртуальных устройств эмулируемые несут совместимость сразу после установки ОС, а синтетические — производительность в повседневном использовании.

6. Почему это не чужая проблема, даже если вы никогда не пользуетесь ВМ

6.1. VBS, WSL2 и Sandbox пользуются той же основой

Структура до сих пор может выглядеть как «история для тех, кто поднимает ВМ». Как сказано в начале, однако, на актуальном Windows гипервизор — часть повседневности.

• Безопасность на основе виртуализации (VBS). Пользуется гипервизором Windows, чтобы создать изолированную среду, и размещает там функции безопасности. В Windows 11 она включена по умолчанию, когда выполнены условия вроде чистой установки на совместимое оборудование.¹ Подробности — в части 2.
• WSL2. Запускает настоящее ядро Linux внутри лёгкой служебной ВМ.⁶
• Windows Sandbox. Одноразовая среда Windows, изолированная гипервизором.⁷ Оба — в части 3.

flowchart TB
    accTitle: Повседневные функции, которые сидят на том же гипервизоре
    accDescr: Не только ВМ Hyper-V, но и VBS, который по умолчанию включён на устройствах, удовлетворяющих условиям вроде чистой установки, плюс WSL2 и Windows Sandbox — все построены на одном гипервизоре Windows
    base["Гипервизор Windows"] --> f1["ВМ Hyper-V"]
    base --> f2["VBS (по умолчанию на чистых установках и подобных)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Почему он работает даже на ПК, которые никогда не пользуются ВМ"]

Рис. 12: Основа одна, и на этой схеме разваливается допущение «виртуализация — история для тех, кто пользуется ВМ».

6.2. Сосуществование со сторонним ПО виртуализации

Ещё одна вещь, с которой часто сталкиваются на практике, — сосуществование со сторонним ПО виртуализации. Потому что гипервизор использует расширения виртуализации ЦП эксклюзивно, в среде, где работает гипервизор Windows, VirtualBox и подобные не могут работать прежним способом (способом, который сам использует расширения виртуализации ЦП).

Для этого дан открытый API Windows Hypervisor Platform, и сторонний стек виртуализации может работать, сидя поверх гипервизора Windows.⁸ Актуальные VirtualBox/VMware могут сосуществовать с WSL2 благодаря этому механизму, но различия производительности и функций, которые приходят со сменой режима, иногда наблюдают как «после того как я включил Hyper-V (или VBS), ПО виртуализации стало вести себя иначе».

flowchart TB
    accTitle: Кто владеет расширениями виртуализации ЦП и путь для стороннего ПО виртуализации
    accDescr: Пока работает гипервизор Windows, он эксклюзивно владеет расширениями виртуализации ЦП; стороннее ПО виртуализации, которое поддерживает WHP, работает поверх него через Windows Hypervisor Platform, а реализации, которые WHP не поддерживают, не могут работать или ограничены по функциям
    vt["Расширения виртуализации ЦП (VT-x/AMD-V)"] --> hvon{"Работает ли гипервизор Windows?"}
    hvon -->|Нет| direct["Стороннее ПО может использовать их напрямую"]
    hvon -->|Да| own["Гипервизор пользуется эксклюзивно"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Стороннее ПО с WHP работает поверх него"]
    third -.-> nowhp["Реализации без поддержки не работают или ограничены"]

Рис. 13: Владелец расширений виртуализации один, и единственное стороннее ПО, которое может сосуществовать, пока работает гипервизор, — ПО, которое поддерживает открытый API (WHP).

7. Посмотрите сами

На своём ПК можно проверить, работает ли гипервизор.

7.1. Проверка гипервизора и VBS через PowerShell

Сначала проверка, которую можно запустить без прав администратора.

# Работаем ли поверх гипервизора
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# Состояние VBS (тот же источник, что и «Безопасность на основе виртуализации» в msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus возвращает состояние работы VBS числом (2 — «выполняется»).⁹

Одна оговорка. Всё, что говорит HypervisorPresent, — «работаем ли мы поверх гипервизора»; корневой от дочернего он не отличает. Если запустить его на Windows внутри ВМ, он всё равно вернёт True — как дочерний раздел. Если True на Windows на физическом ПК, этот Windows внутри корневого раздела; читайте вместе со средой выполнения.

7.2. Отличить «работает» от «предпосылки» в systeminfo

Далее классика из командной строки.

systeminfo

Смотрите «Требования Hyper-V» в конце вывода. На машине, где гипервизор ещё не работает, отдельные требования вроде поддержки SLAT и того, включены ли расширения виртуализации, перечислены по одному. На машине, где гипервизор уже работает, вместо требований одна строка: «Обнаружен гипервизор. Возможности, необходимые для Hyper-V, отображаться не будут.»⁴

Эта одна строка поэтому утверждение, что ваш Windows работает поверх какого-то гипервизора. Как и с HypervisorPresent, нужно читать как «внутри корневого раздела» на физическом ПК или «как дочерний раздел» внутри ВМ.

Даже если каждое требование systeminfo — «Да», это значит только, что сторона оборудования готова. Сама функция Hyper-V доступна в редакциях Pro, Enterprise и Education и отсутствует в Home.¹⁰

7.3. Когда проверяете на экране, различайте, какой пункт проверяете

В графическом интерфейсе смотрите строку «Безопасность на основе виртуализации» в «Сводке системы» в msinfo32. Заметьте, что «Виртуализация: включено» на панели ЦП Диспетчера задач показывает только включены ли расширения виртуализации в прошивке, что отдельно от того, работает ли гипервизор.

flowchart TB
    accTitle: Как проверить, работает ли гипервизор
    accDescr: Если systeminfo говорит, что обнаружен гипервизор, вы работаете на гипервизоре (внутри корневого раздела на физическом ПК); если появляется список требований Hyper-V, он ещё не работает, поэтому проверяйте каждое требование вроде SLAT, расширений режима монитора ВМ и DEP, но все Да значит только, что сторона оборудования готова, а у функции Hyper-V ещё есть требование редакции
    start2["Запустить systeminfo"] --> q1{"Что показывает поле требований Hyper-V?"}
    q1 -->|Обнаружен гипервизор| running["Гипервизор работает (внутри корневого на физическом ПК)"]
    q1 -->|Требования перечислены| notyet["Гипервизор ещё не работает"]
    notyet --> q2{"Все требования Да?"}
    q2 -->|Все Да| can["Сторона оборудования готова"]
    can -.-> ed["Hyper-V ещё нужна Pro/Enterprise/Education"]
    q2 -->|Часть Нет| uefi["Проверьте соответствующие пункты в UEFI/BIOS и подобном"]

Рис. 14: Поле «Требования Hyper-V» в systeminfo служит и проверкой состояния работы, и проверкой предпосылок.

8. Три ложных прочтения, которых избегать на практике

8.1. «Мы не включали Hyper-V, значит виртуализация к нашим ПК не относится»

Даже если вы не включали функцию Hyper-V (средства управления и среду выполнения ВМ), гипервизор Windows работает, если включён VBS. Когда расследуете проблему совместимости драйвера, тест производительности или неприятности со сторонним ПО виртуализации, проверяйте HypervisorPresent и состояние работы VBS, а не то, включена ли функция.

8.2. «Диспетчер задач говорит «Виртуализация: включено», значит Hyper-V работает»

Это отображение — о настройке прошивки (доступны ли VT-x/AMD-V). Состояние работы гипервизора судите по «Обнаружен гипервизор» в systeminfo. Наоборот, если Диспетчер задач говорит «Отключено», вы не сможете включить и Hyper-V, и WSL2, поэтому сначала проверьте настройки UEFI/BIOS.

flowchart TB
    accTitle: Три проверки, которые легко перепутать
    accDescr: Поле виртуализации Диспетчера задач показывает настройку прошивки, список компонентов Windows — состояние установки, а systeminfo или HypervisorPresent — состояние работы; каждое отвечает на другой вопрос
    q3{"Что хотите узнать?"} --> a3["Включены ли расширения виртуализации в прошивке?"]
    q3 --> b3["Установлена ли функция Hyper-V?"]
    q3 --> c3["Работает ли гипервизор прямо сейчас?"]
    a3 -.-> a3t["Панель ЦП Диспетчера задач"]
    b3 -.-> b3t["Диалог компонентов Windows"]
    c3 -.-> c3t["systeminfo и HypervisorPresent"]

Рис. 15: Это три независимых вопроса, и выводить два остальных из любого одного отображения — ложное прочтение.

8.3. «Если ВМ медленная, это проблема гостевой ОС»

Ввод-вывод синтетического устройства пересекает VMBus к VSP в корневом разделе и идёт через стек устройства/бэкенда на стороне корневого (физические драйверы плюс обработка виртуального коммутатора и виртуального диска). Если смотреть только счётчики внутри гостя, узкое место, которое сидит в хостовом хранилище или NIC, вы не найдёте. Принцип для проблем производительности ВМ — наблюдать с обеих сторон: гость и хост (корневой раздел).

9. Итог

• Когда вы включаете Hyper-V, гипервизор работает непосредственно на оборудовании, а хостовый Windows — как корневой раздел.²
• Ядро гостевой ОС продолжает работать в кольце 0, и только операции, настроенные как перехваты, плюс исключения, передаются гипервизору через VM Exit. Обычные обращения к памяти проходят через трансляцию SLAT.
• Только корневой раздел держит драйверы физических устройств и стек управления виртуализацией и создаёт дочерние разделы через гипервызовы.²
• Память становится двухуровневой трансляцией GVA→GPA→SPA, и второй уровень ведётся аппаратно SLAT (EPT/RVI). Актуальный Hyper-V требует SLAT.⁴
• Во вводе-выводе устройств доминирует путь синтетического устройства VSC→VMBus→VSP, и производительность зависит также от стека ввода-вывода на стороне хоста.²
• В Windows 11, потому что VBS по умолчанию включён на устройствах, которые удовлетворяют условиям вроде чистой установки, не редкость, что гипервизор работает даже на ПК, который никогда не пользуется ВМ.¹ Состояние работы можно проверить через HypervisorPresent и systeminfo.

Общая картина части 1 сжимается в эту одну схему.

flowchart TB
    accTitle: Общая картина части 1
    accDescr: Гипервизор сидит под корневым разделом и дочерними разделами; ЦП распределяются планированием виртуальных процессоров (VM Exit только на настроенных перехватах и исключениях), память посредничает двухуровневая трансляция SLAT, ввод-вывод синтетических устройств пересылается по VMBus и обрабатывается VSP корневого раздела, а эмулируемые устройства и Discrete Device Assignment имеют другие пути
    up["Корневой раздел и дочерние разделы"] --> hvS["Гипервизор"]
    hvS --> cpuS["ЦП: распределяет виртуальные процессоры"]
    hvS --> memS["Память: двухуровневая трансляция через SLAT"]
    hvS --> devS["Устройства: синтетический ввод-вывод пересылается по VMBus"]
    cpuS -.-> cpuN["VM Exit только при вмешательстве"]
    devS --> vspS["Обрабатывается VSP на стороне корневого"]
    devS -.-> devN["Эмулируемые устройства и DDA идут другими путями"]

Рис. 16: Планирование ЦП и трансляцию памяти ведёт гипервизор напрямую (VM Exit только при вмешательстве), а ввод-вывод синтетических устройств посредничает корневой раздел (VSP) по ту сторону VMBus.

Продолжение — часть 2, «Память, которую не видит даже ядро — VBS, HVCI и Credential Guard».

Берём сквозную линию этой статьи — что гипервизор держит таблицы трансляции SLAT — и следим, как Windows создаёт «память, которую не прочитать ни администратору, ни ядру».

Похожие статьи

• Глубины памяти Windows (часть 1) — момент, когда виртуальный адрес становится физической ОЗУ: ошибка страницы от начала до конца
• Как читать «использование памяти» в Windows: Working Set, Private Bytes, Commit и файл подкачки
• Как ускорить проверку приложений в Windows Sandbox
• Планирование процессора в Windows: «Фоновые службы» и P-/E-ядра

Смежные области консультирования

KomuraSoft LLC занимается проектированием сред проверки Windows-приложений, расследованием производительности в виртуализованных средах и анализом проблем совместимости драйверов и периферии.

• Разработка Windows-приложений
• Расследование сбоев и анализ причин
• Использование и миграция существующих активов
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если включить Hyper-V, где тогда работает хостовый Windows?

Гипервизор сам распределяет физические ЦП и память, а хостовый Windows работает внутри особого раздела — корневого. Физическими устройствами обычно управляют драйверы на стороне корневого раздела. В корневом разделе лежат драйверы устройств и стек управления виртуализацией, но физическими ЦП распоряжается гипервизор.

Строка «Виртуализация: включено» в Диспетчере задач значит, что Hyper-V уже работает?

Нет. Она показывает лишь, включена ли в прошивке аппаратная поддержка виртуализации ЦП (Intel VT-x/AMD-V). Работает ли гипервизор на самом деле, смотрите по строке «Обнаружен гипервизор» в systeminfo или по свойству Win32_ComputerSystem.HypervisorPresent.

Почему гипервизор работает, хотя я ни разу не создавал ВМ?

В Windows 11 безопасность на основе виртуализации (VBS) по умолчанию включена на устройствах, которые удовлетворяют условиям — например, чистая установка на совместимое оборудование. VBS опирается на гипервизор Windows. То же самое, если вы пользуетесь WSL2 или Windows Sandbox. Гипервизор без какой-либо связи с ВМ — обычная картина, а не редкость.

Что такое SLAT и почему без него Hyper-V не работает?

SLAT (Second Level Address Translation) — механизм, которым ЦП переводит гостевые физические адреса в настоящие физические. На Intel это EPT, на AMD — RVI. Без SLAT гипервизору пришлось бы вести таблицы трансляции программно; по производительности это нереалистично, поэтому актуальный Hyper-V требует SLAT жёстко.

Если включить Hyper-V, VirtualBox и VMware перестанут работать?

Гипервизор использует расширения виртуализации ЦП эксклюзивно, поэтому сторонний гипервизор не может работать прежним способом. У актуальных VirtualBox и VMware есть режим, который работает поверх гипервизора Windows через Windows Hypervisor Platform. Свежие версии этих продуктов могут сосуществовать.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.