Les profondeurs de la virtualisation Windows (partie 1) — Où s'exécute réellement votre Windows ? L'hyperviseur et les partitions

Vous n’avez jamais créé une seule machine virtuelle, et pourtant les Informations système (msinfo32) sous Windows 11 affichent « Sécurité basée sur la virtualisation : En cours d’exécution ». Que signifie cet affichage ?

Sur ce PC, le Windows hôte lui-même s’exécute déjà au-dessus d’un hyperviseur. Sous Windows 11, VBS est activée par défaut sur les configurations qui remplissent les conditions, une installation propre sur un matériel compatible par exemple, et ce fondement est utilisé même si vous ne créez jamais de machine virtuelle.¹ WSL2 et Windows Sandbox utilisent le même hyperviseur Windows.

La partie 1 explique où le Windows hôte finit par s’exécuter lorsque vous activez Hyper-V, à travers la répartition des rôles entre processeur, mémoire et E/S de périphériques. C’est l’article qui remet d’abord d’aplomb la vue « un logiciel de machines virtuelles posé au-dessus de Windows ».

« Les profondeurs de la virtualisation Windows » — les 3 parties

Nous regardons le même hyperviseur Windows dans l’ordre fondement → isolation de sécurité → application aux machines virtuelles légères.

Prérequis de cet article

Comment lire cet article

