Get this Ultimate Guide as a PDF
Click here to download the Ultimate Guide to Embedded Hypervisors and Virtualization.
What is an embedded HyperVisor?
An embedded hypervisor provides a virtual computing environment for operating systems used on embedded hardware. In this section, you’ll learn about embedded hypervisors and their benefits.
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.
Virtualization Terminology
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
Arm® and Intel® have been supporting virtualization for decades to help manufacturers of embedded systems for the automotive, industrial, robotics and other industries reduce costs and speed time to market. Hardware virtualization innovation is accelerating as silicon vendors and board vendors compete in the expanding embedded marketplace. However, the basics of virtualization are unchanged.
A hypervisor Is an Event Handler
A hypervisor is an event handler. It manages interrupts asserted by the hardware, pre-empting a running guest if necessary to route interrupts to guests in their VMs. When it pre-empts a running guest, either to allow another guest to run or to handle some tasks itself, the hypervisor performs a context switch: it saves the guest’s state, then restores it before handing execution back to the guest.
How Virtualization Works
Virtualization abstracts physical hardware. The hypervisor manages execution by alternating between the hypervisor host and guests on the CPU cores. In this section, you’ll learn about hypervisor virtual machines, privilege levels in virtualized systems, hypervisor-guest interaction, virtual machine configuration, and virtual memory and devices.
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).
The Lahav Line above, named for BlackBerry QNX microkernel developer Elad Lahav, presents a dynamic view of the interaction between the hypervisor and a guest. For simplicity, the line shows the execution path on a single CPU core.
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
A hypervisor may allow guests to create and use small memory regions in their allocated memory, then give another guest or the hypervisor access to these regions. This is an efficient mechanism for passing data between guests and between guests and the hypervisor host. Ultimately the hypervisor controls these regions.
Hypervisors in Mixed-Criticality Systems
An embedded hypervisor can provide the separation and isolation required for systems of mixed criticality to run on one board. In this section, you’ll learn how an embedded hypervisor can help get embedded systems safety-certified more quickly and to market faster.
When components designed for very different purposes, such as safety-critical and non-safety critical tasks, are deployed on a single SoC, the heterogeneity is referred to as mixed criticality. System designers who combine systems and components in this way must ensure that safety-critical components are free from interference both from external entities and from other components on the board.
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
Building high-performance VMs requires design talent, expertise and experience. BlackBerry QNX is trusted across industries to provide the software foundation and engineering services companies need to build safe, secure and reliable systems that get to market faster. In this section, you’ll learn about BlackBerry QNX solutions and services for embedded software development with virtualization.
BlackBerry QNX has in-depth virtualization expertise and technology. With a time-tested and field-proven microkernel real-time OS (RTOS) and hypervisor as well as engineering services, we have the tools and expertise to help you deliver reliable, secure and feature-rich embedded systems on time and within budget.
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
BlackBerry QNX Professional Services extends your team with virtualization, functional safety and embedded systems security expertise to help you shorten development timelines. Our virtualization experts help clients configure virtual machines, write virtual devices, tune guests and hypervisor systems, and provide guidance through every step of the safety certification process.
Check Out Our Other Ultimate Guides
Real-time Operating Systems
Provides embedded RTOS basics and considerations when choosing between an open source or commercial OS options
READ THE GUIDE
Embedded Systems Security
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
READ THE GUIDE
Functional Safety
Offers key concepts and information on standards for safe system design
READ THE GUIDE
Contact Us
Our team of experts are here to answer your questions.