Cloud Computing 19 min read

Understanding KVM/ARM: Split‑Mode Virtualization on ARM’s Virtualization Extensions

This article explains how KVM/ARM implements split‑mode virtualization by dividing the hypervisor into a lowvisor running in EL2 and a highvisor running in kernel mode, detailing CPU, memory, I/O, interrupt and timer virtualization, and describing the architectural improvements introduced by ARM's Virtualization Host Extensions (VHE).

Linux Kernel Journey
Linux Kernel Journey
Linux Kernel Journey
Understanding KVM/ARM: Split‑Mode Virtualization on ARM’s Virtualization Extensions

1. Introduction

ARM adds Virtualization Extensions to support hardware‑assisted virtualization. KVM/ARM adapts the Linux‑based KVM hypervisor to the ARM architecture, reusing existing kernel services instead of embedding complex core hypervisor functionality.

2. Split‑mode virtualization

KVM/ARM separates the hypervisor into two components: lowvisor , which runs exclusively in EL2 and handles low‑level trap processing and world‑switching, and highvisor , which runs as part of the host Linux kernel in normal kernel mode and leverages the scheduler, locking, and memory‑allocation code. This split allows each part to exploit the specific advantages of its privilege level while keeping the low‑level code base minimal.

3. CPU virtualization

The transition from host to VM involves a nine‑step world‑switch that saves host general‑purpose registers, configures the virtual GIC, stores host‑specific configuration registers, loads VM registers, programs EL2 traps (floating‑point, WFI/WFE, SMC, etc.), writes the shadow ID, enables stage‑2 translation, restores guest registers and finally enters the guest mode. The reverse switch from VM back to host follows a symmetric nine‑step process that restores host state and disables stage‑2 translation.

4. Memory virtualization

ARM provides a stage‑2 page table that translates Guest Physical Addresses (gPA) to Host Physical Addresses. The highvisor manages the stage‑2 tables, allowing only memory explicitly allocated to the VM to be accessed. Any access outside the VM’s memory triggers a trap to the lowvisor, which then handles the fault or forwards it to the highvisor. The hypervisor reuses the Linux memory‑management subsystem (e.g., get_user_pages) to allocate and map pages for the VM.

5. I/O virtualization

KVM/ARM relies on QEMU and Virtio user‑space device emulation. All MMIO accesses from the VM are filtered by stage‑2 translation; accesses to hardware devices that are not assigned to the VM trap to EL2, where the hypervisor forwards them to the appropriate QEMU device model.

6. Interrupt virtualization

Interrupt handling reuses Linux’s existing interrupt infrastructure. Hardware interrupts are trapped to EL2, causing a world‑switch to the highvisor, which processes the interrupt in the host kernel. Virtual interrupts are delivered via a virtual GIC (vGIC) implemented in the highvisor; the VM programs the vGIC, and the highvisor injects the corresponding virtual interrupt back into the guest.

7. Timer virtualization

ARM’s generic timer virtualization lets the guest read a virtual counter and program a virtual timer without trapping. When a virtual timer expires, the hypervisor detects it, injects a virtual timer interrupt, and programs a software timer to wake the VM if necessary. Physical timers remain under hypervisor control to preserve overall system timing.

8. Architecture improvements (VHE)

ARMv8.1 introduces Virtualization Host Extensions (VHE). VHE adds an E2H control bit that, when set, provides EL2 with additional registers (e.g., TTBR1_EL2) mirroring EL1 registers, makes EL1 register accesses transparently map to EL2 equivalents, and aligns EL2 page‑table format with EL1. This allows a type‑2 hypervisor like KVM/ARM to run the host OS entirely in EL2 without requiring split‑mode virtualization.

KVM/ARM system architecture
KVM/ARM system architecture
ARM two‑level page tables
ARM two‑level page tables
Virtualization Host Extensions (VHE)
Virtualization Host Extensions (VHE)
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

hypervisorARM virtualization extensionshighvisorKVM/ARMlowvisorsplit-mode virtualizationVirtualization Host Extensions
Linux Kernel Journey
Written by

Linux Kernel Journey

Linux Kernel Journey

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.