1. Introduction

Annonçons-le dès maintenant, cet article ne traite ni de la virtualisation, ni de comment monter une usine à gaz pour utiliser un scanner dont les pilotes n’existent que pour Windows. Nous parlerons de Qemu, de son fonctionnement interne en émulateur et de la manière de créer une nouvelle plate-forme émulée.

Qemu est bien connu dans l’univers x86. En effet, il y a encore peu de temps, il constituait une des rares solutions libres pour faire tourner des logiciels propriétaires sous GNU/Linux. Mais alors, pourquoi deux articles sur lui dans un contexte dédié à l’informatique embarquée ? Parce qu’il est un merveilleux outil de simulation et de mise au point dans ce domaine. En voici quelques exemples :

• La formation. Il est beaucoup plus facile et moins coûteux de faire des travaux pratiques sur un système ARM9 simulé dans Qemu qu’avec un système réel.
• Lorsque le développement d’une carte physique n’est pas encore terminé, il est possible de développer les applications sur un système équivalant émulé dans Qemu.
• Lors d’un déplacement en clientèle, une démonstration est toujours plus aisée dans un émulateur.

Je laisse le lecteur curieux consulter les articles [1]Pierre Ficheux, " Introduction à BuildRoot ", GNU Linux Magazine France Hors-série n°47 (Mai 2010) et [2]Pierre Ficheux, " Mise au point à distance avec GDB et QEMU ", Open Silicium n°1 (Janvier/Février/Mars 2011) ainsi que l’ouvrage [3]Pierre Ficheux, Linux embarqué, 3e édition, Éditions Eyrolles (2010). L’auteur, Pierre Ficheux, y détaille l’utilisation de Qemu dans un contexte embarqué. Il traite de son utilisation simple, le démarrage d’un système ARM9 sous GNU/Linux, et enchaîne sur des sujets avancés allant jusqu’au débogage du noyau Linux en utilisant le couple Qemu/GDB.

La preuve est donc faite de l’utilité de Qemu dans l’embarqué, d’ailleurs, il est à la base du simulateur de smartphone de la plate-forme de développement Android. VirtualBox s’inspire de sa recompilation dynamique que nous détaillerons plus bas et Xen utilise une émulation matérielle issue de Qemu. Autant de grands noms devraient donner l’envie d’en savoir plus.

Qemu a été créé par Fabrice Bellard, un Français, alors Cocorico !!!. C’est un développeur de talent et il utilise énormément le préprocesseur C ainsi que des fonctionnalités avancées de GCC. Mais comme un avantage comporte toujours sa contrepartie, il résulte que le code de Qemu est difficile à appréhender et peut sembler, au premier abord, confus. Le site officiel de Qemu en fait mention [4]http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Getting_to_know_the_code. D’ailleurs, est-ce un hasard si, hormis des records de calcul de décimales de Pi, l’auteur a aussi remporté plusieurs fois le IOCCC [5]http://www.ioccc.org/winners.html#B, International Obfuscated C Code Contest, c’est-à-dire le Concours International de Code C Obscurci. La mise en route de la connaissance du code de Qemu est, certes, un peu ardue, mais accessible à quiconque en fait l’effort. Pour cela, quelques outils nous seront bien utiles.

Qemu est un vaste logiciel. Il est capable de réaliser de nombreuses choses. Nous nous intéresserons uniquement à l’émulation d’un système complet. Plus particulièrement, dans la première partie, nous allons étudier l’émulation d’un système complet ARM9 GNU/Linux sur un système hôte x86 GNU/Linux, bien que dans ce cas, les mécanismes génériques restent les mêmes, quels que soient les systèmes hôte et invité. La recompilation dynamique effectuée par le Tiny Code Generator est au cœur de l’émulation et elle sera détaillée. Nous aborderons aussi la gestion du temps ainsi que les horloges de Qemu. Des parties majeures du logiciel comme la virtualisation complète KVM, l’émulation de la MMU, l’émulation des périphériques en mode blocs, l’émulation d’interfaces réseau, le serveur GDB et bien d’autres encore, tant la liste est longue, ne seront pas étudiées. Il faudrait un ouvrage entier pour décrire tout le fonctionnement interne de Qemu.

Dans la seconde partie, nous passerons à la pratique en implémentant une nouvelle plate-forme matérielle ARM9 dans Qemu. Notre choix s'est porté sur un système ARM9 Armadeus APF27. Seuls les composants strictement nécessaires au démarrage d’un noyau Linux seront créés, c’est-à-dire la CPU, la mémoire, le contrôleur d’interruption, un timer et un contrôleur de port série.

2. Introduction générale à Qemu : élégance et complexité

