TP7 : TSAR & lancement d'ALMOS-MKH

1. Objectifs

Le but de ce TP est de présenter le simulateur de l'architecture manycore TSAR, ainsi que le système d'exploitation ALMOS-MKH. Pour cela vous allez dans un premier temps générer le simulateur de l'architecture matérielle. Puis vous allez générer le code binaire de l'OS, du bootloader, et du préloader. Finalement vous allez exécuter une petite application sur cette plate-forme.

Avertissement : On cherche principalement dans ce TP à vous inciter à lire la documentation, en vous fournissant les pointeurs nécessaires, disponible sur les serveurs WEB des projets ​TSAR et un peu ​ALMOS-MKH (pour ALMOS on rentrera dedans la prochaine séance). La compilation de l'OS et la génération du simulateur ne demandent que quelques minutes. Le lancement du simulateur et les expérimentations peuvent se faire en 15 minutes. Prenez donc le temps de lire soigneusement la documentation...

Les codes sources, pour le simulateur de l'architecture matérielle, pour le code système, et pour le code applicatif vous sont fournis dans un fichier tar.

Vous travaillerez dans le répertoire local de votre poste de travail /dsk/l1/misc, qui possède une grosse capacité de stockage. Cependant, l'utilisation du répertoire /dsk/l1/misc impose que vous fassiez tous les TPs sur la même machine. Ce répertoire n'est pas sauvegardé, et peut donc être perdu. Il est fortement conseillé de sauvegarder vos fichiers sources en fin de session sur votre compte personnel.

Commencez par copier dans le répertoire /dsk/l1/misc de votre poste de travail le fichier d'archive almos-mkh_tsar_fw.tjf qui se trouve sur la machine dvorak:

cd /dsk/l1/misc
mkdir <votre login>
cd <votre login>
scp gallus:/dsk/l1/misc/almos-mkh_tsar_fw.tjf .

La décompression de ce fichier doit créer un répertoire almos-mkh_tsar_fw, qui contient lui-même les deux répertoires almos_mkh et tsar, ainsi que le fichier env.sh qui permet d'initialiser les variables d'environnement.

tar xjf almos-mkh_tsar_fw.tjf

Il est important que la décompression se fasse dans le répertoire /dsk/l1/misc/<votre login> parce que les fichiers de configuration d'ALMOS-MKH font cette hypothèse. Après décompression, l'ensemble des fichiers occupent environ 250Moctets.

Le répertoire almos-mkh est une copie du dépôt SVN contenant le code source (C) du système d'exploitation almos-mkh. Il contient principalement les répertoires suivants:

• /almos-mkh/kernel : code du noyau indépendant de l'architecture cible.
• /almos-mkh/hal : code du noyau dépendant de l'architecture cible.
• /almos-mkh/boot : code des bootloaders pour les différentes architectures cibles.
• /almos-mkh/libs : bibliothèques de fonctions utilisées pour accéder aux services système.
• /almos-mkh/user : quelques codes applicatifs, dont init, et un petit shell appelé ksh.

Le répertoire tsar est une copie du dépôt SVN contenant le code source (SystemC) des différents simulateurs de l'architecture tsar. Le simulateur que vous utiliserez dans ce TP et dans les suivants est dans le répertoire /tsar/platforms/tsar_generic_iob.

Vous allez devoir renommer le répertoire en remplaçant _fw par vos initiales _xx. Je suppose que vos initiales sont xy Lancez script env.sh qui permet d'initialiser les variables d'environnement requis par les outils de compilation.

mv /dsk/l1/misc/<votre login>/almos-mkh_tsar_fw /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy
cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy

Vous allez devoir modifier les fichiers suivants en remplaçant fw par xy.

./env.sh
./almos-mkh/params-hard.mk
./almos-mkh/params-soft.mk
./almos-mkh/Makefile

Esuite, vous devez sourcer la configuration de l'environnement :

source env.sh

Vous pouvez mettre ce source à la fin de votre fichier .bashrc, afin de ne pas avoir à exécuter ce script pour chaque shell. Toutefois, juste après avoir modifié le .bashrc, vous devez forcer sa lecture.

echo "source /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/env.sh" >> ~/.bashrc
source ~/.bashrc

