JP2013218738A - Virtualization program, virtual computer system, and computer system control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute a next-generation OS integrated with a virtualization function in a virtual server without deteriorating performance of a virtual computer, and to integrate the next-generation OS and an existing OS in one physical computer.SOLUTION: One of a guest state area 221 for executing a user program and a host state area 222 for executing a guest VMM is selected according to a factor of a call of a host VMM, and a guest state area 131 of a shadow VMCB for controlling a physical processor is updated. Thereby, a next-generation OS having a virtualization function is executed as the user program on a virtual processor.

Description

  The present invention relates to a virtual machine system, and more particularly to a virtual machine system using a processor having a virtualization support function.

  In recent years, with the spread of open servers, a large number of servers have been introduced into corporate information systems. In particular, the iA (Intel Architectures) -32 server, which has a high price-performance ratio, has increased server operation and management costs, including power and hardware maintenance costs, and has become a problem for companies that operate servers. .

  In order to reduce the operation management cost of servers, server integration that consolidates a plurality of servers into one physical server (physical server) is promising. As a server integration implementation method, virtualization software that provides a function for virtualizing computer resources has attracted attention. The virtualization software is control software that divides computer resources such as CPU (processor) and I / O of one physical server and allocates the divided computer resources to a plurality of virtual servers (virtual servers). Each virtual server can run one OS (Guest OS) When using virtualization software, an OS or application that has conventionally been run on multiple physical servers is assigned to each virtual server, and one physical Server integration that provides a plurality of servers on a computer can be realized.

  A policy for assigning computer resources to virtual servers in virtualization software will be described. Regarding the allocation of CPUs among computer resources, in the virtualization software for iA-32, a method using a processor having a virtualization support function such as VT-x (Virtualization Technology for Xeon) function (or AMD-V) is mainstream. It is. VT-x is a function for assigning different operating authorities to virtualization software and guest OS, and is implemented in the hardware of the processor (for example, Patent Document 1 or Non-Patent Documents 1 and 2). The CPU corresponding to VT-x detects the shift of the operating authority between the guest OSs and the virtualization software, saves and restores the register state of the CPU, and provides an independent operating environment for each virtual server.

On the other hand, the I / O allocation policy differs depending on the virtualization software. The I / O allocation of virtualization software is
(1) an I / O direct allocation type that directly uses an I / O device of a physical server;
(2) It is roughly classified into a virtual I / O allocation type that conceals the type and revision of an I / O device of a physical server.

  The I / O direct allocation type (1) has an advantage that server integration can be easily realized without rebuilding a file system or the like for I / O that has already been operated on a physical server. On the other hand, the virtual I / O assignment type (2) has an advantage that a constant 1 / O configuration can be provided to the guest OS regardless of the I / O type of the physical server.

  Here, the following is known as the virtualization software as described above. First, VMware (registered trademark) ESX Server is known as one of the virtualization software for the iA-32 server. This is a physical server including an iA-32 CPU, and it is possible to operate a plurality of existing OSs using the above-described VT-x function.

  As virtualization software based on the technology of general-purpose machines, a logical division operation function is known (IBM System 370 and the like). In this method, a single physical computer is divided into a plurality of logical partitions (LPAR), and an existing OS and a virtualization management unit (VMM = Virtual Machine Manager) are executed on each LPAR. In the logical partitioning operation function, a general-purpose machine (physical computer) operates a conventional OS and VMM on a virtual server (LPAR) by using a function (LPAR mode) corresponding to VT-x of iA-32. Yes.

  In addition, SimOS (http://simos.stanford.edu/introduction.html) and the like are known as those that provide a VT-x function of iA-32 by a simulator. This type of simulator is software that provides an arbitrary server and CPU function by interpreting a command sequence of a guest OS on a virtual server.

  Furthermore, as a virtualization support function implemented in a processor of iA-64 (IPF = Itanium Processor Family), the VT-i function described in Non-Patent Document 3 is known.

JP 2005-529401A

"Intel 64 and IA-32 Architectures Software Developer's Manual VOL 2B", [online], published by Intel corp., [Searched May 1, 2007], Internet <URL: http://www.intel.com/design /processor/manuals/253667.pdf> "AMD-Virtualization (AMD-V)", [online], published by Advanced Micro Devices, Inc., [Search May 1, 2007], Internet <URL: http://www.amd.com/jp- en / assets / content_type / DownloadableAssets / jp-ja_AMD-V_general_200702.pdf> "Intel Itanium Architecture Software Developer's Manual", [online], published by Intel corp., [Searched May 1, 2007], Internet <URL: ftp://download.intel.com/design/Itanium/manuals/24531705 .pdf>

  By the way, due to the recent demand for server integration, the next generation server OS (Windows (registered trademark) Server Longhorn or Windows (registered trademark) Server 2008, etc.) has a virtual I / O allocation type virtual as described in (2) above. It is under consideration to install the function of the computerized software.

  However, the conventional virtualization software has the following problems.

  In the conventional virtualization software such as the ESX server, it is possible to operate an existing OS on a plurality of virtual servers by using the virtualization support (VT-x) function of the CPU constituting the physical computer. The VT-x function cannot be provided to the virtual server. For this reason, the ESX server or the like has a problem that it is difficult to execute an OS integrated with virtualization software (virtualization function) like a next-generation server OS.

  In the logical partitioning operation function, the OS or VMM on the LPAR cannot use the LPAR mode. For this reason, there is a problem that it is difficult to run an OS integrated with virtualization software on the LPAR.

  Further, in the case of the simulator, the VT-x function can be provided to the virtual server, and it is possible to operate a next-generation OS integrated with virtualization software. However, the simulator generates overhead for interpreting the instruction sequence of the virtual server (guest OS) and converting it into an instruction sequence executable by the CPU of the physical computer (binary translation). There is a problem that the processing capability is reduced, and it is not realistic to perform server integration for operating a plurality of virtual servers.

  In addition, the next-generation OS that integrates virtual I / O allocation type virtualization functions is suitable for generating many virtual servers with the same I / O configuration, such as providing a development environment. It is not suitable for use in integrating a conventional operating OS (OS that does not use the VT-x function, such as an NT server). In particular, software assets that are currently operated by companies are mostly software that runs on an OS that does not include a virtualization function. For this reason, in the process of proceeding with server integration in the future, a server integrated environment in which an existing OS that does not include a virtualization function and a next-generation OS that includes a newly introduced virtualization function is required. However, as described above, in the conventional example, it is difficult to integrate a next-generation OS integrated with a virtualization function on a virtual machine, and it is difficult to integrate an existing OS with a next-generation OS. It was.

  Therefore, the present invention has been made in view of the above problems, and an object thereof is to provide a virtual machine capable of executing an OS integrated with a virtualization function on a virtual server without degrading the performance of the virtual machine. It is another object of the present invention to integrate a next-generation OS that integrates a virtualization function and a conventional OS that does not use a processor virtualization support function into one physical computer.

The present invention is a virtualization program that is executed by a physical computer including a physical processor and a memory and operates a host virtual machine manager and a guest virtual machine manager.
A procedure in which the guest virtual machine manager stores, in the memory, first control information indicating a state of a virtual processor during execution of a user program; and when the guest virtual machine manager executes the guest virtual machine manager. Determining the second control information indicating the state of the virtual processor in the memory and whether the host virtual machine manager is executing the user program or the guest virtual machine manager And a procedure for updating control information between one of the first control information or the second control information and the third control information, and the host virtual machine manager sends the physical processor to the physical processor A procedure for issuing a first control instruction to be executed based on the third control information; Make.

  Therefore, the present invention selects either the first control information for executing the user program or the second control information for executing the guest virtual machine manager, and the third control information for controlling the physical processor. By updating the control information, it is possible to execute a next-generation OS having a virtualization function on the virtual processor as a user program. In addition, switching between the user program and guest virtual machine manager can be achieved by updating the third control information with the first or second control information, so that the next-generation OS can be operated without degrading the performance of the virtual machine. it can.

  Then, an existing OS that does not have a guest virtual machine manager and a next-generation OS that includes a guest virtual machine manager can be integrated into one computer.

1 is a block diagram of a virtual machine system according to a first embodiment and applying the present invention. FIG. FIG. 3 is a block diagram illustrating functions of a host VMM and a guest VMM according to the first embodiment. 4 is a block diagram illustrating an example of control data of a shadow VMCB of host VMM holding data according to the first embodiment. FIG. It is explanatory drawing which shows 1st Embodiment and shows an example of the factor list | wrist of VM-exit. FIG. 10 is a flowchart illustrating an example of processing performed by the host VMM according to the first embodiment, and illustrates VM-exit processing caused by a VM-entry instruction. FIG. 6 is a flowchart illustrating an example of processing performed by the host VMM according to the first embodiment, and illustrates VM-exit processing caused by a VMCLEAR instruction. FIG. 9 is a flowchart illustrating an example of processing performed by the host VMM according to the first embodiment, and illustrates VM-exit processing caused by a CPUID command. It is a screen image which shows 1st Embodiment and shows an example of a user interface. FIG. 10 is a block diagram illustrating functions of a host VMM and a guest VMM when a physical CPU supports the AMD-V function according to the second embodiment. FIG. 9 is a block diagram illustrating an example of control data of a shadow VMCB of host VMM holding data according to the second embodiment. It is explanatory drawing which shows 2nd Embodiment and shows an example of the factor list | wrist of #VMEXIT. FIG. 10 is a flowchart illustrating an example of processing performed in the host VMM according to the second embodiment, and illustrates #VMEXIT processing caused by a VMRUN instruction. FIG. 10 is a block diagram illustrating functions of a host VMM and a guest VMM when a physical CPU supports a VT-i function according to the third embodiment. FIG. 10 is a block diagram illustrating an example of host VMM holding data shadow VPD and virtual CPU control data B control data according to the third embodiment. It is explanatory drawing which shows 3rd Embodiment and shows an example of the factor list | wrist of a virtualization exception. The flowchart which shows a 3rd embodiment and shows an example of the process performed by host VMM, and shows the virtualization exception process resulting from PAL_VPS_RESUME procedure execution.

  Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.

  FIG. 1 is a block diagram of a virtual machine system to which the present invention is applied according to the first embodiment. A physical server (physical computer) 101 has a virtualization support function and executes a physical CPU (processor) 104, a memory 105 for storing data and programs, and data transmission / reception with devices external to the physical server 101. And an I / O device 106 for performing the above. The I / O device 106 includes a network interface and a host bus adapter. The physical CPU 104 may be composed of a plurality of CPUs or a CPU including a plurality of arithmetic cores. Further, the virtualization support function (VMX: Virtual Machine Extensions) of the physical CPU 104 is based on the above-mentioned VT-x (Virtualization Technology for IA-32 Processors), AMD-V (AMD Virtualization Technology), or VT-i (Virtualization Technology for Itanium). architecture processors). Note that an operation mode using the virtualization support function is a VMX mode, and an operation mode based on a normal privilege level not using the virtualization support function is a normal operation mode.

  In the physical server 101, in order to operate a plurality of virtual servers 102a to 102n, the host VMM that converts the physical computer resources of the physical server 101 into virtualized computer resources and allocates the virtual computer resources to the virtual servers 102a to 102n. (Virtual Machine Manager) 10 is executed. The host VMM is provided as a program that is read into the memory 105 and executed by the physical CPU 104. The host VMM 10 provides virtual CPUs 108a to 108n to the virtual servers 102a to 102n, and allocates the memory 105 and the I / O device 106 to the virtual servers 102a to 102n. Note that, as a method of assigning the computer resources of the physical server 101 to the virtual servers 102a to 102n, any known or publicly known method may be used as appropriate, and therefore will not be described in detail here.

  The physical server 101 is connected to a management console 300 that provides a user interface 301, and an administrator or the like inputs settings such as computer resource assignment to the host VMM 10 via the user interface 301. In addition, the user interface 301 outputs the setting state received from the host VMM 10 to the display device of the management console 300.

  In the virtual servers 102a to 102n operating on the host VMM 10 of the physical server 101, guest OSs 111a to 111n operate as user programs 110a to 110n, and applications 112a to 112n are executed on the guest OSs 111a to 111n. Each of the guest OSs 111a to 111n is executed by virtual CPUs 108a to 108n provided by the host VMM 10. The virtual CPUs 108a to 108n can allocate a plurality of virtual CPUs to one virtual server.

  In the virtual server 102a, a next-generation OS that integrates a virtualization function (guest VMM 20) is executed as the guest OS 111a. In the virtual server 102n, an existing OS that does not use the virtualization function as the guest OS 111n (for example, an NT server). Is executed.

  The host VMM 10 allocates the virtual CPU 108n and computer resources set from the management console 300 to the virtual server 102n that executes the existing OS, and executes the existing guest OS 111n and the application 112n.

  On the other hand, the host VMM 10 provides a virtualization support function to the virtual CPU 108a assigned to the virtual server 102a that executes the next-generation OS. A guest VMM (second virtual machine manager) 20 runs on the virtual CPU 108a, and the guest VMM 20 provides virtual CPUs 208a to 208i. In the virtual server 102a on which the next-generation OS runs, a plurality of second virtual CPUs 208a to 208i are provided on the first virtual CPU 108a, and each of the virtual CPUs 208a to 208i has a plurality of user programs 110a (guest OS 111a and application 112a) to 110i (guest OS 111i and application 112i) is executed.

  Hereinafter, in the first embodiment, an example of a next-generation OS in which the physical CPU 104 has the VT-x function and the guest OS 111a of the virtual server 102a integrates the virtualization function will be described.

  The host VMM 10 that uses the VT-x function stores the host VMM holding data 11 that stores the state of the virtual servers 102 a to 102 n and control information for controlling the physical CPU 104 in a predetermined area of the memory 105. The host VMM holding data 11 stores physical CPU control data 13 for controlling the physical CPU 104. The physical CPU control data 13 is a data structure indicating the status of the virtual CPUs 108a to 108n using the virtualization support function, and is called a VMCB (Virtual Machine Control Block) or VMCS (Virtual Machine Control Structure). In this embodiment, the physical CPU control data 13 in the host VMM holding data 11 is the shadow VMCB # 0 to #n as shown in FIG. 2, and the virtual CPU control data 21 operated by the guest VMM 20 is the guest VMCB. Distinguish. The physical CPU 104 also includes a pointer 115 for referring to the shadow VMCBs # 0 to #n of the physical CPU control data 13.

  The host VMM 10 rewrites the shadow VMCBs # 0 to #n in the physical CPU control data 13, thereby changing the operation mode of the physical CPU 104 to the operation mode (VMX non-root mode) for executing the user program 110a or the guest VMM 20, and the host The operation mode (VMX root mode) for executing the VMM 10 is set.

  In the virtual server 102a, on the virtual CPU 108a provided by the host VMM 10, a virtualization function (virtualization software) integrated with the guest OS 111a, which is the next generation OS, operates as the guest VMM 20. The guest VMM 20 stores virtual CPU control data 21 including a VMCB (guest VMCB 22) for controlling the virtualization support function of the virtual CPU 108a. The guest VMCB 22 is stored in a predetermined area on the memory 105 allocated by the host VMM 10.

  In addition, the virtual CPU 108 a includes a pointer 116 for referring to the virtual CPU control data 21 (guest VMCB 22) of the guest VMM 20. This pointer 116 is a pointer to the control data structure (guest VMCB 22) of the virtual CPU 108a held by the guest OS 111a corresponding to the VT-x function, and is initialized when a VMPTRLD instruction is issued from the guest OS 111a. The guest VMM 20 executes the initialization of the pointer 116.

  In FIG. 1, the virtual CPUs 208a to 208i of the virtual server 102a on which the next-generation OS runs are provided by the guest VMM 20 integrated with the next-generation OS, and the user programs 110a to 110i are executed on the virtual CPUs 208a to 208i. can do. Note that the guest VMM 20 of the virtual server 102a may function as add-in software for the guest OS 111a.

