Hypervisor and software virtualization is seen as a cure for the common IT problem of supporting multiple operating systems (OSs) and their applications running across the same hardware environments. This has fueled the widespread adoption of software virtualization across servers and datacenters worldwide. But what about the embedded world?
There are two types of hypervisor. One runs on bare hardware, often forming a component part of a small microkernel. “Hosted” hypervisors rely on another OS to host the hypervisor or an emulation layer.
Software virtualization also comes in two forms. Full virtualization offers the guest OS a virtualized view of the hardware that requires no modification of the guest OS to run on the hypervisor. Para-virtualization requires some changes to the guest OS to make it aware of the underlying hypervisor.
MORE TOOLS TO USE Why might this technology be applicable for the embedded world? Running an extra layer of software under an OS just adds an extra layer of inefficiency to embedded systems that usually don’t have spare performance lying around.It’s true that there’s a performance hit for adding this layer. But depending on implementation, application, and underlying hardware, this hit is likely to be acceptable to most embedded systems. And, the potential benefits of using this technology far outweigh the hit.
Traditional hypervisors aren’t designed to meet the real-time performance or memory size requirements of most embedded systems. They’re primarily focused on either data throughput or ease of running guest OSs in an environment that typically features the same hardware configuration.
As embedded software complexity grows to meet market demands for increased functionality, user friendliness, and connectivity, hardware processors and platforms are changing to keep up. A change in hardware can sometimes lead to a monumental software redesign unless existing software can be reused effectively.
For example, the move from a unicore system to a multicore system is a complicated task for software designers, who must repartition their code across different processors. An embedded hypervisor that supports symmetric multiprocessing (SMP) can take the existing unicore OS and applications and provide a virtual unicore system.
In reality, the load will be spread across the multiple cores in the system. This hypervisor could also apply processor affinity, which allows certain guest OSs to be locked to certain cores, while other OSs and applications may float across others.
MOVING ON UP Another trend in high-end embedded systems is the move from 32- to 64-bit processors. This has traditionally required a new OS that supports 64 bits, and the applications have to at least be recompiled and revalidated in this system.A hypervisor can eliminate this pain by presenting a 32-bit virtual environment even when running on a 64-bit chip. Thus, the legacy 32-bit OS and applications can still run without change, and new applications can run on the 64-bit architecture in their own virtual environment.
The requirement for more complex software has also led to the use of more complex OSs such as Linux and in some cases even Windows. These systems aren’t used for their real-time characteristics but more for their user interface, connectivity, and rich device support. However, they’re increasingly required to run in real-time systems. An embedded hypervisor can provide a mechanism to run these large OSs alongside real-time applications on the same piece of hardware.
Continue on Page 2
In unicore systems, the hypervisor can provide real-time cyclic scheduling of multiple guest OSs, which means the real-time and interrupt latency is controlled by the hypervisor (not the guest OSs running on it) and can add higher degrees of determinism to OSs that traditionally don’t allow for it. OSs such as Windows where source code isn’t available can run in a fully virtualized environment, and OSs such as Linux can be para-virtualized to help increase OS performance.
The embedded hypervisor will generally run with a realtime separation kernel, with the hypervisor providing the virtual environments, and the separation kernel providing the real-time, multicore, and partitioning support. In applications that require safety and security, the separation kernel and hypervisor can also make sure that OSs that run in their virtual environments are separated by software from other applications or OSs running on the same hardware.
Any communication required between these environments is governed by security policies defined by the system designer that are then enforced by the separation kernel. Designers can feel comfortable that any fault conditions or even malicious attacks that occur in a virtual environment are then contained in that environment while the rest of the system continues to function, maintaining both safety and security requirements.
Many more use cases for the embedded hypervisor will start to determine its widespread use in tomorrow’s embedded systems. This is probably the most significant technology to hit embedded software in the last 20 years, and it’s likely to shape our next generation of embedded systems.