2. Architecture manycore TSAR

Comme l'architecture multicluster du TP5, l'architecture TSAR est une architecture clusterisée. Chaque cluster[i] contient

• entre 1 et 4 coeurs MIPS32 avec leur cache L1,
• un cache L2 représentant le segment mémoire physique accessible dans le cluster[i],
• un contrôleur d'interruptions local contenant également des timers,
• un contrôleur DMA utilisé par l'OS pour accélérer les mouvements de données de mémoire à mémoire,

Les 6 principales différences par rapport à l'architecture clusterisée du TP5 sont les suivantes:

2.1 Espace d'adressage 40 bits

L'architecture TSAR utilise des processeurs 32bits pour minimiser la consommation énergétique. Chaque application possède donc un espace virtuel limité à 4 Goctets (adresses virtuelles sur 32 bits). Mais l'espace d'adressage physique a une taille de 1 Tera-octet (adresses physiques sur 40 bits). Les 8 bits de poids fort de l'adresse définissent les coordonnées du cluster cible de la transaction. Le segment de mémoire physique accessible dans un cluster ne peut donc pas avoir une longueur supérieure à 4 Goctets.

Pour effectuer les traductions (adresses virtuelles 32 bits => adresses physiques 40 bits) le contrôleur de cache L1 contient une MMU gérant une mémoire virtuelle paginée. Cette MMU supporte deux types de pages (4 Koctets, et 2 Moctets). Les spécifications détaillées de cette MMU peuvent être trouvées ​ici.

En plus de ce mécanisme de traduction paginé, la MMU de TSAR possède un second mécanisme de traduction d'adresse, qui ne concerne que les adresses de données: Lorsque la MMU DATA est désactivée toutes les adresses virtuelles sur 32 bits sont étendues a 40 bits par concaténation d'un numéro de cluster sur 8 bits, stocké dans un registre protégé de la MMU. Ce mécanisme - exclusivement réservé au système d'exploitation - permet à n'importe quel coeur d'accéder en lecture ou en écriture à n'importe quelle adresse de la machine.

2.3 Cohérence des caches

Le contrôleur de cache L1et le contrôleur de cache L2 implémentent le protocole DHCCP présenté en cours, et permettant au matériel de garantir la cohérence entre les caches L1 et les caches L2 sans intervention du logiciel. La cohérence des caches TLB de la MMU est également assurée par le protocole DHCCP. Les spécifications détaillées peuvent être trouvées ​ici.

2.4 Micro-réseau

L'architecture de communication entre les caches L1 et les caches L2 est un NoC comportant une partie globale pour la communication inter-clusters, et une partie locale pour la communication intra-cluster. L'interconnect global est constitué de 5 réseaux DSPIN totalement indépendants, ayant chacun une topologie de grille 2D. Chaque interconnect local est constitué - dans chaque cluster - de 5 crossbars totalement indépendants. Les spécifications détaillées peuvent être trouvées ​ici.

2.5 Opérations atomiques

Le contrôleur de cache L1 et le contrôleur de cache L2 implémentent le mécanisme de lecture-puis-écriture atomique (LL/SC) sans snoop. Les spécifications détaillées de ce mécanisme peuvent être trouvées ​ici.

2.6 Périphériques déportés

Les principaux contrôleurs de périphériques (contrôleur disque / contrôleur réseau / contrôleur TTY, contrôleur graphique, ROM de boot) ne sont pas distribués dans les clusters, mais sont connectés à un bus externe auquel on accède par un bridge (passerelle appelée IOB, pour Input Output Bridge) localisé dans le cluster de coordonnées(x_size-1,y_size-1).

Le simulateur de cette architecture TSAR est une application logicielle écrite en langage SystemC, s'exécutant sur une machine Linux, et appelée tsar.x. Le code source décrivant cette architecture est accessible dans le fichier `tsar/top.cpp'.

3. Système d'exploitation almos-mkh

