IBM’s Quiet Bet: Building Hardware That Runs x86 and Z Architecture Simultaneously

Somewhere inside IBM’s sprawling research apparatus, engineers are working on something that would have seemed improbable a decade ago: a single piece of hardware capable of executing both x86 and IBM Z (s390x) instruction sets natively. Not through emulation. Not through virtualization layers. Through actual dual-architecture silicon.

A recently surfaced patent filing and associated Linux kernel patch series reveal that IBM is actively developing what it calls “dual-architecture hardware” — a system where processors can switch between x86 and s390x execution modes. The implications for IBM’s mainframe business, its cloud strategy, and the broader server market are significant and far-reaching.

What the Kernel Patches Reveal

The technical details first emerged through a patch series submitted to the Linux kernel mailing list, as reported by Phoronix. The patches introduce support for what IBM describes as a system where “both x86 and s390x environments coexist on the same hardware.” This isn’t a software translation layer like Apple’s Rosetta 2 or the various x86-on-ARM compatibility tools that have proliferated in recent years. The hardware itself would be capable of running both instruction sets.

The patch series, authored by IBM engineer Claudio Imbrenda, adds infrastructure to KVM (Kernel-based Virtual Machine) that allows the hypervisor to manage virtual machines running either architecture on the same physical host. A guest VM could run native x86 code on the same machine that’s simultaneously running native s390x workloads. Each architecture gets its own execution context, its own register state, its own memory management — but they share the same underlying physical resources.

That’s a deeply unusual approach.

Modern processors are generally designed around a single instruction set architecture. Intel and AMD build x86. IBM builds POWER and Z. ARM licensees build ARM. The idea of a single chip fluently speaking two radically different ISA dialects represents a substantial engineering challenge. The x86 and s390x architectures differ in endianness, register conventions, memory models, privilege levels, and interrupt handling. Bridging those differences in hardware rather than software is ambitious, to put it mildly.

The kernel patches themselves are pragmatic and focused. They add a new KVM capability flag that advertises dual-architecture support to userspace, introduce mechanisms for switching between architecture contexts, and handle the complex bookkeeping required when two fundamentally different ISAs share the same memory subsystem. The code is real. It compiles. It has been submitted for upstream review.

IBM has not issued any public announcement about the project. The company declined to comment beyond what’s available in the public patch submissions. But the code speaks clearly enough on its own.

Why This Matters for IBM’s Mainframe Future

To understand why IBM would pursue this, you need to understand the economic gravity of the mainframe business. IBM’s Z series mainframes remain enormously profitable. They process an estimated 68% of the world’s production IT workloads by transaction volume, according to IBM’s own figures. Banks, insurers, airlines, and governments depend on them. The hardware is reliable to an almost absurd degree — measured availability often exceeds 99.999%.

But mainframes have a problem. A talent problem.

The pool of developers who know COBOL, who understand z/OS, who can write and maintain s390x-native applications, is shrinking every year. Universities don’t teach mainframe programming the way they once did. New graduates learn x86 Linux, containerized microservices, Python, and cloud-native development patterns. IBM has spent years trying to modernize the Z platform — adding Linux support, enabling containers through zCX, integrating with hybrid cloud tooling via Red Hat OpenShift. But the fundamental challenge remains: convincing organizations that new workloads belong on the mainframe when their developers think exclusively in x86 terms.

Dual-architecture hardware attacks this problem at the root. If a Z system can run x86 workloads natively alongside traditional s390x applications, the talent barrier drops dramatically. Organizations could deploy modern x86 Linux applications on the same machine that runs their core banking COBOL systems. No recompilation. No porting. No architectural translation overhead.

And the consolidation story becomes compelling. Instead of maintaining separate x86 server farms and mainframe installations, enterprises could theoretically run everything on a single, highly available, centrally managed platform. IBM’s legendary mainframe RAS (reliability, availability, serviceability) features would extend to x86 workloads that previously ran on commodity servers with far less resilience.

There’s a defensive angle too. Cloud providers — AWS, Microsoft Azure, Google Cloud — have been steadily pulling workloads off mainframes for years. IBM’s own hybrid cloud strategy through Red Hat acknowledges this reality. But if mainframes could natively absorb x86 workloads rather than just coexist with them, IBM gains a powerful counter-narrative: don’t migrate off the mainframe, migrate your x86 workloads onto it.

The competitive dynamics here are fascinating. For years, the x86 world and the mainframe world have existed in parallel, occasionally overlapping but fundamentally separate. This dual-architecture approach could collapse that separation entirely.

Some technical observers have drawn comparisons to Intel’s abandoned Itanium architecture, which included x86 compatibility modes that were widely criticized for poor performance. But that comparison may not hold. Itanium attempted to replace x86 with a fundamentally different VLIW architecture while maintaining backward compatibility as an afterthought. IBM’s approach appears different — treating both architectures as first-class citizens with native execution capabilities.

