ARM64 KVM on s390

This is the most interesting thing happening on s390 in years, and it is the one I would most want to be able to talk about properly. In April 2026 IBM posted a 27-patch RFC to run hardware-accelerated ARM64 virtual machines on an s390 host. It is a collaboration between IBM and Arm, and it is still RFC, so it is a live conversation rather than settled code.

The core idea

Normal KVM on s390 runs s390 guests with the SIE instruction (Start Interpretive Execution). Intercepts come back to the host as SIE exits. The new work adds a companion instruction:

SAE, Start Arm Execution. It takes an ARM64 vCPU state block and hands execution to the chip's ARM engine, which then runs AArch64 code directly. The mapping onto the ARM privilege levels is the part worth memorising:

s390 host kernel        acts as EL2   (the ARM hypervisor level)
   |  SAE instruction
ARM64 guest kernel      runs at EL1
ARM64 guest userspace   runs at EL0

What the 27 patches actually do

Roughly four groups of work:

• Header reorganisation. The ARM64 KVM UAPI headers move from arch/arm64/include/uapi/asm/kvm.h to include/uapi/arch/arm64/ so a non-ARM64 host (s390) can include them without a cross-arch header mess. The kernel-internal headers move to include/kvm/arm64/ similarly.
• A common KVM layer. Shared infrastructure between s390 and arm64 so they can manage guest state without duplicating it.
• s390 SAE integration. New code in arch/s390/kvm/ to set up ARM64 vCPU state blocks, issue SAE, handle the ARM64-style intercepts coming back, and translate the ARM interrupt model to the s390 host.
• ARM64 KVM changes. The ARM64 KVM code is refactored so some of its logic can be called from a non-ARM64 host context.

Why anyone wants this

IBM Z sits in banks, governments and telcos, and a lot of what those places want to run now is ARM64 cloud-native and edge work. This lets them run ARM64 workloads directly on the mainframe they already own, without standing up a separate ARM fleet. IBM announced a "dual architecture" collaboration with Arm around the same time.

The actual blocker is not technical

The Arm maintainers welcomed the patches but raised fair concerns. The ARM64 KVM code was never designed to be driven from another architecture's host, so refactoring it risks subtle regressions on native ARM64. There is also the plain governance question of who owns bugs that land on the ARM64 and s390 boundary. The plan was for IBM and Arm people to thrash this out in person at the Linux Storage, FS, MM and BPF Summit in Croatia in May 2026. I would expect at least one or two more RFC revisions before any of it merges.

The thing I keep coming back to is that the header move is the quietly significant bit. It is the first time ARM64 KVM UAPI has been made consumable by a non-ARM64 host, which nudges KVM toward a more architecture-neutral shape. That is a bigger shift than one platform feature.

Watching the thread

• LWN: KVM: s390: Introduce arm64 KVM (the review discussion)
• Phoronix v1 coverage and v2 coverage
• On lore, search for KVM: s390: Introduce arm64 KVM

Next week I am switching gears to the thing I most need to actually build into a habit: Rust.

← the lay of the land (s390) all posts next: upskilling toward kernel rust →