Remarque liminaire : ce document est une ressource pédagogique créée pour mes élèves, je la publie ici via une conversion brutale pour DotClear.

  • Lecteurs ciblés : Master 2 en informatique
  • Connaissances prérequises :
    • architectures matérielles
    • technologies des systèmes d’exploitation

Brève histoire des technologies de virtualisation : Xen, VMware, KVM, et QEMU [1]

Contexte

L’évolution des technologies de virtualisation sur architecture x86 représente l’un des aspects les plus significatifs de l’informatique moderne. Son histoire illustre comment les contraintes architecturales du processeur x86 ont conduit au développement de nouvelles solutions, puis de nouveaux paradigmes. Les quatre technologies abordées ici — Xen, VMware, KVM et QEMU - ont chacune apporté des approches distinctes pour résoudre les problèmes fondamentaux de la virtualisation x86. L’aboutissement actuel étant l’informatique par l’approche du nuage.

En complément de ces aspects techniques, la virtualisation répond aussi à des motivations économiques et opérationnelles fortes : consolidation des serveurs physiques, réduction des coûts d’infrastructure, meilleure résilience, flexibilité de déploiement… Mais tout ça on s’en fout ici.

Le défi fondamental de la virtualisation x86 : les anneaux de protection et leurs contraintes

Rappel : l’architecture x86 implémente un système de protection à quatre niveaux, appelés « anneaux de protection » (nommés de ring 0 à ring 3). Les systèmes d’exploitation non-ésotériques utilisent principalement deux de ces anneaux : le ring 0 pour l’espace noyau (kernel space) avec les privilèges maximaux, et le ring 3 pour l’espace utilisateur (user space) avec des privilèges restreints (1, 2) . Cette organisation hiérarchique garantit l’isolation et la sécurité du système en empêchant les applications utilisateur d’accéder directement aux ressources matérielles critiques.

Le problème fondamental de la virtualisation x86 réside dans l’existence d’instructions sensibles non privilégiées. Selon les critères de Popek et Goldberg (3, 4) , une architecture est virtualisable si toutes les instructions sensibles sont privilégiées. L’architecture x86 viole cette condition : certaines instructions se comportent différemment selon l’anneau d’exécution sans générer d’exception (trap). Ces instructions peuvent lire l’état du processeur ou modifier la configuration du système sans déclencher une interruption permettant à l’hyperviseur d’intervenir. C’est ce qu’on appelle pudiquement « le problème ».

Cette particularité architecturale signifie qu’un système d’exploitation conçu pour s’exécuter en ring 0 ne peut pas fonctionner correctement s’il est déplacé en ring 3 sans modifications. Les instructions privilégiées échoueront silencieusement ou produiront des résultats incorrects, compromettant la stabilité et la sécurité du système virtualisé.

La première solution : VMware et sa traduction binaire

VMware a été la première entreprise à résoudre efficacement pour la production — les geeks avaient déjà des trucs avant — le problème de virtualisation x86 avec une solution commerciale viable. L’approche appelée « traduction binaire dynamique » (dynamic binary Translation) (5, 6) représente une forme d’émulation partielle sophistiquée. Le système permet au code invité de s’exécuter directement sur le processeur physique dans la plupart des cas, mais intercepte et émule en logiciel les instructions problématiques.

La traduction binaire fonctionne en analysant dynamiquement le flux d’instructions du système invité. Lorsqu’une instruction sensible non privilégiée est détectée, l’hyperviseur VMware la remplace par une séquence d’instructions équivalentes qui produisent le même effet tout en maintenant l’isolation nécessaire. Cette technique permet d’exécuter des systèmes d’exploitation — même ésotériques — non modifiés avec des performances remarquables pour l’époque : 80 à 95 % des performances natives selon les mesures internes de VMware au début des années 2000.

Le succès commercial initial de VMware provient de cette capacité unique à virtualiser des systèmes invités sans modification, ouvrant la voie à l’adoption massive de la virtualisation dans les environnements d’entreprise.

