Les défis de la virtualisation

Précédent Suivant

La faute de l’ISA x86

Un processeur n’est capable d’exécuter qu’un nombre réduit d’instructions élémentaires. Cet ensemble, appelé ISA (Instruction Set Architecture), est stocké en mémoire et n’est pas modifiable. Il définit les capacités d’un processeur, dont l’architecture matérielle est ensuite optimisée pour exécuter les instructions de l’ISA le plus efficacement possible. Plusieurs ISA existent. Le plus connu dans le monde PC est le x86, utilisé depuis l’origine par les processeurs Intel et repris par les puces d’AMD. On peut aussi citer le PowerPC, l’Alpha AXP, le SPARC, ou encore les récents AMD64 ou EM64T.

Très répandu, voire même omniprésent, le x86 n’est pour autant pas exempt de défauts. D’un point de vue de la virtualisation il fait pour ainsi dire partie des moins bons ISA. Mais comme il est hors de question de le remplacer, il fallait trouver des solutions de contournement. C’est ce qu’ont développé Intel et AMD avec respectivement VT et Pacifica, ou AMD-V.

Si le x86 se prête mal à la virtualisation c’est à cause de 17 instructions critiques, mais non privilégiées. Si vous n’avez rien compris à la phrase précédente lisez ce qui suit :

Toutes les instructions de l’ISA x86 ne sont pas sur un pied d’égalité. Parmi elles, certaines peuvent modifier la configuration des ressources du processeur ; elles sont dites critiques. Pour protéger la stabilité de la machine, ces instructions ne peuvent pas être exécutées par tous les logiciels. Du point de vue du CPU, les logiciels appartiennent à 4 catégories, ou niveaux d’abstraction : les anneaux 0, 1, 2, 3. Chaque anneau définit un niveau de privilège décroissant. Les instructions les plus critiques réclament les privilèges les plus élevés, d’ordre 0. Malheureusement, sur un processeur x86, 17 de ces instructions critiques peuvent être exécutées même par des logiciels de rang 1, 2, ou 3.

Cela constitue un gros problème pour les logiciels de virtualisation. Un système d’exploitation est en effet prévu pour fonctionner en anneau 0 et utiliser des instructions critiques afin de répartir les ressources du processeur entre les différentes applications. Mais lorsqu’il est en situation d’invité, sur une machine virtuelle, le même OS ne doit pas pouvoir modifier les ressources matérielles, sous peine de faire planter tout le système. Seul l’hyperviseur doit avoir ces droits. Il faut donc que toutes les instructions critiques soient interceptées.

C’est très facile pour toutes les instructions privilégiées. L’OS est alors exécuté en ring 3, comme les applications, et toutes les requêtes d’instructions privilégiées déclenchent une erreur qui est traitée par le VMM. C’est beaucoup plus compliqué pour les 17 instructions dangereuses et non privilégiées. Celles-ci ne déclenchant pas d’erreur automatique, elles doivent être détectées au coup par coup par le VMM, puis réinterprétées. Il en résulte une surcharge en calcul importante, et une grande complexité du logiciel hyperviseur.

Les autres coupables

Au-delà des défauts du x86, la virtualisation du matériel pose d’autres soucis. Par exemple, l’OS invité suppose qu’il a accès à la totalité de la mémoire de la machine. Or ce n’est pas le cas puisqu’il la partage avec les autres OS et le VMM. Ce dernier doit donc surveiller et intercepter les tentatives d’accès de l’OS invité à des adresses mémoires non disponibles, et les détourner. Autre exemple, le fait que l’OS invité fonctionne au même niveau (anneau 3) que les applications invitées met en danger sa stabilité. Enfin, l’OS invité ne doit jamais découvrir qu’il tourne en réalité en anneau 3, sous peine de plantage. Le VMM doit donc là encore intercepter les instructions susceptibles de révéler l’état des privilèges de l’invité.

Dernier souci, la gestion des périphériques : générant des accès en mémoire et des interruptions, les périphériques doivent être gérés par le VMM qui doit ensuite les émuler pour chaque OS invité. Une source supplémentaire de ralentissement, et surtout une perte énorme en termes de fonctionnalités.