À l'origine, vous ne pouviez pas laisser le système d'exploitation invité utiliser du vrai matériel car vous n'aviez aucun moyen de le contrôler. Si vous tentiez de l'exécuter sur le vrai CPU, vous n'aviez aucune garantie qu'il rendrait le contrôle au système d'exploitation hôte.
La virtualisation telle que vous la décrivez est implémentée dans le matériel en permettant à certaines règles et restrictions d'être appliquées au niveau du matériel, qui peut être géré par le système d'exploitation hôte. Cela permet au système d'exploitation hôte de définir des règles sur ce que l'invité peut et ne peut pas faire, puis d'exécuter réellement l'invité sur du matériel réel. Si l'invité essaie de faire quelque chose avec le vrai matériel qui viole les règles (comme essayer d'accéder à un périphérique de disque), le matériel suspendra l'invité et enverra à l'hôte une interruption, ce qui permet à l'hôte de fournir une réponse (telle que renvoyant des données à partir d'un périphérique de disque émulé), puis reprenez l'invité.
Voici un exemple simplifié du processus:
OS hôte: Hé CPU, j'ai besoin que vous exécutiez ce code virtualisé. Appelez-moi si elle veut faire quelque chose qui ne consiste pas seulement à exécuter des instructions.
CPU hôte: vous l'avez!
Le processeur hôte enregistre tous les registres et états d'hôte, puis commence à exécuter le code du système d'exploitation invité
OS invité: je suis vivant! Hé CPU, pouvez-vous me procurer ce fichier?
CPU hôte: Euh ... bien sûr. Un moment.
Le CPU hôte enregistre tous les registres et états d'invité, puis restaure tous les registres et l'état d'
hôte CPU hôte: Hey Host OS, l'invité voulait ce fichier!
OS hôte: Oh, donnez-leur ceci: fichier depuis le disque dur virtuel
CPU hôte: vous l'avez!
Le CPU hôte enregistre tous les registres et l'état des hôtes, restaure les registres et l'état des invités, puis commence à exécuter le code OS invité
CPU hôte: voici ce fichier!
OS invité: doux, merci!
La principale différence est ici dans un émulateur, le système d'exploitation invité ne s'exécute jamais réellement sur le matériel. Avec la virtualisation, le système d'exploitation hôte configure les limitations dans le processeur, puis exécute réellement le code invité sur le processeur physique. L'exemple ci-dessus est extrêmement simplifié, mais la mémoire, les E / S disque et même la mise en réseau peuvent être contrôlées sur les derniers processeurs d'aujourd'hui, ce qui leur permet d'être interfacés en toute sécurité sans avoir à déranger le système d'exploitation hôte à chaque fois. Tant que l'invité n'essaie pas d'aller en dehors des limites virtualisées, le système d'exploitation hôte 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, ce n'est qu'une étape de plus dans une longue histoire de virtualisation et de contrôle. (Aucune garantie que cela est dans le bon ordre ou exhaustif, mais devrait donner un bon aperçu de départ)
À l'origine, il n'y avait pas de virtualisation. Les processus partageaient tous le même espace mémoire, tous avaient un accès complet au matériel, et la capacité d'effectuer plusieurs tâches dépendait entièrement de l'arrêt d'un processus et de la maîtrise du processus suivant. Si le système d'exploitation voulait avoir une sorte de contrôle sur un processus, il devait exécuter le processus dans un émulateur (personne ne l'a fait, car c'était trop douloureusement lent).
La première était la mémoire privilégié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, ce qui lui permet d'agir comme une passerelle vers ces actions privilégiées. Un exemple est la possibilité de lire / écrire des données sur le matériel. Cela empêche les processus de lire / écrire directement sur le disque dur et les oblige à la place à demander au système d'exploitation de lire / écrire pour eux. Cela signifie que le système d'exploitation peut vérifier si le processus est autorisé avant d'effectuer l'action.
Vint ensuite le «temps» virtualisé pour ainsi dire. Le système d'exploitation pourrait configurer la CPU pour interrompre le processus actif à des intervalles définis, lui permettant de prendre le contrôle de la planification et de basculer entre les processus. Le système d'exploitation pouvait désormais exécuter des processus directement sur le matériel et toujours les empêcher d'utiliser à mauvais escient le temps processeur. Cela a été fourni par une minuterie matérielle .
Vient ensuite la mémoire virtualisée : le problème avec la mémoire partagée est que tout processus peut lire la mémoire de tout autre processus. Que se passe-t-il lorsque le programme de Mary lit le mot de passe de Bob depuis son navigateur Web? La mémoire virtuelle permet au système d'exploitation de mapper la mémoire qu'un processus voit sur différentes parties de la mémoire physique, ou même de les déplacer complètement de la mémoire physique (vers le fichier d'échange). Chaque fois qu'un processus essaie de lire ou d'écrire dans la mémoire, la VMMU (unité de gestion de mémoire virtuelle) du CPU recherche où il est mappé dans la mémoire physique et y exécute l'action. S'il est mappé hors de la mémoire, le processeur appelle le système d'exploitation pour récupérer la page en mémoire à partir du fichier de page.
Très bien, donc à ce stade, nous avons atteint les 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, sauf si le système d'exploitation le permet spécifiquement. À ce stade, les processus sont effectivement «virtualisés». Ce support existe depuis longtemps , donc vous n'entendez pas vraiment les gens parler de processus virtualisés, car on suppose simplement que tous les processus sont virtualisés maintenant.
Mais pourquoi les OS virtualisés sont-ils spéciaux? Pourquoi ne pouvons-nous pas simplement en lancer un en tant que processus et le laisser faire sa propre chose? Eh bien, le problème est qu'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 - fondamentalement, l'OS s'attend à être la règle suprême de l'ordinateur, et ils ne font tout simplement pas '' t fonctionne si ce n'est pas le cas. Les extensions de «virtualisation matérielle» (AMD-V pour AMD et VT-x pour Intel) permettent au système d'exploitation hôte de fournir un ensemble virtualisé de contrôles de processus virtuels (mémoire virtuelle privilégiée, temporisations matérielles virtuelles, mémoire virtuelle virtuelle).