JP2013191089A - Exception processing method, program, and device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an exception processing method and the like supporting live migration so that original performance and functions of physical CPUs can be wastelessly used without the need for uniformizing an instruction set to an instruction set of the lowest order CPU even when different types of physical CPUs are present.SOLUTION: An instruction invalidated due to movement of a virtual machine between physical machines is detected, a valid operation code associated with an invalid operation code included in the detected instruction is acquired, and an instruction corresponding to the acquired valid operation code is executed.

Description

  The present invention relates to live migration in which a virtual machine dynamically moves between a plurality of physical machines.

  Live migration is to move an operating physical machine to another physical machine while operating the virtual machine. When a virtual machine moves, the CPU type of the movement source CPU (Central Processing Unit) and the movement destination CPU may be different, and the executable instruction set may be different. In such a case, an undefined instruction exception that does not occur in the source CPU occurs in the destination CPU.

  Conventionally, there has been known an exception processing technique in which an OS emulates an undefined instruction when an illegal instruction interrupt due to an undefined instruction occurs during program execution (Patent Document 1).

JP-A-2-231634

  However, in the prior art, an instruction that generates an undefined instruction exception needs to be predetermined. When live migration is executed in an environment in which physical machines with different CPUs are mixed, the destination physical machine is determined each time according to the status of each physical machine. Therefore, since the instruction that generates the undefined instruction exception is also different each time, the conventional technique cannot cope with it.

  Therefore, when performing live migration in an environment where physical machines with different installed CPUs coexist, start all CPUs in a backward compatible operation mode, and set all operable instruction sets. Unification by CPU is also performed. In this case, the instruction set that can be executed by the upper CPU is limited. For this reason, an extended instruction that can efficiently process complex processing is not executed, and the original performance and function of the CPU cannot be fully utilized.

  In one aspect, the present invention provides an exception handling method and the like corresponding to live migration so that the original performance and functions of physical CPUs can be used without waste even when different types of physical CPUs coexist. There is.

  The exception handling method disclosed in the present application detects an invalid instruction by moving a virtual machine between physical machines, and obtains a valid operation code associated with the invalid operation code included in the detected instruction. Acquire and execute an instruction corresponding to the acquired effective operation code.

  According to one aspect of the present application, even if different types of physical CPUs are mixed, the original performance and functions of the physical CPUs can be used without waste.

It is explanatory drawing which shows the outline | summary of an information processing system. It is a block diagram which shows the hardware group of a host. FIG. 3 is an explanatory diagram for illustrating a functional configuration of a host according to the first embodiment. It is a flowchart which shows the process sequence of a host when an undefined instruction exception generate | occur | produces. It is explanatory drawing which shows an example of the record layout of an opcode table. It is explanatory drawing which shows an example of the record layout of an emulation code table. FIG. 6 is an explanatory diagram for illustrating a functional configuration of a host according to a second embodiment. It is a flowchart which shows the process sequence of a host when an undefined instruction exception generate | occur | produces. 10 is a flowchart showing a processing procedure of back-end processing according to the third embodiment. 4 is a block diagram showing a configuration of a host according to Embodiments 1 to 3. FIG. 14 is a flowchart illustrating a processing procedure of instruction rewriting processing according to the fourth embodiment. FIG. 10 is an explanatory diagram for illustrating a functional configuration of a host and a management host according to a fifth embodiment. 10 is a flowchart illustrating a processing procedure of exception processing in a host and a management host according to a fifth embodiment. FIG. 20 is a block diagram illustrating a hardware group of an exception handling device according to a sixth embodiment. FIG. 20 is a block diagram illustrating a hardware group of a host according to a seventh embodiment.

