Politique d'attribution des boîtes aux lettres des WTI

An english version of this page can be found ​here

L'architecture ​TSAR possède un composant ​Iopic. Ce composant permet à un périphérique externe d'écrire à une adresse donnée.

Ce périphérique est principalement utilisé pour écrire dans certains registres du composant ​Xicu. Ces registres sont des boîtes aux lettres, lorsque l'une de ces boîtes a été écrite alors l'Xicu lèvera une interruption et le processeur concerné exécutera l'ISR associée.

On appelle ces interruptions des Write Triggered Interruptions (WTI) car elles sont déclenchées par une opération d'écriture dans les registres boîtes aux lettres de l'Xicu.

Attribution des boîtes aux lettres

Chaque cluster possède une Xicu qui contient 16 boîtes aux lettres, 4 sont réservées pour les interruptions inter-processeur (Inter Process Interruption ou IPI). Pour le cluster 0 la cinquième boîte aux lettres est aussi réservée, c'est la boîte DEV_NULL, son utilité sera détaillée plus tard.

Les périphériques externes peuvent donc utiliser 12 de ces boîtes aux lettres afin de signaler la fin de l'opération d'entrée sortie et qu'il faut donc lancer l'ISR associée à ce périphérique.

Nous avons choisi une politique d'attribution des boîtes aux lettres dite "pollueur/payeur".

Lorsqu'une thread exécute une opération d'entrée/sortie, ce sera le cœur sur lequel elle s'exécute qui traitera l'ISR associée à cette opération. Pour cela il faut donc :

1. obtenir une boîte aux lettres,
2. reconfigurer le masque de l'Xicu,
3. associer l'ISR du périphérique à la boîte aux lettres

Lors de l'exécution de l'ISR il faudra :

1. rendre la boîte aux lettres,
2. reconfigurer le masque l'Xicu pour masquer l'interruption,
3. dés-associer l'ISR du périphérique à la boîte aux lettres

Déroulement d'une opération d'entrée/sortie avec un périphérique externe

Chaque périphérique externe est protégé par un verrou global, pour pouvoir réaliser une opération d'entrée/sortie avec l'un de ces périphériques il faut d'abord prendre ce verrou.

Nous avons décidé qu'avant de prendre le verrou du périphérique le processeur devait s'assurer d'avoir obtenu une boîte aux lettres. En effet, il est plus facile d'obtenir une boîte aux lettres car il y en a 12 par cluster. De plus elles ne sont partagées que par les cœur d'un même cluster. A contrario, les périphériques sont uniques et tous les cœurs de l'architecture sont en concurrence pour les accéder.

Une fois la boîte aux lettres et le verrou du périphérique obtenus il faudra configurer l'Iopic afin que celui-ci écrive dans la boîte aux lettres.

Lors de la réception d'une interruption le verrou du périphérique et la boîte aux lettres seront rendus.

De plus, l'IOPIC sera dé-configuré, c'est-à-dire que si le périphérique envoie une interruption celle-ci ira dans une boîte aux lettres particulière : DEV_NULL.

La boîte aux lettres DEV_NULL est la première boîte aux lettres disponibles de l'XICU du cluster 0, son ISR est traitée par le cœur 0 de ce cluster.

L'ISR associée à cette boîte aux lettres particulières affiche uniquement un message d'erreur indiquant qu'une interruption non souhaitée a été reçue. Ce mécanisme a été implémenté afin de prémunir le système d'exploitation de potentiels dysfonctionnement d'un périphérique.

Dans la première figure, le cœur P1 initie une opération d'entrée/sortie avec le disque. En plus de paramétrer le disque, le cœur paramètre aussi l'IOPIC afin que le disque écrive dans la boîte aux lettres 5 de l'XICU locale.

Lorsque le disque aura fini son opération il ordonnera à l'IOPIC d'écrire dans la boîte aux lettres 5 ce qui aura pour effet de faire exécuter l'ISR liée au disque par le cœur P1.

API d'attribution des boîtes aux lettres

Pour mettre en place ce mécanisme nous avons dû écrire une API, celle-ci est composée d'une structure et de trois fonctions.

Les deux fonctions de base de l'API sont donc get_configure_mailbox et put_mailbox. En effet, celles-ci pourront être utilisées dans l'écriture de futur driver.

La structure mbox_manager

Cette structure est présente dans chaque cluster, elle contient deux champs :

• un spinlock pour prévenir les accès concurents
• un tableau d'état des boîtes aux lettres

Chaque case du tableau représente l'état d'une boîte aux lettres, ces différents états sont :

• IPI : La boîte aux lettres est utilisée pour une IPI, elle ne sera donc pas utilisée pour une WTI. Les n premières boîtes aux lettres sont réservées à cet usage (où n est le nombre de cœur du cluster).
• FREE : La boîte est libre et peut-être utilisée pour une WTI.
• L'identifiant local du cœur propriétaire.

void mbox_m_init(struct mbox_manager *mbox_m)

Cette fonction est appelée lors de l'initialisation du cluster, elle marque les premières boîtes aux lettres comme étant réservées aux IPI tandis que les autres seront marquées comme étant libres.

void get_configure_mailbox(struct mbox_manager *mbox_m, struct device_s *dev)

Cette fonction alloue une boîte aux lettres du mbox_manager mbox_m au device dev, puis elle reconfigure le masque de l'Xicu et associe l'ISR de dev à la boîte au lettre allouée. Cette fonction est bloquante tant qu'aucune boîte aux lettres n'a été trouvée.

int put_mailbox(uint_t wti_index, struct mbox_manager *mbox_m)

Cette fonction rend la boîte aux lettres d'index wti_index appartenant au mbox_manager mbox_m, elle masque aussi l'interruption et dés-associe l'ISR et la boîte aux lettres. Cette fonction renvoie 0 en cas de succès ou un code d'erreur dans le cas contraire.

Avantages et inconvénients de cette API

L'utilisation de cette API permet une certaine souplesse. En effet, grâce à cette API il serait possible d'utiliser tous les périphériques si on disposait d'une XICU possédant une unique boîte aux lettres (bien entendu les processeurs devraient se la partager et il y aurait alors de la séquentialité).

Grâce à la politique pollueur/payeur les caches des cœurs ne sont pas gâchés par l'ISR d'un cœur voisin.

Toutefois l'utilisation de cette API rallonge les opérations d'entrée/sortie. En effet, il semblerait que l'exécution d'un simple programme "open; read; close;" prenne 40 000 cycles supplémentaires par rapport à une opération d'entrée/sortie sans utilisation de l'API.