Virtual machine switching control by prefetching information out of and updating a set of processor control information based on a bitmap having update status

Provided is a virtual machine including a first virtualization module operating on a physical CPU, for providing a first CPU, and a second virtualization module operating on the first CPU, for providing second CPU. The second virtualization module includes first processor control information holding a state of the first CPU obtained at a time of execution of the user program. The first virtualization module includes second processor control information containing a state of the physical CPU obtained at the time of the execution of the second virtualization module, third processor control information containing a state of the physical CPU obtained at the time of the execution of the user program, and prefetch entry information in which information to be prefetched from the third processor control information is set, and, upon detection of a event, the information set in the prefetch entry information is reflected to the first processor control information.

CLAIM OF PRIORITY

The present application claims priority from Japanese patent application JP2008-279973 filed on Oct. 30, 2008, the content of which is hereby incorporated by reference into this application.

BACKGROUND OF THE INVENTION

This invention relates to a virtual machine system, and more particularly, to a virtual machine system using a processor provided with a virtualization support feature.

Recently, as open servers have become popular, a larger number of servers have been introduced to information systems used in enterprises. Especially, indiscriminate introduction of Intel Architecture (IA)-32 servers, which have high cost performance, has increased the operation/management cost of servers, including the cost of power consumption and the cost of hardware maintenance, and is posing a problem for the enterprises which are operating the servers.

Server integration which, in order to reduce the operation/management cost of servers, integrates a plurality of servers into one physical server is promising. As a method for realizing the server integration, a virtualization software program for providing a feature of virtualizing computer resources is attracting attention. The virtualization software program is a control software program, which divides computer resources such as a CPU (processor) and I/Os of a single physical server, and assigns the divided computer resources to a plurality of virtual servers. On the respective virtual servers, one OS (guest OS) can operate. By employing the virtualization software program, it becomes possible to realize the server integration in which OSs and application programs that conventionally run on a plurality of physical servers are assigned to respective virtual servers, and a plurality of servers are provided on a single physical computer.

A description is now given of a policy of the virtualization software program for assigning computer resources to virtual servers. With regard to the assignment of the CPU as the computer resource, virtualization software programs for the IA-32 mainly employ a processor provided with the virtualization support feature such as virtualization technology for Xenon (VT-x) (or AMD-V). The VT-x has a feature which assigns different operation privileges between a virtualization software program and a guest OS, and is implemented as hardware of a processor, as disclosed in JP 2005-529401 A, Intel Corp., “Intel 64 and IA-32 Architectures Software Developer's Manual VOL 2B”, retrieved on May 1, 2007, and Advanced Micro Devices, Inc., “AMD-Virtualization (AMD-V)”, retrieved on May 1, 2007, for example. A CPU compliant with the VT-x feature detects the operation privilege switched between the guest OS and the virtualization software program, and backs up and restores a register state of the CPU, thereby providing independent operation environments for respective virtual servers.

On the other hand, a policy of the assignment of I/Os depends on virtualization software programs. The assignments of the I/Os by the virtualization software programs are generally classified into:

(1) direct I/O assignment type which permits direct use of I/O devices of a physical server; and

(2) virtual I/O assignment type which hides types and revisions of I/O devices of a physical server.

The “direct I/O assignment type (1)” has an advantage that, for presently operating I/Os of a physical server, server integration can be easily realized without rebuilding a file system or the like. On the other hand, the “virtual I/O assignment type (2)” has an advantage that a fixed I/O configuration can be provided for guest OSs independently of I/O types of a physical server.

The following are known examples of the virtualization software programs described above. First, as a virtualization software program for an IA-32 server, ESX Server of VMware (registered trademark) is known. The ESX Server can cause a plurality of conventional OSs to operate on a physical server employing an IA-32 CPU by means of the above-mentioned VT-x feature.

As a virtualization software program based on a mainframe computer technology, a logical partition operation feature (in IBM System370, for example) is known. This feature partitions a single physical computer into a plurality of logical partitions (LPARs), and causes a conventional OS and a virtual machine manager (VMM) to operate on the respective LPARs. With the logical partition operation feature, the mainframe (physical computer) uses a feature (LPAR mode) corresponding to the above-mentioned VT-x of IA-32 to cause the conventional OS and the VMM to run on the virtual server (LPAR).

Moreover, SimOS is known as a virtualization software program which provides the VT-x feature of the IA-32 by means of a simulator. A simulator of this type is a software program for providing functions of an arbitrary server and CPU by interpreting an instruction sequence of a guest OS on a virtual server.

Moreover, as a virtualization support feature implemented on an IA-64 processor (IPF: Itanium Processor Family), the VT-i feature described in Intel Corp., “Intel Virtualization Technology Specification for the Intel Itanium Architecture (VT-i)”, retrieved on May 1, 2007, is known.

SUMMARY OF THE INVENTION

Considering the recent needs for the server integration, it has been studied to integrate the virtualization software feature of the “virtual I/O assignment type (2)” to a new-generation server OS such as Windows Server 2008.

However, the conventional virtualization software program has the following problems.

The conventional virtualization software program such as the ESX Server can cause a conventional OS to run on a plurality of virtual servers based on the virtualization support feature (VT-x) of a CPU constituting a physical computer, but the conventional virtualization software program cannot provide the virtual server with the VT-x feature. Therefore, the ESX Server has a problem that, on the ESX server, an OS incorporating a virtualization software program (virtualization feature), such as the new-generation server OS, is hard to execute.

Moreover, with the logical partition operation feature, an OS or a VMM on an LPAR cannot use the LPAR mode. Therefore, there poses a problem that an OS incorporating the virtualization software program is hard to operate on an LPAR.

Further, the above-mentioned simulator can provide a virtual server with the VT-x feature, and therefore can operate the new-generation OS incorporating the virtualization software program. However, the simulator interprets an instruction sequence of a virtual server (guest OS), and converts it into an instruction sequence executable on a CPU of a physical computer (carries out a binary translation), resulting in generation of an overhead, and a decrease in performance (processing performance) of the virtual server. Hence, it is not practical for the simulator to carry out the server integration which requires operation of a plurality of virtual servers.

Moreover, though a new-generation OS incorporating a virtualization feature of the virtual I/O assignment type is suitable for an application for generating a large number of virtual servers having the same I/O configuration, such as an application for providing a development environment, the new-generation OS is not suitable for an application for integrating conventional OSs operating on existing servers (OSs without the VT-x feature, such as NT servers). Particularly, software assets presently operated by enterprises are mostly software programs operating on OSs without a virtualization feature. Therefore, in a future server integration process, a server integration environment in which existing OSs without a virtualization feature and newly-introduced new-generation OSs with a virtualization feature coexist is necessary. However, as described above, the conventional art has had a problem that it is difficult to integrate new-generation OSs incorporating a virtualization feature on a virtual machine, and to integrate new-generation OSs and conventional OSs.

This invention has been made in view of the above-mentioned problems, and it is an object of this invention to provide a virtual machine capable of running an OS incorporating a virtualization feature on a virtual server without decreasing performance of the virtual machine.

A representative aspect of this invention is as follows.

A control method for a virtual machine system for providing, on a physical computer comprising a physical processor and a memory, a plurality of virtual processors, the virtual machine system comprising: a first virtualization module for providing a first virtual processor; a second virtualization module to be executed on the first virtual processor, for providing a second virtual processor; and a user program to be executed on the second virtual processor, the control method comprising the steps of: holding, by the second virtualization module, first processor control information containing a state of the first virtual processor obtained at a time of execution of one of the second virtualization module and the user program; holding, by the first virtualization module, second processor control information containing a state of the physical processor obtained at the time of the execution of the second virtualization module, third processor control information containing a state of the physical processor obtained at the time of the execution of the user program, and prefetch entry information in which information to be prefetched in a batch from the third processor control information is set in advance; detecting, by the first virtualization module, a first event for switching control from the user program to the second virtualization module on the second virtual processor; reading, by the first virtualization module, upon detection of the first event, the information set in the prefetch entry information out of the third processor control information; updating, by the first virtualization module, out of the first processor control information, information read based on the prefetch entry information; setting, by the first virtualization module, the second processor control information for the physical processor to switch the control to the second virtualization module; and referring to, by the second virtualization module, the first processor control information.

Therefore, according to this invention, when the second virtualization module refers to the first processor control information, the control is restrained from being switched from the second virtualization module to the first virtualization module, and hence it becomes possible to execute, without a reduction in performance of the virtual machine, the OS integrating the virtualization feature on a virtual server. Then, the first virtualization module reflects, based on the prefetch entry information, the third processor control information to the first processor control information, and hence the information to be referred to can be quickly read by the second virtualization module. As a result, it becomes possible to prevent the switch of the control from the second virtualization module to the first virtualization module from occurring frequently, resulting in prevention of a decrease in performance of the virtual machine system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A description is now given of an embodiment of this invention with reference to accompanying drawings.

FIG. 1illustrates an embodiment of this invention, and is a block diagram of a computer system to which this invention is applied. A physical server (physical computer)101is mainly constructed by physical CPUs (processors)104and104nprovided with a virtualization support feature for carrying out arithmetic operations, a memory105for storing data and programs, and an I/O device106for transmitting/receiving data to/from devices external to the physical server101.

