EMBEDDED HYPERVISOR DEFINITION
An embedded hypervisor is software that allows multiple computing environments to run simultaneously on a single system on a chip (SoC). It enables system designers to consolidate diverse operating systems (OSs) and applications with different reliability, safety and security requirements on one SoC.
An embedded hypervisor must provide equivalence, safety and performance—the three conditions for efficient virtualization specified by Popek and Goldberg in 1974:
Equivalence: Virtual machines (VMs) in a hypervisor duplicate the underlying hardware so accurately that guest operating systems can run without modification. From the point of view of a guest OS, the VM is hardware.
Safety: VMs are isolated from the hypervisor and from each other. The safety of the design is enforced without the hypervisor knowing anything about the software running inside a VM.
Performance: Software executing in a VM must show no more than a minor decrease in speed compared to the same software running directly on the hardware (bare metal).
From the point of view of a guest OS, the virtual machine is hardware.
Benefits of Embedded Hypervisors
With an embedded hypervisor, a system designer can:
- Reduce hardware cost, size, weight and power consumption by reducing the number of SoCs in the overall design.
- Reduce development time by reusing proven, legacy software in a VM.
- Maintain fast-boot and real-time behavior while adding features more easily implemented by a specific operating system, such as multimedia applications running on Android™.
- Use the best operating system for a specific purpose, such as the QNX® OS for Safety for safety-critical software, and Linux® or Android for an entertainment system.
- Streamline and limit the scope of safety certifications by isolating non-safety systems in safety-certified hypervisor VMs
- Increase reliability with system monitoring, guest failure detection, shutdown and automated restart: a guest can fail without affecting the hypervisor or other guests
- Increase embedded systems security: isolating components in separate VMs reduces the ability of an attacker to compromise the entire system.
Read more about the benefits of embedded hypervisors in Extend the Lifecycle of Embedded Systems with a Hypervisor.
The following terms are often used when discussing virtual environments and hypervisors:
Host: the hypervisor, also known as the host domain or hypervisor host
Guest: a guest OS and its applications running in a VM
Virtual machine (VM): a hypervisor host process that presents a virtual environment to a guest OS; the VM hosts the guest OS
VIRTIO: a virtualization technique promoted by OASIS and adopted extensively by the Android and Linux communities. A guest enabled with VIRTIO technology can run unmodified on different hypervisors, as long as they support VIRTIO services.
Virtual machine manager: Hypervisors are also known as virtual machine managers (VMMs).
Device: a physical or virtual device. A virtual device may emulate a physical device or it may be a paravirtualized device; that is, a virtual device with no hardware equivalent, such as the virtio-net (virtual network device) provided with the QNX® Hypervisor.
Privilege: the authority to access hardware and execute instructions. A guest runs at a lower privilege than the hypervisor, and applications have the least privilege. Known as Exception Levels on Arm and Rings on x86.
Hardware Virtualization Extensions Enable Hypervisor Software
A hypervisor Is an Event Handler
How Virtualization Works
Hypervisor Virtual Machines
A hypervisor is not a simulator. A simulator emulates an instruction set; this instruction set doesn’t have to match the instruction set of the underlying hardware. Since processing in a simulator can be from five to 1000 times slower than processing directly on hardware, simulators can’t meet Popek and Goldberg’s third condition for equivalence: performance.
By contrast, a hypervisor is a multiplexer. It manages VMs with guests compiled for the architecture and instruction set of the underlying hardware. Though they are in VMs, guests actually run directly on the hardware CPU. A guest system running on a well-designed hypervisor system exhibits only a minimal slowdown.
Thus, from a guest’s perspective, the VM in a hypervisor system replaces hardware. In fact, a guest in a VM doesn’t know it isn’t running on hardware; it will probe for devices and expect the same behavior from them as when it is running directly on hardware. For example, virtual interrupt controllers present the same event sequences, sometimes even the same timing, as their hardware equivalents.
Managing Virtual Machines and Their Guests
Privilege levels affect what a software component is allowed to do. In a virtualized system, the hypervisor is the most privileged component. Guest operating systems in VMs have less privilege than the hypervisor, but more than applications, which have the least privilege. The hardware enforces privilege levels.
In Arm terminology, privilege levels are called exception levels (EL0, EL1, EL2), with EL2 having the most privilege. In Intel x86 terminology, the four privilege levels are called protection rings, and Ring 0 has the most privilege.
In a hypervisor system, execution on the CPU alternates between guests and the hypervisor host. When a guest runs, its instructions execute on the physical CPU, as if the guest were running without a hypervisor. When the guest tries to do something that it doesn’t have sufficient privilege to do, the virtualization hardware traps the attempt and informs the hypervisor.
If the guest attempts an illegal action, such as accessing memory outside its allocated memory range, the hypervisor returns an error to the guest, just like hardware would return an error in a system without virtualization.
If, however, the hypervisor can complete the guest’s action, it saves the guest’s context (guest exit) and completes the action. When it completes the action, the hypervisor updates the guest’s context, restores the guest’s context and hands execution back to the guest (guest entrance).
In a hypervisor system execution on the CPU alternates between the hypervisor and its guests.
Configuration of Virtual Machines
Guests run in VMs. Each VM is a complete computing environment configured by a system designer, who specifies every VM component: CPU cores, graphics controller, memory, virtual, paravirtual and physical device, etc.
Configuring a VM is much like assembling a board, with the difference that instead of assembling physical memory cards, CPUs and other physical components, the VM designer specifies virtual components. The rules are like that for a board; for example:
- Two components can’t respond to the same physical address.
- The environment the VM configuration assembles must be one that the software (the guest OS) is prepared to deal with.
A VM doesn't know what its guest is doing any more than hardware knows what an OS is doing. At BlackBerry QNX, we say, “The guest is a blob.” For example, a VM may not know whether a guest quit due to a user-requested shutdown or a fatal error. If you’re designing a hypervisor system, you may need to add a mechanism for the guest to report such information.
A hypervisor doesn’t know any more about its guests than a board knows about an OS.
Virtual Memory in Embedded Systems
The VM configurations set aside specific areas of memory on the hardware for use by guests. A guest in a VM configured with 4 GB of RAM will see the 4 GB available to it, just as it would see the available RAM in a non-virtualized environment. That is, this memory appears to the guest as if it were contiguous physical memory, though in fact the hypervisor may assemble the memory from non-contiguous physical memory.
In a non-hypervisor system, Stage 1 (single-level) page tables translate physical addresses to virtual addresses. Software running on bare metal uses these virtual addresses.
In a hypervisor system, guests in each VM use their own Stage 1 page tables; these map, not to actual physical addresses, but to intermediate physical addresses (IPAs). These IPAs (called “guest physical addresses” by Intel) correspond to the memory the hypervisor assembled for each VM. In the hypervisor host, another layer of page tables, the Stage 2 page tables, map the IPAs to actual physical memory, just like Stage 1 page tables map virtual addresses in a system without virtualization. These two levels of address translation ensure that guests in VMs can access only the resources assigned to them.
Physical, Virtual and Paravirtualized Devices
Virtualized environments can provide guests with access to virtual and physical devices. Whether it is for a virtual or a physical device, to work with a device, the device owner (hypervisor or guest) requires a device driver, just like in a non-virtualized system.
- Virtual device: A virtual device may emulate a physical device or it may provide functionality without emulating any specific physical device (paravirtualization). An emulation virtual device may either handle everything itself (e.g., emulate a timer chip), or it may act as an intermediary between the guest and an actual physical device (e.g., emulate an asynchronous communications chip such as the Intel 8250 UART).
- Paravirtualized device: A paravirtualized device provides the functionality that might be provided by a physical device (or several physical devices) in a non-virtualized environment, but without the constraints of emulating a piece of hardware. Thus, a paravirtualized device may be more efficient than a virtual device that must emulate hardware. The Organization for the Advancement of Structured Information Standards (OASIS) VIRTIO standard is a popular paravirtualization standard, but not the only one.
- Pass-through device: A guest may access a physical device through a virtual device in its VM. This virtual device acts as an intermediary between the guest and the physical device. The VM configuration may also pass through a physical device (pass-through device) directly to a guest. Guests have exclusive control of their pass-through devices. All the hypervisor knows about a pass-through device is the existence of the memory range reserved for it in the VM.
Sharing Devices in Virtualized Environments
In a virtual environment, every device has a single owner, either the hypervisor host or a guest. A virtual or physical device may be for the exclusive use of the hypervisor host or of a guest, or it may be shared. If it is shared, the device owner must manage access to the device.
When guests share a physical device, they may do so without the involvement of the embedded hypervisor, or the hypervisor may mediate:
- Referred sharing model: The physical device to be shared is assigned to a guest, which has full control of the device. Other guests that want to use the device use mechanisms, such as TCP or shared memory and virtual queues, to communicate with the guest that controls the device.
- Mediated sharing model: The hypervisor serves as a mediator and controls the interface with the physical device. The hypervisor ensures that configured priorities are respected (e.g., safety-related activities take precedence) and even refuses to cooperate with a guest or device whose activities might be harmful.
Sharing information between virtual machines
Hypervisors in Mixed-Criticality Systems
A hypervisor’s safety-certified virtual machines can isolate safety-critical components from non-safety guest systems.
An embedded hypervisor can play an important role in the ability of a product development team to rapidly create, test and certify a new version of a safety-critical product. With a hypervisor, the team can re-use proven legacy software in a VM and keep safety components separated on a single SoC. Software components built by separate groups can be tested separately, run together, and swapped out without affecting other systems or the whole system having to be retested repeatedly.
If a system will be certified to a safety standard, a hypervisor pre-certified to industry standards can significantly reduce the burden of certification. Different operating systems can run in different safety-certified VMs—such as a Linux guest in one VM and an Android guest in another VM—while the safety-critical system runs directly on the safety-certified hypervisor host. BlackBerry QNX has pre-certified our embedded hypervisors to IEC 61508 SIL 3 and ISO 26262 ASIL D to reduce time to market for safety-critical embedded systems.
How BlackBerry QNX can help you
The QNX Hypervisor
The QNX Hypervisor and the QNX® Hypervisor for Safety are built on the same microkernel foundation as the renowned QNX® Neutrino® RTOS and come with the field-proven QNX tool chain and C and math libraries.
- The QNX Hypervisor: The QNX Hypervisor is a real-time microkernel hypervisor that provides the trusted reliability and performance of the QNX Neutrino RTOS while allowing multiple operating systems to co-exist on the same SoC.
- The QNX Hypervisor for Safety: QNX Hypervisor for Safety is built on the QNX OS for Safety, the safety-certified variant of the QNX Neutrino RTOS, so the hypervisor host and its VMs offer the same trusted functionality and performance, and is pre-certified to both IEC 61508 SIL 3 and ISO 26262 ASIL D.
The QNX Hypervisor has the same real-time microkernel foundation as the QNX Neutrino RTOS.
BlackBerry QNX Professional Services
Check Out Our Other Ultimate Guides
Real-time Operating Systems
Embedded Systems Security