WTI mailbox attribution politic

Une version française de cette page peut être trouvée ​ici

The architecture ​TSAR has a component ​Iopic. This component permits an external peripheral to write to a specific address.

This peripheral is principally used to write to certain register of the ​Xicu component. Those registers are mailboxes, when one of them is written then the XICU emits an interrupt so the concerned core will execute the associated ISR.

We call those interruptions the Write Triggered Interruptions (WTI) because they are triggered by a write operation in the Xicu's mailboxes register.

Mailboxes' attribution

Each cluster possess an XICU which has 16 mailboxes, 4 of them are reserved for the inter process interruptions (IPI). The fifth mailbox of the cluster 0's Xicu is also reserved, it is the DEV_NULL mailbox, its use will be explained later.

External peripherals can use 12 of this mailboxes to signal their I/O operation's end and that the ISR associated to the peripheral has to be executed.

We choose an attribution politic called "polluter-payer".

When a thread executes an I/O operation, it will be the core which executes the thread which will execute the ISR associated to that operation. For this we have to :

1. get a mailbox,
2. reconfigure the Xicu's mask,
3. link the peripheral's ISR to the mailbox

When the ISR will execute, we have to :

1. release the mailbox,
2. reconfigure the Xicu's mask to mask the interrupt,
3. unlink the peripheral's ISR to the mailbox

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 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.