Almos-mkh est un système d'exploitation généraliste de type UNIX (c'est-à-dire respectant la norme POSIX), qui vise à analyser - et si possible à résoudre - les problèmes de passage à l'échelle posés par les architectures manycores à espace d'adressage partagé de type NUMA. Le sigle ALMOS-MKH signifie Advanced Locality Management Operating System - Multi Kernel Hybrid. L'objectif principal est de favoriser la localité des accès mémoire par une gestion intelligente du placement, et surtout d'éliminer les goulots d'étranglement, par une politique de réplication et/ou de distribution des ressources et des services. Ceci explique l'approche multi-kernel rappelée ci-dessous. Pour permettre de s'adapter à différents types de systèmes de fichier, almos-mkh, comme la plupart des systèmes UNIX, accède aux fichiers stockés sur disque à travers une API de type VFS (Virtual File System). Actuellement almos-mkh supporte trois systèmes de fichiers: RAMFS, SYSFS, et FAT32. Pour ce TP et les suivants, on supposera que le disque externe est formaté au format FAT32.

Nous verrons en détails lors de la prochaine séance le preloader qui doit charger le système d'exploitation, le code de boot qui démarre le sysème et le démarrage du noyau.

4. Construction de la plate-forme

Vous allons utiliser des Makefile pour générer les fichiers décrits ci-dessous, et construire le disque externe utilisé par le simulateur.

• tsar.x : simulateur de la machine TSAR,
• preloader.elf : code de boot indépendant de l'OS,
• boot.elf : code de boot pour charger almos-mkh,
• kernel.elf : code du noyau almos-mkh,
• arch_info.bin : description de l'architecture matérielle pour almos-mkh,
• init.elf, ksh.elf, hello.elf, etc : différents codes applicatifs.

4.1 paramètrage du matériel

Le simulateur tsar.x est générique puisqu'on peut facilement faire varier:

• le nombre de clusters, défini par les paramètres x_size & y_size.
• le nombre de coeurs par cluster, défini par le paramètre ncores.
• les caractéristiques des périphériques internes et externes.
• la segmentation de l'espace adressable physique dans chaque cluster.

Le système d'exploitation almos-mkh a également besoin d'être configuré en fonction des caractéristiques de l'architecture cible.

• Le fichier permettant de configurer le matériel est le fichier texte hard_config.h, qui est inclus dans le fichier top.cpp (langage SystemC) permettant de générer le simulateur.
• Le fichier permettant de configurer le logiciel système est le fichier binaire arch_info.bin qui est lu sur le disque de l'architecture matérielle par le bootloader lors du démarrage de la plate-forme.

Pour éviter une incohérence entre ces deux fichiers de configuration, on génère ces deux fichiers à partir d'un unique fichier script arch_info.py, écrit en langage Python. Les spécifications détaillées de ce script sont définies ​ici.

En plus de ce script python, les paramètres matériels les plus importants (nombre de clusters, nombre de coeurs par cluster) peuvent être redéfinis grâce au fichier ​almos-mkh/params-hard.mk.

4.2 Génération du disque de la machine TSAR

Le but de cette étape est de produire une image disque au format FAT32 qui sera le disque utilisé par la machine TSAR. Ce disque contient les fichiers suivants:

• le fichier boot.elf, directement stocké dans le secteur 2 du disque.
• le fichier arch_info.bin, stocké dans le répertoire racine / du système de fichier.
• le fichier kernel.elf, stocké dans le répertoire /bin/kernel du système de fichier.
• les fichiers applications init.elf, ksh.elf, hello.elf, etc., stockés dans le répertoire /bin/user du système de fichier.

Pour construire cette image disque, le Makefile utilise le package standard mtools, qui fournit un ensemble d'outils pour construire et manipuler une image disque FAT32 sous Linux.

Pour utiliser ce package, il faut créer un fichier de configuration .mtools, qui doit être stocké dans votre répertoire home. La commande suivante permet de créer ce fichier :

echo "mtools_skip_check=1" >> ~/.mtoolsrc

Editez le fichier ​almos-mkh/params-hard.mk pour spécifier une architecture contenant un seul cluster et un seul coeur par cluster.

cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/almos-mkh
vi params-hard.mk