QEMU : l’émulation universelle par compilation dynamique


## Architecture et fonctionnement de QEMU

QEMU (Quick EMUlator), développé par Fabrice Bellard et publié en 2005, représente une approche radicalement différente basée sur la compilation dynamique à la volée (just in time) (7, 8) . Contrairement aux solutions précédentes qui se concentraient sur la virtualisation depuis x86 vers x86, QEMU vise l’émulation universelle permettant l’exécution de code d’une architecture sur une autre ; par exemple ARM sur x86-64 ou inversement.

Le cœur de QEMU utilise un Tiny Code Generator qui traduit dynamiquement les instructions de l’architecture source vers l’architecture cible. Cette traduction s’effectue par blocs d’instructions, avec mise en cache des blocs traduits pour optimiser les performances lors d’exécutions répétées. Cette approche décomposée permet la portabilité : QEMU peut émuler plus de 15 architectures différentes (ARM, MIPS, PowerPC…)

QEMU fonctionne selon deux modes principaux : l’émulation complète de système (system emulation) qui virtualise une machine complète (CPU, mémoire, et périphériques), et l’émulation utilisateur (user emulation) qui permet d’exécuter des applications compilées pour une architecture différente.

Impact sur l’écosystème de virtualisation

L’intérêt de cette polyvalence en fait un outil indispensable pour le développement cross-platform, les tests de compatibilité, et la recherche en architecture des processeurs.

Aussi, bien que QEMU soit initialement plus lent que les solutions spécialisées en raison de sa généralité, il est devenu un composant fondamental de l’écosystème moderne de virtualisation. La plupart des hyperviseurs libres (KVM, Xen, VirtualBox…) utilisent QEMU pour l’émulation des périphériques tout en déléguant la virtualisation CPU à des mécanismes plus efficaces. Cette architecture modulaire permet de combiner les avantages de différentes approches : performance native pour le CPU grâce aux extensions matérielles, et flexibilité maximale pour les périphériques grâce à QEMU.

Xen et le bond de la paravirtualisation

Conception et principes fondamentaux

Xen, développé à l’Université de Cambridge par Ian Pratt et Keir Fraser, a introduit en 2003 une approche orthogonale appelée paravirtualisation (9). Plutôt que d’émuler ou de traduire les instructions problématiques, Xen propose de modifier directement les systèmes d’exploitation invités pour qu’ils puissent s’exécuter efficacement en ring 3 tout en coopérant explicitement avec l’hyperviseur.

La paravirtualisation repose sur le remplacement des instructions sensibles dans le noyau du système invité par des hypercalls — des appels directs à l’hyperviseur similaires aux appels système (syscalls). Cette modification permet au système invité de fonctionner en ring 3 tout en conservant un accès contrôlé aux ressources privilégiées via l’hyperviseur qui s’exécute en ring 0. L’avantage majeur de cette approche est l’élimination quasi-complète du surcoût (overhead) de virtualisation : les performances sont typiquement de 95 à 98 % des performances natives. Le problème n’est plus alors les pénalités de la virtualisation des instructions, mais l’accès aux ressources matérielles partagées et externes : cartes filles, bus, etc.

Architecture Dom0/DomU [2] et la gestion des ressources

Xen implémente une architecture unique basée sur des domaines. Le Domain 0 (Dom0) est un domaine privilégié exécutant une version modifiée de Linux qui gère les pilotes matériels et fournit les services de gestion. Les Domains Unprivileged (DomU) sont les machines virtuelles standard qui s’exécutent sous contrôle de l’hyperviseur. Cette séparation permet une isolation robuste tout en maintenant la flexibilité nécessaire pour la gestion des ressources physiques.

L’inconvénient majeur de la paravirtualisation est sa limitation aux systèmes libres. Les noyaux propriétaires comme Windows NT à l’époque ne pouvaient pas être modifiés pour supporter les hypercalls, nécessitant l’utilisation de techniques d’émulation plus coûteuses. Cette limitation a restreint l’adoption de Xen dans les environnements mixtes Linux/Windows typiques des entreprises Heureusement, les choses ont changé pour le mieux : les systèmes d’exploitation propriétaires se sont ouverts, et QEMU est arrivé en renfort.