Qemu est un logiciel élégant et complexe. Par contre, comme c’est souvent le cas dans le monde du logiciel libre, il a été écrit par des développeurs passionnés pour lesquels le défit technique compte plus que la rédaction de spécifications et de la documentation technique. Sans aucun jugement moral, force est de reconnaître que la documentation de l’architecture est quasiment inexistante et que le code comporte très peu de commentaires. Au risque de paraphraser Alan Cox [6]Documentaire Nom de code Linux, minute 24, http://video.google.fr/videoplay?docid=-3699763257121592701, " Si le code est bon, vous pouvez le lire sans commentaire ", la seule documentation solide est le code source lui-même. Il est à notre disposition, c’est déjà bien, de plus, il fonctionne.

2.1. Description de l’arborescence des sources et du système de compilation

La version de Qemu étudiée est la version 1.0 sortie le 1er décembre 2011. L’archive du code source peut être obtenue à l’URL http://wiki.qemu.org/download/qemu-1.0.tar.gz. Seuls les répertoires utiles à la bonne compréhension de l’article seront décrits. En voici une brève description :

• La partie centrale du code de Qemu se trouve directement à la racine de l’archive.
• Le répertoire hw contient le code des plates-formes et des périphériques matériels émulés.
• Les répertoires target-* contiennent le code nécessaire à l’émulation d’architecture de processeur *. Cela va de l’ARM au s390.
• Le répertoire tcg contient le Tiny Code Generator, son code commun et celui spécifique aux systèmes hôtes.

Le système de compilation utilise un script configure. Voici la configuration utilisée dans le cadre de cet article :

Passons en revue ces différents paramètres :

• --target-list=arm-softmmu active l’émulation d’un système ARM complet
• --disable-user désactive le support en mode utilisateur. Sans cette option, il est possible de lancer l’émulation d’un programme en mode utilisateur sans un système émulé complet.
• --enable-sdl active le support de la bibliothèque SDL qui permet, par exemple, d’avoir l’émulation d’un frame buffer.
• --extra-cflags=-save-temps est une option pour les explorateurs que nous sommes. Elle sera détaillée en temps voulu.
• --enable-debug active la génération des symboles de débogage pour pouvoir lancer confortablement Qemu sous le contrôle de GDB.

La compilation nécessite d’avoir une station de développement GNU/Linux digne de ce nom, c’est-à-dire dotée de tous les outils de développement classiques GNU. La configuration génère un répertoire arm-softmmu dans lequel se retrouvent les produits de la compilation.

2.2. Quelques conseils et outils avant de partir en exploration

Comme nous l’avons déjà dit, le code de Qemu est complexe. Mais la tâche de Qemu est tout aussi complexe. Il est vrai cependant qu’il peut tomber dans le domaine du compliqué et de l’obscur. Pour ne pas perdre de nombreuses heures et se décourager, mieux vaut se doter de quelques outils avant de partir en exploration. Le premier est un outil de navigation dans le code source. Un tel outil permet d’effectuer des recherches efficaces dans un code source de grande taille. Il permet en particulier de trouver :

• toutes les références à un symbole ;
• les fonctions appelées par une fonction ;
• les fonctions appelant une fonction particulière ;
• des chaînes de caractères correspondant à des expressions régulières ;
• les fichiers inclus par d’autres fichiers.

Suivant les sensibilités de chacun, deux outils semblent convenir : Cscope [7]Cscope, http://cscope.sourceforge.net/ et l’indexeur de code C/C++ d’Eclipse [8]Eclipse C/C++ Indexer, http://help.eclipse.org/indigo/topic/org.eclipse.cdt.doc.user/concepts/cdt_c_indexer.htm.

Un outil de navigation dans le code source est nécessaire, mais il n’est pas suffisant. Prenons un exemple simple qui, pour être concret, est issu de la deuxième partie de l’article. Une des dernières lignes du fichier définissant une nouvelle carte à émuler se termine par ce qui pourrait ressembler à un appel de la fonction machine_init(). Voici la dernière ligne du fichier apf27.c :

L’absence de point-virgule pourra être notée et se comprendra un peu plus bas. apf27_machine_init() est une fonction définie dans le même fichier apf27.c. Naïvement, machine_init() pourrait être pris pour une fonction qui prend en argument un pointeur de fonction. Lors du lancement de Qemu, apf27_machine_init() est effectivement appelée. Après quelque temps passé à comprendre comment cela était possible et à analyser le code source, un fait était clair : il n’y a aucun appel direct à apf27_machine_init() ni à machine_init(). Mais machine_init() est en réalité une macro dont voici la définition :