IBM Z y Arm: qué resuelve un procesador dual-ISA
IBM ya lo intentó en 1994.Su próximo mainframe ejecutará ARM además de z/Architecture. Un mismo núcleo hablando dos arquitecturas: la idea tiene treinta años, y la historia explica por qué el chip es la parte fácil.
Cada núcleo del futuro procesador de mainframe ejecutará ARM y z/Architecture. Es una proeza de ingeniería, y resuelve uno de los cuatro problemas que hacen falta para que un binario ajeno llegue a producción.
IBM Z está aprendiendo ARM
La versión en audio de este artículo.
IBM acaba de anunciar uno de los procesadores empresariales más extraños de los últimos años, y lo llamativo es todo lo que deja sin resolver. Según el anuncio del 24 de agosto, IBM está diseñando un futuro procesador para IBM Z y LinuxONE en el que cada núcleo físico ejecute de forma nativa y concurrente flujos de instrucciones ARM y de IBM Z: dos arquitecturas distintas dentro del mismo silicio, sin emulación de por medio.
En cristiano: una arquitectura del conjunto de instrucciones —la ISA— es el idioma y el reglamento con los que el software da órdenes al procesador, y ARM y la z/Architecture de IBM son dos idiomas distintos. Lo que IBM quiere es que cada núcleo entienda los dos de forma directa, como modos de ejecución de primera clase, y no como un pequeño ARM pegado al lado de los núcleos del mainframe ni como emulación disfrazada de otra cosa.
Y sin embargo, meter dos idiomas en un mismo núcleo es la parte fácil. Comprar un diccionario de japonés no te convierte en alguien capaz de defender un caso ante un tribunal de Tokio, y con un procesador multiarquitectura ocurre lo mismo: ejecutar las instrucciones es solo el primero de los cuatro contratos que un binario ajeno tiene que cerrar para llegar a producción. Cuando un fabricante presume de chip multiarquitectura, casi siempre ha resuelto únicamente ese primero, que es una cuarta parte del problema.
Por eso la pregunta interesante va más allá de si esto va a funcionar: IBM lleva décadas fabricando esta clase de silicio, así que eso es casi seguro. La cuestión de fondo aparece en cuanto uno tira del porqué:
Si añadir otra ISA arregla la compatibilidad, ¿por qué parar en dos? ¿Por qué no x86, RISC-V, Power ISA… o todos los idiomas que el software todavía habla?
Y si tiras de ese hilo, el anuncio deja de ser una noticia de procesadores para convertirse en un mapa de qué puede resolver el hardware, qué le sigue tocando al ecosistema y por qué una aplicación puede seguir sin estar disponible aunque el kernel, el compilador y el código fuente lleven años esperándola.
La versión de 90 segundos
No hace falta diseñar procesadores para seguir esta historia. Con siete términos tienes casi todo lo que hace falta para entenderla.
El vocabulario de instrucciones y el comportamiento que se le promete al software
ARM y z/Architecture son ISAs distintas
Un programa ya compilado para una ISA y un entorno concretos
Un binario ARM no se convierte solo en un binario x86, Power o Z
El procesador implementa la ISA que expone al software
Evita traducir instrucción a instrucción, pero no garantiza soporte de sistema operativo ni de aplicación
Un ordenador simulado y aislado que el hipervisor presenta al software
IBM espera que los entornos Linux ARM convivan con las cargas Z establecidas mediante virtualización
El anfitrión es la máquina física y su sistema operativo; el huésped es cada sistema que corre dentro, aislado, como si tuviera su propio ordenador
El Linux ARM del anuncio corre como huésped sobre el anfitrión Z
Un procesador virtual que el anfitrión planifica para una VM
Una VM ARM puede tener varias vCPU y no está atada permanentemente a un hilo de hardware
KVM es el marco de virtualización de Linux; SAE significa Start ARM Execution
KVM gestiona el huésped ARM; SAE es la puerta de hardware hacia la ejecución ARM
IBM está resolviendo el problema de las instrucciones en silicio y buena parte del camino de virtualización en Linux. A la plataforma terminada le siguen faltando firmware, dispositivos virtuales, migración y soporte de las distribuciones.
Ese hueco entre puede ejecutarse y puede estar en producción es de lo que trata el resto del artículo.
¿No te interesan los detalles históricos? La sección «Ya hemos intentado escapar de la arquitectura» es contexto, no requisito: si vas con prisa, sáltatela y ve directo a «¿Por qué meter ARM en el hardware ahora?».
Una guía, por si alguna palabra se te escapa
Qué es una ISA, qué es una ABI y por qué cuesta tanto que un programa corra en otra arquitectura: un cuaderno de doce páginas lo explica desde cero, con diez casos históricos y la fuente de cada uno. No hace falta para seguir el artículo; está por si quieres el terreno completo.
Descargar «Ejecutar código ajeno» PDF · 12 páginasLo que IBM hace de sobra bien
Muy pocas compañías pueden combinar un procesador que supera los 5,7 GHz con cachés enormes, memoria y E/S a gran escala, detección de fallos en línea, gestión segura de claves, criptografía y aceleración de IA. Y luego hay que meterlo dentro de una máquina de la que se espera que siga disponible bajo cargas que tumbarían a un servidor normal.
Y entonces, unas cuantas capas por encima de toda esa ingeniería, un despliegue falla porque un script de instalación dice, en esencia:
if architecture == amd64 or architecture == arm64:
continue
else:
exit("arquitectura no soportada")Años de trabajo en procesador, firmware y sistema operativo acaban de ser derrotados por un array de dos elementos.
Hay algo magníficamente IBM en responder a «necesitamos más binarios» rediseñando el procesador del mainframe. Pero el contraste marca el límite: el hardware puede hacer ejecutable un binario; no puede hacer que un fabricante lo compile, lo pruebe, lo firme y lo soporte.
Lo que IBM pretende con su anuncio
La nota de IBM describe un procesador de 11 núcleos fabricado en 2 nm en el que cada núcleo está preparado para ejecutar instrucciones ARM y de IBM Z, y sobre esa base IBM espera que Linux nativo de ARM conviva con z/OS y Linux on IBM Z. El diseño incluye además aceleración de inferencia de IA y una unidad de procesamiento de datos —DPU— integrada en el propio chip. Y por si quedaba alguna duda sobre las intenciones, IBM y ARM presentan el acceso al ecosistema de software de ARM como el objetivo central y declarado de todo el diseño.
Hay más detalle preliminar, y esas cifras insinúan más de lo que dicen. El objetivo de la implementación ARM es AArch64 v9.3 con extensiones vectoriales SVE y SVE2, y cualquiera de los dos hilos del núcleo puede ejecutar cualquiera de las dos ISAs con cambios de modo que IBM sitúa en nanosegundos. Y lo más importante: las presentaciones preliminares de IBM apuntan a que el diseño reutiliza buena parte del motor de ejecución de Z para correr ARM —predicción, cachés, tablas de páginas—, aunque el diseño final no es público. Ahí está la eficiencia del diseño, y también la frontera de verificación —el límite de lo verificado—: cuanto más comparten ARM y Z el mismo motor, más hay que demostrar que un modo no contamina al otro.
IA, criptografía y la DPU se presentan también como disponibles para el entorno ARM. Lo que decide el valor es el driver que expone el acelerador al sistema huésped (el Linux ARM que corre dentro), por encima de los megabytes de caché: un acelerador «disponible» sólo cuenta cuando ese driver existe —y de eso el anuncio no dice nada.
Esto se plantea como plataforma, con vocación de producto. Pero funciona como declaración de intenciones que todavía debe cristalizar en una especificación de producto: IBM ha anunciado una dirección de diseño y advierte de que sus planes pueden cambiar o retirarse. Lo que el anuncio establece es qué pretende construir IBM, no cómo se presentará ante los sistemas que corren dentro, ni la política de seguridad, ni el contrato de migración, ni el rendimiento, ni los sistemas operativos soportados, ni el catálogo de desarrolladores de software independientes (ISV). «Hay un acelerador disponible para ARM» sólo sirve de algo cuando existen un driver, una biblioteca, un modelo de errores y una declaración de soporte que lo hagan real.
años sin que ninguna capa de compatibilidad consiga que un fabricante firme un contrato de soporte.
Ni una excepción en treinta añosLos cinco significados de «ejecuta ARM»
IBM describe la ejecución ARM como nativa, y la palabra hace un trabajo útil: significa que el procesador implementa la arquitectura ARM en lugar de pedirle a un emulador que traduzca cada instrucción ARM a instrucciones Z.
No significa que todo programa ARM vaya a funcionar sin tocarlo. No promete el rendimiento de un procesador ARM de servidor dedicado, ni soporte de todas las extensiones opcionales de ARM, ni acceso automático a todas las prestaciones de Z. Y desde luego no genera certificaciones de Red Hat, Canonical, SUSE ni de los ISVs comerciales.
Las CPU modernas ya convierten las instrucciones arquitectónicas visibles en operaciones internas más pequeñas. «Nativo» describe el contrato expuesto al software y da por hecha toda la maquinaria que trabaja detrás del telón. El diseño de IBM parece extender ese principio a dos arquitecturas públicas: predicción, aritmética y unidades de carga/almacenamiento compartidas donde se puede; estado arquitectónico separado donde los contratos divergen.
Esto importa porque ejecutar software ajeno no es un problema, son cinco. Y el lenguaje de marketing tiende a comprimirlos en una sola palabra, aunque cada uno actúa en una capa distinta de la pila.
La ejecución nativa multi-ISA es el núcleo que IBM ha anunciado. La traducción en espacio de usuario es Rosetta 2, Prism, FX!32 y PowerVM Lx86. La emulación de sistema completo es QEMU. La compatibilidad de ABI —la ABI es el contrato de más bajo nivel entre un programa ya compilado y el sistema: cómo se llaman las bibliotecas, cómo se pasan los parámetros— es el Linuxulator de FreeBSD. El empaquetado multiarquitectura es un índice de imagen OCI o un binario universal de Apple. No son variaciones de una misma idea: cada uno se detiene en una capa distinta, y esa frontera decide qué aplicaciones funcionan, a qué velocidad y quién recibe el ticket de soporte cuando fallan.
FreeBSD lo explica mejor que nadie
FreeBSD ejecuta muchos binarios de Linux sin modificar gracias a una capa opcional de compatibilidad llamada Linuxulator. El manual de FreeBSD documenta soporte para x86 y AArch64, y la página de manual linux(4) describe una implementación real de la ABI de Linux, una capa del sistema operativo que deja el emulador de CPU completamente al margen.
El procesador anfitrión sigue teniendo que entender la ISA del binario, así que en una máquina x86 es el hardware x86 el que ejecuta las instrucciones mientras FreeBSD atiende las llamadas al sistema al estilo Linux, y en una máquina ARM ocurre exactamente lo mismo con binarios Linux de ARM. Lo que Linuxulator no hace en ningún momento es traducir x86 a ARM a escondidas.
De ahí sale la primera regla de esta historia:
Entender las instrucciones no es lo mismo que entender el sistema operativo.
Cuatro contratos, no uno
Hasta aquí, las cinco formas de ejecutar ARM. Pero que se ejecute es solo el primero de otra lista distinta: los cuatro contratos que un binario debe cerrar para llegar a producción. La confusión de todo este campo consiste en creer que resolver el primero resuelve los cuatro.
El procesador de IBM aborda el primer contrato. La serie de KVM arm-on-s390 en su v6 esboza buena parte del camino a nivel de kernel hacia una VM ARM. Linux, el firmware y el monitor de máquina virtual todavía tienen que completar la plataforma. Las distribuciones y los ISVs todavía tienen que completar la entrega y el soporte.
Una plataforma puede ser brillante en el primer contrato y decepcionante comercialmente en el cuarto.
Ya hemos intentado escapar de la arquitectura
El diseño de IBM es inusual, pero el sueño que hay detrás no nació ayer: preservar la inversión en software mientras cambia la máquina que hay debajo.
Treinta años de intentos han dejado un patrón, y sorprende a casi todo el mundo.
Un procesador puede hablar dos idiomas y no tener público
En los años noventa, IBM desarrolló al parecer un prototipo conocido como PowerPC 615, capaz de ejecutar x86 además de PowerPC de 32 y 64 bits. Es, casi exactamente, la idea que IBM acaba de anunciar para Z y ARM, treinta años antes. El relato más detallado que sobrevive es un reportaje de 1998, basado en un ingeniero anónimo de IBM; un recuadro de 1995 también habló del dispositivo, nunca comercializado, con fuentes anónimas.
El relato posterior afirmaba que Minix y una versión de desarrollo de OS/2 llegaron a demostrar ejecución mixta, pero que el proyecto no tenía un camino rentable y no consiguió el soporte de Windows que necesitaba. Es el testimonio de alguien de dentro, no historia corporativa establecida. Lo que sí está documentado es que Microsoft terminó el desarrollo de Windows NT para PowerPC en 1997, alegando caída de demanda.
La lección no depende de los detalles discutidos. El silicio funcionaba; el cuarto contrato no se firmó nunca.
La traducción funciona mejor cuando sabe dónde termina el puente
DIGITAL se topó con el mismo problema de catálogo en Alpha, y lo respondió con la ingeniería más elegante de toda esta historia. FX!32 no traducía el código x86 de una pasada. La primera vez que ejecutabas una aplicación, la emulaba mientras registraba un perfil de los caminos que el programa recorría. Después, en segundo plano, traducía a código Alpha nativo sólo los fragmentos de código más usados y guardaba el resultado en caché. Cada arranque era más rápido que el anterior.
DEC publicó que las aplicaciones traducidas sobre un Alpha a 500 MHz rendían de forma comparable a las nativas sobre un Pentium Pro a 200 MHz. Para 1997 aquello era extraordinario. El código de kernel y los drivers quedaban fuera del modelo, y los resultados dependían de la carga.
Alpha murió igual.
IBM siguió después un camino parecido con PowerVM Lx86, traduciendo aplicaciones Linux x86 de 32 bits sobre Power y cacheando el código traducido. Resolvía el problema que describe la Parte III de esta serie: el catálogo de software que nadie compila para Power. Funcionaba para utilidades, instaladores y aplicaciones modestas, y se rompía en acceso directo a hardware, módulos de kernel y código que procesa muchos datos en paralelo de forma intensiva (SIMD). El consejo que dio la propia IBM entonces sigue siendo el correcto: traducción para el software menos crítico, recompilación nativa para lo que exige la plataforma. Lx86 acabó retirándose.
La tecnología detrás de Lx86 era QuickTransit, de una empresa británica llamada Transitive: la misma que Apple licenció para el primer Rosetta, el que traducía aplicaciones PowerPC a los Mac con Intel. El mismo software, funcionando en direcciones opuestas, para las dos compañías de esta historia. IBM compró Transitive en 2008.
Rosetta 2 de Apple es el mejor traductor binario que ha publicado nadie: tan bueno que la mayoría de usuarios no se enteró de que estaba funcionando. ¿Por qué le salió bien a Apple y a nadie más? Porque Apple controla el chip, el sistema operativo, el formato de aplicación, las herramientas, la tienda y el calendario. Pudo decir «dentro de dos años esto se acaba, portad vuestro software», y todo el mundo portó. Aun así, sigue disponible en macOS 27 y, en macOS 28, queda reducido a ciertos juegos antiguos. El mejor traductor de la historia se diseñó con fecha de caducidad.
Prism de Microsoft es técnicamente solvente y le falta lo único que hizo funcionar a Rosetta: Microsoft no puede imponerle una fecha límite a treinta años de aplicaciones Windows de terceros. Y la frontera de siempre sigue exactamente donde estaba: los drivers de kernel tienen que ser Arm64 nativos.
El procesador universal ya existe, y es software
El proyecto DAISY de IBM Research hizo la pregunta más radical del campo: ¿y si el procesador de verdad fuera un motor VLIW interno (que agrupa varias operaciones por instrucción), y todas las ISAs —ESA/390, RS/6000, AS/400, Java— se tradujeran dinámicamente a él? Transmeta acabó comercializando una versión de esa idea. Crusoe exponía un x86 perfectamente normal mientras el Code Morphing Software lo traducía para un núcleo VLIW oculto, y fracasó por partida doble: el rendimiento era irregular porque dependía de cuánto llevara ya traducido, e Intel simplemente bajó el consumo de sus propios chips.
La IA-32 Execution Layer de Intel es el caso que va en dirección contraria, y casi nadie lo cita. Itanium llevaba compatibilidad x86 en hardware, y decepcionó. Intel la sustituyó por una capa de traducción por software que resultó ser más rápida que el silicio dedicado, y más tarde retiró el hardware x86 del procesador. Meter la compatibilidad en silicio no la mejora automáticamente. La hace más difícil de arreglar.
QEMU nunca prometió velocidad. Prometió universalidad: máquinas completas o procesos de espacio de usuario ajenos, con estado privilegiado y dispositivos incluidos, traducidos por bloques con el Tiny Code Generator. Publicado por primera vez en 2003, ahí sigue, después de que hayan cerrado todos los productos comerciales de esta lista.
Seis patrones de treinta años
Seis cosas se repiten en todos los casos anteriores.
- La traducción muere cuando se acaba el incentivo, con la técnica todavía impecable. FX!32 era excelente y Alpha murió. Rosetta 2 es excelente y Apple ya anunció su final. Lx86 funcionaba e IBM lo retiró. En ninguno de estos casos la causa de la muerte fue «no conseguimos que funcionara».
- Gana quien controla el calendario. Apple pudo decirle a un ecosistema entero que tenía dos años. Ese poder, más que la calidad del traductor, es lo que separa a Rosetta de todos los demás intentos de esta lista. Microsoft no puede decírselo a treinta años de software Windows. IBM tampoco puede decírselo a sus ISVs.
- Un puente no es un domicilio. Todos los casos que funcionaron fueron transiciones con final anunciado; los que intentaron ser permanentes —Transmeta, Lx86— no sobrevivieron.
- El kernel marca siempre la frontera: FX!32, Lx86 y Prism se detienen todos ante los drivers y el código de núcleo, una barrera sin una sola excepción en treinta años.
- El hardware compra predictibilidad y el software compra flexibilidad, y el intercambio no es obvio de antemano. Itanium metió x86 en silicio y una capa de software le ganó.
- La entrega y el soporte no las ha resuelto ninguno de ellos, ni una sola vez. En treinta años, ninguna capa de compatibilidad ha convencido a un fabricante de software para que firme un contrato de soporte. Ese es el contrato que decide si una plataforma es usable, y es el único de la lista que el hardware no puede tocar.
El veredicto real es más matizado que «la traducción fracasó» o «ganó el hardware»:
Usa ejecución nativa donde el rendimiento, el privilegio y los horizontes largos de soporte lo justifiquen. Usa traducción como puente. No confundas ninguno de los dos mecanismos con un compromiso de ecosistema.
por ciento cayeron los ingresos de IBM Z dos trimestres después de subir un 67 %.
Se vende por generaciones¿Por qué meter ARM en el hardware ahora?
La traducción dinámica trae tiempo de calentamiento, cachés de código y un peor caso difícil de acotar. Inofensivo para una utilidad de escritorio; bastante más difícil de defender para cargas empresariales consolidadas con acuerdos de nivel de servicio firmados. Un entorno Linux ARM completo necesita además arquitectura privilegiada —niveles de excepción, tablas de páginas, interrupciones y comportamiento del búfer de traducción de direcciones (TLB)— y la implementación nativa hace ese contrato de máquina completa más creíble que una capa en espacio de usuario. Y luego está la longevidad: Rosetta se diseñó para desaparecer, mientras que una arquitectura de cargas empresariales puede necesitar soporte durante una década o más.
Por debajo de todo eso, IBM quiere que las cargas ARM convivan con los entornos Z establecidos bajo el mismo modelo de gestión, fiabilidad y seguridad. Cita un ecosistema ARM de más de 22 millones de desarrolladores: una cifra que abarca muchos mercados y desde luego no significa 22 millones de futuros desarrolladores de mainframe, pero sí muestra la escala de la inversión en software a la que IBM quiere acercarse.
Así que ARM en hardware resuelve un problema grande y caro de forma predecible. Lo que sigue sin hacer es arrancar un sistema operativo, publicar un contenedor, exponer un acelerador, interpretar una licencia o convencer a un fabricante de que acepte una incidencia en producción.
El programa SystemReady de la propia ARM existe precisamente porque cumplir la ISA no basta, y hoy se reparte en una SystemReady Band para sistemas con descubrimiento de hardware estándar (ACPI) y una SystemReady Devicetree Band para entornos integrados (Devicetree), a las que ARM suma las autodeclaraciones SystemReady VE para entornos virtuales.
IBM aseguró que cumple con SystemReady. Pero quedarse en un «¿lo cumple?» genérico no sirve de nada: hay que pedirle a IBM la banda concreta que aplica, la versión de los requisitos, la autodeclaración VE y el resultado del test. E incluso entonces, ARM advierte de que el cumplimiento de plataforma no implica que un fabricante de sistema operativo soporte ese dispositivo.
¿Por qué ARM y no todas las ISAs?
Imagina un procesador que implemente x86-64, AArch64, Power ISA, z/Architecture, RISC-V, SPARC, MIPS, Alpha y 68000. Más otra arquitectura porque alguien encontró un viejo equipo de ERP detrás de un armario.
Suena inclusivo. Sería también un museo permanente de silicio.
Cada ISA trae mucho más que un decodificador: registros, excepciones, comportamiento de privilegio y reglas de ordenación de memoria, entre otros. Y con todo ese equipaje, cada una se convierte en otra obligación de validación, seguridad, licenciamiento y soporte a largo plazo. Por si fuera poco, las arquitecturas viejas ni siquiera se están quietas: x86 arrastra décadas de extensiones, AArch64 tiene perfiles y características opcionales en evolución, y RISC-V es extensible por diseño.
Un procesador que lo implementara todo se convertiría en QEMU en hardware: nuevo silicio cada pocos años e imposible de parchear con una actualización de paquete.
Esa es la respuesta de ingeniería. La comercial —por qué ahora y por qué ARM— se lee en el balance de IBM.
La otra mitad es un balance
El encaje técnico justifica que una segunda ISA sea asumible, pero la elección de ARM y de este momento responde a la estructura de ingresos de IBM.
IBM cerró 2025 con 67.500 millones de dólares de ingresos. Infraestructura —el segmento que contiene el hardware de mainframe— aportó 15.718 millones, alrededor del 23 %. Eso subestima bastante el peso de la plataforma, porque el software que sólo existe porque existen los mainframes no se contabiliza ahí. CICS, IMS, Db2 for z/OS y MQ se facturan dentro del segmento Software, bajo Transaction Processing. IBM no desglosa el margen de esa categoría —sólo publica un 83,5 % de margen bruto para todo el Software—, así que el cálculo es aproximado. Aun así, el orden de magnitud es claro: el software de mainframe por sí solo parece generar unas tres cuartas partes del margen bruto de todo el segmento de Infraestructura con aproximadamente la mitad de sus ingresos. Añade IBM Financing, que financia las propias máquinas, y la parte de consultoría que vive de modernizarlas, y el peso del mainframe en el beneficio va muy por delante de su peso en la facturación.
Ese negocio es además brutalmente cíclico, porque los mainframes se venden por generaciones. Los ingresos de IBM Z crecieron un 51,7 % en 2025 —un 48,4 % a moneda constante— empujados por el z17, lanzado en junio, y un 67 % sólo en el cuarto trimestre. Dos trimestres después cayeron un 42 %. El director financiero de IBM atribuyó la caída al calendario de compra y no al abandono, y aportó el dato que lo respalda: los cinco primeros trimestres del ciclo z17 van cerca de un 30 % por delante del z16, que a su vez había sido el programa más fuerte de la historia de la compañía. Son dos reglas de medir distintas —la variación interanual mide el trimestre, la comparación programa a programa mide el ciclo— y, para un negocio que vende por generación, la segunda parece la más honesta, aunque IBM tiene un interés evidente en defender esa lectura.
Mientras tanto, la base instalada está sana y crece hacia dentro: más capacidad entre los clientes que ya están, con la llegada de clientes nuevos casi plana. Según IBM, el 85 % de los clientes del z16 mantuvo o amplió capacidad y en torno al 70 % de los clientes de mainframe está creciendo en capacidad instalada (medida en MIPS). Lo que ninguna de esas cifras describe es la llegada de tipos de carga nuevos. Y ahí es donde el binario que falta deja de ser una molestia de ingeniería y se convierte en una fuga: un equipo necesita un agente de observabilidad, descubre que no hay compilación para s390x (la arquitectura del mainframe), y despliega esa pieza en otro sitio. Luego la siguiente. En cinco años media aplicación vive fuera.
Leído así, ARM en el mainframe funciona como maniobra defensiva más que como caza de clientes nuevos: elimina la razón por la que esas piezas se marchan, yendo a buscar los binarios donde ya están en lugar de convencer a miles de fabricantes de que compilen para s390x.
Eso explica también la arquitectura elegida, y la candidata más evidente queda fuera por sorpresa.
La opción que parecía la ideal
La segunda arquitectura técnicamente más fácil para IBM no es ARM: es Power. IBM es dueña de ambas ISAs, no le paga licencia a nadie por ninguna, y comparte buena parte del equipo de diseño y de la biblioteca física entre las dos.
IBM no ha explicado por qué no lo hizo, y las razones —lo que dicen del negocio del mainframe y del ecosistema Power— dan para una entrega entera. Son la Parte III de esta serie. Aquí basta con dejar anotado el hecho: teniendo en casa la arquitectura más fácil, IBM eligió la de fuera.
¿Por qué no x86?
IBM no ha dicho que evaluara x86 y lo descartara; con lo público basta para ver por qué x86 es otra historia.
Los hechos públicos siguen explicando por qué x86 es una proposición distinta. Sus derechos de implementación han dependido históricamente de licencias corporativas concretas, licencias cruzadas de patentes y relaciones comerciales. El formulario 10-K de AMD de 2026, por ejemplo, incorpora por referencia la licencia cruzada AMD–Intel. Eso evidencia una relación jurídica bilateral: un licenciamiento cerrado, reservado a las partes del acuerdo y ajeno a cualquier implementador que quiera sumarse.
Un entorno x86-64 moderno y útil heredaría además un contrato de compatibilidad enorme. IBM podría implementar un subconjunto, pero el software que merecería la pena importar podría ser precisamente el que comprueba si faltan características.
Las aplicaciones x86 aún podrían llegar de forma selectiva a través de QEMU u otro traductor dentro de una VM Linux ARM. Windows on ARM ya hace algo parecido con Prism, aunque Microsoft no ha anunciado ningún producto de Windows on ARM para IBM Z. Eso podría servir para una utilidad. No sería soporte nativo de x86.
¿Por qué no RISC-V?
RISC-V es la pregunta más interesante en cuanto a arquitectura abierta. RVA23 define una línea base de aplicación más sólida, y RISC-V International ha ratificado una especificación de plataforma de servidor que cubre firmware, UEFI, ACPI, interrupciones, gestión y seguridad. Eso vuelve a demostrar lo mismo: incluso una ISA abierta necesita un contrato de plataforma antes de que el software de servidor corriente pueda confiar en ella.
RISC-V puede acabar siendo un objetivo empresarial muy atractivo. Pero el objetivo declarado de IBM es acceder a un catálogo que ya existe, y en 2026 ese catálogo es el de ARM. Apertura y amplitud son ventajas distintas, y sólo una de las dos entrega binarios en esta década.
Lo que IBM todavía tiene que explicar
El anuncio merece entusiasmo. Merece también preguntas dirigidas a lo que sigue siendo desconocido, y no a lo que el registro público ya ha respondido.
IBM dice que Z y ARM se ejecutan de forma concurrente, y que un mismo hilo puede usar cualquiera de las dos ISAs
¿Pueden los hilos hermanos de un mismo núcleo ejecutar ISAs distintas bajo cualquier política soportada, y cómo se ubican, aíslan y facturan?
La serie pública v6 kvm-arm64 propone creación de VM/vCPU, gestión de memoria y entrada por SAE
¿Qué completa el firmware, los dispositivos virtuales, la migración, QEMU/libvirt y la orquestación?
AArch64 v9.3, SVE/SVE2 y descubrimiento de características
¿Qué perfil visible para el huésped se mantiene estable entre máquinas y generaciones?
Predicción, aritmética, carga/almacenamiento, cachés y estructuras de TLB se reutilizan de forma sustancial
¿Cómo se aíslan los dominios de seguridad y se da servicio predecible a cargas mezcladas?
Nada público
¿Cómo se sitúan los huéspedes ARM junto al particionado que el cliente ya usa (PR/SM, z/VM)?
Nada público más allá de la serie del kernel
¿Quién escribe y mantiene el modelo de dispositivos del huésped ARM, y durante cuánto tiempo?
El objetivo declarado es Linux nativo de ARM
¿Qué distribuciones, versiones, imágenes, ISVs y aceleradores están soportados?
Las tres últimas son las que, según la historia, van a decidir el resultado. El patrón 4 es la razón por la que importa la pregunta de los drivers; el patrón 6 es la razón por la que la matriz de soporte importa más que cualquier benchmark.
El camino KVM explica el mecanismo a nivel de hilo
La pregunta tentadora —«¿pueden dos hilos hermanos del mismo núcleo (SMT) ejecutar ISAs distintas?»— ya está respondida en principio. Un monitor de máquina virtual en espacio de usuario crea una VM y sus vCPU a través de la API de KVM; KVM guarda el estado ARM de cada vCPU; Linux planifica el hilo anfitrión que conduce esa vCPU sobre una CPU lógica; y SAE entra ahí en el contexto del huésped ARM. KVM mantiene la VM desacoplada del hilo SMT: proporciona contextos de vCPU que Linux planifica de forma independiente.
Lo que la serie no resuelve es la política. ¿Permitirá IBM siempre ISAs distintas en hilos hermanos del mismo núcleo, o recomendará emparejar la misma ISA para ciertos perfiles de seguridad o rendimiento? ¿Cómo funcionarán la afinidad, los derechos de uso, la medición y el informe de capacidad entre LPAR? ¿Qué pasa con los niveles de servicio cuando dos cargas distintas comparten un núcleo?
SAE no es una idea nueva. Es la más vieja del mainframe
Para quien conozca la z/Architecture, la forma de SAE le va a resultar familiar. Y no es casualidad.
Desde mediados de los ochenta, el mainframe entra en la ejecución de huéspedes a través de una instrucción: SIE, Start Interpretive Execution. El anfitrión construye un bloque de control llamado state description, ejecuta SIE apuntando a él, y el procesador ejecuta directamente las instrucciones e interrupciones del huésped hasta que surge algo que requiere al anfitrión. Entonces sale, y el control vuelve. SIE se creó para virtualizar System/370 y 370-XA, se extendió a través de ESA/390 y sigue estando debajo de PR/SM y z/VM. IBM publicó la arquitectura como Interpretive Execution (SA22-7095) y la describió en el IBM Systems Journal.
SAE sigue exactamente esa forma. Recibe la dirección de un bloque de control, entra en ejecución ARM acelerada y devuelve el control al anfitrión s390 al salir, para que KVM y el monitor de máquina virtual gestionen el evento.
IBM no ha descrito SAE como descendiente de SIE, y la serie pública no lo plantea así. Pero el parecido no es decorativo. Sugiere que IBM extiende a una segunda arquitectura el mecanismo de virtualización más ejercitado que tiene, en lugar de abrir una puerta nueva hacia la ejecución de huéspedes. Para una plataforma cuya propuesta de valor entera consiste en no sorprender a nadie, eso es mejor señal que un diseño novedoso.
La maquinaria compartida es la eficiencia, y la frontera de verificación
El diseño apunta a una reutilización sustancial de predicción, caché, TLB y unidades de ejecución, aunque no hay especificación final pública. Las preguntas que siguen son concretas: cómo se limpian, al cambiar de arquitectura, las tablas y cachés internas que aceleran la CPU (TLB, prefetchers, predictores de salto), para que una carga no pueda espiar a la de al lado por los rastros que deja en ese hardware compartido (un ataque de canal lateral); cómo se miden los contadores de rendimiento, las trazas y la depuración; y si colocar ISAs distintas en hilos hermanos agrava ese riesgo. La mayor parte de la eficiencia del diseño viene de esa compartición, que es justamente por lo que necesita una respuesta explícita.
Lo mismo vale para los aceleradores. IBM dice que las cargas ARM pueden alcanzar las funciones de IA, compresión, criptografía, ordenación y DPU; lo que importa es cuáles se publican, cómo las ve el sistema huésped, con qué drivers y con qué garantías de recuperación. Y el benchmark que cuenta mide si un rendimiento ARM aceptable crea valor de sistema que un servidor ARM separado no puede dar, más que si el ARM de IBM le gana a Graviton en una prueba genérica.
Y después, una matriz de soporte. La ejecución de binarios es una propiedad técnica; el soporte en producción es un acuerdo comercial.
Las pistas que IBM dejó antes del anuncio
Las notas de prensa describen intenciones. La infraestructura de desarrollo acaba describiendo la máquina.
OSINT —inteligencia de fuentes abiertas— significa sacar conclusiones prudentes de evidencia pública. Aquí, la evidencia más útil no apareció bajo el nombre del producto. La primera serie pública de KVM arm-on-s390 llegó el 2 de abril, el mismo día que el anuncio de colaboración entre IBM y ARM. La publicó Steffen Eiden, de IBM, bajo un asunto que ningún departamento de marketing habría elegido —«KVM: s390: Introduce arm64 KVM»— y para el 12 de agosto había llegado a la v6 con 33 parches. La serie se siguió públicamente desde su primera revisión hasta la segunda ese mismo mes, y quedó registrada de forma independiente. Ésa es la corroboración que una afirmación así necesita.
Esta cronología demuestra que existió un esfuerzo de desarrollo público, con nombre y apellidos. No demuestra que los parches se hayan integrado, que estén listos para producción ni que sean idénticos al producto final. Una serie de parches funciona como propuesta en revisión que aún debe demostrar su viabilidad.
Qué revelan los 33 parches
La carta de presentación de la v6 describe dos implementaciones de KVM conviviendo en s390 e introduce un segundo módulo llamado kvm-arm64. La serie cubre creación y destrucción de VM y vCPU ARM, llamadas de control (ioctls) de las vCPU, gestión de memoria del huésped, tratamiento de fallos de página, reutilización selectiva del código ARM de KVM ya existente, descubrimiento de características de ARM y manejo del estado de registros entre anfitrión y huésped. También mueve las cabeceras de arm64 a rutas independientes de arquitectura y crea código compartido bajo virt/kvm/arm64/: el tipo de refactorización que sólo tiene sentido si viene un segundo consumidor.
En el centro está la instrucción SAE, descrita más arriba.
Eso es la fontanería necesaria para crear, ejecutar y detener una VM ARM. Los parches exponen además trabajo sin terminar: parte del manejo de registros y funciones relacionadas quedan aplazadas a series posteriores.
Una búsqueda pública dirigida el 27 de agosto no encontró ninguna serie arm-on-s390 claramente atribuible a IBM para QEMU, libvirt o EDK II. Ese resultado negativo hay que leerlo en su justa medida: dice que el backend público del kernel es visible mientras la pila completa pública de espacio de usuario y firmware todavía no lo es. No demuestra que esas capas no existan en privado.
La lección de OSINT es reutilizable
Buscar sólo «procesador dual-ISA de IBM» antes del 24 de agosto probablemente habría fallado. Los términos productivos eran arm-on-s390, KVM_ARM64, kvm-arm64, Start ARM Execution y SAE.
Los ingenieros bautizan un mecanismo mucho antes de que marketing bautice un producto. Busca en los parches interfaces, símbolos de configuración, instrucciones, estructuras de control, identificadores de dispositivo y tipos de máquina. Después verifica autoría, fechas, historial de revisiones y respuestas de revisión. Corrobora cada hallazgo con dos fuentes independientes. Una cadena de texto sin explicar apunta una pista y todavía no dibuja una hoja de ruta.
Vigila tres sitios a partir de ahora: los archivos de KVM y linux-s390 para revisiones posteriores o actividad de integración, QEMU y libvirt para un tipo de máquina y un flujo de migración, y EDK II más ARM SystemReady para firmware y evidencia de cumplimiento.
Una ABI de kernel, más un modelo de dispositivos del VMM, más firmware, más un resultado de cumplimiento publicado, empieza a parecerse a una plataforma. Hasta entonces, lo que hay es todavía una obra en marcha camino de convertirse en producto.
Lo que esto puede cambiar y lo que no
En los entornos Power y AIX con los que trabajamos, la llamada casi nunca empieza por el procesador. Empieza por un despliegue que se ha parado, y la respuesta está casi siempre cuatro capas por encima del silicio: un paquete que nunca se compiló, un agente de seguridad cuyo fabricante soporta dos arquitecturas y no tiene planes para una tercera. El software está a un paso de existir para esa arquitectura —el kernel, el compilador y el código fuente ya la soportan— y falta justo ese último paso: que alguien publique el binario y se comprometa a mantenerlo. Ese es el problema al que apunta ARM en Z, y conviene delimitar qué parte de él puede alcanzar un procesador.
La industria del software trata el soporte de arquitecturas como algo secundario del proceso de publicación. amd64 y arm64 aparecen automáticamente; s390x y ppc64le (la arquitectura de Power) esperan a que alguien habilite una compilación, arregle un test o añada un manifiesto de imagen. IBM no puede portar y certificar personalmente todos los proyectos. Añadiendo ARM gana acceso a software que los fabricantes ya compilan. Es pragmático y, con las cifras de más arriba delante, es también la única palanca disponible sobre la única restricción de crecimiento real de la plataforma.
Lo que no hace es resolver el resto. La plataforma virtual, el soporte de sistemas operativos, el modelo de seguridad y los compromisos comerciales siguen decidiendo si un cliente puede depender del resultado. Lo que sí consigue es poner ese software al lado de los datos de Z sin levantar otra isla de infraestructura: un logro real, y bastante más modesto que «el mainframe ya ejecuta el ecosistema ARM», que es como se ha contado esta semana.
Lo que conviene anotar es dónde se para una carga real: en el conjunto de instrucciones, en la ABI, en la plataforma, o en el paquete que falta y la declaración de soporte que nadie va a firmar. Esos fallos concretos, más que los benchmarks, dirán si ARM en Z elimina la razón por la que las cargas se marchan.
La pregunta que queda: ¿y Power?
Los usuarios de Power conocen este problema de primera mano: la arquitectura está soportada de arriba abajo y, aun así, el fabricante no publica el binario.
Si una segunda ISA resulta buena idea en Z, cuesta no preguntarse lo mismo sobre Power. Responderlo en serio —con la historia y los números delante— es el trabajo de la Parte III. Antes, en unas semanas, llega la Parte II: el anuncio diseccionado desde el rastro público del kernel.
días entre el último parche público y el día en que el producto tuvo nombre.
Rastro abierto desde abrilIBM enseñó sus cartas meses antes
Antes del comunicado oficial, IBM ya estaba subiendo a Linux —en abierto y firmado con nombre y apellidos— el mapa de lo que iba a vender. En la Parte II lo reconstruimos parche a parche: qué es SAE, por qué su forma delata treinta años de linaje, y qué se puede afirmar (y qué no) sobre el producto leyendo solo lo que IBM dejó público.
Leer la Parte II¿Y tu plataforma?
Si algo de esto te suena —el paquete que nadie compila para tu arquitectura, el agente de seguridad que soporta dos plataformas y no la tuya, el despliegue que se atasca cuatro capas por encima del procesador—, es exactamente el cuarto contrato del que va este artículo. Y es donde pasamos el día: Power, AIX, IBM i y Linux sobre sistemas IBM. Cuéntanoslo y le echamos un ojo.
Formación oficial y servicios sobre sistemas IBM · sixe.es
