Initialement, vous ne pouviez pas laisser le système d'exploitation invité utiliser du matériel réel car vous n'aviez aucun moyen de le contrôler. Si vous essayiez de l'exécuter sur le CPU réel, vous n'aviez aucune garantie qu'il rendrait le contrôle à l'hôte OS.
La virtualisation, telle que vous la décrivez, est implémentée dans le matériel en permettant l'application de certaines règles et restrictions au niveau matériel, qui peuvent être gérées par l'hôte OS. Cela permet à l'hôte OS de définir des règles sur ce que l'invité peut ou ne peut pas faire, et ensuite d'exécuter réellement l'invité sur du matériel réel. Si l'invité tente de faire quelque chose avec le matériel réel qui viole les règles (comme tenter d'accéder à un dispositif de disque), le matériel suspendra l'invité et enverra une interruption à l'hôte, ce qui permettra à l'hôte de fournir une réponse (comme le retour de données provenant d'un dispositif de disque émulé), puis de reprendre l'invité.
Voici un exemple simplifié du processus :
Hôte OS : Hé CPU, j'ai besoin que tu exécutes ce code de manière virtualisée. Appelle-moi s'il veut faire quelque chose qui n'est pas juste exécuter des instructions.
Hôte CPU : C'est bon !
L'hôte CPU sauvegarde tous les registres et l'état hôte, puis commence à exécuter le code de l'OS invité
OS invité : Je suis vivant ! Hé CPU, peux-tu me chercher ce fichier ?
Hôte CPU : Euh... bien sûr. Un instant.
L'hôte CPU sauvegarde tous les registres et l'état de l'invité, puis restaure tous les registres et l'état hôte
Hôte CPU : Hé Hôte OS, l'invité voulait ce fichier !
Hôte OS : Ah, donne-leur ça : Fichier du disque dur virtuel
Hôte CPU : C'est bon !
L'hôte CPU sauvegarde tous les registres et l'état hôte, restaure les registres et l'état de l'invité, puis commence à exécuter le code de l'OS invité
Hôte CPU : Voilà ce fichier !
OS invité : Génial, merci !
La différence clé ici est qu'avec un émulateur, l'OS invité ne s'exécute jamais réellement sur le matériel. Avec la virtualisation, l'hôte OS configure des limitations dans le CPU, et exécute ensuite réellement le code de l'invité sur le CPU physique. L'exemple ci-dessus est extrêmement simplifié, mais la mémoire, l'entrée/sortie disque, voire même le réseau peuvent être contrôlés sur les derniers processeurs d'aujourd'hui, ce qui leur permet d'être interfacés en toute sécurité sans avoir à déranger l'hôte OS à chaque fois. Tant que l'invité ne tente pas de sortir des limites virtualisées, alors l'Hôte OS peut ne pas avoir de code en cours d'exécution s'il n'a rien à faire à un moment donné.
Pour ajouter un peu de perspective, cela n'est qu'une étape de plus dans une longue histoire de virtualisation et de contrôle. (Pas de garantie que cela soit dans le bon ordre ou exhaustif, mais cela devrait donner un bon aperçu de départ)
Initialement, il n'y avait pas de virtualisation. Les processus partageaient tous le même espace mémoire, avaient tous un accès complet au matériel, et la capacité de multitâche dépendait entièrement d'un processus s'arrêtant de lui-même et passant le contrôle au processus suivant. Si l'OS voulait avoir un quelconque contrôle sur un processus, il devait exécuter le processus dans un émulateur (personne ne le faisait, car c'était bien trop lent).
En premier est venu la Mémoire Privée : certaines actions qui ne peuvent être effectuées que par des régions spéciales de la mémoire. Ces régions sont occupées par l'OS, lui permettant d'agir comme une passerelle vers ces actions privilégiées. Un exemple est la capacité de lire/écrire des données à un matériel. Cela empêche les processus de lire/écrire directement sur le disque dur, et les force à demander à l'OS de lire/écrire pour eux. Cela permet à l'OS de vérifier si le processus a la permission avant d'effectuer l'action.
Ensuite est venu "l'émulation" du "temps", pour ainsi dire. L'OS pouvait configurer le CPU pour interrompre le processus actif à des intervalles définis, lui permettant de prendre le contrôle de la planification et de passer d'un processus à l'autre. L'OS pouvait désormais exécuter des processus directement sur le matériel et toujours les empêcher de mal utiliser le temps CPU. Cela était assuré par un minuteur matériel.
Ensuite est venu la mémoire virtuelle : Le problème avec la mémoire partagée est que n'importe quel processus pouvait lire la mémoire d'un autre processus. Que se passe-t-il lorsque le programme de Marie lit le mot de passe de Bob depuis son navigateur web ? La mémoire virtuelle permet à l'OS de mapper la mémoire qu'un processus voit à différentes parties de la mémoire physique, voire même de les déplacer hors de la mémoire physique entièrement (vers le fichier de page). Chaque fois qu'un processus tente de lire ou d'écrire dans la mémoire, l'UMVM (unité de gestion de mémoire virtuelle) du CPU recherche où elle est map...
D'accord, à ce stade, nous en sommes à peu près aux débuts du processeur X86, où nous pouvons exécuter des processus en toute sécurité et les empêcher activement de prendre le contrôle du système à moins que l'OS ne les y autorise spécifiquement. À ce stade, les processus sont effectivement "virtualisés". Ce support existe depuis longtemps, donc on n'entend pas vraiment les gens parler de processus virtualisés, car on suppose que tous les processus sont maintenant virtualisés.
Mais pourquoi les OS virtualisés sont-ils spéciaux ? Pourquoi ne pouvons-nous pas simplement en démarrer un en tant que processus et le laisser faire son truc ? Eh bien, le problème est que, en tant qu'OS, le système invité s'attend à pouvoir accéder et utiliser les mêmes contrôles que l'hôte utilise pour contrôler les processus - en gros, l'OS s'attend à être le souverain suprême de l'ordinateur, et ils ne fonctionnent tout simplement pas si ce n'est pas le cas. Les extensions de "Virtualisation Matérielle" (AMD-V pour AMD, et VT-x pour Intel) permettent à l'hôte OS de fournir un ensemble virtualisé de contrôles de processus virtuels (mémoire privilégiée virtuelle, minuteurs matériels virtuels, mémoire virtuelle virtuelle).
