IBM Z apprend l'Arm.Une CPU doit-elle parler toutes les langues ?
Chaque cœur du futur processeur de mainframe exécutera Arm et z/Architecture. C'est une prouesse d'ingénierie, et elle résout un des quatre problèmes à régler pour qu'un binaire venu d'ailleurs arrive en production.
Une application mal écrite qui tourne sur un excellent serveur reste une application mal écrite avec une alimentation électrique très fiable.
Si l'on en parle, c'est qu'IBM vient d'annoncer l'un des processeurs d'entreprise les plus singuliers de ces dernières années. Selon l'annonce du 24 août, un futur processeur pour IBM Z et LinuxONE est conçu pour que chaque cœur physique exécute nativement et simultanément des flux d'instructions Arm et IBM Z.
En clair : une architecture de jeu d'instructions, ou ISA, est la langue et le règlement par lesquels le logiciel donne ses ordres au processeur. Arm et la z/Architecture d'IBM sont deux langues différentes. IBM veut que chaque cœur comprenne les deux directement.
Ce n'est pas la même chose que de poser un petit processeur Arm à côté des cœurs du mainframe. Ce n'est pas non plus de l'émulation logicielle en costume du dimanche. IBM présente les deux ISA comme des modes d'exécution de premier rang du même cœur.
Et pourtant, la question importante n'est pas de savoir si cela peut fonctionner. Le palmarès d'ingénierie d'IBM en fait la partie la moins surprenante de l'histoire. La question révélatrice est ailleurs :
Si ajouter une ISA règle la compatibilité, pourquoi s'arrêter à deux ? Pourquoi pas x86, RISC-V, Power ISA… ou toutes les langues que le logiciel parle encore ?
Tirez sur ce fil assez longtemps et l'annonce cesse d'être une actualité de processeurs. Elle devient une leçon sur ce que le matériel peut résoudre, sur ce qui reste à la charge de l'écosystème, et sur la raison pour laquelle une application peut rester indisponible alors que le kernel, le compilateur et le code source l'attendent depuis des années.
Rien de ce qui suit ne provient d'une clé USB oubliée sur un parking ni d'un forum du dark web au logo mal détouré. Tout sort de listes de diffusion publiques, de communiqués de presse et d'actes de conférence : un matériau nettement plus ennuyeux et nettement plus citable. Chaque affirmation renvoie à sa source, et les éléments antérieurs à l'annonce sont des messages signés en toutes lettres, datés, avec un fil de relecture ouvert.
La version 90 secondes
Pas besoin de concevoir des processeurs pour suivre cette histoire. Six termes portent presque tout.
Le vocabulaire d'instructions et le comportement promis au logiciel
Arm et z/Architecture sont des ISA distinctes
Un programme déjà compilé pour une ISA et un environnement donnés
Un binaire Arm ne se transforme pas tout seul en binaire x86, Power ou Z
Le processeur implémente l'ISA qu'il expose au logiciel
Évite la traduction instruction par instruction, sans garantir pour autant le support du système d'exploitation ni celui de l'application
Un ordinateur simulé et isolé que l'hyperviseur présente au logiciel
IBM prévoit que les environnements Linux Arm cohabitent avec les charges Z établies via la virtualisation
Un processeur virtuel que l'hôte planifie pour une VM
Une VM Arm peut avoir plusieurs vCPU et n'est pas soudée en permanence à un thread matériel
KVM est le cadre de virtualisation de Linux ; SAE signifie Start Arm Execution
KVM gère l'invité Arm ; SAE est la porte matérielle vers l'exécution Arm
La conclusion courte est simple. IBM règle le problème des instructions dans le silicium, et une bonne partie du chemin de virtualisation dans Linux. À la plateforme finie, il manque encore le firmware, les périphériques virtuels, les règles de migration, les frontières de sécurité, les benchmarks, le support des distributions et des applications que quelqu'un accepte de publier et de maintenir.
Cet écart entre peut s'exécuter et peut tourner en production est le sujet du reste de l'article.
Itinéraire rapide : la section historique apporte des preuves, pas des prérequis. Les pressés peuvent sauter de « Ce qu'IBM réussit » à « Pourquoi mettre Arm dans le matériel maintenant ? », puis filer vers les questions ouvertes et la piste publique du kernel.
Vous arrivez sans contexte ?
Cet article entre directement dans l'annonce. Si le terrain vous semble lointain — ce qu'est une ISA, pourquoi il est si difficile de faire tourner un programme sur une autre architecture, ce qui a déjà été tenté —, nous avons préparé un cahier de douze pages qui reprend tout depuis zéro, avec dix cas historiques et les sources de chacun. Nul besoin de l'article pour le suivre : en une demi-heure, vous êtes à jour.
Télécharger « Exécuter le code des autres » PDF · 12 pagesCe qu'IBM réussit, et il faut le dire
Très peu d'entreprises savent combiner un processeur qui, selon la presse spécialisée, dépasse les 5,7 GHz avec des caches énormes, de la mémoire et des E/S à grande échelle, la détection de fautes en ligne, la gestion sécurisée des clés, la cryptographie et l'accélération d'IA. Puis loger le tout dans une machine dont on attend qu'elle reste disponible sous des charges qui pousseraient un serveur ordinaire à reconsidérer sa carrière.
Et alors, quelques couches au-dessus de toute cette ingénierie, un déploiement échoue parce qu'un script d'installation dit, en substance :
if architecture == amd64 or architecture == arm64:
continue
else:
exit("architecture non prise en charge")Des années de travail sur le processeur, le firmware et le système d'exploitation viennent d'être vaincues par un tableau de deux éléments.
Il y a quelque chose de magnifiquement IBM dans le fait de répondre à « il nous faut plus de binaires » en redessinant le processeur du mainframe. Mais ce contraste comique dit aussi la limite de l'approche. Le matériel peut rendre un binaire exécutable. Il ne peut pas obtenir qu'un éditeur le compile, le teste, le signe, le documente ou le supporte.
Ce qu'IBM a réellement annoncé
Le communiqué d'IBM décrit un processeur de 11 cœurs gravé en 2 nm, chaque cœur étant prévu pour exécuter des instructions Arm et IBM Z. IBM s'attend à voir Linux natif Arm cohabiter avec z/OS et Linux on IBM Z. L'accélération d'inférence d'IA et une unité de traitement de données — DPU — intégrée à la puce font partie du design. IBM et Arm présentent l'accès à l'écosystème logiciel d'Arm comme l'objectif central, et non comme un effet de bord.
La couverture de la présentation d'IBM à Hot Chips ajoute du détail préliminaire. La cible Arm qui y est décrite est AArch64 v9.3 little-endian, avec les extensions vectorielles SVE et SVE2 et la prise en charge de 2 792 instructions Arm. Les transparents décrivent du SMT-2 — deux threads matériels par cœur physique — disponible pour les deux architectures, avec des bascules de mode à l'échelle de la nanoseconde. Ils montrent aussi une réutilisation substantielle du moteur d'exécution de Z, à côté d'un décodage, d'un état de registres, d'un parcours de tables de pages et d'unités vectorielles propres à Arm.
Les galeries de transparents de la même session ajoutent la hiérarchie de cache : 36 Mo de L2 privée par cœur, une L3 virtuelle de 432 Mo et jusqu'à 3,5 Go de L4 virtuelle — ces ensembles virtuels puisent dans plus de cache que les onze cœurs n'en totalisent à eux tous. Les facilités d'IA, de compression, de cryptographie, de tri et la DPU y figurent comme accessibles à l'environnement Arm.
L'ambition est une plateforme, pas un mode de compatibilité occasionnel. Mais ce sont des éléments de conférence, pas une spécification de produit : IBM a annoncé une direction de design et prévient que ses plans peuvent changer ou être retirés. Ce que l'annonce établit, c'est ce qu'IBM compte construire : ni les interfaces de l'invité, ni la politique de sécurité, ni le contrat de migration, ni les performances, ni les systèmes d'exploitation supportés, ni le catalogue d'ISV. « Un accélérateur est disponible pour Arm » ne sert à quelque chose que lorsqu'existent un driver, une bibliothèque, un modèle d'erreurs et une déclaration de support qui le rendent réel.
ans sans qu'aucune couche de compatibilité obtienne d'un éditeur qu'il signe un contrat de support.
Constante 6 sur 6Les cinq significations de « exécute Arm »
IBM décrit l'exécution Arm comme native, et le mot fait un travail utile : il signifie que le processeur implémente l'architecture Arm au lieu de demander à un émulateur de traduire chaque instruction Arm en instructions Z.
Il ne signifie pas que tout programme Arm fonctionnera sans y toucher. Il ne promet ni les performances d'un processeur Arm serveur dédié, ni le support de toutes les extensions optionnelles d'Arm, ni l'accès automatique à toutes les facilités de Z. Et il ne génère certainement aucune certification de Red Hat, Canonical, SUSE ni des ISV commerciaux.
Les CPU modernes convertissent déjà les instructions architecturales visibles en opérations internes plus petites. « Natif » décrit le contrat exposé au logiciel, pas l'absence de machinerie derrière le rideau. Le design d'IBM semble étendre ce principe à deux architectures publiques : prédiction, arithmétique et unités de chargement/rangement partagées là où c'est possible ; état architectural séparé là où les contrats divergent.
Cela compte parce qu'exécuter du logiciel venu d'ailleurs n'est pas un problème : c'en est cinq. Et le langage marketing tend à les compresser en un seul mot. La façon la plus claire de les distinguer est de se demander à quelle couche de la pile chacun agit.
L'exécution native multi-ISA est le cœur de ce qu'IBM a annoncé. La traduction en espace utilisateur, c'est Rosetta 2, Prism, FX!32 et PowerVM Lx86. L'émulation de système complet, c'est QEMU. La compatibilité d'ABI, c'est le Linuxulator de FreeBSD. L'empaquetage multi-architecture, c'est un index d'images OCI ou un binaire universel d'Apple. Ce ne sont pas des variations d'une même idée : chacun s'arrête à une couche différente, et cette frontière décide quelles applications fonctionnent, à quelle vitesse, et qui reçoit le ticket de support quand elles tombent.
FreeBSD l'explique mieux que personne
FreeBSD exécute beaucoup de binaires Linux non modifiés grâce à une couche de compatibilité optionnelle appelée Linuxulator. Le manuel de FreeBSD documente le support de x86 et d'AArch64, et la page de manuel linux(4) décrit une véritable implémentation de l'ABI de Linux, pas un émulateur de CPU.
Le processeur hôte doit toujours comprendre l'ISA du binaire. Sur une machine x86, le matériel x86 exécute les instructions et FreeBSD sert les appels système à la façon de Linux. Sur une machine Arm, il fait de même avec des binaires Linux Arm. Le Linuxulator ne traduit pas du x86 vers de l'Arm en cachette.
D'où la première règle de cette histoire :
Comprendre les instructions n'est pas comprendre le système d'exploitation.
Quatre contrats, pas un
Pour qu'une application venue d'ailleurs devienne une charge de production crédible, quatre accords distincts doivent s'emboîter. Toute la confusion de ce domaine consiste à croire que résoudre le premier résout les quatre.
Le processeur d'IBM s'attaque au premier contrat. La série KVM arm-on-s390, dans sa v6, esquisse une bonne partie du chemin côté kernel vers une VM Arm. Linux, le firmware et le moniteur de machine virtuelle doivent encore compléter la plateforme. Les distributions et les ISV doivent encore compléter la livraison et le support.
Une plateforme peut briller sur le premier contrat et décevoir commercialement sur le quatrième. Le problème d'écosystème commence là où s'arrête le manuel du processeur.
Nous avons déjà essayé d'échapper à l'architecture
Le design d'IBM est inhabituel, mais le rêve qu'il poursuit est vieux : préserver l'investissement logiciel pendant que la machine change en dessous.
Trente ans de tentatives ont laissé une constante, et ce n'est pas celle que la plupart des gens attendent.
Un processeur peut parler deux langues et n'avoir aucun public
Dans les années quatre-vingt-dix, IBM aurait développé un prototype connu sous le nom de PowerPC 615, capable d'exécuter du x86 en plus du PowerPC 32 et 64 bits. C'est, presque exactement, l'idée qu'IBM vient d'annoncer pour Z et Arm, trente ans plus tôt. Le récit le plus détaillé qui subsiste est un reportage de The Register de 1998, fondé sur un ingénieur anonyme d'IBM ; un encadré de BYTE de 1995 a lui aussi évoqué l'engin, jamais commercialisé, sur sources anonymes.
Le récit ultérieur affirmait que Minix et une version de développement d'OS/2 avaient démontré l'exécution mixte, mais que le projet n'avait pas de chemin rentable et n'a pas obtenu le support de Windows dont il avait besoin. C'est le témoignage de quelqu'un de l'intérieur, pas de l'histoire d'entreprise établie. Ce qui est documenté, c'est que Microsoft a arrêté le développement de Windows NT pour PowerPC en 1997, en invoquant une demande en berne.
La leçon ne dépend pas des détails contestés. Le silicium fonctionnait ; le quatrième contrat n'a jamais été signé. Un décodeur ne peut pas négocier un accord d'écosystème.
La traduction marche mieux quand elle sait où finit le pont
DIGITAL a buté sur le même problème de catalogue avec Alpha, et y a répondu avec l'ingénierie la plus élégante de toute cette histoire. FX!32 ne traduisait pas le code x86 d'une seule passe. Au premier lancement d'une application, il l'émulait tout en enregistrant un profil des chemins que le programme empruntait. Puis, en arrière-plan, il ne traduisait en code Alpha natif que les routes chaudes et mettait le résultat en cache. Chaque démarrage était plus rapide que le précédent.
DEC a publié que les applications traduites sur un Alpha à 500 MHz rendaient des performances comparables aux natives sur un Pentium Pro à 200 MHz. Pour 1997, c'était extraordinaire. Le code kernel et les drivers restaient hors du modèle, et les résultats dépendaient de la charge.
Alpha est mort quand même.
IBM a suivi ensuite un chemin voisin avec PowerVM Lx86, traduisant des applications Linux x86 32 bits sur Power et mettant en cache le code traduit. Il résolvait le problème que décrit la Partie III de cette série : le catalogue logiciel que personne ne compile pour Power. Cela fonctionnait pour les utilitaires, les installeurs et les applications modestes, et cela cassait sur l'accès direct au matériel, les modules kernel et le code à SIMD intensif. Le conseil que donnait IBM à l'époque reste le bon : la traduction pour la longue traîne, la recompilation native pour ce qu'exige la plateforme. Lx86 a fini retiré.
La technologie derrière Lx86 était QuickTransit, d'une entreprise britannique nommée Transitive : la même qu'Apple a licenciée pour le premier Rosetta, celui qui traduisait les applications PowerPC vers les Mac Intel. Le même logiciel, tournant dans des directions opposées, pour les deux entreprises de cette histoire. IBM a racheté Transitive en 2008.
Rosetta 2 d'Apple est le meilleur traducteur binaire jamais publié : si bon que la plupart des utilisateurs n'ont jamais su qu'il tournait. Pourquoi Apple a-t-elle réussi là où tout le monde a échoué ? Parce qu'Apple contrôle la puce, le système d'exploitation, le format d'application, les outils, la boutique et le calendrier. Elle a pu dire « dans deux ans c'est terminé, portez votre logiciel », et tout le monde a porté. Malgré cela, Rosetta reste disponible dans macOS 27 et se réduit dans macOS 28 à certains vieux jeux. Le meilleur traducteur de l'histoire a été conçu avec une date de péremption.
Prism de Microsoft est techniquement solide et il lui manque la seule chose qui a fait marcher Rosetta : Microsoft ne peut pas imposer de date limite à trente ans d'applications Windows tierces. Et la frontière de toujours reste exactement où elle était : les drivers kernel doivent être Arm64 natifs.
Le processeur universel existe déjà, et c'est du logiciel
Le projet DAISY d'IBM Research a posé la question la plus radicale du domaine : et si le processeur était réellement un moteur VLIW interne, vers lequel toutes les ISA — ESA/390, RS/6000, AS/400, Java — seraient traduites dynamiquement ? Transmeta a fini par commercialiser une version de cette idée. Crusoe exposait un x86 parfaitement normal pendant que le Code Morphing Software le traduisait pour un cœur VLIW caché, et il a échoué deux fois : les performances étaient irrégulières parce qu'elles dépendaient de ce qui était déjà traduit, et Intel a simplement baissé la consommation de ses propres puces.
L'IA-32 Execution Layer d'Intel est le cas qui va en sens inverse, et presque personne ne le cite. Itanium embarquait la compatibilité x86 en matériel, et elle a déçu. Intel l'a remplacée par une couche de traduction logicielle qui s'est révélée plus rapide que le silicium dédié, puis a retiré le matériel x86 du processeur. Mettre la compatibilité dans le silicium ne l'améliore pas automatiquement. Cela la rend plus difficile à corriger.
QEMU n'a jamais promis la vitesse. Il a promis l'universalité : des machines complètes ou des processus utilisateur d'une autre architecture, état privilégié et périphériques compris, traduits par blocs avec le Tiny Code Generator. Publié pour la première fois en 2003, il est toujours là, après la fermeture de tous les produits commerciaux de cette liste.
Six constantes en trente ans
Six choses se répètent dans tous les cas précédents.
- La traduction meurt quand meurt l'incitation, pas quand la technique échoue. FX!32 était excellent et Alpha est mort. Rosetta 2 est excellent et Apple a déjà annoncé sa fin. Lx86 fonctionnait et IBM l'a retiré. Dans aucun de ces cas la cause du décès n'a été « nous n'avons pas réussi à le faire marcher ».
- Celui qui contrôle le calendrier gagne. Apple a pu dire à un écosystème entier qu'il lui restait deux ans. Ce pouvoir, et non la qualité du traducteur, est ce qui sépare Rosetta de toutes les autres tentatives de cette liste. Microsoft ne peut pas le dire à trente ans de logiciel Windows. IBM ne peut pas non plus le dire à ses ISV.
- Un pont n'est pas un domicile. Tous les cas qui ont marché étaient des transitions à échéance annoncée ; ceux qui ont voulu être permanents — Transmeta, Lx86 — n'ont pas survécu.
- Le kernel est toujours la frontière. FX!32, Lx86, Prism : tous trois s'arrêtent aux drivers et au code kernel. Trente ans, aucune exception.
- Le matériel achète de la prédictibilité et le logiciel achète de la flexibilité, et l'arbitrage n'est pas évident d'avance. Itanium a mis le x86 dans le silicium et une couche logicielle l'a battu.
- La livraison et le support, aucun d'entre eux ne les a résolus, pas une seule fois. En trente ans, aucune couche de compatibilité n'a convaincu un éditeur de logiciel de signer un contrat de support. C'est ce contrat qui décide si une plateforme est utilisable, et c'est le seul de la liste que le matériel ne peut pas toucher.
Le verdict n'est ni « la traduction a échoué » ni « le matériel a gagné » :
Utilisez l'exécution native là où la performance, le privilège et les horizons longs de support le justifient. Utilisez la traduction comme un pont. Ne confondez aucun des deux mécanismes avec un engagement d'écosystème.
pour cent de chute des revenus d'IBM Z, deux trimestres après une hausse de 67 %.
La même activité, à deux trimestres d'écartPourquoi mettre Arm dans le matériel maintenant ?
La traduction dynamique apporte un temps de chauffe, des caches de code et un pire cas difficile à borner. Inoffensif pour un utilitaire de bureau ; nettement plus difficile à défendre pour des charges d'entreprise consolidées, avec des accords de niveau de service signés. Un environnement Linux Arm complet a besoin en outre de l'architecture privilégiée — niveaux d'exception, tables de pages, interruptions, temporisateurs, atomiques, comportement du TLB, état de virtualisation — et l'implémentation native rend ce contrat de machine complète plus crédible qu'une couche en espace utilisateur. Reste la longévité : Rosetta a été conçu pour disparaître, alors qu'une architecture de charges d'entreprise peut exiger une décennie de support, ou davantage.
Sous tout cela, IBM veut que les charges Arm cohabitent avec les environnements Z établis sous le même modèle de gestion, de fiabilité et de sécurité. Elle cite un écosystème Arm de plus de 22 millions de développeurs : un chiffre qui couvre beaucoup de marchés et ne signifie certainement pas 22 millions de futurs développeurs mainframe, mais qui montre l'échelle de l'investissement logiciel dont IBM veut se rapprocher.
Arm en matériel résout donc un problème gros et coûteux de façon prévisible. Ce qu'il ne fait toujours pas : démarrer un système d'exploitation, publier un conteneur, exposer un accélérateur, interpréter une licence ou convaincre un éditeur d'accepter un incident en production.
Le programme SystemReady d'Arm elle-même existe précisément parce que respecter l'ISA ne suffit pas. Le programme actuel comprend une SystemReady Band pour les systèmes fondés sur ACPI et une SystemReady Devicetree Band pour ceux décrits par arbre de périphériques. Arm maintient en outre les autodéclarations SystemReady VE pour les environnements virtuels.
La couverture de Hot Chips indique qu'IBM a revendiqué la conformité SystemReady. La question utile n'est pas un vague « est-ce conforme ? ». C'est demander à IBM la bande applicable, la version des exigences, la déclaration VE et le résultat du test. Et même alors, Arm prévient que la conformité de plateforme n'implique pas qu'un éditeur de système d'exploitation supporte l'appareil.
Pourquoi Arm et pas toutes les ISA ?
Imaginez un processeur qui implémente x86-64, AArch64, Power ISA, z/Architecture, RISC-V, SPARC, MIPS, Alpha et 68000. Plus une autre architecture parce que quelqu'un a retrouvé un vieil appliance ERP derrière une armoire.
Cela sonne inclusif. Ce serait aussi un musée permanent en silicium.
Chaque ISA apporte bien plus qu'un décodeur. Elle apporte des registres, des exceptions, un comportement de privilège, des règles d'ordonnancement mémoire, des atomiques, des vecteurs, un état de débogage, des compteurs de performance et des interfaces de firmware. Chacune devient une obligation de plus en validation, sécurité, licences et support à long terme. Et les vieilles architectures ne se tiennent même pas tranquilles : x86 traîne des décennies d'extensions, AArch64 a des profils et des fonctions optionnelles en évolution, et RISC-V est extensible par conception.
Un processeur qui implémenterait tout deviendrait QEMU en matériel : du silicium neuf tous les deux ou trois ans, impossible à corriger par une mise à jour de paquet.
C'est la réponse d'ingénierie, et ce n'est que la moitié.
L'autre moitié est un bilan comptable
L'argument technique explique pourquoi une deuxième ISA est soutenable. Il n'explique ni pourquoi maintenant, ni pourquoi celle-ci. Pour cela, il faut regarder où IBM gagne de l'argent.
IBM a clôturé 2025 avec 67,5 Md$ de chiffre d'affaires. L'Infrastructure — le segment qui contient le matériel mainframe — en a apporté 15,718 Md$, environ 23 %. Cela sous-estime nettement le poids de la plateforme, parce que le logiciel qui n'existe que parce que les mainframes existent n'y est pas comptabilisé. CICS, IMS, Db2 for z/OS et MQ se facturent dans le segment Software, sous Transaction Processing. IBM déclare une marge brute de 83,5 % pour le Software dans son ensemble et ne la ventile pas par catégorie : l'appliquer à Transaction Processing est donc une approximation, pas une mesure. Même avec cette marge d'erreur, la proportion tient : le logiciel mainframe semble générer à lui seul environ les trois quarts de la marge brute de tout le segment Infrastructure, avec à peu près moitié moins de chiffre d'affaires. Ajoutez IBM Financing, qui finance les machines elles-mêmes, et la part du conseil qui vit de les moderniser, et le poids du mainframe dans le bénéfice court très loin devant son poids dans la facturation.
Cette activité est de surcroît brutalement cyclique, parce que les mainframes se vendent par générations. Les revenus d'IBM Z ont crû de 51,7 % en 2025, portés par le z17 lancé en juin, et de 67 % sur le seul quatrième trimestre. Deux trimestres plus tard, ils chutaient de 42 %. Le directeur financier d'IBM a attribué la baisse au calendrier d'achat, pas à un abandon, et il a fourni le chiffre qui l'étaye : les cinq premiers trimestres du cycle z17 courent environ 30 % devant le z16, lui-même le programme le plus fort de l'histoire de l'entreprise. Ce sont deux règles de mesure différentes — la variation annuelle mesure le trimestre, la comparaison programme à programme mesure le cycle — et IBM a raison de dire que la seconde est l'honnête pour un métier qui vend par génération.
Pendant ce temps, la base installée est saine et croît vers l'intérieur — plus de capacité chez les clients déjà là, pas de nouveaux clients. 85 % des clients du z16 ont maintenu ou étendu leur capacité ; environ 70 % des clients mainframe croissent en MIPS. Ce qu'aucun de ces chiffres ne décrit, c'est l'arrivée de nouveaux types de charges. Et c'est là que le binaire manquant cesse d'être une contrariété d'ingénierie pour devenir une fuite : une équipe a besoin d'un agent d'observabilité, découvre qu'il n'existe pas de build s390x, et déploie cette pièce ailleurs. Puis la suivante. En cinq ans, la moitié de l'application vit dehors.
Lu ainsi, Arm sur le mainframe n'est pas un mouvement offensif pour gagner de nouveaux clients. C'est de la défense : une tentative d'éliminer la raison pour laquelle ces pièces s'en vont, en allant chercher les binaires là où ils sont déjà plutôt qu'en convainquant des milliers d'éditeurs de compiler pour s390x.
Ce qui éclaire aussi le choix d'architecture, et il faut être précis, parce que la candidate évidente n'est pas celle que les gens nomment.
La candidate maison
La deuxième architecture techniquement la plus facile pour IBM n'est pas Arm. C'est Power. IBM possède les deux ISA, ne paie de licence à personne pour aucune des deux, et partage une bonne partie de l'équipe de design et de la bibliothèque physique entre elles.
IBM n'a pas expliqué pourquoi elle ne l'a pas fait, et les raisons — ce qu'elles disent du métier mainframe et de l'écosystème Power — méritent un épisode entier. Ce sera la Partie III de cette série. Ici, il suffit de consigner le fait : ayant chez elle l'architecture la plus facile, IBM a choisi celle du dehors.
Pourquoi pas x86 ?
IBM n'a pas dit avoir évalué x86 et l'avoir écarté, donc n'inventons pas cette décision.
Les faits publics expliquent tout de même pourquoi x86 est une proposition différente. Ses droits d'implémentation ont historiquement dépendu de licences d'entreprise précises, de licences croisées de brevets et de relations commerciales. Le formulaire 10-K d'AMD de 2026, par exemple, incorpore par référence la licence croisée AMD–Intel. C'est la preuve d'une relation juridique bilatérale, pas d'un modèle ouvert de licence d'architecture accessible à tout implémenteur.
Un environnement x86-64 moderne et utile hériterait de surcroît d'un contrat de compatibilité énorme. IBM pourrait en implémenter un sous-ensemble, mais le logiciel qui vaudrait la peine d'être importé pourrait être précisément celui qui vérifie ce qui manque.
Les applications x86 pourraient encore arriver de façon sélective via QEMU ou un autre traducteur dans une VM Linux Arm. Windows on Arm fait déjà quelque chose d'approchant avec Prism, même si Microsoft n'a annoncé aucun produit Windows on Arm pour IBM Z. Cela pourrait dépanner pour un utilitaire. Ce ne serait pas du support natif de x86.
Pourquoi pas RISC-V ?
RISC-V est la question la plus intéressante côté architecture ouverte. RVA23 définit une base applicative plus solide, et RISC-V International a ratifié une spécification de plateforme serveur couvrant firmware, UEFI, ACPI, interruptions, gestion et sécurité. Ce qui redémontre la même chose : même une ISA ouverte a besoin d'un contrat de plateforme avant que le logiciel serveur ordinaire puisse lui faire confiance.
RISC-V peut finir par devenir une cible d'entreprise très attractive. Mais l'objectif déclaré d'IBM est d'accéder à un catalogue qui existe déjà, et en 2026 ce catalogue est celui d'Arm. Ouverture et ampleur sont deux avantages distincts, et un seul des deux livre des binaires cette décennie.
Ce qu'IBM doit encore expliquer
L'annonce mérite de l'enthousiasme. Elle mérite aussi des questions dirigées vers ce qui reste véritablement inconnu, et non vers ce que le registre public a déjà répondu.
IBM dit que Z et Arm s'exécutent simultanément ; la presse dit qu'un thread peut utiliser l'une ou l'autre des deux ISA
Les threads jumeaux d'un même cœur peuvent-ils exécuter des ISA différentes sous toute politique supportée, et comment sont-ils placés, isolés et facturés ?
La série publique v6 kvm-arm64 propose la création de VM/vCPU, la gestion mémoire et l'entrée par SAE
Qu'est-ce qui complète le firmware, les périphériques virtuels, la migration, QEMU/libvirt et l'orchestration ?
La presse décrit AArch64 v9.3, SVE/SVE2 et la découverte de fonctionnalités
Quel profil visible par l'invité reste stable entre machines et entre générations ?
Prédiction, arithmétique, chargement/rangement, caches et structures de TLB sont substantiellement réutilisés
Comment isole-t-on les domaines de sécurité et sert-on de façon prévisible des charges mélangées ?
Rien de public
Comment les invités Arm se placent-ils à côté du partitionnement PR/SM et du parc z/VM que le client possède déjà ?
Rien de public au-delà de la série du kernel
Qui écrit et maintient le modèle de périphériques de l'invité Arm, et pendant combien de temps ?
L'objectif déclaré est Linux natif Arm
Quelles distributions, versions, images, quels ISV et accélérateurs sont supportés ?
Les trois dernières sont celles qui, si l'on en croit l'histoire, décideront du résultat. La constante 4 est la raison pour laquelle la question des drivers importe ; la constante 6 est la raison pour laquelle la matrice de support importe plus que n'importe quel benchmark.
Le chemin KVM explique le mécanisme au niveau du thread
La question tentante — « des threads SMT différents peuvent-ils exécuter des ISA différentes ? » — est déjà répondue dans son principe. Un moniteur de machine virtuelle en espace utilisateur crée une VM et ses vCPU via l'API de KVM ; KVM garde l'état Arm de chaque vCPU ; Linux planifie le thread hôte qui conduit cette vCPU sur une CPU logique ; et SAE entre alors dans le contexte de l'invité Arm. KVM ne soude pas une VM à un thread SMT : il fournit des contextes de vCPU que Linux planifie indépendamment.
Ce que la série ne règle pas, c'est la politique. IBM autorisera-t-elle toujours des ISA différentes sur des threads jumeaux du même cœur, ou recommandera-t-elle d'apparier la même ISA pour certains profils de sécurité ou de performance ? Comment fonctionneront l'affinité, les droits d'usage, la mesure et le reporting de capacité entre LPAR ? Que deviennent les niveaux de service quand deux charges différentes partagent un cœur ?
SAE n'est pas une idée neuve. C'est la plus vieille du mainframe
Pour qui connaît la z/Architecture, la forme de SAE aura un air familier. Cela vaut la peine de s'arrêter sur le pourquoi.
Depuis le milieu des années quatre-vingt, le mainframe entre dans l'exécution d'invités par une instruction : SIE, Start Interpretive Execution. L'hôte construit un bloc de contrôle appelé state description, exécute SIE en le pointant, et le processeur exécute directement les instructions et interruptions de l'invité jusqu'à ce que surgisse quelque chose qui requiert l'hôte. Alors il sort, et le contrôle revient. SIE a été créée pour virtualiser System/370 et 370-XA, s'est étendue à travers ESA/390 et reste sous PR/SM et z/VM. IBM a publié l'architecture sous le titre Interpretive Execution (SA22-7095) et l'a décrite dans l'IBM Systems Journal.
SAE suit exactement cette forme. Elle reçoit l'adresse d'un bloc de contrôle, entre en exécution Arm accélérée et rend le contrôle à l'hôte s390 à la sortie, pour que KVM et le moniteur de machine virtuelle gèrent l'événement.
IBM n'a pas décrit SAE comme une descendante de SIE, et la série publique ne le présente pas ainsi. Mais la ressemblance n'est pas décorative. Elle suggère qu'IBM n'invente pas une nouvelle porte vers l'exécution d'invités : elle étend à une deuxième architecture le mécanisme de virtualisation le plus éprouvé qu'elle possède. Pour une plateforme dont toute la proposition de valeur consiste à ne surprendre personne, c'est un meilleur signal qu'un design inédit.
La machinerie partagée est l'efficacité, et la frontière de vérification
Le matériel de Hot Chips indique une réutilisation substantielle de la prédiction, du cache, du TLB et des unités d'exécution, sans spécification finale publique. Les questions qui suivent sont concrètes : comment l'état des prédicteurs, du cache, du TLB et des prefetchers est-il étiqueté, vidé ou partitionné quand l'ISA ou le domaine de sécurité change ; comment compteurs, traces et débogage sont-ils arbitrés ; et si placer des ISA différentes sur des threads jumeaux change le modèle de menace par canal auxiliaire. L'essentiel de l'efficacité du design vient de ce partage, et c'est précisément pourquoi il exige une réponse explicite.
Même chose pour les accélérateurs. IBM dit que les charges Arm peuvent atteindre les facilités d'IA, de compression, de cryptographie, de tri et la DPU ; ce qui compte, c'est lesquelles sont publiées, par quelle interface visible de l'invité, avec quels drivers et quelles garanties de reprise. Et le benchmark qui compte n'est pas de savoir si l'Arm d'IBM bat Graviton sur un test générique : c'est de savoir si une performance Arm acceptable crée une valeur de système qu'un serveur Arm séparé ne peut pas donner.
Et ensuite, une matrice de support. L'exécution de binaires est une propriété technique ; le support en production est un accord commercial.
La piste publique a commencé avant l'annonce
Les communiqués de presse décrivent des intentions. L'infrastructure de développement finit par décrire la machine.
OSINT — le renseignement de sources ouvertes — consiste à tirer des conclusions prudentes de preuves publiques. Ici, la preuve la plus utile n'est pas apparue sous le nom du produit. La première série publique KVM arm-on-s390 est arrivée le 2 avril, le jour même de l'annonce de collaboration entre IBM et Arm. Elle a été publiée par Steffen Eiden, d'IBM, sous un objet qu'aucun service marketing n'aurait choisi — « KVM: s390: Introduce arm64 KVM » — et le 12 août elle atteignait la v6 avec 33 patchs. Phoronix a couvert la première révision en avril, puis la deuxième le même mois ; LWN a également repris la série. Voilà la corroboration indépendante qu'une affirmation pareille exige.
Cette chronologie démontre qu'un effort de développement public a existé, avec des noms en toutes lettres. Elle ne démontre pas que les patchs ont été intégrés, qu'ils sont prêts pour la production ni qu'ils sont identiques au produit final. Une série de patchs est une proposition en relecture, pas une garantie.
Ce que révèlent les 33 patchs
La lettre de présentation de la v6 décrit deux implémentations de KVM cohabitant sur s390 et introduit un second module nommé kvm-arm64. La série couvre la création et la destruction de VM et de vCPU Arm, les ioctl de vCPU, la gestion mémoire de l'invité, le traitement des fautes de page, la réutilisation sélective du code Arm de KVM existant, la découverte de fonctionnalités Arm et la gestion de l'état des registres entre hôte et invité. Elle déplace aussi les en-têtes arm64 vers des chemins indépendants de l'architecture et crée du code partagé sous virt/kvm/arm64/ : le genre de refactorisation qui n'a de sens que si un second consommateur arrive.
Au centre se trouve l'instruction SAE, décrite plus haut.
C'est la plomberie nécessaire pour créer, exécuter et arrêter une VM Arm. Les patchs exposent aussi du travail inachevé : une partie de la gestion des registres et des fonctions associées est reportée à des séries ultérieures.
Une recherche publique ciblée, le 27 août, n'a trouvé aucune série arm-on-s390 clairement attribuable à IBM pour QEMU, libvirt ou EDK II. Ce résultat négatif doit rester étroit : il dit que le backend public du kernel est visible tandis que la pile publique complète d'espace utilisateur et de firmware ne l'est pas encore. Il ne démontre pas que ces couches n'existent pas en privé.
La leçon d'OSINT est réutilisable
Chercher seulement « processeur dual-ISA d'IBM » avant le 24 août aurait probablement échoué. Les termes productifs étaient arm-on-s390, KVM_ARM64, kvm-arm64, Start Arm Execution et SAE.
Les ingénieurs baptisent un mécanisme bien avant que le marketing baptise un produit. Cherchez dans les patchs des interfaces, des symboles de configuration, des instructions, des structures de contrôle, des identifiants de périphérique et des types de machine. Vérifiez ensuite l'auteur, les dates, l'historique de révisions et les réponses de relecture. Corroborez chaque trouvaille par deux sources indépendantes. Une chaîne de texte inexpliquée est un indice, pas une feuille de route ; et ne rien trouver démontre seulement que la recherche n'a rien trouvé.
Surveillez trois endroits à partir de maintenant : les archives de KVM et de linux-s390 pour des révisions ultérieures ou une activité d'intégration, QEMU et libvirt pour un type de machine et un flux de migration, et EDK II plus Arm SystemReady pour le firmware et les preuves de conformité.
Une ABI de kernel, plus un modèle de périphériques du VMM, plus un firmware, plus un résultat de conformité publié, cela commence à ressembler à une plateforme. D'ici là, ce qui existe est un chantier en cours, pas un produit.
Ce que cela peut changer, et ce que cela ne changera pas
Dans les environnements Power et AIX avec lesquels nous travaillons, l'appel ne commence presque jamais par le processeur. Il commence par un déploiement à l'arrêt, et la réponse se trouve presque toujours quatre couches au-dessus du silicium : un paquet jamais compilé, un manifeste de conteneur à deux entrées, un agent de sécurité dont l'éditeur supporte deux architectures et n'a aucun plan pour une troisième. C'est le dernier kilomètre du logiciel : la route entière existe — kernel, compilateur, code source — et il manque le tronçon final, le binaire que quelqu'un publie et supporte. C'est le problème que vise Arm sur Z, et il vaut la peine de délimiter quelle part de ce problème un processeur peut atteindre.
L'industrie du logiciel traite le support d'architectures comme un sous-produit de l'ingénierie de release. amd64 et arm64 apparaissent automatiquement ; s390x et ppc64le attendent que quelqu'un active un build, répare un test ou ajoute un manifeste d'image. IBM ne peut pas porter et certifier personnellement tous les projets, et en ajoutant Arm elle gagne l'accès à du logiciel que les éditeurs compilent déjà. C'est pragmatique et, les chiffres ci-dessus en main, c'est aussi le seul levier disponible sur la seule contrainte de croissance réelle de la plateforme.
Ce que cela ne fait pas, c'est résoudre le reste. La plateforme virtuelle, le support des systèmes d'exploitation, le modèle de sécurité, les interfaces d'accélérateurs, le cycle de vie et les engagements commerciaux continuent de décider si un client peut dépendre du résultat, et trente ans d'histoire disent que la livraison et le support ne se règlent pas tout seuls. Rien de tout cela ne rendra non plus une application mal écrite scalable, sûre ou résiliente. Cela peut rendre cette application disponible à côté de données Z précieuses sans créer une île d'infrastructure de plus — un accomplissement sérieux, et nettement plus modeste que « le mainframe exécute désormais l'écosystème Arm », version sous laquelle la semaine l'a raconté.
Ce qu'on peut faire d'utile avec une annonce comme celle-ci, c'est noter où s'arrête une charge réelle : au jeu d'instructions, à l'ABI, à la plateforme, ou au paquet manquant et à la déclaration de support que personne ne signera. Ce sont ces échecs concrets — pas les benchmarks — qui diront si Arm sur Z élimine la raison pour laquelle les charges s'en vont.
La question qui se pose toute seule
Les utilisateurs de Power connaissent ce dernier kilomètre de première main. Le kernel supporte l'architecture. Le compilateur la supporte. Le code source de l'application est portable. L'éditeur, simplement, n'a pas publié le binaire.
Voilà le fait, et il s'arrête là : si une deuxième ISA se révèle une bonne idée sur Z, la question de savoir si elle le serait sur Power se pose toute seule. Se la poser sérieusement — l'histoire et les chiffres sur la table — c'est le travail de la Partie III.
jours entre le dernier patch public et le jour où le produit a eu un nom.
Piste ouverte depuis avrilL'annonce, vue de l'intérieur
SIE et son petit frère SAE, les 33 patchs d'arm-on-s390 lus dans l'ordre, et ce que la piste publique du kernel permet d'affirmer — et de ne pas affirmer — sur le produit qu'IBM va vendre.
Lire la Partie IIEt votre plateforme ?
Nous travaillons au quotidien avec Power, AIX, IBM i et Linux sur systèmes IBM. Si le dernier kilomètre que décrit cet article vous rappelle quelque chose — le paquet qui n'existe pas, l'agent qui ne supporte pas votre architecture, la migration qui bloque quatre couches au-dessus du processeur —, racontez-le-nous et nous y jetterons un œil.
Formations officielles et services sur systèmes IBM · sixe.beBlog!
Notre mission
SIXE garantit que vos infrastructures basées sur les technologies IBM®, Red Hat®, Canonical® et SUSE® restent stables, sécurisées et optimisées aussi longtemps que vous en avez besoin.
Chez SIXE, nous nous engageons pour la durabilité. C’est pourquoi nous vous aidons à concevoir, mettre en œuvre et maintenir des solutions technologiques durables et efficaces.
