BACKGROUND OF THE INVENTION

The invention generally relates to virtual machine management, and more particularly to efficient scheduling of virtual machines using processor state information.

Virtualization of machine resources has been of significant interest for some time; however, with processors becoming more diverse and complex, such as processors that are deeply pipelined/super pipelined, hyperthreaded, and processors having Explicitly Parallel Instruction Computing (EPIC) architecture, and with larger instruction and data caches, virtualization of machine resources is becoming an even greater interest.

Many attempts have been made to make virtualization more efficient. For example, some vendors offer software products that have a virtual machine system that permits a machine to be partitioned, such that the underlying hardware of the machine appears as one or more independently operating virtual machines (VM). Typically, a Virtual Machine Monitor (VMM) may be a thin layer of software running on a computer and presenting to other software an abstraction of one or more VMs. Each VM, on the other hand, may function as a self-contained platform, running its own operating system (OS), or a copy of the OS, and/or a software application. Software executing within a VM is collectively referred to as "guest software".

A typical VMM, which is considered the host of the VMs, may enhance performance of a VM by permitting direct access to the underlying physical machine in some situations. This may be especially appropriate when an operation is being performed in non-privileged mode in the guest software, which limits access to the physical machine or when operations will not make use of hardware resources in the physical machine to which the VMM seeks to retain control. The VMM may swap guest software state in and out of the processor, devices, memory, and the registers of the physical machine, while the processor may swap some state in and out during transitions between a VM and the VMM.

The conventional VM/VMM architecture rely on time-slicing between various VMs according to round-robin or other predetermined priority-based schemes. For example, a pre-determined allocated time period (or time quanta) for each VM may be stored in the memory to direct the VMM to periodically switch between the VMs based on the previously allocated time period for each VM. Round-robin or pre-determined priority-based schemes inherently fail to provide the VMM any control or authority regarding managing the VMs, as the VMM is limited to following the pre-determined plan or scheme. Stated differently, methods, apparatus, and systems, available today, are limited to round-robin or time-slicing of the VMs, and do not provide the VMM to intelligently swap between the VMs using processor state information including characteristics and/or history of the processor, characteristics and/or history of the guest software, characteristics and/or history of the VMs, and characteristics and/or history of the machine.

One solution proposed by VMWare, Inc. (VMWare) of Palo Alto, Calif., relies on OS thread-scheduling to use the VMM to swap between the VMs. The VMWare solution provides for running two or more operating systems, such as Linux and Microsoft Windows, on a single machine, using the facilities provided by the operating system that runs on the underlying hardware. This system relies on the OS scheduling policy to schedule the VMs. However, virtualization based on OS scheduling (for scheduling the VMs) is performed without the knowledge of the processor state or even the processor. Furthermore, as the VM functionality moves into hardware, the OS-based solutions that attempt to optimize context-switch intervals for processors will be less aware or even completely unaware of the processors and the context-switching for the processors. Furthermore, the OS-based solutions not only do not accommodate characteristics of different processors, but also do not accommodate characteristics of processors of a single family.

Neither the OS-based virtualization solution proposed by VMWare nor any of the other conventional solutions employ software and/or hardware-based state management mechanism to consider the processor state information to intelligently swap between the VMs in order to significantly improve machine performance, and to accommodate rapidly changing processor architecture and characteristics.

DETAILED DESCRIPTION

A method and apparatus are described for virtual machine management. Broadly stated, embodiments of the present invention provide for efficient scheduling of virtual machines using processor state information.

A system, apparatus, and method are provided for managing virtual machines using processor state information and other related information. According to one embodiment, a software and/or hardware-based state management unit is provided to monitor the state of the processor. The information relating to the processor may be gathered and evaluated. According to one embodiment, based on the processor state information gathered, a first virtual machine‘s (VM) time for performing a certain task may be extended by allowing the first VM to run for a longer period of time than its pre-assigned time period (or time quanta) based on the central processing unit‘s (CPU) time allocation. According to another embodiment, the time period of the first VM may be suspended early and the first VM may be switched a second VM to allow the second VM to execute on the CPU. According to one embodiment, the state management unit may continue to gather processor state information, until the processor state information triggers early suspension or further extension of the time quanta allocated to each of the VMs.

