Sortie de l'émulateur Qemu 0.7.0

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
31
mai
2005
Noyau
Après plus de 6 mois de développement, une nouvelle version de Qemu est sortie fin avril. Qemu est un émulateur fonctionnant dans deux modes différents. Le premier mode permet d'émuler une architecture matérielle complète : le processeur ainsi que les périphériques matériels comme les disques, les cartes réseau, les ports séries, etc. Ce mode permet d'exécuter un système d'exploitation complet, et se rapproche de ce que permet l'émulateur Bochs. Le second mode, fonctionnant sous GNU/Linux uniquement permet d'exécuter des binaires prévus pour une architecture donnée sur une autre architecture : l'émulation n'a lieu que pour un processus particulier.

Le premier mode permettant d'exécuter un système d'exploitation complet, il est parfait pour tester de nouveaux systèmes, réaliser le débogage de modules noyau ou simuler des réseaux composés de machines virtuelles. Le second mode permet par exemple aux possesseurs d'architectures non-x86 d'exécuter des applications propriétaires compilés pour x86 lorsque cela est nécessaire.

Qemu étant indépendant du processeur émulé, il supporte l'émulation de différentes plateformes. L'émulation des processeurs x86 et PPC est complète, et l'émulation des processeurs x86_64, ARM ou SPARC sont à des états plus ou moins avancés. D'autre part, Qemu utilise une technique de traduction dynamique, qui consiste à transformer le code binaire de l'architecture cible en code binaire pour l'architecture hôte. Cette traduction étant effectuée une fois pour toutes pour chaque partie de code, la vitesse d'émulation est grandement améliorée par rapport à un émulateur classique comme Bochs.

Par ailleurs, la version 0.7.0 permet d'utiliser un module noyau, kqemu qui permet d'accélérer encore plus l'émulation, en permettant l'exécution de parties du code directement sur le processeur. Ce module ne fonctionne que si l'on émule un PC sur un PC et est livré sous licence propriétaire. Son auteur, Fabrice Bellard, qui est aussi le développeur principal de Qemu, recherche en effet un sponsor pour le développement de Qemu et kqemu. L'utilisation de cette licence propriétaire a provoqué de vives discussions sur la liste, certains défendant le bien-fondé de la démarche du développeur, d'autres la rejetant. Parallèlement, Paul Brooks a créé un projet expérimental pour développer un module aux fonctionnalités similaires à kqemu, mais distribué sous licence GPL: qvm86.

En dehors de ce support de kqemu, la version 0.7.0 apporte quelques nouveautés ou améliorations comme le support initial de l'architecture x86_64, une amélioration du support SPARC qui permet maintenant de démarrer Linux, le support de l'émulation du port parallèle, des instructions MMX, SSE, SSE2 et PNI, l'amélioration du support ARM, et l'intégration d'un code émulant une unité de calcul en virgule flottante.