La carte des connaissances ci-dessous est une liste de relations. Si c’est votre première lecture, suivez le texte à partir de la section 1, la vue d’ensemble.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (22 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

1. D’abord la conclusion

Lorsque les gens entendent Hyper-V, ils peuvent se représenter « un logiciel d’exécution de machines virtuelles posé au-dessus de Windows ». La structure réelle est l’inverse.

Dès le moment où vous activez Hyper-V et redémarrez, c’est l’hyperviseur qui contrôle les processeurs physiques et la mémoire, et le Windows hôte s’exécute au-dessus de lui comme première partition privilégiée — la « partition racine ».

Un hyperviseur est une mince couche de logiciel qui s’interpose entre le matériel et l’OS, crée des environnements d’exécution isolés appelés « partitions », et médiatise l’accès au matériel.² Le Windows hôte va dans la partition racine ; les machines virtuelles vont dans les partitions enfants.

La partition racine est traitée de façon spéciale (elle a un accès direct aux périphériques physiques et détient la pile de gestion), mais au sens où elle ne contrôle pas directement les processeurs physiques, elle se tient dans la même position qu’une partition enfant.

flowchart TB
    accTitle: Structure d'ensemble après activation d'Hyper-V
    accDescr: L'hyperviseur s'assoit directement sur le matériel physique, et au-dessus se tiennent la partition racine qui détient le Windows hôte et les partitions enfants qui détiennent les machines virtuelles
    hw["Matériel physique"] --> hv["Hyperviseur"]
    hv --> root["Partition racine (Windows hôte)"]
    hv --> child1["Partitions enfants (machines virtuelles)"]
    root -.-> stack["Détient la pile de gestion de la virtualisation et les pilotes"]

Figure 1 : Hyper-V n’est pas « un logiciel de machines virtuelles au-dessus de Windows » mais une couche qui passe sous Windows, et l’OS hôte lui-même s’exécute à l’intérieur de la partition racine.

Vous pourriez penser : « Si rien ne change à l’usage avant et après l’activation, une telle inversion majeure a-t-elle vraiment eu lieu ? » Elle a eu lieu. C’est précisément pourquoi cette structure passe généralement inaperçue. Dans cet article, nous démontons ce seul schéma selon trois axes : processeur, mémoire et E/S de périphériques.

2. Du côté du processeur — un privilège de plus sous les anneaux

Dans la discussion du processeur, nous distinguons les anneaux qui séparent le noyau des applications des modes d’exécution qui séparent l’hyperviseur des invités. La question de cette section est : le noyau invité s’exécute aussi à l’anneau 0, alors pourquoi n’y a-t-il pas collision ?

2.1. Un rappel de la protection par anneaux

Les processeurs x64 ont des niveaux de privilège (anneaux), et Windows exécute le mode noyau à l’anneau 0 et le mode utilisateur à l’anneau 3. Les applications ne peuvent pas toucher le matériel directement parce que les instructions privilégiées ne peuvent pas s’exécuter depuis l’anneau 3.

Alors comment loger en toute sécurité plusieurs noyaux d’OS, chacun s’exécutant à l’anneau 0, sur le même processeur physique ? Chaque noyau est écrit en partant du principe que « je contrôle le processeur ». Donnez l’anneau 0 à tous et ils se heurtent ; refusez-le et ils ne tourneront pas.

flowchart TB
    accTitle: Le problème de plusieurs noyaux d'OS qui exigent l'anneau 0
    accDescr: Les noyaux hôte et invité sont tous deux écrits en supposant une autorité pleine à l'anneau 0, donc l'échelle d'anneaux traditionnelle seule ne peut pas les loger en toute sécurité sur le même processeur physique
    k1["Noyau hôte (suppose l'anneau 0)"] --> want["Exige le contrôle du processeur physique"]
    k2["Noyau invité (suppose l'anneau 0)"] --> want
    want --> conflict["Les anneaux traditionnels seuls ne peuvent pas concilier cela"]
    conflict --> need["Un médiateur au-dessus de l'anneau 0 est requis"]

Figure 2 : l’échelle d’anneaux a été construite en supposant un seul OS, donc loger plusieurs noyaux exige un privilège de plus au-dessus.

2.2. Extensions de virtualisation — un mode réservé à l’hyperviseur

Ce qui résout ce problème, ce sont les extensions de virtualisation du processeur (Intel VT-x/AMD-V). Hyper-V exige un processeur qui a cette fonctionnalité.² Les extensions de virtualisation ajoutent, sur un axe distinct des anneaux traditionnels, un « mode d’exécution pour l’hyperviseur » et un « mode d’exécution pour les invités ». C’est un privilège encore plus fort que l’anneau 0, parfois surnommé « anneau -1 ».

• Le noyau invité continue de s’exécuter à l’anneau 0, comme auparavant. Aucune réécriture n’est requise.
• Cet anneau 0, toutefois, est « l’anneau 0 à l’intérieur du mode invité », et il ne contrôle pas le processeur physique dans son ensemble.
• Lorsque l’invité rencontre une opération particulière qui exige l’intervention de l’hyperviseur (une instruction configurée comme interception, ou une exception ou une violation), le processeur transfère automatiquement le contrôle à l’hyperviseur (un VM Exit). Lorsque l’hyperviseur a fini de le traiter, il revient à l’invité (un VM Entry). Les accès mémoire ordinaires passent sans VM Exit, tant que la traduction SLAT réussit.

Les interruptions fonctionnent de la même manière. Les partitions ne touchent pas les processeurs physiques directement ; l’hyperviseur reçoit les interruptions et les dirige vers chaque partition.²

flowchart TB
    accTitle: Le flux d'exécution de l'invité et le VM Exit
    accDescr: Le noyau invité et les applications s'exécutent à l'anneau 0 et à l'anneau 3 en mode invité ; les accès mémoire ordinaires passent via la traduction SLAT, tandis que les opérations configurées comme interceptions et les exceptions provoquent un VM Exit qui transfère le contrôle à l'hyperviseur, lequel revient ensuite à l'invité via VM Entry
    guest["Exécution en mode invité (noyau anneau 0 inclus)"] --> op{"Intervention nécessaire ? (interceptions/exceptions configurées)"}
    op -->|Non| cont["Continuer l'exécution telle quelle"]
    op -->|Oui| exitEv["VM Exit (le processeur transfère le contrôle)"]
    exitEv --> hvp["L'hyperviseur le traite"]
    hvp --> entry["Retour à l'invité via VM Entry"]
    entry --> guest

Figure 3 : l’OS invité continue de s’exécuter à l’anneau 0 sans réécriture, et le processeur n’appelle l’hyperviseur que lorsque c’est nécessaire.

Cet aller-retour ressemble beaucoup au flux que nous avons suivi dans la série mémoire — « entrer dans le noyau sur un défaut de page, puis revenir à la même instruction ». Le processeur intercepte le contrôle via un mécanisme d’exception ou de transition, laisse un gestionnaire de niveau supérieur décider, puis revient. Dans les profondeurs de Windows, cette forme apparaît encore et encore.

2.3. Type 1 et Type 2 — la différence est l’endroit où il s’assoit

Les hyperviseurs se divisent largement en Type 1 (bare-metal), qui s’exécute directement sur le matériel, et Type 2 (hébergé), qui s’exécute au-dessus d’un OS hôte. Hyper-V est de Type 1.³ VirtualBox et VMware Workstation (lorsqu’ils s’exécutent de façon autonome) sont classés Type 2.

En entendant Type 1, les gens ont tendance à imaginer « une configuration serveur uniquement, sans OS hôte », mais Hyper-V est différent. Le Windows hôte ne disparaît pas — il « déménage » dans la partition racine. Lorsque vous activez Hyper-V et redémarrez, l’hyperviseur démarre d’abord pendant le boot, et le Windows hôte vient ensuite en tant que partition racine au-dessus de lui.

flowchart TB
    accTitle: La différence entre hyperviseurs de Type 1 et de Type 2
    accDescr: En Type 2 l'OS hôte s'assoit sur le matériel et l'hyperviseur et les machines virtuelles s'assoient sur l'OS hôte, alors qu'en Type 1 Hyper-V l'hyperviseur s'assoit directement sur le matériel et l'OS hôte lui-même va dans la partition racine au-dessus
    subgraph t2 ["Type 2 (hébergé)"]
        hw2["Matériel"] --> hostos["OS hôte"]
        hostos --> hv2["Hyperviseur"]
        hv2 --> vm2["Machine virtuelle"]
    end
    subgraph t1 ["Type 1 (Hyper-V)"]
        hw1["Matériel"] --> hv1["Hyperviseur"]
        hv1 --> root1["Partition racine (OS hôte)"]
        hv1 --> vm1["Machine virtuelle"]
    end
    vm2 ~~~ hw1

Figure 4 : en Type 2 l’hyperviseur s’assoit sur l’OS hôte, alors qu’en Type 1 Hyper-V l’ordre est inversé et l’OS hôte lui-même s’assoit sur la couche un cran en dessous.

Vue sur une ligne de temps de boot, la modification qui survient à l’activation se présente ainsi.

flowchart TB
    accTitle: Ordre de boot après activation d'Hyper-V
    accDescr: Après la mise sous tension, l'hyperviseur démarre d'abord pendant le boot, le Windows hôte vient ensuite comme partition racine au-dessus de lui, et les machines virtuelles, VBS et ainsi de suite démarrent après
    poweron["Mise sous tension et début du boot"] --> bhv["L'hyperviseur démarre en premier"]
    bhv --> broot["Le Windows hôte démarre comme partition racine"]
    broot --> blater["Machines virtuelles, VBS, WSL2, etc. démarrent au-dessus"]
    broot -.-> feel["L'expérience de l'utilisateur est inchangée"]

Figure 5 : l’inversion d’ordre est déjà terminée avant l’écran d’ouverture de session, et l’OS hôte monte sur l’hyperviseur dès le départ.

3. Les partitions — l’unité d’isolation

Regardons de près les partitions, les « boîtes » de la vue d’ensemble. Ce que nous voulons séparer ici, c’est la médiation du processeur et de la mémoire, que l’hyperviseur assure directement, de l’E/S de périphériques, que la partition racine médiatise normalement.

3.1. Les rôles que seule la partition racine a

Une partition est une unité logique d’isolation que l’hyperviseur fournit.² Toutes les partitions ne sont toutefois pas égales. Il y a des choses que seule la partition racine a.

Accès direct aux périphériques physiques

Les pilotes de périphériques pour disques, NIC, GPU et ainsi de suite vivent dans le Windows à l’intérieur de la partition racine, pas dans l’hyperviseur. Hyper-V sur Windows Server a une configuration qui attribue un périphérique PCIe donné directement à une partition enfant (Discrete Device Assignment) ; dans ce cas la racine lâche ce périphérique (ce n’est pas disponible sur Windows client).⁴

La pile de gestion de la virtualisation

VMMS (Virtual Machine Management Service), qui régit la création, le démarrage et l’arrêt des machines virtuelles, et le processus de travail qui démarre pour chaque machine virtuelle (vmwp.exe) s’exécutent en mode utilisateur dans la partition racine.⁵ Ce sont des éléments des fonctions de gestion de machines virtuelles d’Hyper-V, ils peuvent donc être absents sur un hôte où seul l’hyperviseur tourne pour VBS ou WSL2.

Le droit de créer des partitions enfants

La partition racine crée des partitions enfants via l’API d’hyperappel (l’interface d’appel vers l’hyperviseur).²

Cette conception a une raison. Si vous mettez chaque pilote de périphérique dans l’hyperviseur lui-même, l’hyperviseur devient énorme et le nombre de bogues et de points d’entrée d’attaque augmente. L’hyperviseur se confine au travail minimal de médiation des processeurs et de la mémoire, et laisse le soin des périphériques au Windows de la partition racine. Cette répartition des rôles est ce qui garde Hyper-V mince.

flowchart TB
    accTitle: Répartition des rôles entre la partition racine et les partitions enfants
    accDescr: La partition racine détient la pile de gestion de la virtualisation et les pilotes de périphériques physiques et crée des partitions enfants via des hyperappels ; une partition enfant ne voit que des périphériques virtuels dans la configuration habituelle, et sous Discrete Device Assignment sur Windows Server elle accède directement au périphérique attribué
    subgraph rootp ["Partition racine"]
        vmms["VMMS et processus de travail"]
        drv["Pilotes de périphériques physiques"]
    end
    subgraph childp ["Partition enfant"]
        gos["OS invité"]
        vdev["Dans la configuration habituelle, seuls les périphériques virtuels sont visibles"]
    end
    vmms -->|Créer et gérer via des hyperappels| childp
    hv2["Hyperviseur (se confine à médiatiser processeur et mémoire)"] --- rootp
    hv2 --- childp

Figure 6 : placer les pilotes de périphériques et la pile de gestion du côté de la partition racine est ce qui garde l’hyperviseur lui-même mince.

3.2. Le monde vu depuis une partition enfant

L’OS invité d’une partition enfant ne peut pas voir le matériel physique directement dans la configuration habituelle de périphériques virtuels (la seule exception est un périphérique attribué via Discrete Device Assignment sur Windows Server, comme décrit à la section précédente). Ce qu’il peut voir, ce sont des processeurs virtuels, un espace mémoire qui semble lui appartenir, et des périphériques virtuels. Les demandes vers les périphériques virtuels sont transférées à la partition racine via VMBus ou l’hyperviseur.²

L’allocation du temps processeur et la traduction mémoire via SLAT, en revanche, sont assurées directement par l’hyperviseur sans passer par la racine. Ce que la racine médiatise, c’est l’E/S de périphériques, pas chaque ressource physique.

flowchart TB
    accTitle: Le monde vu depuis une partition enfant
    accDescr: Ce que l'OS invité voit, ce sont des processeurs virtuels, un espace mémoire privé à la partition et des périphériques virtuels ; les demandes vers les périphériques virtuels sont transférées à la partition racine via VMBus et similaires, le temps processeur et la traduction mémoire sont assurés directement par l'hyperviseur, et dans une configuration Discrete Device Assignment sur Windows Server seuls les périphériques attribués sont accédés directement
    gos2["OS invité dans la partition enfant"] --> vcpu["Processeurs virtuels"]
    gos2 --> gpa2["Espace mémoire privé"]
    gos2 --> vdev2["Périphériques virtuels"]
    vdev2 -->|"Via VMBus et similaires"| rootx["Transféré à la partition racine"]
    gos2 -.->|Non visible directement| phys2["Processeurs physiques, RAM et périphériques réels"]
    phys2 -.-> dda2["Dans une configuration DDA (Windows Server), seuls les périphériques attribués sont accédés directement"]
    vcpu ~~~ phys2

Figure 7 : dans la configuration habituelle de périphériques virtuels, tout ce que l’invité voit est une fenêtre virtuelle et le chemin vers le physique passe par un médiateur ; seul un périphérique attribué via DDA sur Windows Server est l’exception.

Ce qui compte ici, c’est que pour une application qui s’exécute sur le Windows hôte, cette structure est presque transparente. Les appels d’API Win32 et le traitement des défauts de page sont toujours traités par le noyau Windows à l’intérieur de la partition racine, comme auparavant. L’hyperviseur n’intervient que lorsqu’une interception configurée ou une exception est rencontrée.

4. Du côté de la mémoire — la traduction d’adresses gagne un niveau de plus

Pour la mémoire, nous séparons l’adresse que l’invité considère « physique » de l’emplacement réel dans la RAM. Retenez l’ordre GVA → GPA → SPA et qui gère chaque traduction.

4.1. Trois sortes d’adresses

Dans la partie 1 de la série mémoire, nous avons suivi le flux par lequel une adresse virtuelle est traduite à travers la table de pages en une adresse physique (« L’instant où une adresse virtuelle devient de la RAM physique »). Dans un environnement virtualisé, un niveau de plus s’ajoute sous cette traduction, et il y a trois sortes d’adresses.

L’OS invité traduit GVA en GPA avec sa propre table de pages. La GPA que l’invité voit, toutefois, n’est pas une adresse physique réelle ; c’est un espace mémoire privé dédié à chaque partition.² Faire correspondre GPA à l’emplacement réel dans la RAM (SPA) est le travail de l’hyperviseur.

4.2. SLAT — une traduction à deux niveaux en matériel

Si cette traduction de second niveau était faite en logiciel seul, l’hyperviseur devrait suivre une à une chaque mise à jour de table de pages de l’invité, ce qui n’est pas réaliste du point de vue des performances. Le processeur fournit donc un mécanisme qui parcourt les tables de traduction de second niveau en matériel. C’est SLAT (Second Level Address Translation) ; Intel EPT (Extended Page Tables) et AMD RVI en sont les implémentations.

Hyper-V actuel exige un processeur 64 bits compatible SLAT.⁴

flowchart TB
    accTitle: Traduction d'adresses à deux niveaux via SLAT
    accDescr: Une adresse virtuelle invité est traduite en adresse physique invité par la table de pages de l'OS invité, puis encore traduite en adresse physique système par SLAT, que l'hyperviseur gère, et atteint la RAM réelle
    gva["Adresse virtuelle invité (GVA)"] -->|Table de pages de l'OS invité| gpa["Adresse physique invité (GPA)"]
    gpa -->|"SLAT (tables de traduction EPT/RVI)"| spa["Adresse physique système (SPA)"]
    spa --> ram["RAM physique"]
    gpa -.-> note["Une couche que l'invité croit seulement physique"]

Figure 8 : une autre table de traduction, gérée par l’hyperviseur, s’assoit sous la table de pages de l’invité, et le processeur parcourt les deux en matériel.

SLAT n’est pas une fonctionnalité qui n’existe que pour l’efficacité d’exécution des machines virtuelles. La VBS que nous verrons en partie 2 utilise la propriété « on peut avoir une table de traduction SLAT différente par niveau de privilège » comme matériau d’une frontière de sécurité. La raison pour laquelle on peut créer une mémoire que même le noyau ne peut pas voir, c’est que l’hyperviseur tient cette traduction de second niveau. C’est un fil conducteur de toute la série, donc retenez un seul point : « le gestionnaire des tables de traduction est l’hyperviseur ».

5. Du côté de l’E/S de périphériques — VMBus et deux sortes de périphériques

L’E/S de périphériques emprunte un chemin différent du temps processeur et de la traduction mémoire. Nous comparons la méthode qui imite le matériel réel et la méthode qui utilise un chemin dédié à la virtualisation.

5.1. Les limites des périphériques émulés

La façon classique de montrer un périphérique à une partition enfant est d’imiter entièrement en logiciel du matériel réel (un ancien contrôleur IDE, par exemple). La compatibilité est élevée parce que les pilotes fournis de l’OS invité fonctionnent tels quels, mais un VM Exit survient chaque fois que l’invité frappe un port d’E/S, et les performances ne passent pas à l’échelle.

flowchart TB
    accTitle: Pourquoi l'E/S vers un périphérique émulé est lente
    accDescr: Chaque fois que l'invité opère un port d'E/S, le contrôle passe côté hyperviseur via un VM Exit, le périphérique est imité en logiciel, et le contrôle revient à l'invité, donc l'aller-retour se répète et est lent
    gio["L'invité opère un port d'E/S"] --> vex["Un VM Exit survient"]
    vex --> emu2["Le périphérique est imité en logiciel"]
    emu2 --> back["Retour à l'invité via VM Entry"]
    back -->|Se répète à l'opération de port suivante| gio

Figure 9 : cet aller-retour s’exécute de nombreuses fois derrière un seul accès disque, et le prix de la compatibilité se paie en performances.

5.2. VMBus et VSP/VSC — un chemin rapide conçu pour la virtualisation

Hyper-V a donc un mécanisme de « périphérique synthétique » conçu en partant du principe de la virtualisation. Il y a trois acteurs.²

• VMBus : un canal de communication logique entre partitions. Il fournit une communication inter-partitions à haute vitesse qui utilise de la mémoire partagée.³
• VSP (Virtualization Service Provider) : un service qui réside du côté de la partition racine, reçoit les demandes de périphérique de l’enfant, et les relie à la pile périphérique/backend du côté racine. Une demande peut atteindre un périphérique physique, ou être traitée par un backend côté hôte tel qu’un disque virtuel ou un commutateur virtuel.
• VSC (Virtualization Service Consumer) : un pilote de périphérique synthétique qui va dans l’OS invité du côté de la partition enfant. Il envoie les demandes au VSP via VMBus.

Exemple : comment le WriteFile d’un invité atteint l’hôte

Une demande de stockage de l’OS invité circule dans l’ordre suivant.

1. Le WriteFile de l’application invité descend la pile d’E/S du noyau invité.
2. Au bas, il atteint le VSC au lieu du matériel réel.
3. Le VSC pose la demande sur VMBus et la remet au VSP de la partition racine.
4. Le VSP fait circuler la demande dans la pile d’E/S côté racine. Dans une configuration de disque virtuel (VHDX), elle est traitée comme une écriture dans le fichier VHDX sur l’hôte et finit par atteindre le disque physique.

Cette approche s’appelle Enlightened I/O (une E/S consciente de la virtualisation), et elle gagne en efficacité en contournant la couche d’émulation de périphériques.²

flowchart TB
    accTitle: Chemin d'E/S d'un périphérique synthétique
    accDescr: Une demande d'E/S d'une application dans la partition enfant atteint le VSC à travers le noyau invité, traverse VMBus jusqu'au VSP de la partition racine, et sur la pile d'E/S côté racine que le VSP relie, elle peut atteindre un périphérique réel via un pilote de périphérique physique, ou être traitée par un backend côté hôte tel qu'un disque virtuel ou un commutateur virtuel
    app["Application dans la partition enfant"] --> gk["Pile d'E/S du noyau invité"]
    gk --> vsc["VSC (pilote de périphérique synthétique)"]
    vsc -->|VMBus| vsp["VSP (côté partition racine)"]
    vsp --> rio["Pile d'E/S côté racine"]
    rio --> pdrv["Pilote de périphérique physique"]
    rio --> hb["Backend côté hôte (disque virtuel, commutateur virtuel, etc.)"]
    pdrv --> dev["Périphérique physique"]

Figure 10 : avec un périphérique synthétique, l’E/S de l’invité traverse vers la partition racine via VMBus et, à travers la pile côté racine, atteint un périphérique réel ou un backend côté hôte.

Autrement dit, la vitesse de l’E/S disque ou du réseau d’une machine virtuelle ne dépend pas seulement du côté invité, mais aussi de l’état de la pile d’E/S et des pilotes de périphériques du côté de la partition racine. La raison pour laquelle l’observation côté hôte est indispensable lorsque vous enquêtez sur un problème de performances d’une machine virtuelle, c’est que le chemin passe réellement par l’hôte.

flowchart TB
    accTitle: Périphériques émulés versus périphériques synthétiques
    accDescr: Un périphérique émulé imite le matériel réel pour que les pilotes fournis de l'invité fonctionnent mais il est lent ; un périphérique synthétique est un pilote conçu pour VMBus et est rapide
    dev2{"Périphérique montré à la partition enfant"} --> emu["Périphérique émulé"]
    dev2 --> syn["Périphérique synthétique"]
    emu -.-> emuP["Imite le matériel réel ; compatibilité d'abord"]
    emuP -.-> emuC["Exige une intervention à chaque E/S ; lent"]
    syn -.-> synP["Conçu autour de VMBus ; rapide"]
    synP -.-> synC["Exige un pilote correspondant dans l'invité"]

Figure 11 : des deux sortes de périphériques virtuels, les périphériques émulés portent la compatibilité juste après l’installation de l’OS, et les périphériques synthétiques portent les performances au quotidien.

6. Pourquoi ce n’est pas l’affaire des autres, même si vous n’utilisez jamais de machine virtuelle

6.1. VBS, WSL2 et Sandbox utilisent le même fondement

La structure jusqu’ici peut ressembler à « une histoire pour ceux qui dressent des machines virtuelles ». Comme le disait l’ouverture, toutefois, sous Windows actuel l’hyperviseur fait partie du quotidien.

• Sécurité basée sur la virtualisation (VBS). Elle utilise l’hyperviseur Windows pour créer un environnement isolé et y loge des fonctions de sécurité. Sous Windows 11, elle est activée par défaut lorsque des conditions telles qu’une installation propre sur un matériel compatible sont remplies.¹ Les détails sont dans la partie 2.
• WSL2. Il exécute un vrai noyau Linux à l’intérieur d’une machine virtuelle utilitaire légère.⁶
• Windows Sandbox. Un environnement Windows jetable isolé par l’hyperviseur.⁷ Les deux sont couverts dans la partie 3.

flowchart TB
    accTitle: Fonctions du quotidien qui reposent sur le même hyperviseur
    accDescr: Non seulement les machines virtuelles Hyper-V, mais aussi VBS, activée par défaut sur les appareils qui remplissent des conditions telles qu'une installation propre, plus WSL2 et Windows Sandbox, sont tous construits sur le même hyperviseur Windows
    base["Hyperviseur Windows"] --> f1["Machines virtuelles Hyper-V"]
    base --> f2["VBS (activée par défaut sur installation propre et similaires)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Pourquoi cela tourne même sur des PC sans machine virtuelle"]

Figure 12 : il y a un seul fondement, et c’est sur ce schéma que l’hypothèse « la virtualisation est une histoire pour ceux qui utilisent des machines virtuelles » s’effondre.

6.2. Coexistence avec les logiciels de virtualisation tiers

Un autre point que l’on rencontre souvent en pratique est la coexistence avec les logiciels de virtualisation tiers. Parce que l’hyperviseur utilise les extensions de virtualisation du processeur de façon exclusive, dans un environnement où l’hyperviseur Windows tourne, VirtualBox et similaires ne peuvent pas s’exécuter de la manière traditionnelle (celle qui utilise elle-même les extensions de virtualisation du processeur).

Pour cela, une API publique appelée Windows Hypervisor Platform est fournie, et une pile de virtualisation tierce peut s’exécuter en s’asseyant au-dessus de l’hyperviseur Windows.⁸ VirtualBox/VMware actuels peuvent coexister avec WSL2 grâce à ce mécanisme, mais les écarts de performances et de fonctions qui accompagnent le changement de mode s’observent parfois sous la forme « après avoir activé Hyper-V (ou VBS), le logiciel de virtualisation s’est mis à se comporter autrement ».

flowchart TB
    accTitle: Qui possède les extensions de virtualisation du processeur, et le chemin pour les logiciels de virtualisation tiers
    accDescr: Tant que l'hyperviseur Windows tourne, il possède exclusivement les extensions de virtualisation du processeur ; un logiciel de virtualisation tiers qui prend en charge WHP s'exécute au-dessus via Windows Hypervisor Platform, tandis que les implémentations qui ne prennent pas en charge WHP ne peuvent pas s'exécuter ou sont limitées
    vt["Extensions de virtualisation du processeur (VT-x/AMD-V)"] --> hvon{"L'hyperviseur Windows tourne-t-il ?"}
    hvon -->|Non| direct["Le logiciel tiers peut les utiliser directement"]
    hvon -->|Oui| own["L'hyperviseur en a l'usage exclusif"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Le logiciel tiers compatible WHP s'exécute au-dessus"]
    third -.-> nowhp["Les implémentations non compatibles ne peuvent pas s'exécuter, ou sont limitées"]

Figure 13 : il y a un seul propriétaire des extensions de virtualisation, et le seul logiciel tiers qui peut coexister tant que l’hyperviseur tourne est un logiciel qui prend en charge l’API publique (WHP).

7. Vérifiez par vous-même

Vous pouvez vérifier sur votre propre PC si un hyperviseur tourne.

7.1. Vérifier l’hyperviseur et VBS avec PowerShell

D’abord, une vérification que vous pouvez exécuter sans privilèges d’administrateur.

# Si nous nous exécutons au-dessus d'un hyperviseur
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# État de VBS (même source que « Sécurité basée sur la virtualisation » dans msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus renvoie l’état d’exécution de VBS sous forme de nombre (2 est « En cours d’exécution »).⁹

Un avertissement. Tout ce que HypervisorPresent vous dit, c’est « si nous nous exécutons au-dessus d’un hyperviseur » ; il ne distingue pas racine et enfant. Si vous l’exécutez sur Windows à l’intérieur d’une machine virtuelle, il renvoie quand même True, en tant que partition enfant. S’il est True sur Windows sur un PC physique, ce Windows est à l’intérieur de la partition racine ; vous le lisez avec l’environnement d’exécution.

7.2. Distinguer « en cours d’exécution » et « prérequis » dans systeminfo

Ensuite, le classique depuis une invite de commandes.

systeminfo

Regardez « Configuration requise pour Hyper-V » à la fin de la sortie. Sur une machine où l’hyperviseur ne tourne pas encore, les exigences individuelles, telles que la prise en charge de SLAT et le fait que les extensions de virtualisation soient activées, sont listées une par une. Sur une machine où l’hyperviseur tourne déjà, au lieu des exigences vous obtenez une seule ligne : « Un hyperviseur a été détecté. Les fonctionnalités requises pour Hyper-V ne s’afficheront pas. »⁴

Cette seule ligne est donc une déclaration que votre Windows s’exécute au-dessus d’un hyperviseur quelconque. Comme pour HypervisorPresent, il faut la lire comme « à l’intérieur de la partition racine » sur un PC physique, ou « en tant que partition enfant » à l’intérieur d’une machine virtuelle.

Même si chaque exigence de systeminfo est « Oui », cela signifie seulement que le côté matériel est prêt. La fonctionnalité Hyper-V elle-même est disponible sur les éditions Pro, Enterprise et Education, et n’est pas sur Home.¹⁰

7.3. Quand vous vérifiez à l’écran, distinguez l’élément que vous vérifiez

Dans l’interface graphique, vérifiez la ligne « Sécurité basée sur la virtualisation » sous « Résumé du système » dans msinfo32. Notez que « Virtualisation : activée » dans le volet processeur du Gestionnaire des tâches ne montre que si les extensions de virtualisation sont activées dans le microprogramme, ce qui est une information distincte de savoir si un hyperviseur tourne.

flowchart TB
    accTitle: Comment vérifier si l'hyperviseur tourne
    accDescr: Si systeminfo dit qu'un hyperviseur a été détecté, vous vous exécutez sur un hyperviseur (à l'intérieur de la partition racine sur un PC physique) ; si la liste Configuration requise pour Hyper-V apparaît, il ne tourne pas encore donc vous vérifiez chaque exigence telle que SLAT, les extensions du mode moniteur de machine virtuelle et DEP, mais tout Oui signifie seulement que le côté matériel est prêt et la fonctionnalité Hyper-V a aussi une exigence d'édition
    start2["Exécuter systeminfo"] --> q1{"Que montre le champ Configuration requise pour Hyper-V ?"}
    q1 -->|Un hyperviseur a été détecté| running["L'hyperviseur tourne (dans la racine sur un PC physique)"]
    q1 -->|Les exigences sont listées| notyet["L'hyperviseur ne tourne pas encore"]
    notyet --> q2{"Toutes les exigences à Oui ?"}
    q2 -->|Toutes à Oui| can["Le côté matériel est prêt"]
    can -.-> ed["Hyper-V a aussi besoin de Pro/Enterprise/Education"]
    q2 -->|Certains Non| uefi["Vérifier les éléments concernés dans l'UEFI/BIOS et similaires"]

Figure 14 : le champ « Configuration requise pour Hyper-V » de systeminfo sert à la fois de vérification d’état d’exécution et de vérification de prérequis.

8. Trois lectures erronées à éviter en pratique

8.1. « Nous n’avons pas activé Hyper-V, donc la virtualisation n’a rien à voir avec nos PC »

Même si vous n’avez pas activé la fonctionnalité Hyper-V (les outils de gestion et l’environnement d’exécution de machines virtuelles), l’hyperviseur Windows tourne si VBS est activée. Lorsque vous enquêtez sur un problème de compatibilité de pilote, un test de performances, ou un souci avec un logiciel de virtualisation tiers, vérifiez HypervisorPresent et l’état d’exécution de VBS, pas si la fonctionnalité est activée.

8.2. « Le Gestionnaire des tâches dit “Virtualisation : activée”, donc Hyper-V tourne »

Cet affichage concerne le réglage du microprogramme (si VT-x/AMD-V est disponible). Jugez l’état d’exécution de l’hyperviseur d’après « Un hyperviseur a été détecté » dans systeminfo. Inversement, si le Gestionnaire des tâches dit « Désactivée », vous ne pouvez activer ni Hyper-V ni WSL2 non plus, donc vérifiez d’abord les réglages UEFI/BIOS.

flowchart TB
    accTitle: Trois vérifications faciles à confondre
    accDescr: Le champ Virtualisation du Gestionnaire des tâches montre le réglage du microprogramme, la liste des fonctionnalités de Windows montre l'état d'installation, et systeminfo ou HypervisorPresent montre l'état d'exécution ; chacun répond à une question différente
    q3{"Que voulez-vous savoir ?"} --> a3["Les extensions de virtualisation sont-elles activées dans le microprogramme ?"]
    q3 --> b3["La fonctionnalité Hyper-V a-t-elle été installée ?"]
    q3 --> c3["L'hyperviseur tourne-t-il en ce moment ?"]
    a3 -.-> a3t["Le volet processeur du Gestionnaire des tâches"]
    b3 -.-> b3t["La boîte de dialogue Fonctionnalités de Windows"]
    c3 -.-> c3t["systeminfo et HypervisorPresent"]

Figure 15 : ce sont trois questions indépendantes, et inférer les deux autres à partir d’un seul affichage est une lecture erronée.

8.3. « Si la machine virtuelle est lente, c’est un problème de l’OS invité »

L’E/S des périphériques synthétiques traverse VMBus jusqu’au VSP de la partition racine et passe par la pile périphérique/backend côté racine (pilotes physiques, plus le traitement du commutateur virtuel et du disque virtuel). Si vous ne regardez que les compteurs à l’intérieur de l’invité, vous ne trouverez pas un goulet d’étranglement qui siège dans le stockage ou une NIC côté hôte. Le principe pour les problèmes de performances des machines virtuelles est d’observer des deux côtés : l’invité et l’hôte (la partition racine).

9. Résumé

• Lorsque vous activez Hyper-V, l’hyperviseur s’exécute directement sur le matériel et le Windows hôte s’exécute comme partition racine.²
• Le noyau de l’OS invité continue de s’exécuter à l’anneau 0, et seules les opérations configurées comme interceptions, plus les exceptions, sont remises à l’hyperviseur via un VM Exit. Les accès mémoire ordinaires passent via la traduction SLAT.
• Seule la partition racine détient les pilotes de périphériques physiques et la pile de gestion de la virtualisation, et elle crée des partitions enfants via des hyperappels.²
• La mémoire devient une traduction à deux niveaux GVA→GPA→SPA, et le second niveau est assuré en matériel par SLAT (EPT/RVI). Hyper-V actuel exige SLAT.⁴
• L’E/S de périphériques est dominée par le chemin de périphérique synthétique VSC→VMBus→VSP, et les performances dépendent aussi de la pile d’E/S côté hôte.²
• Sous Windows 11, parce que VBS est activée par défaut sur les appareils qui remplissent des conditions telles qu’une installation propre, il n’est pas rare que l’hyperviseur tourne même sur un PC qui n’utilise jamais de machine virtuelle.¹ Vous pouvez vérifier l’état d’exécution avec HypervisorPresent et systeminfo.

La vue d’ensemble de la partie 1 se condense dans ce seul schéma.

flowchart TB
    accTitle: La vue d'ensemble de la partie 1
    accDescr: L'hyperviseur s'assoit sous la partition racine et les partitions enfants ; les processeurs sont alloués en planifiant des processeurs virtuels (VM Exit seulement sur interceptions et exceptions configurées), la mémoire est médiatisée par une traduction SLAT à deux niveaux, l'E/S des périphériques synthétiques est transférée via VMBus et traitée par le VSP de la partition racine, et les périphériques émulés et Discrete Device Assignment ont d'autres chemins
    up["Partition racine et partitions enfants"] --> hvS["Hyperviseur"]
    hvS --> cpuS["Processeur : alloue des processeurs virtuels"]
    hvS --> memS["Mémoire : traduction à deux niveaux via SLAT"]
    hvS --> devS["Périphériques : E/S synthétique transférée via VMBus"]
    cpuS -.-> cpuN["VM Exit seulement à l'intervention"]
    devS --> vspS["Traité par le VSP côté racine"]
    devS -.-> devN["Les périphériques émulés et DDA empruntent d'autres chemins"]

Figure 16 : la planification du processeur et la traduction mémoire sont assurées directement par l’hyperviseur (VM Exit seulement à l’intervention), et l’E/S des périphériques synthétiques est médiatisée par la partition racine (le VSP) de l’autre côté de VMBus.

Suite dans la partie 2, « Une mémoire invisible même au noyau — VBS, HVCI et Credential Guard ».

Nous reprenons le fil conducteur de cet article, à savoir que l’hyperviseur tient les tables de traduction SLAT, et suivons comment Windows crée « une mémoire que ni un administrateur ni le noyau ne peuvent lire ».

Articles connexes

• Les profondeurs de la mémoire Windows (partie 1) — L’instant où une adresse virtuelle devient de la RAM physique : un défaut de page de bout en bout
• Que représente réellement la « mémoire utilisée » sous Windows ── Bien lire Working Set, Private Bytes, Commit et le fichier d’échange
• Accélérer la validation des applications avec Windows Sandbox
• Réglages de planification du processeur sous Windows - Services d’arrière-plan et cœurs P/E

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception d’environnements de validation pour les applications Windows, les investigations de performances en environnement virtualisé, et l’analyse des problèmes de compatibilité des pilotes et des périphériques.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Migration d’actifs hérités
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Lorsque vous activez Hyper-V, où s'exécute réellement le Windows hôte ?

L'hyperviseur contrôle directement l'allocation des processeurs physiques et de la mémoire, et le Windows hôte s'exécute à l'intérieur d'une partition spéciale appelée partition racine. Le contrôle des périphériques physiques est normalement assuré par les pilotes côté partition racine. La partition racine détient les pilotes de périphériques et la pile de gestion de la virtualisation, mais la maîtrise des processeurs physiques appartient à l'hyperviseur.

Est-ce que « Virtualisation : activée » du Gestionnaire des tâches signifie qu'Hyper-V tourne ?

Non. Cet affichage indique si les extensions de virtualisation du processeur (Intel VT-x/AMD-V) sont activées dans le microprogramme. Pour voir si un hyperviseur tourne réellement, cherchez « Un hyperviseur a été détecté » dans systeminfo, ou vérifiez HypervisorPresent sur Win32_ComputerSystem.

Pourquoi l'hyperviseur tourne-t-il alors que je n'ai jamais créé de machine virtuelle ?

Sous Windows 11, la sécurité basée sur la virtualisation (VBS) est activée par défaut sur les appareils qui remplissent les conditions, une installation propre sur un matériel compatible par exemple, et VBS est construite sur l'hyperviseur Windows. Il en va de même si vous utilisez WSL2 ou Windows Sandbox. Il n'est pas rare que l'hyperviseur tourne indépendamment de l'usage de machines virtuelles.

Qu'est-ce que SLAT, et pourquoi est-il exigé pour Hyper-V ?

SLAT (Second Level Address Translation) est le mécanisme par lequel le processeur traduit les adresses physiques de l'invité en adresses physiques réelles ; Intel EPT et AMD RVI en sont les implémentations. Sans lui, l'hyperviseur devrait maintenir les tables de traduction en logiciel, ce qui n'est pas réaliste du point de vue des performances, donc Hyper-V actuel le traite comme une exigence dure.

Si j'active Hyper-V, VirtualBox et VMware cesseront-ils de fonctionner ?

Parce que l'hyperviseur utilise les extensions de virtualisation du processeur de façon exclusive, un hyperviseur tiers ne peut plus s'exécuter de la manière traditionnelle. VirtualBox et VMware actuels, toutefois, ont un mode qui s'exécute au-dessus de l'hyperviseur Windows (via Windows Hypervisor Platform), donc les versions récentes de chacun peuvent coexister.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.