Journal La virtualisation directement dans le CPU

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
août
2005
L'an prochain Intel et AMD vont sortir leurs nouvelles puces avec des fonctions de virtualisation directement gravées dans le silicium.
Pour avoir un aperçu technique complet de ces fonctions (Vanderpool pour Intel et Pacifica pour AMD) le site TheInquirer a sorti depuis le début de l'année une bonne suite d'articles.

Intel Vanderpool (articles datant de février) :
Partie 1 : http://www.theinquirer.net/?article=21448(...)
Partie 2 : http://www.theinquirer.net/?article=21449(...)
Partie 3 : http://www.theinquirer.net/?article=21450(...)
Partie 4 : http://www.theinquirer.net/?article=21451(...)

AMD Pacifica (articles datant de juin) :
Partie 1 : http://www.theinquirer.net/?article=23721(...)
Partie 2 : http://www.theinquirer.net/?article=23772(...)
Partie 3 : http://www.theinquirer.net/?article=23840(...)

Lors de l'IDF (forum des devs Intel) c'est Vanderpool 2 et 3 qui ont été évoquées.
Le but est clair : This time, it is not just limited to the CPU, it pulls in the Northbridge, memory controllers, buses and peripherals. It is a lot more of an attempt to virtualise the system rather than only the processor.

