FR 3032537 A1 20160812 FR 1551012 A 20150209 1 La présente invention concerne un procédé d'exécution d'une requête d'échange de données entre des premier et deuxième espaces d'adressage physiques disjoints contrôlés respectivement par des premier et deuxième circuits sur carte ou puce distincts. D'une façon générale, les deux circuits peuvent être montés sur des cartes ou puces différentes, sur une même carte ou sur une même puce, voire dans un même boîtier grâce à l'utilisation de technologies d'intégration de types SiP (de l'anglais « Silicon in Package ») ou 3D. D'une façon générale également, les deux circuits sont interconnectés par des liens de communication rapides permettant à chacun d'accéder à l'espace d'adressage physique contrôlé par l'autre. Ces liens peuvent prendre la forme d'une matrice d'interconnexion d'un réseau sur puce (de l'anglais « Network on Chip »), d'un bus de transmission, d'une connexion à haut débit de type Fibre Channel et à topologie point-à-point, en anneau ou commutée, etc. Le contexte technologique dans lequel est amenée à s'exécuter une telle requête d'échange de données concerne principalement les architectures multiprocesseurs à noeuds de calculs interconnectés et les techniques de groupement de calculateurs en grappes de serveurs permettant de répondre à des besoins de plus en plus importants en puissance de calcul. Il est ainsi possible de concevoir des calculateurs de type HPC (de l'anglais « High Performance Computing ») pouvant intégrer jusqu'à dix mille microprocesseurs élémentaires à fréquences d'horloge très élevées et faible consommation, interconnectés entre eux par des liens à très hauts débits. Dans ces architectures, qualifiées de « scale-out », la mémoire est distribuée entre les processeurs en une pluralité de mémoires locales de grande capacité et des données peuvent devoir être échangées en permanence à haut débit d'une mémoire locale à l'autre en fonction de traitements distribués sur plusieurs processeurs travaillant en parallèle. Dans ces architectures également, les circuits munis de processeurs sont généralement en outre équipés de supports matériels pour la virtualisation de leurs systèmes d'exploitation avec des mécanismes d'accélération de cette virtualisation, pour le contrôle d'accès direct en mémoire à canaux multiples à l'aide du modèle de programmation RDMA (de l'anglais « Remote Direct Memory Access ») et pour la traduction d'adresses virtuelles en adresses physiques. 3032537 2 L'objectif peut être d'atteindre un maximum de Giga Flops (de l'anglais « Floating-point Operations Per Second ») en sollicitant un maximum de calculateurs et d'interconnexion en même temps. L'objectif peut aussi être de répondre à une exigence de proportionnalité 5 énergétique requise par les charges de calcul produites par les applications de la famille des traitements informatiques en nuage (de l'anglais « cloud computing ») dont la variabilité est une caractéristique majeure. Ces applications étant largement distribuées, très gourmandes en mémoire et en entrées/sorties, mais finalement assez peu en calcul proprement dit, les architectures « scale-out », plus efficaces 10 énergétiquement, sont mieux adaptées à ces nouvelles familles d'applications. Dans ce contexte, l'invention s'applique plus particulièrement à un procédé d'exécution d'une requête d'échange de données comportant les étapes suivantes : création d'un canal de communication entre : - un premier port d'accès du premier circuit, obtenu par un premier 15 processus logiciel s'exécutant dans le premier circuit qui comporte au moins un processeur d'exécution de ce premier processus logiciel dans le premier espace d'adressage physique, et - un deuxième port d'accès du deuxième circuit, obtenu par un deuxième processus logiciel s'exécutant dans le deuxième circuit qui 20 comporte au moins un processeur d'exécution de ce deuxième processus logiciel dans le deuxième espace d'adressage physique, émission, par le premier processus logiciel, de ladite requête d'échange de données, cette requête désignant une adresse virtuelle dans un espace d'adressage virtuel du deuxième processus logiciel, et 25 exécution, par des gestionnaires des premier et deuxième ports d'accès, de la requête d'échange de données entre les espaces d'adressage physiques disjoints des deux processus logiciels, sans sollicitation du processeur exécutant le deuxième processus logiciel. Pour éviter de solliciter les processeurs des circuits, et en particulier celui du 30 deuxième circuit, un tel procédé est généralement mis en oeuvre à l'aide d'adaptateurs réseaux onéreux et peu efficaces énergétiquement, par exemple selon le protocole RoCE (de l'anglais « RDMA over Converged Ethernet ») en technologie 10 Gigabit Ethernet utilisée pour implémenter le standard IEEE 802.3 à des débits compris entre 1 000 et 10 000 Mbits/s, selon la technologie Infiniband, ou encore selon d'autres technologies et protocoles. Un exemple de mise en oeuvre concrète 3032537 3 via le standard MPI (de l'anglais « Message Passing Interface ») en programmation RDMA sur Infiniband est par exemple décrit dans l'article de Liu et al, intitulé « High performance RDMA-based MPI implementation over Infiniband », publié dans International Journal of Parallel Programming, Special issue I: The 17th Annual 5 International Conference on Supercomputing (ICS'03), volume 32, n°3, pages 167- 198, juin 2004. Un autre exemple mettant en oeuvre des adaptateurs PCI Express et le protocole PCI-SIG est divulgué dans la demande de brevet européen EP 2 680 155 A1. Il convient de noter que, quels que soient les adaptateurs requis, ils sont en outre susceptibles d'ajouter de la latence dans les échanges de données. 10 Il peut ainsi être souhaité de prévoir un procédé d'exécution d'une requête d'échange de données qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités. Il est donc proposé un procédé d'exécution d'une requête d'échange de données entre des premier et deuxième espaces d'adressage physiques disjoints 15 contrôlés respectivement par des premier et deuxième circuits sur carte ou puce distincts, comportant les étapes suivantes : création d'un canal de communication entre : - un premier port d'accès du premier circuit, obtenu par un premier processus logiciel s'exécutant dans le premier circuit qui comporte au 20 moins un processeur d'exécution de ce premier processus logiciel dans le premier espace d'adressage physique, et - un deuxième port d'accès du deuxième circuit, obtenu par un deuxième processus logiciel s'exécutant dans le deuxième circuit qui comporte au moins un processeur d'exécution de ce deuxième 25 processus logiciel dans le deuxième espace d'adressage physique, émission, par le premier processus logiciel, de ladite requête d'échange de données, cette requête désignant une adresse virtuelle dans un espace d'adressage virtuel du deuxième processus logiciel, et exécution, par des gestionnaires des premier et deuxième ports d'accès, 30 de la requête d'échange de données entre les espaces d'adressage physiques disjoints des deux processus logiciels, sans sollicitation du processeur exécutant le deuxième processus logiciel. selon lequel : - lors de la création du canal de communication, une traduction de l'espace 35 d'adressage virtuel du deuxième processus logiciel vers son espace 3032537 4 d'adressage physique est créée et associée à ce canal de communication dans le deuxième circuit, et lors de l'exécution de la requête, des données d'identification du canal de communication sont ajoutées à l'adresse virtuelle désignée dans la 5 requête. Ainsi, par une astuce peu onéreuse et sans surcoût énergétique sensible, i.e. l'ajout de quelques bits à l'adresse virtuelle désignée dans la requête pour y insérer des données d'identification du canal de communication, on permet d'exécuter du côté du deuxième circuit une traduction aisée et rapide de cette adresse virtuelle en 10 adresse physique de l'espace d'adressage physique contrôlé par le deuxième circuit, sans sollicitation de son processeur et sans aucun besoin en adaptation réseau. De façon optionnelle, la traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique est exploitée par une unité de gestion mémoire du deuxième circuit pour déterminer quelle adresse 15 physique du deuxième espace d'adressage physique correspond à l'adresse virtuelle désignée dans la requête à partir des données d'identification du canal de communication ajoutées à cette adresse virtuelle. De façon optionnelle également, les données d'identification du canal de communication ajoutées à l'adresse virtuelle désignée dans la requête comportent un 20 identifiant du deuxième circuit, d'un système d'exploitation sur lequel s'exécute le deuxième processus logiciel et du deuxième port d'accès obtenu par le deuxième processus logiciel, et un identifiant d'une mémoire tampon d'échange définie du côté du deuxième circuit. De façon optionnelle également, les données d'identification du canal de 25 communication sont ajoutées à l'adresse virtuelle désignée dans la requête par le gestionnaire du premier port d'accès du premier circuit. De façon optionnelle également, l'ajout des données d'identification du canal de communication à l'adresse virtuelle désignée dans la requête se fait par encapsulation de cette adresse virtuelle dans une adresse de transport, cette adresse 30 de transport étant transmise puis traitée par le gestionnaire du deuxième port d'accès comme une adresse virtuelle à traduire. De façon optionnelle également, l'exécution de la requête est gérée par une communication directe établie entre le processeur du premier circuit et une mémoire locale du deuxième circuit. 35 Dans ce cas, de façon optionnelle : 3032537 5 la traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique est exploitée par une unité de gestion mémoire du processeur du premier circuit, et cette unité de gestion mémoire exploite en outre la traduction de l'espace 5 d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire utilisé pour indexer une table de correspondance dans laquelle sont conservées les données d'identification du canal de communication. De façon optionnelle également, l'exécution de la requête est gérée par une 10 communication indirecte établie entre le processeur du premier circuit et une mémoire locale du deuxième circuit avec la sollicitation d'un contrôleur d'accès direct en mémoire pour des accès en écriture et en lecture, en mémoire locale ou à distance, indépendants du processeur du premier circuit. Dans ce cas, de façon optionnelle : 15 - la traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique est exploitée par une unité de gestion mémoire associée spécifiquement au contrôleur d'accès direct en mémoire, et cette unité de gestion mémoire exploite en outre la traduction de l'espace 20 d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire utilisé pour indexer une table de correspondance dans laquelle sont conservées les données d'identification du canal de communication. De façon optionnelle également, la requête d'échange de données émise par 25 le premier processus logiciel concerne : une lecture de données stockées dans le premier espace d'adressage physique dans lequel s'exécute le premier processus logiciel et une écriture de ces données dans le deuxième espace d'adressage physique dans lequel s'exécute le deuxième processus 30 logiciel, ou une lecture de données stockées dans le deuxième espace d'adressage physique dans lequel s'exécute le deuxième processus logiciel et une écriture de ces données dans le premier espace d'adressage physique dans lequel s'exécute le premier processus 35 logiciel. 3032537 6 De façon optionnelle également, au moins l'un des premier et deuxième processus logiciels s'exécute sur une machine virtuelle exécutée elle-même par un hyperviseur du processeur correspondant, chaque traduction d'adresse virtuelle en adresse physique locale correspondante comportant une traduction d'adresse 5 virtuelle en adresse physique intermédiaire vue par la machine virtuelle et une traduction d'adresse physique intermédiaire en adresse physique vue par l'hyperviseur. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés 10 dans lesquels : la figure 1 représente schématiquement la structure générale d'un système sur carte ou sur puce adapté pour la mise en oeuvre d'un procédé d'exécution d'une requête d'échange de données selon l'invention, les figures 2A et 2B illustrent les étapes successives d'un procédé de 15 d'exécution d'une requête d'échange de données entre deux circuits du système de la figure 1 ainsi que les trajets en écriture/lecture correspondants, selon un premier mode de réalisation de l'invention, et les figures 3A et 3B illustrent les étapes successives d'un procédé de d'exécution d'une requête d'échange de données entre deux circuits du 20 système de la figure 1 ainsi que les trajets en écriture/lecture correspondants, selon d'autres modes de réalisation de l'invention. Le système 10, sur carte ou sur puce, représenté schématiquement sur la figure 1, comporte une pluralité de circuits dont deux seulement sont illustrés. Un premier circuit 12 comporte un processeur principal 14, de type mono- ou 25 multi- processeur, mono- ou multi-coeur. Il est par ailleurs associé à une mémoire locale 16 et comporte, pour y accéder en lecture ou en écriture, un contrôleur de mémoire 18. Il comporte en outre un coprocesseur 20 d'accès direct en mémoire, plus précisément un contrôleur DMA (de l'anglais « Direct Memory Access »). L'accès direct en mémoire est un procédé informatique bien connu selon lequel des données 30 provenant de ou destinées à être transmises vers un périphérique, par exemple un autre circuit du système 10, sont transférées directement par le contrôleur DMA 20 vers ou depuis la mémoire locale 16, sans intervention du processeur principal 14 sauf pour lancer et conclure le transfert. Le premier circuit 12 présente en outre une interface 22 de connexion au reste du système 10. Le processeur principal 14, le 3032537 7 contrôleur de mémoire 18, le contrôleur DMA 20 et l'interface 22 sont interconnectés dans le premier circuit 12 à l'aide d'un réseau interne d'interconnexion 24. Le processeur principal 14 est destiné à exécuter des instructions de processus logiciels dans des espaces d'adressage physiques qui leur sont réservés 5 en mémoire locale 16. Il peut le faire par l'intermédiaire d'un système d'exploitation qui lui est propre ou par l'intermédiaire d'un ou plusieurs systèmes d'exploitation invités, qualifiés de « machines virtuelles », exécutés eux-mêmes par un hyperviseur ou VMM (de l'anglais « Virtual Machine Monitor »). Dans tous les cas, les adresses de mémoire identifiées dans les instructions des processus logiciels sont virtuelles et 10 nécessitent d'être traduites en adresses physiques dans les espaces d'adressage physiques correspondants pour la bonne exécution de ces instructions. C'est pourquoi le processeur principal 14 comporte une unité de gestion mémoire 26, appelée MMU (de l'anglais « Memory Management Unit »), dont la fonction est de réaliser ces traductions d'adresses virtuelles en adresses physiques pour chaque 15 processus logiciel. Lorsqu'un processus logiciel s'exécute directement sur le système d'exploitation du processeur principal 14, un seul niveau de traduction d'adresse virtuelle en adresse physique est réalisé par la MMU 26. En revanche, lorsqu'un processus logiciel s'exécute sur une machine virtuelle du processeur principal 14, deux niveaux de traduction d'adresse virtuelle en adresse physique intermédiaire 20 (celle vue par la machine virtuelle), puis d'adresse physique intermédiaire en adresse physique (celle vue par l'hyperviseur), sont réalisés par la MMU 26. En ce qui concerne le contrôleur DMA 20 dont les accès en lecture ou écriture à la mémoire locale 16 sont indépendants du processeur principal 14, il gère lui aussi des adresses virtuelles d'instructions de processus, de sorte qu'il a lui aussi besoin 25 d'une unité de gestion mémoire 28 indépendante de la MMU 26. Cette unité de gestion mémoire 28 spécifique au contrôleur DMA 20 est généralement appelée IOMMU (de l'anglais « Input/Output Memory Management Unit ») parce qu'elle concerne des entrées/sorties du premier circuit 12. Elle est à un ou deux niveaux de traduction. 30 Par ailleurs, comme on le verra par la suite pour la mise en oeuvre d'un échange de données selon l'invention, le premier circuit 12 comporte une unité de gestion mémoire supplémentaire 30, indépendante de la MMU 26 et de la IOMMU 28, pour traduire en adresses physiques de la mémoire locale 16, des adresses virtuelles incluses dans des requêtes d'échange de données reçues par le premier circuit 12 35 via l'interface 22. Cette unité de gestion mémoire supplémentaire 30 est aussi 3032537 8 généralement appelée IOMMU parce qu'elle concerne aussi des entrées/sorties du premier circuit 12. Elle est aussi à un ou deux niveaux de traduction. Enfin, comme on le verra également par la suite pour la mise en oeuvre d'un échange de données selon l'invention, le premier circuit 12 comporte des moyens de 5 mise en correspondance d'adresses virtuelles avec des données d'identification de canaux de communication établis entre des processus logiciels du premier circuit 12 et des processus logiciels d'autres circuits. Ces moyens prennent par exemple la forme d'une table de correspondance 32, généralement appelée LUT (de l'anglais « Look-Up Table »), utilisée pour ajouter des données d'identification de canaux de 10 communication dans des requêtes d'échange de données émises par le premier circuit 12 via l'interface 22. Un deuxième circuit 34 illustré sur la figure 1 est identique au premier circuit 12. Il comporte un processeur principal 36, est associé à une mémoire locale 38 et comporte, pour y accéder en lecture ou en écriture, un contrôleur de mémoire 40. Il 15 comporte en outre un contrôleur DMA 42 et une interface 44 de connexion au reste du système 10. Le processeur principal 36, le contrôleur de mémoire 40, le contrôleur DMA 42 et l'interface 44 sont interconnectés dans le deuxième circuit 34 à l'aide d'un réseau interne d'interconnexion 46. Le processeur principal 36 comporte une MMU 48 dont la fonction est de 20 réaliser des traductions d'adresses virtuelles en adresses physiques pour chaque processus logiciel qu'il exécute. Comme pour le premier circuit 12, lorsqu'un processus logiciel s'exécute directement sur le système d'exploitation du processeur principal 36, un seul niveau de traduction d'adresse virtuelle en adresse physique est réalisé par la MMU 48. En revanche, lorsqu'un processus logiciel s'exécute sur une 25 machine virtuelle du processeur principal 36, deux niveaux de traduction d'adresse virtuelle en adresse physique intermédiaire (celle vue par la machine virtuelle), puis d'adresse physique intermédiaire en adresse physique (celle vue par l'hyperviseur), sont réalisés par la MMU 48. En ce qui concerne le contrôleur DMA 42 dont les accès en lecture ou écriture 30 à la mémoire locale 38 sont indépendants du processeur principal 36, il gère lui aussi des adresses virtuelles d'instructions de processus, de sorte qu'il est associé à une IOMMU 50 à un ou deux niveaux de traduction. Par ailleurs, par symétrie avec le premier circuit 12, le deuxième circuit 34 comporte une IOMMU supplémentaire 52 à un ou deux niveaux de traduction, 35 indépendante de la MMU 48 et de la IOMMU 50, pour traduire en adresses physiques 3032537 9 de la mémoire locale 38, des adresses virtuelles incluses dans des requêtes d'échange de données reçues par le deuxième circuit 34 via l'interface 44. Enfin, également par symétrie avec le premier circuit 12, le deuxième circuit 34 comporte des moyens de mise en correspondance d'adresses virtuelles avec des 5 données d'identification de canaux de communication établis entre des processus logiciels du deuxième circuit 34 et des processus logiciels d'autres circuits. Ces moyens prennent par exemple la forme d'une LUT 54, utilisée pour ajouter des données d'identification de canaux de communication dans des requêtes d'échange de données émises par le deuxième circuit 34 via l'interface 44. 10 Les premier et deuxième circuits 12 et 34 sont reliés l'un à l'autre à l'aide d'une interconnexion 56 qui peut prendre la forme d'une matrice d'interconnexion d'un réseau sur puce, d'un bus de transmission, d'une connexion à haut débit de type Fibre Channel et à topologie point-à-point, en anneau ou commutée, etc. Un procédé d'exécution d'une requête d'échange de données entre des 15 espaces d'adressage physiques disjoints contrôlés respectivement par les premier et deuxième circuits 12 et 34 va maintenant être détaillé en référence aux figures 2A, 2B et 3A, 3B selon différents modes de réalisation possibles. Dans ces figures et à titre d'exemple non limitatif, la requête est émise par un premier processus logiciel s'exécutant dans le premier circuit 12, un premier espace d'adressage physique étant 20 alloué à ce premier processus logiciel dans la mémoire locale 16 par le processeur principal 14. Elle concerne un échange de données avec un deuxième espace d'adressage physique, disjoint du premier, alloué dans la mémoire locale 38 par le processeur principal 36 à un deuxième processus logiciel s'exécutant dans le deuxième circuit 34. 25 Conformément à un premier mode de réalisation de l'invention, la figure 2A illustre la mise en oeuvre d'un tel procédé dans le contexte suivant : une communication directe, c'est-à-dire sans sollicitation du contrôleur DMA 20 et de sa IOMMU 28, peut être établie entre le processeur principal 14 du premier circuit 12 et la mémoire locale 38 du deuxième circuit 34, 30 les adresses virtuelles sont codées sur 64 bits et les adresses physiques sur 48 bits, le premier processus logiciel émetteur de la requête d'échange de données s'exécute directement sur le système d'exploitation du processeur principal 14, et 3032537 10 l'échange de données requis est une écriture à distance, c'est-à-dire une lecture de données stockées dans le premier espace d'adressage physique de la mémoire 16 dans lequel s'exécute le premier processus logiciel et une écriture de ces données dans le deuxième espace d'adressage 5 physique de la mémoire 38 dans lequel s'exécute le deuxième processus logiciel. Dans ce mode de réalisation, la présence du contrôleur DMA 20 et de sa IOMMU 28 n'est pas nécessaire. Par symétrie, la présence du contrôleur DMA 42 et de sa IOMMU 50 n'est pas nécessaire non plus. 10 Au cours d'une première étape de négociation 100 d'une phase de création de canal de communication, un canal de communication est négocié entre un premier port d'accès du premier circuit 12, obtenu par le premier processus logiciel s'exécutant dans le premier circuit 12, et un deuxième port d'accès du deuxième circuit 34, obtenu par le deuxième processus logiciel s'exécutant dans le deuxième 15 circuit 34. Conformément à cette transaction établie entre les deux processus logiciels dont les espaces d'adressage physiques sont concernés par l'échange, une mémoire tampon (de l'anglais « buffer ») d'échange est allouée par le système d'exploitation du processeur principal 14, cette mémoire tampon définissant un premier espace d'adressage virtuel à utiliser pour le premier processus logiciel et un 20 deuxième espace d'adressage virtuel à utiliser pour le deuxième processus logiciel dans le premier circuit 12. De même par réciprocité, une mémoire tampon d'échange est également allouée par le système d'exploitation du processeur principal 36 du côté du deuxième circuit 34. En reprenant à titre d'exemple non limitatif une sémantique de type Infiniband, le canal de communication peut être complètement 25 identifié par le quadruplet de données suivantes : LIDsRc : un paramètre, par exemple codé sur 16 bits, identifiant le premier circuit 12, le système d'exploitation sur lequel s'exécute le premier processus logiciel dans le premier circuit 12 et le premier port d'accès du premier circuit 12, 30 KEYsc : un paramètre, par exemple codé sur 16 bits, identifiant de façon sécurisée la mémoire tampon d'échange définie du côté du premier circuit 12, LIDDEsT : un paramètre, par exemple codé sur 16 bits, identifiant le deuxième circuit 34, le système d'exploitation sur lequel s'exécute le 3032537 11 deuxième processus logiciel dans le deuxième circuit 34 et le deuxième port d'accès du deuxième circuit 34, - KEYDEsT : un paramètre, par exemple codé sur 16 bits, identifiant de façon sécurisée la mémoire tampon d'échange définie du côté du deuxième 5 circuit 34. Ce quadruplet (LIDsRc, KEYsRc, LIDDEsT, KEYDEsT) définit de façon unique la transaction établie entre les deux processus logiciels concernés par l'échange de données. Plus précisément, le couple (LIDsRc, KEYsRc) définit le contexte mémoire à 10 utiliser éventuellement du côté du premier circuit 12 pour effectuer les traductions entre adresses virtuelles et adresses physiques et le couple (LIDDEsT, KEY ) définit DEST, le contexte mémoire à utiliser du côté du deuxième circuit 34 pour effectuer les traductions entre adresses virtuelles et adresses physiques. Les quatre paramètres sont renseignés au cours de la première étape 100 et conservés en mémoire par les 15 deux circuits 12 et 34. On notera que le protocole mis en oeuvre pour la négociation de ce quadruplet de paramètres est indépendant de la présente invention et peut être choisi librement parmi des protocoles bien connus de l'homme du métier. Au cours d'une étape suivante de configuration 102 de la phase de création de canal de communication, la MMU 26 du processeur principal 14 du premier circuit 20 12 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique. Cela peut se faire en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte mémoire (LIDsRc, KEYsRc), mais en communication directe entre le processeur principal 14 du premier circuit 12 et la mémoire locale 38 du deuxième 25 circuit 34 cela peut aussi se faire autrement, de façon connue en soi, sans avoir besoin de ce contexte mémoire. De même, la IOMMU 52 du deuxième circuit 34 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte - DEST, - 30 mémoire (LIDDEsT, KEY En outre, la MMU 26 du processeur principal 14 du premier circuit 12 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire, représentant l'espace d'adressage physique du deuxième processus logiciel vu depuis le premier circuit 12. Enfin, la LUT 32 du premier circuit 12 est 3032537 12 configurée pour associer cet espace d'adressage physique temporaire au contexte mémoire (LIDDEST, KEYDEST) exploitable par le deuxième circuit 34. Ensuite, au cours d'une étape 104, le premier processus logiciel émet une requête d'écriture à distance, cette requête désignant une première adresse virtuelle 5 VAsic d'une donnée à lire dans le premier espace d'adressage virtuel du premier processus logiciel et une deuxième adresse virtuelle VADEST dans laquelle écrire la donnée lue, cette deuxième adresse virtuelle VADEST étant incluse dans le deuxième espace d'adressage virtuel du deuxième processus logiciel. Ces deux adresses virtuelles VASRC et VADEST sont codées sur 64 bits. 10 Au cours d'une étape 106 suivante, l'adresse virtuelle VASRC est traduite par la MMU 26 en une adresse physique PASRC de 48 bits. Cette adresse physique PAsic localise précisément la donnée à lire dans la mémoire locale 16, dans l'espace d'adressage physique alloué au premier processus logiciel par le processeur principal 14. 15 Ensuite, au cours d'une étape de lecture 108, la donnée à lire dans la mémoire locale 16 est lue. Au cours d'une étape 110 suivante, l'adresse virtuelle VADEST est traduite par la MMU 26 en une adresse physique temporaire TPADEST. Cette adresse physique temporaire TPADEST est codée sur 48 bits et n'a pas de signification concrète. En 20 revanche, elle comporte une traduction IOVADEST de la deuxième adresse virtuelle VADEST, codée sur 32 bits et exploitable par la IOMMU 52 du deuxième circuit 34, un paramètre (KEYDEST codé sur 12 bits, ce paramètre (KEYDEST DEST étant dérivé du paramètre KEYDEST pour indexer la LUT 32, un complément à 0 jusqu'au 47e bit et un bit de poids fort à 1. Elle prend ainsi par exemple la forme suivante : 47...44 43 ... 32 31 0 TPADEST 1 0 0 0 I KEYDEST IOVADEST 25 Le bit de poids fort à 1 indique par exemple que cette adresse physique temporaire indexe la LUT 32. Au cours d'une étape 112 suivante, un gestionnaire du premier port d'accès du premier circuit 12 (i.e. le système d'exploitation du processeur principal 14) retrouve, à l'aide de la LUT 32 indexée par l'adresse physique temporaire TPADEST, 30 en particulier par son paramètre IKEY - DEST,DEST, le couple (LIDDEST, KEYDEST) identifiant le contexte mémoire exploitable par le deuxième circuit 34. Il s'en sert pour ajouter les paramètres de ce couple à l'adresse virtuelle IOVADEST maintenant désignée dans la requête d'écriture à distance. 3032537 13 A titre d'exemple concret, l'adresse physique temporaire TPADEST est traduite en une adresse de transport TADEST codée sur 64 bits : TADEST La requête d'écriture à distance est alors transmise par le gestionnaire du premier port d'accès du premier circuit 12 vers l'interconnexion 56 via l'interface 22 5 au cours d'une étape de transmission 114. Cette requête comporte l'adresse de transport TADEST accompagnée du paramètre LIDDEsp Elle est routée de façon classique à travers l'interconnexion 56 jusqu'au deuxième circuit 34. Ce routage peut être facilité grâce à des informations spécifiques contenues dans le paramètre LIDDEs-r- 10 A réception 116 de cette requête par un gestionnaire du deuxième port d'accès du deuxième circuit 34 (i.e. le système d'exploitation ou l'hyperviseur du processeur principal 36), l'adresse de transport TADEST accompagnée du paramètre LIDDEST est traduite par la IOMMU 52 en une adresse physique PADEST sur 48 bits grâce à l'adresse virtuelle IOVADEST, incluse dans l'adresse de transport TADEST, et à 15 au moins une partie des données du contexte mémoire (LIDDEST, KEYDEST) dont le paramètre KEYDEST DEST est inclus dans l'adresse de transport TADEST et dont le paramètre LIDDEST accompagne cette adresse de transport. Le gestionnaire du deuxième port d'accès du deuxième circuit 34 n'a donc pas besoin de solliciter le processeur principal 36 pour réaliser cette traduction. 20 Ensuite, au cours d'une étape d'écriture 118, la donnée lue dans la mémoire locale 16 est écrite dans la mémoire locale 38, à l'adresse physique désignée par PADEST- Le trajet des accès en lecture et écriture du procédé de la figure 2A est illustré sur la figure 2B. On remarque que, même si le processeur principal 14 du premier 25 circuit 12 est sollicité pour l'écriture à distance, ce n'est pas le cas du processeur principal 36 du deuxième circuit 34. On remarque en outre qu'aucun adaptateur de réseau particulier n'est sollicité. On notera qu'il est simple d'adapter le procédé précédemment décrit en une lecture à distance. Il suffit d'émettre une requête de lecture à l'étape 104, puis 30 d'exécuter les étapes 110 à 116 au lieu de l'étape 106, puis de remplacer l'étape 118 par une étape 118' de lecture de donnée à l'adresse physique PADEST de la mémoire locale 38, puis de transmettre cette donnée lue au premier circuit 12, puis d'exécuter 63 ... 48 47 ... 32 31 ... 0 0 ... 0 KEYDEST DEST IOVADEST 3032537 14 l'étape 106, puis enfin de remplacer l'étape 108 par une étape 108' d'écriture de donnée à l'adresse physique PAsic de la mémoire locale 16. On notera également qu'il est simple d'adapter le procédé précédemment décrit pour un échange de données dont la requête serait émise à l'initiative du 5 deuxième processus logiciel du deuxième circuit 34. Ainsi, par symétrie, au cours de l'étape de configuration 102, la MMU 48 du processeur principal 36 du deuxième circuit 34 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique en association avec le canal de communication 10 négocié, c'est-à-dire en association avec le contexte mémoire (LIDDEST, KEY De - DEST,- 1 D même, la IOMMU 30 du premier circuit 12 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte mémoire (LIDsRc, KEYsRc). En 15 outre, la MMU 48 du processeur principal 36 du deuxième circuit 34 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire, représentant l'espace d'adressage physique du premier processus logiciel vu depuis le deuxième circuit 34. Enfin, la LUT 54 du deuxième circuit 34 peut être configurée pour associer 20 cet espace d'adressage physique temporaire au contexte mémoire (LIDsRc, KEYsRc) exploitable par le premier circuit 12. Il suffit ensuite d'adapter les étapes 104 à 118 pour une écriture ou lecture à distance émise depuis le deuxième circuit 34. Conformément à un deuxième mode de réalisation de l'invention, la figure 3A illustre la mise en oeuvre d'un procédé d'exécution d'une requête d'échange de 25 données dans le contexte suivant : une communication indirecte, c'est-à-dire avec sollicitation du contrôleur DMA 20 et de sa IOMMU 28, est établie entre le processeur principal 14 du premier circuit 12 et la mémoire locale 38 du deuxième circuit 34, les adresses virtuelles sont codées sur 64 bits et les adresses physiques 30 sur 48 bits, le premier processus logiciel émetteur de la requête d'échange de données s'exécute directement sur le système d'exploitation du processeur principal 14, et l'échange de données requis est une écriture à distance, c'est-à-dire une 35 lecture de données stockées dans le premier espace d'adressage physique 3032537 15 de la mémoire 16 dans lequel s'exécute le premier processus logiciel et une écriture de ces données dans le deuxième espace d'adressage physique de la mémoire 38 dans lequel s'exécute le deuxième processus logiciel. 5 Dans ce mode de réalisation, la présence du contrôleur DMA 20 et de sa IOMMU 28 est nécessaire. Par symétrie, la présence du contrôleur DMA 42 et de sa IOMMU 50 est également nécessaire si l'on envisage un échange de données dont la requête est émise à l'initiative du deuxième processus logiciel du deuxième circuit 34. Les communications gérées par le contrôleur DMA se font selon le modèle de 10 programmation RDMA, sans qu'il soit nécessaire de détailler le fonctionnement de ce modèle bien connu dans la suite de la description. La première étape de négociation 200 de la phase de création de canal de communication de ce deuxième mode de réalisation est identique à l'étape 100 précédemment décrite. 15 Au cours d'une étape suivante de configuration 202 de la phase de création de canal de communication, la IOMMU 28 du contrôleur DMA 20 du premier circuit 12 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte 20 mémoire (LIDsRc, KEYsRc). De même, la IOMMU 52 du deuxième circuit 34 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte mémoire (LI D DEST, KEYDEST)- En outre, la IOMMU 28 du contrôleur DMA 20 du 25 premier circuit 12 est configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire, représentant l'espace d'adressage physique du deuxième processus logiciel vu depuis le premier circuit 12. Enfin, la LUT 32 du premier circuit 12 est configurée pour associer cet espace d'adressage physique temporaire au contexte / 30 mémoire (LIDDEsT, KEYDEST 1 exploitable par le deuxième circuit 34. Ensuite, au cours d'une étape 204, le premier processus logiciel émet une requête d'écriture à distance, cette requête désignant une première adresse virtuelle IOVASRC d'une donnée à lire dans le premier espace d'adressage virtuel du premier processus logiciel et une deuxième adresse virtuelle IOVADEST dans laquelle écrire la 35 donnée lue, cette deuxième adresse virtuelle IOVADEST étant incluse dans le 3032537 16 deuxième espace d'adressage virtuel du deuxième processus logiciel. Ces deux adresses virtuelles IOVAsRc et IOVADEST, exploitables par le contrôleur DMA 20 et sa IOMMU 28, sont prises en charge par le contrôleur DMA 20. Plus précisément, la première adresse virtuelle IOVASRC, codée sur 32 bits, 5 est encapsulée dans une adresse virtuelle VASRC plus complète codée sur 64 bits qui comporte en outre le paramètre KEYSRC codé sur 16 bits et un complément à 0 : VASRC 63 ... 48 47 ... 32 31 ... 0 0 ... 0 KEYSRC IOVAsRc Plus précisément également, la deuxième adresse virtuelle IOVADEST, codée sur 32 bits, est encapsulée dans une adresse virtuelle VADEST plus complète codée sur 64 bits qui comporte en outre le paramètre IKEYDEST défini précédemment, et un 10 complément à 0 : 63 44 43 ... 32 31 0 VADEST I KEYDEST IOVADEST Au cours d'une étape 206 suivante, l'adresse virtuelle IOVASRC est traduite par la IOMMU 28 en l'adresse physique PASRC définie précédemment grâce au contexte mémoire (LIDSRC, KEYSRC) qui est connu du contrôleur DMA 20. Ensuite, au cours d'une étape de lecture 208, la donnée à lire dans la 15 mémoire locale 16 est lue par le contrôleur DMA 20 sans solliciter le processeur principal 14. Au cours d'une étape 210 suivante, l'adresse virtuelle VADEST est traduite par la IOMMU 28 en l'adresse physique temporaire TPADEST définie précédemment. La traduction consiste dans ce mode de réalisation à simplement à supprimer les 16 bits 20 de poids fort de VADEST et à mettre le 48e bit à 1. Les étapes 212 à 218 suivantes sont identiques aux étapes 112 à 118 du mode de réalisation précédent. Le trajet des accès en lecture et écriture du procédé de la figure 3A est illustré sur la figure 3B. On remarque qu'aucun des processeurs principaux 14 et 36 n'est 25 sollicité. On remarque en outre qu'aucun adaptateur de réseau particulier n'est sollicité. On notera qu'il est simple, comme dans le premier mode de réalisation, d'adapter le procédé précédemment décrit en une lecture à distance ou pour un échange de données dont la requête serait émise à l'initiative du deuxième processus 30 logiciel du deuxième circuit 34. 3032537 17 Ainsi, par symétrie, au cours de l'étape de configuration 202, la IOMMU 50 du contrôleur DMU 42 du deuxième circuit 34 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique en association avec le canal de communication 5 négocié, c'est-à-dire en association avec le contexte mémoire (LIDDEST, KEY 1 De - DEST,- - même, la IOMMU 30 du premier circuit 12 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique en association avec le canal de communication négocié, c'est-à-dire en association avec le contexte mémoire (LIDsRc, KEYSRC). En 10 outre, la IOMMU 50 du contrôleur DMU 42 du deuxième circuit 34 peut être configurée pour réaliser une traduction de l'espace d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire, représentant l'espace d'adressage physique du premier processus logiciel vu depuis le deuxième circuit 34. Enfin, la LUT 54 du deuxième circuit 34 peut être configurée pour associer 15 cet espace d'adressage physique temporaire au contexte mémoire (LIDsRc, KEYSRC) exploitable par le premier circuit 12. Un troisième mode de réalisation de l'invention, également illustré par les figures 3A et 3B, diffère du précédent uniquement en ce que les adresses virtuelles du contrôleur DMA 20 sont codées sur 32 bits (celles du processeur principal 14 20 pouvant être codées sur 64 ou 32 bits) et les adresses physiques sur 40 bits. Dans ce cas, au cours de l'étape 204, la première adresse virtuelle IOVAsRc n'est pas codée sur 32 bits mais sur 24 bits seulement. Elle est encapsulée dans l'adresse virtuelle VASRC plus complète codée sur 32 bits qui comporte en outre une version comprimée CKEYSRC du paramètre KEYSRC, codée sur 8 bits : 31 ... 24 23 0 VASRC 25 Dans ce cas également, la deuxième adresse virtuelle IOVADEST est aussi codée sur 24 bits. Elle est encapsulée dans l'adresse virtuelle VADEST plus complète codée sur 32 bits qui comporte en outre une version comprimée CKEYDEST du paramètre KEY - DEST, codée sur 8 bits : CKEYSRC IOVAsRc VADEST 31 ... 24 23 0 CKEYDEST IOVADEST L'étape 206 est adaptée pour retrouver le paramètre KEYSRC à partir du 30 paramètre comprimé CKEYSRC, à l'aide d'une fonction cache classique, de sorte que 3032537 18 l'adresse physique PAsRD codée sur 40 bits peut être retrouvée grâce au contexte mémoire (LIDSRC, KEYsRC)- Dans ce cas également, au cours de l'étape 210, l'adresse virtuelle VADEST codée sur 32 bits est traduite par la IOMMU 28 en une adresse physique temporaire 5 TPADEST codée sur 40 bits. La traduction consiste dans ce mode de réalisation à retrouver le paramètre IKEYDEST défini précédemment à partir du paramètre comprimé CKEYDEST puis à compléter les 4 derniers bits à « 1 0 0 0 » : 39...36 35 ... 24 23 0 TPADEST 1 0 0 0 I KEYDEST IOVADEST Dans ce cas également, au cours de l'étape 212, l'adresse de transport TADEST, obtenue par traduction de l'adresse physique temporaire TPADEST à l'aide de 10 la LUT 32, est codée sur 40 bits : TADEST : 39 24 23 0 KEYDEST IOVADEST Dans ce cas également, au cours de l'étape 216, l'adresse PADEST obtenue par traduction de l'adresse de transport TADEST à l'aide de la IOMMU 52, est codée sur 40 bits. Comme le deuxième mode de réalisation, le premier mode de réalisation 15 pourrait lui aussi être adapté à des adresses virtuelles codées sur 32 bits et des adresses physiques sur 40 bits en adaptant ses étapes 100 à 118 conformément à ce qui a été fait pour le troisième mode de réalisation. D'une façon générale, on notera que le codage des adresses virtuelles sur 32 ou 64 bits est relativement standard, le codage sur 64 bits étant largement répandu dans les processeurs. En revanche, le 20 nombre de bits sur lequel peuvent être codées les adresses physiques est nettement plus libre. Il a été choisi, dans les modes de réalisation précédents, de les coder sur 40 ou 48 bits mais d'autres choix auraient pu être faits. Un quatrième mode de réalisation de l'invention, également illustré par les figures 3A et 3B, diffère du précédent uniquement en ce que les deux processus 25 logiciels concernés par la requête d'échange de données s'exécutent sur des machines virtuelles des processeurs principaux 14 et 36. Dans ce cas, l'étape 206 est adaptée pour retrouver l'adresse physique PAsRc en deux traductions successives réalisées par la IOMMU 28. Une première traduction, réalisée au niveau de la machine virtuelle qui exécute le premier 30 processus logiciel dans le premier circuit 12, permet de traduire l'adresse virtuelle VASRC sur 32 bits en une adresse physique intermédiaire IPASRC sur 40 bits. Une 3032537 19 deuxième traduction, réalisée au niveau de l'hyperviseur qui exécute cette machine virtuelle, permet de traduire l'adresse physique intermédiaire IPAsRc en l'adresse physique PASRC codée sur 40 bits. Dans ce cas également, l'étape 210 est adaptée pour retrouver l'adresse 5 physique temporaire TPADEST en deux traductions successives réalisées par la IOMMU 28. Une première traduction, réalisée au niveau de la machine virtuelle qui exécute le premier processus logiciel dans le premier circuit 12, permet de traduire l'adresse virtuelle VADEST sur 32 bits en une adresse physique temporaire intermédiaire ITPADEST sur 40 bits dans laquelle le paramètre IKEY - DEST a été traduit 10 en un paramètre virtualisé VIKEY : DEST 39...36 35 ... 24 23 0 ITPADEST 1 0 0 0 Une deuxième traduction, réalisée au niveau de l'hyperviseur qui exécute cette machine virtuelle, permet de traduire l'adresse physique temporaire intermédiaire ITPADEST en l'adresse physique temporaire TPADEsT. Dans ce cas également, l'étape 216 est adaptée pour retrouver l'adresse 15 physique PADEST en deux traductions successives réalisées par la IOMMU 52. Une première traduction, réalisée au niveau de la machine virtuelle qui exécute le deuxième processus logiciel dans le deuxième circuit 34, permet de traduire l'adresse de transport TADEST en une adresse physique intermédiaire IPADEST sur 40 bits. Une deuxième traduction, réalisée au niveau de l'hyperviseur qui exécute cette machine 20 virtuelle, permet de traduire l'adresse physique intermédiaire IPADEST en l'adresse physique PADEST codée sur 40 bits. Dans ce cas également, on notera que le gestionnaire du premier port d'accès du premier circuit 12 est l'hyperviseur du processeur principal 14. Comme le troisième mode de réalisation, les premier et deuxième modes de 25 réalisation pourraient eux aussi être adaptés à des exécutions de leurs processus logiciels sur des machines virtuelles en adaptant leurs étapes conformément à ce qui a été fait pour le quatrième mode de réalisation. Il apparaît clairement qu'un procédé d'exécution d'une requête d'échange de données tel que l'un de ceux décrits précédemment permet, par une astuce exécutée 30 aux étapes 112 et 212 décrites précédemment, des écritures ou lectures de données à distance, i.e. d'un circuit sur carte ou puce à l'autre dans un système de circuits interconnectés, sans solliciter le processeur du circuit distant et sans aucun besoin en adaptation réseau. VI KEY - DEST I OVADEST 3032537 20 En outre, il est avantageux de pouvoir tirer profit des unités de gestion mémoire dédiées aux entrées/sorties et des technologies de virtualisation pour mettre en oeuvre un procédé selon l'invention. En outre, dans les modes de réalisation décrits en référence aux figures 3A et 5 3B, il est avantageux de pouvoir utiliser le modèle de programmation RDMA et par conséquent de bénéficier des bibliothèques logicielles correspondantes et de l'interface de programmation OFEDTM (de l'anglais « OpenFabrics Enterprise Distribution ») sur des circuits à faible consommation ne comportant pas de contrôleurs conformes au protocole Infiniband ou RoCE. 10 On notera par ailleurs que l'invention n'est pas limitée aux modes de réalisation décrits précédemment. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées aux modes de réalisation décrits ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Dans les revendications qui suivent, les termes utilisés ne doivent pas être interprétés comme 15 limitant les revendications aux modes de réalisation exposés dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en oeuvre de l'enseignement qui vient de lui être divulgué. 20 REVENDICATIONS1. Procédé d'exécution d'une requête d'échange de données entre des premier et deuxième espaces d'adressage physiques disjoints (16, 38) contrôlés respectivement par des premier et deuxième circuits sur carte ou puce distincts (12, 34), comportant les étapes suivantes : création (100, 102 ; 200, 202) d'un canal de communication entre : - un premier port d'accès du premier circuit (12), obtenu par un premier processus logiciel s'exécutant dans le premier circuit qui comporte au moins un processeur (14) d'exécution de ce premier processus logiciel dans le premier espace d'adressage physique (16), et - un deuxième port d'accès du deuxième circuit (34), obtenu par un deuxième processus logiciel s'exécutant dans le deuxième circuit qui comporte au moins un processeur (36) d'exécution de ce deuxième processus logiciel dans le deuxième espace d'adressage physique (38), émission (104 ; 204), par le premier processus logiciel, de ladite requête d'échange de données, cette requête désignant une adresse virtuelle dans un espace d'adressage virtuel du deuxième processus logiciel, et exécution (106-118 ; 206-218), par des gestionnaires des premier et deuxième ports d'accès, de la requête d'échange de données entre les espaces d'adressage physiques disjoints (16, 38) des deux processus logiciels, sans sollicitation du processeur (36) exécutant le deuxième processus logiciel, caractérisé en ce que : lors de la création (100, 102 ; 200, 202) du canal de communication, une traduction (102 ; 202) de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique est créée et associée à ce canal de communication dans le deuxième circuit (34), et lors de l'exécution (106-118 ; 206-218) de la requête, des données (LIDDEST, KEYDEST) d'identification du canal de communication sont ajoutées (112 ; 212) à l'adresse virtuelle désignée dans la requête. 3032537 22 2. Procédé d'exécution d'une requête d'échange de données selon la revendication 1, dans lequel la traduction (102 ; 202) de l'espace d'adressage virtuel du deuxième processus logiciel vers son espace d'adressage physique est exploitée par une unité de gestion mémoire (52) du deuxième circuit (34) pour déterminer 5 quelle adresse physique du deuxième espace d'adressage physique (38) correspond à l'adresse virtuelle désignée dans la requête à partir des données (LI D DEST, KEYDEST ) / d'identification du canal de communication ajoutées à cette adresse virtuelle. 3. Procédé d'exécution d'une requête d'échange de données selon la revendication 1 ou 2, dans lequel les données (LIDDEsT, KEYDEST) d'identification du 10 canal de communication ajoutées à l'adresse virtuelle désignée dans la requête comportent un identifiant (LIDDEsT) du deuxième circuit (34), d'un système d'exploitation sur lequel s'exécute le deuxième processus logiciel et du deuxième port d'accès obtenu par le deuxième processus logiciel, et un identifiant (KEYDEST) d'une mémoire tampon d'échange définie du côté du deuxième circuit (34). 15 4. Procédé d'exécution d'une requête d'échange de données selon l'une quelconque des revendications 1 à 3, dans lequel les données (LIDDEsT, KEYDEST) d'identification du canal de communication sont ajoutées à l'adresse virtuelle désignée dans la requête par le gestionnaire du premier port d'accès du premier circuit (12). 20 5. Procédé d'exécution d'une requête d'échange de données selon l'une quelconque des revendications 1 à 4, dans lequel l'ajout (112 ; 212) des données (LIDDEsT, KEYDEsT) d'identification du canal de communication à l'adresse virtuelle désignée dans la requête se fait par encapsulation de cette adresse virtuelle dans une adresse de transport (TADEST), cette adresse de transport étant transmise (114 ; 25 214) puis traitée (116 ; 216) par le gestionnaire du deuxième port d'accès comme une adresse virtuelle à traduire. 6. Procédé d'exécution d'une requête d'échange de données selon l'une quelconque des revendications 1 à 5, dans lequel l'exécution (106-118) de la requête est gérée par une communication directe établie entre le processeur (14) du premier 30 circuit (12) et une mémoire locale (38) du deuxième circuit (34). 7. Procédé d'exécution d'une requête d'échange de données selon la revendication 6, dans lequel : - la traduction (106) de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique est 3032537 23 exploitée par une unité de gestion mémoire (26) du processeur (14) du premier circuit (12), et cette unité de gestion mémoire (26) exploite en outre la traduction (110) de l'espace d'adressage virtuel du deuxième processus logiciel 5 vers un espace d'adressage physique temporaire utilisé pour indexer une table de correspondance (32) dans laquelle sont conservées les données (LIDDEsT, KEY - DEST) d'identification du canal de communication. 8. Procédé d'exécution d'une requête d'échange de données selon l'une 10 quelconque des revendications 1 à 5, dans lequel l'exécution (206-218) de la requête est gérée par une communication indirecte établie entre le processeur (14) du premier circuit (12) et une mémoire locale (38) du deuxième circuit (34) avec la sollicitation d'un contrôleur (20) d'accès direct en mémoire pour des accès en écriture et en lecture, en mémoire locale ou à distance, indépendants du processeur (14) du 15 premier circuit (12). 9. Procédé d'exécution d'une requête d'échange de données selon la revendication 8, dans lequel : la traduction (206) de l'espace d'adressage virtuel du premier processus logiciel vers son espace d'adressage physique est 20 exploitée par une unité de gestion mémoire (28) associée spécifiquement au contrôleur (20) d'accès direct en mémoire, et cette unité de gestion mémoire (28) exploite en outre la traduction (210) de l'espace d'adressage virtuel du deuxième processus logiciel vers un espace d'adressage physique temporaire utilisé pour indexer 25 une table de correspondance (32) dans laquelle sont conservées les données (LIDDEsT, KEY - DEST) d'identification du canal de communication. 10. Procédé d'exécution d'une requête d'échange de données selon l'une quelconque des revendications 1 à 9, dans lequel la requête d'échange de données 30 émise par le premier processus logiciel concerne : - une lecture de données stockées dans le premier espace d'adressage physique (16) dans lequel s'exécute le premier processus logiciel et une écriture de ces données dans le deuxième espace d'adressage physique (38) dans lequel s'exécute le deuxième 35 processus logiciel, ou 3032537 24 une lecture de données stockées dans le deuxième espace d'adressage physique (38) dans lequel s'exécute le deuxième processus logiciel et une écriture de ces données dans le premier espace d'adressage physique (16) dans lequel s'exécute le premier 5 processus logiciel. 11. Procédé d'exécution d'une requête d'échange de données selon l'une quelconque des revendications 1 à 10, dans lequel au moins l'un des premier et deuxième processus logiciels s'exécute sur une machine virtuelle exécutée elle-même par un hyperviseur du processeur (14, 36) correspondant, chaque traduction 10 d'adresse virtuelle en adresse physique locale correspondante comportant une traduction d'adresse virtuelle en adresse physique intermédiaire vue par la machine virtuelle et une traduction d'adresse physique intermédiaire en adresse physique vue par l'hyperviseur.