# SMC Compte Rendu TP9

## Binôme
* Guillaume VACHERIAS : 21204391
* Yann QUERIC : 28712032

## Questions sur la MMU de TSAR

### Question 1
* *Comment est découpée l'adresse virtuelle 32 bits ?*
L'adresse virtuelle de 32 bit est découpé en 3 parties ID1, ID2, Offset ave (ID1 + ID2 = Virtual Page Number) :
* ID1 (11 bits) : Indiquant l'indice à regarder sur la page de table 1
* ID2 (9 bits) : Indiquant l'indice à regarder sur la page de table 2
* OFFSET (12 bits) : Offset à regarder sur la table de dernière niveau contenant les adresses physiques

* *Quelle structure le composant MMU de l'architecture TSAR impose-t-il pour la table des pages que doit construire l'OS ?*
La structure du composant MMU impose que l'architecture de la table soit de 2 niveaux :
* Les adresses du premier niveau doivent être un multiple de 8K octets
* Les adresses du second niveau doivent un multiple de 4k octets

### Question 2
*Chaque entrée valide de la table des page (PTE = Page Table Entry) contient une valeur de PPN et quelques flags.*
* *Combien faut-il de bits pour représenter un PPN ?*
PPN nécessite 28 bits pour une page de 4K octets.
PPN nécessite 19 bits pour une page de 2M octets.

* *Quels sont les flags enregistrés dans chaque entrée de la table ?*
Les flags enregistrés sont :

| Flag | Column 2 |
| ---- | ------------- |
| V | Valid |
| T | Type |
| L | Local access |
| R | Remote access |
| C | Cachable |
| W | Writable |
| X | eXecutable |
| U | User |
| G | Global |
| D | Dirty |

### Question 3
* *Quel est le nom du registre de la MMU contenant l'adresse de base de la table de page ?*
Le nom du registre stockant cette adresse est le registre **MMU_PTPR** (Page Table Pointer Register)

* *À quoi sert ce registre ?*
Ce registre permet d'accéder au premier niveau de la table de page. Changer ce registre signifie de commuter un processus.
Registre est matérielle puisqu'il faut parcourir depui

### Question 4
* *Quel est le nom du registre de la MMU permettant d'activer ou de désactiver la MMU ?*
Le nom du registre permettant d'activer et désactiver est le registre **MMU_MODE**.

* *Comment l'OS peut-il utiliser ce registre ?*
Ce registre contient 4 bits activable pour data cache, instruction cache, data TLB et instruction TLB. Ces composants sont activables avec leurs bit à 1 :

| MODE3 | MODE2 | MODE1 | MODE3 |
| ------- | -------- | --------- | ---------- |
| INS TLB | DATA TLB | INS CACHE | DATA CACHE |

### Question 5
*Quel est le nom du registre permettant de construire une adresse data de 40 bits quand la MMU-DATA est désactivée ?*

On utilise le registre PTPR de la MMU qui contient 27 MSB bit du premier niveau de la page de table. Les 27 MSB bit sont étendu en 40 bit par l'automate Table-Walk dans un cas de TLB Miss.

### Question 6
*En cas de MISS sur la TLB, l'automate de la MMU accède à la tables pages pour obtenir le PTE manquant. Lorsque ce PTE est invalide (indiquant que la page n'est pas mappée), comment la MMU signale-t-elle le défaut de page au système d'exploitation ?*

Le matériel MMU peut lever des signaux d'exceptions via le *general_instruction_bus_error* et le *data_bus_error_signals*. Le type d'accés et l'erreur type sont écrit dans les registres MMU_IETR et MMU_DETR.
Il existe ainsi des exceptions tel que :
* MMU_WRITE_PT1_UNMAPPED
* MMU_WRITE_PT2_UNMAPPED
* MMU_READ_PT1_UNMAPPED
* MMU_READ_PT2_UNMAPPED

indiquant un accés invalide du PTE.

### Question 7
*Quels registres de la MMU doivent être sauvegardés et restaurés lors d'un changement de contexte ?*

Nous devons sauvegarder au moins les registres MMU_PTPR pour la table de page du processus courant et MMU_MODE pour l'activation du matériel

## Questions sur la politique de réplication & distribution

### Question 1
* *Comment almos-mkh représente-t-il l'ensemble des segments accessibles dans l'espace virtuel d'une application (c'est-à-dire d'un processus) ?*

L'ensemble des segments accessible d'un processus est définit par l'adresse virtuel. Ce dernier est composé de VPN (Virtual Page Number) de 2 niveaux dont ID1 (11 bits) représentant l'indexe dans la table première niveau et ID2 (9 bits) dans le deuxième. On rajout au VPN un OFFSET (12 bits) indiquant la position à regarder dans le dernier niveau de la page afin d'obtenir l'adresse physque.

* *À quoi sert cette structure ?*
Cette structure permet de mapper l'espace virtuel à l'espace physique et permet au différent processus de tourner en parallèle sans conflit d'espace d'adressage.

### Question 2
*La table des pages du processeur TSAR_MIPS32 est un radix-tree à 2 niveaux. La table des pages des processeurs Intel64 est un radix tree à 4 niveaux.*

* *Quelle est l'abstraction définie par Almos-mkh pour représenter une table des pages indépendante de l'architecture matérielle cible ?*
On utilise une abstraction définie sur l'indexation grâce au **VPN** (Virtual Page Number) et au **PPN** (Physical Page Number). La MMU effectue une translation de VPN vers PPN.

