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.
Reprints
