cycle. Le P5040 permet un démarrage synchrone des bases temporelles sur tous les cœurs par un registre commun. Ce mécanisme permet d’assurer la propriété de synchronisabilité, définie dans le chapitre précédent (cf page 74).
Moniteurs de performances. Le cœur e5500 dispose de compteurs matériels qui comptent
l’occurrence de certains évènements à des fins statistiques. Ces évènements portent entre autre sur le comportement du matériel. Il est par exemple possible de comp- ter le nombre d’accès qu’un cœur effectue à destination des ressources communes. L’utilisation de ces compteurs peut nous servir à la fois à caractériser finement le comportement du cœur dans des situations bien précises, mais aussi à des fins de débogage sur le logiciel de contrôle une fois fini.
Support pour la virtualisation Le cœur e5500 dispose de support matériel facilitant la mise en place d’une couche de virtualisation. Par exemple, l’information sur le niveau de privilège (MSR[PR]) peut être enrichie par une information de mode lo- giciel invité ou hôte (MSR[GS]). Cela a pour effet de simuler un troisième niveau de privilège. Le noyau du système d’exploitation est exécuté dans un mode de privilège dégradé qui lui interdit certaines opérations, principalement la configu- ration de la MMU ainsi que certains SPR, la liste complète étant donnée dans le manuel de référence [43]. Lorsque ces instructions réservées sont exécutées, cela déclenche une exception de privilège qui enclenche le mode hôte (MSR[GS] = 0), dans lequel est exécuté l’hyperviseur. Ce dernier peut ainsi reproduire l’effet de ces opérations comme si elles avaient été exécutées par le cœur, en altérant leur sémantique selon les spécifications de la machine virtuelle. Par exemple il peut composer les règles de traduction d’adresse mises en place dans la MMU avec un offset lié à la machine virtuelle. Ce type d’opération est à la base de tous les mécanismes de virtualisation que nous mettons en œuvre dans notre prototype.
7.2
Description du cas d’étude
Nous avons introduit le processeur P5040, puis détaillé l’architecture d’un cœur e5500. Notre objectif est de montrer la propriété suivante :
Propriété 7.1 (Contrôlabilité du cœur e5500). Un cœur e5500 intégré dans un pro-
cesseur P5040 satisfait les hypothèses d’application du théorème de contrôlabilité sous réserve que les règles suivantes soient respectées par le logiciel utile :
• Le logiciel utile n’utilise pas les instructions sync et mbar, (barrières mémoire), ainsi que dcbf (flush de cache).
• Données et instructions ne partagent pas les mêmes lignes de caches, i.e. ne sont pas situées sur le même bloc de 64 octets.
Nous posons donc des règles de développement applicables au logiciel utile. Nous pensons que leur impact en pratique est très faible sur le logiciel existant.
Les instructions visées par la première règle sont rarement utilisées dans les appli- cations. Elles ne sont d’ailleurs pas supportées par un compilateur comme GCC. Leur
Chapitre 7. Cas d’étude sur un processeur COTS
utilisation dans un système d’exploitation est plus courante. Ces instructions sont implé- mentées dans l’adhérence matérielle, ce qui fait qu’il n’y a qu’une seule section de code à modifier.
On peut également supposer que la seconde règle ne pose pas de difficultés en pra- tique. Le placement des sections de données dans un binaire est effectué à partir d’un script d’édition de lien. Il est possible de prévoir une contrainte précisant que les sections de données sont alignées sur 64 octets. C’est d’ailleurs le cas pour les scripts d’édition de lien fournis avec GCC.
Nous cherchons à appliquer la méthode définie dans le chapitre précédent et illustrée sur un modèle de cœurs simplifié. Cette méthodologie comprend les étapes suivantes :
1. Identification des évènements sensibles.
La phase d’identification des évènements n’a pas été illustrée sur le modèle de processeurs, dans la mesure où nous étions partis d’un ensemble d’évènements associés au modèle (load, store, fetch).
Dans le cas d’un processeur COTS, on ne connaît pas a priori la liste complète des évènements, même si certains peuvent être intuités. On a également intérêt à avoir une liste d’évènements qui couvre l’activité interne du cœur, mais qui soit aussi réduite que possible.
L’identification des évènements passe par une analyse du jeu d’instructions, puis des différents composants que l’on rencontre dans le cœur, par exemple les caches et la MMU. Ces analyses aboutissent à la construction d’arbres d’activités pour chaque composant.
2. Classification et contrôlabilité des évènements sensibles.
•La phase de classification des évènements sensibles est similaire à celle qui a été développée sur le modèle de processeur. Nous partons d’arbres d’activités définis sur le cœur, qui sont obtenus en combinant ceux que nous avons défini sur les composants, puis nous appliquons les règles de classification proposées dans le chapitre précédent.
Cette phase nous permet d’obtenir une liste d’évènements pour laquelle nous évaluons la contrôlabilité, et les différentes pistes pour la stratégie de contrôle.
•Pour les évènements sensibles qui ne sont pas contrôlables, nous cherchons à définir un invariant qui rende leur occurrence impossible. Nous appliquons dans un premier temps la démarche que nous avons suivie dans le chapitre précédent pour analyser les arbres d’activités et définir des invariants. Dans un second temps, nous montrons qu’un invariant ne peut être invalidé par le logiciel utile. Cela demande une seconde analyse du jeu d’instructions.
3. Définition des séquences de contrôle. Nous abordons la question des sé- quences de contrôle par neutralisation, ainsi que des séquences de contrôle par émulation.
Le jeu d’instructions fait donc l’objet de deux analyses. La première vise à identifier les instructions dont l’exécution est susceptible de déclencher un accès aux ressources
7.3. Identification des évènements sensibles