Embodiment 1
Hereinafter, embodiments will be described with reference to the drawings. FIG. 1 is an explanatory diagram showing an outline of an information processing system. The information processing system includes a plurality of host computers 1 (hereinafter abbreviated as “host 1”) and host computers 2 connected to each other via a communication network N such as the Internet, a LAN (Local Area Network), and a public telephone network. (Hereinafter abbreviated as “host 2”), a management host computer 3 (hereinafter abbreviated as “management host 3”), and a shared disk 4. The host 1, the host 2, and the management host 3 are server computers, for example.

  The host 1 and the host 2 are computers that mainly provide services to users of the information processing system. The host 1 and the host 2 are configured to provide a virtual machine (VM: Virtual Machine). Each of the host 1 and the host 2 is physically one computer, but resources such as CPU and memory are logically divided by software called a hypervisor so that a plurality of independent virtual machines can operate. . Each virtual machine runs an OS, and an application program runs on each OS to provide services to users.

  The management host 3 mainly manages and controls a virtual environment configured by a hypervisor and virtual machines operating on the host 1 and the host 2. The management host 3 operates management / control middleware for managing / controlling the virtual environment.

  The shared disk 4 is a disk that can be accessed from any of the hosts 1, 2, and 3. Each host writes data necessary for its own operation to the shared disk 4 and reads the written data. Each virtual machine creates a VM image file on the shared disk and uses the shared disk 4 as a virtual disk.

  In the example shown in FIG. 1, three virtual machines VM1, VM2, and VM3 are operating on the host 1, and two virtual machines VM4 and VM5 are operating on the host 2. The virtual machine VM4 was operating on the host 1, but has been moved to the host 2 while operating. That is, the virtual machine VM4 is moved by live migration.

  FIG. 2 is a block diagram showing a hardware group of the host 1. Although only the host 1 will be described here, the host 2 has the same configuration. The host 1 includes a CPU 11 as a control unit, a RAM (Random Access Memory) 12, a storage unit 13, a communication unit 14, and the like. The CPU 11 is connected to each part of hardware via a bus. The CPU 11 controls each part of the hardware according to the control program stored in the storage unit 13. The RAM 12 is, for example, SRAM (Static RAM), DRAM (Dynamic RAM), flash memory, or the like. The RAM 12 also functions as a storage unit, and temporarily stores various data generated when the CPU 11 executes various programs.

  The storage unit 13 is, for example, a hard disk or a large-capacity flash memory. The storage unit 13 is one of locations where a hypervisor program and a VM image file can be stored. The hypervisor program is a program for realizing a virtual environment. A virtual machine runs on the hypervisor. An OS (Operating System) operates on the virtual machine, and an application program operates on the OS to provide a service to the user. The OS and application program operating on each virtual machine are written (installed) in each corresponding VM image file. A VM image file is a virtual disk connected to a virtual machine.

  The communication unit 14 is a LAN (Local Area Network) card, for example, and communicates with a user terminal, for example, another host such as the host 2, a management host, or the like.

  In the present embodiment, the host 1 includes a CPU that can operate the extended instruction set, but the host 2 includes a CPU that does not operate the extended instruction set. In the virtual machine VM4 that is live migrated from the host 1 to the host 2, an application using an extended instruction set is running, and therefore an undefined instruction exception occurs in the host 2. FIG. 3 is an explanatory diagram for illustrating a functional configuration of the host according to the first embodiment. FIG. 4 is a flowchart showing the processing procedure of the host 2 when an undefined instruction exception occurs.

The interrupt handler 25a is activated when an undefined instruction exception occurs, and performs exception processing. FIG. 5 is an explanatory diagram showing an example of a record layout of the operation code table 25b. The opcode table 25b includes an extended instruction sequence. The extended instruction string stores an opcode of an invalid instruction that can be executed by the CPU of the other host but cannot be executed by the CPU 21, that is, an instruction that generates an undefined instruction exception when executed. In FIG. 5, as an example, OP1, OP2,... Are stored as operation codes. The operation code matcher 25c acquires the instruction that caused the undefined instruction exception, and checks whether the operation code of the acquired instruction is stored in the operation code table 25b.
Although the operation code is also described as an operation code, it is mainly described as an operation code in this specification.