L’émergence des extensions matérielles

Le contexte Microsoft et les spécifications de sécurité

Le développement des extensions matérielles de virtualisation trouve en partie son origine dans les besoins de sécurité avancée de Microsoft. Lors du développement de Windows Vista, Microsoft travaillait sur le projet « Next-Generation Secure Computing Base (NGSCB) » (10, 11) , anciennement appelé « Palladium », visant à implémenter des fonctionnalités de gestion des droits numériques (DRM) au niveau matériel. L’idée était d’exécuter les composants de sécurité critique dans un environnement isolé, protégé même du système d’exploitation principal.

En parallèle, Intel et AMD développaient déjà leurs propres projets de virtualisation matérielle (« Vanderpool » et « Pacifica »). La collaboration avec Microsoft a accéléré l’adoption de ces extensions.

Technologies Intel VT-x et AMD-V

Les extensions « Intel VT-x » (Virtualization Technology) et « AMD-V » (AMD Virtualization) (12, 13) ont été introduites respectivement en 2005 et 2006. Ces technologies ajoutent un nouveau mode d’exécution au processeur, permettant à l’hyperviseur de s’exécuter dans un contexte privilégié (VMX root mode pour Intel) tandis que les systèmes invités s’exécutent dans un contexte non privilégié (VMX non-root mode) tout en conservant l’illusion d’un accès ring 0.

Ces extensions résolvent élégamment le problème des instructions sensibles non privilégiées en introduisant des VM exits automatiques. Lorsqu’une instruction sensible est exécutée par un système invité, le processeur transfère automatiquement le contrôle à l’hyperviseur qui peut alors émuler l’instruction ou effectuer l’action appropriée. Cette approche élimine le besoin de modification des systèmes invités (comme dans la paravirtualisation) ou de traduction binaire complexe (tel VMware)1415.

KVM : l’intégration native dans Linux

Développement chez Qumranet

KVM (Kernel-based Virtual Machine) a été développé par Avi Kivity chez Qumranet, une jeune-pousse israélienne fondée en 2005 (16, 17). L’objectif initial était de créer une solution de virtualisation de bureau permettant aux entreprises de déployer des postes de travail Windows virtualisés sur infrastructure Linux. Cette approche visait particulièrement les environnements d’activité nécessitant de nombreux postes standardisés (centre d’appel, filiale bancaire, etc.).

La stratégie de Qumranet était elle aussi à contre-pied : plutôt que de développer un hyperviseur indépendant (comme Xen), ils ont choisi d’intégrer directement les fonctionnalités de virtualisation dans le noyau Linux existant. Cette approche tire parti de toute l’infrastructure de Linux : gestion de la mémoire, ordonnancement, pilotes de périphériques, et système de fichiers. KVM augmente essentiellement Linux en hyperviseur natif par l’ajout d’un module noyau. Reste ensuite à gérer toutes les couches service et fonctionnelle, la sécurité, etc. Bref il vaut mieux avoir un OS dédié pour un usage non-individuel car une distribution Linux de bureau (ni même de serveur) ne peut pas être magiquement transformée en hyperviseur correctement sécurisé et proposant les fonctionnalités attendues des utilisateurs.

Architecture et intégration au noyau Linux

KVM a été intégré au noyau Linux en février 2007 avec la version 2.6.20. Cette intégration garantit la maintenance à long terme et l’évolution continue avec les améliorations du noyau Linux.

L’architecture de KVM exploite les extensions matérielles VT-x/AMD-V pour la virtualisation CPU, tout en s’appuyant sur QEMU pour l’émulation des périphériques. Cette combinaison offre des possibilités intéressantes : performances natives pour le processeur grâce au support matériel, et flexibilité maximale pour les périphériques grâce à l’écosystème riche de QEMU. Les machines virtuelles KVM apparaissent comme des processus Linux standard, bénéficiant automatiquement de toutes les fonctionnalités du noyau. Mais cette approche la rend aussi dépendante des évolutions et des limitations de Linux : KVM ne peut qu’ajouter du code, et non pas en supprimer ou en modifier. Il y a donc des pénalités à la surcharge, et des risques liés à la cohabitation avec le reste du code Linux, même s’il n’est pas utilisé par KVM.