According to one embodiment, virtual machine management using the processor state information may be performed with multiple processors. Each of the multiple processors may have their own corresponding processor state, which may be continually monitored by the state management of the Virtual Machine Manager (VMM). Furthermore, according to one embodiment, virtual machine management using the processor state information may also be performed using one or more hyperthreaded processors, with each hyperthreaded processor having multiple threads on one or more logical processors. According to one embodiment, processor state of a single hyperthreaded processor may be monitored. According to another embodiment, multiple processor states may be monitored, where each of the multiple processor states corresponds to each of the multiple hyperthreaded processors. A typical hyperthreaded processor may include a single physical processor with multiple logical processors each sharing the physical execution resources.

FIG. 1 is a block diagram illustrating an embodiment of a computer system. According to one embodiment, the computer system or physical machine100?may include a personal computer (PC), a mainframe computer, a handheld device, a workstation, a server, a portable computer, a set-top box, an intelligent apparatus or system or appliance, a virtual machine, or any other computing system or device. As illustrated, the computer system?100?may include a bus or other communication device?102?for communicating information, and a processing device, such as processor?110, coupled with the bus102?for processing information. Computer system?100?may further include a random access memory (RAM) or other dynamic storage device?104(referred to as main memory), coupled with the bus?102?for storing information and instructions to be executed by processor?110. Main memory?104may be used for storing temporary variables or other intermediate information during execution of instructions by processor?110. Computer system?100also includes a read only memory (ROM) and/or other static storage device?106?coupled with bus?102?for storing static information and instructions for processor?110. Main memory?104?may include a type of machine medium readable by processor?110. Main memory?120?may store instructions and/or data for performing the execution of various embodiments of the present invention.

FIG. 2 is a block diagram illustrating an embodiment of a virtual-machine environment. According to one embodiment, as illustrated, the computer system or physical machine?100?(machine) may include a host platform or hardware platform (platform)?224. The platform?224?may include a processor110?and other hardware devices and components, such as a programmable interrupt controller, a network card, a graphics card, and a disk controller (not shown). The machine?100?may include a virtual machine manager (VMM)?202, which may present a virtualized interface with some or all of the hardware devices and components of the platform?224?for each of the virtual machines (VM)?204-208. The processor?110?may be capable of, for example, executing an operating system (OS) or the VMM?202.

According to one embodiment, the machine?100?may include a personal computer (PC), a mainframe computer, a handheld device, a workstation, a server, a portable computer, or any other computing system or device. According to one embodiment, processor?110?may include any processor capable of executing software, such as a microprocessor, digital signal processor, microcontroller, or the like. The processor?110?may also include microcode, macrocode, software, programmable logic or hard coded logic for performing the execution of various embodiments of the present invention.

According to one embodiment, using a VMM?202, the machine?100?may be partitioned, such that the underlying hardware of the machine may appear as one or more independently operating VMs?204-208. The VMM?202?may run on a machine?100?and present to other software an abstraction of the VMs204-208. Each VM may function as a self-contained platform, running its own operating system (OS) and/or application software, which may be collectively referred to as "guest software."

According to one embodiment, the guest software running in each VM?204-208?may include an OS?218-222, and software applications?212-216. According to one embodiment, the OS?218-222?may be expected to access physical resources (e.g., processors, registers, memory, and I/O devices) within the VMs?204-208?on which the OS?218-222?may be running and to handle various events including interrupts generated by various devices during the operation of the VMs?204-208. OS?218-222?may include standard OS, such as Unix, Linux, and Microsoft Windows. Similarly, application software212-216?may include standard application software, such as Microsoft Word, Microsoft Explorer, Microsoft Outlook, and Web application servers, such as IBM WebSphere.

According to one embodiment, the machine?200?may include a host OS, such as OS?226. The host OS?226?may be one of the standard OS, such as Unix, Linux, and Microsoft Windows. According to one embodiment, the host OS?226?may be used to have the VMM?202?operate as part of the kernel of the host OS?226. Having the VMM?202?as part of the host OS?226, the VMs?204-208?may run on a combination of the host OS?226?and the VMM?202. According to another embodiment, the VMM?202?may operate on the bare hardware platform?224?and the VMs?204-208?may run on the VMM?202. According to one embodiment, various settings, combinations, and functions of the OS, such as OS?218-222?and?226, are contemplated. For example, the machine?200?may include OS?218-222?as the host OS, or may include the OS?226?as the host OS, or may include the like, or may include a combination thereof.

