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