<Outline of the present invention>
In the VT-x function that supports virtualization, the host VMM 10 controls the operation mode of the physical CPU 104 using the shadow VMCB secured on the memory 105 of the physical server 101. The physical CPU 104 having a VT-x function as a virtualization support function has a normal operation mode and a VMX (Virtual Machine Extensions) mode that provides a virtualization support function. In the VMX mode, a host mode (where the host VMM 10 operates) ( Hereinafter, the mode is switched to either the VMX root mode) or the guest mode in which the guest VMM 20 or the user program (guest OS 111a or application 112a) operates (hereinafter, VMX non-root mode).

  The shadow VMCB of the physical CPU control data 13 has only one type of field (guest state area 131) that defines the operation state of the user program 110a on the virtual server 102a, which is simply a virtualization function of the next generation OS. The guest VMM 20 and the user program 110a (guest OS 111a or application 112a) cannot be distinguished.

  Therefore, in the present invention, focusing on the fact that one virtual CPU does not execute the guest VMM 20 and the user program 110a at the same time, the guest VMM 20 of the virtual server 102a that executes the guest OS 111a in which the host VMM 10 integrates the virtualization function. And monitoring the switching of execution of the user program 110a, and rewriting the guest state area 131 in the shadow VMCBs # 0 to #n of the host VMM holding data 11 at the time of switching the operation mode, thereby virtualizing on the virtual server 102a. The function is activated.

  Therefore, the host VMM 10 monitors the guest OS 111a, which is the next generation OS that integrates the virtualization function, and changes the operation mode of the physical CPU 104, the VMX root mode in which the host VMM 10 operates, and the guest VMM 20 or the user program 110a. The VMM non-root mode is switched to the VMX non-root mode, and the host VMM 10 emulates the commands of the guest VMM 20 and the guest OS in the VMX root mode under a predetermined condition (VM-exit). This makes it appear to the guest OS 111a that the virtual CPU 108a provides a virtualization support function.

