Démarrage du noyau

Le démarrage du noyau en mode monocoeur suit les étapes suivantes : 1. La machine démarre.

2. Le chargeur RSW charge le noyau et les partitions en mémoire.

3. Le noyau XtratuM démarre et exécute ces étapes de démarrage avant le début de l’or- donnancement :

a) initialisation des périphériques principaux du système ; b) initialisation du contrôleur d’interruptions ;

c) initialisation des pilotes et objets du noyau ; d) initialisation des partitions ;

e) démarrage des partitions.

85

Dans la version SMP du noyau, il est nécessaire d’ajouter des étapes au démarrage et de réorganiser la séquence afin de synchroniser correctement les évènements. La majeure partie de l’initialisation doit s’exécuter sur un seul coeur, de manière entièrement séquentielle, avant de relâcher les autres coeurs. Si tous les coeurs étaient relâchés dès le démarrage, chacun essaierait de réaliser les mêmes étapes, avec un ordonnancement légèrement différent. Il s’en suivrait une course de réinitialisation de chacun des registres de périphériques et le système se retrouverait dans un état indéterminé.

Les systèmes d’exploitation multicoeur traditionnels, tels que Linux ou FreeBSD, procèdent de la même manière : le coeur principal de la machine démarre le système d’exploitation et configure les périphériques avant de relâcher les autres coeurs du système. Par la suite, les autres coeurs exécutent chacun une version minimale du démarrage où l’initialisation des périphériques est omise et seulement leurs données locales sont initialisées. Enfin, les coeurs peuvent tous exécuter le même code pour autant qu’ils soient synchronisés lorsqu’ils accèdent à des ressources partagées.

Nous avons adapté le démarrage de XtratuM afin qu’il respecte un démarrage séquentiel sur le coeur principal, suivi d’un relâchement des autres coeurs avec un flot de démarrage réduit. Le pseudocode du démarrage adapté est présenté à l’algorithme 4.1. La fonction Setup() est le point d’entrée du noyau, immédiatement après le démarrage d’un coeur. On remarque dans cet algorithme que toute l’initialisation de bas niveau est réalisée par le coeur principal3, dont l’identifiant est 0. Lorsque les autres coeurs démarrent et exécutent le même code, ils sautent par-dessus cette section et n’initialisent que les éléments locaux.

La synchronisation du démarrage est réalisée à l’aide de barrières globales, nommées WAIT_BARRIER() dans le pseudo-code. Ces barrières globales permettent d’assurer un ordre spécifique des opérations. Dans notre adaptation, les barrières n’ont pas de mécanisme 3. Dans un système multicoeur à N coeurs, ces derniers sont habituellement identifiés séquentiellement avec un identifiant dans l’intervalle[0...N − 1].

Algorithme 4.1 Démarrage SMP du noyau XtratuM function Setup() IF get_cpu_id() == 0 THEN initialize_low_level_peripherals() initialize_IRQ_controller() initialize_kernel_objects() initialize_scheduler()

/* Démarrage des autres coeurs */ release_other_cores()

END IF

/* Attente du démarrage des autres coeurs */ WAIT_BARRIER()

/* Initialisation de l’horloge principale */ IF get_cpu_id() == 0 THEN

initialize_system_clock() END_IF

WAIT_BARRIER()

/* Initialisation des données locales */ initialize_local_data()

/* Initialisation des partitions */ IF get_cpu_id() == 0 THEN setup_partitions() END IF WAIT_BARRIER() boot_partitions() WAIT_BARRIER()

/* Synchronisation des horloges locales */ synchronize_clocks()

/* --- GO ! L’ordonnancement démarre ici */

de délai d’attente maximal. Ainsi, un problème peut survenir si un des coeurs plante avant d’atteindre la barrière : les autres coeurs attendraient indéfiniment et le système complet plan- terait. Cependant, des adaptations logiques importantes seraient nécessaires afin d’ajouter la détection de cette condition. Une alternative est l’emploi d’une minuterie chien de garde qui ne serait jamais réinitialisée dans la boucle d’attente de la barrière. Il pourrait ainsi y avoir une logique de détection d’erreur à ce niveau, qui empêcherait le plantage dur de la machine.

87

Cependant, même si un délai d’attente maximal ou un chien de garde était implémenté, une défaillance lors du démarrage d’un coeur rendrait tout de même l’état du système invalide, même si les autres coeurs n’étaient pas en attente infinie, car le plan de configuration du sys- tème pourrait contenir un plan d’exécution nécessitant la présence de tous les coeurs. Des recherches additionnelles sont nécessaires afin de déterminer les adaptations permettant de supporter une défaillance de coeur au démarrage.

Le chronogramme de la figure 4.2 présente la séquence des évènements du démarrage SMP jusqu’au début de l’ordonnancement.

0

t

0

t RSW Setup()

Cœur arrêté Boot

Partition A CPU0 CPU1 Setup() Setup() 0 t Cœur arrêté Boot

CPU2 Setup() Barrières Partition B Setup() Setup() Partition C Démarrage de CPU1 et CPU2 Début de l’ordonnancement Barrière de synchronisation de démarrage

