Type 1 hypervisors manage key system resources required to maintain control over the virtual machines, and facilitate a minimal trusted computing base (TCB).
An embedded hypervisor typically provides multiple VMs, each of which emulates a hardware platform on which the virtualised software executes.
The custom nature of embedded systems means that the need to support unmodified binary-only guest software which require these techniques is rare.
It is also desirable for the hypervisor to maintain, as closely as possible, the native speed, real-time response and determinism and power efficiency of the underlying hardware platform.
Implementations for embedded systems applications have most commonly been based on small microkernel and separation kernel designs, with virtualization built-in as an integral capability.
VirtualLogix appears to take the position that an approach based on a dedicated Virtual Machine Monitor (VMM) would be even smaller and more efficient.
[5][6][7] However, the main point at issue is the same on all sides of the discussion – the speed and size of the implementation (for a given level of functionality) are of major importance.
Thus embedded hypervisors usually have a memory footprint from several tens to several hundred kilobytes, depending on the efficiency of the implementation and the level of functionality provided.
[9] One of the most important functions required in an embedded hypervisor is a secure message-passing mechanism, which is needed to support real-time communication between processes.
An inter-process communication (IPC) mechanism can be used to provide these functions, as well as invoking all system services, and implemented in a manner which ensures that the desired level of VM isolation is maintained.
[10] An embedded hypervisor needs to be in complete control of system resources, including memory accesses, to ensure that software cannot break out of the VM.
Many embedded processors including such as ARM, MIPS and PowerPC have followed desktop and server chip vendors in adding hardware support for virtualization.
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.
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.
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).
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.
[13] 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.