JP2007272576A - Server device, and control program for virtual computer - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a virtual computer system capable of making a high performance compatible with a memory saving in an emulation system. <P>SOLUTION: The virtual computer system is provided with: an emulation module for emulating an operation on the basis of an operation code for executing an operation to hardware of a server device; an exception event handler module for accessing the emulation module with an exception event generated by a CPU as a turning point; a code management module for managing a promotion code for emulating the operation to the hardware of the server device; a frequency determination module for determining whether the frequency of an operation to the hardware of the server device is a high frequency; and a switching module for determining whether to access the emulation module by the exception event handler module or to access the emulation module by executing the promotion code on the basis of the determined frequency. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to the efficiency of hardware emulation related to a virtual machine system realized in a server apparatus.

  As the number of servers included in the IT system increases, the operational complexity increases, and the operation cost becomes a problem. In order to reduce operational costs, server integration is known in which a plurality of servers are integrated into one server. As a technique for realizing server integration, a virtual computer technique for logically dividing one computer at an arbitrary ratio is known.

  In the virtual computer technology, for example, firmware or middleware such as a hypervisor divides a physical computer into a plurality of logical partitions (LPAR), and computer resources (CPU, main memory, and I / O) are divided into each divided LPAR. Assign. An operating system (OS) operates on each LPAR. Further, one host OS (an OS that directly uses a physical computer) is executed on one server, and a hypervisor operating on the host OS similarly divides the physical computer into LPARs. A guest OS (an OS running on the LPAR) may run on each LPAR.

  As described above, the virtual machine technology makes it possible to operate an OS that has been operated on a plurality of servers and software that is operated on the OS on a single server. As a result, server integration is realized.

  This virtual computer technology has been used in large computers such as general-purpose computers (MainFrame) in the past, but can also be applied to low-end servers and personal computers due to recent improvements in microprocessor performance.

  By applying this virtual machine technology, the physical machine controls a virtual machine and a plurality of virtual machines (general names of guest OS and application software running on the guest OS) and a virtual machine. A virtual machine system having a virtual machine monitor (hereinafter referred to as VMM) is configured (see Patent Document 1).

  The OS is originally created on the premise that all server hardware is used exclusively. However, in the virtual machine system, a plurality of guest OSs operate. However, the guest OS cannot monopolize the server hardware. Therefore, the VMM emulates the same behavior as when the guest OS monopolizes the server hardware in response to the hardware operation by the guest OS.

  The VMM uses time and memory for this emulation process. Therefore, when the number of times of emulation by the VMM is increased by the guest OS, there is a problem that the processing time and the memory are increased, thereby reducing the guest performance and reducing the amount of memory available to the guest. In order to alleviate this problem, high-speed (high-performance) emulation technology and memory-saving technology have been devised.

  One of the techniques for speeding up emulation is a code conversion method. In the code conversion method, the VMM creates a conversion code corresponding to an operation code (also referred to as an OS code) by the guest OS on the memory. This conversion code creation process is called code conversion. When creating the conversion code, the hardware operation included in the corresponding OS code is replaced with the emulation code. In this code conversion method, by executing the conversion code instead of the OS code, it is possible to emulate the hardware operation with only the minimum necessary processing. In the code conversion method, code conversion is performed on all OS codes necessary for execution. Since code conversion requires processing time, it can cause a reduction in speed. Therefore, in this method, the created conversion code is kept in the memory, and the conversion code on the memory is reused for the second time and later to prevent the speed reduction. However, when there is a shortage of memory for holding conversion codes, conversion codes with low execution frequency are discarded because all conversion codes cannot be held.

  The VT method, which is a memory saving technology for emulation, uses a VT (Virtualization Technology) function mounted on an Intel CPU. When the VT function is used, an HW operation complete prohibition mode in which no HW operation code can be executed can be selected as an operation mode of the CPU. If the CPU attempts to execute the HW operation code when the CPU is in the HW operation complete prohibition mode, the CPU generates an exception event and forcibly interrupts the code execution. At this time, the CPU changes to the HW operation permission mode in which the HW operation is possible, and then executes a pre-registered code. On the contrary, when the restart process from the exception event is executed in the HW operation permission mode, the CPU transits to the HW operation complete prohibition mode and restarts the execution from the designated address (see Non-Patent Document 1 and Non-Patent Document 2).

In this method, an emulation module that performs emulation processing is pre-registered in the CPU, and the guest is executed in the HW operation inhibition mode to emulate the HW operation. Since this method holds only the emulation module and data used for emulation in the VMM memory, the VMM memory usage is small.
US Pat. No. 6,397,242 Intel Virtualization Technology Specification for the Intel Itanium Architecture Intel Virtualization Technology Specification for the IA-32 Intel Architecture

  The prior art code conversion method and the VT method each have problems.

  Although the code conversion method is high-performance, since all OS codes necessary for execution are converted, a large amount of memory is used to hold the conversion code, and memory saving cannot be expected. If the amount of memory is forcibly reduced to save memory, the reuse of conversion codes will not function sufficiently, and the number of code conversions will increase, leading to performance degradation, so high performance cannot be expected.

  The VT method always causes an exception event at the start of emulation, but recent CPUs perform highly parallel execution on the assumption that no exception event occurs. Therefore, when an exception event occurs, the CPU is effective in the internal state. It is necessary to perform complicated processing such as determination, destruction, and re-execution. Therefore, a delay is required to generate an exception event. Therefore, although the VT method is memory saving, high performance cannot be expected.

  As described above, the prior art solves only one of the high performance and the memory saving, and there is a problem that the high performance and the memory saving are in a trade-off relationship and are not compatible.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide a virtual computer system capable of achieving both high performance and memory saving in an emulation method.

  In order to solve the problem, in the present invention, the guest program code is classified into two parts according to the execution frequency of the HW operation, the code conversion method is used for the part with high execution frequency, and the VT method is used for the part with low execution frequency. Apply.

  In the present invention, the guest code is classified into a part including a high-frequency HW operation code and another part, that is, a low-frequency part, and a code conversion method is applied to emulation of a high-frequency HW operation code, so that the guest code is included in a low frequency. The VT method is applied to emulation of HW operation. By doing so, a virtual machine system that achieves both high performance and memory saving can be realized.

  Embodiments of the present invention will be described below with reference to the accompanying drawings.

