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

L'hyperviseur prend le contrôle direct de 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 propriété 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 « A hypervisor has been detected » dans systeminfo, ou vérifiez Win32_ComputerSystem.HypervisorPresent.

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 sans aucun lien avec quiconque utilisant des 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 pas 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.

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

22 Aug 2026 02:00 · Go Komura · Windows, Virtualisation, Hyper-V, Hyperviseur, SLAT, VMBus

Ouvrez les Informations système (msinfo32) sous Windows 11 et vous verrez souvent « En cours d’exécution » dans le champ « Sécurité basée sur la virtualisation » — même sur une machine où vous n’avez jamais créé de machine virtuelle.

Ce que cela signifie, c’est le fait suivant. Sur ce PC, le Windows hôte lui-même s’exécute déjà au-dessus d’un hyperviseur. La « virtualisation » n’est plus une technologie réservée à ceux qui créent des machines virtuelles dans le Gestionnaire Hyper-V. Sous Windows 11, la sécurité basée sur la virtualisation (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 WSL2 comme Windows Sandbox sont construits sur le même hyperviseur Windows. Sous le Windows que vous utilisez tous les jours, il y a déjà une couche de logiciel de plus.

Cette série, « Les profondeurs de la virtualisation Windows », suit ce qui se passe dans cette couche, en partant des fondements.

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

Partie 1 (cet article) : l’hyperviseur et les partitions
Nous suivons où le Windows hôte finit par s’exécuter lorsque vous activez Hyper-V.
Partie 2 : une mémoire invisible même au noyau — VBS, HVCI et Credential Guard
Nous suivons où Windows place les secrets que ni un administrateur ni le noyau ne peuvent lire.
Partie 3 : des machines virtuelles qui démarrent en quelques secondes — WSL2, Windows Sandbox et les conteneurs
Nous suivons, à partir de la façon dont la mémoire et les images sont partagées, pourquoi WSL2 et Sandbox sont légers alors qu’une machine virtuelle complète est lourde.

La question à laquelle la partie 1 répond n’est qu’une.

Lorsque vous activez Hyper-V, où le Windows hôte finit-il par s’exécuter ?

Le public visé est constitué des développeurs et des opérateurs qui utilisent Hyper-V, WSL2 ou Windows Sandbox et veulent comprendre, depuis le mécanisme, ce qui tourne en dessous. Les prérequis sont Windows 10/11 x64 ou Windows Server actuel (la discussion des anneaux, de VT-x/AMD-V et d’EPT/RVI dans cet article suppose x64 ; Arm64 utilise un mécanisme différent tel que les niveaux d’exception). Le bagage requis est à peu près la distinction entre mode noyau et mode utilisateur ; vous n’avez besoin ni d’expérience d’exploitation de machines virtuelles ni de connaissances de développement d’hyperviseur. La difficulté est intermédiaire. Nous couvrons le concept des extensions de virtualisation du processeur, mais nous n’entrons pas dans les détails du jeu d’instructions.

1. La conclusion, d’abord

Lorsque les gens entendent Hyper-V, ils peuvent se représenter « un logiciel d’exécution de machines virtuelles qui s’assoit 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’assoit 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.² Celle dans laquelle va le Windows hôte est la partition racine ; celles dans lesquelles vont les machines virtuelles sont 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 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 je ne ressens aucune différence après l’avoir activé, 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

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"]
    k2["Noyau invité（suppose l'anneau 0）"] --> want
    want --> conflict["Les anneaux classiques n'y suffisent pas"]
    conflict --> need["Un médiateur au-dessus de l'anneau 0"]

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 interceptions et exceptions configurées 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）"}
    op -->|Non| cont["Continuer l'exécution telle quelle"]
    op -->|Oui| exitEv["VM Exit（le processeur transfère）"]
    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.

Vu sur une chronologie de boot, le changement qui se produit lorsque vous l’activez ressemble à ceci.

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 en tant que partition racine au-dessus, et les machines virtuelles, VBS et analogues démarrent après cela
    poweron["Mise sous tension et début du boot"] --> bhv["L'hyperviseur démarre d'abord"]
    bhv --> broot["Windows hôte comme partition racine"]
    broot --> blater["Machines virtuelles, VBS, WSL2 ensuite"]
    broot -.-> feel["L'expérience utilisateur est inchangée"]

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

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

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.

L’accès direct aux périphériques physiques. Les pilotes de périphériques pour disques, cartes réseau, GPU et analogues vivent dans le Windows à l’intérieur de la partition racine, pas dans l’hyperviseur. Hyper-V sous Windows Server a bien une configuration qui assigne un périphérique PCIe spécifique directement à une partition enfant (Discrete Device Assignment) ; dans ce cas la racine lâche ce périphérique (ceci n’est pas disponible sous Windows client).⁴
La pile de gestion de la virtualisation. VMMS (Virtual Machine Management Service), qui gouverne la création, le démarrage et l’arrêt des machines virtuelles, et le processus worker par machine virtuelle (vmwp.exe) s’exécutent en mode utilisateur dans la partition racine.⁵ Ce sont des fonctionnalités de gestion de machines virtuelles d’Hyper-V, donc elles peuvent être absentes 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 hypercall (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 bugs et de points d’entrée d’attaque croît. L’hyperviseur se confine au travail minimal de médiatiser processeurs et mémoire, et laisse le soin des périphériques au Windows de la partition racine. Cette division des rôles est ce qui garde Hyper-V mince.

flowchart TB
    accTitle: Division des rôles entre partition racine et 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 hypercalls ; une partition enfant ne voit normalement que des périphériques virtuels, et sous Discrete Device Assignment sur Windows Server elle accède directement au périphérique assigné
    subgraph rootp ["Partition racine"]
        vmms["VMMS et processus worker"]
        drv["Pilotes de périphériques physiques"]
    end
    subgraph childp ["Partition enfant"]
        gos["OS invité"]
        vdev["Config. usuelle : périph. virtuels seulement"]
    end
    vmms -->|Créer et gérer via hypercalls| childp
    hv2["Hyperviseur（se confine à médiatiser CPU et mémoire）"] --- rootp
    hv2 --- childp

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

3.2. Le monde vu depuis une partition enfant

L’OS invité dans une partition enfant ne peut pas voir le matériel physique directement dans la configuration usuelle de périphériques virtuels (la seule exception est un périphérique assigné via Discrete Device Assignment sous Windows Server, comme décrit dans la section précédente). Ce qu’il peut voir, ce sont des processeurs virtuels, un espace mémoire qui paraît être le sien, et des périphériques virtuels. Les requêtes 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 gérées directement par l’hyperviseur sans passer par la racine. Ce que la racine médiatise, ce sont les 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 requêtes vers les périphériques virtuels sont transférées à la partition racine via VMBus et analogues, le temps processeur et la traduction mémoire sont gérés directement par l'hyperviseur, et dans une configuration Discrete Device Assignment sous Windows Server seuls les périphériques assignés sont accédés directement
    gos2["OS invité（enfant）"] --> vcpu["Processeurs virtuels"]
    gos2 --> rest{"Mémoire ou périphériques ?"}
    rest --> gpa2["Espace mémoire privé"]
    rest --> vdev2["Périphériques virtuels"]
    vdev2 --> rootx["Transféré vers la racine"]
    rootx -.-> vbus["Via VMBus et analogues"]
    gos2 -.-> phys2["CPU, RAM, périphériques"]
    phys2 -.-> hid["Pas visible directement"]
    phys2 -.-> dda2["DDA : périphériques assignés"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

Figure 7 : dans la configuration usuelle 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 assigné via DDA sous Windows Server est l’exception.

Ce qui importe ici, c’est que pour une application qui s’exécute sur le Windows hôte, cette structure est presque transparente. Les appels à l’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 ou une exception configurée est rencontrée.

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

4.1. Trois types d’adresses

Dans la partie 1 de la série mémoire, nous avons suivi le flux par lequel une adresse virtuelle est traduite via la table des pages en une adresse physique (« The Moment a Virtual Address Becomes Physical RAM »). Dans un environnement virtualisé, un niveau de plus est ajouté sous cette traduction, et il y a trois types d’adresses.

Adresse	Abréviation	Qui la gère
Adresse virtuelle de l’invité	GVA	La table des pages de l’OS invité
Adresse physique de l’invité	GPA	L’adresse que l’OS invité croit « physique »
Adresse physique système	SPA	L’hyperviseur (l’emplacement réel en RAM)

L’OS invité traduit GVA en GPA avec sa propre table des 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 en RAM (SPA) est le travail de l’hyperviseur.

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

Si vous faites cette traduction de second niveau en logiciel seul, l’hyperviseur doit suivre chaque mise à jour de table des pages de l’invité une par une, ce qui n’est pas réaliste du point de vue des performances. Donc le processeur fournit un mécanisme qui parcourt les tables de traduction de second niveau dans le 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 capable de SLAT.⁴

flowchart TB
    accTitle: Traduction d'adresses à deux niveaux via SLAT
    accDescr: Une adresse virtuelle de l'invité est traduite en adresse physique de l'invité par la table des 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 des pages de l'OS invité| gpa["Adresse physique invité（GPA）"]
    gpa -->|"SLAT（tables 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 des pages de l’invité, et le processeur parcourt les deux dans le 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 dans la partie 2 utilise la propriété que « vous pouvez avoir une table de traduction SLAT différente par niveau de privilège » comme matériau pour une frontière de sécurité. La raison pour laquelle vous pouvez créer une mémoire que même le noyau ne peut pas voir, c’est que l’hyperviseur détient cette traduction de second niveau. Ceci devient un fil conducteur pour toute la série, donc retenez simplement un point : « le propriétaire des tables de traduction est l’hyperviseur ».

5. Du côté des E/S de périphériques — VMBus et deux types de périphériques

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

La manière classique de montrer un périphérique à une partition enfant est d’imiter entièrement du vrai matériel (un ancien contrôleur IDE, par exemple) en logiciel. La compatibilité est élevée parce que les pilotes inbox de l’OS invité fonctionnent tels quels, mais un VM Exit se produit chaque fois que l’invité touche un port d’E/S, et les performances ne montent pas.

flowchart TB
    accTitle: Pourquoi les E/S vers un périphérique émulé sont lentes
    accDescr: Chaque fois que l'invité opère un port d'E/S, le contrôle se transfère côté hyperviseur via un VM Exit, le périphérique est imité en logiciel, et l'invité est ramené, 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 se produit"]
    vex --> emu2["Le périphérique est émulé en logiciel"]
    emu2 --> back["Retour à l'invité via VM Entry"]
    back -->|Se répète à l'opération 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

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

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 côté partition racine, reçoit les requêtes de périphériques de l’enfant, et les relie à la pile périphérique/backend côté racine. Une requête peut atteindre un périphérique physique, ou elle peut ê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é côté partition enfant. Il envoie des requêtes au VSP via VMBus.

En prenant une requête de stockage de l’OS invité comme exemple, le flux ressemble à ceci. Le WriteFile de l’application invitée descend la pile d’E/S du noyau invité et, au bas, atteint le VSC (au lieu du vrai matériel). Le VSC met la requête sur VMBus et la remet au VSP dans la partition racine, et le VSP fait circuler la requête dans la pile d’E/S côté racine. Dans une configuration de disque virtuel (VHDX), cette écriture est traitée comme une écriture vers un fichier VHDX sur l’hôte et atteint finalement le disque physique. Cette approche s’appelle Enlightened I/O (des E/S conscientes de la virtualisation), et elle élève l’efficacité en contournant la couche d’émulation de périphérique.²

flowchart TB
    accTitle: Chemin d'E/S d'un périphérique synthétique
    accDescr: Une requête d'E/S d'une application dans la partition enfant atteint le VSC via le noyau invité, traverse VMBus jusqu'au VSP dans la partition racine, et sur la pile d'E/S côté racine dans laquelle le VSP relie elle peut atteindre un vrai périphérique 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 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 hôte（disque virtuel, commutateur, etc.）"]
    pdrv --> dev["Périphérique physique"]

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

Autrement dit, que les E/S disque ou le réseau d’une machine virtuelle soient rapides dépend non seulement du côté invité mais aussi de l’état de la pile d’E/S et des pilotes de périphériques côté partition racine. La raison pour laquelle l’observation côté hôte est indispensable lorsque vous enquêtez sur un problème de performances de 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 du vrai matériel afin que les pilotes inbox de l'invité fonctionnent mais est lent ; un périphérique synthétique est un pilote conçu exprès qui suppose 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["Émule le vrai matériel ; compatibilité d'abord"]
    emuP -.-> emuC["Intervention à chaque E/S ; lent"]
    syn -.-> synP["Conçu autour de VMBus ; rapide"]
    synP -.-> synC["Exige un pilote correspondant chez l'invité"]

Figure 11 : des deux types 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 de l’usage quotidien.

6. Pourquoi ce n’est pas le problème de quelqu’un d’autre, même si vous n’utilisez jamais de machine virtuelle

La structure jusqu’ici peut sembler « une histoire pour ceux qui dressent des machines virtuelles ». Comme l’ouverture le disait, toutefois, sous Windows actuel l’hyperviseur fait partie de la vie quotidienne.

Sécurité basée sur la virtualisation (VBS). Elle utilise l’hyperviseur Windows pour créer un environnement isolé et y loge des fonctionnalités 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: Fonctionnalités quotidiennes qui s'assoient sur le même hyperviseur
    accDescr: Non seulement les machines virtuelles Hyper-V mais aussi VBS, qui est 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（par défaut sur install. propre, etc.）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Pourquoi il tourne même sans machine virtuelle"]

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

Une chose de plus sur laquelle les gens marchent souvent en pratique est la coexistence avec un logiciel 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 analogues 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 des différences de performances et de fonctionnalités qui viennent avec le changement de mode sont parfois observées comme « après avoir activé Hyper-V (ou VBS), le logiciel de virtualisation a commencé à se comporter autrement ».

flowchart TB
    accTitle: Qui possède les extensions de virtualisation, et le chemin pour un logiciel 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（VT-x/AMD-V）"] --> hvon{"L'hyperviseur Windows tourne-t-il ?"}
    hvon -->|Non| direct["Un logiciel tiers peut l'utiliser directement"]
    hvon -->|Oui| own["L'hyperviseur a l'usage exclusif"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Un logiciel tiers compatible WHP s'exécute dessus"]
    third -.-> nowhp["Les implémentations non compatibles ne tournent pas, 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. Voyez-le par vous-même

Vous pouvez confirmer sur votre propre machine si un hyperviseur tourne.

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

# 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 renvoie l’état d’exécution de VBS comme un nombre (2 est « En cours d’exécution »).⁹

Une mise en garde. 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 encore 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 ensemble avec l’environnement d’exécution.

Ensuite, le classique depuis une invite de commandes.

systeminfo

Regardez « Hyper-V Requirements » à la fin de la sortie. Sur une machine où l’hyperviseur ne tourne pas encore, les exigences individuelles — prise en charge de SLAT, si les extensions de virtualisation sont activées, etc. — sont listées. Sur une machine où l’hyperviseur tourne déjà, au lieu des exigences vous obtenez une seule ligne : « A hypervisor has been detected. Features required for Hyper-V will not be displayed. »⁴ Cette seule ligne est donc une affirmation que votre Windows s’exécute au-dessus de quelque hyperviseur. Comme avec HypervisorPresent, vous devez 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 « Yes », 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 ne l’est pas sur Home.¹⁰

Dans l’interface graphique, vérifiez la ligne « Sécurité basée sur la virtualisation » sous « Résumé système » dans msinfo32. Notez que « Virtualisation : activée » dans le volet processeur du Gestionnaire des tâches n’affiche que si les extensions de virtualisation sont activées dans le microprogramme, ce qui est une information distincte de celle 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 Hyper-V Requirements apparaît il ne tourne pas encore donc vous vérifiez chaque exigence telle que SLAT, VM Monitor Mode Extensions et DEP, mais tout Yes 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{"Champ des exigences ?"}
    q1 -->|Détecté| running["L'hyperviseur tourne"]
    running -.-> runN["À l'intérieur de la racine"]
    runN -.-> runN2["sur un PC physique"]
    q1 -->|Listé| notyet["Ne tourne pas encore"]
    notyet --> q2{"Toutes les exigences Yes ?"}
    q2 -->|Toutes Yes| can["Le côté matériel est prêt"]
    can -.-> ed["Exige Pro / Ent / Edu"]
    q2 -->|Certaines No| uefi["Vérifier les éléments UEFI/BIOS"]

Figure 14 : le champ « Hyper-V Requirements » 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 « A hypervisor has been detected » 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 Windows montre l'état d'installation, et systeminfo ou HypervisorPresent montre l'état d'exécution ; chacune répond à une question différente
    q3{"Quelle question ?"}
    q3 --> fw{"Microprogramme ou Windows ?"}
    q3 --> c3["L'hyperviseur tourne-t-il ?"]
    fw --> a3["Extensions du microprogramme ?"]
    fw --> b3["Fonction Hyper-V active ?"]
    a3 -.-> a3t["Volet CPU du Gestionnaire"]
    b3 -.-> b3t["Fonctionnalités Windows"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["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 d’OS invité »

Les E/S des périphériques synthétiques traversent VMBus jusqu’au VSP dans la partition racine et passent 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 qui siège dans le stockage ou une carte réseau côté hôte. Le principe pour les problèmes de performances de 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 en tant que 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 hypercalls.²
La mémoire devient une traduction à deux niveaux GVA→GPA→SPA, et le second niveau est traité dans le matériel par SLAT (EPT/RVI). Hyper-V actuel exige SLAT.⁴
Les E/S de périphériques sont dominées 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 confirmer l’état d’exécution avec HypervisorPresent et systeminfo.

Le grand tableau de la partie 1 se condense dans ce seul schéma.

flowchart TB
    accTitle: Le grand tableau 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, les E/S de périphériques synthétiques sont transférées via VMBus et traitées par le VSP de la partition racine, et les périphériques émulés et Discrete Device Assignment ont d'autres chemins
    up["Partitions racine + enfants"] --> hvS["Hyperviseur"]
    hvS --> cpuS["Processeur : planifier les VP"]
    hvS --> memS["Mémoire : SLAT"]
    cpuS -.-> cpuN["VM Exit à l'interception"]
    memS -.-> memN["Traduction à deux niveaux"]
    memS ~~~ devS
    devS["Périphériques : E/S VMBus"] --> vspS["Le VSP côté racine traite"]
    devS -.-> devN["Émulé / DDA : autre"]

Figure 16 : la planification processeur et la traduction mémoire sont gérées directement par l’hyperviseur (VM Exit seulement à l’intervention), et les E/S de périphériques synthétiques sont médiatisées 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 — que l’hyperviseur dé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 ».

Domaines de conseil associés

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

Références

Microsoft Learn, Silicon assisted security. Sur le fait que VBS utilise la virtualisation matérielle pour isoler le Secure Kernel de l’OS ordinaire, et sur le fait que VBS et HVCI sont activées par défaut sur les appareils qui remplissent les prérequis lors d’une nouvelle installation de Windows 11. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. Sur le fait que l’hyperviseur fournit des partitions comme unité d’isolation ; que la partition racine crée des partitions enfants via l’API hypercall ; que les partitions s’exécutent dans un espace mémoire virtuel privé sans accès direct aux processeurs physiques ; sur les rôles de VMBus, VSP, VSC et Enlightened I/O ; et sur le fait que les extensions de virtualisation matérielle (Intel VT/AMD-V) sont exigées. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). Sur le fait qu’Hyper-V est un hyperviseur de Type 1, que la partition racine possède les périphériques d’E/S physiques, et que VMBus fournit une communication inter-partitions à haute performance qui utilise de la mémoire partagée. ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. Sur le fait qu’un processeur 64 bits capable de SLAT et les VM Monitor Mode Extensions sont exigés ; sur la possibilité de confirmer que les exigences sont remplies dans le champ « Hyper-V Requirements » de systeminfo ; sur le fait que « A hypervisor has been detected » s’affiche tant qu’un hyperviseur tourne ; et sur le fait que Discrete Device Assignment peut assigner un périphérique spécifique directement à une partition enfant. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. Sur le fait que VMMS (Virtual Machine Management Service) gère l’état des machines virtuelles dans les partitions enfants, et qu’un processus worker (VMWP) démarre en mode utilisateur dans la partition racine pour chaque machine virtuelle. ↩
Microsoft Learn, Comparing WSL Versions. Sur le fait que WSL2 exécute un vrai noyau Linux à l’intérieur d’une machine virtuelle utilitaire légère, et sur les mises en garde concernant son usage conjoint avec VMware et VirtualBox actuels. ↩
Microsoft Learn, Windows Sandbox architecture. Sur le fait que Windows Sandbox est un environnement Windows léger qui combine la technologie des conteneurs avec l’isolation par l’hyperviseur. ↩
Microsoft Learn, Windows Hypervisor Platform. Sur le fait qu’une API en mode utilisateur est fournie afin qu’une pile de virtualisation tierce puisse créer et gérer des partitions au-dessus de l’hyperviseur Windows. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Sur le fait de pouvoir confirmer l’état d’exécution de VBS (mode sécurisé virtuel) via VirtualizationBasedSecurityStatus sur la classe Win32_DeviceGuard. ↩
Microsoft Learn, Install Hyper-V. Sur le fait qu’Hyper-V est activable sous Windows 10/11 Pro ou Enterprise et analogues, et n’est pas installable sur l’édition Home. ↩

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

Les profondeurs de la virtualisation Windows (partie 3) — Des machines virtuelles qui démarrent en quelques secondes : pourquoi WSL2, Windows Sandbox et les conteneurs sont si légers

Pourquoi WSL2 et Windows Sandbox démarrent-ils en quelques secondes et paraissent-ils si légers ? Cet article explique les mécanismes, de...

Lire l’article

Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard

Lors d'une installation propre sur un matériel compatible, VBS est activée par défaut et utilise l'hyperviseur et SLAT pour créer une iso...

Lire l’article

L'API du pool de threads Win32 — de la concurrence sans créer de threads, via CreateThreadpoolWork

Vous semez des appels CreateThread partout dans votre code natif ? Cet article explique l'API du pool de threads Win32 refondue sous Vist...

Lire l’article

Tubes nommés en pratique — l'IPC standard de Windows, de la conception à la sécurité

Guide pratique des tubes nommés, mécanisme standard de communication inter-processus sous Windows. Cet article organise, à partir des sou...

Lire l’article

Que représente réellement la « mémoire utilisée » sous Windows ── Bien lire Working Set, Private Bytes, Commit et le fichier d'échange

La « mémoire » du Gestionnaire des tâches, Working Set, Private Bytes et Commit ne représentent pas la même valeur. Cet article explique ...

Lire l’article

Sujets associés

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

Thèmes techniques Windows

Portail des sujets sur le développement Windows, l'analyse des incidents et la valorisation des actifs existants.

Voir le sujet

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Développement d'applications Windows

Applications métier, intégration d'équipements et outils de communication, des besoins au développement.

Voir le service Nous contacter

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 prend le contrôle direct de 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 propriété 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 « A hypervisor has been detected » dans systeminfo, ou vérifiez Win32_ComputerSystem.HypervisorPresent.
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 sans aucun lien avec quiconque utilisant des 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 pas 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.

Voir le profil Nous contacter

Liens publics

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Retour au blog

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

1. La conclusion, d’abord

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

2.1. Un rappel de la protection par anneaux

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

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

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

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

3.2. Le monde vu depuis une partition enfant

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

4.1. Trois types d’adresses

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

5. Du côté des E/S de périphériques — VMBus et deux types de périphériques

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

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

6. Pourquoi ce n’est pas le problème de quelqu’un d’autre, même si vous n’utilisez jamais de machine virtuelle

7. Voyez-le par vous-même

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 »

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

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

9. Résumé

Articles connexes

Domaines de conseil associés

Références

Articles associés

Les profondeurs de la virtualisation Windows (partie 3) — Des machines virtuelles qui démarrent en quelques secondes : pourquoi WSL2, Windows Sandbox et les conteneurs sont si légers

Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard

L'API du pool de threads Win32 — de la concurrence sans créer de threads, via CreateThreadpoolWork

Tubes nommés en pratique — l'IPC standard de Windows, de la conception à la sécurité

Que représente réellement la « mémoire utilisée » sous Windows ── Bien lire Working Set, Private Bytes, Commit et le fichier d'échange

Sujets associés

Thèmes techniques Windows

Services liés à ce sujet

Développement d'applications Windows

Questions fréquentes

Profil de l’auteur

Go Komura