IBM Z is learning Arm.Should one CPU speak every language?

Why put Arm in hardware now?

Dynamic translation brings warm-up time, code caches and a worst case that is hard to bound. Harmless for a desktop utility; much harder to defend for consolidated enterprise workloads with signed service-level agreements. A complete Arm Linux environment also needs privileged architecture—exception levels, page tables, interrupts, timers, atomics, TLB behaviour, virtualization state—and native implementation makes that full-machine contract more credible than a user-space layer. Then there is longevity: Rosetta was designed to disappear, while an enterprise workload architecture may need support for a decade or more.

Underneath all of it, IBM wants Arm workloads to coexist with established Z environments under the same management, reliability and security model. It cites an Arm ecosystem of more than 22 million developers: a figure that spans many markets and certainly does not mean 22 million future mainframe developers, but does show the scale of the software investment IBM wants to reach.

So Arm in hardware solves a large, expensive problem predictably. What it still does not do is boot an operating system, publish a container, expose an accelerator, interpret a licence or persuade a vendor to accept a production incident.

Arm's own SystemReady programme exists precisely because ISA compliance is not enough. The current programme has a SystemReady Band for ACPI-based systems and a SystemReady Devicetree Band for systems described through device tree. Arm also maintains SystemReady VE self-declarations for virtual environments.

Hot Chips coverage says IBM claimed SystemReady compliance. The useful follow-up is not a vague "is it compliant?" It is to ask IBM for the applicable band, the requirements version, the VE declaration and the test result. And even then, Arm warns that platform compliance does not mean an operating-system vendor supports that device.

Why Arm, rather than every ISA?

Imagine a processor implementing x86-64, AArch64, Power ISA, z/Architecture, RISC-V, SPARC, MIPS, Alpha and 68000. Plus one more architecture because somebody found an old ERP appliance behind a cupboard.

It sounds inclusive. It would also be a permanent silicon museum.

Every ISA brings far more than a decoder. It brings registers, exceptions, privilege behaviour, memory-ordering rules, atomics, vectors, debug state, performance counters and firmware interfaces. Each becomes another validation, security, licensing and long-term support obligation. And old architectures do not even stay conveniently still: x86 carries decades of extensions, AArch64 has evolving profiles and optional features, and RISC-V is extensible by design.

A processor that implemented everything would become QEMU in hardware: new silicon every few years and impossible to patch with a package update.

That is the engineering answer, and it is only half of it.

The other half is a balance sheet

The technical argument explains why a second ISA is affordable. It does not explain why now, or why this one. For that, look at where IBM actually earns its money.

IBM closed 2025 with $67.5 billion in revenue. Infrastructure—the segment that contains the mainframe hardware—accounted for $15.7 billion of it, about 23%. That understates the platform considerably, because the software that exists only because mainframes exist is not counted there. CICS, IMS, Db2 for z/OS and MQ are booked inside the Software segment, under Transaction Processing. IBM reports an 83.5% gross margin for Software as a whole and does not break the figure out by category, so applying it to Transaction Processing is an approximation, not a measurement. The order of magnitude survives the caveat: mainframe software alone appears to generate roughly three-quarters as much gross margin as the entire Infrastructure segment, on about half the revenue. Add IBM Financing, which finances the machines themselves, and the consulting work that lives off modernizing them, and the mainframe's weight in profit runs well ahead of its weight in revenue.

That business is also violently cyclical, because mainframes sell by generation. IBM Z revenue grew 51.7% across 2025 on the strength of the z17, launched that June, and 67% in the fourth quarter alone. Two quarters later it fell 42%. IBM's CFO attributed the drop to purchase timing rather than abandonment, and produced the number that supports him: the first five quarters of the z17 cycle run nearly 30% ahead of the z16, itself the strongest program in the company's history. Those are two different rulers—year-on-year change measures the quarter, program-to-program measures the cycle—and IBM is right that the second is the honest one for a business that sells by generation.

Meanwhile the installed base is healthy and growing inward—more capacity at the customers already there, not new customers. 85% of z16 customers maintained or expanded capacity; around 70% of mainframe customers are growing their MIPS. What none of those figures describes is the arrival of new kinds of workload. And that is exactly where the missing binary stops being an engineering nuisance and becomes a leak: a team needs an observability agent, discovers there is no s390x build, and deploys that piece somewhere else. Then the next one. In five years half the application lives elsewhere.

Read that way, Arm on the mainframe is not an offensive move to win new customers. It is defence: an attempt to remove the reason those pieces leave, by going to where the binaries already are instead of persuading thousands of vendors to compile for s390x.

Which also explains the choice of architecture, and it is worth being precise here, because the obvious candidate is not the one people name.

