{"id":37939,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obshhie-printsipy-raboty-qemu-kvm\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"obshhie-printsipy-raboty-qemu-kvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Principes g\u00e9n\u00e9raux de fonctionnement de QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Principes
\n
\nMa compr\u00e9hension actuelle :<\/p>\n

1) KVM<\/h2>\n

\nKVM (Machine Virtuelle Bas\u00e9e sur le Noyau) \u2013 un hyperviseur (VMM \u2013 Gestionnaire de Machines Virtuelles) qui fonctionne comme un module sur le syst\u00e8me d'exploitation Linux. L'hyperviseur est n\u00e9cessaire pour ex\u00e9cuter un logiciel dans un environnement virtuel non existant tout en masquant le mat\u00e9riel physique r\u00e9el sur lequel ce logiciel fonctionne. L'hyperviseur agit comme un \u00ab interm\u00e9diaire \u00bb entre le mat\u00e9riel physique (h\u00f4te) et le syst\u00e8me d'exploitation virtuel (invit\u00e9).<\/p>\n

Puisque KVM est un module standard du noyau Linux, il b\u00e9n\u00e9ficie de toutes les fonctionnalit\u00e9s offertes par le noyau (gestion de la m\u00e9moire, planificateur, etc.). Par cons\u00e9quent, tous ces avantages profitent \u00e9galement aux invit\u00e9s (car les invit\u00e9s fonctionnent sur l'hyperviseur qui tourne dans le noyau du syst\u00e8me d'exploitation Linux).<\/p>\n

KVM est tr\u00e8s rapide, mais \u00e0 lui seul, il n'est pas suffisant pour lancer un syst\u00e8me d'exploitation virtuel, car une \u00e9mulation I\/O est n\u00e9cessaire. Pour l'I\/O (processeur, disques, r\u00e9seau, vid\u00e9o, PCI, USB, ports s\u00e9rie, etc.), KVM utilise QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (\u00c9mulateur Rapide) \u2013 un \u00e9mulateur de divers dispositifs qui permet d'ex\u00e9cuter des syst\u00e8mes d'exploitation con\u00e7us pour une architecture sur une autre (par exemple, ARM \u2192 x86). En plus du processeur, QEMU \u00e9mule divers p\u00e9riph\u00e9riques : cartes r\u00e9seau, disques durs, cartes graphiques, PCI, USB, etc.<\/p>\n

\u00c7a fonctionne comme ceci :<\/p>\n

Les instructions \/ code binaire (par exemple, ARM) sont convertis en code interm\u00e9diaire ind\u00e9pendant de la plateforme \u00e0 l'aide du convertisseur TCG (Tiny Code Generator), puis ce code binaire ind\u00e9pendant de la plateforme est converti en instructions \/ code cible (par exemple, x86).<\/p>\n

ARM \u2192 code_interm\u00e9diaire \u2192 x86<\/p>\n

En gros, vous pouvez ex\u00e9cuter des machines virtuelles sur QEMU sur n'importe quel h\u00f4te, m\u00eame avec d'anciens mod\u00e8les de processeurs qui ne supportent pas Intel VT-x (Technologie de Virtualisation Intel) \/ AMD SVM (Machine Virtuelle S\u00e9curis\u00e9e AMD). Cependant, dans ce cas, cela fonctionnera tr\u00e8s lentement, en raison du fait que le code binaire d'ex\u00e9cution doit \u00eatre recompil\u00e9 \u00e0 la vol\u00e9e deux fois, \u00e0 l'aide de TCG (TCG est un compilateur Just-in-Time).<\/p>\n

C'est-\u00e0-dire que QEMU est en soi super, mais il fonctionne tr\u00e8s lentement.<\/p>\n

3) Anneaux de protection<\/h2>\n

\n\"Principes
\n
\nLe code binaire sur les processeurs ne fonctionne pas n'importe comment, mais se situe \u00e0 diff\u00e9rents niveaux (anneaux \/ Anneaux de Protection) avec diff\u00e9rents niveaux d'acc\u00e8s aux donn\u00e9es, du plus privil\u00e9gi\u00e9 (Anneau 0) au plus restreint, r\u00e9gul\u00e9 et \u00ab avec des contraintes \u00bb (Anneau 3).<\/p>\n

Le syst\u00e8me d'exploitation (noyau OS) fonctionne en Ring 0 (mode noyau) et peut faire tout ce qu'il veut avec n'importe quelles donn\u00e9es et dispositifs. Les applications utilisateur fonctionnent au niveau Ring 3 (mode utilisateur) et ne peuvent pas faire ce qu'elles veulent, elles doivent \u00e0 chaque fois demander l'acc\u00e8s pour effectuer une op\u00e9ration (de cette fa\u00e7on, les applications utilisateur n'ont acc\u00e8s qu'\u00e0 leurs propres donn\u00e9es et ne peuvent pas \u00ab s'immiscer \u00bb dans le \u00ab bac \u00e0 sable \u00bb des autres). Les Rings 1 et 2 sont destin\u00e9s \u00e0 \u00eatre utilis\u00e9s par les pilotes.<\/p>\n

Avant l'invention d'Intel VT-x \/ AMD SVM, les hyperviseurs fonctionnaient en Ring 0, tandis que les invit\u00e9s fonctionnaient en Ring 1. \u00c9tant donn\u00e9 que le Ring 1 n'a pas suffisamment de droits pour le bon fonctionnement de l'OS, \u00e0 chaque appel privil\u00e9gi\u00e9 du syst\u00e8me invit\u00e9, l'hyperviseur devait modifier cet appel \u00e0 la vol\u00e9e et l'ex\u00e9cuter en Ring 0 (un peu comme le fait QEMU). C'est-\u00e0-dire que le code binaire de l'invit\u00e9 NON<\/i><\/b> s'ex\u00e9cutait directement sur le processeur, subissant \u00e0 chaque fois plusieurs modifications interm\u00e9diaires \u00e0 la vol\u00e9e.<\/p>\n

Les frais g\u00e9n\u00e9raux \u00e9taient consid\u00e9rables et c'\u00e9tait un gros probl\u00e8me, et \u00e0 ce moment-l\u00e0, les fabricants de processeurs, ind\u00e9pendamment les uns des autres, ont publi\u00e9 un ensemble d'instructions \u00e9tendu (Intel VT-x \/ AMD SVM) permettant d'ex\u00e9cuter du code des syst\u00e8mes d'exploitation invit\u00e9s DIRECTEMENT<\/i><\/b> sur le processeur h\u00f4te (en contournant toutes sortes d'\u00e9tapes interm\u00e9diaires co\u00fbteuses, comme cela se faisait auparavant).<\/p>\n

Avec l'apparition d'Intel VT-x \/ AMD SVM, un nouveau niveau sp\u00e9cial Ring -1 (moins un) a \u00e9t\u00e9 cr\u00e9\u00e9. Et maintenant, l'hyperviseur fonctionne \u00e0 ce niveau, tandis que les invit\u00e9s fonctionnent en Ring 0 et obtiennent un acc\u00e8s privil\u00e9gi\u00e9 au CPU.<\/p>\n

C'est-\u00e0-dire qu'en d\u00e9finitive :<\/p>\n