<Configuration of host VMM>
The host VMM 10 includes a CPU control unit 12 that monitors the virtual servers 102a to 102n and switches the operation mode of the physical CPU 104 to either the VMX root mode or the VMX non-root mode in addition to the host VMM holding data 11 described above. .

  Further, the host VMM 10 includes a control / communication interface 14 that is an interface for the CPU control unit 12 to acquire the status of the virtual servers 102a to 102n and transmit commands to the virtual servers 102a to 102n, and the CPU control unit 12 An instruction issue interface 15 for issuing instructions to the physical CPU 104, a reference / update interface 16 for the physical CPU 104 to reference or update the physical CPU control data 13, an interrupt request from the I / O device 106, etc. And an I / O request / response interface 17 for responding to the request.

  FIG. 2 is a block diagram illustrating functions of the host VMM 10 and the guest VMM 20. The host VMM 10 sets the host VMM holding data 11 in a predetermined area of the memory 105 in order to use the virtualization support function (VT-x function) of the physical CPU 104.

  The host VMM holding data 11 is a shadow that stores an area for storing presence / absence of use of the virtualization support function of the guest OSs 111a to 111n, a flag indicating the status of the virtual CPUs 108a to 108n, a status for each of the virtual CPUs 108a to 108n, and the like. It includes a physical CPU control data 13 area that holds VMCBs # 0 to #n.

  As a flag indicating the state of the guest OS or virtual CPU of the host VMM holding data 11, for example, a virtualization function valid flag 141 for identifying whether the virtualization support function of the physical CPU 104 can be used for each of the guest OSs 111a to 111n The VMXON flag 142 for setting whether or not the virtualization support function is being used for each virtual CPU 108a to 108n, and whether the virtual CPU 108a to 108n virtualization support function is operating in the VMX root mode or the VMX non-root mode The operation mode flag 143 indicating

  If the virtualization function valid flag 141 is set for each of the guest OSs 111a to 111n and is “1”, it indicates that the corresponding guest OS can use the virtualization support function. Indicates that the virtualization support function is not used. The virtualization function enable flag 141 is set from the management console 300 for each of the guest OSs 111a to 111n, or set from a preset file or the like.

  The VMXON flag 142 is a flag indicating the operation state of the VMX mode for each of the virtual CPUs 108a to 108n. When it is “1”, it indicates that the operation mode of the corresponding virtual CPU 108a to 108n is the VMX mode, and when it is “0”. It indicates that the operation mode of the corresponding virtual CPU 108a to 108n is a normal operation mode in which the virtualization support function is not used. The VMXON flag 142 is set to “1” by the host VMM 10 when the guest OSs 111 a to 111 n issue the VMXON command, and is reset to “0” when the guest OSs 111 a to 111 n issue the VMXOFF command.

  The operation mode flag 143 is a flag for tracking the operation mode of a program operating on the virtual CPUs 108a to 108n. The operation mode flag 143 is set to “1” by the host VMM 10 when the guest OSs 111 a to 111 n are VM-entry, and the host VMM 10 is reset to “0” when the guest OS is VM-exit. That is, this operation mode flag 143 indicates the type of VMX mode for each virtual CPU 108a to 108n when the VMXON flag 142 is "1", and when the operation mode flag 143 is "0", the virtual CPUs 108a to 108n Indicates the state in which the guest VMM 20 is executed (VMX root mode of the virtual CPU), and when the operation mode flag 143 is “1”, the virtual CPU executes the user program 110a (guest OS 111a or application 112a) (VMX non-virtual CPU) Root mode).

  Here, transition between the VMX root mode and the VMX non-root mode in the VMX mode is as described in Non-Patent Document 1 above. Here, only the outline will be described. When shifting from the normal operation mode to the VMX mode, the host VMM 10 issues a VMXON instruction to shift the operation mode of the physical CPU 104 to the VMX mode. Then, the host VMM 10 that has shifted to the VMX mode writes information for causing the shadow VMCBs # 0 to # n-1 of the corresponding virtual CPUs 108a to 108n to execute the user program 110a, and then executes a VM-entry instruction (a VMLAUNCH instruction or a VMRESUME instruction). Command) to shift from the VMX root mode to the VMX non-root mode. This transition from the VMX root mode to the VMX non-root mode is called VM-entry.

  Conversely, the transition from the VMX non-root mode to the VMX root mode is referred to as VM-exit. In the VM-exit, the physical CPU 104 notifies the host VMM 10 of the VM-exit due to a predetermined factor such as when the guest OSs 111a to 111n issue privileged instructions. When the CPU control unit 12 of the host VMM 10 detects the VM-exit, after performing the predetermined emulation and completing the processing of the guest VMM 20 or the guest OS, the shadow VMCB is rewritten as necessary, and then the VM-entry instruction (first Control command) to switch from the VMX non-root mode to the VMX root mode.

  In the present invention, during VM-entry of the guest OS 111a, which is the next generation OS, the host VMM 10 reads the guest status area 221 and the host status area 222 of the guest VMCB 22, and the contents of one area according to the operation of the guest OS 111a Is set in the guest status area 131 of the shadow VMCB # 0, the virtual server 102a implements the virtualization function of the guest OS 111a.

  In the VT-x function, the host VMM 10 and the guest VMM 20 or the user program 110a are switched by the transition between the VM-entry and the VM-exit as described above. For this reason, in order to hold the status of the physical CPU 104 before and after the VM-entry and the VM-exit, the shadow VMCBs # 0 to #n that are the data structure of the physical CPU control data 13 are used.

  In the physical CPU control data 13, shadow VMCBs # 0 to #n are set for the virtual CPUs 108a to 108n, and the following data is stored in each shadow VMCB.

  In the guest state area 131, as shown in FIG. 3, statuses such as register states of the virtual CPUs 108a to 108n are stored. That is, as will be described later, the status of the guest VMM 20 or the status of the user program 110a is selectively stored.

  As shown in FIG. 3, the host status area 132 stores status such as the register status of the physical CPU 104 of the host VMM 10. The VM execution control area 133 stores setting information of the virtual servers 102a to 102n, and includes information such as an exception bitmap and an I / O bitmap. The VM-exit control area 134 stores information such as the VM-exit factor. The VM-entry control area 135 stores information for controlling the operation of the VM-entry. The VM-exit information area 136 stores a factor (command or event) that causes the VM-exit. As a factor for generating the VM-exit, for example, the one shown in “description” shown in FIG. 4 is set in the VM-exit information area 136.

  With the shadow VMCBs # 0 to #n as described above, the host VMM 10 controls the virtual servers 102a to 102n.

  On the other hand, in the virtual CPU control data 21 managed by the guest VMM 20 of the virtual server 102a, the guest VMCB 22 having the same data structure as the shadow VMCB # 0 of the physical CPU control data 13 is stored.

  The guest VMM 20 stores a guest state area 221 for storing the status and the like of the register state of the virtual CPU 108a that executes the user program 110a (guest OS 111a or application 112a), and a status of the register state and the like of the virtual CPU 108a that executes the guest VMM 20 Host status area 222, a VM execution control area 223 for storing setting information of the virtual server 102a, a VM-exit control area 224 for storing information such as a VM-exit factor in the virtual server 102a, and a virtual server 102a A VM-entry control area 225 for storing information for controlling the operation of the VM-entry, and a VM-exit information area for storing information for specifying the cause of the VM-exit in the virtual server 102a And a 226.

  The guest status area 221 stores the status such as the register status of the virtual CPU 108a as in FIG. That is, as will be described later, the status of the guest OS 111a or the status of the application 112a is selectively stored.

  In the shadow VMCB # 0 of the host VMM 10 that controls the state of the virtual server 102a, the status of the guest VMM 20 or the status of the user program 110a (guest OS 111a or application 112a) is stored in the guest status area 131, and the host status area 132 stores the host The status of the VMM 10 is stored.

  On the other hand, the guest VMCB 22 of the guest VMM 20 is different from the shadow VMCB # 0 in that the status of the guest OS 111a or the status of the application 112a is stored in the guest state area 221 and the status of the guest VMM 20 is stored in the host state area 222. .

  Next, the configuration of the CPU control unit 12 of the host VMM 10 will be described. In addition to a resource management unit (not shown) that allocates the computer resources of the physical server 101 to each of the virtual servers 102a to 102n based on input from the management console 300, the CPU control unit 12 has a virtualization function (guest) The VMM 20) to operate, a state area selection unit 121 that selects a reading destination of the status of the virtual CPU, an emulator 122, a shadow VMCB reference / update unit 123, a VM-exit handler 124, and a VM-entry instruction issue unit 125 and a user interface 301. Note that the resource management unit is not described in detail in the present embodiment because a known or well-known technique may be applied as described above.

  The VM-exit handler 124 receives the VM-exit from the physical CPU 104 and activates the emulator 122.

  The emulator 122 identifies the instruction or event that has caused the occurrence of the VM-exit received from the VM-exit handler 124, and activates the module corresponding to the identified occurrence factor as will be described later, so that the guest VMM 20 and the user program 110a are activated. Process on behalf of

  When the emulator 122 detects a change in the operation mode of the virtual CPU 108a (switching between the VMX root and the VMX non-root), modules according to the specified factors (VM-entry instruction execution module, VMCLEAR instruction execution module, CPUID instruction execution module) , The VM-exit condition detection module) is activated, and the state area selection unit 121 is activated.

  Here, the generation factor of the VM-exit is set to “Exit reason” in the VM-exit information area 136 of the shadow VMCB # 0 as shown in FIG. The VM-exit factor list shown in FIG. 4 includes a factor 1361 caused by the issuance of the VM-entry instruction, a factor 1362 caused by the issuance of the VMCLEAR instruction (fourth control instruction), and the VM-exit to the guest VMM 20 A notification condition 1363 for setting the presence / absence of notification is set in advance.

  For example, if a VM-entry instruction (VMLAUNCH instruction or VMRESUME instruction) is detected as a VM-exit factor when switching the operation mode of the virtual CPU 108a, it corresponds to the factor 1361 of FIG. Emulation is performed by an entry instruction execution module, and processing is performed in place of the guest VMM 20 or the user program 110a.

  Alternatively, when the cause of the VM-exit is a notification condition to the guest VMM corresponding to the notification condition 1363 in FIG. 4, the VM-exit condition detection module is activated to perform emulation in the same manner.

  The state area selection unit 121 reads the operation mode flag 143 of the virtual CPU (108a in this example) that generated the VM-exit from the host VMM holding data 11, and determines whether the VMX root mode or the VMX non-root mode is set. judge. If the VMX root mode with the operation mode flag 143 set to “0”, the guest VMM 20 was operating, so the state area selection unit 121 operates from the guest VMCB 22 of the virtual server (102a in this example) that generated the VM-exit to the host. The status area 222 is read.

  On the other hand, if the VMX non-root mode in which the operation mode flag 143 is “1”, the user program 110a was operating, so the state area selection unit 121 reads the guest state area 221 from the guest VMCB 22 of the corresponding virtual server 102a. .

  When reading from the guest VMCB 22 is completed, the CPU control unit 12 activates the shadow VMCB reference / update module 123. The shadow VMCB reference / update module 123 writes the information of the guest VMCB 22 read by the state area selection unit 121 into the guest state area 131 of the shadow VMCB # 0 corresponding to the virtual CPU 108a that is the processing target of the VM-exit, and writes the shadow VMCB. Update.

  When the update of the guest state area 131 of the shadow VMCB # 0 is completed, the CPU control unit 12 updates the operation mode flag 143 to “1” in order to switch the operation mode of the virtual CPU 108a from the VMX root mode to the VMX non-root mode. The shadow VMCB # 0 address of the virtual CPU 108a to be operated is set in the pointer 115 of the physical CPU 104.

  Then, the CPU control unit 12 activates the VM-entry instruction issuing module 125 and issues a VM-entry instruction (VMRESUME instruction) to the physical CPU 104.

  When the physical CPU 104 receives the VM-entry command, the physical CPU 104 reads the guest state area 131 of the shadow VMCB # 0 pointed to by the pointer 115 and executes the guest VMM 20 or the user program 110a of the virtual server 102a selected by the state area selection unit 121.

  As described above, when the guest OS 111a of the next generation OS that integrates the virtualization function is operating in the virtual server 102a, when the CPU control unit 12 of the host VMM 10 detects the VM-exit of the physical CPU 104, the shadow VMCB # With reference to the operation mode flag 143 of 0, it is determined whether the program being executed by the virtual CPU 108a is the guest VMM 20 or the user program 110a. Then, the CPU control unit 12 writes the contents of the guest state area 221 or the host state area 222 to the guest state area 131 of the shadow VMCB # 0 of the host VMM 10 according to the program executed by the virtual CPU 108a, and then the VM-entry. Execute the instruction.

  Thus, by updating the guest state area 131 of the shadow VMCB # 0 held by the host VMM 10 with the information of the guest VMCB 22 held by the guest VMM 20 of the virtual server 102a, the virtual server 102a that operates the virtualization function of the guest OS 111a The virtual server 102n that executes an existing OS that does not use the virtualization function can be integrated into one physical server 101.

