On August 24, 2026, IBM unveiled at Hot Chips 2026 a processor design capable of natively executing both Arm's AArch64 and IBM's z/Architecture on each core. Rather than adding a separate Arm-only core, the design extends all 11 cores to support both instruction sets. Historically, Linux on IBM Z has targeted s390x, and the platform's processors were not built to directly handle the widely distributed Arm64 binaries. This new design is an attempt to expand cloud-native and AI software options while preserving the mainframe's hallmark high availability and encryption capabilities.
However, what IBM disclosed is a design still under development for future IBM Z and LinuxONE systems. The company has not revealed a product name or launch timeline, and it explicitly notes that specifications and plans may change or be withdrawn.
Beyond 2nm and 11 Cores: The Shift to Dual-ISA Support
The new processor is designed on a 2nm process node and is planned to run 11 high-performance cores at over 5.7GHz. On-chip, it will also include an AI inference accelerator aimed at detecting fraud during transactions, along with a data processing unit (DPU) to accelerate I/O. IBM states it will adopt a large-cache configuration, though the official announcement does not specify capacity.
Compared to the Telum II, which powers the current IBM z17, the differences are as follows:
| Item | Telum II | New Dual-ISA Design |
|---|---|---|
| Process node | Samsung 5nm | 2nm, manufacturing partner undisclosed |
| High-performance cores | 8 | 11 |
| Announced clock speed | 5.5GHz (base) | Over 5.7GHz |
| CPU instruction sets | z/Architecture | z/Architecture and AArch64 |
| I/O acceleration | On-chip DPU | On-chip DPU |
| AI processing | On-chip AI accelerator | AI inference accelerator |
While core count and clock speed have increased, IBM has not yet disclosed application performance or power consumption figures. Nor does the process node designation imply that performance necessarily scales inversely with the number. Since the AI accelerator and DPU were already present in Telum II, the biggest change distinguishing this generation is the integration of AArch64 into the same cores.
How AArch64 Was Integrated Into the Same Core
According to technical materials presented at Hot Chips, IBM implemented AArch64 v9.3 in hardware, supporting 2,792 instructions including SVE, which extends vector operations. Unlike emulation, which sequentially translates between two instruction sets in software, the cores directly interpret and execute AArch64 instructions.
That said, the core's internals were not duplicated. The branch predictor carries over from the Telum II design, and the main data paths for integer operations and load/store also remain shared across both ISAs. The area that required the most additional silicon to support AArch64 was the instruction decoder. IBM added circuitry for SVE and half-precision floating point (FP16), and for address translation, it built a new mechanism to walk AArch64-specific page tables while still using the existing TLB.
In this design, differences between AArch64 and z/Architecture are absorbed at the instruction-fetch stage, while the downstream execution units and caches are shared as much as possible. This is because operations like addition or memory reads can be routed to the same circuitry even if the instruction representations differ. This approach could make more efficient use of silicon than placing two complete, separate cores side by side. However, since IBM has not disclosed the area or power overhead required for dual-ISA support, it is not yet possible to conclude that this approach is more efficient.
On the Arm side, the execution environment uses KVM-based virtualization, and the cores are said to switch ISA modes at the nanosecond level. "Simultaneous execution" here does not mean a single program mixing AArch64 and z instructions. Rather, it means that Arm-native Linux virtual machines and z/OS or Linux-on-IBM-Z environments can coexist within the same system. Details of the virtualization configuration—such as how core resources are partitioned—have not yet been disclosed.
Why Arm: More Than 22 Million Developers
IBM and Arm state that Arm's software ecosystem includes more than 22 million developers worldwide. This figure refers to the number of developers, not a guarantee that all of that software will run on IBM Z. Still, as cloud and AI software increasingly ship Arm64 as a primary distribution target, welcoming AArch64 into hardware is likely a more efficient way to broaden IBM Z's software reach than porting applications to s390x one by one.
For enterprises running mainframes, this raises the possibility of running Arm64-based analytics tools and AI platforms without sending transaction data out to a separate server. This is also why IBM is working to share existing caching, encryption, and fault-detection mechanisms across both ISAs. Reducing data movement and system separation could simplify operations, but the actual benefits can only be judged once supported software and performance benchmarks are available.
Sharing the same chassis is not the same as eliminating the need for data exchange. It remains undisclosed which memory z/OS transaction processing and Arm virtual machines will share, or what communication paths will connect them. IBM's AI inference accelerator is also primarily framed around fraud detection during transactions, and there is no guarantee that Arm-based AI software will automatically be able to use that circuitry. Turning hardware proximity into a practical advantage will require cooperation at the OS and middleware level.
When the two companies announced their collaboration in April 2026, the effort was described as spanning three directions: extending virtualization technology, adapting the Arm environment to meet enterprise-grade availability and security requirements, and expanding the ecosystem through a shared technology layer. Four months later, IBM has now fleshed out concrete processor specifications. The core development milestone here is the progression from concept to implementation.
Native Support and Product Compatibility Are Different Matters
Even with native AArch64 execution, existing Arm software will not automatically receive unconditional product support. Guest OSes and drivers must be prepared, and hypervisors and management tools must be validated. Middleware licensing and certification to meet IBM Z's availability requirements also remain outstanding issues.
Even if a container image has an Arm64 version, it won't run unless the native extensions it calls internally and any peripheral drivers are also supported. Conversely, even for runtime environments like Java that abstract away CPU differences, the underlying libraries still need to be verified. Additionally, what's being added here is AArch64—no functionality for directly running x86-only binaries has been announced. Not all cloud-oriented software will simply move over to IBM Z as-is.
The fact that IBM simultaneously called on independent software vendors and open-source developers to register their interest at the time of the announcement speaks volumes about the current state of readiness. Registrants are expected to receive information about future testing, validation, and previews, but participation is not guaranteed. The hardware has opened a door for Arm. Turning that into a path that can actually be walked through is work that still lies ahead.
The key indicators for judging eventual productization will be the list of supported Arm guest OSes and certified applications, performance and power consumption when running alongside z environments, and fault-isolation specifications. Availability by region and licensing terms will also be essential. Once these are in place, enterprises will be able to weigh the benefits of running Arm-based software close to critical data against the costs of migration and operation. Whatever software compatibility list IBM releases next will determine whether this dual-ISA approach evolves from a technology showcase into a practical platform.