L’évolution moderne et la convergence technologique

Adoption universelle des extensions matérielles

Aujourd’hui, tous les grands hyperviseurs modernes utilisent les extensions matérielles Intel VT-x et AMD-V pour la virtualisation CPU. Cette standardisation a éliminé des différences fondamentales entre les approches, créant une base technologique commune pour l’ensemble de l’industrie. Les performances de virtualisation atteignent désormais 95 à 99 % des performances natives pour la plupart des charges de travail, rendant la virtualisation transparente pour les utilisateurs finaux.

Parallèlement, l’approche paravirtualisée de Xen a été adoptée universellement pour les pilotes de périphériques. Les pilotes paravirtualisés (standard technique « virtio ») remplacent l’émulation matérielle traditionnelle par une interface optimisée entre invité et hyperviseur. Cette convergence technique illustre comment les meilleures idées de chaque approche ont été intégrées dans un modèle hybride optimal : extensions matérielles pour le CPU, drivers paravirtualisés pour les périphériques. Bon, ça c’est la version simple et rose, dans la pratique des industriels se tirent dans les pattes et verrouillent via les licences privatives de leurs systèmes.

Technologies avancées de virtualisation

Les hyperviseurs modernes intègrent des technologies sophistiquées bien au-delà de la virtualisation CPU basique. La Second Level Address Translation (SLAT), implémentée via Intel EPT (Extended Page Tables) et AMD NPT (Nested Page Tables), permet la virtualisation efficace de la mémoire en éliminant le surcoût (overhead) des tables de pages shadow. Les IOMMU (Input-Output Memory Management Unit) étendent la virtualisation aux périphériques, permettant l’accès direct des machines virtuelles aux cartes réseau et de stockage via des technologies comme SR-IOV.

Ces avancées apportent des cas d’usage savoureux comme le GPU passthrough pour les tâches spécialisées (traitement du signal, réseaux de neurones…), la virtualisation réseau pour les environnements dans le nuage, et l’isolation de sécurité pour les applications critiques. L’évolution vers le calcul confidentiel avec Intel Trusted Execution Technology (TXT) et AMD Memory Guard montre que les travaux de recherche et d’ingénierie sur la virtualisation continuent fortement. On constate également un rapprochement avec les mécanismes de conteneurisation, qui doivent quant à eux répondre à des enjeux connexes.

Applications contemporaines et spécialisations

Xen dans les systèmes embarqués et de sécurité

Xen a trouvé sa place dans des domaines spécialisés où ses caractéristiques uniques offrent des avantages distincts. Le mode Dom0less, introduit récemment, permet de démarrer des machines virtuelles directement sans nécessiter un domaine de contrôle Linux complet (18) . Cette fonctionnalité est particulièrement intéressante dans l’industrie automobile et les systèmes embarqués où les contraintes de mémoire et de temps de démarrage sont critiques.

Qubes OS utilise Xen pour implémenter un modèle de sécurité security by isolation où chaque application s’exécute dans une machine virtuelle dédiée. Cette approche offre une protection maximale contre les malwares et les attaques par compromission, au prix d’une complexité d’utilisation accrue. Et croyez-moi, c’est tellement chiant que vous n’avez pas envie de l’utiliser au quotidien.

Les systèmes critiques de défense et de recherche adoptent également Xen pour ses garanties d’isolation.

QEMU dans le développement et la recherche

QEMU est indispensable pour le développement cross-platform et la recherche en architecture des processeurs. Les développeurs utilisent QEMU pour tester leurs applications sur des architectures non disponibles physiquement, accélérant significativement les cycles de développement. La communauté de recherche en systèmes s’appuie sur QEMU pour prototyper de nouvelles architectures et évaluer des modifications matérielles sans nécessiter de fabrication de puces.