According to one embodiment, the VMM?202?may host software for the VMs?204-208?and may manage the VMs?204-208?according to the data stored in the memory of the machine?100, or according to the indicators provided to the VMM?202?by the machine?100. According to one embodiment, the VMM202?may swap the software?212-222?state in and out of the processor?110, devices, memory and the registers of the machine as needed. The processor?110?may swap some state in and out during transitions between a VM?204-208?and the VMM?202. Furthermore, according to one embodiment, the VMM?202?may enhance the performance of a VM?204-208?by permitting direct access to the underlying machine?100.

Typically, a transition from the VMM?202?to one of the VMs?204-208?(e.g., to the Software?212-222) may be referred to as "entry" or "VM-entry," while a transition from one of the VMs?204-208?to the VMM?220?may be referred to as "exit" or "VM-exit." Collectively, entries and exits may be referred to as "transitions" or "VM-transitions." According to one embodiment, a VMM?202?may initiate a VM-entry by executing a particular instruction to cause the VM-entry. A VM-exit may be explicitly requested by a VM?204-208, for example, by executing a special instruction to generate the VM exit. According to another embodiment, a VM?204-208?may not explicitly request a transition, but instead an event or occurrence, such as protection fault, interrupt, or an instruction executed by a VM?204-208, may require a VM-exit as determined by the virtual machine management of the machine?100. For example, if a particular control bit is set, then the execution of an instruction may cause a VM-exit, or occurrences of a non-maskable interrupt may cause VM-exits.

According to one embodiment, the VM-entry controls may be represented as a bit string having a length of 7 bits having each bit location within the bit string identifying or representing an action or non-action regarding a particular element or component of the machine?100?or machine state. The VM-exit controls, on the other hand, may be represented as a bit string having a length of 4 bits.

According to one embodiment, the processor?110?may act on various elements of the machine state of the machine?100. The machine state may be associated with a variety of architectural components, such as the processor?110, Input/Output (I/O) devices, and chipset. Machine state may include general purpose and floating-point registers (e.g., in the Instruction Set Architecture (ISA) of Intel‘s Pentium IV referred to as Intel Architecture-32 (IA-32) ISA, and the like), control registers (CR) (e.g., in the IA-32 ISA, CR0, CR3; and the like), instruction pointers (WP) (e.g., in the IA-32 ISA, Extended IP, and the like), processing flags (FLAGS) (e.g., in the IA-32 ISA, Extended FLAGS, and the like), model-specific registers (MSR) (e.g., in the IA-32 ISA, and the like), segment registers (e.g. in the IA-32 ISA, and the like, which may include selector, base, limit, and byte fields), additional internal (architectural or non-architectural) machine state (e.g., sleep state, interpretability information, state-machine state), memory management related state (e.g., translation look aside buffer (TLB) contents), chipset registers, I/O device state, and others. The machine?100?may employ a flexible architecture for implementing mechanisms that are used when managing the loading and/or storing of machine state during transitions (e.g., entries and exits) between the VMM?202?and the VMs?204-208.

According to one embodiment, the VMM?202, though typically implemented in software, may emulate and export a machine interface to higher-level software. Such higher level software may include a standard or real-time OS?218-222, or may be a highly stripped down operating environment with limited OS functionality, or may not include traditional OS facilities, and the like. According to one embodiment, for example, the VMM?202?may be run within, or on top of, another VMM.

According to one embodiment, the processor?110?may execute the VMM?202, and the VMM?202?may be implemented in software or exports-a bare machine interface to higher-level software. The interface may be exported as one or more VMs?204-208?and may mirror the actual platform?224, e.g., the processor?110?or the machine?100, so that it is virtualized. According to another embodiment, the interface exported by the VMM?202?may differ in some or all respects so that a different host platform may be emulated.

FIG. 3 is a block diagram illustrating an embodiment of a network environment. According to one embodiment, a computer system or physical machine100?(machine) may include a single machine, or multiple machines coupled with each other directly, or via a network or device, or via other physical and/or logical links.

According to one embodiment, as illustrated, the machine?100?may include a modem?304?and/or a network interface?306. The machine?100, for example, may be coupled or communicatively connected with other remote machines?308-312?via a network?314?using the modem?304, or the network interface?306, or the like. The network?314?may include a physical network, a logical network, a wide area network (WAN), a local area network (LAN), the Internet, an intranet, or the like. As will be appreciated by one skilled in the art, any communication via network?314?may include the use of a variety of wired and/or wireless carrier and protocols, including radio frequency (RF), satellite, microwave, Bluetooth, optical, infrared, cable, laser, or the like.

