Introduction
New Arm architecture features often arrive before developers have broad access to production hardware. That creates a difficult gap for teams working on operating systems, firmware, hypervisors, toolchains and platform software: support must be developed and tested before suitable silicon is widely accessible.
QEMU helps close that gap by making emerging architectural features available through emulation and virtualization. The second of QEMU’s three planned releases for 2026, QEMU 11.1 expands that capability with support for FP8 arithmetic in Arm’s Scalable Vector Extension and Scalable Matrix Extension, experimental Generic Interrupt Controller version 5 emulation, more accurate modelling of wait-for-event instructions, and several additional improvements across the Arm ecosystem.
Testing FP8 Support for Arm AI Workloads
Smaller floating-point formats can help make increasingly large AI workloads more practical.
AI software developers increasingly need to support reduced-precision arithmetic, but validating that support can be difficult while compatible hardware remains scarce. Compiler developers, operating-system teams and runtime maintainers still need a way to exercise instruction handling, context switching and feature detection before systems using the newest architecture extensions are widely available.
One of the biggest updates to QEMU’s instruction emulation will be support for 8-bit floating-point (FP8) numbers for Arm’s Scalable Matrix Extension (SME) and Scalable Vector Extension (SVE) instruction sets. The implementation covers floating-point arithmetic, conversion, accumulation and scaling instructions, together with fused multiply-accumulate operations commonly used by modern AI inference workloads. Depending on the execution mode, these operations can be applied to vectors through SVE or matrices through SME.
Why use a format with less precision and numerical range than conventional floating point? Many AI workloads can tolerate reduced numerical precision without materially reducing the quality of their results. Smaller values reduce model size and memory-bandwidth requirements, while suitable hardware can perform more operations in parallel. The acceptable trade-off depends on the model and workload, and reduced-precision formats remain an active area of research, including proposed 4-bit and 2-bit formats.
QEMU’s role here is not to run production-scale AI models at competitive performance. It is to let developers validate the surrounding software stack: instruction decoding, architectural feature discovery, operating-system support, context management, exception handling and regression tests. This also makes it possible to add FP8 and SME coverage to continuous integration systems before compatible hardware is broadly available.
These new instructions are available automatically when running the `max` CPU type under Tiny Code Generator (TCG) emulation. Developers can also configure architectural properties such as the nominal SVE vector length to exercise different implementation assumptions.
Developers using Apple silicon M4 or newer systems can also run QEMU guests through Apple’s Hypervisor Framework (HVF), with SME exposed to the guest using support introduced in QEMU 11.0.
Reduced-precision arithmetic is only one example of software arriving alongside new hardware capabilities. Platform infrastructure must also evolve, particularly around interrupt delivery and virtualization.
GICv5
Interrupt-controller support is fundamental to operating-system bring-up and virtualization on Arm systems. The Generic Interrupt Controller (GIC) routes and manages interrupts across processors, devices and virtual machines, making it a critical part of both platform hardware and its supporting software stack. GICv4 evolved from the existing GICv3 design, both of which QEMU has supported through emulation and Kernel-based Virtual Machine (KVM) acceleration for several years. GICv5 is a more substantial redesign intended to address limitations identified in earlier generations.
With 11.1 we now have experimental support for emulation of this interrupt controller by specifying `-M virt,gic-version=x-5`. In QEMU, the x- prefix marks an experimental interface. Its behaviour and command-line syntax may change without following QEMU’s normal deprecation process.
Early emulation support gives firmware, Linux kernel and hypervisor developers a platform on which to begin implementation and testing before GICv5-based systems are widely available. For silicon vendors, this can reduce the amount of software enablement deferred until late-stage hardware bring-up.
The wider GICv5 software stack is also advancing upstream. Linaro engineer Lorenzo Pieralisi contributed the Linux host driver, which has been available since Linux 6.16, while KVM guest support was merged for Linux 7.0. Work is continuing to extend QEMU’s model with virtualization support, Realm security-state support and, eventually, KVM acceleration.
More Accurate Wait-State Modelling with WFET and WFIT
Low-power and event-driven code is difficult to validate when the emulator does not model the architectural state that controls whether a processor waits, resumes or traps into a higher exception level. Simplifying these operations can be sufficient for ordinary guest execution, but it leaves important firmware and hypervisor behaviour untested.
QEMU has historically been permitted to treat wait instructions such as Wait For Event (WFE) as no-operations. Under emulation, this is often adequate because the guest typically resumes after only a small amount of simulated execution. Armv8.7, however, introduced timed variants—WFET and WFIT—along with additional trap behaviour that allows a hypervisor or monitor to control whether the guest may enter a wait state. Supporting this behaviour required QEMU to model the architectural Event Register, including the instructions and Generic Timer event stream capable of setting it.
The goal is not to predict the real-world performance or power consumption of the target system. The benefit is behavioural fidelity: firmware and hypervisor developers can now exercise timeout handling, event delivery and trap paths that previously could not be represented accurately under QEMU’s Arm emulation.
Supporting the Wider Arm Ecosystem
Linaro’s contribution to QEMU extends beyond the code written by its own engineers. As maintainers of substantial parts of QEMU’s Arm support, Linaro engineers review, test, integrate and help refine contributions from companies and developers across the ecosystem. That work is essential to keeping support upstream, interoperable and maintainable. It also helps ensure that features developed by different organizations integrate coherently within QEMU rather than becoming isolated downstream implementations.
For QEMU 11.1, Arm-related work reviewed and integrated through the project’s maintainer trees includes:
- Arm Enhanced Memory Tagging Extension (
FEAT_MTE4) - A new NXP i.MX 8M Mini Evaluation Kit board model
- Nested virtualization through Apple’s Hypervisor Framework
- Platform virtual Generic Interrupt Controller support for HVF
- Command Queue Virtualization (CMDQV) for NVIDIA Tegra 241
Together, these changes support several parts of the Arm ecosystem: silicon vendors preparing software for new processors, operating-system and firmware teams bringing up platforms, virtualization developers validating new execution environments, and product teams seeking to automate testing before target hardware is readily available.
These improvements represent work from contributors across the QEMU community. We would particularly like to thank everyone who contributed to, reviewed or tested Arm support during the QEMU 11.1 development cycle.
Linaro’s Upstream Impact
Contribution volume alone does not capture the full value of upstream engineering, but sign-off data can provide a useful indication of the maintenance and integration work performed during a release. QEMU includes support for the LWN’s Git Datamining Tool (gitdm) contribution-analysis tool, allowing activity to be grouped by employer.
git log --numstat v11.0.0..v11.1.0 | gitdm -n -s -l 10 -z -UEmployers with the most signoffs (total 1814)
Red Hat 625 (34.5%)
Linaro 548 (30.2%)
Western Digital 252 (13.9%)
Qualcomm Technologies, Inc. 92 (5.1%)
IBM 55 (3.0%)
(None) 45 (2.5%)
SUSE 45 (2.5%)
NVIDIA 24 (1.3%)
Samsung 23 (1.3%)
Loongson Technology 22 (1.2%)
Employers with the most hackers (total 264)
Red Hat 29 (11.0%)
IBM 21 (8.0%)
Qualcomm Technologies, Inc. 9 (3.4%)
Linaro 6 (2.3%)
(None) 6 (2.3%)
Samsung 5 (1.9%)
Intel 5 (1.9%)
Huawei 5 (1.9%)
SiFive 5 (1.9%)
Academics (various) 5 (1.9%)The contrast between six identified Linaro contributors and 548 sign-offs illustrates the leverage of upstream maintainership. Linaro engineers are not only developing Arm functionality; they are reviewing, integrating and taking responsibility for a much larger body of work contributed across the ecosystem.
For organizations building Arm platforms, that upstream presence matters. It helps reduce long-lived downstream patch sets, improves collaboration with adjacent projects and gives new features a clearer path into broadly supported releases.
QEMU 11.1 demonstrates how emulation and virtualization can shorten the gap between architectural specification, hardware availability and production-ready software. FP8 instruction support, GICv5 emulation and improved wait-state modelling each allow a different part of the software stack to be developed and validated earlier. Combined with Linaro’s ongoing upstream maintenance work, these changes help the wider Arm ecosystem prepare for new hardware with less dependence on scarce early hardware.
If your organization is enabling new Arm silicon, developing firmware or virtualization software, or building support for hardware that is not yet widely available, Linaro’s upstream QEMU engineers can help. Contact Us to discuss platform modelling, architecture enablement, virtualization support or upstream integration.
About the author
Alex is the Senior Emulation and Virtualisation Tech Lead at Linaro, where he leads the QEMU team. Holding a degree in Chemistry, his software journey began in the 80s home computer era, evolving into decades of hands-on experience across embedded systems, telecom hardware, and open-source software. A long-time Linux practitioner and avid Emacs enthusiast, Alex is always ready to advocate for the “One True Editor.”