Tiens, quelqu'un a déjà répondu pendant que j'étais en train de taper... Tant pis, je poste quand même =)
Je vais essayer de répondre... Que quelqu'un me corrige si je dis une connerie !
ring 0 : mode noyau. Tout est permis. Si on fait des conneries en ring 0, on doit rebooter en gros =)
ring 1 : on permet un peu moins de choses.
ring 3 : mode utilisateur. On permet beaucoup moins de choses : par exemple, si une appli en ring 3 veut écrire à un emplacement mémoire où elle a pas le droit => L'OS l'interrompt (ça segfault =). Et comme ça seule l'appli plante, pas tout le système.
(Qemu+kqemu) et Xen sont 2 solutions différentes de virtualisation.
Le but de la virtualisation est de pouvoir exécuter directement (ou avec quelques modifications) le code des OS invités sur le processeur de l'OS hôte (c'est-à-dire sans passer par une émulation).
Fonctionnement de Xen :
Xen est en ring 0 et les noyaux des OS invités sont en ring 1. C'est donc Xen qui attribue les ressources aux OS invités. Cela fait qu'il faut modifier les OS que l'on veut faire tourner sur un Xen. (Et ça pose problème avec Windows parce qu'il faudrait modifier son code source...)
Fonctionnement de Qemu+keqmu avant :
On ne modifie pas les OS invités. On va juste transformer le code qui pose problème (le code en ring 0 notamment) en un code équivalent qui pourra tourner en ring 3. Et on rappelle ce bloc de code recompilé dynamiquement à chaque fois à la place du code qui a posé problème.(Et il y a aussi un superviseur qui gère la mémoire, les interruptions de l'OS invité, ainsi que le passage en mode exécution directe ou recompilation dynamique...). La même chose que VMWare en gros.
Fonctionnement de Qemu+kqemu maintenant (à vue de nez) :
On y va en bourrin. On ne transforme plus le code qui pose problème et on croise les doigts pour que ça marche. Ça fait que si un OS (ou un driver) utilise une instruction asm qui renvoie un résultat différent en ring 0 et en ring 3, ça va bugger :/
Mais de toute façon, beaucoup de choses vont changer d'ici peu de temps avec l'apparition de la virtualisation matérielle dans le processeur (technologies Vanderpool chez Intel et Pacifica chez AMD). Là, le processur virtuel est directement dans le processeur physique. Ça fait que pour Xen, on ne devrait plus avoir à faire de modifs dans le code des OS invités. (Y aura juste un driver dans la machine hôte et voilà). Et pour UML (User Mode Linux), on pourrait faire tourner un UML en ring 0 et le voir comme un processus sur la machine hôte...
[^] # Re: demande d'explications
Posté par poil . En réponse à la dépêche Virtualisation complète avec kqemu. Évalué à 10.
Je vais essayer de répondre... Que quelqu'un me corrige si je dis une connerie !
ring 0 : mode noyau. Tout est permis. Si on fait des conneries en ring 0, on doit rebooter en gros =)
ring 1 : on permet un peu moins de choses.
ring 3 : mode utilisateur. On permet beaucoup moins de choses : par exemple, si une appli en ring 3 veut écrire à un emplacement mémoire où elle a pas le droit => L'OS l'interrompt (ça segfault =). Et comme ça seule l'appli plante, pas tout le système.
(Qemu+kqemu) et Xen sont 2 solutions différentes de virtualisation.
Le but de la virtualisation est de pouvoir exécuter directement (ou avec quelques modifications) le code des OS invités sur le processeur de l'OS hôte (c'est-à-dire sans passer par une émulation).
Fonctionnement de Xen :
Xen est en ring 0 et les noyaux des OS invités sont en ring 1. C'est donc Xen qui attribue les ressources aux OS invités. Cela fait qu'il faut modifier les OS que l'on veut faire tourner sur un Xen. (Et ça pose problème avec Windows parce qu'il faudrait modifier son code source...)
Fonctionnement de Qemu+keqmu avant :
On ne modifie pas les OS invités. On va juste transformer le code qui pose problème (le code en ring 0 notamment) en un code équivalent qui pourra tourner en ring 3. Et on rappelle ce bloc de code recompilé dynamiquement à chaque fois à la place du code qui a posé problème.(Et il y a aussi un superviseur qui gère la mémoire, les interruptions de l'OS invité, ainsi que le passage en mode exécution directe ou recompilation dynamique...). La même chose que VMWare en gros.
Fonctionnement de Qemu+kqemu maintenant (à vue de nez) :
On y va en bourrin. On ne transforme plus le code qui pose problème et on croise les doigts pour que ça marche. Ça fait que si un OS (ou un driver) utilise une instruction asm qui renvoie un résultat différent en ring 0 et en ring 3, ça va bugger :/
Mais de toute façon, beaucoup de choses vont changer d'ici peu de temps avec l'apparition de la virtualisation matérielle dans le processeur (technologies Vanderpool chez Intel et Pacifica chez AMD). Là, le processur virtuel est directement dans le processeur physique. Ça fait que pour Xen, on ne devrait plus avoir à faire de modifs dans le code des OS invités. (Y aura juste un driver dans la machine hôte et voilà). Et pour UML (User Mode Linux), on pourrait faire tourner un UML en ring 0 et le voir comme un processus sur la machine hôte...