Most mainstream operating systems are built on the assumption that a system has a single privileged OS running several unprivileged applications. ARM virtualization however, enables more than one OS to co-exist and operate on the same system. Implementing these virtual cores requires both dedicated hardware extensions (to accelerate switching between virtual machines) and hypervisor software.
A hypervisor is a program that allows multiple operating systems to share a single hardware processor. Virtualization hypervisors can be broadly classified as bare metal or hosted according to their design. Each has specific use cases. Regardless of the classification, the functional role of a hypervisor remains the same, namely, arbitration of platform resources, and seamless operation of individual guest operating systems with minimal porting effort and runtime sacrifices.
In the following figure, for Type 1, the bare-metal hypervisor, each Virtual Machine (VM) contains a guest OS. In Type 2, the hosted hypervisor is an extension of the host OS with each subsequent guest OS contained in a separate VM. There are two major Open Source hypervisors, KVM and Xen. Using this scheme, Xen is a Type1 hypervisor and KVM is Type2.
Bare-metal virtualization means that the Type 1 hypervisor has direct access to hardware resources, which results in better performance.
A hosted (Type 2) hypervisor requires an OS to be installed first. The host OS boots first. The hypervisor then behaves like an application that is installed on the OS. This approach provides better hardware compatibility, because the OS is responsible for the hardware drivers instead of the hypervisor. On the other hand, a hosted virtualization hypervisor does not have direct access to hardware and must go through the OS, which can degrade VM performance. Because there can be many services and applications running on the host OS, the hypervisor can often steal resources from the VMs running on it.
Using multiple operating systems on the same system then becomes possible, while providing each OS with an illusion of sole ownership of the system through several architectural features:
- A dedicated Exception level (EL2) for hypervisor code.
- Support for trapping exceptions that change the core context or state.
- Support for routing exceptions and virtual interrupts.
- Two-stage memory translation, where the second stage is for the hypervisor to isolate the guest operating systems.
- A dedicated exception for Hypervisor Call (
The ARMv8-A architecture permits virtualization using either AArch32 or AArch64 execution states. The hypervisor at EL2 can run in either AArch32 or AArch64 execution state. In AArch32, the execution is similar to the ARMv7-A architecture.
Virtualization support is provided in the Non-secure state only. There is no virtualization support in the Secure state, because TrustZone technology is intended to allow a Secure or trusted environment. This implies a small code base, to enable validation and certification.
When hypervisor code in EL2 is executing in AArch64, there are dedicated registers available, including:
- Exception return state registers: SPSR_EL2 and ELR_EL2.
- Stack pointer: SP_EL2 (and SP_EL0).