FIG. 4 is a block diagram illustrating an embodiment of virtual machine management. According to one embodiment, as illustrated, the computer system or physical machine?100?(machine) may include a host platform or hardware platform (platform)?224. The platform?224?may include a processor?110?and other hardware devices and components, such as a programmable interrupt controller, a network card, a graphics card, and a disk controller. The machine?100?may include a virtual machine manager (VMM)?202, which may present a virtualized interface with some or all of the hardware devices and components of the platform?224?for each of the virtual machines (VM)?204-208. The processor?110?may be capable of, for example, executing an operating system (OS) or the VMM?202. Typically, the VMM?202?may serve as the host of the VMs?204-208?for swapping between the VMs?204-208. According to one embodiment the VMM?202?may be implemented, for example, as hardware on the chipset or as software, or as a combination thereof. The processor?110?may serve as the host platform and may include one or more processors, including hyperthreaded processors.

According to one embodiment, using a VMM?202, the machine?100?may be partitioned, such that the underlying hardware of the machine may appear as one or more independently operating VMs?204-208. The VMM?202?may run on a machine?100?and present to other software an abstraction of the VMs204-208. Each VM may function as a self-contained platform, running its own operating system (OS) and/or application software, which may be collectively referred to as "guest software."

According to one embodiment, the guest software running in each VM?204-208?may include an OS?218-222, and software applications?204-208. According-to one-embodiment, the OS?218-222?may be expected to access physical resources (e.g., processors, registers, memory, and I/O devices) within the VMs?204-208?on which the OS?218-222?may be running and to handle various events including interrupts generated by various devices during the operation of the VMs?204-208. OS?218-222?may include standard OS, such as Unix, Linux, and Microsoft Windows. Similarly, application software212-216?may include standard application software, such as Microsoft Word, Microsoft Explorer, Microsoft Outlook, and Web application servers, such as IBM WebSphere.

According to one embodiment, the machine?200?may include a host OS, such as OS?226. The host OS?226?may be one of the standard OS, such as Unix, Linux, and Microsoft Windows. According to one embodiment, the host OS?226?may be used to have the VMM?202?operate as part of the kernel of the host OS?226. Having the VMM?202?as part of the host OS?226, the VMs?204-208?may run on a combination of the host OS?226?and the VMM?202. According to another embodiment, the VMM?202?may operate on the bare hardware platform?224?and the VMs?204-208?may run on the VMM?202. According to one embodiment, various settings, combinations, and functions of the OS, such as OS?218-222?and?226, are contemplated. For example, the machine?200?may include OS?218-222?as the host OS, or may include the OS?226?as the host OS, or may include the like, or may include a combination thereof.

According to one embodiment, the machine?100?may include a personal computer (PC), a mainframe computer,sa handheld device, a workstation, a server, a portable computer, a set-top box, an intelligent apparatus or system or appliance, a virtual machine, or any other computing system or device. According to one embodiment, processor?110?may include any processor capable of executing software, such as a microprocessor, a hyperthreaded processor, a digital signal processor, a microcontroller, or the like, or a combination thereof. The processor?110?may also include microcode, macrocode, software, programmable logic, hard coded logic, or the like, or a combination thereof for performing the execution of various embodiments of the present invention. Furthermore, according to one embodiment, the machine?100?may include one or more processors including one or more hyperthreaded processors.

According to one embodiment, the VMM?202?may host software for the VMs?204-208?and may manage the VMs?204-208?according to the data stored in the memory of the machine?100, or according to the indicators provided to the VMM?202?by the machine?100. However, according to one embodiment, the data stored may be dynamically updated and stored, and referred to as history, based on one or more factors. The one or more factors may include the following: how a particular task is performed by a particular VM?204-208, the overall performance of the VMs?204-208, the VM?204-208?compatibility with the corresponding software application?212-216, event monitoring (EMON) data, data from other hooks on the processor?110, characteristics and history of the VMs?204-208?(also referred to as "VM profile"), and characteristics and history of the processor?110?(also referred to as "processor profile"). EMON data, also known as E86MON data, may include processor-specific counters and registers dynamically indicating information about the inner workings of the processor?110.

According to one embodiment, the machine?100?may include multiple processors?110, including multiple hyperthreaded processors?110, to read the stored data to effectively and efficiently manage the VMs?204-208?and the Software?212-222. A hypethreaded processor includes a physical processor with multiple threads or logical processors that give the appearance of multiple processors and share the physical execution resources. The VMM?202may swap the Software?212-222?state in and out of the processor?110, devices, memory and the registers of the machine as needed. The processor110?may swap some state in and out during transitions between a VM?204-208?and the VMM?202. Furthermore, according to one embodiment, the VMM202?may enhance the performance of a VM?204-208?by permitting direct access to the underlying machine?100.