<Embodiment 1>
FIG. 1 is a block diagram of a physical computer according to the first embodiment of this invention.

  This figure shows the configuration of a physical computer 90 on which the virtual computer system operates.

  The physical computer 90 includes one or more CPUs 400 (400-1 to 400-n). These CPUs 400 are connected to the north bridge 420 via the front side bus 425.

  The north bridge 420 is connected to the physical memory 415 via the memory bus 435. Further, the I / O interface 440 is connected via the bus 445. Further, the console 430 is directly connected.

  The I / O interface 440 is connected to an I / O device outside the physical computer 90 and transmits / receives data to / from these devices. In the example of FIG. 1, the I / O interface 440 includes a network adapter 451 connected to the LAN 450, a SCSI adapter 461 connected to the disk device 460, and a fiber channel adapter 471 connected to a SAN (Storage Area Network) 470. Connect to.

  The CPU 400 accesses the physical memory 415 via the north bridge 420 and executes a program stored in the physical memory 415, thereby executing processing defined in the program. Further, the CPU 400 accesses an I / O device outside the physical computer 90 via the north bridge 420 and the I / O interface 440.

  The north bridge 420 controls input / output of data to / from the host physical memory 415. The north bridge 420 includes a graphic controller and displays images and data on the console 430.

  The physical memory 415 stores a program for realizing a virtual machine monitor (hereinafter referred to as “VMM”) 10 and a guest 20 (20-1 to 20-n). The VMM 10 is executed by the CPU executing this program, and the guest 20 is executed by the VMM 10.

  The CPU 400 (400-1 to 400-n) is an IPF (Itanium Processor Family) processor having a VT-i function. CPU 400 operates in the HW operation complete prohibition mode when the VM bit of the PSR (Processor Status Register) is 1, among the registers included in CPU 400. Further, when the VM bit of the PSR is 0 and the CPL (Current Privilege Level) field of the PSR is 0, the operation is performed in the HW operation permission mode. When neither condition is satisfied, the operation is performed in the HW operation partial prohibition mode.

  The CPU 400 includes an instruction address conversion mechanism for converting a virtual address and a physical address of an instruction. This instruction address translation mechanism uses an instruction TLB (Translation Lookaside Buffer). Note that the CPU 400 may implement an address translation mechanism by combining the instruction TLB and the instruction page table.

  Next, the virtual computer system of this embodiment will be described.

  FIG. 2 is a block diagram of hardware and software including the guest 20 (20-1 to 20-n) and the VMM 10 that operates the guest 20 in the physical computer 90.

  In FIG. 2, a VMM 10 that manages a plurality of guests 20 (20-1 to 20-n) is operating on the physical computer 90. The VMM 10 emulates hardware operations (hereinafter referred to as “HW operations”) executed by the plurality of guests 20.

  Each guest 20 includes one or more guest codes 21 (21-1 to 21-m) necessary for operation. This guest code 21 includes an HW operation code 25.

  The VMM 10 includes a code management module 30, a code generation module 40, an exception event handler module 50, an emulation module 60, a frequency determination module 70, and a switching module 80.

  Hereinafter, the processing of the VMM 10 when the guest 20 executes the guest code including the HW operation code will be described.

  The VMM 10 executes the guest code 21 in the HW operation complete prohibition mode. When the guest 20 executes the guest code 21 including the HW operation code, the CPU 400 generates an exception event. Then, after the CPU 400 transitions to the HW operation permission mode, the exception event handler module 50 of the VMM 10 is executed.

  The exception event handler module 50 analyzes the cause of the exception event and calls the emulation module 60 corresponding to the exception event, that is, the HW operation code.

  The emulation module 60 operates the physical computer 90 as necessary. As a result, emulation corresponding to the HW operation code is performed. The emulation module 60 calls the frequency determination module 70 when performing emulation.

  The frequency determination module 70 determines the frequency of the HW operation for each address group, and passes the determination result to the switching module 80.

  A predetermined address range including the instruction address of the HW operation code is called an address group. In this embodiment, pages are used for address groups.

  In addition, the frequency determination module 70 refers to the storage device 91 included in the physical computer 90 as necessary, such as when the module is initialized, and acquires the method switching condition stored in the storage device 91.

  The switching module 80 acquires the frequency of the HW operation for each page from the frequency determination module 60. If it is determined that the frequency is high, the code management module 30 is requested to search for a conversion code corresponding to the HW operation.

  The code management module 30 manages conversion codes. The code management module 30 includes a conversion code management table 35 and a conversion code LRU (Least Recent Used) list 36. The conversion code management table 35 holds information for searching for conversion codes. The conversion code LRU list 36 holds information on conversion codes having a long unused time.

  As a result of the request to the code management module 30, the switching module 80 calls the code generation module 40 when the conversion code management table 35 does not record information corresponding to the page including the address of the HW operation code.

  The code generation module 40 refers to the page including the address of the HW operation code, and corresponds to a plurality of shadow codes 31 (31-1 to 31-p) and a plurality of promotion codes 32 (32-1 to 32-2). q) is generated on the memory managed by the code management module 30. Then, the contents are stored in the conversion code management table 35.

  Thereafter, the switching module 80 sets an association between the virtual address of the page and the physical address of the shadow code 31 in the instruction address conversion mechanism 93 of the physical computer 90.

  Through the above operation, after that, when a page including the address of the HW operation code by the guest 20 is executed, the shadow code 31 is executed.

  The VMM 10 executes an “rfi instruction” for returning the CPU operation mode to the HW operation complete prohibition mode at the end of the series of processes. As a result, the shadow code is executed in the HW operation complete prohibition mode like the guest code.

  The shadow code 31 calls the promotion code 32 instead of the HW operation code.

  The promotion code 32 shifts the CPU to the HW operation permission mode and calls the emulation module 60. Alternatively, the emulation code 33 (33-1), which is a partial copy of the emulation module 60, is executed. As a result, emulation of the HW operation is executed. Thereafter, the CPU is returned to the HW operation complete prohibition mode.

  Note that the promotion code 32 includes “vmsw.0” and “vmsw.1” which are instructions for manipulating the VM bit of the PSR in order to cause the CPU to transition to the HW operation permission mode.

  The guest code 21 corresponding to the shadow code 31 may be rewritten by the guest 20. When the emulation module 60 detects this rewriting, the emulation module 60 notifies the frequency determining module 70 and the switching module 80 of the rewriting. The frequency determination module 70 sets the frequency of the rewritten page to “low frequency”. The switching module 80 invalidates the conversion code corresponding to the rewritten page and records this in the conversion code management table 35. Further, the setting relating to the rewritten page is deleted from the instruction address conversion mechanism 93 of the physical computer 90.

  The physical computer 90 is connected to the console 92. When the system administrator changes the code conversion setting using the console 92, the contents are recorded in the storage device 91 that stores the code conversion setting. Further, the contents are transmitted to the frequency determination module 70 and the code management module 30.

  FIG. 3 is an explanatory diagram of an example of the code conversion setting table 95 stored in the storage device 91.

  The code conversion setting table 95 shows, for each guest 20, an upper limit of the memory amount used by the guest and a frequency threshold for determining whether the guest code of the guest is high frequency or low frequency. Store.

  The code conversion setting 95 includes a guest identification number field 501, an upper limit field 520 for the amount of memory to be used, and a frequency threshold field 521.

  The guest identification number field 501 stores a guest identification number that is an identifier assigned to each guest 20. The upper limit field 520 of the memory amount to be used stores an upper limit of the memory amount used to hold the memory conversion code. The frequency threshold field 521 stores a threshold value for determining whether the guest code has a high frequency or a low frequency.

  FIG. 4 is a configuration block diagram of the frequency determination module 70.

  The frequency determination module 70 includes a frequency determination code 71 and a HW operation frequency table 72.

  The frequency determination code 71 is a program that refers to and updates the HW operation frequency table 72 to determine the frequency of the HW operation. The HW operation frequency table 72 is a table that stores the number of HW operations executed by the guest 20 in units of physical pages of guest code.

  FIG. 5 is an explanatory diagram of an example of the HW operation frequency table 72.

  The HW operation frequency table 72 stores, for each guest 20, the physical page address of the guest code and the number of executions of the HW operation on the page.

  The HW operation frequency table 72 includes a guest identification number field 501, an address field 503 of a guest code physical page, and an HW operation execution frequency field 506.

  The guest identification number field 501 stores the same guest identification number as the code conversion setting table 95 described above. The guest code physical page address field 503 stores the address of the guest code physical page. The HW operation execution frequency field 506 stores the number of times that the HW operation corresponding to the physical page of the guest code has been executed. Note that the initial value of the HW operation execution count is zero.

  FIG. 6 is an explanatory diagram of an example of the conversion code management table 35.

  The conversion code management table 35 stores, for each guest 20, the physical page address of the guest code and the address of the physical page of the conversion code corresponding to the guest code.

  The conversion code management table 35 includes a guest identification number field 501, a guest code physical page address field 503, a valid bit field 504, and a conversion code physical page address 505.

  The guest identification number field 501 stores the same guest identification number as that in the code conversion table 95 and the HW operation frequency table 70 described above. The guest code physical page address field 503 stores the same address as the guest code physical page address of the HW operation frequency table 72 described above. The valid bit field 504 stores a valid bit that is an identifier indicating whether or not the conversion code corresponding to the page is valid. The initial value of this valid bit is 0 (invalid). The physical page address field 505 of the conversion code stores the address of the physical page of the conversion code corresponding to the physical page address of the guest code.

  FIG. 7 is an explanatory diagram of an example of the conversion code LRU list 36.

  The conversion code LRU list 36 is a bidirectional linear list for holding, for each address of the conversion code physical page, an order in which the unused time of the address is short.

  The conversion code LRU list 36 includes a prev pointer field 530 (530-1 to 530-t), an address field 505 (505-1 to 505-t) of a conversion code physical page, and a next pointer field 531 (531-1 to 531). -T) is one element, and these elements are connected by respective pointers.

  The prev pointer field 530 stores a prev pointer indicating the previous element. The next pointer field 531 stores a next pointer indicating the next element. The conversion code physical page address field 505 stores the same address as the conversion code physical page of the conversion code management table 35 described above.

  Next, processing of the VMM 10 accompanying the operation of the guest 20 will be described with reference to a flowchart.

  FIG. 8 is a flowchart of processing when the VMM 10 operates the guest 20.

  First, when the guest 20 is activated by turning on the power of the virtual machine or the like, the VMM 10 refers to the guest information held by itself and initializes an entry related to the activated guest (S200).

  Thereafter, the guest 20 executes the guest code or the conversion code in the HW operation complete prohibition mode (S240). The VMM 10 determines whether or not execution of the HW operation code is detected by execution of the guest code by the guest 20 (S250).

  When it is determined that the execution of the HW operation code by the guest 20 is detected, the VMM 10 generates an exception event and changes the operation mode of the CPU 400 to the HW operation permission mode. Thereafter, the process proceeds to step S210. Similarly, when the execution of the promotion code by the guest 20 is detected and it is determined that the emulation module 60 has been called, the VMM 10 similarly changes the CPU operation mode to the HW operation permission mode. Then, it progresses to S210. On the other hand, if the VMM 10 determines not to detect the execution of the HW operation code or the promotion code, the process returns to step S240 and waits for the detection of the execution of the next guest code.

  In step S210, the VMM 10 performs an emulation process of the HW operation. Also, the type of code to be executed next is determined by this emulation processing.

  Next, the VMM 10 determines whether or not the guest 20 has been terminated due to power-off of the virtual machine or the like. If it is determined that the guest 20 has ended, the VMM 10 ends the processing of the guest 20. On the other hand, if it is determined that the guest 20 does not end and the operation continues, the process proceeds to step S260.

  In S <b> 260, the VMM 10 determines whether a change in code conversion setting by the system administrator has been input to the console 92. If it is determined that the code conversion setting 95 has been changed by the input to the console 92, the process proceeds to step S270. On the other hand, if there is no change in the code conversion setting 95, the process proceeds to step S230.

  In step S270, the physical computer 90 receives the content set by the console 92 and executes code conversion setting update processing for updating the code conversion setting 95 of the storage device 91.

  Next, the VMM 10 sets the code type determined in step S210. That is, when returning to the guest code or the shadow code, the VMM 10 executes an instruction to change the CPU operation mode to the HW operation complete prohibition mode. Thereafter, the process returns to step S240. When returning to the promotion code, the process returns to S240 without doing anything. Thereafter, the CPU operation mode is changed to the HW operation complete prohibition mode by executing the instruction in the promotion code.

  FIG. 9 is a flowchart of the VMM emulation processing in step S210 of FIG.

  First, the VMM 10 performs emulation according to the contents of the HW operation code executed by the guest 20 (S100).

  At this time, the VMM 10 determines whether or not the contents of the emulation include a change of the guest code subjected to code conversion, that is, whether or not to change the setting of the instruction address conversion mechanism 93 (S110). The VMM 10 determines that the guest code has been rewritten when the guest 20 tries to execute an FC (Flush Cache) instruction that is a cache operation instruction. If it is determined not to change, the process proceeds to step S130.

  If it is determined to be changed, the VMM 10 searches the conversion code management table 35 (S111), and determines whether there is a conversion code corresponding to the corresponding guest code (S112).

  If it is determined that there is a corresponding conversion code, the VMM 10 sets the association between the virtual address of the corresponding guest code and the physical address of the conversion code in the instruction address conversion mechanism 93 (S113). Further, the VMM 10 adds the conversion code information to the conversion code LRU list 36 and updates the conversion code LRU list 36 (S114).

  On the other hand, when determining that there is no corresponding conversion code, the VMM 10 sets the association between the virtual address of the corresponding guest code and the physical address of the corresponding guest code in the instruction address conversion mechanism 93 (S115).

  Next, the VMM 10 executes a conversion code invalidation process corresponding to the rewritten guest code. With this process, the guest code page emulation method is switched to the VT method (S120).

  In step S130, the VMM 10 executes a frequency determination process for the HW operation. With this process, it is determined whether the frequency of the HW operation performed by the guest 20 is high or low.

  Next, the VMM 10 determines whether the frequency is high as a result of the low frequency processing of the HW operation (S140). If it is determined that the frequency is high, the process proceeds to step S150. If it is determined that the frequency is low, the process proceeds to step S160.

  In step S150, the VMM 10 executes processing for applying the code conversion method to emulation of the HW operation included in the page.

  In step S160, the VMM 10 executes a selection process for the next process of the HW operation.

  FIG. 10 is a flowchart of the conversion code invalidation process in step S120 of FIG.

  The VMM 10 refers to the conversion code management table 35 and clears the valid bit of the entry corresponding to the rewritten guest code. That is, the valid bit is changed to 0 (S600).

  Next, the VMM 10 refers to the HW operation frequency table 72 and sets the number of executions of the HW operation for the entry corresponding to the rewritten guest code to 0 (S610).

  Next, the VMM 10 sets the association between the rewritten virtual address of the guest code and the physical address of the guest code in the instruction address conversion mechanism 93 (S630).

  FIG. 11 is a flowchart of the frequency determination process in S130 of FIG.

  First, the VMM 10 determines whether it is an application of the guest 20 that has executed the HW operation code (S790). If it is determined that the application has been executed, the process proceeds to step S730. When it is determined that the OS of the guest 20 has been executed, the process proceeds to step S700.

  In step S700, the VMM 10 calculates the physical address of the page to which the HW operation code belongs.

  Next, the VMM 10 refers to the HW operation frequency table 72 and obtains the number of executions of the HW operation for the entry corresponding to the calculated physical address of the page (S710).

  Next, the VMM 10 refers to the code conversion setting table 95 and obtains the frequency threshold value from the entry of the identification number of the guest 20 that has requested the HW operation code. Then, the number of times of execution of the acquired HW operation is compared with the threshold value of the acquired frequency to determine whether or not the number of times of execution is equal to or greater than the threshold value (S720). If it is determined that the number of executions is equal to or greater than the threshold, the process proceeds to step S740. If it is determined that the number of executions is less than the threshold, the process proceeds to step S730.

  In S740, the VMM 10 determines that the frequency of the HW operation on the page is high.

  In S730, the VMM 10 determines that the frequency of the HW operation on the page is low.

  Next, the VMM 10 updates the HW operation frequency table 72 by adding 1 to the number of executions of the HW operation for the page in the HW operation frequency table 72 (S750).

  FIG. 12 is a flowchart of the selection process of the next process in step S160 of FIG.

  The VMM 10 determines whether or not the guest 20 has been terminated, that is, whether or not the virtual machine 21 in which the guest 20 is running has been turned off (S1000). If it is determined that the virtual computer 21 has been powered off, the process advances to step S1010. Otherwise, the process proceeds to step S1020.

  In step S1010, the VMM 10 selects guest termination as the next process to be executed.

  In step S1020, the VMM 10 determines to continuously apply the guest code or conversion code to the next process to be executed.

  FIG. 13 is a flowchart of the application process of the code conversion method in step S150 of FIG.

  In step S1200, the VMM 10 refers to the conversion code management table 35 and determines whether there is a conversion code corresponding to the physical address of the page including the HW operation code. If it is determined that no conversion code exists, the process advances to step S1210. If it is determined that a conversion code has been set, this process ends and the process returns to the flowchart of FIG.

  In S1210, the VMM 10 determines whether or not there is a free capacity necessary for the memory capacity of the memory area for storing the conversion code. If it is determined that the necessary free space does not exist in the memory area, the process proceeds to step S1220. If it is determined that the necessary free space exists, the process proceeds to step S1230.

  In step S1220, the VMM 10 refers to the conversion code LRU list 36 and selects one element including the conversion code with the longest unused time. Then, the conversion code is discarded from the memory area by invalidating the physical address of the page belonging to the conversion code included in the selected element. Further, the conversion code information included in the selected element is deleted from the conversion code LRU 36. Then, the process returns to step S1210. That is, the conversion code with the longest unused time is discarded from the memory area until the necessary free space can be secured.

  In step S1230, the VMM 10 generates a conversion code corresponding to the guest code of the page, and stores the generated conversion code. Among the conversion codes, the shadow code has a one-to-one correspondence with the guest code, and calls the promotion code instead of the HW operation code. Of the conversion codes, the promotion code includes a vmsw instruction and includes at least one of a code that calls the emulation module 60 and an emulation code 33 that is a partial copy of the emulation module 60.

  Next, the VMM 10 stores the generated conversion code information in the conversion code management table 35. Further, the information of the generated conversion code is added to the conversion code LRU 36 list (S1240).

  FIG. 14 is a flowchart of the code update setting update process in step S270 of FIG.

  First, the physical computer 90 receives a change in code conversion setting set by the system administrator from the console (S1400).

  The physical computer 90 reflects the received change contents in the code conversion setting table 95 of the storage device 91 to update the code conversion setting table 95 (S1410).

  Next, the physical computer 90 notifies the updated code conversion setting table 95 to the frequency determination module 70 and the code management module 30. As a result, the frequency determination module 70 and the code management module 30 update the code conversion setting table 95 stored therein.

  As described above, in the virtual machine system according to the first embodiment of this invention, when the guest 20 requests the execution of the guest code including the HW operation, the VMM 10 determines according to the execution frequency of the HW operation. Change the processing method. That is, the HW operation is divided into two parts, a code conversion method with high execution efficiency is applied to a part with high execution frequency, and a VT method with low memory consumption is applied to a part with low execution frequency. By doing so, it is possible to perform emulation processing capable of achieving both high performance and memory saving.

