BACKGROUNDER TenAsys Real-time Hypervisor Host Real-time and General-purpose Operating Systems on a Single Hardware Platform with Intel® Virtualization Technology August, 2006 TenAsys Corporation 1400 NW Compton Drive, #301 Beaverton, OR 97006 USA +1 503 748-4720 fax +1 503 748-4730 [email protected] www.tenasys.com Copyright © 2006, TenAsys Corporation. TENASYS, INTIME, and IRMX are registered trademarks of TenAsys Corporation. 060803 Other trademarks and brand names are the property of their respective owners. Virtualization Background Virtualization of computer hardware has been used for many decades. The most widely noted early examples are those implemented by IBM on their mainframe hardware giving their customers a means to easily upgrade from old “iron” to new “iron.” In this case a primary goal of virtualization was to allow legacy applications to run on newer machines, alongside applications designed for the new OS and hardware. [1] Software that manages computer hardware virtualization is referred to as a Virtual Machine Manager (VMM) or hypervisor. [2] A VMM is akin to a machine emulator. A machine emulator typically simulates the CPU instruction set, some key hardware elements, and the operating system calls from a real system; usually for the purpose of running applications developed for obsolete hardware on newer hardware. For example, emulators have been written to run the code copied from ROM cartridges of old gaming systems on a desktop computer. Like an emulator, a VMM creates the illusion of a hardware platform, for the purpose of hosting an entire operating system (the guest OS) and its applications. A key difference between an emulator and a virtual machine is that a virtual machine can be built from virtual hardware; that is, the I/O devices inside a virtual machine need not emulate real hardware. Most modern VMMs operate without the need for CPU instruction set emulation, since the instruction set of the virtual machine is identical to, or is a subset of, the underlying hardware. The guest OS and applications running inside each virtual machine are native to the underlying processor instruction set. Also, instead of perfectly emulating a specific hardware platform, the typical VMM presents a virtual computing system that can be replicated multiple times on a single hardware platform and contains sufficient virtual I/O to support common client and server applications. Emulation on the IA platform VM86 mode, part of the Intel® architecture since the Intel® architecture (IA) processors, 386 processor, provides a means by which a VMM ubiquitous on desktops and widely used can efficiently host a 16-bit guest operating system for many embedded applications, supports (e.g., DOS and Windows versions thru ME). The four distinct privilege levels of application VM86 hardware traps accesses to key processor execution named rings 0 thru 3. Ring 0 resources so the VMM can maintain control of the executes at the highest privilege level and machine hardware. This x86 virtualization feature ring 3 at the lowest. In typical practice only was exploited over fifteen years ago by TenAsys two levels are ever used: rings 0 and 3, engineers, in DOS RMX and the original iRMX® for referred to, respectively, as “supervisor- Windows. Instances of these virtual real-time mode” and “user-mode.” Operating embedded applications are still in use today, systems that utilize these execution modes running the iRMX® RTOS and a general-purpose OS are referred to as “protected-mode” side-by-side, on a single hardware platform. operating systems; the OS executes its instructions in supervisor-mode and its applications execute in user-mode. Drivers might execute either in supervisor or user-mode, depending on the architecture of the OS and the nature of the driver. On an IA processor, the typical emulator simulates an application’s operating system environment by intercepting legacy OS calls made by the emulated application and page 2 of 11 Copyright © 2006, TenAsys Corporation • www.tenasys.com • August, 2006 translating them into equivalent calls to the hosting OS. The emulated application runs in user-mode, making it very easy to trap and substitute system-level calls using the x86 ring hardware. A VMM, on the other hand, hosts a complete protected-mode OS (the guest OS) plus its applications. A protected-mode guest OS expects to run in supervisor-mode with full access to the underlying CPU registers and data structures. One of the most difficult jobs a VMM must do is intercept guest OS instructions that modify supervisor-mode registers and data structures and then simulate the impact of those instructions inside the virtual machine on which the guest OS is running. Static virtualization and real-time In 1997 TenAsys® Corporation introduced INtime®, an RTOS that runs deterministically alongside 32-bit and 64-bit versions of Microsoft® Windows® on a single IA hardware platform. A unique form of virtualization makes this feat possible, allowing Windows to run unmodified as the lowest priority task (i.e., the idle task) in the INtime real-time task list. This “dual-OS, single-platform” arrangement gives developers a means to build deterministic embedded Windows systems that can reliably control critical machine functions and simultaneously present high-level interfaces for system monitoring, enterprise connectivity, and complex user interaction. INtime and Windows share a single hardware platform. Windows runs as the lowest priority task (the idle task) in the INtime real-time task list. The INtime RTOS is a 32-bit protected-mode operating system, as is Windows XP, the desktop OS which “shares” a single hardware platform with INtime. Running two specific protected-mode operating systems on a single platform is sometimes referred to as “static virtualization.” [3] In this case Windows boots first and then INtime inserts itself between the system hardware and Windows. Memory and I/O hardware designated for use by the INtime RTOS are “hidden” from Windows and dedicated for use by RTOS processes. All standard user interface I/O, such as the video, keyboard, and mouse, remain under the ownership of Windows. Windows is unaware that the INtime RTOS and its processes exist, even as it is relegated to the lowest-priority task in the INtime task list. Copyright © 2006, TenAsys Corporation • www.tenasys.com • August, 2006 page 3 of 11 Static virtualization of an RTOS with Windows has many applications: • Phoenix Contact of Ann Arbor, Michigan implements their Steeplechase soft PLC engine on INtime and a PLC-to-enterprise network interface, called Transaction Express, on Windows, resulting in one of the fastest and most flexible Windows-based PLC engines for factory floor automation. • AVL in Graz, Austria, drives their PUMA Open test bed software with INtime. PUMA Open is a real-time Windows test automation system for measuring and processing high-speed data from engines, transmissions, and power trains. AVL products are used by major car and truck manufacturers worldwide. • CNC maker ANCA from Melbourne, Australia puts an INtime plus Windows powered PC at the heart of their CNC machines, giving their customers fast and accurate machining along with the ability to model and preview grinding operations in 3D, directly on the CNC machine. The combination reduces their customer’s cost of operation by simplifying equipment requirements and avoiding expensive tool crashes during trial runs. Conventional IT virtual machine shortcomings The static virtualization method used by INtime succeeds where the conventional approach to virtualization used by traditional VMMs simply will not work; that is, for real-time applications. Like a general-purpose OS, such as Windows or Linux, a conventional VMM must be “fair” in its approach to scheduling CPU time for virtual machines and allocating I/O resources among the virtual machines. The conventional VMM is targeted at solving problems for a corporate IT network: maximizing the use of server resources and simplifying the deployment and maintenance of client desktops. The “IT virtual machine” presented by a conventional VMM is not capable of supporting the deterministic scheduling and dedicated I/O required of real-time applications and their operating systems. The I/O presented by a conventional IT virtual machine usually consists of a CPU, RAM, disk, video, keyboard, mouse, and a network interface. A few other generic I/O devices may be available to “install” inside the IT virtual machine, but due to the difficulty associated with multiplexing a wide range of I/O between multiple virtual machines, most virtual machine I/O is limited to these basic devices. Despite these limitations, this I/O complement satisfies a large percentage of IT server and desktop applications, making this form of virtualization popular with corporate IT groups as a means to quickly buildup and teardown server applications and client desktops. Intel® Virtualization Technology Until the introduction of Intel® Virtualization Technology (Intel® VT) as part of the Intel® Core™ microarchitecture, a software-only VMM designed to support multiple protected- mode operating systems on an x86 virtual machine encountered significant challenges. Both the VMM and the protected-mode guest OS expect to maintain supervisor-level control over the hardware platform; however, absent some form of cooperation between the VMM and the guest operating systems (sometimes referred to as “paravirtualization”) the VMM must resort to trickery. Supervisor-level control can be reliably maintained by only one software system, resulting in a conflict between the VMM and the guest OS. The tricks a VMM must page 4 of 11 Copyright © 2006, TenAsys Corporation • www.tenasys.com • August, 2006 use, without Intel VT, involve modifying the guest OS binary code and running the guest operating systems at ring levels for which they were not written. The downside to such VMM trickery is a decrease in performance and limited guest OS compatibility. For example, binary files of a guest OS may be modified to trap supervisor- level CPU instructions, requiring the VMM to emulate these instructions.