Exemple de séquence de contrôle par émulation

Les séquences de contrôle par émulation concernent les instructions sensibles, ainsi que celles qui peuvent invalider l’invariant. Ces séquences de contrôle visent à reproduire le comportement de ces instructions, sans que ces dernières ne soient exécutées.

L’émulation d’instructions est une technique connue notamment dans les solutions de virtualisation, que nous pouvons reprendre dans notre cas. Dans les cas où une instruction n’altère que des registres, ce qui correspond à la majorité des situations, la construction d’une séquence de contrôle ne pose pas de difficultés. On reprend la sémantique de cette instruction, telle que décrite dans le standard [72] ou dans le manuel de référence [41]. Un exemple de sémantique pour une instruction de lecture dans un registre spécial est donné sur la figure 7.12. Pour ce type d’intruction, la séquence de contrôle effectuera les éventuels accès, puis altèrera les registres concernés, et retournera l’exécution au logiciel utile. Une manière de procéder consiste à donner au logiciel de contrôle le moyen d’altérer les valeurs des registres récupérées lors de la sauvegarde de contexte, implémentée dans le vecteur d’exception.

42. Least Recently Used 43. Pseudo Least Recently Used 44. First In First Out

Chapitre 7. Cas d’étude sur un processeur COTS

mfspr

mfspr

Move from Special Purpose Register

mfspr rD,SPRN SPRN ← sprn0:4 || sprn5:9 if SPR(SPRN) is a 64-bit SPR then rD ← SPR(SPRN) else rD ← 320 || SPR(SPRN) 0 5 6 10 11 15 16 20 21 30 31 0 1 1 1 1 1 rD sprn_5:9 sprn_0:4 0 1 0 1 0 1 0 0 1 1 / Base User

Note : L’instruction mfspr (“Move from Special Purpose Register”) est appelée pour lire dans les registres de configuration et d’état du cœur. Ces registres permettent entre autre de configurer la MMU, les caches, de retrouver des informations sur l’état du logiciel lors d’une exception, et d’accéder à des moniteurs de performances présents sur le cœur.

Figure 7.12 – Sémantique de l’instruction mfspr, décrite dans le manuel de référence des cœurs e500 [41]

Pour les instructions de gestion des caches et de la MMU, qui sont en minorité, la séquence de contrôle est amenée à altérer la table des pages virtuelles et la table des pages en cache. Assurer la cohérence entre le contenu de ces tables, l’état du cœur et la bonne exécution du logiciel utile pose certaines difficultés d’implémentation.

Nous proposons dans cette section d’illustrer quelques unes de ces difficultés à travers un exemple portant sur l’émulation de l’instruction tlbwe, qui effectue les écritures dans la MMU. Cette instruction a été identifiée lors de la seconde analyse du jeu d’instruc- tions, portant sur les instructions pouvant invalider l’invariant. Comme dans la section précédente, l’essentiel de la complexité se situe dans la phase de préparation.

L’écriture dans la MMU est interceptée par le logiciel de contrôle, qui évaluera la règle de traduction associée et la propagera dans la table des pages virtuelles. Lors de cette opération, toute modification doit être propagée dans la TLB0, dont les entrées ont été programmées à partir des informations contenues dans la table des pages virtuelles.

A titre d’exemple, nous considérons la séquence d’opérations suivante, effectuées par le logiciel utile, sur la base d’une configuration donnée de la table des pages virtuelles :

• Le logiciel utile effectue un certain nombre d’accès, ce qui a entraîné des char- gements de données dans le cache L2. Considérons en particulier une donnée chargée à partir d’une règle de traduction d’adresse présente dans la table des pages virtuelles.

• Le logiciel utile invalide cette règle de traduction par une instruction tlbwe. Pour éviter d’invalider l’invariant, le logiciel de contrôle propage cette invalidation dans la table des pages virtuelles et non dans la MMU.

7.6. Synthèse • Si le logiciel de contrôle laissait le logiciel utile reprendre son exécution à ce stade, ce dernier pourrait effectuer de nouveaux accès utilisant la règle de traduction qu’il vient d’invalider. En temps normal, cela déclencherait une exception, mais pas ici : les accès seraient reconnus par les entrées générées par le logiciel de contrôle dans la TLB0.