<Embodiment 2>
Next, a virtual machine system according to a second embodiment of this invention will be described. In the second embodiment, the frequency of the HW operation is determined based on the instruction type that is the type of operation.

  The hardware configuration of the second embodiment is the same as that shown in FIG. In addition, the same reference numerals are given to components that perform the same operations as those in the first embodiment, and the description thereof is omitted.

  In the second embodiment, since the instruction type is used for frequency determination, only the two points of the code conversion setting contents and the format of the HW operation frequency table are different from the first embodiment.

  FIG. 15 is an explanatory diagram of a code conversion setting table 95 according to the second embodiment.

  Unlike FIG. 4 described above in the first embodiment, the code conversion setting table 95 stores an instruction type instead of a threshold value in order to determine a high frequency.

  The code conversion setting 95 includes a guest identification number field 501, an upper limit field 502 of the amount of memory to be used, and an instruction type list field 522.

  The guest identification number field 501 stores a guest identification number that is an identifier assigned to each guest 20. The upper limit field 520 of the memory amount to be used stores an upper limit of the memory amount used to hold the memory conversion code. The instruction type list field 522 stores, in a list format, instruction types that are determined to be high in frequency among guest code instruction types.

  FIG. 16 is an explanatory diagram of the HW operation frequency table 72 according to the second embodiment.

  Unlike FIG. 5 described above in the first embodiment, the HW operation frequency table 72 includes an instruction type 507 and a frequency flag for determining whether or not the instruction type is high frequency for each guest 20. 508 is stored.

  The HW operation frequency table 72 is generated by the frequency determination code 71 based on the code conversion setting table 95 set by the administrator. That is, the list of guest identification numbers and instruction types in the code conversion setting table 95 is rearranged by the guest identification number and the instruction type.

  The HW operation frequency table 72 includes a guest identification number field 501, an instruction type field 507, and a frequency flag field 508.

  The guest identification number field 501 stores the same guest identification number as the code conversion setting table 901 described above. The instruction type field 507 stores an identifier indicating the instruction type of the guest code. The frequency flag field 508 stores a frequency flag corresponding to the instruction type. If the frequency flag is 1, it indicates that the frequency is high, and if it is 0, it indicates that the frequency is low. The initial value of the frequency flag is acquired from the code conversion setting table 95 by the frequency determination module 70.

  Next, processing of the VMM 10 accompanying the operation of the guest 20 according to the second embodiment will be described with reference to a flowchart.

  The outline of the processing of the second embodiment is the same as that of FIG. 8 described above in the first embodiment.

  Further, the VMM emulation process in step S210 of FIG. 8 is the same as the process of FIG.

  FIG. 17 is a flowchart of the conversion code invalidation process of the second embodiment in step S120 of FIG.

  The VMM 10 refers to the conversion code management table 35 and clears the valid bit field 504 of the entry corresponding to the rewritten guest code. That is, the valid bit is changed to 0 (S600).

  Next, the VMM 10 sets the association between the rewritten virtual address of the guest code and the physical address of the guest code in the instruction address conversion mechanism 93 (S630).

  FIG. 18 is a flowchart of the frequency determination process according to the second embodiment in step S130 of FIG.

  First, the VMM 10 determines whether it is an application of the guest 20 that has executed the HW operation code (S790). If it is determined that the application has been executed, the process proceeds to step S830. When it is determined that the OS of the guest 20 has been executed, the process proceeds to step S800.

  In step S800, the VMM 10 acquires the instruction type of the HW operation code.

  Next, the VMM 10 refers to the HW operation frequency table 72 and acquires the frequency flag of the entry corresponding to the acquired instruction type (S810).

  Next, the VMM 10 determines whether or not the acquired frequency flag is 1. If the frequency flag is 1, that is, indicates a high frequency, the process proceeds to step S840. If the frequency flag is 0, that is, indicates a low frequency, the process proceeds to step S830 (S820).

  In step S840, the VMM 10 determines that the frequency of the HW operation on the page is high.

  In step S830, the VMM 10 determines that the frequency of the HW operation on the page is low.

  Note that the selection process of the next process in step S160 of FIG. 9 is the same as the process of FIG. 12 of the first embodiment described above.

  The application process of the code conversion method in step S150 of FIG. 9 is almost the same as the process of FIG. 13 of the first embodiment described above, except for the following one point.

  First, in step S1230, the VMM 10 excludes an instruction whose instruction type included in the page is not high in frequency from the code conversion target, and copies the guest code instruction to the shadow code as it is.

  Further, the code update setting update process in step S270 of FIG. 8 is the same as that of FIG. 14 of the first embodiment described above.

  As described above, in the second embodiment of the present invention, the guest code is classified into two parts according to the instruction type of the HW operation. Then, the code conversion method is applied to a portion including an instruction type having a high execution frequency, and the VT method is applied to a portion not including an instruction type having a high execution frequency. By doing so, it is possible to perform emulation processing that achieves both high performance and memory saving.