The emulation unit 25d emulates an instruction that is invalid in the CPU 21. FIG. 6 is an explanatory diagram showing an example of a record layout of the emulation code table 25e. The emulation code table 25e includes an extended instruction sequence, an argument sequence, and an alternative code sequence. The extended instruction sequence stores an opcode of an extended instruction that causes an undefined instruction exception. The argument string stores an argument for the extension instruction. The substitute code string stores substitute codes for emulating extension instructions. As an example, FIG. 6 shows that the instruction of the operation code OP1 takes arguments a and b, and the alternative codes are composed of three instructions whose operation codes are OP11, OP12, and OP13, respectively. The instruction of the operation code OP2 takes an argument a, and the alternative code is shown to be composed of two instructions which are operation codes OP21 and OP22.
The emulation unit 25d obtains an alternative code from the emulation code table 25e, and performs emulation of the instruction that caused the undefined instruction exception based on the replacement code.

  The register context save / restore area 25f is an area for saving the register state when an undefined instruction exception occurs. When an exception occurs, first, the CPU 21 automatically saves the state of various registers at that time in the register context save / restore area 25f. Thereafter, an interrupt is given to the hypervisor 25, and the interrupt handler 25a registered in the hypervisor 25 in charge of the corresponding exception performs exception processing. When the exception processing ends, the CPU 21 automatically restores the register state based on the register context save / restore area 25f, and returns control to the interrupt source program.

  Returning to FIG. 4, the processing by the interrupt handler 25a will be described. The virtual machine VM4 causes the CPU 21 to execute an extension instruction that is not supported by the CPU 21. An undefined instruction exception occurs in the CPU 21 (step S1). Accordingly, the CPU 21 generates an undefined instruction exception interrupt (step S2). In accordance with the setting of the hypervisor 25, the CPU 21 shifts the control to the interrupt handler 25a registered in advance as an interrupt handler for an undefined instruction exception (step S3).

  The CPU 21 functions as the operation code matcher 25c, and acquires the operation code of the instruction that caused the undefined instruction exception. The CPU 21 searches the operation code table 25b and checks whether the acquired operation code is included in the operation code table 25b (step S4). The CPU 21 checks whether or not the search is hit (step S5). If the search is hit (YES in step S5), the CPU 21 functions as the emulation unit 25d, and extracts an alternative code corresponding to the undefined instruction from the emulation code table 25e. The substitute code is composed of instructions (opcode and argument) effective in the CPU 21. Based on the alternative code, the CPU 21 generates a code that emulates an undefined instruction, and emulates the undefined instruction (step S6). The CPU 21 checks whether the emulated instruction has a return value (step S7). If there is a return value (YES in step S7), the return value is reflected in the register context save / restore area 25f (step S8). The CPU 21 returns control to the virtual machine VM4 (step S9), and ends the processing as an interrupt handler. If there is no return value (NO in step S7), the CPU 21 returns the control to the virtual machine VM4 (step S9) and ends the process as an interrupt handler. If the operation code of the instruction that caused the undefined instruction exception is searched and the search is not hit (NO in step S5), it is not caused by the execution of the extended instruction, so that the normal exception processing (step S10) is performed. ) To finish the process.

  As described above, in the first embodiment, when an undefined instruction exception caused by an extended instruction occurs in a host that does not support the extended instruction, the instruction that generated the exception is emulated and executed. Thereby, even if different types of physical CPUs are mixed, it is not necessary to align the instruction set with the instruction set of the lowest CPU, so that the original performance and functions of the physical CPU can be used without waste.

