Running multiple operating systems on a single platform continues to be a mainstay in server environments. But now this ability is migrating to embedded environments for various reasons, ranging from legacy operating-system (OS) support to enhanced security. More powerful processing environments are even driving OS coexistence and virtualization into portable, handheld devices.
Most developers are familiar with the native single-image OS architecture (Fig. 1). It's used on desktop PCs and embedded devices. Add a memory management unit (MMU), and the OS can isolate applications so no one will accidentally or maliciously stomp all over their kin or the OS.
The single-image OS serves most applications well. Yet many applications now demand more flexibility. This can be gained through a number of techniques, depending on application requirements and system support. For example, it's becoming more common to mix real-time applications with applications that don't require the same level of real-time support.
One approach delivers this mix in a single OS like FSM Labs' RTLinux. The OS is built on a real-time portion, and the Linux OS sits on top of it. Real-time applications operate in one environment, and Linux operates in the other. Communication exists between the two environments, though applications never migrate from one to the other without being rewritten.
The other method retains the OS to handle existing applications and mixes OSs to provide a more flexible environment. There are basically three approaches. One is applicable to environments where all applications run on the same type of virtual machines that run under the same operating system (see "Software Virtual Machines," p. 46). The other two approaches, para-virtualization and full virtualization, virtualize the OS run-time environment to support one or more guest OSs.
Para-virtualization requires guest OSs specifically targeted for the host environment (Fig. 2). Advantages include low overhead for guest OSs, which in turn increases system performance and utilization. On the flip side, a guest OS must be modified. It's one reason why open-source OSs are often the first targets for para-virtualization systems.
Full virtualization requires hardware support in the host processor over and above MMU support (Fig. 3). This typically includes trapping privilege instructions whereby the underlying system can efficiently emulate the instructions for the interrupted application.
Virtualization offers a number of benefits. Of course there is the obvious benefit of running multiple OSs on a single platform. It also is possible to implement quality of service (QoS) at the OS level. The same is true for security. It's possible to share or simulate peripherals that the guest OSs have access to. Finally, a virtualized system is great for management and debugging since a virtual-machine image can be arbitrarily stopped, saved, and restarted. In fact, quick guest OS startup can be accomplished by loading an image that has already reached the desired starting point.
Virtual systems can run on top of a conventional OS. Typically, though, they're built on a more limited hypervisor, which is a virtual-machine "manager." A hypervisor provides many of the services a conventional virtual-memory OS would, such as coordinating memory and I/O protection.
However, a hypervisor wouldn't offer services like generalized messaging (e.g., BSD sockets and file management). Instead, the hypervisor controls and coordinates hardware services and protection mechanisms that are then managed by the guest OSs for their respective applications.
Hypervisors are designed to be very small, very fast, and very efficient. Xen is only 50k lines of code. Anything less, and the overhead would make the virtualization process impractical. It's possible to incorporate the hypervisor in a host OS, but it tends to be more efficient to run a host OS as a guest OS.
So why consider all of this sophisticated design and support hardware? Surprisingly, the reasons for using virtualization on a server are often the same reasons why it winds up in an embedded application.
Load balancing is key for using virtualization on multiprocessor servers. On the embedded side, multiple processor systems are becoming more common, and load balancing is often a requirement. Load balancing often leads to application migration, which is another use of virtualized systems.
Another reason is to mix different versions of the same OS. This can be used to support legacy applications as well as to test new environments while maintaining existing services. It's a key advantage in high-availability systems, too.
Of course, mixing different OSs is another possibility. In embedded environments, one OS may be a real-time version, allowing combinations like RTLinux but without the need for tight application integration. Such a mixed-mode environment may emerge for a variety of reasons.
For instance, combining two processors into one can reduce the hardware cost and the system footprint. With a virtualized system, the OSs from the two processors, which are typically different, can run on the single processor.
Security presents another situation where a hypervisor environment can improve system capability (see "Virtual Security," p. 50). In this case, the hypervisor is the most secure part of the system. It can give guest OSs different levels of security and even control the types of connections available between guest OSs and their applications. System managers then have simpler, more flexible control over security policies. It also can make the job of proving system security easier since low-security environments can be isolated from high-security environments.
Regardless of the reason, virtual systems are going to play a more important part in processing and a very specific role in embedded applications. If all this sounds familiar, you may have experience with mainframes. Virtualization has been around for some time, starting with systems like IBM's VM/370 and the Burroughs B1700 processor.
SINGLE OS IMAGE The single-image OS is so ubiquitous, it almost doesn't need to be mentioned. But it's interesting to note the wide variety of similar implementations. Boil down most real-time OS (RTOS) implementations to the bare architecture, and they become almost identical. On the other hand, unique features such as security, communications, and development tools continue to differentiate vendors and their solutions.
In virtualization, the ARINC 653-1 standard stands out like the POSIX standard does for general OS services. ARINC 653 defines an APplication EXecutive (APEX) for space and time partitioning. It's usually found in DO-178B environments, and it has found support in standard OSs like Green Hills Software's Integrity and LynuxWorks' LynxOS-178.
With ARINC 653, developers can define resource partitions for applications. A partition can be limited in a variety of ways, such as the length of the time slot it has to execute and the amount of accessible memory. Of course, this is all done while keeping applications isolated. This makes it easier to control and confirm Evaluation Assurance Level (EAL) security within a system.
Reprints