The in-house candidate

The technically easiest second architecture for IBM is not Arm. It is Power. IBM owns both ISAs, pays nobody a licence for either, and shares much of the design team and physical library between them.

IBM has not explained why it did not go that way, and the reasons—what they say about the mainframe business and the Power ecosystem—deserve an instalment of their own. They are Part III of this series. Here it is enough to note the fact: with the easier architecture in the house, IBM chose the one from outside.

Why not x86?

IBM has not said that it evaluated x86 and rejected it, so let's not invent that decision.

The public facts still explain why x86 is a different proposition. Its implementation rights have historically depended on specific corporate licences, patent cross-licences and commercial relationships. AMD's 2026 Form 10-K, for example, incorporates the AMD–Intel cross-licence by reference. That is evidence of a bilateral legal relationship, not of an open architecture-licensing model available to any implementer.

A useful, modern x86-64 environment would also inherit an enormous compatibility contract. IBM could implement a subset, but the software worth importing might be precisely the software that probes for missing features.

x86 applications could still arrive selectively through QEMU or another translator inside an Arm Linux VM. Windows on Arm already does something similar with Prism, although Microsoft has announced no Windows-on-Arm product for IBM Z. That might suit a utility. It would not be native x86 support.

Why not RISC-V?

RISC-V is the more interesting open-architecture question. RVA23 defines a stronger application baseline, and RISC-V International has ratified a server-platform specification covering firmware, UEFI, ACPI, interrupts, management and security. Which proves the same point again: even an open ISA needs a platform contract before ordinary server software can rely on it.

RISC-V may well become a compelling enterprise target. But IBM's stated objective is access to a catalogue that already exists, and in 2026 that catalogue is Arm's. Openness and breadth are different advantages, and only one of them delivers binaries this decade.

What IBM still needs to explain

The announcement deserves enthusiasm. It also deserves questions aimed at what remains genuinely unknown, rather than at what the public record has already answered.

The last three are the ones history says will decide the outcome. Pattern 4 is why the drivers question matters; pattern 6 is why the support matrix matters more than any benchmark.

The KVM path explains the thread-level mechanism

The tempting question—"can separate SMT threads run different ISAs?"—is already answered in principle. A userspace virtual-machine monitor creates a VM and its vCPUs through the KVM API; KVM holds each vCPU's Arm state; Linux schedules the host thread driving that vCPU onto a logical CPU; and SAE enters the Arm guest context there. KVM does not weld a VM to one SMT thread: it provides vCPU contexts that Linux schedules independently.

What the series does not settle is policy. Will IBM always permit different ISAs on sibling threads of the same core, or recommend same-ISA pairing for certain security or performance profiles? How will affinity, entitlement, metering and capacity reporting work across LPARs? What happens to service levels when two unlike workloads share one core?

SAE is not a new idea. It is the mainframe's oldest one

For readers who know z/Architecture, the shape of SAE will look familiar. It is worth pausing on why.

Since the mid-1980s, the mainframe has entered guest execution through one instruction: SIE, Start Interpretive Execution. The host builds a control block called a state description, executes SIE pointing at it, and the processor runs guest instructions and interruptions directly until something arises that requires the host. Then it exits, and control returns. SIE was created to virtualize System/370 and 370-XA, extended through ESA/390, and still sits underneath PR/SM and z/VM. IBM published the architecture as Interpretive Execution (SA22-7095) and described it in the IBM Systems Journal.

SAE follows exactly that shape. It receives the address of a control block, enters accelerated Arm execution, and returns control to the s390 host on exit so that KVM and the virtual-machine monitor can handle the event.

IBM has not described SAE as a descendant of SIE, and the public series does not use that framing. But the resemblance is not decoration. It suggests IBM is not inventing a new doorway into guest execution: it is extending the most heavily exercised virtualization mechanism it owns to a second architecture. For a platform whose entire value proposition is that it does not surprise anyone, that is a better sign than a novel design would be.

Shared machinery is the efficiency, and the verification boundary

The Hot Chips material indicates substantial reuse of prediction, cache, TLB and execution units, though no final specification is public. The questions that follow are concrete: how predictor, cache, TLB and prefetcher state is tagged, flushed or partitioned when the ISA or the security domain changes; how counters, tracing and debug are mediated; and whether placing unlike ISAs on sibling threads changes the side-channel threat model. Most of the design's efficiency comes from that sharing, which is exactly why it needs an explicit answer.

The same goes for the accelerators. IBM says Arm workloads can reach the AI, compression, cryptography, sorting and DPU facilities; what matters is which of them ship, through what guest-visible interface, with which drivers and with what recovery guarantees. And the benchmark that counts is not whether IBM's Arm beats Graviton on a generic test: it is whether acceptable Arm performance creates system-level value that a separate Arm server cannot.