Embodiment 2
In the first embodiment, when an undefined instruction exception occurs, the instruction that caused the exception is emulated and executed. In the second embodiment, when the instruction that caused the exception is emulated, the instruction on the memory of the virtual machine VM4 or on the disk is rewritten to the instruction to emulate. As a result, all instructions that have once generated an undefined instruction exception are rewritten as instructions for emulation, and therefore an undefined instruction exception due to the same instruction does not occur again in the same virtual machine. As a result, the number of occurrences of exception processing is reduced, and more efficient processing is possible.

  FIG. 7 is an explanatory diagram for illustrating a functional configuration of a host according to the second embodiment. In the second embodiment, a binary patch unit 25g is added to the interrupt handler 25a. The binary patch unit 25g has a function of rewriting a binary code of a program running on the virtual machine. The binary patch unit 25g rewrites an instruction that generates an undefined instruction exception into an emulation code.

  FIG. 8 is a flowchart showing the processing procedure of the host when an undefined instruction exception occurs. Hereinafter, differences from the first embodiment will be mainly described. The CPU 21 functions as the operation code matcher 25c, and checks whether the operation code of the instruction that caused the undefined instruction exception is included in the operation code table 25b (step S4). The CPU 21 checks whether or not the search is hit (step S5). If the search is hit (YES in step S5), the CPU 21 functions as the emulation unit 25d, and extracts an alternative code corresponding to the undefined instruction from the emulation code table 25e. Based on the alternative code, the CPU 21 generates an emulation code that emulates an undefined instruction (step S11). The CPU 21 functions as the binary patch unit 25g, searches for the VM image file on the RAM 12, the storage unit 13, and the shared disk 4 managed by the virtual machine VM4 that has generated the undefined instruction exception (step S12), and is stored. All the instructions that have generated an undefined instruction exception included in the existing program code are rewritten to the corresponding emulation code (step S13). Specifically, the emulation code is written in an empty area of the RAM 12. A return instruction is provided at the end of the emulation code to return to the jump source. The instruction that caused the undefined instruction exception is replaced with a jump instruction, and the emulation code written in the empty area of the RAM 12 is executed.

  Next, the CPU 21 returns to the state before the occurrence of the undefined instruction exception (step S14). The CPU 21 returns control to the virtual machine (step S9). In the virtual machine, the state immediately before the occurrence of the undefined instruction exception is restored. The next instruction is executed. However, since the code has been rewritten by the above-described processing, the executed instruction is not an undefined instruction but a jump instruction, for example. The jump instruction calls a code that emulates an undefined instruction and emulates the undefined instruction.

  In the above description, after rewriting an instruction in which an undefined instruction exception has occurred, the state of the CPU 21 is returned to return to control of the virtual machine. However, as in the first embodiment, an undefined instruction exception is returned. It is also possible to rewrite the code in the backend process after emulating the generated instruction and returning the processing to the virtual machine.

  As described above, in the second embodiment, when an undefined instruction exception occurs, the VM image file on the RAM 12, the storage unit 13, and the shared disk 4 managed by the virtual machine that has generated the exception is searched. Rewrite the instruction that caused the exception. As a result, once the exception has occurred, the emulation code is executed and no exception is generated. Therefore, the overhead due to exception processing is reduced, and the processing can be performed more efficiently.

  The second embodiment is as described above, and the other parts are the same as those of the first embodiment. Therefore, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

Embodiment 3
In the second embodiment, the program code is rewritten only for the instruction that caused the undefined instruction exception. In the third embodiment, all instructions that cause an undefined instruction exception are targeted, and rewrite processing is performed at the back end. Processing in the back end here means that the processing is performed in the background and does not have a function of interacting with the user.

  The back-end process is a function that the hypervisor 25 has. The hypervisor monitors the load status of the CPU 21 and activates back-end processing when idling. FIG. 9 is a flowchart showing a processing procedure of back-end processing according to the third embodiment.

  The CPU 21 acquires an operation code that causes an undefined instruction exception from the operation code table (step S21). The opcode table referred to here is the same as that shown in FIG. The CPU 21 searches for the VM image file on the RAM 12, the storage unit 13, and the shared disk 4 managed by the virtual machine, and checks whether or not the stored program code includes the acquired operation code (step S22). The CPU 21 checks whether or not the search is hit (step S23). If the search is hit (YES in step S23), the CPU 21 acquires an alternative code corresponding to the acquired operation code from the emulation code table, and generates an emulation code (step S24). The emulation code table here is the same as that shown in FIG. The CPU 21 rewrites an instruction that causes an undefined instruction exception into an emulation code (step S25). This rewriting is the same as in the second embodiment.

  The CPU 21 determines whether all the operation codes have been searched (step S26). When the search is completed for all the operation codes (YES in step S26), the CPU 21 ends the process. If the search has not been completed for all the operation codes (NO in step S26), the CPU 21 returns the process to step S21, acquires the operation code of the instruction that causes an undefined instruction exception that has not been searched, and performs the process.

  As described above, in the third embodiment, since an instruction that generates an undefined instruction exception is rewritten by back-end processing, the frequency of occurrence of an undefined instruction exception is reduced, and the overhead due to exception processing is reduced. It becomes possible to perform processing more efficiently.

  The third embodiment is as described above, and the other parts are the same as in the first and second embodiments. Therefore, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

  FIG. 10 is a block diagram illustrating a configuration of the host 2 according to the first to third embodiments. When the CPU 21 executes a control program or the like, the host 2 operates as follows. The virtual machine execution unit 21a operates the virtual machine and provides a service to the user. The exception detection unit 21b detects the occurrence of an exception such as an undefined instruction exception. The opcode matcher 21c, the emulation unit 21d, and the binary patch unit 21g perform the above-described operations. The functions of the operation code table 25b, the emulation code table 25e, and the register context save / restore area 25f are as described above. The host 1 has the same configuration as the host 2.