Others have pointed to the Transmeta Crusoe processor from the early 2000s, which used code morphing software to translate x86 instructions into its native VLIW format. Again, not quite analogous. IBM’s dual-architecture concept implies hardware-level support for both ISAs, not a software translation layer.

The closest historical parallel might be the IBM System/370 Model 168-3, which could run both System/370 and System/360 code natively. IBM has done this before, within its own architectural family. Extending the concept across two entirely different architectural lineages — one CISC (x86), one with its own unique heritage (s390x) — is a different order of magnitude in complexity.

The patent filings associated with this work, referenced in the kernel patch documentation, suggest IBM has been thinking about this for years. Patents describe mechanisms for architectural context switching, shared memory coherency between ISA domains, and unified I/O handling. The depth of the intellectual property portfolio implies this isn’t a skunkworks experiment. It’s a strategic initiative.

How would this actually work in silicon? The patches don’t reveal the microarchitectural details, and IBM certainly isn’t sharing them. But several possibilities exist. The processor could contain separate execution units for each ISA, sharing a common cache hierarchy and memory controller. It could use a unified execution engine with front-end decode stages for both instruction formats. Or it could employ a more exotic approach — perhaps a reconfigurable core that morphs between architectural modes.

Each approach has tradeoffs. Separate execution units would be the most straightforward but would consume significant die area. A unified engine would be more efficient but fantastically complex to design and verify. Reconfigurable logic sits somewhere in between. Without more disclosure from IBM, the specific implementation remains speculative.

What isn’t speculative is the software support. The kernel patches are concrete, public, and under active development. KVM already supports multiple architectures — x86, ARM, s390x, POWER — but always one per host. The dual-architecture patches fundamentally change that assumption, allowing a single KVM host to manage guests of different architectures simultaneously on hardware that can execute both natively.

The implications for cloud infrastructure are considerable. IBM Cloud could offer instances that mix x86 and s390x workloads on shared physical infrastructure, potentially improving utilization and reducing costs. Enterprises running hybrid environments could consolidate their server footprint. And IBM’s Red Hat division could offer OpenShift clusters that span both architectures on a single machine, with pods running native code regardless of their target ISA.

So where does this stand in terms of timeline? The kernel patches are in early stages — RFC (Request for Comments) rather than formal submission for inclusion. That typically means the code works but isn’t considered production-ready. Hardware availability is unclear. IBM could be testing on FPGA prototypes, simulation environments, or early silicon. The gap between kernel patches appearing and actual product availability could be anywhere from one to five years, based on historical precedent with IBM’s Z development cycles.

But the signal is unmistakable. IBM is investing serious engineering resources into dual-architecture hardware. The kernel work is being done in the open, which means IBM intends this to be part of mainline Linux, not a proprietary fork. And the strategic logic — protecting the mainframe franchise while expanding its addressable market — is sound.

Wall Street should pay attention. IBM’s Infrastructure segment, which includes Z systems, generated $3.4 billion in revenue in Q1 2025. The mainframe business follows a cyclical pattern tied to new hardware releases, but the long-term trend depends on IBM’s ability to keep mainframes relevant as the center of gravity in enterprise computing shifts. Dual-architecture hardware could be the most significant evolution of the Z platform since the introduction of Linux on Z in the early 2000s.

For enterprise IT leaders, the message is different but equally important. If this technology reaches production, the calculus around mainframe investment changes substantially. The traditional objection — “we can’t find people who know how to develop for Z” — loses much of its force when Z can run the same x86 binaries as your commodity servers.

Not everyone is convinced. Critics point out that running x86 workloads on mainframe hardware, even natively, doesn’t necessarily make economic sense if the per-core licensing costs of mainframe infrastructure dwarf those of commodity x86 servers. IBM’s pricing model would need to accommodate mixed workloads in a way that doesn’t penalize customers for consolidation.

And there are questions about performance. Even with native execution, will x86 code on dual-architecture IBM hardware match the performance of the same code on a modern AMD EPYC or Intel Xeon? Memory latency, cache behavior, branch prediction, and dozens of other microarchitectural factors could differ. Native execution eliminates the translation penalty, but it doesn’t guarantee parity.

These are real concerns. But they’re also solvable engineering and business problems, not fundamental barriers. IBM has decades of experience optimizing workload performance on its platforms and structuring pricing to match customer needs.

The bigger picture is strategic. IBM is attempting to dissolve the architectural boundary that has defined enterprise computing for decades. Mainframes on one side, x86 commodity servers on the other, with workloads allocated based on tradition, talent availability, and inertia as much as technical merit. Dual-architecture hardware doesn’t just blur that line. It erases it.

Whether IBM can execute on this vision — in silicon, in software, and in the market — remains to be seen. But the ambition is clear, the engineering is underway, and the patches are public. Something real is being built.