<Details of host VMM processing>
Next, processing performed by the host VMM 10 will be described below with reference to FIG. FIG. 5 is a flowchart illustrating an example of processing performed by the CPU control unit 12 of the host VMM 10 when receiving a VM-exit from the physical CPU 104 while the virtual servers 102a to 102n are operating. In this example, the VM-exit factor is a VM-entry instruction.

  First, in S <b> 1, the CPU control unit 12 of the host VMM 10 enables the virtualization function of the host VMM holding data 11 corresponding to the operation target guest OSs 111 a to 111 n (hereinafter referred to as guest OSs) that have caused the VM-exit. With reference to the flag 141, it is determined whether or not the guest OS that has generated the VM-exit can use the VT-x function. If the guest OS to be operated can use the VT-x function, the process proceeds to S2. On the other hand, when the guest OS to be operated does not use the VT-x function (NT server or 2000 server or the like), the process proceeds to S15, and the host VMM 10 is described in Patent Document 1 or Non-Patent Document 1 shown in the conventional example. Perform virtual machine processing as described.

  In S2, the host VMM 10 refers to the VMXON flag 142 of the virtual CPUs 108a to 108n (hereinafter referred to as virtual CPUs) that caused the VM-exit, and determines whether or not the operation target virtual CPU is in the VMX mode. To do. If the VMXON flag 142 is “1”, the virtual CPU is in the VMX mode and the process proceeds to S3. On the other hand, when the VMXON flag 142 is “0”, since the virtual CPU is in the normal operation mode, the process proceeds to S15 as described above, and the host VMM 10 executes the existing virtual machine processing.

  In S3, the CPU control unit 12 of the host VMM 10 refers to the operation mode flag 143 of the operation target virtual CPU, and determines whether the operation mode of the virtual CPU is the VMX root mode or the VMX non-root mode. When the operation mode flag 143 is “0”, it is determined that the virtual CPU is in the VMX root mode, and the process proceeds to S4. On the other hand, when the operation mode flag 143 is “1”, it is determined that the virtual CPU is in the VMX non-root mode, and the process proceeds to S11.

  In S <b> 4, the CPU control unit 12 identifies the cause of occurrence of the VM-exit received from the physical CPU 104. In this example, since the operation mode of the virtual CPU is the VMX root mode, the CPU control unit 12 refers to the guest state area 131 in which the state (status) of the guest VMM 20 is stored, and the VM-entry instruction issued by the guest VMM 20 Is specified as a factor of VM-exit.

  Next, in S5, the CPU control unit 12 executes a VM-entry instruction execution module from the emulator 122, and performs predetermined processing (switching of the state area selection unit 121) necessary for switching the operation target virtual CPU to the VMX non-root mode. And the like are emulated on behalf of the guest VMM 20.

  Next, in S6, since the CPU control unit 12 of the host VMM 10 shifts the operation mode of the virtual CPU from the VMX root mode to the VMX non-root mode, the operation mode flag 143 of the operation target virtual CPU is updated to “1”. . In S7, the CPU control unit 12 reads the status of the guest OS or application stored in the guest status area 221 from the virtual CPU control data 21 of the guest VMM 20 to be operated.

  Next, in S <b> 8, the CPU control unit 12 issues a VMPTLDR instruction to the physical CPU 104, sets the shadow VMCB corresponding to the virtual CPU to be operated to active, and sets the address of the activated shadow VMCB as a pointer 115. Set to. In response to this VMMPTLDR instruction (second control instruction), the host VMM 10 selects the shadow VMCB of the virtual CPU (virtual server) to be operated from among the plurality of shadow VMCBs # 0 to # n-1.

  In S9, the CPU control unit 12 updates the guest status area 131 of the shadow VMCB # 0 to be operated with the information of the guest status area 221 read in S7. In step S <b> 10, the CPU control unit 12 issues a VM-entry instruction to the physical CPU 104.

  The physical CPU 104 that has received the VM-entry command executes the user program (guest OS or application) of the operation target virtual server based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115. When receiving the VM-entry instruction, the physical CPU 104 stores the status of the host VMM 10 that has been executed in the host status area 132 of the shadow VMCB and prepares for the next call.

  On the other hand, when the operation mode flag 143 is determined to be “1” in S3, since the operation target virtual CPU is in the VMX non-root mode in which the user program is being executed, the process of S11 is performed.

  In S <b> 11, the CPU control unit 12 refers to the VM-exit factor list in FIG. 4 and searches for a VM-exit notification condition from the notification condition 1363 to the guest VMM. In this example, since it is a VM-entry instruction (VMLAUNCH, VMRESUME instruction) that causes the VM-exit, it matches the VM-exit notification condition.

  Then, the CPU control unit 12 executes the VM-exit condition detection module of FIG. 2 in S12, and performs predetermined processing (such as activation of the state area selection unit 121) necessary for switching the operation target virtual CPU to the VMX root mode. ) On behalf of the user program.

  Next, in S13, the CPU control unit 12 resets the operation mode flag 143 of the operation target virtual CPU to “0” in order to shift the operation mode of the operation target virtual CPU from the VMX non-root mode to the VMX root mode. . In S14, the CPU control unit 12 reads the status of the guest VMM 20 stored in the host status area 221 from the virtual CPU control data 21 of the guest VMM 20 to be operated.

  When the processing of S14 is completed, S8 to S10 are executed, and the CPU control unit 12 updates the guest status area 131 of the shadow VMCB to be operated with the information of the host status area 222 read in S14, and the guest VMM 20 After setting the status, a VM-entry instruction is issued to the physical CPU 104.

  As a result, the physical CPU 104 that has received the VM-entry command executes the guest VMM 20 of the operation target virtual server based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115.

  As described above, when the guest OS is a next-generation OS in which the virtualization function is integrated, the host VMM 10 writes in the guest status area 131 of the shadow VMCB according to the operation mode of the virtual CPU and the generated VM-exit factor. The status is selected from either the guest VMM or the user program. When the host VMM 10 issues a VM-entry instruction to the physical CPU 104 (first virtual CPU), the host VMM 10 operates on the guest VMM on the virtual server and on the second virtual CPU provided by the guest VMM. User programs can be switched and executed, and the guest VMM can provide a plurality of virtual environments (user programs) on the virtual server.

  When the guest OS does not use the virtualization function in the determination of S1 or when the virtual CPU does not use the VT-x function of the physical CPU 104 in the determination of S2, the conventional example is shown in S15. Virtual machine processing according to the description in Patent Document 1 or Non-Patent Document 1 may be performed by the host VMM 10.

  In the virtual machine process of S15, for example, the guest OS 111n of the virtual server 102n shown in FIG. 1 is an existing OS, and this guest OS 111n or application 112n (user program 110n) executes a predetermined command such as a privileged command. As described above, the physical CPU 104 notifies the host VMM 10 of the occurrence of the VM-exit.

  When receiving the VM-exit notification from the physical CPU 104, the host VMM 10 stores the status of the user program 110n (virtual CPU 108n) in the guest state area 131 of the shadow VMCB # n-1. Then, the host VMM 10 sets the address of the pointer 115 in the host state area in which the status of the host VMM 10 is stored, and executes predetermined processing.

  When a predetermined process such as a privileged instruction is completed, the host VMM 10 stores the status of the host VMM 10 in the host state area 132, sets the guest state area 131 to the address of the pointer 115, and then a VM-entry instruction (VMRESUME instruction) To transfer control to the virtual CPU 108n and resume execution of the user program 110n.

  As described above, according to the present invention, it is possible to integrate a next-generation OS that integrates virtualization functions and an existing OS into one physical server 101, and reduce the number of physical servers. Operation management costs can be reduced.

  Further, as described above, the host VMM 10 can make the virtual CPU provide the VT-x function to the next-generation OS, and can reliably operate the OS integrated with the virtualization software. . In addition, according to the host VMM 10 of the present invention, unlike the conventional simulator, there is no overhead such as instruction sequence conversion, and an OS that integrates the virtualization function without reducing the performance of the virtual machine is virtual server. It is possible to execute with.

  In the present invention, since a plurality of shadow VMCBs # 0 to # n−1 are provided corresponding to the plurality of virtual CPUs 108a to 108n, even when a plurality of guest VMMs 20 are executed on the physical server 101, the shadow VMCB # It is possible to switch processing quickly by simply switching from 0 to # n-1. Thereby, even when a plurality of next-generation OSs are integrated into the physical server 101, the performance of the virtual server can be maintained.

  FIG. 6 is a flowchart illustrating an example of processing performed by the CPU control unit 12 of the host VMM 10 when receiving a VM-exit from the physical CPU 104 due to execution of the VMCLEAR instruction while the virtual server is operating.

  S21 to S23 are the same as S1 to S3 in FIG. 5 described above, and the CPU controller 12 of the host VMM 10 can use the VT-x function by the operation target guest OS that causes the VM-exit. It is determined whether or not the operation target virtual CPU is using the VT-x function with reference to the VMXON flag 142 of the operation target virtual CPU. When the guest OS to be operated does not use the VT-x function or when the virtual CPU whose VMXON flag 142 is “0” is in the normal operation mode, the process proceeds to S35, and the host VMM 10 executes the existing virtual machine processing. To do.

  Further, the CPU control unit 12 refers to the operation mode flag 143 of the operation target virtual CPU to determine whether the operation mode of the virtual CPU is the VMX root mode or the VMX non-root mode. If it is VMX non-root mode, the process proceeds to S30.

  In S <b> 24, the CPU control unit 12 identifies a factor from the VM-exit received from the physical CPU 104. In this example, the CPU control unit 12 refers to the guest state area 131 and specifies the VMCLEAR instruction of the guest VMM 20 as the cause of the VM-exit.

  In step S25, emulation is performed by activating the VMCLEAR instruction execution module from the emulator 122 of the CPU control unit 12. In S26, the operation state (status) of the physical CPU 104 is read by emulation, and the shadow VMCB corresponding to the operation target virtual CPU is updated. As a result, the status of the physical CPU 104 is reflected in the shadow VMCB.

  In S27, the CPU control unit 12 reads the status stored in the guest state area 131 of the shadow VMCB corresponding to the virtual CPU to be operated.

  Next, in S28, the CPU control unit 12 writes the status read from the guest status area 131 of the shadow VMCB into the guest status area 221 of the guest VMM 20 and updates it. As a result, the guest state area 221 of the guest VMM 20 is synchronized with the status of the physical CPU 104.

  In S <b> 29, the CPU control unit 12 sets the address of the pointer 115 in the guest state area 131 of the shadow VMCB corresponding to the operation target virtual CPU, and then issues a VM-entry instruction to the physical CPU 104.

  The physical CPU 104 that has received the VM-entry command executes the user program (guest OS or application) of the operation target virtual server based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115.

  On the other hand, if the operation mode flag 143 is determined to be “1” in S23, the operation target virtual CPU is in the VMX non-root mode, so the process of S30 is performed. In S30, the VM-exit factor list in FIG. 4 is referenced to analyze the VM-exit factor. The CPU control unit 12 searches for a VM-exit notification condition from the notification condition 1363 to the guest VMM. In this example, the VMCLEAR instruction that caused the VM-exit matches the VM-exit notification condition.

  In S31, the CPU control unit 12 notifies the guest VMM 20 of an unspecified instruction error. That is, it notifies the guest VMM 20 that the VMCLEAR instruction could not be executed with the authority of the user program.

  Next, in S32, the CPU control unit 12 shifts the operation mode of the operation target virtual CPU from the VMX non-root mode to the VMX root mode, so the operation mode flag 143 of the operation target virtual CPU is reset to “0”. .

  In S33, the CPU control unit 12 reads the status of the guest VMM 20 stored in the host state area 221 from the virtual CPU control data 21 of the guest VMM 20 to be operated.

  In S34, the CPU control unit 12 writes the status of the host status area 222 read in S33 to the guest status area 131 of the shadow VMCB to be operated and updates the shadow VMCB. Thereafter, in S <b> 29, the CPU control unit 12 sets the address of the pointer 115 in the guest state area 131 and then issues a VM-entry instruction to the physical CPU 104.

  As a result, the physical CPU 104 that has received the VM-entry command executes the guest VMM 20 of the operation target virtual server based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115.

  If the guest OS does not use the virtualization function in the determination in S21 or if the virtual CPU does not use the VT-x function of the physical CPU 104 in the determination in S22, in S35, S15 in FIG. Similarly, the virtual machine processing according to the description of Patent Document 1 or Non-Patent Document 1 shown in the conventional example may be performed by the host VMM 10.

  As described above, when the guest VMM 20 issues the VMCLEAR instruction, the host VMM 10 acquires the operation state (status) of the physical CPU 104 and updates the guest state area 131 of the shadow VMCB with the acquired operation state. Then, the host VMM 10 reflects the status of the guest status area 131 of the shadow VMCB in the guest status area 221 of the guest VMCB, so that the status of the physical CPU 104, the guest status area 131 of the host VMM 10 and the guest status area on the guest VMM 20 The status of 221 can be synchronized.

  As a result, the next-generation OS that integrates the virtualization function can smoothly provide a virtual environment on the virtual server.

  FIG. 7 illustrates an example of processing performed by the CPU control unit 12 of the host VMM 10 when a VM-exit is received from the physical CPU 104 due to execution of a CPUID command (third control command) during operation of the virtual server. It is a flowchart to show.

  First, in S41, as in S3 of FIG. 5, the CPU control unit 12 of the host VMM 10 refers to the operation mode flag 143 of the operation target virtual CPU that causes the VM-exit, and the operation mode of the virtual CPU is set. It is determined whether the VMX root mode or the VMX non-root mode. When the operation mode flag 143 is “0”, it is determined that the virtual CPU is in the VMX root mode, and the process proceeds to S42. On the other hand, when the operation mode flag 143 is “1”, it is determined that the virtual CPU is in the VMX non-root mode, and the process proceeds to S41.

  In S <b> 42, as in S <b> 4 of FIG. 5, the CPU control unit 12 identifies the occurrence factor of the VM-exit received from the physical CPU 104 from the value in the guest state area 131. In this example, since it is the VMX root mode, the CPU control unit 12 specifies the CPUID command of the guest VMM 20 as a cause of occurrence of VM-exit.

  In S43, as in S1 of FIG. 5, the CPU control unit 12 refers to the virtualization function enable flag 141 of the host VMM holding data 11 corresponding to the operation target guest OS that has caused the VM-exit, and then executes the VM. -It is determined whether or not the guest OS that generated the exit can use the VT-x function. When the guest OS to be operated can use the VT-x function, the process proceeds to S44. On the other hand, if the guest OS to be operated does not use the VT-x function, the process proceeds to S45.

  In S44, a predetermined bit (CPUID.1.ECX [5] = 1) of the return register (ECX in the case of IA-32) indicating the return value of the CPUID instruction is set to 1, and the VT-x function is enabled. Set that there is.

  On the other hand, in S45, a predetermined bit of the return register (ECX in the case of IA-32) indicating the return value of the CPUID instruction is set to 0 to set that the VT-x function is invalid.

  Next, in S46, the CPU control unit 12 activates the CPUID instruction execution module from the emulator 122, checks for exceptions to be notified to the guest VMM 20 or the user program, and stores the check result in the guest status area 131.

  In S <b> 47, the CPU control unit 12 issues a VM-entry command to the physical CPU 104 and transfers control to the virtual server.

  On the other hand, if it is determined in S41 that the user program whose operation mode flag 143 is “1” is being executed (VMX non-root mode), the process proceeds to S48, and the VM− during the user program is being executed. Analyze the cause of exit. In S <b> 48, the CPU control unit 12 specifies the generation factor of the VM-exit received from the physical CPU 104 from the value in the guest state area 131. In this example, since it is a VMX non-root mode, the CPU control unit 12 specifies the CPUID command of the guest OS or application as a cause of occurrence of VM-exit.

  In S49, the CPU control unit 12 determines whether or not notification to the guest VMM 20 is necessary for the VM-exit caused by the CPUID command during execution of the user program. This determination is performed by the CPU control unit 12 referring to information preset in the VM execution control area 223 of the guest VMCB 22 in the virtual CPU control data 21. If it is necessary to notify the guest VMM 20 of the VM-exit accompanying the CPUID command, the process proceeds to S50. On the other hand, if the notification of the VM-exit to the guest VMM 20 is unnecessary, the process proceeds to S43, and the above-described processing of S43 migration is executed.

  In S50, in order to notify the VMM 20 of the VM-exit, the CPU control unit 12 executes the VM-exit emulator, and in S51, resets the operation mode flag 143 of the operation target virtual CPU to “0” and the VMX route. Switch to mode.

  Next, in S52, the CPU control unit 12 reads the status of the host status area 222 of the guest VMCB 22 to be operated. In S53, the CPU control unit 12 writes and updates the read status in the guest status area 131 of the shadow VMCB of the virtual CPU to be operated. Thereafter, in S47, the CPU control unit 12 issues a VM-entry instruction to the physical CPU 104 to transfer control to the guest VMM 20.

  As described above, when the guest VMM 20 issues the CPUID instruction and when the VM-exit resulting from the CPUID instruction is not notified to the guest VMM 20, the value of the return register is set according to the setting of the virtualization function enable flag 141. After that, the CPU control unit 12 can issue a VM-entry instruction to return control to the guest VMM 20 or the user program. When the user program issues a CPUID command and the VM-exit needs to be notified to the guest VMM 20, the guest status area 131 of the shadow VMCB is updated with the contents of the host status area 222 of the guest VMCB 22, and control is performed. It can be transferred to the guest VMM 20.

  As described above, according to the first embodiment, the host VMM 10 monitors the guest OS or application state and the virtual CPU state and rewrites the guest state area 131 of the shadow VMCB, thereby reducing the performance of the virtual server. Therefore, it is possible to reliably operate an OS integrated with virtualization software. Then, it becomes possible to coexist with the existing OS and the next generation OS that integrates the virtualization function in one physical server 101, and server operation costs can be reduced by efficiently performing server integration. It becomes possible.

  Note that the user interface provided by the host VMM 10 to the management console 300 is configured with a GUI as shown in FIG. 8, for example. FIG. 8 shows a user interface for setting whether to enable or disable the virtualization function for each virtual server. In the figure, “VM #” indicates the identifier of the virtual server, “current setting” indicates that the virtualization function is valid if “ON”, and the virtualization function is invalid if “OFF”. Indicates. Then, by setting “ON” or “OFF” in “New setting” and clicking “OK” in the lower left of the screen, the virtualization function can be enabled or disabled for a desired virtual server. That is, the host VMM 10 sets “1” or “0” in the virtualization function enable flag 141 of the corresponding virtual server in the host VMM holding data 11 based on the value of “new setting” input from the user interface 301. Set. Thereby, the setting value input from the user interface 301 can be reflected on an arbitrary virtual server.