Embodiment 4
In the first to third embodiments, after migration, the virtual machine emulates an instruction that caused an undefined instruction exception or rewrites an instruction that causes an undefined instruction exception. In the present embodiment, when migration is performed, an instruction that causes an undefined instruction exception is rewritten.

  FIG. 11 is a flowchart showing the procedure of the instruction rewriting process according to the fourth embodiment. This is processing when the virtual machine VM4 moves from the host 1 to the host 2.

  The management host 3 notifies the host 1 that the virtual machine VM4 is moved to the host 2 by live migration (step S31). The CPU 11 of the host 1 acquires a list of operation codes of instructions that are invalid in the host 2 (step S32). This list is the same as the operation code table 25b shown in FIG. The list is acquired from the destination host 2. The CPU 11 acquires an operation code to be processed from the list (step S33). The CPU 11 performs a search for whether or not the operation code to be processed is included in the memory image managed by the virtual machine VM4 (step S34). The CPU 11 verifies the search result (step S35). If the search is hit (YES in step S35), an emulation code is generated (step S36). The generation of the emulation code is the same as that described above, and is generated using a table similar to the emulation code table 25e shown in FIG. The table is obtained from the host 2 of the movement destination. The CPU 11 rewrites an invalid instruction with an emulation code (step S37). The CPU 11 determines whether or not all the operation codes of the invalid instructions have been searched (step S38). If all the operation codes have been searched (YES in step S38), the memory image of the virtual machine VM4 is transferred to the destination host 2 (step S39). The management host 3 executes live migration and moves the virtual machine VM4 from the host 1 to the host 2 (step S40). If the search is not hit (NO in step S35), the CPU 11 advances the process to step S38. If all the operation codes have not been searched (NO in step S38), the CPU 11 moves the process to step S33.

  In this embodiment, since an instruction that becomes invalid at the migration destination host is rewritten when a virtual machine image is transmitted during live migration, it is possible to prevent an undefined instruction exception from occurring after live migration.

  In the present embodiment, the virtual machine migration source host 1 rewrites the invalid instruction, but the migration destination host 2 may do it. In that case, the host 2 first receives the virtual machine image transmitted from the host 1. The host 2 performs processing similar to the processing from step S32 to S38 shown in FIG. 11 on the received virtual machine image, and rewrites the invalid instruction. When the rewriting is completed, the management host 3 is notified and migration may be executed.

  In the first to fourth embodiments described above, the operation code table 25b and the emulation code table 25e are held in the program of the interrupt handler 25a. When the interrupt handler 25a is loaded into the RAM, the operation code table 25b and the emulation code table 25e are loaded into the memory. When updating the contents of the operation code table 25b and the emulation code table 25e, it is necessary to update the program of the interrupt handler 25a, so that maintainability is lowered.

Modification 1
In the first modification, the operation code table 25b and the emulation code table 25e are not embedded in the program code, but are stored in a storage device such as a hard disk or a flash memory provided in each host. The interrupt handler 25a refers to the operation code table 25b and the emulation code table 25e stored in the storage device as necessary. In this case, the table can be updated simply by replacing the table on the storage device, so that maintenance is high. Further, there is an advantage that updating can be performed even when the interrupt handler 25a is operating.

Modification 2
In the second modification, the operation code table 25 b and the emulation code table 25 e are stored in the shared disk 4. Since the table can be centrally managed, the maintainability is further improved as compared with the first modification. However, when the access to the shared disk increases, the reading time becomes an overhead. Therefore, when loading the interrupt handler 25a, the operation code table 25b and the emulation code table 25e may be loaded on the memory and referenced on the memory. .

