IBM Z et Arm : ce que résout un processeur dual-ISA
IBM l'a déjà tenté en 1994.Son prochain mainframe exécutera ARM en plus de z/Architecture. Un même cœur parlant deux architectures : l'idée a trente ans, et l'histoire explique pourquoi la puce est la partie facile.
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.
IBM Z apprend l’ARM
La version audio de cet article.
IBM vient d'annoncer l'un des processeurs d'entreprise les plus étranges de ces dernières années, et ce qui frappe, c'est tout ce qu'il laisse non résolu. Selon l'annonce du 24 août, IBM conçoit un futur processeur pour IBM Z et LinuxONE dans lequel chaque cœur physique exécute nativement et simultanément des flux d'instructions ARM et IBM Z : deux architectures distinctes au sein du même silicium, sans la moindre émulation.
En clair : une architecture de jeu d'instructions, l'ISA, est la langue et le règlement par lesquels le logiciel donne ses ordres au processeur, et ARM et la z/Architecture d'IBM sont deux langues différentes. Ce qu'IBM veut, c'est que chaque cœur comprenne les deux directement, comme des modes d'exécution de premier rang, et non comme un petit ARM collé à côté des cœurs du mainframe ni comme de l'émulation déguisée en autre chose.
Et pourtant, mettre deux langues dans un même cœur, c'est la partie facile. Acheter un dictionnaire de japonais ne fait pas de vous quelqu'un capable de plaider devant un tribunal de Tokyo, et il en va de même pour un processeur multi-architecture : exécuter les instructions n'est que le premier des quatre contrats qu'un binaire venu d'ailleurs doit signer pour arriver en production. Quand un fabricant se vante d'une puce multi-architecture, il n'a presque toujours réglé que ce premier-là, soit un quart du problème.
C'est pourquoi la question intéressante va au-delà de savoir si cela va fonctionner : IBM fabrique ce type de silicium depuis des décennies, donc le tenir pour acquis est quasi certain. La question de fond apparaît dès qu'on tire sur le pourquoi :
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 ?
Et si vous tirez sur ce fil, l'annonce cesse d'être une actualité de processeurs pour devenir une carte de ce que le matériel peut résoudre, de ce qui reste à la charge de l'écosystème, et de la raison pour laquelle une application peut rester indisponible alors même que le kernel, le compilateur et le code source l'attendent depuis des années.
La version 90 secondes
Pas besoin de concevoir des processeurs pour suivre cette histoire. Avec sept termes, vous avez presque tout ce qu'il faut pour la suivre.
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
L'hôte est la machine physique et son système d'exploitation ; l'invité est chaque système qui tourne dedans, isolé, comme s'il avait son propre ordinateur
Le Linux ARM de l'annonce tourne comme invité sur l'hôte Z
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
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, la migration et le support des distributions.
Cet écart entre peut s'exécuter et peut tourner en production est le sujet du reste de l'article.
Les détails historiques ne vous intéressent pas ? La section « Nous avons déjà essayé d'échapper à l'architecture » apporte du contexte, pas des prérequis : si vous êtes pressé, sautez-la et allez directement à « Pourquoi mettre ARM dans le matériel maintenant ? ».
Un guide, au cas où un mot vous échappe
Ce qu'est une ISA, ce qu'est une ABI et pourquoi il est si difficile qu'un programme tourne sur une autre architecture : un cahier de douze pages l'explique depuis zéro, avec dix dossiers historiques et la source de chacun. Inutile pour suivre l'article ; il est là si vous voulez tout le terrain.
Télécharger « Exécuter le code des autres » PDF · 12 pagesCe qu'IBM fait remarquablement bien
Très peu d'entreprises savent combiner un processeur qui 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 il faut loger le tout dans une machine dont on attend qu'elle reste disponible sous des charges qui mettraient à genoux un serveur ordinaire.
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 le contraste dit la limite : le matériel peut rendre un binaire exécutable ; il ne peut pas obtenir qu'un éditeur le compile, le teste, le signe et le supporte.
Ce que vise IBM avec son annonce
Le communiqué d'IBM décrit un processeur de 11 cœurs gravé en 2 nm dont chaque cœur est prévu pour exécuter des instructions ARM et IBM Z, et c'est sur cette base qu'IBM s'attend à voir Linux natif ARM cohabiter avec z/OS et Linux on IBM Z. Le design y ajoute une accélération d'inférence d'IA et une unité de traitement de données — DPU — intégrée à la puce elle-même. Et pour lever tout doute sur les intentions, IBM et ARM présentent l'accès à l'écosystème logiciel d'ARM comme l'objectif central et déclaré de tout le design.
Il y a plus de détail préliminaire, et ces chiffres laissent entrevoir plus qu'ils ne disent. La cible de l'implémentation ARM est AArch64 v9.3 avec les extensions vectorielles SVE et SVE2, et chacun des deux threads du cœur peut exécuter l'une ou l'autre ISA avec des bascules de mode qu'IBM situe de l'ordre de la nanoseconde. Et surtout, les présentations préliminaires d'IBM indiquent que le design réutilise une bonne partie du moteur d'exécution de Z pour faire tourner ARM — prédiction, caches, tables de pages —, bien que le design final ne soit pas public. C'est là qu'est l'efficacité du design, et aussi la frontière de vérification (la limite du vérifié) : plus ARM et Z partagent le même moteur, plus il faut prouver qu'un mode ne contamine pas l'autre.
Les fonctions d'IA, de cryptographie et la DPU sont elles aussi présentées comme disponibles pour l'environnement ARM. Ce qui décide de la valeur, c'est le pilote qui expose l'accélérateur au système invité (le Linux ARM qui tourne dedans), au-dessus des mégaoctets de cache : un accélérateur « disponible » ne vaut que quand ce pilote existe — et là-dessus, l'annonce ne dit rien.
Le tout est présenté comme une plateforme, avec une vocation de produit. Mais cela fonctionne comme une déclaration d'intentions qui doit encore cristalliser en 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, non comment il se présentera aux systèmes qui tournent dedans, 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'éditeurs de logiciels indépendants (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.
Pas une seule exception en trente ansLes 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 prestations 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 et tient pour acquise toute la machinerie qui travaille 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, alors que chacun agit à une couche distincte de la pile.
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 — l'ABI est le contrat de plus bas niveau entre un programme compilé et le système : comment les bibliothèques sont appelées, comment les paramètres sont passés — 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, une couche du système d'exploitation qui laisse complètement de côté l'émulateur de CPU.
Le processeur hôte doit toujours comprendre l'ISA du binaire : sur une machine x86, c'est le matériel x86 qui exécute les instructions pendant que FreeBSD sert les appels système à la façon de Linux, et sur une machine ARM il se passe exactement la même chose avec des binaires Linux ARM. Ce que le Linuxulator ne fait à aucun moment, c'est traduire 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
Voilà pour les cinq façons d'exécuter ARM. Mais s'exécuter n'est que le premier d'une autre liste : les quatre contrats qu'un binaire doit signer pour arriver en production. 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.
Nous avons déjà essayé d'échapper à l'architecture
Le design d'IBM est inhabituel, mais le rêve derrière ne date pas d'hier : préserver l'investissement logiciel pendant que la machine change en dessous.
Trente ans de tentatives ont laissé une constante, et elle surprend presque tout le monde.
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 1998, fondé sur un ingénieur anonyme d'IBM ; un encadré 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é.
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 fragments de code les plus utilisés 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 qui traite beaucoup de données en parallèle de façon intensive (SIMD). Le conseil que donnait IBM à l'époque reste le bon : la traduction pour les logiciels les moins critiques, 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 (qui regroupe plusieurs opérations par instruction), 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 l'incitation s'épuise, la technique encore intacte. 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, plus que 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 marque toujours la frontière : FX!32, Lx86 et Prism s'arrêtent tous devant les drivers et le code de noyau, une barrière sans une seule exception en trente ans.
- 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 réel est plus nuancé que « la traduction a échoué » ou « 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 %.
Un métier qui se vend par générationsPourquoi 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 et comportement du tampon de traduction d'adresses (TLB) — 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 à découverte matérielle standard (ACPI) et une SystemReady Devicetree Band pour les environnements embarqués (Devicetree). ARM maintient en outre les autodéclarations SystemReady VE pour les environnements virtuels.
IBM a revendiqué la conformité SystemReady, mais se contenter d'un « est-ce conforme ? » générique ne sert à rien : il faut lui demander la bande précise qui s'applique, la version des exigences, l'autodé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 pour autant 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 équipement 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 : des registres, des exceptions, un comportement de privilège et des règles d'ordonnancement mémoire, entre autres. Et avec tout ce bagage, chacune devient une obligation de plus en validation, en sécurité, en licences et en support à long terme. Pire encore, 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. La commerciale — pourquoi maintenant et pourquoi ARM — se lit dans le bilan d'IBM.
L'autre moitié est un bilan comptable
L'adéquation technique justifie une deuxième ISA, mais le choix d'ARM et de ce moment répond à la structure de revenus d'IBM.
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 ne ventile pas la marge de cette catégorie — elle ne publie qu'un taux de 83,5 % pour tout le Software —, le calcul est donc approximatif. L'ordre de grandeur, lui, est net : 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 la moitié de ses revenus. 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 — 48,4 % à taux de change constant — 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, pour un métier qui vend par génération, la seconde paraît la plus honnête, bien qu'IBM ait un intérêt évident à défendre cette lecture.
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. Selon IBM, 85 % des clients du z16 ont maintenu ou étendu leur capacité et environ 70 % des clients mainframe croissent en capacité installée (mesurée 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 (l'architecture du mainframe), 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 ne cherche pas de nouveaux clients : c'est une manœuvre défensive pour é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.
Cela éclaire aussi l'architecture choisie, et la candidate la plus évidente en reste écartée, contre toute attente.
L'option qui semblait idéale
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 qu'elle avait évalué x86 et l'avait écarté ; le public suffit à voir pourquoi x86 est une autre histoire.
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 : un régime de licence fermé, réservé aux parties de l'accord et inaccessible à tout implémenteur qui voudrait s'y joindre.
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 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 que le client utilise déjà (PR/SM, z/VM) ?
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 — « deux threads jumeaux du même cœur (SMT) 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 garde la VM découplée du 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 étend à une deuxième architecture le mécanisme de virtualisation le plus éprouvé qu'elle possède, au lieu d'ouvrir une porte nouvelle vers l'exécution d'invités. 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 design pointe vers 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 nettoie-t-on, au changement d'architecture, les tables et caches internes qui accélèrent le CPU (TLB, prefetchers, prédicteurs de branchement), pour qu'une charge ne puisse pas espionner sa voisine via les traces laissées dans le matériel partagé (une attaque par canal auxiliaire) ; comment on mesure les compteurs de performance, les traces et le débogage ; et si placer des ISA différentes sur des threads jumeaux aggrave ce risque. 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 fonctions d'IA, de compression, de cryptographie, de tri et la DPU ; ce qui compte, c'est lesquelles sont publiées, comment le système invité les voit, avec quels drivers et quelles garanties de reprise. Et le benchmark qui compte mesure si une performance ARM acceptable crée une valeur de système qu'un serveur ARM séparé ne peut pas donner, plus que s'il bat Graviton sur un test générique.
Et ensuite, une matrice de support. L'exécution de binaires est une propriété technique ; le support en production est un accord commercial.
Les indices qu'IBM a laissés 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. La série a été suivie publiquement de sa première révision à la deuxième le même mois, et a été enregistrée de façon indépendante. Voilà la corroboration 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 fonctionne comme une proposition en relecture qui doit encore démontrer sa viabilité.
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 appels de contrôle (ioctls) des 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 signale un indice sans encore dessiner une feuille de route.
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 agent de sécurité dont l'éditeur supporte deux architectures et n'a aucun plan pour une troisième. Le logiciel est à un pas d'exister pour cette architecture — le kernel, le compilateur et le code source la prennent déjà en charge — et il manque justement ce dernier pas : que quelqu'un publie le binaire et s'engage à le maintenir. 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 du processus de publication. amd64 et arm64 apparaissent automatiquement ; s390x et ppc64le (l'architecture de Power) 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é et les engagements commerciaux continuent de décider si un client peut dépendre du résultat. Ce qu'il réussit, c'est à mettre ce logiciel à côté des données de Z sans dresser une île d'infrastructure de plus : un gain réel, 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'il faut noter, c'est 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, plus que les benchmarks, qui diront si ARM sur Z élimine la raison pour laquelle les charges s'en vont.
La question qui reste : et Power ?
Les utilisateurs de Power connaissent ce problème de première main : l'architecture est prise en charge de bout en bout et, malgré tout, l'éditeur ne publie pas le binaire.
Si une deuxième ISA se révèle une bonne idée sur Z, difficile de ne pas se poser la même question pour Power. Se la poser sérieusement — l'histoire et les chiffres sur la table — c'est le travail de la Partie III. Avant, dans quelques semaines, arrive la Partie II : l'annonce disséquée à partir de la piste publique du kernel.
jours entre le dernier patch public et le jour où le produit a eu un nom.
Piste ouverte depuis avrilIBM a montré ses cartes des mois plus tôt
Avant le communiqué officiel, IBM poussait déjà dans Linux — en clair, signé d'un nom — la carte de ce qu'elle allait vendre. Dans la Partie II, nous la reconstruisons patch par patch : ce qu'est SAE, pourquoi sa forme trahit trente ans de lignée, et ce qu'on peut affirmer (et ce qu'on ne peut pas) sur le produit à partir de ce qu'IBM a laissé public.
Lire la Partie IIEt votre plateforme ?
Si quelque chose de tout cela vous parle — le paquet que personne ne compile pour votre architecture, l'agent de sécurité qui supporte deux plateformes et pas la vôtre, le déploiement qui bloque quatre couches au-dessus du processeur —, c'est exactement le quatrième contrat dont parle cet article. Et c'est là que nous passons nos journées : Power, AIX, IBM i et Linux sur systèmes IBM. Racontez-le-nous et nous y jetterons un œil.
Formations officielles et services sur systèmes IBM · sixe.be