Second Embodiment
FIG. 9 shows the second embodiment, in which the VT-x function of the physical CPU 104 shown in the first embodiment is replaced with AMD-V (Virtualization) shown in the conventional example (Non-Patent Document 2). Is.

  In FIG. 9, the physical CPU 104a on which AMD-V is mounted includes a pointer 118 that points to the address of the host status area 132 in addition to the pointer 115 that points to the address of the shadow VMCB of the host VMM 10 described in the first embodiment.

  When executing the VMRUN instruction instead of the VM-entry instruction, the physical CPU 104a provided with AMD-V switches from the host mode in which the host VMM 10 is executed to the guest VMM 20 or the guest mode in which the user program is executed. The host VMM 10 is different from the VT-x function of the first embodiment in the following points according to the AMD-V specification.

  The VMXON flag 142 of the first embodiment is deleted from the host VMM retained data 11, and a virtual function valid flag 141 for each virtual server and an operation mode flag 143 for each virtual CPU 108a-n are provided. As shown in FIG. 10, the physical CPU control data of the host VMM holding data 11 includes the guest status area 131 in the host status area 132 for each virtual CPU and the shadow VMCBs # 0 to # n−1 for each virtual CPU. And a control area 137. Note that the control areas 137 of the shadow VMCBs # 0 to # n−1 store information corresponding to the VM-exit information area 136 of the first embodiment.

  That is, in the control area 137, as shown in FIG. 11, EXITCODE 1371 indicating the code of the occurrence factor of preset #VMEXIT (corresponding to the VM-exit of the first embodiment), the code name 1372, A determination result 1373 indicating that this code is caused by the VMRUN instruction, and a notification condition 1374 indicating that #VMEXIT is notified to the guest VMM 20 are included.

  The emulator 122 of the CPU control unit 12 includes a VMRUN instruction execution module instead of the VM-entry instruction, and deletes the VMCLEAR instruction execution module. In addition, the CPU control unit 12 includes a VMRUN instruction issuing unit 125A that issues a VMRUN instruction to the physical CPU 104 in place of the VM-entry instruction issuing unit of the first embodiment.

  Next, the virtual CPUs 108a to 108n provided by the host VMM 10 to the virtual servers 102a to 102n also receive the host status in addition to the pointer 116 indicating the address of the guest status area 221 in the guest VMM 20 in accordance with the change in the configuration of the physical CPU 104a. A pointer 117 indicating the address of the area 222 is provided. Note that the guest VMM 20 operates on the virtual server 102a when the next-generation OS that integrates the virtualization function is adopted as the guest OS 111a, as in the virtual server 102a of the first embodiment.

  The virtual CPU control data 21 of the guest VMM 20 stores a host status area 222 that holds the status of the guest VMM 20 according to the specifications of the AMD-V and the status of the user program, similarly to the host VMM holding data 11 of the host VMM 10. The guest VMCB 22 includes a guest state area 221 and a control area 226.

  With the configuration described above, when the host VMM 10 receives #VMEXIT from the physical CPU 104a, the contents of the guest state area 221 or the host state area 222 of the guest VMM 20 are added to the guest state area 131 of the shadow VMCBs # 0 to # n-1. Can be switched between the guest VMM 20 integrated in the next-generation OS running on the virtual server 102a and the user program running on the guest VMM 20.

  Next, processing performed in the host VMM 10 will be described below with reference to FIG. FIG. 12 is a flowchart illustrating an example of processing performed by the CPU control unit 12 of the host VMM 10 when #VMEXIT is received from the physical CPU 104a while the virtual server 102a is operating. This example shows a case where the cause of #VMEXIT is a VMRUN instruction.

  First, in S61, the CPU control unit 12 of the host VMM 10 sets the virtualization function valid flag 141 of the host VMM holding data 11 corresponding to the operation target guest OS 111a (hereinafter referred to as a guest OS) that has caused #VMEXIT. It is determined whether or not the guest OS that has generated #VMEXIT can use the AMD-V function. If the virtualization function enable flag 141 is “1”, it is determined that the guest OS to be operated can use the AMD-V function, and the process proceeds to S62. On the other hand, if the virtualization function enable flag 141 is “0”, it is determined that the guest OS to be operated does not use the AMD-V function, and the process proceeds to S73. In S73, as in S15 shown in FIG. 5 of the first embodiment, the host VMM 10 performs the virtual machine processing shown in the conventional example.

  In S62, the CPU control unit 12 of the host VMM 10 refers to the operation mode flag 143 of the virtual CPU to be operated, and the operation mode of the virtual CPU is the host mode (the VMX root mode of the first embodiment) and the guest mode (the above-mentioned The VMMX non-root mode of the first embodiment is determined. When the operation mode flag 143 is “0”, it is determined that the virtual CPU is in the host mode, and the process proceeds to S63. On the other hand, when the operation mode flag 143 is “1”, it is determined that the virtual CPU is in the guest mode, and the process proceeds to S69.

  In S63, the CPU control unit 12 identifies the cause of occurrence of #VMEXIT received from the physical CPU 104a. In this example, since it is the host mode, the CPU control unit 12 refers to the guest state area 131 storing the state (status) of the guest VMM 20 and identifies the VMRUN instruction issued by the guest VMM 20 as the factor of #VMEXIT.

  Next, in S64, the VMRUN instruction execution module is executed from the emulator 122 of the CPU control unit 12, and predetermined processing (such as activation of the state area selection unit 121) necessary for switching the virtual CPU to be operated to the guest mode is performed on the guest. Emulate on behalf of VMM20.

  Next, in S65, since the CPU control unit 12 of the host VMM 10 shifts the operation mode of the virtual CPU from the host mode to the guest mode, the operation mode flag 143 of the operation target virtual CPU is updated to “1”.

  In S66, the CPU control unit 12 reads the status of the user program (guest OS or application) stored in the guest status area 221 from the guest VMCB 22 of the guest VMM 20 to be operated.

  In S67, the CPU control unit 12 updates the guest status area 131 of the operation target shadow VMCB # 0 with the information of the guest status area 221 read in S66. In step S68, the CPU control unit 12 issues a VMRUN command to the physical CPU 104a (virtual CPU 108a to be operated).

  The physical CPU 104a that has received the VMRUN command executes the user program (guest OS or application) of the virtual server to be operated based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115. When the physical CPU 104a receives the VMRUN command, the physical CPU 104a stores the status of the host VMM 10 in the host status area 132 of the host VMM holding data 11 and prepares for the next call.

  On the other hand, in the guest mode in which the operation mode flag 143 is determined to be “1” in S62, the operation target virtual CPU is executing the user program, so the process of S69 is performed. In S69, the CPU control unit 12 acquires EXITCODE, refers to the #VMEXIT factor list shown in FIG. 11, and the user program is being executed on the operation target virtual server, so the notification condition 1374 to the guest VMM Search for #VMEXIT notification condition. In this example, the VMRUN instruction with the cause of #VMEXIT matches the #VMEXIT notification condition. In S70, the CPU control unit 12 executes the #VMEXIT condition detection module in FIG. 9 from the emulator 122, and performs predetermined processing (such as activation of the state area selection unit 121) required to switch the virtual CPU to be operated to the host mode. ) On behalf of the user program.

  Next, in S71, the CPU control unit 12 shifts the operation mode of the operation target virtual CPU from the guest mode to the host mode, so the operation mode flag 143 of the operation target virtual CPU is reset to “0”.

  In S <b> 72, the CPU control unit 12 reads the status of the guest VMM 20 stored in the host status area 221 of the virtual CPU control data 21 from the operation target guest VMM 20.

  When the processing of S72 is completed, S67 to S68 are executed, and the CPU control unit 12 updates the guest status area 131 of the shadow VMCB to be operated with the information of the host status area 222 read in S72, and the physical CPU 104a ( A VMRUN command is issued to the virtual CPU 108a to be operated. As a result, the physical CPU 104a that has received the VMRUN command executes the guest VMM 20 of the virtual server to be operated based on the contents of the guest status area 131 of the shadow VMCB designated by the pointer 115.

  As described above, when the guest OS running on the virtual server is a next-generation OS integrated with a virtualization function, the host VMM 10 determines the guest state of the shadow VMCB according to the operation mode of the virtual CPU and the generated #VMEXIT factor. The status to be written in the area 131 is selected from either the guest VMM or the user program. When the host VMM 10 issues a VMRUN instruction to the physical CPU 104a, it operates on the guest VMM operating on the first virtual CPU on the virtual server and on the second virtual CPU provided by the guest VMM. The user program can be switched and executed, and the guest VMM can provide a virtual environment on the virtual server.

  If the guest OS does not use the virtualization function in the determination of S61, the virtual machine processing according to the description in Patent Document 1 or Non-Patent Document 1 shown in the conventional example is performed in the host VMM 10 in S15. Good.

  In the virtual machine processing in S73, for example, the guest OS 111n of the virtual server 102n illustrated in FIG. 1 is an existing OS, and when the guest OS 111n or the application 112n (user program 110n) executes a predetermined command such as a privileged command, As described above, the physical CPU 104a notifies the host VMM 10 of the occurrence of #VMEXIT.

  Upon receiving the #VMEXIT notification from the physical CPU 104a, the host VMM 10 stores the status of the user program 110n (virtual CPU 108n) in the guest status area 131 of the shadow VMCB # n-1.

  When a predetermined process such as a privileged instruction is completed, the host VMM 10 stores the status of the host VMM 10 in the host state area 132, sets the guest state area 131 to the address of the pointer 115, and then issues a VMRUN instruction to control To the virtual CPU 108n to resume execution of the user program 110n.

  As described above, according to the second embodiment, similarly to the first embodiment, it is possible to run the next-generation OS that integrates the virtualization function on the host VMM 10. In addition, it is possible to integrate a next-generation OS that integrates virtualization functions and an existing OS into one physical server 101, thereby reducing the number of physical servers and reducing server operation management costs. It becomes possible.

  Further, as described above, the host VMM 10 can appear to the guest VMM running on the first virtual CPU that the first virtual CPU provides the AMD-V function, and the virtualization software is integrated. The OS can be reliably operated. In addition, according to the host VMM 10 of the present invention, unlike the conventional simulator, there is no overhead such as instruction sequence conversion, and an OS that integrates the virtualization function without reducing the performance of the virtual machine is virtual server. It is possible to execute with.

<Third Embodiment>
FIG. 13 shows the third embodiment, and the virtualization support function of the physical CPU 104 shown in the first embodiment is changed from the VT-x function to the IPF (Itanium Processor) shown in the conventional example (Non-Patent Document 3). (Family) VT-i function.

  In FIG. 13, in the physical CPU 104b in which the VT-i function is implemented, if there is a preset command or event during execution of the guest (guest VMM 20 or user program 110a), a virtualization exception is generated and the host VMM 10 Transfer control to. When the host VMM 10 detects a virtualization exception, it executes (emulates) a preset virtualization procedure (such as PAL_VPS_RESUME procedure) and updates a shadow VPD (Virtual Processor Descriptor) for controlling the virtual CPUs 108a to 08n. Issues a virtualization procedure (PAL_VPS_RESUME procedure) to the physical CPU 104b to transfer control to the guest. Note that the PAL_VPS_RESUME procedure is a generic term for a PAL_VPS_RESUME_NORMAL procedure call or a PAL_VPS_RESUME_HANDLER procedure call.

  That is, the physical CPU 104b generates a virtualization exception in place of the VM-exit of the first embodiment, and executes a virtualization procedure in place of the VM-entry instruction, thereby switching the control between the host VMM 10 and the guest. It is. Details are detailed in Non-Patent Document 3, and a detailed description of this architecture is omitted.

  The host VMM holding data 11 of the host VMM 10 includes a virtual CPU control including an architecture state 151 for storing the status of the virtual CPUs 108a to 108n in addition to the virtualization function valid flag 141 and the operation mode flag 143 similar to those in the first embodiment. Data B150 is provided.

  The physical CPU control data 13 stores the following information according to the specification of the VT-i function. In the physical CPU control data 13, the shadow VPDs # 0 to # n-1 including the architecture state 1310 for storing the status of each of the virtual CPUs 108a to 108n and the suppression of the occurrence of the virtualization exception are set for each of the virtual CPUs 108a to 108n. VDC (Virtualization Disable Control) areas # 0 to # n-1 (1320) and virtualization that predefines instructions or events that cause a virtualization exception in the physical CPU 104b among instructions or events executed by the virtual CPUs 108a to 108n An exception factor 1330.

  The architecture state stored in the host VMM holding data 11 is as shown in FIG. That is, the status of the guest (guest VMM 20 or user program) executed by the virtual CPUs 108a to 108n is stored in the architectural state 151 of the virtual CPU control data B150, and the physical CPU 104b executes the architectural state 1310 of the shadow VPD. The status of the guest or host VMM 10 is stored.

  Further, the virtualization exception factor 1330 stored in the physical CPU control data 13 of the host VMM holding data 11 is set, for example, as shown in the virtualization exception factor list of FIG. In FIG. 15, the virtualization exception factor list includes a code 1331 indicating a factor of a virtualization exception, a virtualization exception content 1332 corresponding to the code, a call setting 1333 of a PAL_VPS_RESUME procedure for transferring control to a guest, This is composed of a virtualization exception notification setting 1334 to the guest VMM 20. The setting 1333 means that a PAL_VPS_RESUME procedure for transferring control to a guest is called when an instruction with “◯” in the figure is set. In addition, the notification setting 1334 means that notification is given to the guest VMM 20 when an instruction is set with “◯” in the figure, and the VDC area 2202 of the guest VMM 20 does not suppress the occurrence of a virtualization exception. Is notified to the guest VMM 20.

  The state of the virtual CPU 108a held by the guest VMM 20 is stored in the virtual CPU control data A210. The virtual CPU control data A210 defines a command or event that causes a virtualization exception in the virtual CPU 108a among the commands or events executed by the guest OS or application and the guest VPD 220 including the architecture state 2210 for storing the status of the virtual CPU 108a. Virtualization exception factor 2201 and a VDC region 2202 indicating whether or not the virtual CPU 108a executing the guest VMM 20 uses the VT-i function.

  The CPU control unit 12 detects a virtualization exception from the physical CPU 104b, and executes a virtualization exception handler 1240 that notifies the emulator 122 and a process that has become a virtualization exception in the PAL (Processor Abstraction Layer) provided by the physical CPU 104b. The state area selection unit 121 for selecting either the architecture state 2210 of the guest VPD or the architecture state 151 of the virtual CPU control data B150 of the host VMM holding data 11 based on the operating state of the emulator 122 and the virtual CPU 108a It operates on the guest VMM 20 from the host VMM 10 or the second virtual CPU 208a on the guest VMM 20 from the host VMM 10 and updates the shadow VPD architecture state 1310 with the information selected by the area selector 121. To switch the control to the chromatography The program includes a virtualization procedure instruction unit 1250 instructs the execution of a predetermined procedure to the physical CPU 104b, a.

  Next, an example of processing performed by the CPU control unit 12 of the host VMM 10 will be described below with reference to the flowchart of FIG. In the following description, an example in which the guest OS 111a, the application 112a, and the guest VMM 20 of the next generation OS are operating on the virtual server 102a illustrated in FIG. 1 of the first embodiment will be described.

  FIG. 16 is a flowchart illustrating an example of processing performed by the CPU control unit 12 of the host VMM 10 when a virtualization exception is received from the physical CPU 104b during operation of the virtual server 102a. This example shows a case where the cause of the virtualization exception is a vmsw instruction from the PAL_VPS_RESUME procedure.

  First, in S81, the CPU control unit 12 of the host VMM 10 causes the virtualization function valid flag 141 of the host VMM holding data 11 corresponding to the operation target guest OS 111a (hereinafter referred to as the guest OS) that has caused the virtualization exception. The guest OS that has generated the virtualization exception determines whether the VT-i function can be used. If the virtualization function valid flag 141 is “1”, it is determined that the operation target guest OS can use the VT-i function, and the process proceeds to S82. On the other hand, if the virtualization function enable flag 141 is “0”, it is determined that the guest OS to be operated does not use the VT-i function, and the process proceeds to S94. In S94, the host VMM 10 performs virtual machine processing using the VT-i function shown in Non-Patent Document 3 of the conventional example.

  In S82, the CPU control unit 12 of the host VMM 10 refers to the operation mode flag 143 of the virtual CPU to be operated, and the operation mode of the virtual CPU is the host mode (the VMX root mode of the first embodiment) and the guest mode (the above-mentioned The VMMX non-root mode of the first embodiment is determined. When the operation mode flag 143 is “0”, it is determined that the virtual CPU is in the host mode for executing the guest VMM 20, and the process proceeds to S83. On the other hand, when the operation mode flag 143 is “1”, it is determined that the virtual CPU is in the guest mode for executing the user program, and the process proceeds to S90.

  In S83, the CPU control unit 12 specifies the cause of occurrence of the virtualization exception received from the physical CPU 104b. In this example, since the host mode is set, the CPU control unit 12 refers to the architecture state 151 of the virtual CPU control data B150 in the host VMM holding data 11 storing the state (status) of the guest VMM 20, and the guest VMM 20 is PAL_VPS_RESUME. The vmsw instruction issued from the procedure is specified as the cause of the virtualization exception.

  Next, in S84, the CPU control unit 12 executes the PAL_VPS_RESUME procedure module that caused the virtualization exception, executes predetermined processing on behalf of the guest VMM 20, and switches the operation target virtual CPU to the guest mode. Necessary predetermined processing (such as activation of the state area selection unit 121) is executed.

  Next, in S85, since the CPU control unit 12 shifts the operation mode of the virtual CPU from the host mode to the guest mode, the operation mode flag 143 of the operation target virtual CPU is updated to “1”.

  In S86, the CPU control unit 12 reads the status of the user program (guest OS or application) stored in the architecture state 2210 from the guest VPD 220 in the virtual CPU control data A210 of the guest VMM 20 to be operated.

  In S87, the CPU control unit 12 issues a PAL_VPS_SAVE / RESTORE procedure to the physical CPU 104b, and selects the shadow VPD # 0 that has caused the virtualization exception.

  Next, in S88, the CPU control unit 12 writes and updates the status of the architecture state 2210 read in S86 in the architecture state 1310 of the operation target shadow VPD # 0 selected in S87. In step S88, the CPU control unit 12 issues a PAL_VPS_RESUME procedure to the physical CPU 104b.

  The physical CPU 104b that has received the PAL_VPS_RESUME procedure executes the user program (guest OS or application) of the operation target virtual server based on the contents of the architecture state 1310 of the shadow VPD selected in S87.

  On the other hand, in the guest mode in which the operation mode flag 143 is determined to be “1” in S82, the operation target virtual CPU is executing the user program, so the process of S90 is performed. In S90, the CPU control unit 12 acquires a virtualization exception factor, refers to the virtualization exception factor list shown in FIG. 15, and searches for a virtualization exception notification condition from the notification condition 1334 to the guest VMM. In this example, since the cause of the virtualization exception is the vmsw instruction, the virtualization exception notification condition depends on the setting of the VDC area 2202 of the guest VMM 20. Here, it is handled as a notification of the virtualization exception to the guest VMM 20. In S91, the virtualization exception condition detection module shown in FIG. 13 is executed, and predetermined processing (such as activation of the state area selection unit 121) necessary for switching the operation target virtual CPU to the host mode is performed on behalf of the guest VMM 20. Emulate.

  Next, in S92, the CPU control unit 12 shifts the operation mode of the operation target virtual CPU from the guest mode to the host mode, so the operation mode flag 143 of the operation target virtual CPU is reset to “0”.

  In S93, the CPU control unit 12 reads the status of the guest VMM 20 stored in the architecture state 151 of the virtual CPU control data B150 corresponding to the operation target virtual CPU in the host VMM holding data 11.

  When the processing of S93 is completed, S87 to S89 are executed, and the CPU control unit 12 uses the information of the architecture state 151 of the virtual CPU control data B150 of the host VMM holding data 11 read in S93 to determine the shadow VPD to be operated. The architecture state 1310 is updated, and a PAL_VPS_RESUME procedure is issued to the physical CPU 104b. As a result, the physical CPU 104b that has received the PAL_VPS_RESUME procedure executes the guest VMM 20 of the operation target virtual server based on the contents of the architecture state 1310 of the shadow VPD # 0.

  As described above, when the guest OS running on the virtual server is a next-generation OS that integrates the virtualization function, the host VMM 10 determines the shadow VPD according to the operation mode of the virtual CPU and the cause of the generated virtualization exception. The status to be written in the architecture state 1310 is selected from either the guest VMM or the user program. When the host VMM 10 issues a PAL_VPS_RESUME procedure to the physical CPU 104b, the guest VMM on the virtual server and the user program running on the second virtual CPU 208a provided by the guest VMM can be switched and executed. The guest VMM can provide a virtual environment on the virtual server.

  If the guest OS does not use the virtualization function in the determination of S81, the virtual machine process according to the description in Patent Document 1 or Non-Patent Document 3 shown in the conventional example is performed in the host VMM 10 in S94. Good.

  In the virtual machine processing in S94, for example, when the guest OS 111n of the virtual server 102n illustrated in FIG. 1 is an existing OS, and the guest OS 111n or the application 112n (user program 110n) executes a virtualization exception factor instruction, the virtual OS 102n illustrated in FIG. As described above, the physical CPU 104b notifies the host VMM 10 of the occurrence of the virtualization exception.

  Upon receiving the notification of the virtualization exception from the physical CPU 104b, the host VMM 10 stores the status of the user program 110n (virtual CPU 108n) in the architecture state 151 of the virtual CPU control data B150.

  After emulating the instruction that caused the virtualization exception, the host VMM 10 issues a PAL_VPS_RESUME procedure, transfers control to the virtual CPU 108n, and resumes execution of the user program 110n.

  As described above, according to the third embodiment, similarly to the first embodiment, it is possible to integrate a next-generation OS that integrates virtualization functions and an existing OS into one physical server 101. Thus, the number of physical servers can be reduced to reduce the server operation management cost.

  Further, as described above, the host VMM 10 can make the virtual CPU provide the VT-i function to the next-generation OS, and can reliably operate the OS integrated with the virtualization software. . In addition, according to the host VMM 10 of the present invention, unlike the conventional simulator, there is no overhead such as instruction sequence conversion, and an OS that integrates the virtualization function without reducing the performance of the virtual machine is virtual server. It is possible to execute with.

  In each of the above embodiments, the processors described as the physical CPUs 104, 104a, and 104b may have a multi-core processor configuration, and a homogeneous processor or a heterogeneous processor may be employed. That is, when a heterogeneous multi-core processor including a plurality of general-purpose processor cores (CPUs) and a special-purpose processor core is used as the physical CPUs 104, 104a, and 104b, the present invention can be used if the general-purpose processor core has a virtualization support function. Can be applied.

1.
In a virtualization program that is executed on a physical computer including a physical processor and a memory and provides a plurality of virtual processors,
The first virtual machine manager generating a first virtual processor;
A second virtual machine manager executing on the first virtual processor generating a second virtual processor;
A procedure in which the second virtual processor executes a user program;
The first virtual machine manager receiving a call to the first virtual machine manager from the physical processor;
A procedure in which the first virtual machine manager analyzes a factor of the first virtual machine manager call;
The first virtual machine manager determines whether to execute the second virtual machine manager or the user program based on the result of the analysis;
The first virtual machine manager causing the first virtual processor to execute one of the second virtual machine manager or the user program based on the result of the determination;
Is executed by the physical processor.

2.
A procedure in which the first virtual machine manager sets, in the memory, first control information that defines a state of a first virtual processor when the user program is executed;
A procedure in which the first virtual machine manager sets, in the memory, second control information that defines a state of the first virtual processor when the second virtual machine manager is executed;
A procedure in which the first virtual machine manager sets, in the memory, third control information that defines a state of the physical processor when the second virtual machine manager or the user program is executed;
Further including
The first virtual machine manager causes the first virtual processor to execute one of the second virtual machine manager or the user program based on a determination result.
A step of referring to the first control information when the first virtual machine manager causes the first virtual processor to start executing the user program;
A step of referring to the second control information when the first virtual machine manager causes the first virtual processor to start execution of the second virtual machine manager;
A procedure in which the first virtual machine manager updates the third control information on one of the referenced first control information or second control information;
A procedure in which the first virtual machine manager issues a first control instruction that instructs the physical processor to start executing an instruction according to the third control information;
The above-mentioned 1. is characterized by including The virtualization program described in.

3.
The physical processor is a processor conforming to the instruction set of Intel Architecture 32,
The procedure in which the first virtual machine manager determines which of the second virtual machine manager and the user program to execute based on the result of the analysis is as follows:
If the result of the call factor analysis is a VM-entry instruction issued from the second virtual machine manager, it is determined that the execution of the user program is started;
When the result of the call factor analysis notifies the second virtual machine manager of the VM-exit from the first virtual processor, it is determined that the execution of the second virtual machine manager is started. 2 above. The virtualization program described in.

4).
The physical processor is a processor conforming to the instruction set of AMD64,
The procedure in which the first virtual machine manager determines which of the second virtual machine manager and the user program to execute based on the result of the analysis is as follows:
When the result of the call factor analysis is a VMRUN instruction issued from the second virtual machine manager, it is determined that the execution of the user program is started,
When the result of the analysis of the call factor notifies #VMEXIT from the first virtual processor to the second virtual machine manager, it is determined that the execution of the second virtual machine manager is started. 2 above. The virtualization program described in.

5.
The physical processor is a processor conforming to the instruction set of the Itanium processor family,
The procedure in which the first virtual machine manager determines which of the second virtual machine manager and the user program to execute based on the result of the analysis is as follows:
If the result of the call factor analysis is an issuance of a PAL_VPS_RESUME_HANDLER procedure call from the second virtual machine manager, it is determined that the execution of the user program is started;
When the result of the analysis of the call factor notifies the second virtual machine manager of a virtualization exception from the first virtual processor, it is determined that the execution of the second virtual machine manager is started. 2 above. The virtualization program described in.

6).
The first virtual machine manager generates a first virtual processor by:
Including a step of generating a plurality of the first virtual processors,
The procedure for setting the third control information defining the state of the physical processor in the memory is as follows:
Including a procedure for setting the third control information in the memory for each of the first virtual processors,
The first virtual machine manager issues a first control instruction that instructs the physical processor to start executing an instruction according to the third control information.
2. A procedure for issuing a second control command for selecting one of the plurality of third control information. The virtualization program described in.

7).
The second virtual machine manager further includes a step of issuing a third control instruction for confirming whether or not the first virtual processor can accept the first control instruction.
The first virtual machine manager analyzes the cause of the first virtual machine manager call.
A step of referring to response availability information set in advance when the cause of the first virtual machine manager call is the third control command from the second virtual machine manager;
Determining a response to the third control command according to the response availability information;
The above-mentioned 2. characterized by including The virtualization program described in.