Modification 3
In the third modification, the operation code table 25b and the emulation code table 25e are stored in the storage device of the management host 3 and managed. Live migration is performed dynamically mainly according to the load status of each host. Therefore, the operation code table 25b and the emulation code table 25e need to correspond to all types of CPUs existing in the information system. Therefore, the number of records in the operation code table 25b increases in proportion to the number of CPU types. In the emulation code table 25e, as the number of CPU types increases, the number of combinations of the movement source CPU and the movement destination CPU increases, so the number of records increases. When the number of records in the table increases, the table search efficiency and the read efficiency decrease. Therefore, the operation code table 25b and the emulation code table 25e are stored in the storage device of the management host 3. At the time of live migration, necessary records in the operation code table 25b and the emulation code table 25e are extracted based on the types of the migration source CPU and the migration destination CPU, and passed to the interrupt handler 25a of the migration destination host. By doing so, the number of records in the operation code table 25b and the emulation code table 25e used by the destination host is minimized, and it is possible to prevent a decrease in search efficiency and read efficiency.

Embodiment 5
FIG. 12 is an explanatory diagram for illustrating functional configurations of the host 2 and the management host 3 according to the fifth embodiment. As in the first embodiment, the virtual machine VM4 is moved from the host 1 to the host 2 by live migration. FIG. 13 is a flowchart showing a processing procedure of exception processing in the host 2 and the management host 3 according to the fifth embodiment.

  In the fifth embodiment, as shown in FIG. 12, the operation code table 3b, the operation code matcher 3c, and the emulation code table 3e are provided in the management host 3 on which the management / control middleware operates. The management / control middleware may include the operation code table 3b, the operation code matcher 3c, and the emulation code table 3e. Further, the operation code table 3b or the emulation code table 3e may be stored in the shared disk 4.

  Processing procedures of the host 2 and the management host 3 will be described with reference to FIG. Due to the operation of the virtual machine VM4, an undefined instruction exception occurs in the CPU 21 (step S41). The CPU 21 generates an undefined instruction exception interrupt (step S42). The CPU 21 shifts control to the interrupt handler 25a according to the setting of the hypervisor 25 (step S43). The interrupt handler 25a notifies the management host 3 of the opcode of the instruction that caused the undefined instruction exception. The CPU 31 of the management host 3 executes the operation code matcher 3c and searches the operation code table 3b (step S44). The CPU 31 checks whether or not the search is hit (step S45). If the search is hit (YES in step S45), the CPU 31 refers to the emulation code table 3e and corresponds to the instruction that can be emulated by the CPU 21 of the host 2 (emulation code) corresponding to the instruction that caused the undefined instruction exception. ) And transmitted to the host 2 (step S46).

  The CPU 21 of the host 2 functions as the emulation unit 25d and executes the emulation code transmitted from the management host 3 (step S47). The CPU 21 determines whether there is a return value in the emulation code (step S48). If there is a return value (YES in step S48), the return value is reflected in the register context save / restore area 25f (step S49). The CPU 21 returns control to the virtual machine. If there is no return value (NO in step S48), the CPU 21 returns control to the virtual machine (step S50).

  If the opcode of the instruction that caused the undefined instruction exception does not hit the search of the opcode table (NO in step S45), the CPU 31 of the management host 3 notifies the host 2 to that effect, and the CPU 21 of the host 2 Normal exception processing is executed (step S51). The CPU 21 returns control to the virtual machine (step S50).

  In the fifth embodiment, the management host 3 includes an operation code table 3b, an operation code matcher 3c, and an emulation code table 3e. The management host 3 includes management / control middleware, and manages a movement source and a movement destination during live migration as a history. Accordingly, it is possible to efficiently search for an operation code of an instruction that has caused an undefined instruction exception and generate an emulation code for the instruction.