Figure 4.2 Chronogramme de la séquence de démarrage du noyau XtratuM sur trois coeurs

4.6.3 Gestion de l’horloge

L’horloge globale du noyau XtratuM sur LEON est utilisée autant par le noyau que par les par- titions. Dans le cas de l’adaptation multicoeur, il serait possible d’utiliser une horloge globale si une telle ressource était disponible. Malheureusement, la plupart des processeurs multi- coeurs ne sont pas dotés d’une horloge à haute résolution globalement accessible par tous les coeurs. Ce genre de périphérique peut cependant être réalisé à l’extérieur des coeurs par un compteur matériel lisible sur un bus partagé.

Afin de simplifier l’implémentation et d’augmenter la précision de la gestion de l’horloge, nous utilisons dans l’adaptation multicoeur une horloge locale et une minuterie matérielle locale sur chaque coeur. Une synchronisation entre les horloges locales au moment du démar- rage du noyau est effectuée pour assurer un minimum de différences entre les temps perçus par les coeurs. Cette synchronisation est la dernière opération dans l’algorithme 4.1 et elle est nécessaire afin de permettre l’exploitation de groupes de partitions parallèles qui seront présentés plus loin à la section 4.8.1. Puisque tous les coeurs sont alimentés par la même hor- loge principale synchrone, leurs horloges et minuteries locales demeurent alignées après la synchronisation. Il peut rester une erreur résiduelle minimale entre les horloges locales des coeurs, mais cette dernière sera constante.

L’utilisation d’une horloge locale et d’une minuterie locale sur chaque coeur présente certains avantages :

• il n’y a aucune contention pour l’accès à la valeur de l’horloge ;

• la lecture de l’horloge locale dans un registre interne du processeur est immédiate alors que la lecture sur un périphérique peut prendre plusieurs cycles qui introduisent une incertitude additionnelle sur la valeur ;

• la corruption de la valeur d’horloge locale ou de minuterie locale d’un coeur n’a aucun effet sur l’ordonnancement des autres coeurs ;

• chaque coeur peut employer son propre ordonnanceur d’évènements locaux, ce qui éli- mine plusieurs couplages entre les coeurs.

Par contre, deux inconvénients découlent aussi de cette approche :

• la synchronisation globale d’évènements sans l’utilisation d’interruptions inter-coeurs est toujours accompagnée d’un délai de latence égal à la différence maximale de valeur d’horloge entre les coeurs qui essaient de se synchroniser, en raison de l’erreur systé- matique de synchronisation initiale des horloges locales ;

89

• la synchronisation des horloges peut prendre beaucoup de temps.

Le délai de synchronisation des horloges dépend de l’algorithme utilisé et il peut être élevé. Nous reviendrons sur ce problème en même temps que les détails d’implémentation de notre version sur PowerPC à la section 5.4.3.

4.6.4 Gestion des interruptions et exceptions

Les interruptions en mode multicoeur sont traitées de la même manière que celles en mode monocoeur : chaque coeur traite les interruptions qu’il reçoit. Il est important que toutes les sources d’interruptions matérielles, sauf celles conçues pour la messagerie ou la synchronisa- tion inter-coeurs, ne soient assignées qu’à un seul coeur. Si plusieurs coeurs essaient en même temps d’accéder à un périphérique, il risque d’y avoir des conditions de course graves qui pourraient engendrer des fautes.

L’adaptation multicoeur de XtratuM gère le contrôleur d’interruption OpenPIC afin que le routage de chaque source soit destiné à un seul coeur. Les règles d’allocation des sources d’interruptions aux partitions sont validées à partir du PCS par l’outil xmcparser.

En plus de gérer les sources d’interruptions des périphériques, le contrôleur OpenPIC com- porte des mécanismes de communication inter-coeur et des minuteries globales. Ces deux types de fonctions peuvent interrompre n’importe quelle combinaison de coeurs à la fois, ce qui permet la réalisation de mécanismes de synchronisation à partir d’évènements asyn- chrones. Toutes ces sources d’interruptions globales sont réservées et ne peuvent être em- ployées que par des pilotes du noyau afin de simplifier les règles d’assignation des ressources. Notre implémentation multicoeur du noyau n’emploie aucune des fonctions globales du contrô- leur OpenPIC. Cependant, ces dernières pourraient éventuellement être employées à travers des hyperappels pour simplifier la réalisation de la synchronisation multicoeur.

Un problème identifié dans l’architecture initiale de XtratuM est que les sources d’interrup- tions externes sont toujours activées, peu importe à qui elles appartiennent. Ainsi, une inter-

