ARM64 Virtualization Extension (EL2): Practical Engineering Choice for Cloud and Embedded Workloads

Why ARM64 virtualization matters for cloud and embedded workloads

Cloud providers and device manufacturers increasingly need to run multiple isolated operating systems on a single ARM64 processor. Doing so reduces hardware costs, power consumption, and physical footprint, which is especially valuable for edge and IoT deployments. The ARM64 architecture includes a built‑in solution called the Virtualization Extension (EL2) that lets the CPU trap and emulate a guest OS efficiently, enabling a lightweight hypervisor to run directly on the silicon without adding extra chips. This design eliminates the need for dedicated virtualization hardware, lowering total cost of ownership and simplifying system integration for both data‑center VMs and resource‑constrained edge devices.

The problem: optional EL2 support

Not every ARM64 system implements the Virtualization Extension. Some low‑power SoCs, such as those found in wearables or low‑cost routers, omit EL2 entirely. If a developer assumes the feature is present, the hypervisor will fail to initialize, wasting development time. The practical first step is to verify EL2 availability at runtime before writing any hypervisor code.

EL2 architecture and engineering choices

ARM64 defines four execution levels:

• EL0 – user‑mode applications.
• EL1 – the primary operating system (the host).
• EL2 – the hypervisor level where guest OSes are trapped.
• EL3 – a secure world for trusted firmware.

When EL2 is present, the CPU uses separate address spaces and instruction sets for the host and each guest. A VM exit automatically saves the guest’s register state and transfers control to the hypervisor, then restores the state on return, which cuts the overhead of manual context switches. The Hypervisor Call interface (e.g., SVC #0x80) exposes a small, well‑defined set of registers and instructions that OS‑level hypervisors can use, abstracting away vendor‑specific details and simplifying development. Because the interface is part of the architecture, a hypervisor written for one ARM64 SoC can run on another with only minor adjustments, making EL2 a practical engineering choice for heterogeneous environments.

Verification and a minimal test

To confirm that EL2 is available, read the system register ID_AA64ELFR0_EL2. Bit 31 of this register indicates support. On Linux, you can obtain the value via the auxiliary vector (getauxval(AT_HWCAP)) or by parsing /proc/cpuinfo if the register is exposed there. The following table summarizes the relevant bits:

Bit	Meaning
31	EL2 support present
30	EL2 locked
29	EL2 enabled in the current EL

Run the C program shown below to check the register. It must be executed with root privileges or the appropriate capability.

#include 
#include 
#include 

int main(void) {
    // In practice, read the register using an ioctl on /dev/cpu/* or getauxval().
    unsigned long el2 = 0; // placeholder value
    // Assume el2 now holds ID_AA64ELFR0_EL2.
    if (el2 & (1UL << 31)) {
        printf("EL2 supported\n");
    } else {
        printf("EL2 not reported\n");
    }
    return 0;
}

Execute the program. If it prints “EL2 supported”, you can proceed to a simple hypervisor test. A minimal test might consist of executing an SVC instruction that triggers a VM exit and then verifying that the guest’s registers are correctly saved and restored. The risk is that an incorrect hypervisor implementation can crash the host, so always test on a non‑production device first.

Trade‑off, limitation, and actionable next steps

The performance advantage of EL2 depends on how frequently VM exits occur. Workloads that generate many interrupts, such as high‑rate networking or real‑time audio, may see only modest improvements because each interrupt still causes a trap. Moreover, if the SoC does not expose EL2, the hypervisor must fall back to full software emulation, which consumes more CPU cycles and power. To use EL2 effectively, follow these steps:

1. Detect EL2 support on the target hardware (read ID_AA64ELFR0_EL2).
2. If supported, experiment with an existing hypervisor such as KVM, Xen, or a lightweight userspace emulator.
3. Profile your workload’s interrupt latency; if VM‑exit overhead dominates, consider tuning the hypervisor or selecting a different virtualization strategy.
4. Document the detection step in deployment scripts so that systems lacking EL2 gracefully degrade to software‑based virtualization.

By verifying EL2 availability and understanding its trade‑offs, you can make an informed engineering decision about whether to build a custom hypervisor or leverage existing solutions on ARM64 hardware.