Embodiment 6
FIG. 14 is a block diagram illustrating a hardware group of the exception handling apparatus 5 according to the sixth embodiment. The exception processing apparatus 5 according to the sixth embodiment is configured with hardware different from that of the host 1, the host 2, and the management host 3 for performing an operation code search and an emulation code generation in exception processing. . In the following description, a case will be described in which the exception processing device 5 is configured by causing a general-purpose computer to read a computer program and causing the central processing unit of the computer to execute predetermined processing. However, the present invention is not limited thereto, and the exception handling device 5 may be configured as a device having dedicated hardware that performs an equivalent function.

  The exception processing device 5 includes a CPU 51, a RAM 52, a storage unit 53, and a communication unit 54. The CPU 51 controls each part of the hardware according to the control program 531 stored in the storage unit 53. The RAM 52 is, for example, SRAM, DRAM, flash memory or the like. The RAM 52 also functions as a storage unit, and temporarily stores various data generated when the CPU 51 executes various programs.

  The storage unit 53 is, for example, a hard disk or a large-capacity flash memory. The storage unit 53 stores a control program 531, an operation code table 532, and an emulation code table 533.

  The communication unit 54 is, for example, a LAN (Local Area Network) card or the like, and communicates with a host, a management host, and the like.

  The exception handling apparatus 5 according to the present embodiment is assumed to store the CPU type of each host in the storage unit 53. In addition, it is assumed that live migration information such as the migration source host name, the migration destination host name, and the identification information of the migrated virtual machine is received from the management host 3 and held as history information.

  The processing in the exception handling device 5 and each host is the same as in FIG. A brief description is given below. When an undefined instruction exception occurs due to the operation of the virtual machine, each host transmits an operation code of the instruction in which the exception has occurred to the exception processing device 5. The CPU 51 of the exception processing device 5 acquires the type of the transmission source CPU. The CPU 51 searches the operation code table 532 and checks whether the operation code received from the host is included in the operation code table 3b and is associated with the acquired CPU type. When the search is hit, the CPU 51 generates an emulation code suitable for the CPU type of the host based on the emulation code table 533 and transmits it to the host. If there is no hit in the search, the CPU 51 sends a message to that effect to the normal exception processing.

  In the present embodiment, the operation code search and emulation code generation are performed by the exception processing device 5, so that when performing undefined instruction exception processing, the load on each host and management host can be reduced. It becomes possible.

  In the above description, the operation code table 532 and the emulation code table 533 are provided in the exception processing device 5. However, the present invention is not limited thereto, and may be stored in the shared disk 4, for example.

  In the above description, the exception handling device 5 is assumed to be connected to the network N, but is not limited thereto. The exception processing device 5 may be configured as an expansion card that can be loaded into the expansion card slot of each host. In this case, the exception processing device 5 is mainly responsible for exception processing of the loaded host.

In Embodiments 1 to 6 and Modifications 1 to 3 described above, the operation code table may include an argument (operand) in addition to the operation code. By including an argument, it becomes possible to perform matching more strictly.
The opcode table and the emulation code table may be one table.

Embodiment 7
FIG. 15 is a block diagram illustrating a hardware group of the host 1 according to the seventh embodiment. In the first to fifth embodiments described above, a control program for operating the host 1 is stored in a reading unit 10A such as a disk drive in a CD-ROM, a DVD (Digital Versatile Disc) disk, a memory card, or a USB (Universal Serial Bus) memory. The portable recording medium 1 </ b> A may be read and stored in the storage unit 13. Further, a semiconductor memory 1B such as a flash memory storing the program may be mounted in the host 1. Further, the program can be downloaded from another server computer (not shown) connected via a communication network such as the Internet. The contents will be described below.

  The host 1 shown in FIG. 15 reads a program for executing the above-described various software processes from the portable recording medium 1A or the semiconductor memory 1B or downloads it from another server computer (not shown) via a communication network. . The program is installed as a control program, loaded into the RAM 12 and executed. Thereby, it functions as the host 1 described above.

  The seventh embodiment is as described above, and the other parts are the same as those of the first to fifth embodiments. Accordingly, the corresponding parts are denoted by the same reference numerals, and detailed description thereof is omitted.

Similarly to the host 1, the host 2 can be configured. Also, the management host 3 or the exception processing device 5 in the sixth embodiment may also read a control program from a portable recording medium and store it in a storage unit, or may be implemented as a semiconductor memory.
In addition to the control program, an operation code table or an emulation code table may be read from a portable recording medium and stored in a storage unit, or may be mounted as a semiconductor memory.

  It should be understood that the above-described embodiment is illustrative in all respects and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the meanings described above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

  The following additional notes are further disclosed regarding the embodiments including Examples 1 to 7 and Modifications 1 to 3 described above.

