IBM already tried this in 1994.Its next mainframe will run ARM alongside z/Architecture. One core speaking two architectures: the idea is thirty years old, and history explains why the chip is the easy part.
Every core of the future mainframe processor will execute ARM and z/Architecture. It is a feat of engineering, and it solves one of the four problems standing between a foreign binary and production.
IBM Z is learning ARM
The audio version of this article.
IBM has just announced one of the strangest enterprise processors in years, and what stands out is not the engineering but what it leaves unsolved. According to the August 24 announcement, IBM is designing a future processor for IBM Z and LinuxONE in which every physical core can natively execute both ARM and IBM Z instruction streams concurrently: two different architectures inside the same silicon, with no emulation in between.
In plain English, an instruction set architecture, or ISA, is the language and rulebook through which software gives orders to the processor, and ARM and IBM's z/Architecture are two different languages. What IBM wants is for every core to understand both directly, as first-class execution modes, and not as a small ARM bolted onto the mainframe cores nor as emulation dressed up as something else.
And yet, putting two languages in one core is the easy part. Buying a Japanese dictionary does not make you someone who can argue a case before a court in Tokyo, and a multi-architecture processor is no different: executing the instructions is only the first of the four contracts that a foreign binary has to close before it reaches production. When a vendor shows off a multi-architecture chip, it has almost always solved only that first one, which is a quarter of the problem.
That is why the interesting question goes beyond whether this will work: IBM has spent decades building this kind of silicon, so that much is a safe bet. The underlying question shows up the moment you pull on the why:
If adding another ISA fixes compatibility, why stop at two? Why not x86, RISC-V, Power ISA—or every language software still speaks?
And if you pull on that thread, the announcement stops being a processor story and becomes a map of what hardware can solve, what remains the ecosystem's job, and why an application can still be unavailable even when the kernel, the compiler and the source code have been waiting years for it.
The 90-second version
You do not need to design processors to follow this story. Seven terms give you almost everything you need to follow it.
The instruction vocabulary and the behaviour promised to software
ARM and z/Architecture are different ISAs
A program already compiled for a specific ISA and operating environment
An ARM binary does not turn itself into an x86, Power or Z binary
The processor implements the ISA it exposes to software
It avoids instruction-by-instruction translation, but guarantees neither operating-system nor application support
An isolated, simulated computer that the hypervisor presents to software
IBM expects ARM Linux environments to coexist with established Z workloads through virtualization
The host is the physical machine and its operating system; the guest is each system running inside, isolated, as if it had its own computer
The ARM Linux in the announcement runs as a guest on the Z host
A virtual processor that the host schedules for a VM
An ARM VM may have several vCPUs and is not permanently tied to one hardware thread
KVM is Linux's virtualization framework; SAE stands for Start ARM Execution
KVM manages the ARM guest; SAE is the hardware doorway into ARM execution
IBM is solving the instruction problem in silicon and much of the virtualization path in Linux. The finished platform still needs firmware, virtual devices, migration and distribution support.
That gap between can execute and can operate in production is what the rest of this article is about.
Not here for the history? The section "We have tried to escape architecture before" is context, not a prerequisite: if you are in a hurry, skip it and go straight to "Why put ARM in hardware now?".
A guide, in case a word trips you up
What an ISA is, what an ABI is, and why it is so hard to run a program on another architecture: a twelve-page notebook explains it from scratch, with ten historical case files and the source for each. You do not need it to follow the article; it is here if you want the full ground.
Download "Running someone else's code" PDF · 12 pagesWhat IBM gets thoroughly right
Very few companies can combine a processor running at over 5.7 GHz with huge caches, memory and I/O at scale, inline fault detection, secure key management, cryptography and AI acceleration. And then put it inside a machine expected to stay available under workloads that would flatten an ordinary server.
Then, a few layers above all that engineering, a deployment fails because an installation script says, in essence:
if architecture == amd64 or architecture == arm64:
continue
else:
exit("unsupported architecture")Years of processor, firmware and operating-system work have just been defeated by a two-item array.
There is something magnificently IBM about answering "we need more binaries" by redesigning the mainframe processor. But the contrast marks the limit: hardware can make a binary executable; it cannot make a vendor compile, test, sign and support it.
What IBM is aiming for with this announcement
IBM's statement describes an 11-core processor built on a 2 nm process in which every core is ready to run both ARM and IBM Z instructions, and on that basis IBM expects ARM-native Linux to run alongside z/OS and Linux on IBM Z. The design also includes AI inference acceleration and an on-chip data processing unit—DPU—integrated into the chip itself. And in case there were any doubt about the intent, IBM and ARM present access to ARM's software ecosystem as the central, stated objective of the whole design.
There is more preliminary detail, and those figures hint at more than they say. The target of the ARM implementation is AArch64 v9.3 with SVE and SVE2 vector extensions, and either of the core's two threads can run either ISA with mode changes IBM puts in the nanosecond range. And most important: IBM's preliminary presentations point to the design reusing much of the Z execution engine to run ARM—prediction, caches, page tables—though the final design is not public. That is where the design's efficiency lives, and also the verification frontier (the limit of what has been verified): the more ARM and Z share the same engine, the more must be proven that one mode does not contaminate the other.
AI, cryptography and the DPU are also presented as available to the ARM environment. What counts is the driver that exposes the accelerator to the guest system (the ARM Linux running inside), well ahead of the megabytes of cache: an accelerator that is "available" only counts when that driver exists—and about that the announcement says nothing.
This is meant to be a platform, with product ambition. But it is conference evidence, not a product specification: IBM has announced a design direction and warns that its plans may change or be withdrawn. What the announcement establishes is what IBM intends to build—not how it will present itself to the systems running inside, the security policy, the migration contract, the performance, the supported operating systems or the catalogue of independent software vendors (ISVs). "An accelerator is available to ARM" becomes useful only when a driver, a library, an error model and a support statement make it real.
years without a single compatibility layer persuading a vendor to sign a support contract.
Not one exception in thirty yearsThe five meanings of "it runs ARM"
IBM describes ARM execution as native, and the word is doing useful work: it means the processor implements the ARM architecture instead of asking an emulator to translate every ARM instruction into Z instructions.
It does not mean every ARM program will run unchanged. It does not promise the performance of a dedicated ARM server processor, support for every optional ARM extension or automatic access to every Z facility. And it certainly does not generate certifications from Red Hat, Canonical, SUSE or commercial ISVs.
Modern CPUs already turn visible architectural instructions into smaller internal operations. "Native" describes the contract exposed to software and takes for granted all the machinery working behind the curtain. IBM's design appears to extend that principle across two public architectures: shared prediction, arithmetic and load/store machinery where possible; separate architectural state where the contracts diverge.
This matters because running foreign software is not one problem. It is five, and marketing language tends to compress them into a single word, though each one acts on a different layer of the stack.
Native multi-ISA execution is the core IBM has announced. User-mode translation is Rosetta 2, Prism, FX!32 and PowerVM Lx86. Full-system emulation is QEMU. ABI compatibility—the ABI is the lowest-level contract between a compiled program and the system: how libraries are called, how parameters are passed—is FreeBSD's Linuxulator. Multi-architecture packaging is an OCI image index or an Apple Universal binary. They are not variations on one idea: each stops at a different layer, and that boundary decides which applications work, how fast they run, and who gets the support ticket when they fail.
FreeBSD offers the cleanest explanation
FreeBSD runs many unmodified Linux binaries through an optional compatibility layer called the Linuxulator. The FreeBSD Handbook documents x86 and AArch64 support, and the linux(4) manual page describes a real implementation of the Linux ABI—an operating-system layer that leaves the CPU emulator entirely to one side.
The host processor still has to understand the binary's ISA, so on an x86 machine it is the x86 hardware that executes the instructions while FreeBSD handles the Linux-style system calls, and on an ARM machine exactly the same happens with ARM Linux binaries. What Linuxulator never does is quietly translate x86 into ARM.
Hence the first rule of this story:
Understanding the instructions is not the same as understanding the operating system.
Four contracts, not one
So much for the five ways to run ARM. But running is only the first of a different list: the four contracts a binary must close to reach production. The confusion in this whole field consists of believing that settling the first one settles all four.
IBM's processor tackles the first contract. The v6 arm-on-s390 KVM series sketches much of the kernel-level route to an ARM VM. Linux, the firmware and the virtual-machine monitor still have to complete the platform. Distributions and ISVs still have to complete delivery and support.
A platform can be brilliant at the first contract and commercially disappointing at the fourth.
We have tried to escape architecture before
IBM's design is unusual, but the dream behind it is an old one: preserve the software investment while the machine underneath changes.
Thirty years of attempts have left a pattern, and it surprises almost everyone.
A processor can speak two languages and still have no audience
In the 1990s, IBM reportedly developed a prototype known as the PowerPC 615, capable of executing x86 as well as 32-bit and 64-bit PowerPC. It is, almost exactly, the idea IBM has just announced for Z and ARM—thirty years earlier. The most detailed surviving account is a 1998 report, based on an anonymous IBM engineer; a 1995 sidebar also discussed the never-released device through anonymous sources.
The later account claimed that Minix and a development version of OS/2 demonstrated mixed execution, but that the project lacked a profitable path and could not secure the Windows support it needed. That is an insider's testimony, not established corporate history. What is documented is that Microsoft ended Windows NT development for PowerPC in 1997, citing declining demand.
The lesson does not depend on the disputed details. The silicon worked; the fourth contract was never signed.
Translation works best when it knows where the bridge ends
DIGITAL ran into the same catalogue problem with Alpha, and answered it with the most elegant engineering in this entire history. FX!32 did not translate x86 code in one pass. The first time you ran an application it was emulated, while FX!32 recorded a profile of the paths the program actually took. Afterwards, in the background, it translated only the most frequently used code paths into native Alpha code and cached the result. Every launch was faster than the last.
DEC reported that translated applications on a 500 MHz Alpha could perform comparably with native x86 versions on a 200 MHz Pentium Pro. For 1997, that was extraordinary. Kernel code and drivers stayed outside the model, and results depended on the workload.
Alpha died anyway.
IBM later took a similar route with PowerVM Lx86, translating 32-bit x86 Linux applications on Power and caching the translated code. It solved the problem Part III of this series describes: the catalogue of software nobody compiles for Power. It worked for utilities, installers and modest applications, and broke on direct hardware access, kernel modules and code that processes large amounts of data in parallel (SIMD). IBM's own advice at the time is still the right advice: use translation for less critical software, rebuild natively where the platform demands it. Lx86 was eventually withdrawn.
The technology behind Lx86 was QuickTransit, from a British company called Transitive: the same one Apple licensed for the first Rosetta, the one that translated PowerPC applications onto Intel Macs. The same software, running in opposite directions, for the two companies in this story. IBM bought Transitive in 2008.
Apple's Rosetta 2 is the finest binary translator anyone has shipped: good enough that most users never noticed it was running. Why did it work for Apple and for nobody else? Because Apple controls the chip, the operating system, the application format, the tools, the store and the calendar. It could say "in two years this ends, port your software," and everyone ported. Even so, it remains available through macOS 27, and in macOS 28 it narrows to selected older games. The best translator in history was designed with an expiry date.
Microsoft's Prism is technically accomplished and lacks the one thing that made Rosetta work: Microsoft cannot impose a deadline on thirty years of third-party Windows applications. And the old boundary is exactly where it always was: kernel drivers must be native Arm64.
The universal processor already exists, and it is software
IBM Research's DAISY project asked the most radical question in the field: what if the real processor were an internal VLIW engine (which bundles several operations into one instruction), and every ISA—ESA/390, RS/6000, AS/400, Java—were dynamically translated onto it? Transmeta eventually shipped a version of that idea. Crusoe exposed a perfectly ordinary x86 while its Code Morphing Software translated it for a hidden VLIW core, and it failed twice over: performance was irregular because it depended on how much had already been translated, and Intel simply lowered the power consumption of its own chips.
Intel's IA-32 Execution Layer is the case that runs in the opposite direction, and almost nobody cites it. Itanium carried x86 compatibility in hardware, and it disappointed. Intel replaced it with a software translation layer that turned out to be faster than the dedicated silicon, and later removed the x86 hardware from the processor altogether. Putting compatibility in silicon does not automatically make it better. It makes it harder to fix.
QEMU never promised speed. It promised universality: whole machines or foreign user-space processes, privileged state and devices included, translated in blocks by the Tiny Code Generator. First released in 2003, it is still here, after every commercial product on this list has shut down.
Six patterns from thirty years
Six things recur across every case above.
- Translation dies when the incentive dies, not when the technique fails. FX!32 was excellent and Alpha died. Rosetta 2 is excellent and Apple has already announced its end. Lx86 worked and IBM withdrew it. In none of these cases was the cause of death "we could not make it work".
- Whoever controls the calendar wins. Apple could tell an entire ecosystem it had two years. That power, far more than the quality of the translator, is what separates Rosetta from every other attempt on this list. Microsoft cannot say it to thirty years of Windows software. Neither can IBM say it to its ISVs.
- A bridge is not an address. Every case that worked was a transition with an announced end; the ones that tried to be permanent—Transmeta, Lx86—did not survive.
- The kernel is always the boundary: FX!32, Lx86 and Prism all stop at drivers and kernel code, a barrier without a single exception in thirty years.
- Hardware buys predictability and software buys flexibility, and the trade is not obvious in advance. Itanium put x86 in silicon and a software layer beat it.
- Delivery and support has never once been settled by any of them. In thirty years, no compatibility layer has persuaded a software vendor to sign a support contract. That is the contract that decides whether a platform is usable, and it is the only one on the list that hardware cannot touch.
The real verdict is more nuanced than "translation failed" or "hardware won":
Use native execution where performance, privilege and long support horizons justify it. Use translation as a bridge. Never confuse either mechanism with an ecosystem commitment.
percent: how far IBM Z revenue fell two quarters after rising 67%.
Sold by generationWhy 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, translation lookaside buffer (TLB) behaviour—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 systems with standard hardware discovery (ACPI) and a SystemReady Devicetree Band for embedded environments (Devicetree). ARM also maintains SystemReady VE self-declarations for virtual environments.
IBM claimed SystemReady compliance, but stopping at a generic "does it comply?" gets you nowhere: you have to ask IBM for the specific band that applies, the requirements version, the VE self-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 box behind a cupboard.
It sounds inclusive. It would also be a permanent silicon museum.
Every ISA brings far more than a decoder: registers, exceptions, privilege behaviour and memory-ordering rules, among others. And with all that baggage, each one becomes another validation, security, licensing and long-term support obligation. As if that were not enough, old architectures do not even stay 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's the engineering answer. The commercial one—why now and why ARM—is read in IBM's balance sheet.
The other half is a balance sheet
The technical fit justifies a second ISA, but the choice of ARM and of this moment answers to IBM's revenue structure.
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—48.4% at constant currency—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 for a business that sells by generation the second seems the more honest, though IBM has an obvious interest in defending that reading.
Meanwhile the installed base is healthy and growing inward—more capacity at the customers already there, not new customers. According to IBM, 85% of z16 customers maintained or expanded capacity and around 70% of mainframe customers are growing their installed capacity (measured in 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 build for s390x (the mainframe architecture), 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 works as a defensive move more than a hunt for new customers: it removes 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 the most obvious candidate is, surprisingly, the one left out.
The option that looked ideal
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; the public record is enough to see why x86 is another story.
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 unknown, rather than at what the public record has already answered.
IBM says Z and ARM run concurrently; coverage says a thread can use either ISA
Can sibling threads on the same core run different ISAs under every supported policy, and how are they placed, isolated and billed?
The public v6 kvm-arm64 series proposes VM/vCPU creation, memory handling and SAE entry
What completes the firmware, virtual devices, migration, QEMU/libvirt and orchestration?
Coverage describes AArch64 v9.3, SVE/SVE2 and feature discovery
Which guest-visible profile stays stable across machines and generations?
Prediction, arithmetic, load/store, caches and TLB structures are substantially reused
How are security domains isolated, and how do mixed workloads get predictable service?
Nothing public
How do ARM guests sit alongside the partitioning a customer already uses (PR/SM, z/VM)?
Nothing public beyond the kernel series
Who writes and maintains the ARM guest's device model, and for how long?
The stated target is ARM-native Linux
Which distributions, versions, images, ISVs and accelerators are supported?
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 sibling threads on the same core (SMT) 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 keeps a VM decoupled from any single 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 extending the most heavily exercised virtualization mechanism it owns to a second architecture, rather than opening a new doorway into guest execution. 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 design points to substantial reuse of prediction, cache, TLB and execution units, though no final specification is public. The questions that follow are concrete: how, when the architecture changes, the internal tables and caches that speed up the CPU (TLB, prefetchers, branch predictors) get cleared, so that one workload cannot spy on the one beside it through the traces it leaves in that shared hardware (a side-channel attack); how performance counters, tracing and debug are measured; and whether placing unlike ISAs on sibling threads worsens that risk. 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 features; 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 measures whether acceptable ARM performance creates system-level value that a separate ARM server cannot, rather than whether IBM's ARM beats Graviton on a generic test.
Then, a support matrix. Binary execution is a technical property; production support is a commercial agreement.
The clues IBM left 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. The series was followed publicly from its first revision to the second that same month, and was recorded independently. That is the 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 that still has to prove itself.
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, control calls (ioctls) for the vCPUs, 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. An unexplained string points to a lead without yet drawing a roadmap.
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 still a construction site on its way to becoming 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 security agent whose vendor supports two architectures and has no plans for a third. The software is one step from existing for that architecture—the kernel, the compiler and the source already support it—and the one missing step is precisely that: someone publishing the binary and committing to maintain it. 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 secondary detail of the publishing process. amd64 and arm64 appear automatically; s390x and ppc64le (the Power architecture) 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 that 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 and commercial commitments still decide whether a customer can depend on the result. What it does achieve is putting that software next to Z's data without standing up another infrastructure island: a real gain, and rather more modest than "the mainframe now runs the ARM ecosystem", which is how this week has told it.
What is worth noting is 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, more than the benchmarks, will say whether ARM on Z removes the reason workloads leave.
The question that remains: what about Power?
Power users know this problem first-hand: the architecture is supported top to bottom and, even so, the vendor never publishes the binary.
If a second ISA turns out to be a good idea on Z, it is hard not to ask the same about Power. Asking it seriously—with the history and the numbers on the table—is the job of Part III. First, in a few weeks, comes Part II: the announcement dissected from the public kernel trail.
days between the last public patch and the day the product got a name.
A trail open since AprilIBM showed its hand months early
Before the official press release, IBM was already pushing the map of what it meant to sell into Linux—in the open, signed with a name. In Part II we reconstruct it patch by patch: what SAE is, why its shape betrays thirty years of lineage, and what can be claimed (and what cannot) about the product from what IBM left public.
Read Part IIWhat about your platform?
If any of this sounds familiar—the package nobody compiles for your architecture, the security agent that supports two platforms and not yours, the deployment stuck four layers above the processor—that is exactly the fourth contract this article is about. And it is where we spend our days: Power, AIX, IBM i and Linux on IBM systems. Tell us about it and we will take a look.
Official training and services for IBM systems · sixe.euBlog!
Our mission
SIXE ensures that your infrastructures based on IBM®, Red Hat®, Canonical®, and SUSE® technologies remain stable, secure, and optimized for as long as you need them.
At SIXE, we are committed to sustainability. That’s why we help you design, implement, and maintain durable and efficient technological solutions.