<Embodiment 3>
Next, a virtual machine system according to a third embodiment of this invention will be described. In the third embodiment, the frequency is determined based on the interval between HW operations.

  In addition, the same code | symbol is attached | subjected to the structure which carries out the same effect | action as 1st Embodiment, and the description is abbreviate | omitted.

  The hardware configuration of the third embodiment is almost the same as that of FIG. However, in the third embodiment, the functions of the CPUs (400-1 to 400-n) used are different.

  The CPU 400 (400-1 to 400-n) is an x86 processor corresponding to the VT-x function. The CPU 400 includes an HW operation complete prohibition mode, an HW operation permission mode, and an HW operation partial prohibition mode. The HW operation complete prohibition mode is enabled by setting the CPU 400 to the VMX non-root mode. The HW operation permission mode is enabled by setting the CPU 400 to the VMX root mode and the privilege level (CPL: Current Privilege Level) to 0. The HW operation partial prohibition mode is enabled by setting the CPU 400 to the VMX root mode and CPL to non-zero.

  Further, in order for the CPU 400 to transition from the VMX root mode to the VMX non-root mode, it is necessary to execute a VMEntry operation. The VMEntry operation is a generic term for the execution of the VMLAUNCH instruction for instructing the activation of the guest OS and the execution of the VMRESUME instruction for temporarily stopping the guest OS. Further, in order to transition from the VMX non-root mode to the VMX root mode, it is necessary to execute a VMExit event. The VMexit event is an exception event resulting from the execution of the HW operation.

  Next, a virtual computer system according to a third embodiment will be described.

  FIG. 19 is a block diagram of hardware and software including the guest 20 (20-1 to 20-n) and the VMM 10 that operates the guest 20 in the physical computer 90.

  FIG. 19 is almost the same as the block diagram of FIG. 2 of the first embodiment described above. However, the operation of the code management module 30 is different.

  Hereinafter, the processing of the VMM 10 when the guest 20 executes the guest code including the HW operation code will be described.

  When the guest 20 executes the guest code 25 including the HW operation code 25, the VMM 10 generates an exception event. Due to this exception event, the CPU 400 shifts to the HW operation permission mode. Thereafter, the exception event handler module 50 of the VMM 10 is executed.

  The exception event handler module 50 analyzes the cause of the exception event and calls the emulation module 60 corresponding to the exception event, that is, the HW operation code.

  The emulation module 60 operates the physical computer 90 as necessary. As a result, emulation corresponding to the HW operation code is performed. The emulation module 60 calls the frequency determination module 70 when performing emulation.

  The frequency determination module 70 determines the short HW operation interval, that is, the frequency of the HW operation from the difference between the time information when the previous HW operation is performed by the guest 20 and the time information when the current HW operation is performed. Is calculated. Then, using the calculated frequency history, the shortness of the interval between the time information when the current HW operation is performed and the time information when the HW operation is performed next time, that is, the frequency is determined. The result is passed to the switching module 80.

  The time information is information with which the time can be specified, and in this embodiment is the number of branch instructions between pages executed by the guest. As the time information, any information that can approximate the time, such as the time value of the clock provided in the physical computer 90, the number of executed guest instructions, the number of CALL instructions and RET instructions of executed guests, can be used.

  The frequency determination module 70 refers to the method switching condition stored in the storage device 91 of the physical computer 90 as needed, such as when the module is initialized, and stores the contents in the frequency determination module 70.

  When the frequency determination module 70 determines that the interval between the current HW operation and the next HW operation is long, that is, the frequency is low, the switching module 80 returns the operation mode of the CPU 400 to the HW operation complete prohibition mode. . That is, the switching module 80 performs a VMEntry operation on the CPU 400. After this operation, the process branches to the guest code.

  On the other hand, when the frequency determination module 70 determines that the interval between the current HW operation and the next HW operation is short, that is, the frequency is high, the switching module 80 first responds to the guest code to be executed next. The code management module 30 is inquired about the address of the conversion code to be processed. Then, the operation mode of the CPU 400 is returned to the HW operation partial prohibition mode. That is, the switching module 80 executes the CPL increase branch instruction. After this instruction, the process branches to the conversion code. By this process, the conversion code is executed in the HW operation part prohibition mode. For the CPL increase branch instruction, an IRET instruction, a SYSRET instruction, a SYSEXIT instruction, or the like is used.

  In response to the inquiry from the switching module 80, the code management module 30 searches the conversion code management table 35 and determines whether a conversion code corresponding to the inquiry code exists. If a conversion code exists, the address of the conversion code is returned. If there is no conversion code corresponding to the inquiry code, the code generation module 40 is called to generate the conversion code, and the address of the generated conversion code is returned.

  The code generation module 40 refers to the next guest code page and stores the corresponding shadow code 31 (31-1 to 31-p) and the promotion code 32 (32-1) on the memory managed by the code management module 30. To generate. Then, the contents are registered in the conversion code management table 35.

  The shadow code 31 (31-1 to 31-p) includes a promotion code 32 (32-1) instead of the HW operation code. The promotion code 32 (32-1) causes the CPU to transition to the HW operation permission mode, calls the emulation module 60 to emulate the HW operation, and then returns the CPU to the HW operation partial prohibition mode. The promotion code 32 includes a CPL decrease branch instruction (privilege level decrease branch instruction). As the CPL decrement branch instruction, a farCALL instruction, a SYSCALL instruction, a SYSENTER instruction, or the like is used.

  The guest code 21 corresponding to the shadow code 31 may be rewritten by the guest 20. When the emulation module 60 detects this rewriting, it notifies the switching module 80 of this rewriting. The switching module 80 invalidates the conversion code corresponding to the rewritten page and records this in the conversion code management table 35.

  The code conversion setting table 95 stored in the storage device 91 is the same as that in FIG. 3 of the first embodiment described above.

  FIG. 20 is a configuration block diagram of the frequency determination module 70.

  The frequency determination module 70 is substantially the same as the frequency determination module 71 of the first embodiment, but includes an HW operation history table 73.

  The HW operation frequency table 72 stores the physical address of the guest code that executes the HW operation X when the interval between the HW operation X and the next executed HW operation is short, that is, when the frequency is high. The HW operation history table 73 stores the operation subject (OS or AP) that executed the last processed HW operation, the physical address of the guest code, and time information.

  FIG. 21 is an explanatory diagram of an example of the HW operation frequency table 72.

  The HW operation frequency table 72 stores, for each guest 20, a valid bit indicating the validity of the entry and a physical address of the guest code.

  The HW operation frequency table 72 includes a guest identification number field 501, a valid bit field 504, and a guest code physical address field 509.

  The guest identification number field 501 stores a guest identification number that is an identifier assigned to each guest 20. The valid bit field 504 stores a valid bit indicating that the physical address of the guest code has a short HW operation interval, that is, a start point or an intermediate point of a high-frequency part. The guest code physical address field 509 stores the physical address of the guest code.

  The physical address of the guest code not included in this table is a start point or an intermediate point of a part where the interval of the HW operation is long, that is, the frequency is low. The initial value of the valid bit is 0, that is, invalid.

  FIG. 22 is an explanatory diagram of an example of the HW operation history table 73.

  The HW operation history table 73 includes a guest identification number field 501, a CPU identification number field 502, an operation subject field 523, a guest code physical address field 509, and a time information field 510.

  The guest identification number field 501 stores the same guest identification number as that shown in FIG. The CPU identification number field 502 stores a number for identifying the CPU 400. The action subject field 523 stores an identifier for distinguishing whether the subject that executed the last processed HW operation is an OS or an AP. The guest code physical address 509 is the same as the guest code physical address of FIG. As described above, the time information field 510 stores the number of branch instructions between pages executed by the guest at the time of the last processed HW operation. Any information that can approximate the time, such as the time value of the clock provided in the physical computer 90, the number of executed guest instructions, the number of CALL instructions and RET instructions of executed guests, can be used.

  FIG. 23 is a configuration block diagram of the switching module 80.

  The switching module 80 includes a method switching code 81 and an operation method table 82.

  The operation method is a method for calling an emulation module. In this embodiment, a VT method or a code conversion method is used. The method switching code 81 switches between the code conversion method and the VT method which are operation methods according to the frequency, and stores the result in the operation method table 82. The operation method table 82 stores the operation method currently applied.

  FIG. 24 is an explanatory diagram of an example of the operation method table 82.

  The operation method table 82 includes a guest identification number field 501, a CPU identification number field 502, and an operation method field 513.

  The guest identification number field 501 stores the same guest identification number as that in the HW operation frequency table 72 of FIG. The CPU identification number field 502 stores the same CPU identification number as that of the HW operation history table 73 shown in FIG. The operation method field 513 stores the operation method currently applied. The initial value of the operation method is “VT method”.

  FIG. 25 is an explanatory diagram of an example of the conversion code management table 35.

  The conversion code management table 35 stores, for each guest 20, a guest code physical address 509 and a conversion code physical address 511 corresponding to the guest code.

  The conversion code management table 35 includes a guest identification number field 501, a guest code physical address field 509, a valid bit field 504, and a conversion code physical address 511.

  The guest identification number field 501 stores the same guest identification number as that in the HW operation frequency table 72 of FIG. The guest code physical address 509 is the same as the guest code physical address of FIG. The valid bit field 504 stores a valid bit that is an identifier indicating whether or not the conversion code corresponding to the physical address is valid. The initial value of this valid bit is 0 (invalid). The conversion code physical address field 509 stores the physical address of the conversion code corresponding to the physical address of the guest code.

  Next, processing of the VMM 10 accompanying the operation of the guest 20 according to the third embodiment will be described with reference to a flowchart.

  FIG. 26 is a flowchart of processing when the VMM 10 operates the guest 20.

  FIG. 26 is similar to the flowchart of FIG. 8 of the first embodiment described above, except that the first HW operation is always emulated by the guest code.

  First, when the guest 20 is activated by turning on the power of the virtual machine or the like, the VMM 10 refers to the guest information held by itself and initializes an entry related to the activated guest (S200).

  Thereafter, the guest 20 executes the guest code in the HW operation complete prohibition mode (S340). The VMM 10 determines whether or not execution of the HW operation code is detected by execution of the guest code by the guest 20 (S350).

  When the execution of the HW operation code by the guest 20 is detected, the VMM 10 generates an exception event and changes the operation mode of the CPU 400 to the HW operation permission mode. Thereafter, the process proceeds to step S210. On the other hand, if the VMM 10 does not detect the execution of the HW operation code, the process returns to step S340 to execute the next guest code.

  In step S210, the VMM 10 performs an emulation process of the HW operation. Also, the type of code to be executed next is determined by this emulation processing.

  Next, the VMM 10 determines whether or not the guest 20 has been terminated due to power-off of the virtual machine or the like. If it is determined that the guest 20 has ended, the VMM 10 ends the processing of the guest 20. On the other hand, if it is determined that the guest 20 does not end and the operation continues, the process proceeds to step S260.

  In S <b> 260, the VMM 10 determines whether a change in code conversion setting by the system administrator has been input to the console 92. If it is determined that the code conversion setting 95 has been changed by the input to the console 92, the process proceeds to step S270. On the other hand, if there is no change in the code conversion setting 95, the process proceeds to step S330.

  In step S270, the physical computer 90 receives the content set by the console 92 and executes code conversion setting update processing for updating the code conversion setting 95 of the storage device 91.

  Next, the VMM 10 determines whether or not the next process executed by the guest 20 is execution of a conversion code (S330). If it is determined that the next process is the execution of the conversion code, the VMM 10 executes the CPL increase branch instruction to change the CPU operation mode to the HW operation partial inhibition mode. Thereafter, the process proceeds to step S360. On the other hand, when it is determined that the next process is the execution of the guest code, the VMM 10 executes the VMEntry operation and changes the CPU operation mode to the HW operation complete prohibition mode. Thereafter, the process returns to step S340.

  In step S360, the VMM 10 executes the conversion code in the HW operation part prohibition mode.

  Next, the VMM 10 detects the execution of the promotion code by the guest 20 and determines whether the emulation module 60 has been called (S370). When the promotion code is executed and the emulation module is called, the VMM 10 changes the CPU operation mode to the HW operation permission mode and proceeds to S210. On the other hand, if the VMM 10 does not detect the execution of the promotion code, the process returns to step S360 and the next conversion code is executed.

  FIG. 27 is a flowchart of the VMM emulation processing in step S210 of FIG.

  First, the VMM 10 performs emulation according to the contents of the HW operation code executed by the guest 20 (S100).

  At this time, the VMM 10 determines whether or not the contents of the emulation include a change in the guest code that has been subjected to code conversion (S110). Note that the VMM 10 determines whether or not the guest code has been changed by determining whether or not the guest code exists in the page when the guest 20 writes to the page for which write protection is set. If it is determined not to change, the process proceeds to step S130. On the other hand, if it is determined to be changed, the process proceeds to step S120.

  In step S120, the VMM 10 executes conversion code invalidation processing corresponding to the rewritten guest code (S120).

  In step S130, the VMM 10 executes a frequency determination process for the HW operation. With this process, it is determined whether the frequency of the HW operation performed by the guest 20 is high or low.

  Next, the VMM 10 determines whether the frequency is high as a result of the frequency determination process of the HW operation (S140). If it is determined that the frequency is high, the process proceeds to step S170. If it is determined that the frequency is low, the process proceeds to step S180.

  In step S <b> 170, the VMM 10 determines the code conversion method as the subsequent HW operation detection means. Then, the operation method 513 corresponding to the guest and CPU in the operation method table 82 is changed to the code conversion method.

  On the other hand, in step S180, the VMM 10 determines the detection means for the subsequent HW operation as the VT method. Then, the operation method 513 corresponding to the guest and CPU in the operation method table 82 is changed to the VT method.

  Next, in S160, the VMM 10 executes a selection process for the next process of the HW operation.

  FIG. 28 is a flowchart of the conversion code invalidation process in step S120 of FIG.

  The VMM 10 refers to the conversion code management table 35 and clears the valid bit of the entry corresponding to the rewritten guest code. That is, the valid bit is changed to 0 (S600).

  Next, the VMM 10 releases the write protect corresponding to the rewritten guest code (S620).

  FIG. 29 is a flowchart of the frequency determination process in step S130 of FIG.

  First, the VMM 10 refers to the HW operation history table 73 and acquires an entry related to the HW operation executed immediately before. Then, the operation subject, the physical address of the guest code, and time information of the entry are acquired (S900).

  Next, the VMM 10 determines whether or not the operating subject of the HW operation executed immediately before is an application (AP) (S990). If it is determined that the operating subject is an AP, the process proceeds to step S940. If it is determined that the operating subject is not an AP, that is, the operating subject is an OS, the process proceeds to step S910.

  In step S910, the VMM 10 calculates the interval of the HW operation from the difference between the time information of the current HW operation and the time information of the previous HW operation.

  Next, the VMM 10 compares the calculated HW operation interval with the threshold acquired from the code conversion setting table 95. As a result of the comparison, it is determined whether or not the calculated HW operation interval is within the acquired threshold range (S920). If it is determined that the calculated HW operation interval is within the threshold, the process proceeds to step S930. On the other hand, if it is determined that the calculated HW operation interval exceeds the threshold, the process proceeds to step S940.

  In step S930, the VMM 10 adds the physical address of the guest code of the entry related to the previous HW operation to the HW operation frequency table 72. Then, the valid bit of the added entry is set to 1. As a result, the physical address of this guest code is set as the start point or intermediate point of the high-frequency portion.

  In step S940, the VMM 10 stores the entry related to the currently executed HW operation, that is, the operation subject, the instruction address of the guest code, and the time information in the HW operation history table 73.

  Next, the VMM 10 determines whether or not the instruction address of the guest code of the HW operation is included in the HW operation frequency table 72 for the currently executed HW operation (S950). If it is determined that it is included in the HW operation frequency table 72, the process proceeds to step S740. If it is determined that it is not included in the HW operation frequency table 72, the process proceeds to step S730.

  In step S740, the VMM 10 determines that the HW operation executed this time is the start point or the intermediate point of the high-frequency portion.

  In step S730, the VMM 10 determines that the HW operation executed this time is the start point or the intermediate point of the low frequency portion.

  FIG. 30 is a flowchart of the selection process of the next process in step S160 of FIG.

  The VMM 10 determines whether or not the guest 20 has been terminated, that is, whether or not the virtual machine 21 in which the guest 20 is running has been turned off (S1000). If it is determined that the virtual computer 21 has been powered off, the process advances to step S1010. Otherwise, the process proceeds to step S1120.

  In step S1010, the VMM 10 selects guest termination as the next process to be executed.

  In step S1120, the VMM 10 refers to the operation method table 82 and determines whether or not the current operation method is a code conversion method. If it is determined that the current operation method is the code conversion method, the process proceeds to step S1040. If it is determined that the current operation method is the VT method, the process proceeds to step S1060.

  In step S1040, the VMM 10 determines to apply the conversion code to the next process to be executed. Then, a conversion code search process for searching for a conversion code to be executed next is executed (S1130).

  On the other hand, in step S1060, the VMM 10 determines to apply the guest code to the process to be executed next.

  FIG. 31 is a flowchart of the conversion code search process in step S1130 of FIG.

  First, the VMM 10 searches the entry corresponding to the guest code next to the HW operation code processed this time with reference to the conversion code management table 35 (S1300).

  Next, the VMM 10 determines whether or not the corresponding entry exists (S1310). If it is determined that an entry exists, the process advances to step S1320. If it is determined that no entry exists, the process advances to step S1210.

  In step S1210, the VMM 10 determines whether there is a free space necessary for the memory capacity of the memory area for storing the conversion code. If it is determined that the necessary free space does not exist in the memory area, the process proceeds to step S1340. If it is determined that the necessary free space exists, the process proceeds to step S1350.

  In step S1340, the VMM 10 refers to the conversion code LRU list 36 and selects one element including the conversion code with the longest unused time. Then, the conversion code is discarded from the memory area by invalidating the physical address of the page belonging to the conversion code included in the selected element. Further, the conversion code information included in the selected element is deleted from the conversion code LRU list 36. Then, the process returns to step S1210. That is, the conversion code with the longest unused time is discarded from the memory area until the necessary free space can be secured.

  On the other hand, in step S1350, the VMM 10 generates a conversion code corresponding to a decodable code among the codes after the guest code to be executed next, and stores the generated code. The conversion code includes a shadow code and a promotion code. The shadow code is generated corresponding to the guest code. The shadow code includes a promotion code instead of the HW operation code included in the guest code. The promotion code includes a CPL decrement branch instruction for calling the emulation module. The conversion code generated in this step is used as the search result.

  Next, the VMM 10 stores the generated conversion code information in the conversion code management table 35. Further, information on the generated conversion code is added to the end of the conversion code LRU list 36 (S1360).

  Next, the VMM 10 sets write protection to a page including the guest code in order to detect rewriting of the guest code (S1370).

  On the other hand, in step S1320, the VMM 10 acquires the address of the conversion code to be executed next from the retrieved entry. The obtained conversion code is used as a search result.

  Next, the VMM 10 updates the conversion code LRU list 36 by changing the set of conversion codes corresponding to the entry to the latest (S1330).

  Note that the code conversion setting update processing in step S270 of FIG. 26 is the same as the flowchart of FIG. 14 of the first embodiment described above.

  As described above, in the virtual machine system according to the third embodiment of this invention, when the guest 20 requests execution of the guest code including the HW operation, the VMM 10 performs processing according to the execution interval of the HW operation. Change the way. That is, the HW operation is divided into two parts, a code conversion method with high execution efficiency is applied to a part where the execution interval is small (that is, execution frequency is high), and a part where the execution interval is large (that is, execution frequency is high) The VT method that consumes less memory is applied. By doing so, it is possible to perform emulation processing capable of achieving both high performance and memory saving.

  The present invention can be applied to a virtual machine system including an IPF equipped with a VT-i function and an x86 equipped with a VT-x function as a CPU.