Le logiciel de contrôle doit donc au préalable invalider toutes les entrées dans la TLB0 issues de cette entrée. Pour celà, il doit disposer des informations lui permettant de retrouver à partir d’une entrée dans la table des pages virtuelles l’ensemble des entrées dans la TLB0 issues de cette entrée. Nous associons ainsi à chaque entrée dans la table des pages virtuelles une liste des descripteurs de TLB générés par cette entrée. En cas de modification de l’entrée en question, chaque descripteur présent dans cette liste est invalidé.

Cet exemple montre que la construction d’une séquence de contrôle par émulation pour certaines instructions doit être pensée de manière cohérente avec le reste de la logique implémentée dans le logiciel de contrôle. Cependant, les difficultés que nous avons soulevées ne remettent pas en cause l’existence de séquences de contrôle. Nous pouvons conclure positivement quand à l’existence de séquences de contrôle pour chaque évènement sensible aux instructions.

Cette dernière étape nous permet de valider la seconde hypothèse d’application du théorème de contrôlabilité, et nous permet donc de conclure sur son application. Au cours de cette étape, nous avons été amenés à définir les principaux mécanismes que notre logiciel de contrôle est amené à implémenter. La construction des séquences de contrôle aboutit donc à une spécification à un niveau de détails relativement élevé de la plupart des mécanismes du logiciel de contrôle.

7.6

Synthèse

Nous avons développé dans ce chapitre un cas d’étude basé sur le processeur P5040. L’objectif était de montrer que, sous certaines conditions, ce processeur satisfait les conditions d’application du théorème de contrôlabilité. C’est effectivement le cas, sous réserve que les règles suivantes soient respectées dans le logiciel utile :

• Le logiciel utile n’utilise pas les instructions mbar, sync (cf règle 1), ainsi que dcbf (cf règle 2)

• Le logiciel utile est organisé pour que données et instructions ne partagent pas les mêmes lignes de caches, i.e. ne soient jamais contenues dans le même bloc de 64 octets. (cf règle 3)

Nous avons démontré la contrôlabilité du P5040 en appliquant la méthodologie que nous avions proposée dans le chapitre 6. Cette méthode visait dans un premier temps à caractériser le cœur e5500 pour en extraire un ensemble d’évènements sensibles, dont les relations ont été formalisées par des arbres d’activités. Dans un deuxième temps nous avons classifiés ces évènements selon leur type de sensibilité, et leur contrôlabilité, pour

Chapitre 7. Cas d’étude sur un processeur COTS

satisfaire la première hypothèse d’application du théorème de contrôlabilité. Cela nous a amené à définir une propriété invariante sur l’état du cœur, dont la mise en œuvre est à la charge du logiciel de contrôle. Dans un troisième temps, nous avons construit des séquences de contrôle, dont nous avons détaillé certains aspects dans la section 7.5.

Limites du cas d’étude

Les analyses que nous avons effectuées pour caractériser le cœur e5500 ont été menées de la manière la plus exhaustive possible. Toutefois, cette exhaustivité a été limitée par le fait que le cœur e5500 est un composant COTS, que Freescale a documenté à un certain niveau de détails. Même si ce niveau de détails est élevé, le niveau de confiance dans notre analyse sera toujours limité par le caractère COTS du cœur.

Se pose également la question de l’applicabilité de notre méthode sur d’autres proces- seurs. Une partie importante de notre méthode repose sur le fait que l’on est capables de contrôler le contenu des caches de manière logicielle. Cela est possible sur un cœur Po- werPC car il dispose d’instructions de gestion de caches. En passant sur d’autres cœurs, on risque de ne pas retrouver ce type d’instructions. Il faudrait alors investiguer d’autres pistes pour maîtriser le contenu des caches.

Spécification du logiciel de contrôle

La combinaison des mécanismes qui implémentent l’invariant ainsi que les séquences de contrôle que nous avons construit aboutit à une spécification presque complète du logiciel de contrôle.

Dans notre cas, le logiciel de contrôle devra implémenter les éléments suivants : • Une réplique logicielle de la MMU afin de décoreller les informations relatives à la

traduction d’adresse, qui proviennent du logiciel utile, de l’état réel de la MMU qui devra respecter l’invariant.

