Understanding embedded hypervisors

Many of us are familiar with the idea of a hypervisor in a powerful computer. It facilitates the simultaneous use of multiple operating systems and provides a virtualized environment in which unmodified legacy software may be deployed. Hypervisors have a place in modern embedded systems too. This article considers the characteristics of an embedded hypervisor, what facilities it can offer and some typical applications.

Some technologies should not really exist. They do, however, because they address a specific need. Typically, such technologies stretch something to make it perform in a way that was not originally intended. An example would be the fax machine. In a paper-based office environment, there was a frequent need to move documents from A to B. Initially, this resulted in the mail. But fax was an ingenious way to use phone lines to deliver a similar result. As soon as email became widespread, fax disappeared almost overnight. Domestic broadband is another example – ancient copper wiring is used to deliver digital connectivity at speeds that would have been regarded as quite impossible just a few years ago. Hypervisors are yet another "should not exist" technology that has found a firm place in the world.

What is a hypervisor?
Broadly speaking, a hypervisor is a software layer that enables multiple operating systems to be run simultaneously on a single hardware platform. They have been used for decades on mainframes, more recently on desktop computers, but are now beginning to be very relevant to embedded developers.

Hypervisors are not really a new technology – the first recognisable products were introduced on mainframe computers nearly 50 years ago. The incentives at that time were to make the very best use of costly resources. The expensive hardware needed to be used efficiently to be at all economic and downtime was expensive. Software investments needed to be protected, so facilitating seamless execution on new hardware was attractive. An interesting irony is that IBM's early virtualisation software was distributed in source form (initially with no support) and modified/enhanced by users; this was many years before the concept of open source was conceived.

In the context of a modern embedded system, what is the benefit of running multiple OSes on one piece of hardware, bearing in mind that this introduces significant complexity? The most important answer is security. A hypervisor provides a very strong layer of insulation and protection between the guest operating systems, ensuring that there is no possibility of one multi-threaded application interfering with another. A secondary, but still very significant, motivation to run multiple OSes is IP reuse. Imagine that there is some important software IP available for Linux that you want to use in your design. However, your device is real time, so an RTOS makes better sense. If multi-core is not an option (as that is another way to run multiple OSes on one device), using a hypervisor is the way forward, so that you can run Linux and your RTOS.

Types of hypervisor
Hypervisors essentially come in two flavours, which are imaginatively named Type 1 and Type 2. Type 1 hypervisors run on bare metal; Type 2 require an underlying host operating system. For embedded applications, Type 1 makes most sense for the majority of applications.

Multicore – SMP and AMP
The statement that a hypervisor enables multiple OSes on a single hardware platform implies that this meant a single processor. In fact, many products support the use of multiple CPUs, with the hypervisor distributing resources. To explore this further needs a little consideration of multi-core basics.

From a software perspective, there are essentially two types of multi-core architecture: Symmetric MultiProcessing (SMP) and Asymmetric MultiProcessing (AMP). With SMP, a single operating system runs across all the CPU cores, which must be of identical architecture. The OS needs to be specifically designed to run in an SMP system. In an AMP system, each CPU runs its own OS (or none at all); the CPUs need not be of the same architecture.

Hypervisors and multi-core
All embedded systems have finite resources, which need to be managed. It may be argued that this is the crux of what embedded software development is all about. For the purposes of this discussion, we will consider a hypothetical example system which has a single serial port. There are various ways that this port may be managed, depending on the configuration of software and CPU hardware.