Embedded Hypervisor - Use Cases

Use Cases

Some of the most common use cases for an embedded hypervisor are:

1. OS independence
Designers of embedded systems may have many hardware drivers and system services which are specific to a target platform. If support for more than one OS is required on the platform, either concurrently or consecutively using a common hardware design, an embedded hypervisor can greatly simplify the task. Such drivers and system services can be implemented just once for the virtualized environment; these services are then available to any hosted OS. This level of abstraction also allows the embedded developer to implement or change a driver or service in either hardware or software at any point, without this being apparent to the hosted OS.

2. Support for multiple operating systems on a single processor
Typically this is used to run a real-time operating system (RTOS) for low-level real-time functionality (such as the communication stack) while at the same time running a general purpose OS, (GPOS) like Linux or Windows, to support user applications, such as a web browser or calendar. The objective might be to upgrade an existing design without the added complexity of a second processor, or simply to minimize the bill of materials (BoM).

3. System security
An embedded hypervisor is able to provide secure encapsulation for any subsystem defined by the developer, so that a compromised subsystem cannot interfere with other subsystems. For example, an encryption subsystem needs to be strongly shielded from attack to prevent leaking the information the encryption is supposed to protect. As the embedded hypervisor can encapsulate a subsystem in a VM, it can then enforce the required security policies for communication to and from that subsystem.

4. System reliability
The encapsulation of a subsystem components into a VM ensures that failure of any subsystem cannot impact other subsystems. This encapsulation keeps faults from propagating from a subsystem in one VM to a subsystem in another VM, improving reliability. This may also allow a subsystem to be automatically shut down and restarted on fault detection. This can be particularly important for embedded device drivers, as this is where the highest density of fault conditions is seen to occur, and is thus the most common cause of OS failure and system instability. It also allows the encapsulation of operating systems that were not necessarily built to the reliability standards demanded of the new system design.

5. Dynamic update of system software
Subsystem software or applications can be securely updated and tested for integrity, by downloading to a secure VM before “going live” in an executing system. Even if this process then fails, the system can revert to its former state by restarting the original software subsystem/application, without halting system operation.

6. Legacy code re-use
Virtualization allows legacy embedded code to be used with the OS environment it has been developed and validated with, while freeing the developer to use a different OS environment in a separate VM for new services and applications. Legacy embedded code, written for a particular system configuration may assume exclusive control of all system resources of memory, I/O and processor. This code base can be re-used unchanged on alternative system configurations of I/O and memory through the use of a VM to present a resource map and functionality that is consistent with the original system configuration, effectively de-coupling the legacy code from the specifics of a new or modified hardware design.
Where access to the operating system source code is available, paravirtualization is commonly used to virtualize the OS’s on processors without hardware virtualization support, and thus the applications supported by the OS can also run unmodified and without re-compilation in new hardware platform designs.
Even without source access, legacy binary code can be executed in systems running on processors with hardware virtualization support such as the AMD-V, Intel VT technologies and the latest ARM processors with virtualization support. The legacy binary code could run completely unmodified in a VM with all resource mapping handled by the embedded hypervisor, assuming the system hardware provides equivalent functionality.

7. IP protection
Valuable proprietary IP may need protection from theft or misuse when an embedded platform is being shipped for further development work by (for example) an OEM customer. An embedded hypervisor makes it possible to restrict access by other system software components to a specific part of the system containing IP that needs to be protected.

8. Software license segregation
Software IP operating under one licensing scheme can be separated from other software IP operating under a different scheme. For example, the embedded hypervisor can provide an isolated execution environment for proprietary software sharing the processor with open source software subject to the GPL.

9. Migration of applications from uni-core to multi-core systems
As new processors utilise multi-core architectures to increase performance, the embedded hypervisor can manage the underlying architecture and present a uni-processor environment to legacy applications and operating systems while efficiently using the new multiprocessor system design. In this way a change in hardware environment does not require a change to the existing software.