System and method for binding virtual machines to hardware contexts

1

SYSTEM AND METHOD FOR BINDING
VIRTUAL MACHINES TO HARDWARE
CONTEXTS

BACKGROUND 5

1. Field of the Invention

This invention relates to virtual machines of a computer processor such as a microprocessor. In particular, the invention relates to a virtual machine manager that may bind 10 virtual machines to hardware contexts of a processor in a computer or other computing device.

2. Background

An Operating System (OS) is a software program that controls physical computer hardware (e.g., a processor, 15 memory, and disk and CD-ROM drives) and presents application programs with a unified set of abstract services (e.g., a file system). A Virtual Machine Manager (VMM) is also a software program that controls physical computer hardware such as, for example, the processor, memory, and disk 20 drives. Unlike an OS a VMM presents programs executing within a Virtual Machine (VM) with the illusion that they are executing on real physical computer hardware that includes, for example, a processor, memory and a disk drive. Each VM typically functions as a self-contained entity, such that 25 software executing in a VM executes as if it were running alone on a "bare" machine instead of within a virtual machine that shares a processor and other physical hardware with other VMs. It is the VMM that emulates certain functions of a "bare" machine so that software executing 30 within a VM executes as if it were the sole entity executing on the computer.

In order to accomplish this emulation it is necessary for some operations within a VM to be trapped and emulated by the VMM. The VMM may perform a sequence of operations 35 on simulated hardware resources in order to maintain the illusion that a VM is actually interacting with real hardware. Transitions from a VM to the VMM and back will occur with some frequency, depending upon the number of tasks which the VMM must emulate for the VM. For example, a 40 VMM must trap and emulate attempts to configure hardware devices. This may be achieved by the VMM via simulated hardware registers in system memory.

When executing "real-time" applications, computations upon data that is available at one substantially predeter- 45 mined time should be completed by another substantially predetermined time. An OS that schedules a real-time application with sufficient frequency and for sufficient duration that the real-time application is able to complete its computations before their respective deadlines is said to have 50 received adequate scheduling Quality of Service (QoS). Similarly, a VMM that includes a VM and a real-time OS (RTOS) provides adequate scheduling QoS when real-time applications and the VMs complete execution before respective deadlines. OSs and VMMs should schedule the com- 55 puting resources of their real or virtual machine in such a fashion as to ensure that real-time applications receive adequate scheduling QoS.

Many current generation microprocessors such as, for example, the Intel® Pentium® 3 and 4 microprocessors 60 include superpipelined out of order machines where instructions need not be executed in strict program order. While such processors typically have a number of independent execution units, they only fetch instructions from a single instruction stream. Some microprocessors, including some 65 future members of the Pentium® family of processors, will have the ability to simultaneously fetch instructions from

2

two or more instruction streams. These instruction streams are generally called threads because they correspond to threads scheduled by the system software. Microprocessors that simultaneously fetch instructions from two or more instruction streams are variously referred to as "hyperthreaded", "multi-threaded" or "symmetric multi-threaded." On hyper-threaded microprocessors the instruction fetch units are controlled by "hardware contexts", which include both a stack pointer and an instruction pointer, a set of standard processor registers plus any additional state information necessary such as, for Pentium® family processors, control registers and translation look-aside buffer (TLB) tag bits. On out-of-order processors the nominal processor registers will generally be dynamically allocated from a pool of renameable registers, so that the actual static hardware context may be little more than a stack pointer, instruction pointer and a few control registers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a conceptual diagram of the components involved in the invention described herein.

FIG. 2 illustrates a computer system in which one embodiment of the invention can be practiced.

FIG. 3 illustrates one embodiment of a flow of actions taken by a virtual machine manager.

FIG. 4 illustrates a more detailed flow of actions of one embodiment of a virtual machine manager.

DESCRIPTION

In many processors used in various kinds of computing devices, including personal computers, a virtual machine manager (VMM) may be implemented and used to manage multiple virtual machines (VMs) that are used to provide an environment for multiple operating systems to concurrently execute. The VMM provides emulation assistance to the VMs so that software (e.g., an operating system) in each VM believes that it has sole access to and thus control of the entire computing device. In reality, the VMM shares the resources of the computing device (e.g., the processor, memory and disk drive(s)) among the multiple VMs based on the respective requirements of the software executing in each VM and the availability and suitability of system and processor resources. Thus, there may be significant overhead incurred in switching among the various VMs. According to a method described herein, the VMM may bind certain VMs to certain hardware contexts in a hyper-threaded processor. According to the methods described herein, in certain situations, it may be beneficial to bind one or more VMs, particularly real-time VMs, to one or more hardware contexts for reasons including, but not limited to, maximizing efficiency and minimizing latency and response time.

Real-time virtual machines (RTVMs) are virtual machines that contain software applications that perform computations that must complete before a deadline or deadlines as measured according to an external reference clock (i.e., a so-called "wall clock"). Among the applications that an RTVM might contain are streaming media applications, including audio and video applications, digital signal processing and communications applications, including modem and networking applications. RTVMs may also be used in other instances. Because of the fine grained machine switch requirements placed on a virtual machine system by RTVMs, an undesirable amount of overhead may be generated when the VMM switches between various VMs and RTVMs. By binding RTVMs, and, in some instances, nonUS 7,296

3

real-time VMs, to dedicated hardware contexts on a hyperthreaded processor, the overhead associated with such switching is reduced and performance of the virtual machine system is improved. Although the term "binding" is used herein, binding includes and/or is synonymous with, for 5 example, but not limited to, assigning, aggregating, designating, allocating, distributing, or otherwise establishing and/or managing the relationship between VMs and hardware contexts.