Aller plus loin

  • # Français

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

    "translation dynamique" ne serait pas une mauvaise traduction de "dynamic translation" ? Dans ce cas, je dirais plutôt "traduction dynamique".

  • # pc sur une cafetiere pour quoi ?

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

    Ce module ne fonctionne que si l'on émule un PC sur un PC

    Il est dommage qu'on ne puisse pas émulé un PC sur un cafetière avec le module noyau, ca limite grandement son interet.

  • # Question technique

    Posté par  . Évalué à 2.

    Quelqu'un peut-il m'expliquer pourquoi certains logiciels comme Virtual PC ou VMWare arrivent à émuler avec de très bonnes performances et que nos alternatives libres n'y arrivent pas ?

    Est-ce un problème de temps de développement pour rechercher des optimisations ou un problème de spec non disponibles ?

    • [^] # Re: Question technique

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

      As-tu testé Qemu avec kqemu ? Au niveau performances, c'est à mon avis très proche de ce que fait un VMWare. Il me semble que les mêmes techniques sont utilisées : traduction dynamique de code (Qemu) + exécution directe de code sur le processeur quand l'architecture cible est la même que l'architecture hôte (kqemu).

      Ce qui pêche encore un peu peut-être dans Qemu, ce sont les entrées-sorties, en particulier l'affichage à l'écran qui rame pas mal.

      • [^] # Re: Question technique

        Posté par  (Mastodon) . Évalué à 8.

        Et il me semble que vmware se contente d'émuler un processeur x86 sur une machine x86, alors que qemu peut émuler un ppc sur un alpha, ou un x86 sur un amiga :)

        Ca doit changer pas mal de choses.
        Et en fait le module kqemu doit permettre le même genre d'optimisation que fait vmware quand on émule du x86 sur du x86.

        Yth.

      • [^] # Kqemu + Win9x

        Posté par  . Évalué à 1.

        Kqemu ne fonctionne pas encore très bien avec Win9x en système "invité - le gain est faible, voir nul, voir même une perte... du moins c'est ce que j'ai compris de mes lectures.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Kqemu + Win9x

          Posté par  . Évalué à 1.

          En effet. J'ai installé win98 avec une version qemu-6.2 (avec un facteur de gain de 1/10, soit une install 10x plus lente ;[ ).

          Après avoir installé une version 0.7 ça tourne toujours, c'est génial ! (surtout le format de fichier qui permet de créer un disque virtuel de 4Go et de n'occuper sur le disque que la taille réelle des données présentes sur ce disque: 150Mo pour un 98 tout neuf ;))

          En revanche, dès que je mets le module Kqemu dans le noyau et que je lance le qemu (la version optimisée, donc), win98 plante lors du démarrage avec une "erreur de protection".

          Il ne me reste plus qu'à lire la licence proprio du module et voir comment je peux aider le monsieur qui code. Je ne suis pas le patron d'une boîte, je n'ai donc pas les moyens de l'aider financièrement, mais j'admire son travail.

    • [^] # Re: Question technique

      Posté par  . Évalué à 6.

      Je n'ai jamais essayé VMware mais j'ai vu tourné VirtualPC et je n'étais pas bluffé par les performances. Qemu me semblait tourner aussi bien sur une machine équivalente. Je faisais tourner sans problème un FreeBSD en même temps qu'une Ubuntu sous Qemu pour faire la démo d'un firewall, bon ça allait pas du feu de Dieu non plus mais c'était assez réactif pour se servir de Mozilla dans l'Ubuntu pour se connecter à un Apache sur le FreeBSD et je n'utilisais même pas Kqemu!

      Sinon pour les différences de perfs, il faut distinguer les émulateurs "purs" comme Bochs qui visent d'abord à restituer parfaitement le comportement du matériel émulé, et les émulateurs "pratiques" qui cherchent à augmenter la vitesse d'exécution en utilisant par exemple les instructions du processeur du système hote si il est identique à celui émulé.

    • [^] # Re: Question technique

      Posté par  . Évalué à 3.

      En la matière MOL (Mac-on-linux) m'a semblé très abouti. Cela consome pas mal de RAM mais je fais tourner MacOsX de mon linux de manière tout à fait satisfaisante (assez réactif sur mon ibook G4, 1,2 Ghz). Il est assez comparable au niveau technique à Vmware dans le sens où c'est de l'archi PPC sur de l'archi PPC (VMWare étant du x86 sur du x86). L'émulateur en question propose bien plus.

      • [^] # Re: Question technique

        Posté par  . Évalué à 1.

        Si seulement un jour ça permettait d'utiliser l'airport extreme sous linux...

  • # Le second mode, comment faire ?

    Posté par  . Évalué à 4.

    Le second mode permet par exemple aux possesseurs d'architectures non-x86 d'exécuter des applications propriétaires compilés pour x86 lorsque cela est nécessaire.


    Concrètement, comment faire pour par exemple exécuter "firefox + flash version x86" sur un linux ppc ? Merci.

  • # VMware

    Posté par  . Évalué à 0.

    Bah pour moi, VMware, c'est 100% de perfs proc par rapport au natif, avec le goulot d'étranglement qui est le disque dur virtuel, même si je lui fait accéder directement une vraie partition.

    • [^] # Re: VMware

      Posté par  . Évalué à 3.

      Bah pour moi VMWare - demo - a été crash de toutes les partitions montées, avec perte du superblock et écriture de données aléatoires un peu partout... J'ai alors fait conaissance avec les joies d'un hexedit sur un cd knopix pour finalement sauver 95% de tout ce petit monde (ouf !).
      D'où le danger des executions en mode noyau... Quand ça plante, ça fait pas dans le détail.

  • # Une joli GUI

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

    Même si ce n'est pas indispensable (sourout que la ligne de commande est parfois plus pratique), ce serait bien d'avoir une GUI ...
    Ne serait-ce que pour avoir un bouton pour prendre un screenshoot. par exemple.
    Ou changer la configuration materielle alors que qemu est déja lancé

    • [^] # Re: Une joli GUI

      Posté par  . Évalué à 1.

      ... ou au moins une utilisation conviviale. La GUI peut se faire en dialog (je suis fan de ce procédé). En revanche, l'utilisation est liée au programme.

      Loin de moi l'idée de critiquer nos chers logiciels libres (je n'ai qu'à contribuer :), mais Qemu n'est pas de tout repos à utiliser. Notamment la partie réseau, qui manque singulièrement de simplicité.

      • [^] # Re: Une joli GUI

        Posté par  . Évalué à 3.

        oui mais bon c'est une version 0.7 hein le 0 devant le point ça veut dire pas fini faut lui laisser le temps quoi

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Une joli GUI

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

        Je trouve la partie réseau très simple justement ! Tu as une interface tun et tu en fais ce que tu veux (NAT, bridge, routage...).
        Par contre il serait peut être bien de faire un repository ou distribuer avec qemu des scripts types pour ces différentes utilisations courantes. Ici j'en ai un pour le bridge entre instances qemu + NAT vers le reste du réseau et un autre pour direct bridger.

        • [^] # Re: Une joli GUI

          Posté par  . Évalué à 4.

          on a le même (faux) problème avec coLinux, la partie réseau pour relier les deux systèmes marche bien, mais c'est compliqué à mettre en oeuvre pour des gens qui ne connaissent que le nécessaire vital pour accéder à leur FAI et ils sont ensuite génés par les outils bridés et malcommodes de Windows (2k, XP), les assistants et autres boites de dialogues qui empêchent certains choix...

          c'est donc versatile, on peut faire ce qu'on veut... si on a déjà une idée de ce qu'il faudra faire.

      • [^] # Re: Une joli GUI

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

        > Qemu n'est pas de tout repos […]. Notamment la partie réseau, qui manque singulièrement de simplicité.

        Bah moi, j'utilise VDE (Virtual Distributed Ethernet : [http://vde.sourceforge.net/(...)]) et ça marche fort bien. J'ai gentiment défini mon interface tap0 dans /etc/network/interfaces, et je lance mes instances de QEMU avec ‘vdeqemu -hda image-machine -m 64’. Rien que de très simple, en fin de compte, et ça permet d'avoir plusieurs QEMU qui se parlent sur le « commutateur » Ethernet virtuel.

        Sinon, j'ai lu sur la liste que l'auteur privilégiait une GUI bien intégrée au soft, et multiplateformes (genre avec GTK+). Voili voilou.

        Envoyé depuis mon PDP 11/70

  • # Accès aux autres partitions

    Posté par  . Évalué à 1.

    Bonjour, quemu m'interesse grandement pour me servir de mon imprimante qui n'a pas de pilote sous linux..donc j'émulerai widows et hop hop hop, j imprimerai mes docs depuis windows...
    Mais pour ce faire je doit créer un partition d'échange en fat32 pour que windows y ai accès..et la question qui me taraude c'est : Peut on accéder aux autres partitions du disque dur avec Qemu?
    merci bcp

    • [^] # Re: Accès aux autres partitions

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

      > Peut on accéder aux autres partitions du disque dur avec Qemu?

      QEMU n'a pas besoin de partitions sur un disque dur physique. Tu peux juste utiliser (en fait, c'est très recommandé) un fichier image (avec la commande ‘dd’) que tu « partitionneras » depuis QEMU via l'installateur du système d'exploitation invité. Tu pourras ensuite accéder aux « partitions » de ce fichier image en l'attachant au système de fichier grâce au périphérique de bouclage (il y a justement un petit utilitaire bien pratique à cet effet : [http://www.dad-answers.com/qemu/utilities/QEMU-HD-Mounter/lomount/(...)]). Toutefois, cette solution n'est pas très utilisable (il faut arrêter l'émulateur avant d'accéder à ses disques, pour éviter que le système d'exploitation invité ne plante). Une meilleure solution reste la possibilité qu'a QEMU de permettre l'accès aux dossiers de la machine hôte à travers un partage SaMBa.

      En revanche, j'ai des doutes sur l'utilité de QEMU dans ta situation. Pour que QEMU fasse marcher ton imprimante, il faut déjà qu'il soit « conscient » de sa présence. Or, l'émulateur ne voit pas les périphériques de la machine, mais des périphériques virtuels. Il y a donc des chances qu'il ne puisse utiliser ton imprimante. Néanmoins, si c'est une imprimante parallèle, tu peux toujours essayer avec ‘qemu -parallel /dev/lp0’ (assure-toi que le périphérique /dev/lp0 est bien accessible par l'utilisateur qui lance QEMU) et espérer que ça passe. Bonne chance.

      Envoyé depuis mon PDP 11/70

      • [^] # Re: Accès aux autres partitions

        Posté par  . Évalué à 0.

        > En revanche, j'ai des doutes sur l'utilité de QEMU dans ta situation. Pour que QEMU fasse marcher ton imprimante, il faut déjà qu'il soit « conscient » de sa présence. Or, l'émulateur ne voit pas les périphériques de la machine, mais des périphériques virtuels. Il y a donc des chances qu'il ne puisse utiliser ton imprimante.

        Ben je suis perplexe... vu qu'il est capable d'émuler un Intel Pentium sur mon AMD avec une soundblaster la ou j'ai une Via97.....

Suivre le flux des commentaires

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