According to one embodiment, the machine?100?may include a state monitoring/management engine or unit (state management unit)?402?to monitor the processor state?404?of the processor?110. According to one embodiment, the state management unit?402?may be hardware implemented on the processor?110?or a chipset. According to another embodiment, the state management unit?402?may be software implemented on the VMM?202. The state management unit, according to another embodiment, may be a combination of software and hardware. The VMM?202, using the state management unit?402?may manage the VMs?204-208?based on the processor state information gathered by monitoring the processor state?404?of the processor110. According to one embodiment, the processor state information including the processor profile and/or VM profile may provide the VMM?202?with the ability to intelligently manage the VMs?204-208.

According to one embodiment, the VM schedule operation, e.g., when to swap between the VMs?204-208, may be determined based on the processor state information gathered by monitoring the processor state?404. Stated differently, the swapping or altering between the VMs?204-208?may be dynamic, e.g., swapping between the VMs?204-208?based on the characteristics of the processor?110?rather than based on predetermined time slices (time quantum) assigned to the VMs?204-208. Although, according to one embodiment, a time quanta may be allocated to each of the VMs?204-208, the time allocation based on a predetermined criteria or scheme may be subject to change based on the processor state information.

According to one embodiment, monitoring the processor state?404, for example, may include monitoring instruction and data caches, instruction pipelines (traditional, Explicitly Parallel Instruction Computing (EPIC), Out-Of-Order execution (OOO)), branch target buffers (BTB), and cache line predictors. For example, if current VM?204?has recently flushed the entire data cache to the memory and its time quanta has not yet expired, the VMM202, according to one embodiment, may switch to another VM?206, rather than allowing the processor?110?to begin prefetching data that the current VM204?may not use before its quanta expires. In such circumstances, the switch from the current VM?204?to the next VM?206?may save important time and memory-bus bandwidth making the machine?100?more efficient.

According to one embodiment, for example, by watching or monitoring the state of the BTB for the current VM‘s?204?execution stream, the VMM?202may change the time quanta of VM?204, running in a tight loop, allowing the BTB and the instruction cache to be more optimally reused, as opposed to switching to another VM, e.g., VM?206?or VM?208, which may not benefit from the data. According to another embodiment, for example, the BTB and the instruction pointer may indicate the end of a loop, and the VMM?202?may switch from VM?204?to VM?206?earlier than as previously determined to, for example, pay back the VM?206?for previous preemptions.

According to one embodiment, the machine?100?may include a software-based. VMM?202?having a software-based state management unit?402. According to another embodiment, the VMM?202?and the state management unit?402?may be hardware-based implemented on the processor?110?or the chipset. With regard to the software-based VMM?202, the state management unit?402?may monitor the processor?110?and the processor state?404?to gather the processor state information from, for example, EMON registers and other hooks (current and planned) into the processor?110. With regard to the hardware-based VMM?202?and the state management unit?402, according to one embodiment, direct processor-related data collection may be employed, such as accessing the hooks into the processor?110?to obtain the processor state information.

According to one embodiment, using the processor state information may include using or taking advantage of any information relating to the processor‘s?110?history of execution or predicted future execution in branch prediction or speculative execution. According to one embodiment, the processor profile used by the VMM?202?may include processor history as recent as present or concurrent event, or as distant as since the last powering-on of the machine?100. Furthermore, the processor profile or the use of the processor profile may be compatible with recent processor-related technologies and enhancements and may make the processors?110?even more efficient with intelligent scheduling, optimization, and management of the VMs?204-208.

The managing of the VMs?204-208, according to one embodiment, may provide a framework and guidance for software tweaking and optimization by using the processor state information. According to one embodiment, intelligent scheduling of the VMs?204-208?may provide for tweaking and optimization of both the time quanta allocated to each of the VMs?204-208?and the surrounding processor state?404?in each of the VM‘s?204-208execution.

Furthermore, the processor?110?may be more diverse and more complex, such as deeply pipelined or super-pipelined, out-of-order, Explicitly Parallel Instruction Computing (EPIC), or having large instruction and data caches, the intelligent scheduling and managing of the VMs?204-208, according to one embodiment, may provide a notable performance improvement to such and future processors by accommodating unique characteristics of a particular processor?110?and intelligently choosing the time of context switches between the processor-based VMs?204-208.