8).
A procedure in which the first virtual machine manager receives a setting request for the first virtual processor;
The first virtual machine manager sets the response availability information based on the setting request;
The above-mentioned 7. The virtualization program described in.

9.
The physical processor is a processor conforming to the instruction set of Intel Architecture 32,
6. The seventh control instruction is a CPUID instruction. The virtualization program described in.

10.
The second virtual machine manager receiving a response to the third control command from the first virtual machine manager;
The second virtual machine manager can accept the first control instruction to the first virtual processor when the first control instruction can be accepted by the first virtual processor. A procedure for issuing instructions to be set;
The above-mentioned 9. characterized by including The virtualization program described in.

11.
A procedure in which the first virtual machine manager sets, in the memory, first control information that defines a state of a first virtual processor when the user program is executed;
A procedure in which the first virtual machine manager sets, in the memory, second control information that defines a state of the first virtual processor when the second virtual machine manager is executed;
A procedure in which the first virtual machine manager sets, in the memory, third control information that defines a state of the physical processor when the second virtual machine manager or the user program is executed;
Further including
The procedure in which the first virtual machine manager determines which of the second virtual machine manager and the user program to execute based on the result of the analysis is as follows:
As a result of the analysis, a factor causing the first virtual machine manager to call a fourth control instruction reflecting the operation state of the first virtual processor with respect to the first control information from the second virtual machine manager. When
The first virtual machine manager issues a fourth control instruction for reflecting the operation state of the physical processor in the third control information to the physical processor;
The first virtual machine manager refers to the third control information reflecting the operating state of the physical processor;
The first virtual machine manager determines execution of the second virtual machine manager after updating the first control information based on the referenced third control information. 1. The virtualization program described in.

