Unlocking ARMv8‑A: How Stage‑2 Translation Powers Secure Virtualization

1 Overview

This article describes ARMv8‑A AArch64 virtualization support, including Stage 2 page‑table translation, virtual exceptions, and traps. It introduces basic hardware‑assisted virtualization theory and examples of how hypervisors use these features, without detailing any specific hypervisor implementation.

1.1 Introduction to Virtualization

We first present fundamental hypervisor and virtualization concepts. A hypervisor is defined as software that creates, manages, and schedules virtual machines (VMs). Readers already familiar with these concepts may skip this section.

Why Virtualization Matters

Virtualization is widely used in modern cloud computing and enterprise infrastructure. Developers run multiple operating systems on a single hardware platform to develop and test software without risking the host environment. It provides isolation, high availability, load balancing, and sandboxing for servers.

Isolation : Virtual machines on the same physical core are isolated, allowing untrusted workloads to share hardware safely.

High Availability : Workloads can be migrated transparently between physical machines for maintenance or failure recovery.

Load Balancing : Efficient resource utilization reduces hardware and power costs.

Sandbox : VMs act as sandboxes, protecting the host from buggy or malicious software.

1.2 Two Types of Hypervisors

Hypervisors are classified as Type 1 (bare‑metal) or Type 2 (hosted). Type 2 runs on a host OS that has full control of the hardware. Figure 1 shows a Type 2 hypervisor (e.g., VirtualBox or VMware Workstation).

Type 1 hypervisors run directly on hardware without a host OS, managing physical resources and guest operating systems. Figure 2 illustrates a Type 1 hypervisor (e.g., Xen).

1.3 Full Virtualization vs. Paravirtualization

Full virtualization simulates real hardware completely, which can be slow. Paravirtualization modifies the guest OS to be aware it runs in a VM, allowing better I/O performance. Modern ARM architectures provide hardware assistance, reducing the need for paravirtualization except for some I/O devices (e.g., virtio, Xen PV Bus).

1.4 Virtual Machines (VM) and Virtual CPUs (vCPU)

VMs and vCPUs are distinct: memory pages are allocated to a VM, and all its vCPUs can access them. Virtual interrupts target a specific vCPU. Figure 3 shows the relationship between VMs and vCPUs.

2 AArch64 Virtualization

In ARMv8, the hypervisor runs at Exception Level 2 (EL2). Only software executing at EL2 or higher can access and configure virtualization features.

Stage 2 Translation

EL1/0 Instruction and Register Access

Injecting Virtual Exceptions

Figure 4 shows the exception levels and software execution in secure and non‑secure states.

2.1 Stage 2 Translation

What Is Stage 2 Translation?

Stage 2 translation lets the hypervisor control a VM’s memory view, deciding which physical memory a VM can access and where it appears in the VM’s address space. This requires a Stage 2 page table, distinct from the Stage 1 tables managed by the OS. The intermediate physical address (IPA) is the term used for the VM‑view physical address. Figure 5 illustrates the VA → IPA → PA translation chain.

VMID

Each VM receives a VMID stored in VTTBR_EL2, which can be 8 or 16 bits (16‑bit VMID introduced in Armv8.1‑A). VMID tags TLB entries so multiple VMs can share a TLB.

VMID vs. ASID

ASID tags TLB entries for applications; VMID serves a similar purpose for VMs, often used together.

Attribute Merging and Overriding

Stage 1 and Stage 2 mappings each have attributes (memory type, access permissions). The MMU merges them, choosing the more restrictive attribute. Figure 6 shows an example where the Device attribute overrides Normal.

Registers HCR_EL2.CD, HCR_EL2.DC, and HCR_EL2.FWB can control attribute handling.

Simulating MMIO

The VM’s IPA address space contains memory and peripheral regions. Figure 7 shows MMIO simulation, where virtual devices are fully emulated by the hypervisor.

Physical devices can be passed through (direct mapping) or virtualized (faulted Stage 2 entry). The hypervisor uses registers HPFAR_EL2 and ESR_EL2 to obtain faulting IPA addresses and exception details for emulation (Figure 9).

System Memory Management Units (SMMUs)

DMA controllers also need Stage 2 protection. Without virtualization, DMA sees physical addresses directly (Figure 10). With virtualization, the hypervisor configures an SMMU (Arm’s IOMMU) so DMA sees the same address space as the kernel (Figure 12).

2.2 Instruction Trapping and Emulation

Hypervisors may trap privileged instructions (e.g., WFI) to emulate them at EL2, preventing VMs from directly affecting hardware state.

2.3 Register Access Trapping

Registers such as ID_AA64MMFR0_EL1 can be trapped and presented with virtual values. Frequently accessed registers (MIDR_EL1, MPIDR_EL1) have non‑trapping aliases VPIDR_EL2 and VMPIDR_EL2 to reduce overhead.

2.4 Virtual Exception Handling

Virtual interrupts (vIRQs, vFIQs, vSErrors) are delivered to VMs only when running at EL0/1. Hypervisors configure HCR_EL2 bits (IMO, FMO, AMO) to route physical interrupts to EL2 and virtual interrupts to EL1.

Enabling Virtual Interrupts

Setting HCR_EL2.IMO enables vIRQ routing; similar bits exist for vFIQ and vSError. The GIC can deliver virtual interrupts directly to VMs without hypervisor mediation (Figure 15).

Interrupt Masking

PSTATE.I/F/A bits mask IRQ/FIQ/SError. When HCR_EL2.IMO is set, PSTATE.I masks virtual IRQs instead of physical ones.

2.5 Clock Virtualization

Each CPU has generic timers with comparators that generate timer interrupts. EL1 can use either the physical system counter or a virtual counter offset by the hypervisor (Figure 19). This allows timers to advance only while the vCPU is scheduled.

2.6 Virtualization Host Extensions (VHE)

VHE (Armv8.1‑A) allows the host OS kernel to run at EL2, eliminating the need for a separate high‑visor (EL1) and low‑visor (EL2) split. The HCR_EL2.E2H and HCR_EL2.TGE bits control this behavior.

|         Running in        | E2H | TGE |
|---------------------------|-----|-----|
| Guest kernel (EL1)         |  1  |  0  |
| Guest application (EL0)    |  1  |  0  |
| Host kernel (EL2)          |  1  |  1* |
| Host application (EL0)     |  1  |  1  |

*When exiting a VM, TGE is cleared and must be set again before the host kernel resumes.

Address Space Changes with VHE

With VHE enabled, EL2 gains separate kernel and user address spaces and ASID support (Figure 25). The TGE bit determines whether EL0/1 uses the guest or host address space.

2.7 Nested Virtualization

A hypervisor can run inside a VM (guest hypervisor). Armv8.3‑A introduced HCR_EL2.NV and NV1 to trap accesses to EL2 registers, allowing a guest hypervisor at EL1 to be serviced by a host hypervisor at EL2. Armv8.4‑A adds NV2 and VNCR_EL2 to redirect these accesses to a memory region, reducing trap overhead (Figure 30).

2.8 Secure‑World Virtualization

Armv8.4‑A adds EL2 support in the secure world (enabled by SCR_EL3.EEL2). This allows moving firmware from EL3 to EL1 under hypervisor control, improving isolation (Figure 31).

3 Virtualization Overhead

Switching between a VM and the hypervisor requires saving/restoring registers: 31 general‑purpose registers, 32 SIMD/floating‑point registers, and two stack pointers. Using LDP/STP, at least 33 instructions are needed, and the actual overhead depends on hardware and hypervisor design.