L’intégration de QEMU avec des frameworks de simulation (comme gem5) permet des analyses de performance détaillées et l’exploration d’architectures expérimentales. Cette capacité est cruciale pour la recherche académique et le développement de futurs processeurs dans l’industrie semiconductrice.

Il n’existe aujourd’hui pas d’alternative réelle à QEMU.

Comparaison simple de solutions modernes

Technologie Forces principales Cas d’usage typiques Surcoût en performances
KVM Intégration Linux native, écosystème riche Nuage, centres de données légers 2–5 %
VMware ESXi Maturité enterprise, outils de gestion Centres de données d’entreprise 3–7 %
Xen Isolation robuste, empreinte mémoire réduite Nuage, systèmes embarqués, sécurité critique 2–5 %
QEMU Émulation universelle, développement ''cross-platform'' Développement, recherche, émulation héritée 10–50 %

Leçons et perspectives d’évolution

L’histoire de la virtualisation x86 illustre comment les contraintes architecturales stimulent l’innovation technologique. Le manque de sécurité dans la conception des instructions sensibles non privilégiées de l’architecture x86 a conduit à un écosystème technologique diversifié, qui commence à rendre pénible le travail à cause de l’accumulation des couches historiques. Les nouvelles architectures (puces pour l’informatique mobile, Apple avec ses puces M*) peuvent laisser espérer de nouvelles approches natives. Bien sûr cela veut dire redévelopper des écosystèmes logiciels entiers, mais ça on sait faire.

Cette évolution souligne également l’importance de la collaboration entre logiciel et matériel. Les extensions VT-x/AMD-V résultent d’une coopération étroite entre les concepteurs de processeurs (Intel, AMD) et les développeurs de logiciels de virtualisation. Cette synergie continue de s’approfondir avec les technologies émergentes comme les enclaves sécurisées (Intel SGX) et le calcul confidentiel.

Ligne de temps : des étapes de la virtualisation x86 de 1974 à 2025

  • 1974 :
    • Gerald J. Popek et Robert P. Goldberg publient « Formal requirements for virtualizable third generation architectures », établissant les critères théoriques de la virtualisation
  • 1998 :
    • Fondation de VMware à Palo Alto ; environ 20 employés et développement discret
  • 1999 :
    • Lancement officiel de VMware
  • 2001 :
    • VMware entre sur le marché des serveurs avec VMware GSX Server (hébergé) et VMware ESX Server (bare-metal)
  • 2002 :
    • VMware lance ESX Server 1.5, son premier hyperviseur professionnel
    • Introduction de vMotion (migration à chaud de machines virtuelles), début de la haute disponibilité dans la virtualisation
  • 2003 :
    • Première publication de Xen : « Xen and the Art of Virtualization »
    • VMware lance vCenter Server pour la gestion centralisée
  • 2004 :
    • AMD annonce ses extensions de virtualisation sous le nom de code Pacifica (futur AMD-V/SVM)
    • Intel développe ses extensions Vanderpool Technology (futur VT-x)
    • Première conférence VMworld
  • 2005 :
    • Fabrice Bellard publie le papier QEMU à l’USENIX Annual Technical Conference
    • Intel sort les premiers processeurs VT-x (Pentium 4)
  • 2006 :
    • AMD lance les premiers processeurs AMD-V (Athlon 64)
  • 2007 :
    • KVM intégré au noyau Linux mainline avec la version 2.6.20
    • Avi Kivity publie « kVM: the Linux Virtual Machine Monitor » au Ottawa Linux Symposium
  • 2009 :
    • Extension de AMD-V 2.0 avec Rapid Virtualization Indexing (RVI)
  • 2013 :
    • Introduction de Docker pour la conteneurisation, qui rassemble plusieurs technologies existantes (jails, cgroups, namespaces…)
  • 2019 :
    • VirtualBox 6.1 supprime définitivement le support de la virtualisation logicielle, nécessitant désormais VT-x/AMD-V
  • 2020 :
    • Mode Dom0less pour Xen dans les systèmes embarqués
    • Intégration native de virtio dans tous les hyperviseurs modernes
  • 2021 :
    • Émergence des microVM et convergence conteneur/virtualisation