1 is a block diagram of a physical computer that operates a virtual computer system according to a first embodiment of this invention. FIG. FIG. 2 is a block diagram illustrating main parts of software and hardware of a virtual computer system according to the first embodiment of this invention. It is explanatory drawing of the setting table | surface of the code conversion of the 1st and 3rd embodiment of this invention. It is a block diagram of the frequency judgment module of the 1st Embodiment of this invention. It is explanatory drawing of the HW operation frequency table | surface of the 1st Embodiment of this invention. It is explanatory drawing of the conversion code management table | surface of the 1st Embodiment of this invention. It is explanatory drawing of the conversion code LRU list | wrist of the 1st Embodiment of this invention. 3 is a flowchart of the operation of the VMM according to the first embodiment of this invention. It is a flowchart which shows the emulation process of the 1st Embodiment of this invention. It is a flowchart of the invalidation process of the conversion code of the 1st Embodiment of this invention. 3 is a flowchart of hardware operation frequency determination processing according to the first embodiment of this invention. It is a flowchart of the next process selection process after emulation of the 1st Embodiment of this invention. It is a flowchart of the application process of the code conversion system of the 1st Embodiment of this invention. It is a flowchart of the update process of the system switching condition of the 1st Embodiment of this invention. It is explanatory drawing of the setting table | surface of the code conversion of the 2nd Embodiment of this invention. It is explanatory drawing of the HW operation frequency table | surface of the 2nd Embodiment of this invention. It is a flowchart of the invalidation process of the conversion code of the 2nd Embodiment of this invention. It is a flowchart of the frequency judgment process of HW operation of the 2nd Embodiment of this invention. It is a block diagram of the principal part of the software and hardware of a virtual machine system of the 3rd Embodiment of this invention. It is a block diagram of the frequency judgment module of the 3rd Embodiment of this invention. It is explanatory drawing of the HW operation frequency table | surface of the 3rd Embodiment of this invention. It is explanatory drawing of the HW operation history table | surface of the 3rd Embodiment of this invention. It is a block diagram of the switching module of the 3rd Embodiment of this invention. It is explanatory drawing of the operation | movement system table | surface of the 3rd Embodiment of this invention. It is explanatory drawing of the conversion code management table | surface of the 3rd Embodiment of this invention. It is a flowchart of operation | movement of VMM of the 3rd Embodiment of this invention. It is a flowchart of the emulation process of the 3rd Embodiment of this invention. It is a flowchart of the invalidation process of the conversion code of the 3rd Embodiment of this invention. It is a flowchart of the frequency judgment process of the hardware operation of the 3rd Embodiment of this invention. It is a flowchart of the next process selection process after emulation of the 3rd Embodiment of this invention. It is a flowchart of the search process of the conversion code of the 3rd Embodiment of this invention.

