Virtualization has been a major factor in the enterprise space for years; several virtualization providers have become billion-dollar companies. More recently, virtualization has started to become a hot topic in the embedded systems areas. This is demonstrated by recent moves of the dominant providers of virtualization for the enterprise, VMware and Citrix, who are clearly developing business strategies for that space.

Are we therefore likely to see versions of Xen, KVM or the VMware hypervisor on embedded devices, or should embedded-systems developers even try to port one of the open source solutions themselves? The answer is 'no' for good technical reasons. First, let's look at some of the virtualization use cases, which are considered for embedded systems.

Embedded virtualization use cases
While there are literally dozens of actual and potential use cases for virtualization in embedded systems, they can be broadly broken into three main categories: co-existence of different operating-system (OS) environments on the same platform, isolating critical components from an untrusted OS environment, and the use of an indirection level for remote control of OS environments on deployed systems.

These are all based on the fundamental idea of virtualization: inserting an additional software layer --the hypervisor--between an OS and the hardware. An OS running on a hypervisor does not access real hardware resources, but virtualized resources provided by the hypervisor. This is a generalization of the idea of virtual memory to all system resources. The immediate advantage is that a single hardware platform can be shared between several OS environments, as shown in Figure 1.

Figure 1. Virtualization allows partitioning physical resources (memory, processor) between multiple "guest" operating systems

From this bird's-eye view there is no difference between embedded- and enterprise-style virtualization. However, the differences emerge when we dig a bit deeper.

Why run several OSes concurrently?
In the enterprise space, one of the main drivers is quality of service (QoS). Different services can be protected from interference (eg. a highly-loaded service degrading a lightly-loaded one) by running them on different machines. Replacing physical machines by virtual machines allows this QoS isolation to happen on a single platform, with significant cost savings.

This is not normally a consideration in embedded systems, where different sub-systems all contribute to the overall system mission. There are, however, classes of embedded systems that are much more like enterprise-style servers, such as high-end network infrastructure devices. This kind of systems may indeed be served adequately by an enterprise-style hypervisor. This class of system, however, will be ignored in the remainder of this article.

The typical reason for using multiple OSes in an embedded system is "horses for courses." Modern embedded devices frequently contain massive amounts of software, measuring in the millions of lines of code (LoC). This implies a need for high developer productivity, which creates the demand for operating systems with familiar and high-level APIs, Consequently, "rich OSes," such as Linux or Windows, are becoming development platforms of choice in the embedded space.

While good for user-facing software, these rich OSes do not provide an appropriate base for other embedded software, in particular real-time subsystems. These are both functionality and legacy problems. Rich OSes do not tend to have the low and highly predictable interrupt latencies required by embedded systems, and frequently many real-time subsystems are large and difficult to port to APIs provided by rich OSes.

The inevitable consequence is a requirement for co-existence of several very different OSes on the same platform. This is accomplished by running each OS on a separate processor. However, in order to properly isolate the two systems from each other, physical memory needs to be partitioned either by connecting the processors to different memory banks or by having some other mechanism for partitioning shared physical memory.

Virtualization allows this to be done on a single processor core, which frequently results in lower BoM cost. But it is actually useful even on a multicore setup since the hypervisor partitions the shared physical memory between OSes without a need for further hardware mechanisms. What is particularly appealing is the abstraction of the underlying architecture provided by the hypervisor. The system designer can develop the software stack independent of the number of cores and can use the hypervisor to map the same stack to uni- or multi-processor hardware. This "architectural abstraction" is shown in Figure 2.

Figure 2. Architectural abstraction provided by a hypervisor, which maps virtual processors (each running a guest OS) to one or more physical processors