FIG. 5 is a flow diagram illustrating an embodiment of a virtual machine management process. First, according to one embodiment, the state monitoring/management engine or unit (state management unit) of a virtual machine manager (VMM) may monitor the processor state of a processor at processing block?502. The state management unit may be implemented as hardware or software, or as a combination thereof. The VMM may serve as the host of the virtual machines (VMs) of the computer system or physical machine (machine). According to one embodiment, the VMM may be considered hosting software for the VMs and may manage the VMs according to the data stored in the memory of the machine, or according to the indicators provided to the VMM by the machine.

According to one embodiment, the state management unit of the VMM may gather the processor state information as it monitors the processor state of the processor at processing block?504. The processor state information, according to one embodiment, may include characteristics and history of the processor ("processor profile") and/or characteristics and history of the VMs ("VM profile") as indicated by the processor state. The processor state information may be used to intelligently schedule and manage the VMs. According to one embodiment, processor state information may include information regarding instruction and data caches, various instruction pipelines, branch target buffers, and the like.

According to one embodiment, the processor state information may be evaluated at processing block?506. Evaluating the processor state information may include evaluating the profiles of the processor and VMs, including, for example, evaluating the branch target buffer relating to the current VM execution. The history may include very recent history, such as an event occurring at the present instant, or very long history, such as the very first event since the powering-on of the machine noted in the processor state information. At decision block?508, whether there is any indication or event that would trigger a change in the amount of time allocated (time quanta) to each of the VMs is determined. If not, the processing continues with first gathering and then evaluating the processing state information at processing blocks?504?and?506, respectively. If yes, then, at decision block?510, whether time quanta assigned to a particular VM is to be increased based on the processor state information gathered and evaluated is determined. If yes, the time quanta initially assigned to a particular VM is increased at processing block?512. If not, time from the time quanta previously assigned to a particular VM is decreased at processing block?514.

According to one embodiment, a time quanta may be allocated to each of the VMs. The VMM may monitor and manage each of the VMs according to its previously assigned time quanta; for example, 1 millisecond (ms) of time quanta allocated to each of the VMs. However, according to one embodiment, using the state management unit of the VMM and by evaluating the processing state information may help the VMM intelligently determine whether the time quanta assigned to a particular VM be change, i.e., whether time be added to or decreased from the originally allocated time quanta; for example, decreasing time quanta to ? ms or increasing the time quanta to 1? ms.

Furthermore, for example, the VMM may provide more time to a certain VM, such as VM-1, if VM-l is performing a particular task, which, historically, based on the processor state information, is better performed by VM-1?than any of the other VMs. Conversely, if, historically, VM-2?is better at performing the same task, then, VM-1‘s time may be reduced by the VMM to transfer the task to VM-2. According to one embodiment, using the example of VM-l and VM-2?performing a particular task, the change may be made in the parameters, e.g., VM-l and VM-2?may be provided more or less time on a relatively permanent manner by changing the parameters, or the change may be regimented by the VMM every time the event, as mentioned in the example, occurs.

Stated differently, according to one embodiment, processor state information, including characteristics and history of the processor and the VMs, may be gathered at the processor level and used to manage the VMs. The processor state information may include profiles of the VMs indicating what the VMs have done in the past and what are they likely to do in the future under certain circumstances. The VM past, according to one embodiment, may include instantaneous or nearly instantaneous history of the VM, or historically what may have occurred since the powering-on of the machine. For example, with instruction data cache, if L1 cache is full of data and it has been traversing data by, for example, looping, the VMM may select to provide extra portion of the time clock to a particular VM to continue and finish the process rather than to eject all of the data from the L1 cache and later recreate the cache that is currently in an optimal state. With regard to a branch target buffer (BTB), for example, the VM history may provide the VMM with the information and history relating to a loop or course of execution of the BTB. By using the history, the processor may, for example, prefetch based on whether the answer will be yes or no according to the history. Stated differently, using the processor state information, a more refined decision may be made by intelligently selecting and managing the VMs. Such intelligent selection and management of the VMs may not only reduce cost, but may also enhance the performance of the machine.

According to one embodiment, the processor may perform the embodiments of the present invention by, for example, processing logic that may include hardware, such as circuitry, dedicated logic, programmable logic, microcode, or software, such as executing on a general purpose computer system or a dedicated machine, or a combination thereof. Furthermore, the machine?100?may include architecture flexible enough to implement components and/or mechanisms that may be used for virtual machine management, according to one embodiment.