* *À quoi sert cette structure ?*
Cette structure permet de fournir une abstraction sur l'utilisation du radix tree. En effet, elle fournit une abstraction générale et c'est dans l'implémentation du cas de ALMOS-MKH qu'on utilise un radix tree.

### Question 3
*Pourquoi faut-il absolument que le descripteur d'un processus soit répliqué dans chaque cluster contenant au moins un thread de ce processus ?*

Le descripteur de processus contient la table d'adresse utilisé par le composant MMU pour traduire l'adresse virtuelle en adresse physique. Ainsi, en réplicant le descripteur de processus sur chaque cluster, on peut éviter le problème de contention puisqu'on a un composant MMU par core. Ainsi en sollicitant la MMU locale du core qui exécute le thread permet de réduire la surchage des cannaux.

### Question 4
*Quelle est la politique implémentée par almos-mkh pour minimiser la contention lors de l'accès au segment user CODE contenant le code, pour une application parallèle multi-threads ?*

Dans almos-mkh, un *private/public* vseg utilise 2 attributes :
* VSL(P, K) : liste segment virtuels du process P dans le cluster K
* GPT(P, K) : Generic Page Table qui définit l'adresse physique mapping pour chaque page et chaque vseg.

Le segment privé vseg contient le code l'application. Il est répliqué sur tous les clusters. Almos-mk crée un CODE vseg par cluster actif. Pour un process P, le CODE vseg est enregistré dans VSL(P, KREF) (KREF le cluster contenant le descripteur du processeur P). Dans les autres cluster K, CODE vseg est enregistré en VSL(P,K). Dans chaque cluster actif K, CODE vseg est mappé au cluster K.

### Question 5
*Quelle est la politique implémentée par almos-mkh pour maximiser la localité lors de l'accès au segment user STACK ?*

l'attribut privé vseg contient le stack du thread en exécution. Almos-mkh crée une STACK vseg par thread du processus P dans le cluster K. vseg est enregistré dynamiquement dans VSL(P,K) quand le descripteur du processeur est créé. Pour enforcer la localitén vseg est physiquement mappé au cluster K.

### Question 6
*Quelle est la politique implémentée par almos-mkh pour minimiser la contention lors de l'accès au segment user DATA contenant les données globales définies à la compilation, pour une application parallèle multi-threads ?*

Almos-mlh crée un DATA vseg qui est enregistré dans VSL(P, KREF) lorsque le processus P est crée. Dans chaque cluster K, DATA vseg est répliqué lors d'une page fault. Pour minimiser la contention lors de l'accès au user DATA, vseg est distribué sur tous les cluster :
* 2 page continue sont stcoké sur 2 cluster différent selon le bit LSB.

### Question 7
*Pourquoi les segments kernel KCODE, KDATA, KHEAP doivent-ils pouvoir être accédés localement par n'importe quel thread de n'importe quel processus utilisateur?*

Les thread d'un processus utilisateur doit pouvoir accéder au kernel segment pour effectuer des appels système et au resource protégé. Ainsi le VMM(P,K) d'un processus P du cluster K doit contenir le segement user et le jernel segment.

### Question 8
* *Pourquoi les N segments kernel KDATA et les N segments kernel KHEAP distribués dans tous les clusters doivent-ils pouvoir être accédés par n'importe quel thread de n'importe quel processus utilisateur?*
Le segment KDATA contient les data global du kernel.elf.
Le segment KHEAP contient les données (process descriptors, thread descriptos, vseg descriptos, ...) d'un processus du user en exécution.
Il est important que n'importe quel thread ait accés au N segements du KDATA et KHEAP pour s'exécuter.

* *Quelle abstraction Almos-mkh définit-il pour permettre ces accès distants ?*
Almos-mkh définit une abstraction à l'aide du VSL(P,K) mappé au GPT(P,K) pour un processus P du cluster K. VSL (Virtual Segment List) contient les adresses virtuels qui est mappé au GPT (Global Page Table) contenant les adresses physiques.

### Question 9
*Comment almos-mkh implémente-t-il ces accès distants dans le cas des architectures contenant des processeurs 32 bits telles que TSAR-MIPS32?*

Le problème d'accès au remote KDATA et KHEAP segements est causé par le manque d'adresse de l'espace virtuel adressable en 32 bits (4GBytes virtuel) puisque le total espace physique que doit couvrir par les N KHEAP segements est de 256Gbits.

Pour régler le problème, TSAR-MIPS32 simplifie la truction par un pointer XPTR(cxy,ptr) d'adresse physique de 40 bits :
* TSAR 40 bits est le résultat de la concaténation de 8 bits CXY et les 32 bits LPADDR. (cluster identifier et local physical adress du cluster)
* MIPS32 core utilise un autre composant que MMU pour la traduction d'adresse : 40 bits d'adresse physique est contruit en ajoutant les 32 bits adresses virtuel et les 8 bits d'extension dans le registre DATA_PADDR_EXT.

### Question 10
*Comment almos-mkh implémente-t-il ces accès distants dans le cas des architectures contenant des processeurs 64 bits telles que les serveurs Intel64 ?*

Dans le cas de d'adresse 64 bits, on a largement assez d'espace virtuel (256TBytes) pour couvrir l'espace physique. Tout les segment peuvent être mapper dans l'espacce virtuel :
* segment user est mappé par les bits du poids faible du user land
* KCODE, KDATA, KHEAP est mappé par les bits du poid fort du kernel land
* Les N segements KDATA et N segements KHEAP distribué dans les cluster sont mappé dans le kernel land.

On utilise la MMU qui est responsable de la traduction de l'adresse virtuelle à l'adresse physique dans dans les architecture 64 bits.

## Question prof