Le futur de la technologie Vanderpool par Intel (sorti aujourd'hui) : http://www.theinquirer.net/?article=25576(...)

  • # Bonne nouvelle...

    Posté par  . Évalué à 1.

    ... pour les linuxiens, cela devrait nous permettre de faire tourner Windows (et n'importe quel autre OS) sous Linux, à vitesse quasi native, et sans problème de compatibilité.

    Mais quel dommage qu'Intel et AMD n'aient pas adopté une norme commune, ça promet encore un beau bordel dans le futur et des transistors qui ne servent à pas grand chose :(

    • [^] # Re: Bonne nouvelle...

      Posté par  (site web personnel) . Évalué à 10.

      >> cela devrait nous permettre de faire tourner Windows

      oui enfin bon à priori c'est pas le but des linuxiens de faire tourner Windows. ça sera plus utile pour les serveurs afin d'isoler les tâches et éviter que les failles ne donne accès à tout le reste de la machine.

      • [^] # Re: Bonne nouvelle...

        Posté par  . Évalué à 10.

        Pourtant combien de linuxiens ont un double boot parce que telle ou telle appli ne passe pas sous Linux ? Combien d'utilisateur de Windows seraient susceptibles de passer totalement à Linux s'il était possible de jouer à tous les jeux sans avoir à redémarrer sous Windows ou à galérer avec Wine ?

        Évidemment, ce n'est pas un fin en soi, mais c'est comme les drivers non-libres de NVidia ou ATI : c'est pas l'idéal, mais c'est quand même mieux avec.

        • [^] # Re: Bonne nouvelle...

          Posté par  . Évalué à 4.

          Mouais. Attention, la vitualisation, c'est beaucoup plus simple avec des serveurs qu'avec des desktop. Pour switcher d'une config a l'autre c'est un peu le meme bordel que pour faire une mise en hibernation (veille sur disque dur). Il faut quasiment fermer tous les drivers.
          Faut remettre la carte video dans le meme etat qu'avant, idem pour l'imprimante, la webcam, le lecteur de cartes SDIO, etc..
          Pour un serveur, il y a peine que le driver ethernet a reconfigurer..

          • [^] # Re: Bonne nouvelle...

            Posté par  . Évalué à 5.

            Oula, de quoi tu parles ? La virtualisation desktop, c'est un VMWare Workstation ou QEMU qui laisse le CPU (équipé de VT ou Pacifica) faire ce qui est fait aujourd'hui logiciellement, mais plus rapidement.

            Il ne s'agit pas de donner accès au système invité aux périphériques physiques. L'hôte simule des périphériques (carte graphique, carte réseau), exactement comme ce qui est fait aujourd'hui, mais moins rapidement. Ça permet d'avoir son OS invité dans une fenêtre de l'OS hôte, les deux fonctionnant parallèlement.

            • [^] # Re: Bonne nouvelle...

              Posté par  . Évalué à 1.

              Le gars parlait de tourner windows pour les jeux en virtualisation. Ca veut dire un acces privilegie a la carte video et la carte son. Je vois mal comment materiellement ca serra possible.

              • [^] # Re: Bonne nouvelle...

                Posté par  . Évalué à 2.

                Non, aucun accès privilégié n'est nécessaire, il suffit d'écrire un pilote pour le système invité (disons Windows) qui émule, par exemple, la carte graphique ou la carte son. C'est comme ça que ça marche déjà avec VMWare, ils fournissent des pilotes Windows à installer.

                Pour la 3D par exemple, puisqu'on parle de jeu, le pilote Windows (Direct3D) ne ferait que « traduire » les appels qui lui sont faits par les jeux en appels OpenGL vers la machine hôte. Nullement besoin d'accès privilégié, on émule.

                • [^] # Re: Bonne nouvelle...

                  Posté par  . Évalué à 0.

                  Donc on sera encore tres loin du full speed. L'emulation Direct3d en opengl, on connais, ca s'appelle cedega, et ca fait perdre 50% de perfs..

        • [^] # Re: Bonne nouvelle...

          Posté par  . Évalué à 3.

          Mouai...
          le contraire peut devenir vrai aussi: quitte à avoir une license, qu'est-ce qui désormais empêcherait l'utilisateur de garder son windows, et d'avoir à côté une distribution linux qui s'ouvrirait depuis leur windows, juste pour faire mumuse de temps en temps?
          je suppose qu'on peut même envisager un prog. windows qui permettrait alors de faire tourner ttes les applis linux!
          nous on sait pourquoi on a migré, mais l'utilisateur lambda, qui se pose pas la question, lui...

          • [^] # Re: Bonne nouvelle...

            Posté par  . Évalué à 2.

            Tout à fait d'accord, la virtualisation ca permet de faire tourner plusieurs OS, dans un sens comme dans l'autre. Et si ca peut rendre la migration vers les LL plus simple, c'est bien®.

            Là où ca peut être déterminant (en bien comme en mal) c'est quand la machine est équipée de Palladium TCPA et autres verrouillages hardware pour DRM.

            Pourra-t-on faire tourner un Linux virtualisé sur une machine qui n'accepte de booter qu'un Windows signé ?
            Sera-ce* la seule manière de le faire ?
            MacOS pourra-t-il tourner sur un vulgaire PC virtualisé ?
            Est-ce que ce sera la fin des failles par buffer overflow (à moins qu'on invente le vitualization overflow ?) ?


            * oui, je sais, ca me fait bizarre aussi. Mais ca me semble grammaticallement logique.

  • # Un peu d'aide...

    Posté par  (site web personnel) . Évalué à 8.

    Excusez moi mais j'ai du mal a comprendre ce qu'est la "virtualisation" si l'un d'entre vous pourrez me (nous, je ne pense pas être le seul dans ce cas...) l'expliquer ca serait sympa ;)
    Merci :)

    • [^] # Re: Un peu d'aide...

      Posté par  . Évalué à 4.

      Article Wikipédia : http://fr.wikipedia.org/wiki/Virtualisation_%28informatique%29(...)

      En très gros, c'est une technologie qui permet d'émuler un CPU (voire tout un système). Jusqu'à aujourd'hui, c'était fait logiciellement, donc lent (VMWare Workstation, Virtual PC de Microsoft, l'excellent logiciel libre QEMU de Fabrice Bellard).

      Intel et AMD s'apprêtent à intégrer des technologies de virtualisation dans leurs processeurs (au moyen d'un nouveau jeu d'instruction), ce qui permet de faire la même chose, mais beaucoup plus rapidement (à vitesse native), et donc a priori de démocratiser la chose et de la rendre utile alors que ça ne l'était pas jusqu'à maintenant.

      • [^] # Re: Un peu d'aide...

        Posté par  . Évalué à 4.

        C'est plus generique que cela. Dans la pluspart des presentations que j'ai eu, il est tout a fait possible d'avoir un OS minimaliste qui ne s'occupe que de la virtualisation, et tout tes OS, y comprit ton Linux prefere, tournent en paralles dans des machines virtuelles.

        Effectivement, si Linux est capable de dialoguer avec le hard pour gerer la virtualisation directement, cela marcherait comme tu le decrits. Mais je pense que pour des raisons de stabilite, beaucoup de personnes prefereraient un systeme dedie, plus simple, pour la virtualisation. Ca s'inclut dans l'idee du "chacun son boulot".

  • # Qemu c'est génial

    Posté par  . Évalué à 2.

    J'ai besoin d'Autocad ... donc de windows.

    Malheureusement mon nouveau pc n'est pas supporté pas NT (J'ai que ça).

    J'avais pensé à wine, mais ça semble très difficile à faire fonctionner.

    Avec Qemu c'est incroyable, installation de NT et d'autocad en 30 min. La dégradation est très légère sur un sempron 2500 256Mo. Bref, c'est tellement bien, que je si je pouvais l'installer, je ne ferai pas.

    Grand merçi à son auteur!

    Je me demande quelle est l'interêt de wine. L'API M$ étant fermé, cela ne marchera jamais correctement. Avis à mono ...

  • # super codeurs ?

    Posté par  . Évalué à 6.

    L'article parle de fonctions de virtualisation directement gravées dans le silicium, les commentaires précédents expliquent que c'est un peu comme WMWare et QEmu, mais en hard donc beaucoup plus rapide. Or tous ces logiciels, aussi bons soient-ils, connaissent à peu près tous des mises à jour pour des bugs qui trainent. Il parait même (ça m'agace d'entendre ça, grrrr...) qu'on ne peut jamais être sûr de ne pas avoir des bugs dans les logiciels, limite c'est normal d'en trouver.
    Alors je me pose la question suivante: les gens qui font les circuits chez les fondeurs comme AMD et Intel sont ils vraiment plus intelligents que les 'simples' programmeurs de logiciels? Comment font-ils pour ne pas avoir de bugs, eux? Un logiciel, on peut le mettre à jour rapidement, un CPU on ne peux pas.

    • [^] # Re: super codeurs ?

      Posté par  . Évalué à 7.

      Tout simplement parce que le logiciel doit émuler le CPU, or les x86 sont extrêmement complexes, d'où les bugs.

      La virtualisation dans les CPU est presque triviale : en gros, le logiciel hôte dit au CPU : exécute-moi tel code (l'OS invité) avec quelques protections autour, et le CPU exécute à peu près « normalement » le code invité, à peu près comme si c'était n'importe quel code.

      Donc le CPU rajoute un peu de sucre autour, mais il n'émule rien. Ce n'est qu'une gestion de contexte.

    • [^] # Re: super codeurs ?

      Posté par  . Évalué à 4.

      Comment font-ils pour ne pas avoir de bugs, eux?
      Ils en ont. Regarde la liste des errata pour les procs (l'opteron par ex en a a pas mal (une simple recherche errata+opteron dans google t'en dira plus)). Contrairement aux softs, il y a une forte pression sur la QA des procs (par extension, tous les circuits imprimes). Ca se chiffre en milliers d'heures-CPU pour les simulations. Ce qui n'est pas forcement le cas des softs dont les test sont souvent empiriques.

      • [^] # Re: super codeurs ?

        Posté par  (site web personnel) . Évalué à 2.

        Oué, quand un CPU est bogué (oups), il faut rapatrier tout ça en urgence. Ca coûte bonbon. Voir le bug de la division dans les Penitum ...
        http://fr.wikipedia.org/wiki/Bogue_de_la_division_du_Pentium(...)

        Bon, apparement pour l'instruction FDIV bogué (Pentium < 100 MHz), seules les personnes ayant demandé le remplacement ont reçu un nouveau CPU. Et comme le bug apparait que dans des cas particuliers, ça touchait pas grand monde.

        Pour la petite histoire, lors du passage au Pentium, Intel a développé un calcul optimisé avec une table de précalcul pour la division. Malheureusement cette table était erronée (genre une ou deux valeurs fausses, arf). Du coup, l'arrondit du résultat n'était pas bon. Quand on aligne de nombreux de calculs, ça peut faire des dégats (genre un missile qui se gourre de cible).

        Haypo

  • # Retour des micro-noyaux

    Posté par  (site web personnel) . Évalué à 2.

    J'imagine que ce genre de technologie va peut-être relancer les motivations du coté des micro-noyaux.

    Qui sait, peut-être qu'un jour on aura Hurd/Linux/Windows qui tournent en même temps sur un L4 ;-)

    J'ai juste eu un aperçu de la doc, au premier abord, ça m'a pas mal fait penser aux besoins en terme de partage de ressources bas niveau dans le contexte des micro-noyaux (virtualisation des interruptions, allocation d'espaces mémoire, ...)

    • [^] # Re: Retour des micro-noyaux

      Posté par  . Évalué à 3.

      Je pense que tu confonds avec les exokernels, qui sont effectivement très proches dans l'idée de la virtualisation.

      Un micro-noyau, en revanche, contient beaucoup plus de fonctionnalités (L4 est un peu à part et pourrait presque être appelé un nano-noyau, tellement il propose peu de choses).

      Sinon Linux sur L4 ça existe déjà avec L4Linux http://os.inf.tu-dresden.de/L4/LinuxOnL4/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.