FIG. 6 is a block diagram illustrating an embodiment of virtual machine management using multiple processors. According to one embodiment, as illustrated, the computer system or physical machine?100?(machine) may include a host platform or hardware platform (platform)?224. The platform?224may include processors?110,?610?and other hardware devices and components, such as a programmable interrupt controller, a network card, a graphics card, and a disk controller. The machine?100?may include a virtual machine manager (VMM)?202, which may present a virtualized interface with some or all of the hardware devices and components of the platform?224?for each of the virtual machines (VM)?204-208. The processors?110,?610?may be capable of, for example, executing an operating system (OS) or the VMM?202. Typically, the VMM?202?may serve as the host of the VMs?204-208?for swapping between the VMs?204-208. According to one embodiment, the VMM?202?may be implemented as hardware on the chipset or the processor, or as software, or as a combination thereof.

According to one embodiment, the guest software running in each VM?204-208?may include an OS?218-222, and software applications?204-208. According to one embodiment, the OS?218-222?may be expected to access physical resources (e.g., processors, registers, memory, and I/O devices) within the VMs?204-208?on which the OS?218-222?may be running and to handle various events including interrupts generated by various devices during the operation of the VMs?204-208. OS?218-222?may include standard OS, such as Unix, Linux, and Microsoft Windows. Similarly, application software212-216?may include standard application software, such as Microsoft Word, Microsoft Explorer, Microsoft Outlook, and Web application servers, such as IBM WebSphere.

According to one embodiment, the machine?200?may include a host OS, such as OS?226. The host OS?226?may be one of the standard OS, such as Unix, Linux, and Microsoft Windows. According to one embodiment, the host OS?226?may be used to have the VMM?202?operate as part of the kernel of the host OS?226. Having the VMM?202?as part of the host OS?226, the VMs?204-208?may run on a combination of the host OS?226?and the VMM?202. According to another embodiment, the VMM?202?may operate on the bare hardware platform?224?and the VMs?204-208?may run on the VMM?202. According to one embodiment, various settings, combinations, and functions of the OS, such as OS?218-222?and?226, are contemplated. For example, the machine?200?may include OS?218-222?as the host OS, or may include the OS?226?as the host OS, or the like, or may include a combination thereof.

Although two processors?110,?610?are illustrated, the machine?110?may include more than two processors?110,?610. Furthermore, according to one embodiment, the two or more processors?110,?610?may be any one or a combination of any of the following: a microprocessor, a hyperthreaded processor, a digital signal processor, a microcontroller, and the like. According to one embodiment, the processors?110,?610?may include microcode, macrocode, software, programmable logic, hard coded logic, or the like, or a combination thereof, for, for example, performing the execution of various embodiments of the present invention. The machine?100, according to one embodiment, may include a personal computer (PC), a mainframe computer, a handheld device, a workstation, a server, a portable computer, a set-top box, an intelligent apparatus or system or appliance, a virtual machine, or any other computing system or device.

According to one embodiment, the machine?100?may include state monitoring/management engine or unit (state management unit)?402?hardware or firmware or software, or a combination thereof, implemented in or coupled with the VMM?202?or the processors?110,?610?to monitor the processor states?404,?604?of the processors?110,?610. According to one embodiment, the VMM?202?may be considered hosting software for the VMs?204-208and may manage the VMs?204-208?according to the data stored in the memory of the machine?100, or according to the indicators provided to the VMM202?by the machine?100.

According to one embodiment, the VMM?202?may host software for the VMs?204-208?and may manage the VMs?204-208?according to the data stored in the memory of the machine?100, or according to the indicators provided to the VMM?202?by the machine?100. According to one embodiment, the VMM202?may manage the VMs?204-208?based on the processor state information gathered by monitoring the corresponding processor state?404,?604?of each of the processors?404,?604. According to one embodiment, the processor state information may include, for example, characteristics and history of the processors?110,?610, characteristics and history of the VMs?204-208, event monitoring (EMON) data, and other hooks into the processors?110,610. EMON data, also known as E86MON data, may include processor-specific counters and registers dynamically indicating information about the inner workings of the processors?110,?610.