Puis lancez le Makefile situé dans le répertoire almos-mkh. Ce Makefile est hiérarchique. Il génère dans les sous-répertoires almos-mkh/kernel/build, almos-mkh/boot/tsar_mips32/build, ou almos-mkh/user/appli/build, les différents fichiers binaires exécutables au format .elf, et construit dans le répertoire almos-mkh/hdd l'image disque virt_hdd.dmg, qui est utilisée comme disque externe par la machine TSAR.

make

Vous pouvez vérifier le contenu de l'image disque virt_hdd.dmg générée en utilisant la commande mdir du package mtools:

mdir -/ -b -i hdd/virt_hdd.dmg ::/

L'exécution de ce Makefile permet également de générer le fichier almos-mkh/hard_config.h (pour configurer le simulateur tsar.x), et le fichier almos-mkh/arch_info.bin (pour configurer almos-mkh).

Ouvrez le fichier généré almos-mkh/hard_config.h pour vérifier que les informations qu'il contient sont cohérentes avec les informations contenues dans le fichier source (python) qui se trouve dans tsar/platforms/tsar_generic_iob/arch_info.py.

vi hard_config.h

4.3 Compilation du preloader

Le but de cette étape est de produire le code du préloader, sous la forme du fichier binaire preloader.elf, dont le contenu est préchargé par le simulateur tsar.x dans la ROM de boot.

Il faut se placer dans le répertoire tsar/softs/tsar_boot pour lancer la compilation.

cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/tsar/softs/tsar_boot/
make

Attention: Le code du preloader dépend du nombre de coeurs et du nombre de clusters, et il utilise le fichier hard_config.h pour obtenir cette information. Il faut donc re-compiler le préloader chaque fois qu'on modifie la plate-forme matérielle.

4.4 Génération du simulateur tsar.x

Le but de cette étape est de produire le simulateur tsar.x, pour l'architecture matérielle définie dans le fichier hard_config.h. Placez-vous dans le répertoire tsar/platforms/tsar_generic_iob qui contient le fichier top.cpp décrivant l'architecture TSAR.

La génération du fichier exécutable tsar.x utilise évidemment les composants matériels et logiciels de la plate-forme SoClib, et en particulier l'outil soclib-cc que vous avez déjà utilisé dans les TPs précédents.

cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/tsar/platforms/tsar_generic_iob/
make

Attention : Le fichier hard_config.h étant inclus dans le fichier top.cpp, il faut regénérer le simulateur tsar.x, à chaque fois que l'on change la configuration matérielle.

5. Plate-forme mono-processeur

Placez-vous dans le répertoire tsar/platforms/tsar_generic_iob pour lancer le simulateur.

./tsar.x

Deux fenêtres apparaissent :

