Over the years, a variety of techniques have been used for executing multiple software modules within a computer system. Early computer systems could execute multiple software programs, but they could only execute one program at a time. For example, such computers might load one program into memory and execute it to completion, or other termination, before proceeding to a subsequent program that would then be loaded into memory and executed. As another example, various multi-tasking operating systems (OSs) enable multiple programs (or selected portions thereof) to be loaded into memory at one time, and to be executed in an alternating manner, according to a scheduling algorithm. Also, some processors include multi-threading capabilities which enable multiple threads of one or more programs to be executed simultaneously on a single processor. Finally, multi-processor computer systems have also become commonplace where each of the multiple processors can execute one or more threads, all at the same time.
Such computer systems generally attempt to isolate code and data of different software modules from each other, so that, for example, one software module cannot interfere with the execution of another software module by altering its code or data. Such isolation may be provided for code and/or data that is stored on a hard drive (or other secondary data storage means) and/or that is resident in main memory (or other primary data storage means).
As one example of the isolation of code and data, many computer systems implement a virtual addressing mechanism in which different software modules within the computer system have different virtual address spaces, with each virtual address space being mapped to different portions of physical address space of the computer system. As such, virtual addresses of a given software module are only mapped to physical addresses that contain code or data of that particular software module. Thus, although a given software module may access every memory location in its own virtual address space; it will only be able to access its own code and data (assuming that there is no shared memory). Thus, a virtual addressing mechanism provides some isolation between code and data of multiple software modules in a computer system. Various other mechanisms may also be implemented in such computer systems to isolate the code and/or data of multiple software modules from one another.
FIG. 1 illustrates computer system 2A that has multiple software modules. Computer system 2A includes system hardware (system H/W 100A), an operating system (OS 20A), a first software application (APP 40A) and a second software application (APP 40B). System H/W 100A may be conventional hardware based on, for example, the x86 platform, and OS 20A may be, for example, a Windows OS or a Linux OS. APPs 40A and 40B may be any applications designed to run on system H/W 100A and OS 20A. OS 20A also includes a set of drivers (DRIVERS 29A) which may be conventional drivers for OS 20A, possibly including one or more drivers from a company that is different from the OS vendor.
OS 20A, in conjunction with system H/W 100A, attempts to isolate the code and data of APPs 40A and 40B from one another. For example, OS 20A and system H/W 100A may implement a virtual addressing mechanism, as described above. As illustrated in FIG. 1, implementing such a protection mechanism may be characterized as establishing an isolation barrier (indicated by dotted line) 80B between APPs 40A and 40B, thereby preventing (or at least hindering) one application from accessing the code and data of the other application. There may also be some code and/or data that are shared explicitly or transparently between APPs 40A and 40B. Techniques are known for allowing such sharing of code and data while maintaining isolation between APPs 40A and 40B. OS 20A also establishes an isolation barrier (indicated by dotted line 80A) between OS 20A and all applications in computer system 2A, including APPs 40A and 40B.
Machine virtualization provides certain advantages in establishing OS isolation barriers and application isolation barriers. A virtual machine (VM) is a software abstraction—a “virtualization”—of an actual or an abstract physical computer system. The VM runs as a “guest” on an underlying “host” hardware platform. Guest software, such as a guest OS and guest applications, may be loaded onto the virtual machine for execution. The guest OS may, but need not, be the same as an OS or other system software running at a system level in the host computer system. For example, in one known type of machine virtualization, a Windows OS may be run in a VM even though an OS used to handle I/O (input/output), memory management, etc., on the host computer might be a Linux OS. Also, as long as a suitable interface is provided between a VM and a host hardware platform, a user of a VM might not be aware that s/he is not using a “real” computer, that is, a computer system with hardware dedicated exclusively to her/his use.
FIG. 2 illustrates computer system 2B in which multiple VMs are implemented. Computer system 2B includes system hardware (system H/W 100B) which may be conventional hardware such as hardware based on the x86 platform. System H/W 100B may be substantially the same as system H/W 100A of FIG. 1, or it may be different. Virtualization software 200A executes on system H/W 100B, and supports a plurality of VMs, such as a first VM (VM 300A) and a second VM (VM 300B), in a known manner. Virtualization software 200A may comprise a Virtual Machine Monitor (VMM), for example, a VMM implemented in a virtualization product of VMware, Inc., Palo Alto, Calif. Such a VMM and other components of virtualization software 200A are described in greater detail below.
In supporting VM 300A, virtualization software 200A virtualizes system hardware (VIRTUAL H/W 310A), which VIRTUAL H/W 310A may be based on an existing hardware platform such as the x86 platform. OS 20B, along with a set of drivers 29B, run on VIRTUAL H/W 310A. OS 20B may be any OS designed to run on VIRTUAL H/W 310A. For example, if VIRTUAL H/W 310A is based on the x86 platform, OS 20B may be a Windows OS or a Linux OS. In addition, the set of drivers 29B may be conventional drivers for OS 20B. As further shown in FIG. 2, a first software application (APP 40C) and a second software application (APP 40D) run on OS 20B. APPs 40C and 40D may be any applications designed to run on VIRTUAL H/W 310A and OS 20B. Similar to OS 20A of FIG. 1, OS 20B, in conjunction with VIRTUAL H/W 310A, attempts to isolate the code and data of APPs 40C and 40D from one another, thereby establishing an OS isolation barrier (indicated by dotted line 80B) between APPs 40C and 40D. Also similar to OS 20A of FIG. 1, OS 20B, again in conjunction with VIRTUAL H/W 310A, establishes an OS isolation barrier (indicated by dotted line 80A) between OS 20B and all applications in VM 300A, including APPs 40C and 40D. Thus, VM 300A may operate substantially the same as computer system 2A shown in FIG. 1, except that VIRTUAL H/W 310A is a software abstraction of hardware, created by virtualization software 200A instead of physical hardware.
Virtualization software 200A supports VM 300B, including virtual system hardware (VIRTUAL H/W 310B), OS 20C, drivers 29C, and software applications (APPs 40E and 40F) in a manner similar to that of VM 300A and its corresponding component elements. Similar to OS 20B, OS 20C, in conjunction with VIRTUAL H/W 310B, attempts to isolate the code and data of APPs 40E and 40F from one another, establishing an OS isolation barrier (indicated by dotted line 80B) between APPs 40E and 40F. Also similar to OS 20B, OS 20C, in conjunction with VIRTUAL H/W 310B, establishes an OS isolation barrier (indicated by dotted line 80A) between OS 20C and all applications in VM 300B, including APPs 40E and 40F. Thus, VM 300B may also be substantially similar to computer system 2A, except that VIRTUAL H/W 310B is a software abstraction of hardware, created by virtualization software 200A instead of physical hardware.
Virtualization software 200A isolates VMs 300A and 300B in computer system 2B from one another. For example, virtualization software 200A allows software within VM 300A to access portions of physical memory in system H/W 100B, and allows software within VM 300B to access other portions of the physical memory. Virtualization software 200A maps attempted memory accesses from the respective VMs 300A and 300B to different portions of the physical memory, ensuring that no memory address generated by software in one VM can access code or data of another VM. In a similar manner, virtualization software 200A maps attempted hard disk accesses from the respective VMs 300A and 300B to different portions of one or more hard disks in system H/W 100B, ensuring that one VM cannot access the hard disk space of another VM.
Virtualization software 200A also takes other precautions to isolate VMs 300A and 300B in computer system 2B from one another, and from virtualization software 200A itself. For example, commonly assigned, U.S. Pat. No. 7,281,102, Agesen et al., “Restricting Memory Access to Protect Data when Sharing a Common Address Space,” which is incorporated herein by this reference for all purposes, describes methods that may be used to enable a VMM to occupy a portion of a linear address space of a VM, while preventing the VM from accessing the memory of the VMM.
Various other methods may be used to enable virtualization software to coexist with VMs in a virtual computer system, while protecting or isolating the virtualization software from software within the VMs. Virtualization software 200A may also prevent software within VMs 300A and 300B from directly accessing certain hardware resources to further isolate the VMs from one another and from virtualization software 200A. For example, virtualization software 200A may prevent software within VMs 300A and 300B from directly accessing a Direct Memory Access (DMA) device to prevent the DMA device from accessing either hard disk space or memory of other VMs or of the virtualization software itself. Various other precautions may also be taken, depending on the particular implementation.
Thus, virtualization software 200A, in conjunction with system H/W 100B, may be said to establish a first isolation barrier (indicated by dotted line 280B) between VMs 300A and 300B and a second isolation barrier (indicated by dotted line 280A) between virtualization software 200A and all VMs in computer system 2B, including the VMs 300A and 300B. Isolation barriers 280A and 280B may be referred to as “virtualization barriers” because they are established through virtualization of hardware resources, such as virtualization of system memory.
USPTO Backgrounds
USPTO Backgrounds