FIG. 7 is a block diagram illustrating an embodiment of virtual machine management using multiple hyperthreaded processors. According to one embodiment, as illustrated, the computer system or physical machine?100?(machine) may include a host platform or hardware platform (platform)?224. The platform?224?may include processors?110,?710?and other hardware devices and components, such as a programmable interrupt controller, a network card, a graphics card, and a disk controller. The machine?100?may include a virtual machine manager (VMM)?202, which may present a virtualized interface with some or all of the hardware devices and components of the platform?224?for each of the virtual machines (VM)?204-208. The processors?110,?710?may be capable of, for example, executing an operating system (OS) or the VMM?202. Typically, the VMM?202?may serve as the host of the VMs?204-208?for swapping between the VMs?204-208. According to one embodiment the VMM?202?may be implemented as hardware on the chipset or the processor, or as software, or as a combination thereof.

According to one embodiment, the guest software running in each VM?204-208?may include an OS?218-222, and software applications?204-208. According to one embodiment, the OS?218-222?may be expected to access physical resources (e.g., processors, registers, memory, and I/O devices) within the VMs?204-208?on which the OS?218-222?may be running and to handle various events including interrupts generated by various devices during the operation of the VMs?204-208. OS?218-222?may include standard OS, such as Unix, Linux, and Microsoft Windows. Similarly, application software212-216?may include standard application software, such as Microsoft Word, Microsoft Explorer, Microsoft Outlook, and Web application servers, such as IBM WebSphere.

According to one embodiment, the machine?200?may include a host OS, such as OS?226. The host OS?226?may be one of the standard OS, such as Unix, Linux, and Microsoft Windows. According to one embodiment, the host OS?226?may be used to have the VMM?202?operate as part of the kernel of the host OS?226. Having the VMM?202?as part of the host OS?226, the VMs?204-208?may run on a combination of the host OS?226?and the VMM?202. According to another embodiment, the VMM?202?may operate on the bare hardware platform?224?and the VMs?204-208?may run on the VMM?202. According to one embodiment, various settings, combinations, and functions of the OS, such as OS?218-222?and?226, are contemplated. For example, the machine?200?may include OS?218-222?as the host OS, or may include the OS?226?as the host OS, or the like, or may include a combination thereof.

According to one embodiment, each of the hyperthreaded processors?110,?710?may serve as the host platform for all of the VMs?204-208. According to another embodiment, each of the hyperthreaded processors?110,?710?may serve as a corresponding host platform for one of the VMs?204-208, called corresponding VM. Although two hyperthreaded processors?110,?710?are illustrated, the machine?110?may include more than two hyperthreaded processors?110,?710. Furthermore, according to one embodiment, both processors?110,?710?may be hyperthreaded processors, or one or more hyperthreaded processors combined with any one or more of the following: a microprocessor, a digital signal processor, a microcontroller, and the like. According to one embodiment, the hyperthreaded processors?110,?710?may include microcode, macrocode, software., programmable logic, hard coded logic, or the like, or a combination thereof, for performing the execution of various embodiments of the present invention. The machine?100, according to one embodiment, may include a personal computer (PC), a mainframe computer, a handheld device, a workstation, a server, a portable computer, a set-top box, an intelligent apparatus or system or appliance, a virtual machine, or any other computing system or device.

Each of the hyperthreaded processor?110,?710?may include a single physical processor with multiple threads or multiple logical processors, such as706-708,?712-714, and a processor state?404,?704?corresponding to each of the processors?110,?710. The threads or logical processor?706-708,?712-714?may appear as multiple processors and share the physical execution resources. According to one embodiment, the machine?100?may include a state monitoring/management engine or unit (state management unit)?402?hardware or firmware or software, or a combination thereof, implemented in or coupled with the VMM?202?or the processors?110,?710, to monitor the processor states?404,?704?of the processors?110,?710.

According to one embodiment, the VMM?202?may host software for the VMs?204-208?and may manage the VMs?204-208?according to the data stored in the memory of the machine?100, or according to the indicators provided to the VMM?202?by the machine?100. According to one embodiment, the VMM202?may manage the VMs?204-208?based on the processor state information gathered by monitoring the corresponding processor state?404,?604?of each of the hyperthreaded processors?110,?710. According to one embodiment, the processor state information may include, for example, characteristics and history of the processors?110,?710, characteristics and history of the VMs?204-208, event monitoring (EMON) data, and other hooks into the processors?110,?710. EMON data, also known as E86MON data, may include processor-specific counters and registers dynamically indicating information about the inner workings of the processors?110,?710.

SRC=http://www.freepatentsonline.com/7415708.html