Faites le bon choix pour votre plateforme de virtualisation #2 : translation des adresses mémoire
Le premier bulletin de cette série traitera de la gestion de la mémoire.
La gestion de la mémoire est un facteur crucial au sein d’un système d’exploitable.
Dans le monde de la virtualisation, le mécanisme visant à gérer les allocations mémoire est d’autant plus complexe et coûteux qu’il faut prendre en compte deux niveaux de mémoire alors qu’un système traditionnel n’en a qu’un seul (d’un point de vue très simplifié).
Gestion de la mémoire sur un système classique
Sur un système Windows classique, il y a une notion de mémoire physique et une notion de mémoire virtuelle.
Le système alloue un espace mémoire au kernel et un espace mémoire au mode user dans ce que l’on appelle la mémoire virtuelle. Cette mémoire virtuelle est adressée dans la mémoire physique et la mémoire paginée (le pagefile).
Sur un système 32 bit, cet espace mémoire virtuel alloue par défaut 2GB au kernel et 2GB au mode user (avec le /3GB : 1GB pour le kernel et 3GB pour le mode user).
Sur un système 64 bit, la répartition est de 8TB pour le kernel et 8TB pour le mode user.
Dans les deux cas, même si la mémoire physique disponible est inférieure à 4GB.
Une partie du travail du Memory Manager est donc de traduire les adresses virtuelles en adresses physiques (qui se trouvent soit en mémoire physique soit dans le pagefile).
Gestion de la mémoire sur un système virtualisé
Sur un système où un hypervisor s’exécute, on retrouve un niveau de mémoire supplémentaire : la mémoire allouée aux machines virtuelles et vue par celles-ci comme de la mémoire physique.
Et c’est là où ça se complique un peu et où il est nécessaire d’utiliser tout un jeu d’acronymes barbares pour comprendre ce que doit assumer l’hypervisor:
- SPA (System Physical Address Space) : l’espace d’adressage physique réel (en gros dans les barrettes de RAM)
- GPA (Guest Physical Address Space) : l’espace d’adressage physique vu d’une machine virtuelle (dans la représentation qu’a la machine virtuelle de la mémoire physique qui lui est présentée par l’hypervisor)
- GVA (Guest Virtual Address Space) : l’espace d’adressage virtuel d’une machine virtuelle (ou de l’hôte)
Ces espaces sont représentés d’une autre manière dans le schéma ci-dessous :
Dans cette situation, le système d’exploitation s’exécutant dans la machine virtuelle traduit les adresses mémoires virtuelles (GVA) en adresses mémoires “physiques” (GPA) et l’hypervisor va traduit les adresses “physiques” des pages mémoires (GPA) de la machine virtuelle en adresses physiques réelles (SPA).
Ce qui correspond au schéma ci-dessous :
La translation d’adresse GPA vers SPA est donc prise en charge par l’hypervisor. C’est une solution de translation d’adresse logicielle.
Dans le détail, le processeur maintient une liste de correspondance des adresses de la mémoire virtuelle (GVA) utilisées par les machines virtuelles avec la mémoire physique (SPA) dans ce qu’on appelle un Translation Looksaside Buffer (TLB) . Lorsque la machine virtuelle tente d’accéder à une donnée ou une fonction qui est référencée par une adresse virtuelle mais que cette adresse virtuelle ne correspond à aucun contenu cela résulte en une faute de page (Page Fault). Cette faute de page est interceptée par l’hypervisor qui charge en mémoire la donnée ou la fonction et établit la translation d’adresse en spécifiant l’adresse physique dans la page TLB.
Comme on peut le comprendre, comme toute opération traitée par du logiciel, cette tâche de translation d’adresse est consommatrice en temps CPU. Bien plus que par du microcode embarqué dans du silicium.
C’est ce que nous appellons Second Level Address Translation (SLAT) .
Prise en charge de la translation d’adresse par le CPU
J’en viens alors au premier avantage qu’apportent les nouvelles fonctionnalités d’AMD et d’Intel ® : le déport de cette mécanique de l’hypervisor vers le CPU.
- Pour Intel ® , cette tâche est assurée par la technologie Intel VT Extended Page Tables
- Pour AMD, c’est la technologie Rapid Virtualization Indexing (ou Nested Page Tables) qui assume ce rôle
Les deux fondeurs utilisent une terminologie différente mais le principe est le même, et cela permet de libérer l’hypervisor de cette tâche lui donnant plus de temps pour effectuer des actions plus importantes sinon plus utiles.
Cette fonctionnalité mise en oeuvre par les CPUs est supporté par Hyper-V v2 disponible avec Windows Server 2008 R2.
Ressources
KB555223 - RAM, Virtual Memory, Pagefile and all that stuff
Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2 (en Anglais) – Extended Page Tables, chapitre 25.2
Rapid Virtualization Indexing with Windows Server 2008 R2 Hyper-V
Guillaume
Windows Core Support Escalation Engineer