Download A New Generation of Hypervisors Leverage Multi

Hypervisors Leverage Multicore Processors for Embedded Systems
The ability to run an RTOS with real-time control processes on the same multicore processor as a
human interface OS like Windows, is made possible by an embedded hypervisor working in
conjunction with on-chip virtualization technology.
by Kim Hartman, TenAsys Corp.
The newest multicore processors contain hardware-assisted virtualization features that enable
hypervisors to be constructed in such a way that they can support multiple operating systems of
different types to be hosted on an embedded system platform. Now real-time OSs can readily be
hosted along with general-purpose OSs on the same platform. This has huge positive
implications on the embedded computing industry because applications that previously required
multiple processor platforms in order to guarantee determinism (typically a PC-compatible
processor and another real-time computer that may or may not be PC-compatible), can now be
implemented with greater ease on a single platform. Besides enabling lower system costs, the
consolidation of platforms can also increase system performance and reliability by removing
inter-platform communication bottlenecks that may have existed in multi-platform
implementations.
Running multiple operating systems on the same processor/platform requires software,
sometimes called a hypervisor or virtual machine manager (VMM), which implements
virtualization of the platform, whereby each operating system is presented with its own separate
version of the underlying machine’s software architecture. Traditional virtualization consisted of
virtualizing the entire machine, including its I/O for each OS, but this causes serious
performance limitations in embedded applications that have real-time constraints. It may still
work in office and server applications that don’t have real-time processing requirements, but for
real-time functions, this virtualization approach is impractical.
What has worked instead in real-time applications is a technique called embedded virtualization,
whereby using an embedded virtualization manager (eVM), each operating system is presented
with a software interface that is similar to the underlying machine, but is not identical. This is in
order to allow each OS to access its I/O in a manner that serves the performance requirements of
its applications. At first this was done with para-virtualization, a software-intensive technique
that remaps the memory used by a particular RTOS to allow it to run in a system with another
OS. The advent of new CPUs has simplified the implementation of multi-OS systems by remapping memory at runtime using hardware address translators.
The latest Intel processors contain architectural features called VT-x and VT-d extensions that
replace some of the para-virtualization techniques with hardware. Hardware-assisted
virtualization features like VT-x do away with much of the complexity of software paravirtualization by providing hardware address translators built into the chipset that ensure that any
memory address issued by a guest OS is automatically adjusted by a constant value called a loadoffset. Likewise, the hardware assisted virtualization feature called VT-d automatically adjusts
the memory accesses generated by DMA bus mastering I/O devices according to the load-offset
of the particular guest. Some platforms feature processors supporting VT-x but don’t have
chipset support with VT-d. In those cases, software para-virtualization techniques must still be
used. There are instances where para-virtualization may still have to be implemented, such as the
re-routing of interrupts serviced by the guest OS when sharing the platform with Windows.
These need to be altered by the VMM at load time according to rules setup by the user prior to
load time.
Some embedded VMM implementations require that the guest operating systems, drivers and
middleware be modified, or para-virtualized in order to work together. This is costly and risky
since the customization work needs to be reimplemented and verified every time a new version
of one of the OSs and/or a driver is released. To avoid the expense and risk of maintaining
customized OS and VMM software environments, a better solution is to use an embedded VMM
that can run standard OS and application software without modification.
To do this, the VMM should leverage the hardware virtualization support provided in Intel
processors to enable PC-based RTOSs to run alongside Windows without requiring any
modifications to Windows or the RTOS. It should dedicate a thread/core to each OS and use the
processor’s VT-x feature to map the memory, making use of the processor’s VT-d extensions
when the guest RTOS needs to interface directly to DMA bus mastering I/O devices.
In addition, the optimal embedded VMM technology should enable users to work with an offthe-shelf copy of Windows that runs directly on the platform (bare-metal), supporting all of the
latest devices and drivers that Windows employs. Since no modifications to the guest RTOS are
required with this type of system, legacy application software will also run on the new platform
without modification.
The advantage of being able to preserve legacy code while consolidating platforms can’t be
overemphasized. It can make or break the attractiveness of a new embedded system project.
For example, Command Alkon of Birmingham, Alabama has millions of dollars invested in its
control software for bulk construction materials plants. They have used the QNX 4 real-time OS
since 1985 and have thousands of installations in place worldwide. The company is in the
process of migrating from a dual-platform control system product that runs Windows on a PC
and QNX on a separate real-time embedded PC “brick” to a single-platform system that runs
both QNX and Windows on the same PC (Figure 1).
“Combining the platforms was a natural evolution for us,” said Randy Willaman, senior manager
of business expansion at Command Alkon. “We are able to simplify system maintenance and
reduce the component count while maintaining reliability.”
Before moving to a hypervisor, Willaman did a survey of available virtualization solutions. “One
option that we looked at was virtualizing the entire machine and consequently, this solution
couldn’t guarantee that our real-time control software would maintain its deterministic
responsiveness,” said Willaman. “Another alternative was to rewrite our I/O drivers in order to
get the system to work, but we couldn’t get source code from our OS vendor and we didn’t want
to pay the cost. In the end, we chose eVM for Windows from TenAsys Corp. of Beaverton,
Oregon, which gave us the performance we needed without requiring us to change our QNX
application code.”
In the Command Alkon implementation, the embedded virtualization manager (eVM) partitions
the machine to separate resources for exclusive use by each operating system. This is done by
configuring Windows to limit the number of hardware threads and memory that it uses.
Windows boots first and runs normally within remaining allocated resources. Since it’s running
on the bare machine rather than on an emulating software layer, Windows tasks execute with
maximum performance.
After Windows boots, the RTOS and real-time application software are loaded into memory that
has been allocated for the real-time portion of the application, and the RTOS is loaded from a
Windows driver and begins executing application code in its dedicated hardware environment.
With access to its own performance-critical I/O devices, the real-time application will run
completely independent of Windows. So that the real-time environment may use resources such
as native drivers, they are provided for that purpose. When Windows and real-time tasks need to
communicate, or the real-time application needs to use Windows resources, the two
environments communicate via emulated communications links in shared memory (Figure 2).
The Command Alkon system described above uses an emulated virtual Ethernet channel, but an
emulated serial interface could also have been used. Real-time I/O devices are configured via a
generic device driver on the Windows side and real-time interrupts are configured to be delivered
to the virtual machine manager and not to Windows.
Command Alkon may be at the leading edge of the embedded system consolidation trend, but
their experience will be shared by thousands of embedded system designers who will use the
latest hypervisor technology to decrease system costs. At the same time, they will increase
performance while improving system reliability by combining real-time and Windows platforms
on the same multicore processor.
TenAsys, Beaverton, OR. (503) 748-4720. [www.tenasys.com].
Command Alkon, Birmingham, AL. (205) 879-3282. [www.commandalkon.com].