• term0 : C'est la console du noyau où s'affichent les traces du système (pensez à l'agrandir un peu pour avoir un affichage du logo en entier).
• term1 : C'est un terminal utilisateur sur lequel le processus init démarre le premier schell ksh.

Sur le terminal term1, tapez la commande help en réponse au prompt [ksh], pour obtenir la liste des commandes disponibles.

[ksh] help <return>

Utilisez la commande ls pour obtenir la liste des applications disponibles dans le répertoire /bin/user.

[ksh] ls <return>

Utilisez la commande load pour lancer l'application hello.

[ksh] load /bin/user/hello.elf <return>

Pour arrêter l'exécution, de cette application, tapez <CTRL C>.

Lancez maintenant l'application idbg, qui permet d'afficher l'état courant de certaines structures internes du noyau.

[ksh] load /bin/user/idbg.elf <return>

Lorsque le prompt de l'application idbg s'affiche, tapez la commande h pour obtenir la liste des commandes idbg disponibles.

[idbg] h

Pour obtenir l'état des processus créés dans le cluster 0, tapez p puis 0. Tapez x pour tuer l'application idbg et redonner la propriété du terminal term1 à l'application ksh.

Pour arrêter la machine virtuelle, Tapez <CTRL C> dans le terminal où vous avez lancé le simulateur tsar.x, ce qui correspond à un hard reset.

6. Plate-forme multi-coeurs

Éditez le fichier : ​almos-mkh/params-hard.mk et modifier les paramètres X_SIZE, Y_SIZE, NCORES, NB_TTYS pour générer le simulateur d'une plate-forme matérielle comportant 4 clusters, 2 coeurs par cluster, et trois terminaux TTY. Avoir trois terminaux TTY permet d'avoir une console système, et deux shells en parallèle.

Placez-vous dans le répertoire almos-mkh, et supprimer tous les fichiers générés dans le répertoire almos-mkh.

cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/almos_mkh
make clean

Recompilez successivement

1. le code noyau (fichiers boot.elf, kernel.elf, hard_config.h, arch_info.bin,
2. le fichier preloader.elf,
3. le simulateur tsar.x

Lancez à travers le shell une ou plusieurs applications hello, en parallèle

7. Ajout d'une application utilisateur

Vous allez maintenant définir une nouvelle application utilisateur, la compiler, et enregistrer le fichier contenant le code binaire exécutable de cette application sur le disque utilisé par Tsar.

Le code source des applications utilisateur sont stockées dans le répertoire almos-mkh/user :

cd /dsk/l1/misc/<votre login>/almos-mkh_tsar_xy/
cd almos-mkh/user
ls
   convol  display  fft  hello  idbg  init  ksh  pgcd  sort  transpose

Vous allez dupliquer l'application hello en application bye :

cp -r hello bye

Dans le répertoire bye se trouve :

cd bye
ls -1
   build       -->  répertoire utilisé pour la compilation
   hello.c     -->  code source de l'application qu'il faut renommer en bye.c
   hello.ld    -->  ldscript utilisé par l'éditeur de lien pour produire l'exécutable qu'il faut renommer en bye.ld
   Makefile    -->  Makefile de compilation

Renommez hello.c et hello.ld respectivement en bye.c et bye.ld, puis:

1. Ouvrez bye.c
   Cette application créée deux threads exécutant le même code affichant chacun un message reçu en argument et attendant l'appui d'une touche. Changez juste les messages affichés.

2. Ouvrez bye.ld
   Ce fichier contient la description du mapping des sections produites par le compilateur C dans l'espace d'adressage de l'application. Il n'y a rien à changer ici parce que toutes les applications utilisent le même mapping.

3. Ouvrez Makefile
   Remplacer partout hellopar bye.

Vous allez maintenant modifiez le Makefile d'almos-mkh qui se trouve dans le répertoire racine d'almos-mkh.

1. Modifiez la cible .PHONY: pour ajouter user/bye/build/bye.elf
   Cette cible permet d'imposer la recompilation même quand les sources n'ont pas été modifiés.

2. Modifiez la cible compile: pour ajouter user/bye/build/bye.elf
   Ceci va permettre de compiler la nouvelle application.

3. Modifiez la cible clean: pour exécuter le Makefile dans user/bye
   Ceci va permettre de nettoyer le répertoire build de bye.

4. Ajouter la règle de production de l'exécutable bye.elf(c'est à la fin du Makefile)
   Notez que c'est dans cette règle que le nouvel exécutable est ajouté sur le disque de tsar.

Vous devez maintenant recompilez almos-mkh. Il n'est pas nécessaire de recompiler le preloader et le simulateur tsar.x, puisque l'architecture matérielle n'a pas été modifiée. Lancez l'exécution des applications hello.elfet bye.elfdans deux terminaux différents.

8. Questions

Répondez succinctement avec vos propres mots aux questions suivantes.

1. Quelle est la taille (en octets) de l'espace d'adressage physique. Quelle est la taille de l'espace virtuel?

2. Quelles sont les tailles des tables de 1er et 2e niveau d'une table de page ?

3. À quoi servent les bits V et D dans les tables de 1er et de 2e niveau de la table des pages ?

4. Quel est le nombre d'entrées de chaque TLB ?

5. Que signifie LL/SC ? À quoi servent ces instructions ?

6. Combien de réseaux DSPINs indépendants interconnectent les caches L1 et les caches L2 ? Pourquoi ?

7. Dans quel fichier doit-on indiquer le nombre de cores et le nombre de clusters ?

8. Quelle est la différence entre le bootloader et le preloader ?

9. À quoi sert le fichier ldscript utilisé pour la production d'un exécutable ?

10. Pourquoi toutes les applications utilisateur utilisent-t-elles le même ldscript ?

11. Pourquoi doit-on modifier l'image disque utilisée par TSAR pour ajouter une application ?