Then, a support matrix. Binary execution is a technical property; production support is a commercial agreement.

The public trail began before the announcement

Press releases describe intent. Development infrastructure eventually describes the machine.

OSINT—open-source intelligence—means drawing careful conclusions from public evidence. Here, the most useful evidence did not appear under the product's name. The first public arm-on-s390 KVM series arrived on April 2, the same day as IBM and Arm's collaboration announcement. Steffen Eiden of IBM posted it under a subject line no marketing department would have chosen—"KVM: s390: Introduce arm64 KVM"—and by August 12 it had reached v6 with 33 patches. Phoronix covered the first revision in April and the second that same month; LWN carried the series too. That is the independent corroboration a claim like this needs.

This chronology proves that a named public development effort existed. It does not prove that the patches were merged, production-ready or identical to the eventual product. A patch series is a proposal under review, not a warranty.

What the 33 patches reveal

The v6 cover letter describes two KVM implementations coexisting on s390 and introduces a second module named kvm-arm64. The series covers Arm VM and vCPU creation and destruction, vCPU ioctls, guest-memory management, page-fault handling, selective reuse of existing Arm KVM code, Arm feature discovery and host/guest register-state handling. It also moves arm64 headers to architecture-independent paths and creates shared code under virt/kvm/arm64/: the kind of refactoring that only makes sense if a second consumer is coming.

At its centre is the SAE instruction, described above.

That is the plumbing needed to create, run and stop an Arm VM. The patches also expose unfinished work: some register handling and related functions are deferred to later series.

A targeted public search on August 27 found no arm-on-s390 series clearly attributable to IBM for QEMU, libvirt or EDK II. That negative result must stay narrow: it says the public kernel backend is visible while the full public userspace and firmware stack is not yet. It does not prove those layers do not exist privately.

The OSINT lesson is reusable

Searching only for "IBM dual-ISA processor" before August 24 would probably have missed the trail. The productive terms were arm-on-s390, KVM_ARM64, kvm-arm64, Start Arm Execution and SAE.

Engineers name a mechanism long before marketing names a product. Search patches for interfaces, configuration symbols, instructions, control structures, device identifiers and machine types. Then verify authorship, dates, revision history and review replies. Corroborate every finding across two independent sources. One unexplained string is a lead, not a roadmap; and finding nothing proves only that the search found nothing.

Watch three places from here: the KVM and linux-s390 archives for later revisions or merge activity, QEMU and libvirt for a machine type and a migration stream, and EDK II plus Arm SystemReady for firmware and compliance evidence.

A kernel ABI, plus a VMM device model, plus firmware, plus a published compliance result, begins to look like a platform. Until then, what exists is a construction site, not a product.

What this could change, and what it cannot

In the Power and AIX estates we work on, the call almost never starts with the processor. It starts with a deployment that has stopped, and the answer is almost always four layers above the silicon: a package that was never built, a container manifest with two entries in it, a security agent whose vendor supports two architectures and has no plans for a third. This is software's last mile: the whole road exists—kernel, compiler, source code—and the final stretch is missing, the binary somebody publishes and supports. That is the problem Arm on Z is aiming at, and it is worth marking off how much of it a processor can reach.

The software industry treats architecture support as a release-engineering afterthought. amd64 and arm64 appear automatically; s390x and ppc64le wait for someone to enable a build, fix a test or add an image manifest. IBM cannot personally port and certify every project, and by adding Arm it gains access to software vendors already build—which is pragmatic and, with the figures above in view, is also the only lever available on the platform's one real growth constraint.

What it does not do is settle the rest. The virtual platform, operating-system support, the security model, accelerator interfaces, lifecycle and commercial commitments still decide whether a customer can depend on the result, and thirty years of history say delivery and support do not settle themselves. Nor will any of it make a badly written application scalable, secure or resilient. It may make that application available next to valuable Z data without creating another infrastructure island, which is a serious achievement, and rather more modest than "the mainframe now runs the Arm ecosystem", which is how this week has told it.

The useful thing to do with an announcement like this is to write down where a real workload actually stops: at the instruction set, at the ABI, at the platform, or at the missing package and the support statement nobody is going to sign. Those specific failures—not the benchmarks—will say whether Arm on Z removes the reason workloads leave.

The question that asks itself

Power users know that last mile first-hand. The kernel supports the architecture. The compiler supports it. The application source is portable. The vendor simply never published the binary.

That is the fact, and it stops here: if a second ISA turns out to be a good idea on Z, the question of whether it would be one on Power asks itself. Asking it seriously—with the history and the numbers on the table—is the job of Part III.