• Une table de données contenant les informations nécessaires pour maintenir et décider du remplacement de pages de quatre kilo-octets dans le cache L2. • Une table de données contenant les informations nécessaires pour référencer le

contenu du cache L2 dans la MMU, plus précisément dans la TLB0.

Les séquences de contrôle, tant par émulation que par neutralisation, ont de nom- breuses intéractions avec ces structures de données. Elles participent notamment à une logique de remplacement dans le cache L2 avec une granularité d’une page mémoire, soit quatre kilo-octets. Ce point fait l’objet d’un développement dans le chapitre suivant.

Nous avons montré dans ce chapitre qu’il était possible de mettre en place un logiciel de contrôle sur le P5040, en assurant les propriétés de contrôle des ressources et d’équi- valence vis-à-vis du logiciel utile. Cela a abouti à la réalisation d’un prototype, dont nous étudions les aspects d’efficacité dans le chapitre suivant.

Chapitre 8

Efficacité du logiciel de contrôle

Sommaire

8.1 Vue d’ensemble de Marthy . . . 132 8.1.1 Principaux modules logiciels . . . 132 8.1.2 Mécanisme de démarrage des cœurs secondaires . . . . 133 8.1.3 Organisation du cache L2 . . . 134 8.2 Démarche d’évaluation . . . 134 8.3 Évaluation de benchmarks industriels . . . 137 8.3.1 Efficacité du logiciel de contrôle sur Stream . . . 137 8.3.2 Efficacité du logiciel de contrôle sur AES . . . 138 8.3.3 Efficacité du logiciel de contrôle sur FFT . . . 140 8.4 Evaluation d’une application avionique . . . 141 8.4.1 Efficacité du logiciel de contrôle sur l’application avionique142 8.4.2 Pistes pour l’optimisation du logiciel de contrôle . . . . 143 8.5 Synthèse . . . 144

Nous avons développé dans le chapitre précédent un cas d’étude dans lequel nous avons établi la contrôlabilité du processeur P5040, appartenant à la gamme QorIQ déve- loppée par Freescale. Pour appliquer le théorème de contrôlabilité, nous avons été amenés à définir une logique de contrôle qui met en œuvre une gestion logicielle du cache L2, ainsi qu’une réplique logicielle de la MMU.

Nous avons implémenté cette logique de contrôle dans un prototype, appelé Marthy45_, dont nous donnons une vue générale dans ce chapitre. Nous nous intéressons, à travers la notion d’efficacité du logiciel de contrôle, à la manière dont du logiciel utile se comporte au niveau macroscopique, lorsqu’il subit cette logique de contrôle. L’objectif est de faire ressortir des caractéristiques générales du logiciel utile qui font que le logiciel de contrôle sera efficace, ou à l’inverse inefficace.

Ce chapitre est découpé en quatre sections. Dans un premier temps nous donnons une vue d’ensemble des principales caractéristiques de notre prototype. Cette section vise

45. Multicore Avionic Real-Time Hypervisor

Chapitre 8. Efficacité du logiciel de contrôle

Couche d'abstraction matérielle (HAL) Core Gestion des ressources communes (logiciel de contrôle) Gestion des machines virtuelles (Virtual Machine Monitor) Appels Système (hypercalls) Serveur Périodique LibFDT Stdlib

Figure 8.1 – Vue d’ensemble de l’architecture logicielle de Marthy

à illustrer l’environnement logiciel dans lequel le logiciel de contrôle va s’insérer. Dans la section 8.2, nous développons la notion d’efficacité du logiciel de contrôle, ainsi que notre démarche d’évaluation avec les différentes configurations de test. Dans la section 8.3, nous appliquons cette démarche sur trois benchmarks utilisés dans l’industrie. Enfin, dans la section 8.4, nous appliquons cette démarche à un exemple d’application avionique.

8.1

Vue d’ensemble de Marthy

Le logiciel de contrôle introduit dans notre approche est implémenté dans un hypervi- seur appelé Marthy, qui a été développé dans le cadre de cette thèse. Nous en présentons les principales fonctionnalités dans cette section.

Marthy intègre ponctuellement du code de Topaz [42], qui est un hyperviseur déve- loppé par Freescale sous licence autorisant la redistribution et la réutilisation du code source.