ruption appartenant à une partition P1 pourrait survenir pendant la fenêtre d’activation d’une partition P2. Le gestionnaire d’interruptions externes dans XtratuM enregistrerait alors l’oc- currence de l’interruption dans un champ de bits de la partition à laquelle la source appartient, soit P1. Une exception virtuelle n’est exécutée que si l’interruption appartient à la partition active. Dans notre exemple, il n’y aurait pas d’exécution superflue d’une exception virtuelle. Cependant, l’exécution d’un gestionnaire d’interruption pour une source n’appartenant pas à la partition active P2 équivaut à une subtilisation de cycles imprévue à l’encontre des contraintes du partitionnement temporel robuste. Ce problème a déjà été identifié par Rushby [57] dans le contexte du partitionnement robuste et par Littlefield-Lawwill et Kinnan [41] dans le contexte de l’IMA. Notre solution consiste à modifier le changement de contexte de partitions pour inclure une reconfiguration du contrôleur d’interruptions. Ainsi, seules les sources d’inter- ruptions appartenant à la partition active seront traitées et l’analyse d’ordonnancement peut être faite avec un nombre réduit de sources potentielles d’évènements asynchrones, au dé- triment d’un temps de latence d’interruption élevé pour les sources n’appartenant pas à la partition active. Dans plusieurs systèmes IMA, la seule interruption permise est celle de l’hor- loge [41]. Nous permettons l’utilisation d’interruptions dans notre adaptation, mais les par- titions critiques doivent préférablement employer l’interrogation continue des périphériques (« polling ») au lieu des interruptions, car c’est un mécanisme directement analysable par les outils d’analyse statique et de détermination du WCET. Cependant, l’approche par « polling » dégrade considérablement le facteur de charge du processeur, en raison du temps perdu à l’at- tente active d’évènements.

4.7 Mécanisme d’hyperappels

Aucune adaptation particulière n’a été nécessaire au niveau du mécanisme d’hyperappels pour l’implémentation multicoeur du noyau. Cependant, quelques hyperappels ont été ajoutés ou modifiés, afin de supporter l’adaptation multicoeur. De plus, la convention d’appel des hyper-

91

appels doit être adaptée au processeur ciblé, mais ces adaptations n’affectent pas le traitement des hyperappels en tant que tel.

4.8 Partitionnement temporel

Le support de l’exécution parallèle de plusieurs partitions est l’objectif principal de l’adap- tation d’un noyau de partitionnement robuste vers une architecture multicoeur. Les systèmes IMA actuellement déployés sont pour la plupart des systèmes distribués qui exécutent des partitions communiquant entre elles sur plusieurs machines interconnectées [68, 55, 35] par des bus temps réel sûrs tels que ARINC-659 (SAFEBus) et ARINC-664 (AFDX). D’ailleurs, Rushby traite autant du partitionnement monoprocesseur que des répercussions du partition- nement distribué dans son rapport séminal sur le partitionnement robuste [57]. L’exécution parallèle de partitions dans un système n’est donc pas une nouvelle idée.

La différence majeure entre le partitionnement robuste distribué et le partitionnement robuste sur processeurs multicoeurs est le débit de communication atteignable entre les partitions. Dans les systèmes distribués, le débit globalement atteignable entre les partitions est limité à un ordre de grandeur d’environ 10 Mo/s dans le meilleur des cas [11] pour l’ensemble des communications. Certaines contraintes de synchronisation globales doivent être respectées, mais la quantité de données partagées et l’architecture des bus de communications permettent des latences tolérables de l’ordre des centaines de microsecondes. Dans les processeurs mul- ticoeurs, la communication entre les partitions peut s’effectuer à travers des bus internes à très haute vitesse. Il devient ainsi possible de communiquer localement des données à un dé- bit plusieurs ordres de grandeur supérieurs à celui des bus de communications inter-machine traditionnels. En particulier, le débit est assez élevé pour permettre l’utilisation du parallé- lisme au niveau des tâches (« task-level parallelism », en anglais) comme dans les systèmes d’exploitation traditionnels.

L’exploitation du parallélisme exposé par les processeurs multicoeurs requiert cependant l’adaptation des modèles de partitionnement robuste existants. En effet, l’unité de séparation des fonctions demeure la partition et les partitions existent pour permettre de faire respecter l’isolation entre les fonctions. Il faut spécifier des modifications au modèle de partitionnement robuste qui permettront d’exploiter le parallélisme sans mettre en péril l’isolation nécessaire entre les partitions.

Il n’existe actuellement aucune norme pour le partitionnement robuste multicoeur. La norme ARINC-653 est explicitement une norme vouée au partitionnement d’un seul processeur doté d’un seul coeur. Cependant, il existe différents modèles avancés par l’industrie pour s’attaquer au problème. Les deux modèles les plus avancés à notre connaissance sont ceux de SYSGO pour PikeOS [30] et ceux d’une équipe de Honeywell publié sous la forme d’un brevet [65]. Pour l’adaptation multicoeur de XtratuM, nous avons choisi d’étendre le modèle existant afin qu’il supporte plusieurs partitions et différents types de plans d’exécution. Le modèle ori- ginal de XtratuM est basé sur ARINC-653 avec quelques différences. Malgré que la norme ARINC-653 et le modèle de partitionnement original de XtratuM ne mentionnent aucunement le partitionnement parallèle, les extensions nécessaires se sont avérées assez minimes.

L’élément central du partitionnement multicoeur est la composante temporelle : on veut pou- voir exécuter plusieurs partitions en même temps sur un même processeur. Les extensions au partitionnement spatial découlent ensuite directement de l’implémentation du partitionnement temporel parallèle.