Much is being said about virtualization these days in the software world. Simply stated, virtualization is about getting multiple OSs to run on the same computing platform at the same time. Virtualization has been cited as a key technology for getting the most performance out of the newest multicore processors. But just as not all computing applications are the same, not all virtualization approaches are appropriate for all applications.

Embedded systems have a key requirement that doesn’t normally apply to office and server computers: the need for deterministic response to real-time events. To support the requirement for determinism, embedded applications typically use RTOSs. Embedded applications also employ general-purpose OSs to handle operator interfaces, databases, and general-purpose computing tasks.

In the past, because OSs couldn’t successfully co-reside on computing platforms, system developers employed multiple processing platforms using one or more to support real-time functions and others to handle general-purpose processing. System designers that can combine both types of processing on the same platform can save costs by eliminating redundant computing hardware. The advent of multicore processors supports this premise because it is possible to dedicate processor cores to different computing environments; however, the software issues posed by consolidating such environments require special consideration. Combining real-time and general-purpose operating environments on the same platform (Figure 1) places some stringent requirements on how virtualization is implemented.

Paravirtualization

A common approach to supporting multiple OSs, on an embedded platform is to employ operating software called a hypervisor that boots first on power-up, then loads the OSs. The hypervisor is in charge of the platform and handles the memory partitioning and other processor resources between the OS environments. If the CPU doesn’t support Intel’s VT-x hardware extensions for virtualization, modifications must be made to the guest OSs, so they know that they’re supported by a hypervisor. They must carry out their own address translation to avoid conflict with memory belonging to other OSs.

A situation such as this, where the guest OS is aware that it is a guest, is called paravirtualization. Though the scheme might work, the main downside to this approach is that developers can’t use a standard out-of-the-box OS as a guest. This is the virtualization approach that the Xen hypervisor takes. Modifying a third-party OS can lead to major support headaches, and the cost of supporting such a product over its long-term life cycle through upgrades and updates is significant.

Server virtualization

To minimize the changes that need to be made to a guest OS so that it can run in a virtual environment, developers can build a hypervisor that emulates the entire machine, providing each guest OS with what it thinks is exclusive access to the processor platform. This approach is being used today on multicore processor systems to run multiple instances of the same application.

While this approach might be satisfactory for server applications that are optimized to keep the processors busy, it is unacceptable for embedded applications that need to ensure the fastest possible response to external events. Currently available software products of this type are not optimized for Intel Architecture processors or a particular class of applications. Every time a new OS configuration needs to be supported, significant work is required to tailor the hypervisor to work with the selected OSs.

Hardware-aided embedded virtualization

The best type of virtualization for embedded applications involves hardware assist features provided by the processor and platform architecture, which the hypervisor uses to ensure that the system meets the performance goals of the applications to be supported. With embedded virtualization, parts of the machine are emulated to provide a standard environment for multiple OSs, and parts of the system are not emulated to ensure that system performance goals are met. Basic functions such as the PCI bus interface and CMOS registers are emulated, but the I/O interfaces that are necessary for real-time responsiveness are assigned for exclusive use by the guest RTOS.

The embedded hypervisor must partition the machine to separate resources for exclusive use by each OS. TenAsys’ eVM for Windows accomplishes this by configuring the Microsoft Windows bootloader to limit the number of hardware threads and memory that it uses. Windows boots first and runs normally with the remaining resources allocated to it. Because it is running on the bare machine rather than an emulating software layer, Windows tasks execute with maximum performance.

Next, the RTOS and real-time application software are loaded into memory allocated for the real-time portion of the application, then the RTOS is booted from a Windows driver and begins executing application code in its isolated hardware environment. With access to its own performance-critical I/O devices, the real-time application will run completely independently of Windows. Special drivers are provided so that the real-time environment can use Windows resources. 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 such as virtual Ethernet and serial links (see Figure 2). 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.

Leveraging Intel Architecture

Embedded system developers have made huge investments in intellectual property that they would like to protect. Besides costing money and time to re-implement, changing application code to run in new OS environments can inject errors into applications or cause them to become unreliable.

Efficient embedded virtualization requires hardware support so that a variety of OSs can run without modification. By using the VT-x hardware extensions that Intel provides in its new CPUs and chipsets, an efficient execution platform can be delivered without requiring the guest OS or its drivers to be modified or the system disk to be repartitioned.

New hardware support under development at Intel will enable embedded virtualization with other general-purpose OSs. In addition, Intel is currently developing support for virtualizing the CPU’s paging mechanism and interrupt controller. With the new hardware features, guest OSs can be started and stopped independently, and Windows can be rebooted without needing to reboot the entire platform.

Embedded virtualization saves costs

In the embedded market, developers have been accustomed to tailoring operating environments with additional work and expense using multiple processing platforms to guarantee real-time system responsiveness. But the future can be different. Using eVM for Windows to enable system consolidation without requiring software customization can avoid solutions that are not adaptable while enabling solutions that can be implemented quickly at reasonable cost.

Chris Main is CTO of TenAsys Corporation, where he has led development of the company’s virtualization technologies. He has worked in real-time systems starting with minicomputers and was involved in the iRMX group at Intel. He was on the original development team for INtime and is a cofounder of TenAsys. He earned a graduate degree in Physics from York University and postgraduate degree in Education from Bath University.

TenAsys 503-748-4720 www.tenasys.com