12
The physical processor is a processor conforming to the instruction set of Intel Architecture 32,
10. The fourth control instruction is a VMCLEAR instruction. The virtualization program described in.

13.
In a virtual computer system that provides a plurality of virtual processors on a physical computer having a physical processor and a memory,
A first virtual machine manager operating on the physical processor and providing a first virtual processor;
A second virtual machine manager that operates on the first virtual processor and provides a second virtual processor that executes a user program;
The second virtual machine manager is
First control information that defines the state of the first virtual processor when executing the user program, and second that defines the state of the first virtual processor when executing the second virtual machine manager Virtual processor control data for storing control information of
The first virtual machine manager is
Physical processor control data for storing, in the memory, third control information that defines a state of the physical processor when executing the second virtual machine manager or the user program;
A receiving unit for receiving a call to the first virtual machine manager from the physical processor;
Analyzing a factor of the first virtual machine manager invocation and determining which of the second virtual machine manager and the user program to execute;
A selection unit that selects one of the first control information and the second control information of the virtual processor control data based on the determination result;
An update unit for updating the third control information of the physical processor control data with the selected first control information or second control information;
An instruction issuing unit for issuing an instruction for causing the first virtual processor to execute one of the second virtual machine manager or the user program based on the third control information;
A virtual computer system characterized by comprising:

14
The physical processor is a processor conforming to the instruction set of Intel Architecture 32,
The determination unit
When the result of analyzing the call factor of the first virtual machine manager is the issue of a VM-entry instruction from the second virtual machine manager, it is determined that the execution of the user program is started,
Execution of the second virtual machine manager when the result of analyzing the call cause of the first virtual machine manager notifies the second virtual machine manager of the VM-exit from the first virtual processor 13. The above-described 13., characterized in that the start is determined. The virtual computer system described in 1.

15.
The physical processor is a processor conforming to the instruction set of AMD64,
The determination unit
If the result of analyzing the call factor of the first virtual machine manager is the issue of a VMRUN instruction from the second virtual machine manager, it is determined that the execution of the user program is started;
When the result of analyzing the call factor of the first virtual machine manager notifies #VMEXIT to the second virtual machine manager from the first virtual processor, execution of the second virtual machine manager starts. 13. It is determined that The virtual computer system described in 1.

16.
The physical processor is a processor conforming to the instruction set of the Itanium processor family,
The determination unit
If the result of analyzing the call factor of the first virtual machine manager is the issuance of a PAL_VPS_RESUME_HANDLER procedure call from the second virtual machine manager, it is determined that the execution of the user program is started,
Execution of the second virtual machine manager when the result of analyzing the call cause of the first virtual machine manager notifies the second virtual machine manager of a virtualization exception from the first virtual processor 13. The above-described 13., characterized in that the start is determined. The virtual computer system described in 1.

17.
In a virtualization program that is executed on a physical computer including a physical processor and a memory and provides a plurality of virtual processors,
The first virtual machine manager generating a first virtual processor;
A second virtual machine manager executing on the first virtual processor generating a second virtual processor;
A procedure in which the second virtual processor executes a user program;
A procedure in which the first virtual machine manager sets, in the memory, first control information that defines a state of a first virtual processor when the user program is executed;
A procedure in which the first virtual machine manager sets, in the memory, second control information that defines a state of the first virtual processor when the second virtual machine manager is executed;
A procedure in which the first virtual machine manager sets, in the memory, third control information that defines a state of the physical processor when the second virtual machine manager or the user program is executed;
A step of referring to the first control information when the first virtual machine manager causes the first virtual processor to start executing the user program;
A step of referring to the second control information when the first virtual machine manager causes the first virtual processor to start execution of the second virtual machine manager;
A procedure in which the first virtual machine manager updates the third control information on one of the referenced first control information or second control information;
A procedure in which the first virtual machine manager issues a first control instruction that instructs the physical processor to start executing an instruction according to the third control information;
Is executed by the physical processor.

  As described above, the present invention can be applied to a virtual machine system that provides a plurality of virtual servers. The present invention can also be applied to virtualization management (VMM) software that provides a plurality of virtual servers on a physical computer.

10 Host VMM
11 Host VMM holding data 12 CPU control unit 13 Physical CPU control data 20 Guest VMM
21 Virtual CPU control data 101 Physical server (physical computer)
102a to 102n virtual servers 108a to 108n virtual CPU
104 CPU
105 Memory 110a to 110n User program 111a to 111n Guest OS
112a to 112n Application 208 Virtual CPU
301 User interface

Claims (15)

In a virtualization program that runs on a physical computer with a physical processor and memory and runs a host virtual machine manager and a guest virtual machine manager,
A procedure in which the guest virtual machine manager stores, in the memory, first control information indicating a state of a virtual processor when a user program is executed;
A procedure in which the guest virtual machine manager stores, in the memory, second control information indicating a state of the virtual processor when the guest virtual machine manager is executed;
The host virtual machine manager determines whether the user program is executed or the guest virtual machine manager is executed, one of the first control information or the second control information, and the third Updating the control information with the control information of
A procedure in which the host virtual machine manager issues a first control instruction to the physical processor to be executed based on the third control information;
Is executed by the physical processor. The virtualization program according to claim 1,
Further, the host virtual machine manager determines whether to execute the guest virtual machine manager or the user program based on the host virtual machine manager call received from the physical processor. Let the physical processor run,
The host virtual machine manager updates the third control information as follows:
A procedure for determining whether the host virtual machine manager is to update the third control information based on the first control information or the second control information based on the determination result ,including,
A virtualization program characterized by that. The virtualization program according to claim 2,
Further, the guest virtual machine manager causes the physical processor to execute a procedure for issuing a third control instruction for confirming whether or not the virtual processor can accept the first control instruction.
The host virtual machine manager determines whether to execute the guest virtual machine manager or the user program.
A step of referring to response availability information set in advance when the cause of the calling of the host virtual machine manager is the third control command from the guest virtual machine manager;
And a procedure for determining a response to the third control command according to response availability information. The virtualization program according to claim 3,
The host virtual machine manager receives a setting request for the virtual processor;
The host virtual machine manager causes the physical processor to execute a procedure for setting the response availability information based on the setting request.
A virtualization program characterized by that. The virtualization program according to claim 3,
The guest virtual machine manager receiving a response to the third control command from the host virtual machine manager;
When the guest virtual machine manager determines that the first control instruction can be accepted by the virtual processor based on a response to the third control instruction, the first virtual machine manager receives the first control instruction from the virtual processor. Issuing a command for setting a control command to be receivable, and causing the physical processor to execute
A virtualization program characterized by that. The virtualization program according to claim 2,
The host virtual machine manager determines whether to execute the guest virtual machine manager or the user program.
When the cause of the call of the host virtual machine manager is a fourth control instruction that reflects the operation state of the virtual processor in the first control information from the guest virtual machine manager,
The host virtual machine manager issues a fourth control instruction for reflecting the operation state of the physical processor in the third control information to the physical processor;
The host virtual machine manager refers to the third control information reflecting the operating state of the physical processor;
A step of determining execution of the guest virtual machine manager after the host virtual machine manager updates the first control information based on the referenced third control information;
including,
A virtualization program characterized by that. The virtualization program according to claim 1,
The procedure for setting the third control information in the memory includes a procedure for setting the third control information in the memory for each virtual processor,
The procedure in which the host virtual machine manager issues the first control instruction to the physical processor includes a second control instruction that requests to select one of the plurality of third control information. Including publishing procedures,
A virtualization program characterized by that. A virtual machine system that executes a host virtual machine manager and a guest virtual machine manager on a physical machine having a physical processor and memory,
The guest virtual machine manager
First control information indicating a state of a virtual processor during execution of a user program and second control information indicating a state of the virtual processor during execution of the guest virtual machine manager are stored in the memory. ,
The host virtual machine manager
Storing in the memory third control information indicating a state of the physical processor when the guest virtual machine manager or the user program is executed;
The host virtual machine manager
It is determined whether the execution of the user program or the guest virtual machine manager is executed, and between one of the first control information or the second control information and the third control information. An update unit for updating the control information;
A first instruction issuing unit that issues a first control instruction to the physical processor to be executed based on the third control information;
A virtual computer system characterized by that. The virtual machine system according to claim 8,
The host virtual machine manager further includes:
A determination unit that determines which of the guest virtual machine manager and the user program to execute based on the host virtual machine manager call received from the physical processor;
A selection unit that selects one of the first control information and the second control information based on a result of the determination;
The update unit
Updating the third control information based on the selected first control information or second control information;
A virtual computer system characterized by that. The virtual machine system according to claim 9, wherein
The first instruction issuing unit is
The guest virtual machine manager issues a third control instruction for confirming whether the virtual processor can accept the first control instruction;
The determination unit
When the cause of the call of the host virtual machine manager is the third control command from the guest virtual machine manager, refer to the response availability information set in advance,
Determining a response to the third control command according to the response availability information;
A virtual computer system characterized by that. The virtual computer system according to claim 10,
The host virtual machine manager further includes:
A response availability information setting unit configured to set the response availability information based on a setting request for the virtual processor;
A virtual computer system characterized by that. The virtual computer system according to claim 10,
The guest virtual machine manager further issues a command for setting the first control command to be receivable to the virtual processor when the first control command is receivable by the virtual processor. A second instruction issuing unit,
A virtual computer system characterized by that. The virtual machine system according to claim 9, wherein
The determination unit
When the cause of the call of the host virtual machine manager is a fourth control instruction that reflects the operation state of the virtual processor in the first control information from the guest virtual machine manager,
The host virtual machine manager issues a fourth control instruction for reflecting the operation state of the physical processor in the third control information to the physical processor;
The host virtual machine manager refers to the third control information reflecting the operating state of the physical processor;
The host virtual machine manager determines execution of the guest virtual machine manager after updating the first control information based on the referenced third control information.
A virtual computer system characterized by that. The virtual machine system according to claim 8,
The host virtual machine manager
Storing the third control information in the memory for each virtual processor;
The first instruction issuing unit is
Instructing the physical processor to select one of the plurality of third control information and execute the guest virtual machine manager or the user program. . A computer system control method in a virtual computer system that runs a host virtual machine manager and a guest virtual machine manager on a physical computer having a physical processor and memory,
The guest virtual machine manager stores, in the memory, first control information indicating a state of a virtual processor when a user program is executed;
The guest virtual machine manager stores, in the memory, second control information indicating a state of the virtual processor when the guest virtual machine manager is executed;
The host virtual machine manager determines whether the user program is executed or the guest virtual machine manager is executed, one of the first control information or the second control information, and the third Update the control information with the control information of
The host virtual machine manager issues a first control instruction to the physical processor for execution based on the third control information;
A computer system control method characterized by the above.