The physical CPUs104,104nare connected to a north bridge4provided with a memory controller, thereby making access to the memory105. The north bridge4is connected to a south bridge5connected to the I/O device106, thereby enabling the physical CPUs104,104nto make access to the I/O devices106. One of the I/O devices106is connected, via a connection line, to a hard disk drive (HDD)6serving as a machine-readable storage medium. The HDD6stores programs such as a virtual machine manager, an OS, and application programs, which are described later, and the physical CPUs104,104nload programs in the HDD6to the memory105, expand executable images on the memory105, and execute the executable images. The I/O devices106are constructed by a network interface, host bus adaptor, and the like.

Moreover, the physical CPU104may be constructed by an arbitrary number (of sockets) of CPUs or by a processor provided with a plurality of processing cores. Moreover, the virtualization support feature (virtual machine extensions: VMX) of the physical CPU104includes the above-mentioned virtualization technology for IA-32 processors (VT-x). It should be noted that an operation mode using the virtualization support feature is a VMX mode, and an operation mode without using the virtualization support feature on a normal privilege level is a normal operation mode.

FIG. 2is a block diagram of a virtual machine system to which this invention is to be applied.FIG. 2illustrates an example in which virtual machines are executed on the physical CPU104illustrated inFIG. 1.

On the physical server101, in order to operate a plurality of virtual servers102ato102n, a host virtual machine manager (VMM)103is executed for converting physical computer resources of the physical server101into virtualized computer resources, and assigning the virtualized computer resources to the respective virtual servers102ato102n. This host VMM103(first virtualization module) is provided as a program which is read to the memory105and then executed by the physical CPU104.

The host VMM103provides the respective virtual servers102ato102nwith virtual CPUs108ato108n, and assigns the memory105and the I/O device106to the respective virtual servers102ato102n. A well-known or publicly-known method may be properly used for assigning the computer resources of the physical server101to the respective virtual servers102ato102n, and hence a detailed description thereof is omitted.

The physical server101is connected to a management console107providing a user interface, and an administrator or the like enters setting such as allocations of the computer resources for the virtual servers102ato102nor the like to the host VMM103via the user interface. Moreover, the user interface outputs setting states received from the host VMM103and the like on a display device of the management console107.

On the virtual servers102ato102nrunning on the host VMM103of the physical server101, grandchild OSs (guest OSs on the guest VMMs109)111ato111nrespectively run as the user programs110ato110n, and application programs112ato112nare respectively executed on the grandchild OSs111ato111n. The grandchild OSs111ato111nare respectively executed on the virtual CPUs108ato108nprovided by the host VMM103. It should be noted that the virtual CPUs108ato108nallow assignment of a plurality of virtual CPUs to a single virtual server.

On the virtual server102a, a new-generation OS incorporating the virtualization feature (guest VMM109) is executed as the grandchild OS111a, and on the virtual server102n, a conventional OS (such as NT Server) without a virtualization feature is executed as the grandchild OS111n.

The host VMM103assigns the virtual CPU108nand computer resources set via the management console107to the virtual server102nexecuting the conventional OS, thereby executing the grandchild OS111nand the application program112n.

On the other hand, the host VMM103provides the virtual CPU108ato be assigned to the virtual server102aexecuting the new-generation OS111awith the virtualization support feature. On the virtual CPU108a, the guest VMM (second virtualization module)109is running, and this guest VMM109provides virtual CPUs208ato208i. On the virtual server102aon which the new-generation OS is running, the plurality of second virtual CPUs208ato208iare provided on the first virtual CPU108a, and, on the respective virtual CPUs208ato208i, a plurality of user programs110a(grandchild OS111aand application program112a) to110i(grandchild OS111iand application program112i) are executed. It should be noted that the host VMM103may generate the guest VMM109.

In the following section of this first embodiment, a description is given of an example in which the physical CPU104has the VT-x feature, and the grandchild OS111aof the virtual server102ais the new-generation OS incorporating the virtualization feature (guest VMM109).