(Appendix 1)
Detects instructions that are invalidated because the virtual machine has moved between physical machines,
Obtain a valid operation code associated with an invalid operation code included in the detected instruction,
An exception handling method for executing an instruction corresponding to the obtained valid operation code.

(Appendix 2)
If the invalid instruction is detected,
Identify the virtual machine that executed the detected instruction,
Search the invalid operation code for the storage area reserved by the identified virtual machine,
The exception handling method according to attachment 1, wherein an invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 3)
For the storage area reserved by the specified virtual machine, search for an invalid operation code in the physical machine on which the virtual machine operates,
The exception handling method according to appendix 1 or 2, wherein an invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 4)
When a virtual machine moves between physical machines,
Search the invalid operation code for the memory image associated with the virtual machine,
The exception handling method according to any one of appendices 1 to 3, wherein an invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 5)
The exception handling method according to any one of appendices 1 to 4, wherein when acquiring the valid operation code, a table in which the invalid operation code and the valid operation code are associated with each other is used.

(Appendix 6)
When a virtual machine moves between physical machines, it detects an invalid instruction on the physical machine on which the virtual machine operates.
Obtain a valid operation code associated with the invalid operation code included in the detected instruction,
A program that causes the physical machine to execute a process that executes an instruction corresponding to the acquired valid operation code.

(Appendix 7)
If the invalid instruction is detected,
Identify the virtual machine that executed the detected instruction,
Search the invalid operation code for the storage area reserved by the identified virtual machine,
The program according to appendix 6, wherein the invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 8)
For the storage area reserved by the specified virtual machine, search for an invalid operation code in the physical machine on which the virtual machine operates,
The program according to appendix 6 or 7, wherein an invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 9)
Detects that virtual machines move between physical machines,
Search for invalid operation codes in the memory image associated with the virtual machine that detected the movement,
The program according to any one of appendices 6 to 8, wherein an invalid operation code included in the search result is rewritten to a valid operation code.

(Appendix 10)
The program according to any one of appendices 6 to 9, wherein a table in which invalid operation codes are associated with valid operation codes is used when acquiring the valid operation codes.

(Appendix 11)
A detection unit that detects an instruction invalidated by the movement of a virtual machine between physical machines,
An acquisition unit that acquires a valid operation code associated with the operation code included in the detected instruction;
A device having an output unit that outputs the acquired valid operation code.

DESCRIPTION OF SYMBOLS 1, 2 Host 21a Virtual machine execution part 21b Exception detection part 25 Hypervisor 25a Interrupt handler 25b Operation code table 25c Operation code matcher 25d Emulation part 25e Emulation code table 25f Register context save / restore area 3 Management host 4 Shared disk 5 Exception processing device

Claims (7)

Detects instructions that are invalidated because the virtual machine has moved between physical machines,
Obtain a valid operation code associated with an invalid operation code included in the detected instruction,
An exception handling method for executing an instruction corresponding to the obtained valid operation code. If the invalid instruction is detected,
Identify the virtual machine that executed the detected instruction,
Search the invalid operation code for the storage area reserved by the identified virtual machine,
The exception processing method according to claim 1, wherein an invalid operation code included in the search result is rewritten to a valid operation code. For the storage area reserved by the specified virtual machine, search for an invalid operation code in the physical machine on which the virtual machine operates,
The exception processing method according to claim 1, wherein an invalid operation code included in the search result is rewritten to a valid operation code. When a virtual machine moves between physical machines,
Search the invalid operation code for the memory image associated with the virtual machine,
The exception handling method according to any one of claims 1 to 3, wherein an invalid operation code included in the search result is rewritten to a valid operation code. The exception processing method according to any one of claims 1 to 4, wherein when acquiring the valid operation code, a table in which invalid operation codes and valid operation codes are associated with each other is used. When a virtual machine moves between physical machines, it detects an invalid instruction on the physical machine on which the virtual machine operates.
Obtain a valid operation code associated with the invalid operation code included in the detected instruction,
A program that causes the physical machine to execute a process that executes an instruction corresponding to the acquired valid operation code. A detection unit that detects an instruction invalidated by the movement of a virtual machine between physical machines,
An acquisition unit that acquires a valid operation code associated with the operation code included in the detected instruction;
A device having an output unit that outputs the acquired valid operation code.

Images