Explanation of symbols

10 VMM
20 guest 30 code conversion module 31 shadow code 32 promotion code 35 conversion code management table 40 code generation module 50 exception event handler module 60 emulation module 70 frequency determination module 80 switching module 90 physical computer 91 storage device 92 console

Claims (28)

In a server device comprising one or more CPUs, a memory for storing data and programs, and an interface for transmitting and receiving data to and from the outside,
When the CPU executes a program stored in the memory, a virtual machine monitor that operates one or more virtual machines on which an operating system operates is executed,
The virtual machine monitor is
Emulation for emulating the operation based on an operation code for executing an operation on the hardware of the server device when an operation on the hardware of the server device is requested by the operating system or an application running on the operating system Modules,
An exception event handler module that calls the emulation module triggered by an exception event generated by the CPU by detecting an operation on the hardware of the server device;
A code management module that manages promotion codes that emulate operations on hardware of the server device by switching the operation mode of the CPU and calling the emulation module;
A frequency determination module that determines whether or not the frequency of the operation of the hardware of the server device is high as a result of comparison with a predetermined determination condition;
A switching module that determines whether to call the emulation module by the exception event handler module or to call the emulation module by executing the promotion code based on the determined frequency. Server device. The CPU has two operation modes, a hardware operation permission mode and a hardware operation prohibit mode, and generates an exception event when an operation on the hardware is detected when the operation mode is the hardware operation prohibit mode. To switch to hardware operation permission mode,
The promotion code includes an instruction to switch between the hardware operation permission mode and the hardware operation prohibition mode,
The virtual machine monitor corresponds to the operation code with a shadow code that emulates an operation on the hardware of the server device by calling the promotion code when the operation mode of the CPU is the hardware operation inhibition mode. Including the generation module
When the operation is requested with the operation mode of the CPU as the hardware operation prohibition mode, the switching module calls the shadow code if the frequency of the operation on the hardware of the server device is high. The server device according to claim 1, wherein a promotion code is executed, and the emulation module is called by the promotion code. The switching module is
When the frequency of the first operation on the hardware of the server device requested by the operating system or an application running on the operating system satisfies a predetermined condition,
When executing the second operation code in the vicinity of the instruction address space of the first operation code for executing the first operation, the promotion is performed instead of calling the emulation module by the exception event handler module. The server device according to claim 2, wherein the emulation module is called by executing a code. The switching module is
When the virtual machine monitor detects that the operating code for executing the operation has been changed by the operating system or an application running on the operating system,
Invalidate the shadow code corresponding to the changed operation code,
3. The emulation module is called by the exception event handler module instead of calling the emulation module by executing the shadow code when executing the modified operation code. Server device. The switching module is
When the memory capacity required to hold the shadow code and the promotion code is insufficient,
Selecting a shadow code having the longest non-executed period among the generated shadow codes, and deleting the selected shadow code and a promotion code associated with the selected shadow code from the memory;
3. The server device according to claim 2, wherein the emulation module is called by the exception event handler module instead of executing the deleted shadow code. The frequency determination module includes:
Holds frequency information that can identify the operations with high frequency,
When the operation is requested, it is determined whether or not the type of the requested operation is included in the held frequency information,
The server device according to claim 1, wherein when the type of the requested operation is included in the held frequency information, it is determined that the frequency of the requested operation is high. The frequency determination module includes:
The number of executions of the operation code belonging to a predetermined address range in the instruction address space of the operation code is held for each predetermined address range,
When the operation is requested, the number of executions of all operation codes included in the address range to which the operation code that executes the requested operation belongs is acquired, and the acquired number of executions exceeds a predetermined threshold The server device according to claim 1, wherein the server device determines that the frequency of the requested operation is high. The frequency determination module includes:
Holds time information that can identify when the operation is performed,
Time information when an operation code for executing the requested operation is executed when the operation is requested, and time information when an operation code for executing the requested operation is executed last time Calculate the interval,
The server device according to claim 1, wherein when the calculated interval is smaller than a predetermined threshold, it is determined that the frequency of the operation is high. An input unit for receiving the predetermined determination condition input by an administrator;
The server apparatus according to claim 1, further comprising: a storage device that stores the received predetermined determination condition. The CPU
By setting the VM bit to 0, transition to the hardware operation permission mode,
By setting the VM bit to a value other than 0, the hardware operation prohibit mode is entered,
The shadow code is executed with the VM bit set to non-zero,
The promotion code includes an instruction to change a setting of the VM bit;
The switching module is
Associating an address of an operation code for executing an operation on the hardware of the server device with an address storing the shadow code corresponding to the operation code;
When executing the emulation of the operation, the shadow code is executed by replacing the address of the operation code with the address of the shadow code based on the association, and the emulation module is executed by executing the shadow code. The server device according to claim 2, wherein the server device is called. The CPU
By setting the privilege level to 0 and the VMX root mode, transition to the hardware operation permission mode,
By setting the privilege level to a value other than 0 or VMX non-root mode, transition to the hardware operation prohibition mode,
The shadow code operates in a state where the privilege level is 3 and the VMX root mode is set.
The promotion code includes an instruction to change the privilege level;
The switching module is
Associating an address of an operation code for executing an operation on the hardware of the server device with an address storing the shadow code,
When executing the emulation of the operation, by executing the processing branch to the address where the shadow code is stored instead of the processing branch to the operation code based on the association, the shadow 3. The server apparatus according to claim 2, wherein a code is executed and the emulation module is called by executing the shadow code. The code generation unit includes the emulation code included in the emulation module in the promotion code,
The server apparatus according to claim 2, wherein an operation on hardware of the server apparatus is executed by executing the emulation code in addition to the promotion code. The code generation unit includes the promotion code in the shadow code,
3. The server apparatus according to claim 2, wherein an operation on the hardware of the server apparatus is emulated on the virtual machine monitor by executing the promotion code in addition to the shadow code. In a server device comprising one or more CPUs, a memory for storing data and programs, and an interface for transmitting and receiving data to and from the outside,
When the CPU executes a program stored in the memory, a virtual machine monitor that operates one or more virtual machines on which an operating system operates is executed,
The virtual machine monitor holds a frequency of execution for each operation on the hardware of the server apparatus requested by the operating system or an application running on the operating system. Control of a virtual machine that operates one or more virtual machines on which an operating system is operated in a server device having one or more CPUs, a memory for storing data and programs, and an interface for transmitting and receiving data to and from the outside A program,
When an operation on the hardware of the server device is requested by the operating system or an application running on the operating system, an exception event generated by the CPU is detected by detecting the operation on the hardware of the server device. A first procedure for emulating an operation on the hardware based on an operation code for executing an operation on the hardware of the server device;
A second procedure for switching an operation mode of the CPU and executing a promotion code for emulating an operation on hardware of the server device;
A third procedure for determining whether or not the frequency of the operation is high as a result of comparison with a predetermined determination condition;
A virtual procedure that causes the server device to execute a fourth procedure for determining whether to execute the first procedure or the second procedure based on the determined frequency. Computer control program. The CPU has two operation modes, a hardware operation permission mode and a hardware operation inhibition mode, and generates an exception event when an operation on the hardware is detected when the operation mode is the hardware operation inhibition mode. Switch to hardware operation permission mode,
In the first procedure, the CPU operation mode is set to the hardware operation prohibition mode, and when the operation is requested, the CPU is triggered by an exception event generated by the CPU by detecting the operation. Including a procedure for switching the operation mode to the hardware operation permission mode and emulating the operation,
In the second procedure, a shadow code that emulates an operation on the hardware of the server device is called the operation code by calling the promotion code when the operation mode of the CPU is the hardware operation prohibition mode. Including correspondingly generating steps,
If the operation frequency of the server apparatus is high when the operation is requested when the operation mode of the CPU is set to the hardware operation inhibition mode, the fourth procedure is performed. The virtual machine control program according to claim 15, wherein: The fourth procedure includes:
When the frequency of the first operation on the hardware of the server device requested by the operating system or an application running on the operating system satisfies a predetermined condition,
When executing the second operation code in the vicinity of the instruction address space of the first operation code for executing the first operation, the second procedure is executed instead of the first procedure. The virtual machine control program according to claim 15, wherein: A procedure for detecting that an operation code for executing the operation has been changed by the operating system or an application running on the operating system;
Further comprising a step of invalidating a shadow code corresponding to the changed operation code,
The virtual machine according to claim 16, wherein the fourth procedure executes the first procedure instead of the second procedure when executing the changed operation code. Control program. A procedure for detecting that the memory capacity necessary for holding the shadow code and the promotion code is insufficient;
A step of selecting a shadow code having the longest non-executed period from among the generated shadow codes, and deleting the selected shadow code and a promotion code associated with the shadow code from the memory; ,
The virtual machine according to claim 16, wherein when executing the deleted shadow code, the fourth procedure executes the first procedure instead of the second procedure. Control program. The third procedure is:
A procedure for determining whether the operation is requested by the operating system or an application running on the operating system;
A procedure for holding frequency information that can identify the operation with high frequency,
A procedure for determining whether or not the type of the requested operation is included in the held frequency information when an operation to the hardware of the server device is requested by the operating system;
The method according to claim 15, further comprising: a step of determining that the frequency of the requested operation is high when the type of the requested operation is included in the held frequency information. Virtual computer control program. The third procedure is:
A procedure for holding the number of executions of an operation code belonging to a predetermined address range in the instruction address space of the operation code for each of the predetermined address ranges;
When execution of an operation on the hardware of the server device is requested by the operating system or an application running on the operating system, all the addresses included in the address range to which an operation code that executes the requested operation belongs The procedure to get the number of executions of the operation code,
The virtual computer control program according to claim 15, further comprising: a step of determining that the frequency of the requested operation is high when the acquired number of executions exceeds a predetermined threshold value. The third procedure is:
A procedure for determining whether the operation is requested by the operating system or an application running on the operating system;
A procedure for holding time information that can specify when the operation is performed;
When an operation on the hardware of the server device is requested by the operating system, the time information when the operation code for executing the requested operation is executed and the operation code for executing the requested operation are previously executed. A procedure for calculating an interval with the time information when
The virtual computer control program according to claim 15, further comprising: determining that the frequency of the operation is high when the calculated interval is smaller than a predetermined threshold. A procedure for receiving the predetermined judgment condition input by an administrator;
The virtual computer control program according to claim 15, further comprising: a procedure for storing the input predetermined determination condition in a storage device. The first procedure includes a procedure for transitioning to the hardware operation permission mode by setting a VM bit of the CPU to 0 when an exception event occurs,
The second procedure includes a procedure of transitioning to the hardware operation permission mode by executing a vmsw instruction and setting the VM bit of the CPU to 0,
The fourth procedure includes:
By associating the instruction address of the operation code with the address where the shadow code corresponding to the operation code is stored, and replacing the address of the operation code with the address of the shadow code based on the association, Executing the second procedure instead of the first procedure;
The virtual machine control program according to claim 16, further comprising: a step of executing the first procedure instead of the second procedure by causing the operation code to be executed. The first procedure includes a procedure of transitioning to the hardware operation permission mode by setting the CPU to a VMX root mode by occurrence of a VMexit event,
The second procedure includes a procedure of transitioning to the hardware operation permission mode by executing a privilege level decrease branch instruction to set the privilege level of the CPU to 0.
The fourth procedure includes:
When executing emulation of the operation by executing a branch of processing to a virtual address in which the shadow code is stored instead of an instruction address of an operation code for executing an operation on the hardware of the server device, Executing the second procedure instead of the first procedure;
When the emulation of the operation is executed by executing a branch of processing to an instruction address of an operation code for executing an operation on the hardware of the server device, the first procedure is performed instead of the second procedure. The virtual machine control program according to claim 16, further comprising: The second procedure is:
Including an emulation code for emulating the operation in the promotion code;
The virtual machine control program according to claim 16, further comprising: a procedure for executing an emulation of an operation on hardware of the server device by executing the emulation code in addition to the promotion code. The second procedure is:
Include the promotion code in the shadow code,
17. The virtual machine control program according to claim 16, wherein an operation on the hardware of the server device is emulated by executing the promotion code in addition to the shadow code. Control of a virtual machine that operates one or more virtual machines on which an operating system is operated in a server device having one or more CPUs, a memory for storing data and programs, and an interface for transmitting and receiving data to and from the outside A program,
Control of a virtual machine, which causes the server device to execute a procedure that holds the frequency of execution for each operation on the hardware of the server device requested by the operating system or an application running on the operating system program.

Images