The host VMM103using the VT-x feature stores host-VMM-held data11for storing states of the virtual servers102ato102nand control information used for controlling the physical CPU104in a predetermined field of the memory105. Then, in the host-VMM-held data11, physical CPU control data13used for controlling the physical. CPU104is stored. The physical CPU control data13is a data structure representing a status of the virtual CPU108ausing the virtualization support feature, and is referred to as virtual machine control structure (VMCS). According to this embodiment, as illustrated inFIG. 3, the physical. CPU control data13in the host-VMM-held data11are shadow VMCSs130(#0to #n−1), virtual CPU control data114handled by the guest VMM109is a guest VMCS22(first processor control information), and the shadow VMCSs130and the guest VMCS22are distinguished from each other. Moreover, the physical CPU104has a pointer115used to refer to the shadow VMCSs130(#0to #n−1) in the physical CPU control data13. Further, as illustrated inFIG. 5, the shadow VMCS130according to this invention provides one guest VMM109with a shadow VMCS #0accessible in the VMX root mode, and a shadow VMCS #1accessible in the VMX non-root mode. In the following description, the shadow VMCSs are generally referred to as shadow VMCS130, and, when individual shadow VMCSs are to be identified, the shadow VMCSs are denoted by shadow VMCSs #0to #n−1. It should be noted thatFIG. 5is a map showing a relationship between the shadow VMCSs #0, #1used by the physical CPU104and the operation modes of the VT-x feature. The host VMM103sets, by rewriting the shadow VMCSs130(#0to #n−1) in the physical CPU control data13, an operation mode of the physical CPU104to any one of an operation mode (VMX non-root mode) for executing the user program110aor the guest VMM109and an operation mode (VMX root mode) for executing the host VMM103.

On the virtual server102a, the virtualization feature (virtualization software program) integrated into the grandchild OS111a, which is the new-generation OS, runs as the guest VMM109on the virtual CPU108aprovided by the host VMM103.

The guest VMM109is provided with the virtual CPU control data114containing the guest VMCS22for controlling the virtualization support feature of the virtual CPU108a, an update bitmap227indicating update states of the shadow VMCS130, and instruction code230emulating read/write from/to the guest VMCS22. The guest VMCS22and the update bitmap227are stored in a predetermined field of the memory105assigned by the host VMM103.

Moreover, the virtual CPU108ahas a pointer116used to refer to the virtual CPU control data114(guest VMCS22) of the guest VMM109. This pointer116is a pointer pointing to the control data structure (guest VMCS22) of the virtual CPU108acorresponding to the VT-x feature held by the grandchild OS111a, and is initialized when a VMPTRLD instruction (instruction to cause the processor to read the memory secured for the VMCS) is issued by the grandchild OS111a. It should be noted that the pointer116is initialized by the guest VMM109.

InFIG. 2, the virtual CPUs208ato2081of the virtual server102aon which the new-generation OS is running are provided by the guest VMM109integrated into the new-generation OS111a, and the user programs110ato110ican be executed on the respective virtual CPUs208ato208i. It should be noted that the guest VMM109of the virtual server102amay serve as an add-in software program of the grandchild OS111a.

OVERVIEW OF THIS INVENTION

The VT-x feature for supporting the virtualization controls the operation mode of the physical CPU104by using the shadow VMCS secured by the host VMM103on the memory105of the physical server101. The physical CPU104having the VT-x feature as the virtualization support feature has the normal operation mode and the virtual machine extensions (VMX) mode for providing the virtualization support feature, and, in the VMX mode, switches the mode to one of a host mode (hereinafter, VMX root mode) in which the host VMM103operates and a guest mode (hereinafter, VMX non-root mode) in which the guest VMM109or the user program (grandchild OS111aor application program112a) operates.

The shadow VMCS130of the physical CPU control data13has only one type of field (guest-state area131) specifying the operation state of the user program110aon the virtual server102a. Hence, it is impossible to simply distinguish which of the guest VMM109, which is the virtualization feature of the new-generation OS, and the user program110a(grandchild OS111aor application program112a) is operating.

In view of this, this invention focuses on a fact that a single virtual CPU does not execute the guest VMM109and the user program110aat the same time. The host VMM103monitors the switch between the guest VMM109and the user program110aof the virtual server102aexecuting the grandchild OS111aincorporating the virtualization feature, and rewrites the guest-state area131of the shadow VMCSs130(#0to #n−1) of the host-VMM-held data11in switching the operation mode, thereby causing the virtualization feature to operate on the virtual server102a.

Therefore, the host VMM103monitors the grandchild OS111awhich is the new generation OS incorporating the virtualization feature, thereby providing control which sets the operation mode of the physical CPU104to the VMX root mode in a period in which the host VMM103is operating, and to the VMX non-root mode in a period in which the guest VMM109or the user program110ais operating. When the host VMM103enters into the VMX root mode due to a predetermined condition (VM-exit), the host VMM103emulates instructions of the guest VMM109or the grandchild OS. As a result, for the grandchild OS111a, it appears that the virtual CPU108ais providing the virtualization support feature.

Moreover, the transition of the physical CPU104from the VMX root mode to the VMX non-root mode is referred to as VM-entry, and, conversely, the transition from the VMX non-root mode to the VMX root mode is referred to as VM-exit. Upon the VM-exit due to a predetermined reason such as issuance of a privilege instruction (such as page fault) from the grandchild OSs111ato111n, the physical CPU104notifies the host VMM103of the VM-exit. The host VMM103detects the VM-exit or VM-entry as an event, thereby carrying out predetermined processes.

The transition between the VMX root mode and the VMX non-root mode of the VMX mode is carried out as described in “Intel 64 and IA-32 Architectures Software Developer's Manual VOL 2B”. Thus, only a brief description is now given thereof. When the normal operation mode is switched to the VMX mode, the host VMM103issues a VMXON instruction, thereby switching the operation mode of the physical CPU104to the VMX mode. Then, the host VMM103in the VMX mode writes information used for executing the user program110ain the shadow VMCSs (#0to #n−1) of the corresponding virtual CPUs108ato108n, issues a VM-entry instruction (VMLAUNCH instruction or VMRESUME instruction), and switches from the VMX root mode to the VMX non-root mode.

On the other hand, the VM-exit is an event which occurs due to a predetermined reason such as issuance of an privilege instruction from the grandchild OSs111ato111n, and this event causes the physical CPU104to notify the host VMM103of the VM-exit, and, simultaneously, switches the operation mode from the VMX non-root mode to the VMX root mode.

When the CPU control module12of the host VMM103detects the VM-exit, the CPU control module12carries out a predetermined emulation, thereby completing a process of the guest VMM109or the grandchild OS, then rewrites the shadow VMCS130according to necessity, and again issues the VM-entry instruction (first control instruction) to switch the VMX root mode to the VMX non-root mode.

As described above, when the user program110aexecuted on the virtual server102ais switched between the guest VMM109and the grandchild OS111a, the contents of the guest VMCS22are synchronized with the shadow VMCS130pointed by the pointer115of the physical CPU104. The guest VMM109, by making access to the virtual guest VMCS22, can obtain and update statuses in the user program110aand contents of events without making access to the shadow VMCS130.

The physical CPU104having the VT-x feature provides, as instructions to carry out read/write from/to the shadow VMCS130, a VMREAD instruction for reading the shadow VMCS130and a VMWRITE instruction for carrying out write to the shadow VMCS130. It should be noted that the read from the shadow VMCS130(VMREAD instruction) and the write to the shadow VMCS130(VMWRITE) can be used only in the VMX root mode.

On this occasion, when the guest VMM109makes access to the guest VMCS22, instead of requesting, by a physical VMREAD instruction or VMWRITE instruction, for access to the guest VMCS22, a VMREAD emulator231or a VMWRITE emulator232set in advance in the instruction code230inside the guest VMM109is started. In the following description, the startup of the VMREAD emulator231or VMWRITE emulator232performed by the guest VMM109in place of the VMREAD instruction or VMWRITE instruction is referred to as issuance of a virtual VMREAD instruction or virtual VMWRITE instruction. Those instructions may be implemented by branch instructions, function call instructions, SYSCALL/SYSENTER, and software interrupts (INT3, INTO, INN, which operate with the user privilege, but other instructions which avoid occurrence of the physical VM-exit may replace them.

The guest VMM109, upon reading the guest VMCS22, issues a virtual VMREAD instruction, and, upon writing information to the guest VMCS22, issues a virtual VMWRITE instruction.

If the guest VMM109issues the VMREAD instruction or the VMWRITE instruction in the VMX non-root mode, the VM-exit occurs in the physical. CPU104in the above-mentioned conventional example, and the guest VMM109switches to the VMX root mode, and then reads the guest VMCS22. Then, if the guest VMM109issues a plurality of VMREAD instructions, the VM-exit occurs for each of the VMREAD instructions, and the switch to the VMX root mode frequently occurs, resulting in an increase in load on the physical CPU104. As a result, a decrease in performance of the virtual machine system is of concern.

Though many types of information are stored in the shadow VMCS130, limited information is accessed by the guest VMM109with the VMREAD or VMWRITE instruction, and information to be accessed can be predicted by reason information (basic reason) of the VM-exit. For example, a privilege exception such a page fault occurs on the grandchild OS111a, information to be referred to by the VMREAD instruction is limited to IDT interruption information, IDT vectoring information, and the like in addition to the basic reason.

On the other hand, information to be accessed by the VMWRITE instruction is written and referred to at different timings. For example, when the guest VMM109writes information by means of the VMWRITE instruction to the guest VMCS22, upon the transition to the grandchild OS111adue to a next VM-entry, the guest VMCS22is referred to.

Therefore, according to this invention, the guest VMM109is caused to issue, in place of the physical VMREAD instruction or physical VMWRITE instruction, the virtual VMREAD instruction or virtual VMWRITE instruction. Then, the VMREAD emulator231or VMWRITE emulator232provided in the instruction code230of the guest VMM109is started, thereby providing access to the guest VMCS22without issuing the VM-exit instruction.

Then, the VMREAD emulator231, only when the values of the guest VMCS22have not been updated by the values of the shadow VMCS130, actually issues the VM-exit instruction, and reflects the values of the shadow VMCS130to the values of the guest VMCS22, thereby reflecting the data requested by the virtual VMREAD instruction to a predetermined destination. As the predetermined destination, a general register or the memory is specified.

When the VM-exit occurs as described above, the host VMM103, based on the exit reason of the VM-exit, predicts information to be accessed, and prefetches a plurality of pieces of the information, thereby reflecting them to the guest VMCS22, which restrains the VM-exit from occurring for the case of the next virtual VMREAD instruction.

After the occurrence of the VM-exit, data requested with the virtual VMREAD instruction by the guest VMM109operating in the VMX non-root mode is data indicating an operation state of the user program110a. This information is stored in the shadow VMCS #1with the VM-exit as a trigger, and thus, the host VMM103carries out the prefetch directed to the shadow VMCS #1.

On this occasion,FIG. 5is a map showing relationship between the shadow VMCSs #0, #1used by the physical CPU104and the operation modes of the VT-x feature. To the shadow VMCS130of the host-VMM-held data11, as fields used by the virtual server102a, the shadow VMCS #0used by the physical CPU104in the VMX (virtualization feature) root mode, and the shadow VMCS #1used by the physical CPU104in the VMX (virtualization feature) non-root mode are set in advance.

The host VMM103, by switching the pointer115of the physical CPU104, switches between the shadow VMCSs #0and #1. Both the shadow VMCSs #0and #1can be accessed only by the host VMM103. On the other hand, the guest VMM109operating in the VMX non-root mode can access only the guest VMCS22.

InFIG. 2, the host VMM103includes, in addition to the host-VMM-held data11described above, the CPU (processor) control module12which monitors the virtual servers102ato102nand switches the operation mode of the physical CPU104to one of the VMX root mode and the VMX non-root mode.

Moreover, the host VMM103includes control/communication interfaces17ato17nused by the CPU control module12for obtaining the states of the virtual servers102ato102n, and for transmitting an instruction to the respective virtual servers102ato102n, an instruction issuing interface18used by the CPU control module12for issuing an instruction to the physical CPU104, reference/update interfaces19ato19bused by the physical CPU104for referring to or updating the physical CPU control data13stored in the memory105, and an I/O request/response interface16for receiving an interrupt request from the I/O device106, and responding to the request.

FIG. 3is a block diagram illustrating functions of the host VMM103and the guest VMM109. The host VMM103sets, in order to use the virtualization support feature (VT-x feature) of the physical. CPU104, the host-VMM-held data11in a predetermined field of the memory105.

The host-VMM-held data11is constructed by a field for storing flags indicating use or nonuse of the virtualization support feature of the grandchild OSs111ato111n, and the states of the virtual CPUs108ato108n, and a field of the physical CPU control data13for holding the shadow VMCSs130(#0to #n−1) storing the statuses and the like of the respective virtual CPUs108ato108n.

The flags of the host-VMM-held data11indicating the states of the grandchild OSs and the virtual CPUs include, for example, a virtualization feature enable flag141for specifying whether or not each of the grandchild OSs111ato111ncan use the virtualization support feature of the physical CPU104, a VMXON flag142for setting whether or not the virtualization support feature is being used by each of the virtual CPUs108ato108n, and an operation mode flag143for indicating whether the virtualization support feature is operating in the VMX root mode or the VMX non-root mode for each of the virtual CPUs108ato108n.

The virtualization feature enable flag141is set for the respective grandchild OSs111ato111n. The value “1” indicates that the corresponding grandchild OS can use the virtualization support feature, and “0” indicates that the grandchild OS does not (or cannot) use the virtualization support feature. This virtualization feature enable flag141is set to the respective grandchild OSs111ato111nfrom the management console107, or is set according to a file specified in advance.

The VMXON flag142indicates whether or not the operation mode of each of the virtual CPUs108ato108nis the VMX mode. The value “1” indicates that the operation mode of the corresponding one of the virtual CPUs108ato108nis the VMX mode, and “0” indicates that the operation mode of the corresponding one of the virtual CPUs108ato108nis the normal operation mode, in which the virtualization support feature is not used. The VMXON flag142is set to “1” by the host VMM103when the grandchild OSs111ato111nissue the VMXON instruction, and is reset to “0” by the host VMM103when the grandchild OSs111ato111nissue a VMXOFF instruction.

The operation mode flag143is used to trace the operation mode of a program running on the virtual CPUs108ato108n. This operation mode flag143is set to “1” by the host VMM103upon the VM-entry of the grandchild OSs111ato111n, and is reset to “0” by the host VMM103upon the VM-exit of the grandchild OSs111ato111n. In other words, the operation mode flag143indicates, when the VMXON flag142is “1”, the type of the VMX mode for each of the virtual CPUs108ato108n. When the operation mode flag143is “0”, the virtual CPUs108ato108nare in the state (VMX root mode of the virtual CPU) of executing the guest VMM109, and when the operation mode flag143is “1”, the virtual CPUs are in the state (VMX non-root mode of the virtual CPU) of executing the user program110a(grandchild OS111aor application program112a).

According to this invention, upon the VM-entry of the grandchild OS111a, which is the new-generation OS, the host VMM103reads a guest-state area221and a host-state area222of the guest VMCS22, and sets a content of one of the areas according to an operation of the grandchild OS111ato the guest-state area131of the shadow VMCS #0, thereby realizing the virtualization feature of the grandchild OS111aon the virtual server102a.

With the VT-x feature, the switching between the host VMM103and the guest VMM109or the user program110ais carried out by the transition between the VM-entry and the VM-exit as described above. Therefore, in order to hold the status of the physical CPU104or the like before and after the VM-entry and the VM-exit, the shadow VMCSs #0to #n−1, which are data structures of the physical CPU control data13, are used.

To the physical CPU control data13, for each of the virtual CPUs108ato108n, the shadow VMCSs #0to #n−1 are set, and, as described above, the host VMM103assigns, to one guest VMM109, two shadow VMCSs #0and #1. Then, the host VMM103, as illustrated inFIG. 5, uses the shadow VMCS #0in the virtual VMX root mode, and uses the other shadow VMCS #1in the virtual VMX non-root mode. In other words, in the virtual VMX root mode, the host VMM103sets, to the pointer115, the address of the shadow VMCS #0, and, as illustrated inFIG. 5, when the guest VMM109operates, the setting of the shadow VMCS #0is reflected to the physical CPU104. On the other hand, in the virtual VMX non-root mode, the host VMM103sets, to the pointer115, the address of the shadow VMCS #1, and, when the grandchild OS111a(or application112a) operates, the setting of the shadow VMCS #1is used.

Each of the shadow VMCSs130includes a guest-state area131, a host-state area132, a VM-execution control field133, a VM-exit control field134, a VM-entry control field135, and a VM-exit information field136.

As illustrated inFIG. 4, the guest-state area131stores statuses such as register states and non-register states of the virtual CPUs108ato108n. In other words, as described later, the status of the guest VMM109or the status of the user program110ais selectively stored. It should be noted thatFIG. 4is a block diagram illustrating an example of the control data of the shadow VMCS of the host-VMM-held data.

As illustrated inFIG. 4, the host-state area132stores statuses such as the register state of the physical CPU104of the host VMM103. The VM-execution control field133stores setting information of the virtual servers102ato102n, such as an exception bitmap and an I/O bitmap. The VM-exit control field134stores information such as occurrence reasons (exit reasons) for the VM-exit and IDT-vectoring information. The VM-entry control field135stores information used for controlling an operation of the VM-entry. The VM-exit information field136stores reasons (instructions or events) for occurrence of the VM-exit. As the reasons for occurrence of the VM-exit, reasons listed under “description” illustrated inFIG. 7, for example, is set to the VM-exit information field136. It should be noted thatFIG. 7illustrates the details of the reason information (exit reason)1360contained in the basic VM-exit information in the VM-exit information field136illustrated inFIG. 6.

Using the shadow VMCSs (#0to #n−1) as described above, the host VMM103controls the respective virtual servers102ato102n. It should be noted thatFIG. 6is a block diagram illustrating a relationship between the shadow VMCS130and the VM-exit information field136. Moreover,FIG. 7is an explanatory diagram illustrating an example of a list of the reasons for the VM-exit.

A description is now given of a configuration of the CPU control module12of the host VMM103. InFIG. 3, the CPU control module12includes, in addition to a resource management module (not shown) for assigning the computer resources of the physical server101to the respective virtual servers102ato102naccording to the input from the management console107or the like, a state area selection module121for selecting, in order to cause the virtualization feature (guest VMM109) of the grandchild OS111ato operate, an access destination from which the status of the virtual CPU108aare read, an emulator122, a shadow VMCS reference/update module123, a VM-exit handler124, a VM-entry instruction issuing module125, and a user interface. To the resource management module, as described above, a publicly-known or well-known technology may be applied, and hence, a detailed description thereof is omitted in this embodiment.

The VM-exit handler124receives the VM-exit from the physical CPU104, and starts the emulator122.

The emulator122identifies an instruction or an event causing the VM-exit received from the VM-exit handler124, starts, as described later, a module corresponding to the identified reason for the occurrence, and carries out a process in place of the guest VMM109or the user program110a.

When the emulator122detects a change of the operation mode (switch between the VMX root mode and the VMX non-root mode) of the virtual CPU108a, the emulator122starts a module corresponding to the identified reason (VM-entry instruction execution module1221, VMCLEAR instruction execution module1223, CPUID instruction execution module1224, or VM-exit instruction execution module1222), and starts the state area selection module121.

On the other hand, the reason for occurrence of the VM-exit received by the emulator122from the VM-exit handler124is the VMREAD instruction for reading the guest VMCS22or the VMWRITE instruction for writing information to the guest VMCS22, the emulator122starts a VMREAD/VMWRITE instruction execution module1225for reading/wring the contents of the shadow VMCS #1in a batch. It should be noted that the VMREAD/VMWRITE instruction execution module1225, as detailed later, can be called from the VMREAD emulator231of the guest VMM109.

The shadow VMCS reference/update module123makes access to the shadow VMCS130corresponding to the access destination selected by the state area selection module121, and notifies the emulator122of an access result.

The shadow VMCS reference/update module123contains prefetch entry information1231and virtual VM-exit trigger information1232used by the VMREAD/VMWRITE instruction execution module1225of the emulator122.

The virtual VM-exit trigger information1232, as described later, stores a reason for occurrence of the VM-exit obtained by the VM-exit instruction execution module1222from the shadow VMCS130.

FIGS. 9A,9B,10A, and10B are a map showing an example of the prefetch entry information1231.FIGS. 9A and 10Aillustrate a first part of the map.FIGS. 9B and 10Billustrate a last part of the map. The prefetch entry information1231, as illustrated inFIGS. 9A,9B,10A, and10B, is constructed by a bitmap defining, in advance, elements to be read in a batch by the VMREAD/VMWRITE instruction execution module1225from the shadow VMCS130, and is held in the memory105.

The prefetch entry information1231is constructed by area names12311corresponding to the guest-state area221to the VM-exit information field226illustrated inFIG. 3, field names12312constructing the area names12311, and entries12313for respective exit reasons of the VM-exit, and “0” or “1” is set to the respective entries. Though, inFIGS. 9A,9B,10A, and10B, a part of the fields of the shadow VMCS130are omitted, fields defined by the VT-x may be properly set.

The prefetch entry information1231shows that field names12312and area names12311to which “1” is set in the entry12313for each occurrence reason (exit reason) are read out together by the VMREAD/VMWRITE instruction execution module1225. On the other hand, the prefetch entry information1231shows that when “0” is set in an entry12313, it is not necessary to read a value of a corresponding field name12312.

For example, in an entry12313of an occurrence reason “CPUID” for the VM-exit, “RFLAGS” and “RIP” fields in the guest-state area131, and, in entries12313of “Exit reason” and “VM-exit instruction length” fields in the VM-exit information field136, “1” is set, which indicates that those fields are read in a batch by the VMREAD/VMWRITE instruction execution module1225.

Moreover, to the prefetch entry information1231, the VMREAD/VMWRITE instruction execution module1225of the host VMM103, described later, learns about the read fields, and field names12312to be read can be added to the occurrence reasons for the VM-exit.

In this example, though the prefetch entries are defined for each exit reason, in a certain embodiment, more detailed conditions may be set. For example, in addition to the exit reasons, when the IDT-vectoring information is used as a key, for respective exceptions and external interrupt vector numbers, prefetch entries may be set in detail. Though a detailed description thereof is omitted due to limitation in available space, it is a variation which is readily understood by persons skilled in the art, and is included in this invention.

Though the example in which the prefetch entry information1231is held in the memory105, and thus rewritable has been described, the prefetch entry information1231may be set as fixed data, and may be integrated into the program of the host VMM103, or may be implemented as hard code in a ROM (not shown) of the physical server101.

(Configuration of Guest VMM)

On the other hand, the virtual CPU control data114managed by the guest VMM109of the virtual server102astores the guest VMCS22having the same data structure as the shadow VMCS #0of the above-mentioned physical CPU control data13.

The guest VMM109includes the guest-state area221for storing statuses such as register states of the virtual CPU108aexecuting the user program110a(grandchild OS111aor application program112a), and the like, the host-state area222for storing statuses such as the register states of the virtual CPU108aexecuting the guest VMM109, a VM-execution control field223for storing setting information of the virtual server102a, a VM-exit control field224for storing information such as a reason for the VM-exit on the virtual server102a, a VM-entry control field225for storing information used for controlling the operation of the VM-entry on the virtual server102a, and a VM-exit information field226for storing information identifying a reason for the VM-exit on the virtual server102a.

Similarly toFIG. 4, the guest-state area221stores the statuses such as the register states of the virtual CPU108a. In other words, as described later, the status of the grandchild OS111aor the status of the application program112ais selectively stored.

In the shadow VMCS #0of the host VMM103for controlling the states of the virtual server102a, the guest-state area131stores the status of the guest VMM109or the status of the user program110a(grandchild OS111aor application program112a), and the host-state area132stores the status of the host VMM103.

On the other hand, in the guest VMCS22of the guest VMM109, the guest-state area221stores the status of the grandchild OS111aor the status of the application program112a, and the host-state area222stores the status of the guest VMM109, which is different from the shadow VMCS130.

The guest VMM109further includes the VMREAD emulator231and the VMWRITE emulator232as the instruction code230for reading/writing from/to the guest VMCS22.

Those VMREAD emulator231and VMWRITE emulator232, in place of the guest VMCS22, carry out the reading and writing in the VMX non-root mode, thereby restraining the VM-exit from occurring.

Moreover, the guest VMM109includes the update bitmap227used by the guest VMCS22to notify the VMREAD emulator231or VMWRITE emulator232of update states from the shadow VMCS130.

The update bitmap227is updated by the host VMM103, and, as illustrated inFIG. 11, stores update states of the respective fields constructing the respective areas of the guest VMCS22.

FIG. 11is a map showing an example of the update bitmap227. In the update bitmap227, one entry is constructed by an area name2271corresponding to one of the guest-state area221to the VM-exit information field226illustrated inFIG. 3, a field name2272constructing the area name2271, an update state2273(indicated as “Updated” inFIG. 3) indicating whether or not, to a value corresponding to the field name2272or the area name2271of this entry in the guest VMCS22, a value in the shadow VMCS #0has been updated by the host VMM103, and a dirty state2274(indicated as “Dirty” inFIG. 3) indicating whether the value corresponding to the field name2272or the area name2271of this entry in the guest VMCS22has been updated by the guest VMM109. Though, inFIG. 11, a part of the fields in the shadow VMCS130are omitted, fields defined by the VT-x may be appropriately set.

When the value in the guest VMCS22corresponding to the field name2272or the area name2271has been updated by the host VMM103, to the update state2273, “1” is set, and otherwise, “0” is set.

When the value in the guest VMCS22corresponding to the field name2272or the area name2271has been updated by the guest VMM109, to the dirty state2274, “1” is set, and otherwise, “0” is set.

The VMREAD emulator231of the instruction code230, which provides the emulator, refers to the update bitmap227, reads the values updated by the host VMM103from the guest VMCS22, and returns the values to the guest VMM109.

Moreover, the VMREAD emulator231refers to the update bitmap227, thereby checking the update state of the guest VMCS22. For elements of the guest VMCS22which have not been updated by the host VMM103, the VMREAD emulator231request the host VMM103to read the shadow VMCS130. On this occasion, the VMREAD emulator231generates the VM-exit, thereby causing the host VMM103to read the shadow VMCS130, and updates the values of the guest VMCS22corresponding to the fields subject to the VMREAD and the update states2273. As a result, the VMREAD emulator231returns, to the guest VMM109, for all the elements in the guest VMCS22, the values updated by the values of the shadow VMCS130.

The VMWRITE emulator232of the instruction code230, which provides the emulator, writes values instructed by the virtual VMWRITE instruction to the guest VMCS22. Then, the VMWRITE emulator232sets 1 to the dirty state2274of the entry corresponding to the area name2271and the field name2272written in the guest VMCS22, thereby indicating the update carried out by the guest VMM109for reference to be made by the host VMM103.

As a method involving calling the VMREAD emulator231or the VMWRITE emulator232from the guest VMM109, by a binary conversion of the VMM codes (for example, replacing the VMREAD instruction and VMWRITE instruction by MOVE instructions, thereby reading the shadow VMCS), or a static conversion of the VMM codes by a quasi-virtualization, the VMREAD instruction and the VMWRITE instruction are converted, thereby restraining the VM-exit from occurring on the physical CPU104.

(Overview of Operation of Host VMM>

As illustrated inFIGS. 6 and 7, on this occasion, a reason for occurrence of the VM-exit is one set to “EXIT REASON” of the VM-exit information field136of the shadow VMCS #0. To the list of the reasons of the VM-exit illustrated inFIG. 7, reasons1361caused by the issuance of the VM-entry instruction, reasons1362caused by the issuance of the VMCLEAR instruction (fourth control instruction), and notice conditions1363to which an absence/presence of a VM-exit notice to the guest VMM109is set are set in advance. Though, inFIG. 7, the VMREAD instruction, the VMWRITE instruction, and the like are omitted, reasons for generation of the VM-exit defined by the VT-x may be appropriately set.

For example, if the VM-entry instruction (VMLAUNCH instruction or VMRESUME instruction) is detected as a reason for the VM-exit of when the operation mode of the virtual CPU108ais switched, the VM-entry instruction corresponds to the reason1361ofFIG. 7, and thus, the host VMM103carries out the emulation on the VM-entry instruction execution module, thereby carrying out a process in place of the guest VMM109or the user program110a.

If a reason for the VM-exit is a condition for a notice to the guest VMM20corresponding to a notice condition1363ofFIG. 7, the host VMM103starts the VM-exit instruction execution module1222and carries out the emulation similarly.

The state area selection module121reads the operation mode flag143of the virtual CPU (CPU108ain this example) which has generated the VM-exit from the host-VMM-held data11, and determines whether the VMX mode is the VMX root mode or the VMX non-root mode. If the operation mode flag143is “0”, which indicates the VMX root mode, the guest VMM109is operating, and thus, the state area selection module121reads the host-state area222from the guest VMCS22of the virtual server (virtual server102ain this example) which has generated the VM-exit.

On the other hand, if the operation mode flag143is “1”, which indicates the VMX non-root mode, the user program110ais operating, and thus, the state area selection module121reads the guest-state area221from the guest VMCS22of the corresponding virtual server102a.

When the CPU control module12has completed the read from the guest VMCS22, the CPU control module12starts the shadow VMCS reference/update module123. The shadow VMCS reference/update module123writes the information in the guest VMCS22read by the state area selection module121to the guest-state area131of the shadow VMCS #0corresponding to the virtual CPU108a, which is subject to the process of the VM-exit, thereby updating the shadow VMCS.

When the guest-state area131of the shadow VMCS #0has been updated, the CPU control module12, in order to switch the operation mode of the virtual CPU108afrom the VMX root mode to the VMX non-root mode, updates the operation mode flag143to “1”, and sets the address of the shadow VMCS #0of the subject virtual CPU108ato the pointer115of the physical CPU104.

Then, the CPU control module12starts the VM-entry instruction issuing module125, thereby issuing the VM-entry instruction (VMRESUME instruction) to the physical CPU104.

When the physical CPU104receives the VM-entry instruction, the physical CPU104reads the guest-state area131of the shadow VMCS #0pointed by the pointer115, and executes the guest VMM109or the user program110aof the virtual server102aselected by the state area selection module121.

On the other hand, when the VMREAD emulator231of the guest VMM109refers to the guest VMCS22, and when data specified by the virtual VMREAD instruction are not updated by the values of the shadow VMCS130(the update states2273of the update bitmap227are “0”), the guest VMM109generates, in the VMX root mode, VM-exit that the VMREAD instruction causes.

On this occasion, the VMREAD/VMWRITE instruction execution module1225of the host VMM103carries out the emulator processing, thereby reading data from the shadow VMCS #1to reflect the data to the guest VMCS22. Then, the data reflected to the guest VMCS22have not been prefetched, and thus, “1” is set to corresponding fields in the prefetch entry information1231, thereby preventing the VM-exit from occurring on subsequent virtual VMREAD instructions.

Moreover, when the VM-exit is generated from the user program110ain the VMX non-root mode, and the VM-exit notice condition1363to the guest VMM109is set, the VM-exit instruction execution module1223of the host VMM103carries out the prefetch. As a result, the guest VMCS22of the guest VMM109is updated with the latest values of the shadow VMCS130.

A process for restraining the VM-exit caused by the virtual VMREAD instruction or virtual VMWRITE instruction as described above from occurring is described inFIG. 16.FIG. 16is a time chart illustrating an example of accesses to the shadow VMCSs #0and #1, and the guest VMCS22by the host VMM103and the guest VMM109.

A case in which, at a time T1, during instruction execution of the user program110a, the physical VM-exit corresponding to the virtual VM-exit for switching the operation mode of the virtual CPU108aoccurs is illustrated. Examples of the virtual VM-exit include issuance of the VMCALL instruction which is an explicit call of the guest VMM109by the user program110a.

This VM-exit in the VMX non-root mode switches the control to the host VMM103. For the occurrence reason for the VM-exit, the notice condition of the VM-exit to the guest VMM109is set, and thus, the host VMM103starts the VM-exit instruction execution module1222illustrated inFIG. 3.

The VM-exit instruction execution module1222, as described later with reference toFIG. 12, carries out the block read of the shadow VMCS #1. In other words, the VM-exit instruction execution module1222refers to the prefetch entry information1231according to the occurrence reason for the VM-exit, and then reads fields to the entry12313having the value of “1” from the shadow VMCS #1in a batch. The VM-exit instruction execution module1222of the host VMM103writes values of the fields read in a batch to the guest VMCS22, and then sets “1” to the update state2273of the update bitmap227.

Then, at a time T3, the host VMM103issues the VM-entry to the physical CPU104, thereby returning the control to the guest VMM109.

Between times T4and T5, an example in which the VMREAD emulator231or VMWRITE emulator232of the guest VMM109operates is illustrated, and, by the virtual VMREAD instruction or virtual VMWRITE instruction, writing to or reading from the guest VMCS22is carried out. In other words, in the case of the virtual VMREAD instruction, due to the prefetch between the times T2and T3, the VMREAD emulator231substituting the virtual VMREAD instruction can read the guest VMCS22without generating the VM-exit.

Moreover, the VMWRITE emulator232substituting the virtual VMWRITE instruction writes information to the guest VMCS22without generating the VM-exit. On this occasion, the VMWRITE emulator232sets, for the updated fields, “1” to the dirty states2274of the update bitmap227.

Then, at the time T5, during the operation of the guest VMM109, the VM-entry instruction is issued, resulting in the VM-exit. In this case, the mode is the VMX root mode, and thus, the host VMM103starts the VM-entry instruction execution module1221.

The VM-entry instruction execution module1221reads, at a time T6, the guest-state area221of the guest VMCS22. Then, the VM-entry instruction execution module1221sets the shadow VMCS #1corresponding to the subject virtual CPU into active, and updates the guest-state area131of the subject shadow VMCS #1with the read information of the guest-state area221. On this occasion, the VM-entry instruction execution module1221, by updating only fields having the dirty states2274of “1” in the update bitmap227, can quickly update the guest-state area131of the shadow VMCS #1.

Then, at a time T7, the VM-entry instruction execution module1221issues the VM-entry instruction, thereby switching the control from the host VMM103to the user program110a.

As described above, by reading the data of the shadow VMCS #1in a batch according to the prefetch entry information1231at the time T2, to thereby update the guest VMCS22, the VMREAD emulator231of the guest VMM109can read the guest VMCS22without generating the VM-exit.

Moreover, the VMWRITE emulator232of the guest VMM109can carry out writing to the guest VMCS22without generating the VM-exit. Then, upon the next switch of the control to the user program110a, the data written to the guest VMCS22can be reflected to the shadow VMCS #1.

(Details of Process by Host VMM)

A description is now given of a process carried out by the CPU control module12of the host VMM103with reference toFIG. 8.FIG. 8is a flowchart illustrating an example of a process carried out by the CPU control module12of the host VMM103when the CPU control module12receives the VM-exit from the physical CPU104while the virtual servers102ato102nare operating.

First, in Step S1, the CPU control module12of the host VMM103refers to the virtualization feature enable flag141of the host-VMM-held data11, thereby determining whether one of the grandchild OS111ato111nwhich has generated the VM-exit (referred to as grandchild OS hereinafter) can use the VT-x feature. If the subject grandchild OS can use the VT-x feature, the CPU control module12proceeds to Step S2. On the other hand, if the subject grandchild OS does not (or cannot) use the VT-x feature (if the subject grandchild OS is the NT Server or the 2000 Server), the CPU control module12proceeds to Step S15, and the host VMM103carries out a virtual machine process as described in Japanese Patent Translation Publication No. 2005-529401, or “Intel 64 and IA-32 Architectures Software Developer's Manual VOL 2B”.

In Step S2, the host VMM103refers to the VMXON flag142, thereby determining whether or not the virtual CPUs108ato108n(referred to as virtual CPU hereinafter) which have caused the VM-exit are in the VMX mode. If the VMXON flag142is “1”, the virtual CPU is in the VMX mode, and then, the CPU control module12proceeds to Step S3. On the other hand, if the VMXON flag142is “0”, the virtual CPU is in the normal operation mode, and then, the CPU control module12proceeds to Step S15similarly to the above. Then, the host VMM103carries out the conventional virtual machine process.

In Step S3, the CPU control module12of the host VMM103refers to the operation mode flag143of the subject virtual CPU, thereby determining whether the operation mode of the virtual CPU is the VMX root mode or the VMX non-root mode. If the operation mode flag143is “0”, the CPU control module12determines that the virtual CPU is in the VMX root mode, and proceeds to Step S4. On the other hand, if the operation mode flag143is “1”, the CPU control module12determines that the virtual CPU is in the VMX non-root mode, and proceeds to Step S11.

In Step S4, the CPU control module12identifies a reason for occurrence of the VM-exit received from the physical CPU104. In Step S4, because the operation mode of the virtual CPU is the VMX root mode, the CPU control module12identifies a shadow VMCS130(shadow VMCS #0in this example) storing the status of the guest VMM109, and refers to the guest-state area131of the shadow VMCS #0, thereby identifying the reason for occurrence of the VM-exit. The CPU control module12, upon detecting the VM-entry instruction (virtual VM-entry instruction=first event) as a reason for occurrence of the VM-exit, proceeds to a process of Step S5, and, upon detecting the VMREAD instruction as the reason for occurrence of the VM-exit, proceeds to a process of Step S16. Otherwise, the CPU control module12proceeds to a process of Step S11.

In Step S5in the case where the VM-entry instruction has caused the VM-exit, the CPU control module12executes the VM-entry instruction execution module1221from the emulator122, thereby emulating a predetermined process (such as the startup of the state area selection module121) required for switching the subject virtual CPU to the VMX non-root mode in place of the guest VMM109.

Then, in Step S6, the CPU control module12of the host VMM103switches the operation mode of the virtual CPU from the VMX root mode to the VMX non-root mode, and hence the CPU control module12updates the operation mode flag143of the subject virtual CPU to “1”.

In Step S7, the CPU control module12reads the statuses of the grandchild OS or the application program stored in the guest-state area221from the guest VMCS22of the virtual CPU control data114of the subject guest VMM109.

Then, in Step S8, the CPU control module12issues the VMPTRLD instruction to the physical CPU104, thereby setting the shadow VMCS #0corresponding to the subject virtual CPU to be active, and sets the address of the activated shadow VMCS #0to the pointer115. As a result of this VMPTRLD instruction (second control instruction), the host VMM103selects the shadow VMCS of the subject virtual CPU (virtual server) from the plurality of shadow VMCSs #0to #n−1.

In Step S9, the CPU control module12updates the guest-state area131of the subject shadow VMCS #0based on the information of the guest-state area221read in Step S7and the update bitmap227described later. Of the update process for this shadow VMCS #0, a detailed description is later given referring to a subroutine illustrated inFIG. 14.

Then, in Step S10, the CPU control module12issues the VM-entry instruction to the physical CPU104.

When the physical CPU104receives the VM-entry instruction, the physical CPU104executes the guest VMM109or the user program110a(referred to as user program hereinafter) of the subject virtual server based on the content of the guest-state area131of the shadow VMCS #0specified by the pointer115.

On the other hand, if the operation mode flag143is “1” in Step S3, because the subject virtual CPU is in the VMX non-root mode, which indicates that the subject virtual CPU is executing the user program, the CPU control module12executes a process of Step S11.

In Step S11, the CPU control module12refers to the list of reasons for generation of the VM-exit illustrated inFIG. 7, thereby searching the VM-exit notice condition1363directed to the guest VMM109. When, for the reason for occurrence of the VM-exit during the execution of the user program, the VM-exit notice condition1363is set, the CPU control module12proceeds to Step S12of notifying the guest VMM109of the VM-exit. On the other hand, when, for the reason for occurrence of the VM-exit during the execution of the user program, the VM-exit notice condition1363is not set, the CPU control module12proceeds to Step S15, and carries out a virtual machine process as in a conventional case.

In Step S12of notifying the guest VMM109of the VM-exit, the CPU control module12executes the VM-exit instruction execution module1222ofFIG. 3, thereby emulating a predetermined process (such as the startup of the state area selection module121) required for switching the subject virtual CPU to the VMX root mode.

FIG. 12is a flowchart illustrating the subroutine of the emulation process of the VM-exit instruction execution module1222carried out by the host VMM103in Step S12. This flowchart illustrates the process carried out by the VM-exit instruction execution module1222illustrated inFIG. 3in the VMX non-root mode.

In Step S21, the VM-exit instruction execution module1222of the host VMM103clears, to zero, all entries of the update state2273and the dirty state2274of the update bitmap227of the virtual CPU control data114.

In Step S22, the host VMM103obtains the occurrence reason1360from the shadow VMCS #1corresponding to the user program having caused the VM-exit. In the VMX non-root mode, the process of Step S12ofFIG. 8is carried out, and thus, the host VMM103reads the shadow VMCS #1used in the VMX non-root mode.

Then, the host VMM103stores the obtained occurrence reason1360in the virtual VM-exit trigger information1232of the shadow VMCS reference/update module123of the CPU control module12.

Then, in Step S23, the host VMM103refers to the prefetch entry information1231of the shadow VMCS reference/update module123, thereby obtaining a column corresponding to the obtained occurrence reason1360(subject entries12313).

In Step S24, the host VMM103refers to the top entry of the column (such as the entry12313corresponding to CS of the guest-state area inFIGS. 9A and 9B, for example) of the prefetch entry information1231obtained in Step S23.

Then, in Step S25, the host VMM103determines whether the value of the referred entry is “1” or not. If the value of the entry is “1”, the host VMM103proceeds to Step S26.

In Step S26, the host VMM103obtains the value in the field of the shadow VMCS #1specified by the area name12311and the field name12312of the prefetch entry information1231. In other words, because the process illustrated inFIG. 12is carried out in Steps S3, S11, and S12ofFIG. 8, the process is carried out for the VM-exit in the VMX non-root mode. Thus, the shadow VMCS #1is referred to as illustrated inFIG. 5. On the other hand, if the value of the entry is “0”, the host VMM103proceeds to Step S30, refers to the next entry, and repeats the above-mentioned process of Step S25.

In Step S27, the host VMM103writes the value of the field obtained in Step S26in a field of the guest VMCS22specified by the area name12311and the field name12312of the prefetch entry information1231, thereby updating the field.

Then, in Step S28, the host VMM103sets “1” to the update state2273of the update bitmap227corresponding to the prefetch entry information1231presently being referred to, thereby indicating that the corresponding field in the guest VMCS22has been updated.

Then, in Step S28, the host VMM103determines whether, for all the entries whose values are set to “1” out of the entries12313in the column of the prefetch entry information1231obtained in Step S23, values of the guest VMCS22are updated by the values in the shadow VMCS #1. When all the entries of the obtained column have been processed, the subroutine ofFIG. 12is finished, and the host VMM103returns to the process ofFIG. 8. On the other hand, when all the entries of the obtained column have not been processed, the host VMM103proceeds to Step S30, refers to the next entry, and repeats the process from Step S25to Step S29.

As a result of the process illustrated inFIG. 12, in the case where the VM-exit occurs in the VMX non-root mode, and where, in the occurrence reason1360, the VM-exit notice condition1361to the guest VMM is set, the VM-exit instruction execution module1222ofFIG. 12can select a column (entries12313) in the prefetch entry information1231corresponding to the occurrence reason for the VM-exit, and for all the fields having the value of the entry of “1” in the column, read values in a batch from the shadow VMCS #1, thereby updating the guest VMCS22.

In other words, by defining, based on the occurrence reason for the VM-exit, which fields of the shadow VMCS #0are to be read in the prefetch entry information1231, the values of the plurality of fields in the shadow VMCS #1can be read in a batch in the VMX non-root mode when the VM-exit occurs once, and the guest VMCS22can be updated by the values of the shadow VMCS #1. As a result, the guest VMM109writes, to the guest VMCS22, values of the fields of the shadow VMCS #1which are highly possibly referred to by the virtual VMREAD instruction, and it is thus possible to restrain the VM-exit from frequently occurring upon the reference to the guest VMCS22.

After the completion of the subroutine ofFIG. 12, the CPU control module12proceeds to Step S13ofFIG. 8.

Then, in Step S13, the CPU control module12switches the operation mode of the subject virtual CPU from the VMX non-root mode to the VMX root mode, and hence the CPU control module12resets the operation mode flag143of the subject virtual CPU from “1” to “0”. Then, in Step S14, the CPU control module12reads the statuses of the guest VMM109stored in the host-state area221from the virtual CPU control data114of the subject guest VMM109.

When the process of Step S14has been completed, processes of Steps S8b, S9b, and S10are sequentially carried out. In Step S8b, the CPU control module12issues the VMPTRLD instruction, thereby switching the shadow VMCS #1to the shadow VMCS #0. In Step S9b, the CPU control module12updates the guest-state area131of the subject shadow VMCS130by the information of the host-state area222read in Step S14, thereby setting the status of the guest VMM109. When it is determined that the guest VMM109does not change the host-state area, there may be provided an implementation which skips this process.

In Step S10, the CPU control module12issues the VM-entry instruction to the physical CPU104.

As a result, when the physical CPU104receives the VM-entry instruction, the physical CPU104executes the guest VMM109of the subject virtual server based on the content of the guest-state area131of the shadow VMCS130specified by the pointer115.

Through the above-mentioned process, if the grandchild OS111ais the new-generation OS incorporating the virtualization feature, the host VMM103selects the statuses to be written to the guest-state area131of the shadow VMCS130from one of the guest VMM and the user program according to the operation mode of the virtual CPU108aand the reason for the generated VM-exit. Then, when the host VMM103issues the VM-entry instruction to the physical CPU104(first virtual CPU), it becomes possible to switch the execution on the virtual server between the guest VMM and the user program operating on the second virtual CPU provided by the guest VMM, and thus, the guest VMM can provide a plurality of virtualization environments (user programs) on the virtual server.

A description is now given of a process for restraining the VM-exit from frequently occurring due to the virtual VMREAD instruction or virtual VMWRITE instruction by the guest VMM109.

In Step S4ofFIG. 8, when the mode is the VMX root mode, and the occurrence reason for the VM-exit is the VMREAD instruction, the CPU control module12proceeds to Step S16, and carries out the emulator process carried out by the VMREAD/VMWRITE instruction execution module1225. A detailed description is later given of the emulator process by the VMREAD/VMWRITE instruction execution module1225referring to a subroutine illustrated inFIG. 15.

In Step S16, when the shadow VMCS #1has been read, the CPU control module12proceeds to Step S10, sets the status of the guest VMM109, and issues the VM-entry instruction to the physical CPU104. After the VM-entry instruction has been issued, the physical CPU104resumes the VMREAD emulator starting from Step S45illustrated inFIG. 13.

FIG. 14is a flowchart of the subroutine illustrating an example of the update process for the shadow VMCS carried out in Step S9ofFIG. 8. This process is carried out following Step S5ofFIG. 8, and because the mode is switched to the VMX non-root mode in Step S6, the host VMM refers to the shadow VMCS #1.

A process of writing the data written to the guest VMCS22by the virtual VMWRITE instruction to the guest-state area131of the shadow VMCS130for the update is carried out. This process is carried out by the VMREAD/VMWRITE instruction execution module1225of the CPU control module12.

In Step S51, the host VMM103refers to the update bitmap227of the guest VMM109. In Step S52, the host VMM103refers to the dirty state2274of the top entry (such as CS inFIG. 11) of the update bitmap227. In Step S53, the host VMM103determines whether the referred dirty state2274is “1”. When the referred dirty state2274is “0”, the corresponding field in the guest VMCS22has not been updated, the host VMM103thus refers to the next entry, and repeats the process of Step S53.

On the other hand, when the referred dirty state2274is “1”, the corresponding field in the guest VMCS22has been updated, the host VMM103proceeds to Step S54, and reads the value of the field corresponding to the dirty state2274from the guest VMCS22.

Then, in Step S55, the host VMM103writes the value of the field read in Step S54to the corresponding field of the shadow VMCS130for update.

In Step S56, when all the entries in the update bitmap227have been processed, the host VMM103finishes the subroutine, and returns toFIG. 8. On the other hand, when all the entries in the update bitmap227have not been processed, the host VMM103proceeds to Step S57, and repeats the process from Step S53to Step S56.

As a result of the above-mentioned process, the values of the fields of the guest VMCS22having the dirty states2274of “1” in the update bitmap227are reflected to the shadow VMCS130.

FIG. 15is a flowchart illustrating an example of the VMREAD instruction process carried out in Step S16ofFIG. 8. This flowchart illustrates the process carried out by the VMREAD/VMWRITE instruction execution module1225ofFIG. 3. This process is carried out when the VM-exit is generated by the VMREAD emulator231of the guest VMM109, which is described later, and the occurrence reason for the VM-exit generated in the VMX root mode is the VMREAD instruction.

In Step S61, the VMREAD/VMWRITE instruction execution module1225of the host VMM103refers to the VM-exit information field136of the shadow VMCS #0, thereby obtaining an instruction address of the VMREAD instruction issued by the VMREAD emulator231of the guest VMM109.

In Step S62, the host VMM103decodes the VMREAD instruction at the instruction address obtained by the host VMM103in Step S61, thereby obtaining operand information. On this occasion, as the operand information, for example, first operand information represents a register number to which a result of the VMREAD instruction is to be returned, and second operand information represents field information of the shadow VMCS #0to be referred to by the VMREAD instruction.

In Step S63, the host VMM103identifies, based on the second operand information obtained in Step S62, the field of the shadow VMCS #0to be read by the VMREAD instruction.

In Step S64, the host VMM103issues the VMPTRLD instruction to the physical CPU104, thereby switching the shadow VMCS130to the shadow VMCS #1for the VMX non-root mode which is provided for the user program. In other words, in order that the VMREAD emulator231of the guest VMM109obtain status indicating how the user program110ahas been operating, the host VMM103switches the shadow VMCS130, which is subject to reading, to the shadow VMCS #1for the VMX non-root mode.

In Step S65, the host VMM103issues the VMREAD instruction, thereby reading the information in the field identified in Step S63from the switched shadow VMCS #1.

Then, in Step S66, the host VMM103writes the value of the field of the shadow VMCS #1obtained in Step S65to the guest VMCS22, thereby updating the information in the field.

In Step S67, the host VMM103issues the VMPTRLD instruction to the physical CPU104to switch the shadow VMCS130to the shadow VMCS #0used in the VMX root mode, which is used by the guest VMM109, thereby switching back to the shadow VMCS130which is intended to be operated by the host VMM103.

In Step S68, the host VMM103sets the update state2273of the update bitmap227corresponding to the field identified in Step S63to “1”, thereby recording the fact that the value of the shadow VMCS #1has been reflected to the guest VMCS22.

In Steps S69and S70, the occurrence reason for the VM-exit from the VMREAD emulator231of the guest VMM109is estimated that the field identified in Step S63is not set to “1” in the prefetch entry information1231. Therefore, in order to prevent the VM-exit from occurring for the next VMREAD instruction, learning is carried out.

First, in Step S69, the occurrence reason for the virtual VM-exit, which is the virtual VMREAD instruction, is identified as the virtual VM-exit trigger information. Then, the host VMM103identifies, out of the prefetch entry information1231, a column of entries12313corresponding to the virtual VM-exit trigger information.

Then, in Step S70, in the identified column, the host VMM103sets the entry12313corresponding to the field identified in Step S63to “1”, and finishes the process.

As a result of the above-mentioned process, first, the VMREAD/VMWRITE instruction execution module1225executes the VMREAD instruction issued by the VMREAD emulator231of the guest VMM109, thereby reflecting the values of the shadow VMCS #1to the guest VMCS22. Then, by setting “1” to the entries12313corresponding to the virtual VM-exit trigger information which triggers the guest VMM109to issue the VMREAD instruction out of the prefetch entry information1231, the VMREAD/VMWRITE instruction execution module1225sets the subject fields of the VMREAD instruction carried out by the host VMM103this time to the subject of the prefetch, thereby restraining subsequent VM-exit.

(Details of Processes by Guest VMM)

FIG. 13is a flowchart illustrating an example of the emulation process carried out by the guest VMM109.FIG. 13illustrates an example of the process by the VMREAD emulator231and VMWRITE emulator232of the instruction code230of the guest VMM109illustrated inFIG. 3. InFIG. 3, Steps S42to S45relate to the VMREAD emulator231, and Steps S46to S48relate to the VMWRITE emulator232. In this process, the guest VMM109starts the emulator in place of execution of the VMREAD instruction or the VMWRITE instruction.

The guest VMM109determines whether the request corresponds to the virtual VMREAD or virtual VMWRITE, proceeds to Step S42in the case of the virtual VMREAD instruction, and starts the VMREAD emulator231, whereas the guest VMM109proceeds to Step S46in the case of the virtual VMWRITE instruction, and starts the VMWRITE emulator232.

In the process carried out by the VMREAD emulator231, in Step S42, the guest VMM109refers to the update bitmap227of the virtual CPU control data114. Then, in Step S43, the guest VMM109determines whether fields to be read, which are specified by the virtual VMREAD instruction, have “1” in the update state2273.

When the update state2273is “1”, for the subject field of the virtual VMREAD instruction, the guest VMM109has been updated to the latest value of the shadow VMCS130by the prefetch, and thus the guest VMM109proceeds to Step S45.

On the other hand, the update state2273is “0”, to the corresponding field in the guest VMCS22, the latest value of the shadow VMCS130is not reflected, and thus the guest VMM109proceeds to Step S44.

In Step S44, the guest VMM109, in order to read, from the shadow VMCS130, the field specified by the virtual VMREAD instruction, issues the actual VMREAD instruction (physical VMREAD instruction) to the physical CPU104.

As a result of the guest VMM109actually issuing the VMREAD instruction, the physical CPU104generates the VM-exit, thereby passing the control to the host VMM103. Then, by the process illustrated inFIG. 15, the host VMM103reflects the value of the field requested by the virtual VMREAD instruction from the shadow VMCS #1to the guest VMCS22, carries out the learning control, and then, passes, by means of the VM-entry instruction, the control to the guest VMM109.

Then, the guest VMM109, in Step S45, reads a value of the subject field in the guest VMCS22updated with the value of the shadow VMCS130, thereby reflecting it to a predetermined destination. As the predetermined destination, a general register or the memory is specified.

On the other hand, when the virtual VMWRITE instruction is issued, in Step S46, the guest VMM109refers to the update bitmap227of the virtual CPU control data114. In Step S47, the guest VMM109sets the dirty state2274corresponding to the field specified in the virtual VMWRITE instruction to “1”.

Then, in Step S48, the guest VMM109writes data specified by the virtual VMWRITE instruction to the field of the guest VMCS22specified by the virtual VMWRITE instruction.

In the above-mentioned process, the guest VMM109carries out, via the VMREAD emulator231or VMWRITE emulator232, the read from or write to the guest VMCS22without generating the VM-exit. Only when the update bitmap227contains the update states2273whose values are “0”, the guest VMM109issues the VMREAD instruction, and consequently, the physical CPU104generates the VM-exit, and the host VMM103starts the above-mentioned VMREAD/VMWRITE instruction execution module1225and updates the guest VMCS22with the values of the shadow VMCS #1.

SUMMARY

If it is determined that the grandchild OS does not use the virtualization feature in Step S1, or it is determined that the virtual CPU does not use the VT-x feature of the physical CPU104in Step S2, the virtual machine process as described in the conventional example of Japanese Patent Translation Publication No. 2005-529401, or “Intel 64 and IA-32 Architectures Software Developer's Manual VOL 2B” may be carried out on the host VMM103in Step S15.

In the virtual machine process of Step S15, for example, the grandchild OS111nof the virtual server102nillustrated inFIG. 2is a conventional OS, and if this grandchild OS111nor the application program112n(user program) executes a predetermined instruction such as a privilege instruction, as described above, the physical CPU104notifies the host VMM103of the occurrence of the VM-exit.

When the host VMM103receives the notice of the VM-exit from the physical CPU104, the host VMM103stores the status of the user program (virtual CPU108n) in the guest-state area131of the shadow VMCS #n−1. Then, the host VMM103sets an address of the pointer115to the host-state area in which the status of the host VMM103is stored, and carries out a predetermined process.

When the host VMM103has completed the predetermined process such as the privilege instruction, the host VMM103stores the status of the host VMM103in the host-state area132, sets the address of the pointer115to the guest-state area131, then, issues the VM-entry instruction (VMRESUME instruction), and passes the control to the virtual CPU108n, thereby resuming the execution of the user program.

In this way, according to this invention, it is possible to integrate a new-generation OS incorporating the virtualization feature and a conventional OS into the single physical server101, thereby reducing the number of physical servers to reduce the operation/management cost of the servers.

Further, as described above, the host VMM103can make it appear to the new-generation OS that the virtual CPU provides the VT-x feature, thereby enabling an OS incorporating a virtualization software program to surely operate. Moreover, with the host VMM103according to this invention, there is no overhead caused by the conversion of an instruction sequence as in the conventional simulator, and thus, there is no decrease in the performance of the virtual machine, and the OS incorporating the virtualization feature can be executed on the virtual server.

Then, when the guest VMCS22is to be referred to or updated, the virtual VMREAD instruction or virtual VMWRITE instruction is issued, thereby enabling access while the VM-exit is restrained from frequently occurring, which enables an increase in processing capability of the virtual server.

Then, when the VM-exit occurs, in the VMX non-root mode, the prefetch is carried out thereby updating contents of the guest VMCS22in a batch with contents of the shadow VMCS #1, and further, the occurrence reason for the VM-exit of this time is learned and reflected to the prefetch entry information1231for the subsequent prefetch, which decreases the occurrence of the VM-exit.

Moreover, according to this invention, because there are provided the plurality of shadow VMCSs130(#0to #n−1) in correspondence to the plurality of virtual CPUs108ato108n, even when a plurality of guest VMM's109are executed on the physical server101, it is possible to quickly switch a process only by switching the shadow VMCSs130(#0to #n−1). As a result, even if a plurality of new-generation OSs are integrated on the physical server101, it is possible to maintain the performance of the virtual server.

As described above, according to this invention, because the host VMM103monitors the states of the grandchild OS and the application program and the states of the virtual CPUs, thereby rewriting the guest-state area131of the shadow VMCS130, it is possible to surely operate the OS incorporating the virtualization software without decreasing the performance of the virtual server. Then, it is possible to make the new-generation OS incorporating the virtualization feature and a conventional OS to coexist on the single physical server101, thereby efficiently carrying out the server integration to reduce an operation cost of the server.

Moreover, by using the virtual VMREAD instruction or virtual VMWRITE instruction, the physical CPU104can restrain the frequency of occurrence of VM-exit, thereby increasing the processing capability of the virtual server.

It should be noted that the processors described as the physical CPU104according to the embodiment may have a configuration of a multi-core processor, and homogeneous or heterogeneous processors may be employed. In other words, when, as the physical CPU104, a heterogeneous multi-core processor including a plurality of general-purpose processor cores (CPUs) and special-purpose processor cores is used, as long as the general-purpose processor core has the virtualization support feature, this invention can be applied.

As described above, this invention may be applied to a virtual machine system providing a plurality of virtual servers. Moreover, this invention may be applied to a virtual machine manager (VMM) software program for providing a plurality of virtual servers on a physical computer.