FIG. 1 illustrates a conceptual diagram of the components 10 involved in the invention described herein. In one embodiment, one or more virtual machines 110 and one or more real-time virtual machines 120 are managed by VMM 130. VMM 130 may permanently allocate some of hardware contexts 140 to specific virtual machines 110 and/or real- 15 time virtual machines 120, and may dynamically allocate other hardware contexts to other virtual machines. Generally, a hardware context may be defined by various data required by a processor to execute a software task. In one embodiment, hardware contexts 140 may include an instruc- 20 tion pointer, a stack pointer, control registers, a microarchitecture to fetch, a micro-architecture to claim renameable registers and a micro-architecture to dispatch to shared execution units. The shared execution units may be an adder, a floating point multiplier accumulator (FMAC), and other 25 execution units.

FIG. 2 illustrates a computer system in which one embodiment of the invention can be practiced. In various embodiments, the methods described herein may be implemented in any processor in any type of computing device, 30 including personal computers, personal digital assistants (PDAs), servers, workstations, cellular telephones, laptops, computing tablets, and the like. In one embodiment, computer system 200 includes processor 210, system memory 220, storage device 230, graphics controller 240 and Uni- 35 versal Serial Bus (USB) host controller 250 all coupled to bus 260. In various embodiments, one or more instances of these components, as well as other well-known components may be included in personal computer 200. Personal computer 200 may also include peripheral buses such as Periph- 40 eral Component Interconnect (PCI), accelerated graphics port (AGP), Industry Standard Architecture (ISA) bus, I.E.E.E. 1394 (aka, Firewire), etc. in addition to or in place of USB host controller 250. In one embodiment, storage device 230 may be any machine readable medium such as, 45 for example, optical and magnetic disk drives such as floppy disks, hard disks, compact disk read-only memory (CDROM) readable and writeable compact disk (CD-RW), stick and card memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, and the 50 like, whether internal, external, accessible locally or remotely via a network, and accessible via electrical, acoustic, optical or other forms of propagated signals (e.g., carrier waves, initiated signals, digital signals, etc.).

In various embodiments, the methods described herein 55 may be implemented as software, such as VMM software 232 stored on storage device 230. When executed by processor 210, VMM software 232 is stored as VMM 222 in memory 220. When managing real-time virtual machines, the hardware contexts and the real-time virtual machines 60 themselves may be stored as RTVM 226 in memory 220, and may be stored in and/or swapped out to storage device 230 as RTVM 236. As shown in FIG. 2, while some RTVMs (such as RTVM-2, RTVM-3, and others through RTVM-Q) may be stored in memory, other RTVMs (such as RTVM-1, 65 RTVM-4, and others through RTVM-P) may be concurrently stored in a storage device, such as storage device 230.

,267 B2

4

In one embodiment, the software executing on personal computer 200 and in the virtual machines may have access to and communicate with users of personal computer 200 by presenting text and images via graphics controller 240 which is coupled to display 242. Similarly, a user of personal computer 200 may provide input to those programs executing as virtual machines via keyboard 252 and mouse 254 coupled to USB host controller 250.

The processor 210 represents a processing unit of any type, including embedded processors, micro-controllers, digital signal processors, superscalar computers, vector processors, single instruction multiple data (SIMD) computers, complex instruction set computers (CISC), reduced instruction set computers (RISC), very long instruction word (VLIW) computers, hybrid architecture processors, and the like. In one embodiment, the processor 210 is compatible with the 32 bit Intel Architecture (IA) processor specification, known as IA-32. In another embodiment, the processor may be compatible with other instruction sets and/or processor architectures, including the 64 bit Intel Architecture known as IA-64. For further information regarding IA-32 and IA-64 see IA-32 Intel Architecture Software Developer's Manual, rev. 2 (February 2001) and Intel IA-64 Architecture Software Developer's Manual, rev. 1.1 (July 2000) available from Intel Corporation of Santa Clara, Calif. The processor 210 may contain a number of control registers to support memory management tasks such as virtual memory and cache memory. These tasks may include paging and segmentation. In various embodiments, personal computer 200 may include two or more processors like processor 210.

FIG. 3 illustrates one embodiment of a flow of actions taken by a virtual machine manager. The VMM first evaluates the bandwidth and latency requirements of one or more real-time virtual machines, as shown in block 310. Bandwidth and latency may be described as resource requirements of a virtual machine. Bandwidth is referred to by the variable X, and latency is referred to as the variable Y. Bandwidth refers to the amount of computing resources such as memory and other devices that are required by the particular virtual machine, and latency refers to how frequently the virtual machine requires access to the processor for execution. In one embodiment, bandwidth may be a tuple of values between 0 and 1, inclusive, which represent the fraction of corresponding resources the VM requires. In one embodiment, the tuple may be a quad tuple in which each element represents the fraction or percentage of processor, memory, display and disk resources required. For example, the tuple (0.5, 0.25, 0, 0.1) could represent a VM which requires 50% of the processor cycles, 25% of the system memory, 0% of the display (i.e., this VM is non-interactive) and 10% of the system disk bandwidth. The size of the tuple may vary depending on the components of a particular system. The resources represented in the tuple are not limited and are based on the hardware components of a particular system. In one embodiment, latency may refer to a period such as, for example, five milliseconds, or fifty microseconds, etc. which represents the longest duration for which the VM can be "held off' or delayed from execution. The VMM determines whether any real-time virtual machines are candidates for binding to one or more hardware contexts, as shown in block 320. The VMM binds one or more of the binding candidates; that is, real-time virtual machines, to one or more hardware contexts, as shown in block 330. Although the VMM is described in this paragraph as functioning solely with real-time virtual machines, the VMM may apply this same flow of execution to non-real