Références académiques et industrielles

  • 1 Protection ring. Wikipedia. https://en.wikipedia.org/wiki/Protection_ring
  • 2 Bugnion, E., Nieh, J., Tsafrir, D. (2017). The Popek/Goldberg Theorem. In: Hardware and Software Support for Virtualization. Synthesis Lectures on Computer Architecture. Springer, Cham. https://doi.org/10.1007/978-3-031-01753-7_2
  • 3 Popek, G. J., & Goldberg, R. P. (1974). "Formal requirements for virtualizable third generation architectures." Communications of the ACM, 17(7), 412-421. https://dl.acm.org/doi/10.1145/361011.361073
  • 4 Popek and Goldberg virtualization requirements. Wikipedia. https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
  • 5 Adams, K., & Agesen, O. (2006). "A comparison of software and hardware techniques for x86 virtualization." ACM SIGPLAN Notices, 41(11), 2-13. ASPLOS 2006. https://pdos.csail.mit.edu/6.828/2018/readings/adams06vmware.pdf
  • 6 Bugnion, E., et al. (2012). "Bringing Virtualization to the x86 Architecture with the Original VMware Workstation." ACM Transactions on Computer Systems, 30(4). https://dl.acm.org/doi/10.1145/2382553.2382554
  • 7 Bellard, F. (2005). "QEMU, a Fast and Portable Dynamic Translator." USENIX Annual Technical Conference, FREENIX Track. https://www.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf
  • 8 "QEMU." Wikipedia. https://en.wikipedia.org/wiki/QEMU
  • 9 Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., ... & Warfield, A. (2003). "Xen and the art of virtualization." ACM SIGOPS Operating Systems Review, 37(5), 164-177. SOSP 2003. https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf
  • 10 Lavania, K. K., Gupta, M., Jain, N., & Sharma, S. (2011). "Next-Generation Secure Computing Base (NGSCB)." Journal of International Academy of Physical Sciences, 15(2), 445-453. https://www.iaps.org.in/journal/index.php/journaliaps/article/view/657
  • 11 Anderson, R. (2003). "Cryptography and competition policy: issues with ’trusted computing’." PODC ’03: Proceedings of the twenty-second annual symposium on Principles of distributed computing, 3-10. https://www.research.ed.ac.uk/en/publications/cryptography-and-competition-policy-issues-with-trusted-computing
  • 12 "x86 virtualization." Wikipedia. https://en.wikipedia.org/wiki/X86_virtualization
  • 13 Fisher-Ogden, J. "Hardware Support for Efficient Virtualization." UCSD Technical Report. https://cseweb.ucsd.edu/~jfisherogden/hardwareVirt.pdf
  • 14 "Understanding Hardware-Assisted Virtualization." Admin Magazine. https://www.admin-magazine.com/Articles/Hardware-assisted-Virtualization
  • 15 Goto, Y. (2011). "Kernel-based Virtual Machine Technology." Fujitsu Scientific & Technical Journal, 47(3), 362-368. https://hobby.esselfe.ca/docs/KVM-tech.pdf
  • 16 Kivity, A. (2007). "kvm: the Linux Virtual Machine Monitor." Ottawa Linux Symposium, 225-230. https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf
  • 17 "KVM: Kernel-based Virtualization Driver." Qumranet White Paper. https://docs.huihoo.com/kvm/kvm-white-paper.pdf
  • 18 "dom0less." Xen Project Documentation. https://xenbits.xen.org/docs/unstable/features/dom0less.html

Notes

[1] On va laisser de côté Hyper-V, hein. Ça sera mieux pour tout le monde 😛

[2] je vous renvoie à la 4e déclinaison du latin pour la signification et la prononciation