WO2017094132A1 - 計算機および計算機の制御方法 - Google Patents

計算機および計算機の制御方法 Download PDF

Info

Publication number
WO2017094132A1
WO2017094132A1 PCT/JP2015/083846 JP2015083846W WO2017094132A1 WO 2017094132 A1 WO2017094132 A1 WO 2017094132A1 JP 2015083846 W JP2015083846 W JP 2015083846W WO 2017094132 A1 WO2017094132 A1 WO 2017094132A1
Authority
WO
WIPO (PCT)
Prior art keywords
physical
mode
hypervisor
virtual
processor
Prior art date
Application number
PCT/JP2015/083846
Other languages
English (en)
French (fr)
Inventor
学豊 田口
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2015/083846 priority Critical patent/WO2017094132A1/ja
Publication of WO2017094132A1 publication Critical patent/WO2017094132A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt

Definitions

  • the present invention relates to a computer and a computer control method.
  • the virtual computer technology is a technology for operating a plurality of OSs on one physical server by performing processing for dividing physical computer resources by software called a hypervisor.
  • a plurality of virtual computers realized by allocating divided physical computer resources are called virtual machines.
  • An OS operating on the virtual machine is called a guest OS.
  • the guest OS and application programs that run on the guest OS are collectively referred to as guests.
  • a virtual machine has one or more virtual CPUs, and a guest can execute processing by assigning a physical CPU to the virtual CPU.
  • Guest operates the same on a virtual machine as in a physical computer environment.
  • an event that attempts to change the configuration of the system resource or an event whose operation depends on the configuration of the system resource requires appropriate emulation by the hypervisor and hardware.
  • Such an event is called a sensitive event.
  • Emulation needs to be done to handle sensitive events. Due to the overhead associated with this emulation, the performance in the virtual machine environment is lower than that in the non-virtual machine environment. Therefore, it is required to reduce this overhead as much as possible.
  • the virtualization support function provides two new operation modes as CPU operation modes. One is an operation mode in which a guest is operated, and is hereinafter referred to as a guest mode. The other is an operation mode in which the hypervisor is operated, and is hereinafter referred to as a host mode. When a sensitive event occurs during execution in the guest mode, the CPU operation mode automatically changes from the guest mode to the host mode, and the hypervisor performs appropriate emulation.
  • VM Exit the transition of the CPU operation mode from the guest mode to the host mode
  • VM Entry the transition from the host mode to the guest mode
  • VMCS Virtual Machine Control Structure
  • the hypervisor can control the VM Exit / VM Entry behavior of the virtual CPU by setting VMCS.
  • the process status information accompanying VM Exit / VM Entry is also transferred via VMCS.
  • External Interrupt Exiting that transmits I / O device interrupts to the guest OS.
  • External Interrupt Exiting is a VM Exit function when an interrupt arrives at the physical Local APIC.
  • the physical local APIC is hardware that controls an interrupt, one for each physical CPU.
  • an External Interrupt Exit function is used as follows.
  • the hypervisor enables the External Interrupt Exiting function of all virtual CPUs by setting the value of the “external Interrupt Exit” VM-execution control field of all VMCSs to 1. This allows the hypervisor to handle interrupts from all I / O devices. In the CPU that has received the interrupt and transitioned to the host mode, the hypervisor identifies the source of the interrupt and sends a virtual interrupt to the appropriate virtual CPU.
  • the virtual interrupt is a virtual interrupt for the virtual CPU realized by the cooperation of the software emulation by the hypervisor and the CPU virtualization support function. This virtual interrupt is transmitted to the virtual CPU via the virtual Local APIC that the virtual CPU has. In the virtual CPU that has received the virtual interrupt, an interrupt handler is executed through the guest Interrupt Descriptor Table (IDT).
  • IDT guest Interrupt Descriptor Table
  • the guest IDT is a table that exists for each virtual CPU and associates an interrupt handler of the guest OS with an interrupt that reaches the virtual CPU.
  • the guest OS sets a vector value for the interrupt, and sets an interrupt handler in the guest IDT entry corresponding to the vector value, thereby associating the interrupt with the interrupt handler.
  • the hypervisor In order to implement a method for causing a guest OS to directly process external interrupts in a virtual machine environment, it is necessary to allow the hypervisor to control any external interrupt processing method. It is an essential requirement that the hypervisor can control either the “method directly processed by the guest OS” or the “method emulated by the hypervisor”. This is because in the virtual machine environment, external interrupts that the hypervisor should intervene and external interrupts that can be directly executed by the guest are mixed, and the guest OS and hardware cannot distinguish these external interrupts.
  • the shadow IDT is a special IDT prepared in the kernel space of the guest OS by the hypervisor in the form of replacing the guest IDT.
  • the purpose of the shadow IDT is to process according to the type of external interrupt.
  • the process branches to an interrupt handler set by the guest OS, and the external interrupt is processed in the guest mode.
  • the guest mode is changed to the host mode, and the external interrupt is processed through emulation of the hypervisor.
  • the hypervisor sets the present bit to 0 only for entries corresponding to interrupts that require hypervisor intervention.
  • an external interrupt that requires hypervisor intervention reaches the physical CPU and the entry is accessed to execute the interrupt handler, the physical CPU raises an exception.
  • the hypervisor processes the interrupt.
  • Shadow IDT a new data structure (shadow IDT) is prepared for the hypervisor to control an arbitrary external interrupt processing method.
  • the hypervisor needs to maintain the shadow IDT when the guest OS rewrites the guest IDT or receives an IPI (Inter-processor interrupt). In this maintenance, processing costs are generated and mutual interference with other CPUs occurs.
  • IPI Inter-processor interrupt
  • the present invention provides a computer and a computer control method capable of processing an external interrupt with a guest program on a virtual processor or emulating with a hypervisor without using a shadow IDT. is there.
  • a computer is a computer, and includes a plurality of physical processors, a hypervisor realized by at least one physical processor among the plurality of physical processors, and at least one controlled by the hypervisor.
  • a virtual machine including at least one virtual processor and a guest program executed by the virtual processor, wherein the hypervisor has a first physical processor that processes an external interrupt in a first execution mode;
  • the second physical processor that processes external interrupts in the second execution mode can be generated from a plurality of physical processors, and the first physical processor can assign all received external interrupts to the first physical processor.
  • the hypervisor controls whether to any of the external interrupt destination of the first physical processor or a second physical processor.
  • the hypervisor includes at least one first physical processor that processes an external interrupt in the first execution mode and at least one second physical processor that processes an external interrupt in the second execution mode. Can be generated one by one. Then, the first physical processor processes all accepted external interrupts by the guest program on the virtual processor assigned to the first physical processor, and the second physical processor handles all accepted external interrupts by the hypervisor. Emulation processing can be performed.
  • FIG. 1 is a block diagram of a physical computer that operates a virtual computer system.
  • the block diagram which shows the logical structure of a physical computer and a virtual computer system.
  • the block diagram which shows the logical correspondence of the data structure of a memory area
  • FIG. 3 is an explanatory diagram illustrating an example in which a virtual machine is started from the initial state of the virtual machine system and an external interrupt execution mode is applied to each physical CPU.
  • the block diagram which shows a mode that an external interrupt is directly transmitted to a guest in emulation mode physical CPU.
  • the flowchart which shows the process which transmits an external interrupt to a guest in emulation mode physical CPU.
  • FIG. 3 is an explanatory diagram showing an example of dynamically switching an external interrupt execution mode in order to distribute the load of an interrupt process that requires hypervisor intervention when a physical CPU is degenerated.
  • FIG. 3 is an explanatory diagram showing an example of dynamically switching an external interrupt execution mode so that an interrupt destination that requires hypervisor intervention is periodically switched among a plurality of physical CPUs to distribute a load.
  • the flowchart which shows the process which notifies the opportunity for switching external interrupt execution mode The flowchart which shows the process which determines the switch from direct execution mode to emulation mode. 14 is a flowchart showing external interrupt execution mode switching processing in FIG. 13. The flowchart which shows the process which determines the switch from emulation mode to direct execution mode. 16 is a flowchart showing an external interrupt execution mode switching process in FIG.
  • the present embodiment discloses a technique that allows an external interrupt to be directly executed by a guest in a virtual machine environment.
  • the physical CPU 2 is divided into “a physical CPU (first physical processor) that accepts only external interrupts that can be directly executed by the guest and directly executes all the received external interrupts” and “a guest directly External interrupts other than executable external interrupts can also be accepted, and are broadly divided into two types: a physical CPU (second physical processor) that causes the hypervisor to emulate all accepted external interrupts.
  • a physical CPU first physical processor
  • second physical processor that causes the hypervisor to emulate all accepted external interrupts.
  • the hypervisor 10 can control whether the external interrupt is directly executed by the guest or the hypervisor is emulated by switching the destination of an arbitrary external interrupt between the first physical processor and the second physical processor. it can.
  • the hypervisor can dynamically switch between the above-described two types of physical CPU forms (first physical processor and second physical processor).
  • the load of external interrupt processing can be distributed, or the configuration of the virtual machine can be changed.
  • FIG. 1 shows the configuration of a physical computer 1 that operates a virtual computer system.
  • the physical computer 1 includes a plurality of CPUs 2 (may be referred to as processors), a north bridge 3, a memory 4, a south bridge 5, and an I / O device 6.
  • CPU 2 supports the virtualization support function.
  • An example of such a CPU 2 is an x86 (or IA-32) compatible CPU that supports Intel VT or AMD-V which is a virtualization support function.
  • Each CPU 2 has one physical Local APIC (Advanced Programmable Interrupt Controller) 7 and is connected to the North Bridge 3 via a bus 8A.
  • a memory 4 is connected to the north bridge 3 via a memory bus 8B.
  • An I / O device 6 PCI Express (registered trademark) device
  • a south bridge 5 is connected to the north bridge 3 via a bus 8C.
  • North bridge 3 has IOxAPIC (not shown).
  • An I / O device 6 is connected to the south bridge 5 via a bus 8D.
  • Examples of the I / O device 6 include a PCI (Peripheral Component) Interconnect (LPE) device, a LPC (Low Pin Count) device, and a legacy device.
  • PCI Peripheral Component
  • LPE Low Pin Count
  • FIG. 2 is a diagram showing a logical configuration of the physical computer 1 and the virtual computer system.
  • a computer employing a virtual computer system has a virtual machine 11 and a hypervisor 10 that controls the virtual machine 11.
  • the virtual machine 11 as a “virtual computer” has a virtual CPU 12 and a guest 13.
  • the guest 13 is a general term for a guest OS and software operating on the guest OS, and corresponds to a “guest program”.
  • the virtual CPU 12 has a virtual local APIC 14.
  • the virtual CPU 12 is a virtual CPU recognized by the guest 13, and the processing of the guest 13 is executed by allocating the physical CPU 2 to the virtual CPU 12.
  • the virtual local APIC 14 is a local APIC created virtually by the virtualization support function of the hypervisor 10 and the physical CPU 2 in order to make the virtual machine 11 recognize the interrupt.
  • a CPU-occupied virtual machine is one in which a specific physical CPU is exclusively allocated to each virtual CPU of the virtual machine.
  • a CPU shared virtual machine is one in which a plurality of physical CPUs are allocated in a time-sharing manner to the virtual CPU of the virtual machine.
  • the former is referred to as an exclusive allocation physical CPU 2 and the latter is referred to as a shared allocation physical CPU 2.
  • selecting a virtual CPU 12 to be executed at a certain time for a certain physical CPU 2 is called virtual CPU 12 dispatch.
  • FIG. 3 is an explanatory diagram showing a logical correspondence between the data structure used in the present embodiment and the physical computer 1 and the virtual computer system.
  • the virtual CPU management data D11 is data set for the hypervisor 10 to control the behavior of the virtual CPU 12.
  • the virtual CPU management data D11 is called VMCS (Virtual Machine Control) structure in Intel, and VMCB (Virtual Machine Control) block in AMD.
  • the virtual CPU management data D11 is prepared for each virtual CPU 12.
  • the virtual APIC register D12 is for virtualizing access to the physical APIC register D15 by the guest 13.
  • the virtual APIC register D15 is a data structure for managing virtual interrupts.
  • the virtual local APIC 14 is realized by appropriately managing the virtual APIC register D12 by the hypervisor 10 and hardware.
  • External interrupt execution mode identification data D13 is data for identifying what the external interrupt execution mode of the corresponding physical CPU 2 is.
  • the switching notification flag D14 is a flag for notifying the corresponding physical CPU 2 that an instruction to switch the external interrupt execution mode has been issued.
  • the physical APIC register D15 is a register for controlling an external interrupt that reaches the physical local APIC 7, or a register for controlling generation of IPI.
  • the physical APIC register D15 includes an EOI (End of Interrupt) register, an ISR (In Service Register), and the like.
  • the interrupt parameter D16 is a data structure for determining parameters such as a vector value and a destination CPU for each interrupt of the I / O device 6.
  • the guest OS and the hypervisor 10 control the interrupt of the I / O device 6 by rewriting the interrupt parameter D16.
  • the external interrupt execution mode identification data D13 and the switching notification flag D14 are data structures used in the second embodiment, and will be described in detail later.
  • an interrupt processing method when an external interrupt arrives while the physical CPU 2 is executing in the guest mode is referred to as an external interrupt execution method.
  • Two types of external interrupt execution methods are defined: a direct execution method and an emulation method.
  • the hypervisor 10 can control any external interrupt execution method to be one of the two external interrupt execution methods described above.
  • the physical CPU 2 remains in the guest mode even if an interrupt arrives at the physical local APIC 7.
  • the interrupt (external interrupt) is processed through the guest IDT 130 (see FIG. 5) of the virtual CPU 12 being executed on the physical CPU 2.
  • the guest 13 also directly notifies the end of external interrupt processing (issue of EOI) to the physical local APIC 7 without intervention of the hypervisor 10. That is, in the direct execution method, the external interrupt that reaches the physical CPU 2 is processed by the guest 13 without going through the hypervisor 10. Therefore, in the direct execution method, the physical CPU 2 does not need to shift from the guest mode to the host mode, and can process an external interrupt in a relatively short time.
  • the interrupt transmitted to the virtual CPU 12 is processed by the guest 13 when the virtual CPU 12 is dispatched to the physical CPU 2 in the guest mode.
  • the hypervisor 10 also intervenes when the guest 13 issues an EOI.
  • the hypervisor 10 converts the EOI issued to the virtual Local APIC 14 instead of the EOI directed to the physical Local APIC 7.
  • software processing by the hypervisor 10 is entered, so that the processing performance of the external interrupt is lower than that in the direct execution method.
  • the vector value of the external interrupt that reaches the physical CPU 2 is transmitted to the guest 13 as it is. Therefore, the external interrupt that can be processed by the direct execution method is an external interrupt that is assigned in advance to the guest IDT 130 of the virtual CPU 12 to which the external interrupt has arrived and is dispatched to the physical CPU 2.
  • the guest 13 (specifically, the guest OS) can preset an external interrupt in the guest IDT 130.
  • the virtual CPU 12 is set by the hypervisor 10 rewriting the virtual CPU management data D11. The following describes how the virtual CPU 12 is set to realize the direct execution method and the emulation method.
  • the virtual CPU 12 When the external interrupt execution method of the virtual CPU 12 is the emulation method, the virtual CPU 12 is set as follows. (Ea) When an external interrupt arrives in guest mode, transition to host mode occurs. (Eb) When accessing the physical EOI register in the guest mode, a transition to the host mode occurs. (Ec) Virtual interrupt handling is effective.
  • the virtual CPU 12 is set as follows. (Da) Even if an external interrupt arrives in the guest mode, the mode does not transit to the host mode. (Db) Even if a physical EOI register (not shown) is accessed in the guest mode, the host mode is not changed. (Dc) The handling of the virtual interrupt is invalid.
  • the physical EOI register is a register included in the physical APIC register D15.
  • an EOI is issued to the corresponding physical local APIC 7.
  • the virtual interrupt is a virtual interrupt transmitted to the virtual CPU 12 through the virtual Local APIC 14.
  • the virtual interrupt is generated by the hypervisor 10 and the hardware virtualization support function.
  • the setting method described above will be described by taking an Intel CPU as an example.
  • the VMCS “external interrupt exiting” VM-execution control field is set to 1. Conversely, 0 is set to disable this function.
  • the access to the physical APIC register D15 is usually set so as to cause a transition to the host mode.
  • the VMCS “use MSR bitmap” VM-execution control field is set to 1, and MSR bitmap is appropriately set.
  • MSR bitmap is appropriately set.
  • the external interrupt execution method can be set for each virtual CPU 12.
  • the external interrupt execution method is controlled in units of physical CPUs. That is, the external interrupt execution method of all the virtual CPUs 12 that can operate on one physical CPU 2 is unified to either the direct execution method or the emulation method.
  • the physical CPU 2 that processes all external interrupts by the direct execution method is called a direct execution mode physical CPU.
  • a physical CPU that processes all external interrupts in an emulation mode is called an emulation mode physical CPU.
  • These two external interrupt execution methods set in units of physical CPUs are called external interrupt execution modes.
  • the external interrupt execution mode of the physical CPU is an emulation mode physical CPU. . This is because such a physical CPU does not operate in the guest mode, and an interrupt reaching the physical CPU is always processed by the hypervisor.
  • Such a physical CPU exists when no virtual machine is activated, such as in the initial state of the virtual machine system.
  • the direct execution mode physical CPU corresponds to “a first physical processor that processes an external interrupt in the first execution mode”.
  • the emulation mode physical CPU corresponds to “a second physical processor that processes an external interrupt in the second execution mode”.
  • Whether the external interrupt is processed by one of the two types of external interrupt processing methods is determined by the external interrupt execution mode of the physical CPU 2 that is the destination of the interrupt.
  • the hypervisor 10 can control the destination CPU of any external interrupt. Furthermore, as will be described later in the embodiment, the hypervisor 10 can dynamically switch the external interrupt execution mode of any physical CPU 2.
  • the hypervisor 10 can control whether the destination CPU of any external interrupt is the direct execution mode physical CPU or the emulation mode physical CPU. Since at least one of the plurality of physical CPUs 2 operates in the host mode, the hypervisor 10 can determine the physical CPU 2 that is the destination of the external interrupt. That is, the hypervisor 10 can control a method for processing an external interrupt.
  • external interrupt execution mode identification data D13 is prepared in order to determine in which external interrupt execution mode each physical CPU 2 operates.
  • the external interrupt execution mode identification data D13 stores information for identifying the external interrupt execution mode currently being executed by each physical CPU 2.
  • the direct execution mode physical CPU is a physical CPU in which the external interrupt execution method of the virtual CPU to which the physical CPU is exclusively assigned is the direct execution method.
  • the physical CPU condition to which the direct execution mode is applicable is to satisfy the following two conditions.
  • a dedicated physical CPU A physical CPU that is not the destination of an external interrupt that requires hypervisor intervention.
  • the hypervisor traps it and the destination of the external interrupt is assigned to the virtual CPU.
  • the interrupt parameter is changed so as to be the direct execution mode physical CPU.
  • the vector value of the external interrupt that has reached the physical CPU in the direct execution mode is directly transmitted to the virtual machine as it is, without passing through the hypervisor 10 emulation. For this reason, the vector value of the external interrupt that reaches the physical local APIC 7 and the vector value assigned to the interrupt by the guest OS of the guest 13 must always match.
  • the hypervisor traps it and Set the same vector value as the interrupt parameter of the external interrupt
  • the emulation mode physical CPU refers to the following two.
  • a physical CPU whose external interrupt execution method of all virtual CPUs that can be assigned is an emulation method.
  • FIG. 4 shows an example in which the virtual machine is started up from the initial state of the virtual machine system and the external interrupt execution mode is applied to each physical CPU.
  • the emulation mode may be abbreviated as E mode and the direct execution mode may be abbreviated as D mode.
  • the physical CPU on which the virtual machine operates becomes a shared allocation physical CPU.
  • the shared physical CPU cannot apply the direct execution mode, the external interrupt processing method of the generated virtual CPU is the emulation method, and the physical CPU shared by the virtual CPU Emulation mode physical CPU is applied.
  • a physical CPU that does not accept external interrupts that require hypervisor intervention can apply the direct execution mode. Therefore, the external interrupt processing method of the virtual CPU that is generated for allocation to the physical CPU is the direct execution method.
  • the direct execution mode is applied to the physical CPU.
  • FIG. 5 shows a state in which an external interrupt that has reached the emulation mode physical CPU 2 being executed in the guest mode is transmitted to the guest 13 via the hypervisor 10.
  • the emulation mode may be abbreviated as E mode and the direct execution mode may be abbreviated as D mode.
  • the hypervisor 10 emulates the external interrupt to convert it into a virtual interrupt, and sends the virtual interrupt to the virtual Local APIC 14. In this way, an external interrupt to the emulation mode physical CPU is transmitted to the guest 13 via the hypervisor 10.
  • FIG. 6 is a flowchart showing details of the processing described in FIG. In the drawing, an interrupt may be abbreviated as INT.
  • the hypervisor 10 writes in the EOI register of the physical APIC register D15 and issues an EOI to the physical Local APIC 7 (S35). By issuing the EOI, the physical local APIC 7 detects the end of the external interrupt (S36).
  • the physical CPU 2 transitions to the guest mode, and the process moves from the hypervisor 10 to the guest 13 (S37).
  • the stored virtual interrupt is detected (S38), and the execution of the interrupt handler of the guest 13 is started (S39).
  • the interrupt handler accesses the EOI register of the physical APIC register D15 in order to execute the EOI.
  • the virtual CPU 12 is set so as to transition to the host mode when the physical EOI register is accessed. Therefore, the physical CPU 2 transitions from the guest mode to the host mode, and the process proceeds to the hypervisor 10 (S40).
  • the hypervisor 10 operates the virtual APIC register D12 instead of writing to the EOI register of the physical APIC register D15. By this emulation processing, the hypervisor 10 converts the EOI issue to the physical Local APIC 7 into the EOI issue to the virtual Local APIC 14 (S41).
  • the virtual local APIC 14 detects the end of the virtual interrupt (S42). Thereafter, the physical CPU 2 shifts to the guest mode (S43), and the processing shifts from the hypervisor 10 to the guest 13. When the processing of the guest 13 is resumed, the guest 13 ends the interrupt handler (S44). The guest 13 resumes the process interrupted by the external interrupt (S45).
  • FIG. 7 is an explanatory diagram showing a state in which an interrupt handler is directly executed through the guest IDT 130 without transitioning to the host mode when an external interrupt arrives at the direct execution mode physical CPU 2.
  • FIG. 8 is a flowchart showing each process in the guest 13, the hypervisor 10, the physical local APIC 7 and the virtual local APIC 14 in FIG.
  • the physical CPU 2 When an external interrupt arrives at the physical local APIC 7 (S51), the physical CPU 2 starts executing the interrupt handler through the guest IDT 130 in the guest mode (S52). As the vector value passed to the interrupt handler, the vector value of the external interrupt that reaches the physical local APIC 7 is used as it is.
  • the EOI issuance from the physical CPU 2 to the physical local APIC 7 is also performed in the guest mode (S53).
  • the physical local APIC 7 detects that the external interrupt has ended (S54). After issuing the EOI, the guest 13 ends the interrupt handler (S55), and resumes the process before the interrupt (S56).
  • the virtual CPU 12 operating on the direct execution mode physical CPU 2 does not handle virtual interrupts. Therefore, in the direct execution mode physical CPU, it is not necessary to adjust the priority of the external interrupt between the virtual local APIC 14 and the physical local APIC 7.
  • the direct mode physical CPU can entrust the control of all EOIs issued to the physical local APIC 7 to the guest 13 (guest OS).
  • RFLAGS.IF RFLAGS and EFLAGS are registers indicating the state of the program being executed. IF refers to the Interrupt Enable Flag bit of these registers.
  • Direct execution mode When the physical CPU is executing in host mode, always set RFLAGS.IF and EFLAGS.IF to 0 to hold all external interrupts received in host mode in the physical local APIC7. be able to. Then, when the direct execution mode physical CPU transits from the host mode to the guest mode and RFLAGS.IF and EFLAGS.IF become 1, the interrupt placed in the pending state is processed according to the flowchart of FIG.
  • the reason for setting as described above is that there is no way for the guest 13 to recognize an external interrupt that has reached the direct execution mode physical CPU 2 other than causing the guest 13 to directly process the external interrupt.
  • Each register is controlled as described above in order to cause the guest 13 to directly execute all external interrupts.
  • an external interrupt can be processed by the guest 13 on the virtual CPU or can be emulated by the hypervisor 10.
  • each physical CPU 2 is divided into a direct execution mode physical CPU and an emulation mode physical CPU. Furthermore, since the direct execution mode physical CPU of this embodiment causes the guest 13 to directly process all received external interrupts, the time required for interrupt processing can be reduced compared to the case where all interrupts are emulated, and the computer Performance can be improved.
  • the computer according to the present embodiment can improve performance while maintaining high reliability as compared with the prior art.
  • a second embodiment will be described with reference to FIGS.
  • the hypervisor 10 dynamically switches the external interrupt execution mode of the physical CPU 2 at an arbitrary timing.
  • the external interrupt execution mode is dynamically switched while the virtual machine is operating.
  • To dynamically switch the external interrupt execution mode is to switch the external interrupt execution mode of the physical CPU 2 between the direct execution mode and the emulation mode while the virtual machine 11 is operating.
  • the condition regarding the state of the physical CPU 2 for dynamically switching the external interrupt execution mode of an arbitrary physical CPU 2 from the emulation mode to the direct execution mode is that the physical CPU 2 is an occupied physical CPU 2.
  • the switching from the direct execution mode to the emulation mode there is no condition regarding the state of the physical CPU 2.
  • the adjustment of the external interrupt destined for the switching target physical CPU 2 is performed in the external interrupt execution mode switching process.
  • the first case is a case where the configuration of the virtual machine 11 or the I / O device 6 is dynamically changed. If the configuration of the virtual machine 11 or the I / O device 6 is changed, the necessity of intervention of the hypervisor 10 with respect to the external interrupt may change, and accordingly, the external interrupt execution mode needs to be changed accordingly. is there.
  • FIG. 9 shows an example in which the external interrupt execution mode of the physical CPU 2 is switched in accordance with the dynamic physical CPU allocation setting change of the virtual machine 11.
  • all of the three physical CPUs 2 (1) to 2 (3) are the shared allocation physical CPU 2 and operate as the emulation mode physical CPU 2.
  • two physical CPUs 2 (1) and 2 (2) of the three physical CPUs 2 operate as the direct execution mode physical CPU 2 because they are the occupied physical CPUs 2.
  • the virtual computer environment shown on the upper side of FIG. 9 and the virtual computer environment shown on the lower side can be switched to each other by dynamically switching the external interrupt execution mode.
  • the second case where the external interrupt execution mode must be dynamically switched will be described.
  • the second case is a case where an interrupt that requires the intervention of the hypervisor 10 is load-balanced.
  • FIG. 10 shows a case where some of the emulation mode physical CPUs 2 (3) and 2 (4) are disabled due to a failure or the like.
  • the emulation mode physical CPUs 2 (3) and 2 (4) accept an interrupt from the I / O device 6 to be converted to the virtual device 101.
  • an external interrupt assigned to the physical CPU 2 (3) is assigned to the other emulation mode physical CPU 2 (4). Then, the load on the other emulation mode physical CPU 2 (4) increases.
  • the external interrupt execution mode of one physical CPU 2 (2) of the direct execution mode physical CPUs 2 (1) and 2 (2) is switched to the emulation mode, and the emulation mode physical CPU 2 (2). Then, the destination of the external interrupt assigned to the emulation mode physical CPU 2 (3) that cannot be used due to a failure or the like is changed to a new emulation mode physical CPU 2 (2).
  • the interrupt destination of the I / O device 6 (2) to be converted to the virtual device 101 is periodically changed among a plurality of physical CPUs 2 (1) and 2 (2) to distribute the load. In this case, dynamic switching of the external interrupt execution mode is also used.
  • one physical CPU 2 (1) is a direct execution mode physical CPU
  • the other physical CPU 2 (2) is an emulation mode physical CPU.
  • the I / O device 6 (2) is a device to be converted to the virtual device 101, and an external interrupt from the I / O device 6 (2) is processed by the emulation mode physical CPU.
  • one physical CPU 2 (1) is switched from the direct execution mode to the emulation mode, and the other physical CPU 2 (2) is switched from the emulation mode to the direct execution mode.
  • the hypervisor 10 changes the external interrupt destination from the I / O device 6 (2) in accordance with the switching of the external interrupt execution mode.
  • the IPI is issued to an arbitrary physical CPU 2 to change to the host mode, thereby notifying the hypervisor 10 of the execution of a specific process.
  • the IPI does not cause the transition to the host mode and is directly transmitted to the guest 13, so the external interrupt execution mode switching trigger must be notified by a method other than the IPI.
  • a hardware virtualization support function is used in which the host mode is periodically changed after a certain time Tp has elapsed in the guest mode. This function is hereinafter referred to as a periodic host mode transition function.
  • the preemption timer function is a function of decrementing the count number designated in advance by the hypervisor 10 at regular intervals during the guest mode, and transitioning to the host mode when the count value becomes zero.
  • the physical CPU 2 can be periodically changed from the guest mode to the host mode.
  • NMI Non-Maskable Interrupt
  • the notification of the external interrupt execution mode switching trigger is performed by interrupting the processing of the guest 13 instead of the hypervisor 10.
  • the notification of the switching trigger interrupts the processing of the hypervisor 10 that depends on the external interrupt execution mode, switches the external interrupt execution mode, and causes inconsistency in the processing of the hypervisor 10. Can be prevented.
  • the transition interval Tp is preferably set as large as possible in order to minimize the performance degradation caused by the transition to the host mode periodically.
  • the switching process from the direct execution mode to the emulation mode will be described.
  • the process of switching to the emulation mode is performed only when the external interrupt process in the guest 13 is not suspended.
  • the case where the external interrupt processing of the guest 13 is interrupted is a case where the count of the preemption timer becomes 0 during the external interrupt processing of the guest 13 and transitions to the host mode.
  • the reason is as follows.
  • the guest 13 controls the external interrupt via the physical Local APIC 7 in the direct execution mode, but controls the external interrupt via the virtual Local APIC 14 in the emulation mode. Therefore, if the interrupt mode is interrupted and the mode is switched to the emulation mode, the EOI is issued to the virtual local APIC 14 instead of the physical local APIC 7 after the interrupt processing that has been interrupted is resumed. In this case, the external interrupt detected by the physical local APIC 7 does not end normally.
  • FIG. 12 is a flowchart showing a process for notifying the switching timing of the external interrupt execution mode.
  • FIG. 12 is used for both a notification of a switching opportunity from the direct execution mode to the emulation mode and a notification of a switching opportunity from the emulation mode to the direct execution mode.
  • the physical CPU 2 When the physical CPU 2 that notifies the switching trigger arrives at the switching timing of the external interrupt execution mode (S101: YES), the physical CPU 2 sets a switching trigger notification flag for switching the external interrupt execution mode of the physical CPU 2 to be switched (S102). .
  • the physical CPU 2 to be switched may be referred to as a switching target CPU 2.
  • FIG. 13 shows a switching determination process executed by the switching target CPU 2.
  • 13 and 14 show processing for switching the external interrupt execution mode of the switching target physical CPU 2 from the direct execution mode to the emulation mode.
  • the switching target CPU 2 sets the value of the counter Tp to the first switching time T1.
  • the counter Tp is a value set in the “VMX-preemption-timer value” field of VMCS.
  • the first switching time T1 is set to a relatively large value. This is because the frequency of transition from the guest mode to the host mode is suppressed to prevent a decrease in processing performance.
  • the hypervisor 10 checks whether or not the switching opportunity notification flag is set (S113).
  • the value of the switching trigger notification flag is 1, the description will be made assuming that the flag is set.
  • the switching trigger notification flag is not set (S113: NO), so the counter is reset to T1 (S114), transitions to the guest mode again (S115), and the process returns to the guest 13. In the case of this flow, the value of the counter Tp is returned to the first switching time T1.
  • the switching trigger notification flag is set (S113: YES)
  • the hypervisor 10 detects that the switching target CPU 2 is a switching trigger of the external interrupt execution mode.
  • the hypervisor 10 checks whether ISR (In Service Register) of the physical Local APIC 7 of the switching target CPU 2 is 0 (S116). This is to determine whether or not the interrupt process of the guest 13 operating on the virtual CPU 12 of the switching target CPU 2 is being interrupted.
  • ISR is one of the physical APIC registers D15 and is a register indicating an interrupt currently being processed.
  • the hypervisor 10 changes the counter Tp to the second switching time T2 (S119), and transitions to the guest mode (S115).
  • the second switching time T2 is set shorter than the first switching time T1 (T2 ⁇ T1).
  • the hypervisor Since the hypervisor detects that it is a trigger for switching the external interrupt execution mode, when the interrupt processing being interrupted is completed, the hypervisor transitions to the host mode as soon as possible and executes the external interrupt execution mode switching processing. is there.
  • FIG. 14 is a flowchart of processing for switching the external interrupt execution mode from the direct execution mode to the emulation mode. This process shows a detailed example of step S118 in FIG.
  • the interrupt handler of the hypervisor 10 is reset (S121).
  • the hypervisor 10 operates the virtual CPU management data D11 of the virtual CPU 12 to which the switching target CPU 2 is exclusively assigned, and changes the interrupt processing method of the virtual CPU 12 to the emulation method (S122).
  • the hypervisor 10 clears the switching notification flag D14 (S123), and transitions to the guest mode (S124).
  • RFLAGS.IF and EFLAGS.IF are always changed from the transition to the host mode for the external interrupt execution mode switching process until the termination of the external interrupt execution mode switching process and the transition to the guest mode again. Set to zero.
  • a preemption timer function can be used as in the case of switching from the direct execution mode to the emulation mode.
  • the emulation mode physical CPU 2 shifts to the host mode when an external interrupt arrives, it can also notify the switching trigger using IPI.
  • a counter Tp such as preemption timer is used. The reason is as follows.
  • RF RFALGS.IF and EFLAGS.IF must be 0 after the external interrupt execution mode switching process starts and before returning to guest mode. If the external interrupt execution mode switching process interrupts during the processing in the hypervisor 10, the processing of the hypervisor 10 is resumed after the switching process ends. In this case, it is difficult to ensure that RFLAGS.IF and EFLAGS.IF are zero. Therefore, in this embodiment, in order to ensure that the external interrupt execution mode switching process is always performed when transitioning from the guest mode to the host mode, the switching trigger is transmitted using the counter Tp. Note that the process of switching from the direct execution mode to the emulation mode is also performed only when the external interrupt process of the guest 13 is not suspended.
  • FIG. 15 is a flowchart showing a process for notifying a trigger for switching the external interrupt execution mode from the emulation mode to the direct execution mode.
  • the difference between the notification process for switching from the emulation mode to the direct execution mode shown in FIG. 15 and the process for notifying the trigger for switching from the direct execution mode to the emulation mode described in FIG. It is in the register that checks whether or not. In the process of FIG. 13, the ISR of the physical APIC register D15 is checked, but in the process of FIG. 15, the ISR of the virtual APIC register D12 is checked.
  • steps S131 to S135 and S137 to S139 shown in FIG. 15 are the same as steps S111 to S115 and S117 to S119 shown in FIG.
  • Step S136 in FIG. 15 differs from step S116 in FIG. 13 only in the register to be checked. Accordingly, further description of the processing of FIG. 15 is omitted.
  • the external interrupt execution mode switching process in step S138 will be described later.
  • FIG. 16 is a flowchart of processing for switching the external interrupt execution mode from the emulation mode to the direct execution mode. This process shows a detailed example of step S138 in FIG.
  • the hypervisor 10 changes the interrupt parameter D16 so that external interrupts other than the external interrupt that can be directly executed by the physical CPU 2 among the external interrupts destined for the switching target CPU 2 are destined for the other emulation mode physical CPU 2. (S141). That is, the external interrupt destination that can be processed by the other emulation mode physical CPU 2 among the external interrupts received by the switching target CPU 2 is changed.
  • the hypervisor 10 is configured so that all the interrupts that can be directly executed by the switching target CPU 2 among the external interrupts destined for the other physical CPU 2 (external interrupts of the I / O device 6) are destined for the switching target CPU 2.
  • the interrupt parameter D16 is changed (S142).
  • the emulation processing for the virtual device 101 changes the setting of the hypervisor 10 so as to be IPI to the switching target CPU 2.
  • the external interrupt directly executable by the switching target CPU 2 is an external interrupt assigned by the guest OS to the IDT of the virtual CPU 12 to which the switching target physical CPU 2 is exclusively assigned.
  • the hypervisor 10 changes the interrupt parameter D16 so that the vector value of the external interrupt destined for the switching target CPU 2 is the same as the vector value set for each interrupt by the guest OS (S143).
  • the hypervisor 10 checks whether there is an interrupt pending in the physical local APIC 7 of the switching target CPU 2 among the interrupts whose destination has been changed to another physical CPU 2 in step S141 (S144).
  • Interrupts pending in the physical local APIC 7 of the switching target CPU 2 are discarded as invalid interrupts after switching the switching target CPU 2 to the direct execution mode. Therefore, the hypervisor 10 prevents the pending interrupt in the CPU 2 before changing the destination from being discarded without being processed, and the IPI having the changed vector value is assigned to the physical CPU 2 after changing the destination. Is issued (S145).
  • the hypervisor 10 checks whether there is a virtual interrupt pending in the virtual local APIC 14 (S146). After the switching target CPU 2 is switched to the direct execution mode, the interrupt control using the virtual Local APIC 14 is not performed, so that the interrupt suspended in the virtual Local APIC 14 is not recognized by the guest 13 (guest OS).
  • the hypervisor 10 reissues Self-IPI having the same vector value as the pending interrupt (S147). By reissuing the IPI, the suspension destination of the interrupt is converted from the virtual local APIC 14 to the physical local APIC 7.
  • RFLAGS.IF and EFLAGS.IF are set to 0. Therefore, the interrupt received by Self-IPI is not processed at that time, and is pending to the physical local APIC7 until it changes to the guest mode. Will remain.
  • the hypervisor 10 operates the virtual CPU management data D11 of the virtual CPU 12 to which the switching target CPU 2 is exclusively assigned, and changes the interrupt processing method to the direct execution method (S148). Finally, the hypervisor 10 clears the external interrupt mode switching notification flag D14 (S149), and transitions to the guest mode (S150).
  • This embodiment which is configured in this way, also has the same function and effect as the first embodiment. Furthermore, in this embodiment, the external interrupt execution mode of any physical CPU 2 can be dynamically changed between the direct execution mode and the emulation mode. Therefore, in this embodiment, it is possible to deal with a failure occurring in the physical CPU 2 and to distribute the load on the physical CPU 2. Thereby, usability is improved as compared with the first embodiment.
  • each of the above-described embodiments is a description of the present invention in an easy-to-understand manner, and the present invention does not have to have all the configurations described in the embodiments. At least a part of the configuration described in the embodiment can be changed to another configuration or deleted. Furthermore, a new configuration can be added to the embodiment.
  • Some or all of the functions and processes described in the embodiments may be realized as a hardware circuit or as software.
  • the computer program and various data may be stored not only in the storage device in the computer but also in a storage device outside the computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

本発明の計算機１は、複数の物理プロセッサ２と、ハイパバイザ１０と、ハイパバイザにより制御される仮想計算機１１を備える。仮想計算機は、仮想プロセッサ１２と、ゲストプログラム１３とを含む。ハイパバイザは、第１実行モードで外部割込みを処理する第１物理プロセッサと、第２実行モードで外部割込みを処理する第２物理プロセッサとを生成する。第１物理プロセッサは、受け付けた全ての外部割込みを、第１物理プロセッサに割り当てられた仮想プロセッサ上のゲストプログラムにより処理させる。第２物理プロセッサは、受け付けた全ての外部割込みを、ハイパバイザでエミュレーション処理させる。ハイパバイザは、外部割込みの宛先を第１物理プロセッサまたは第２物理プロセッサのいずれにするかを制御する。

Description

計算機および計算機の制御方法
　本発明は、計算機および計算機の制御方法に関する。
　サーバの運用コストおよび複雑さを低減するために、複数サーバを一台のサーバにまとめる仮想計算機技術が注目されている。仮想計算機技術とは、ハイパバイザと呼ばれるソフトウェアが、物理計算機資源を分割する処理を行うことで、一つの物理サーバ上で複数のＯＳを稼働させる技術である。
　分割された物理計算機資源が割り当てられることで実現される、複数の仮想的な計算機を仮想マシンと呼ぶ。仮想マシン上で動作するＯＳをゲストＯＳと呼ぶ。ゲストＯＳおよびゲストＯＳ上で動作するアプリケーションプログラムを総称して、ゲストと呼ぶ。仮想マシンは、１つ以上の仮想ＣＰＵを有し、仮想ＣＰＵに対して物理ＣＰＵが割り当てられることで、ゲストは処理を実行することができる。
　ゲストは、仮想マシン上においても、物理計算機環境にある場合と同じ動作をする。しかし、システム資源の構成を変えようとするイベントやシステム資源の構成に動作が依存しているイベントについては、ハイパバイザおよびハードウェアによる適切なエミュレーションが必要となる。このようなイベントをセンシティブなイベントと呼ぶ。センシティブなイベントを処理するためにエミュレーションを行う必要がある。このエミュレーションに伴うオーバーヘッドによって、仮想計算機環境では、非仮想計算機環境よりも性能が低下する。そのため、このオーバーヘッドをできるだけ低減することが求められる。
　エミュレーションを支援するハードウェア機能は、従来、メインフレームのような高価な計算機のみに搭載されていた。しかし、近年では仮想化技術の普及に伴い、安価でより一般的なＣＰＵにおいても、このような機能が搭載されつつある。例えば、Ｉｎｔｅｌ（登録商標）はＩｎｔｅｌ ＶＴ（Virtualization Technology）という名称で、ＡＭＤ（登録商標）はＡＭＤ－Ｖという名称で、ＣＰＵによる仮想化支援機能を提供している。
　仮想化支援機能は、ＣＰＵの動作モードとして、新たに２つの動作モードを用意している。１つは、ゲストを動作させる動作モードであり、以下ではゲストモードと呼ぶ。もう１つは、ハイパバイザを動作させる動作モードであり、以下ではホストモードと呼ぶ。ゲストモードで実行中にセンシティブなイベントが発生すると、ＣＰＵの動作モードは自動的にゲストモードからホストモードへ遷移し、ハイパバイザが適切なエミュレーションを行う。
　以下、Ｉｎｔｅｌ ＶＴを例として、ＣＰＵによる仮想化支援機能について説明する。Ｉｎｔｅｌ ＶＴでは、ＣＰＵの動作モードがゲストモードからホストモードに遷移することを”VM Exit”といい、逆にホストモードからゲストモードに遷移することを”VM Entry”という。仮想ＣＰＵは、それぞれＶＭＣＳ（Virtual Machine Control Structure）というデータ構造を持つ。
　ハイパバイザは、ＶＭＣＳを設定することで、仮想ＣＰＵのVM Exit/VM Entryの挙動を制御することができる。VM Exit/VM Entryに伴うプロセス状態の情報の受け渡しも、ＶＭＣＳを介して行う。
　仮想化支援機能の１つに、ゲストＯＳにＩ／Ｏデバイスの割込みを伝達するための、External Interrupt Exitingという機能がある。External Interrupt Exitingとは、物理Local APICに割込みが届いたことを契機にVM Exitする機能である。物理Local APICとは、物理ＣＰＵごとに１つ存在する、割込みを制御するハードウェアである。ゲストＯＳへのＩ／Ｏデバイス割込み伝達の従来技術では、External Interrupt Exiting機能を、以下のように用いている。
　ハイパバイザは、全てのＶＭＣＳの”external Interrupt Exiting” VM-execution controlフィールドの値を１とすることで、全ての仮想ＣＰＵのExternal Interrupt Exiting機能を有効にする。これにより、ハイパバイザは、全てのＩ／Ｏデバイスからの割込みを処理することができる。割込みを受け取ってホストモードに遷移したＣＰＵでは、ハイパバイザがその割込みの発生源を特定し、適切な仮想ＣＰＵに仮想割込みを送る。
　仮想割込みとは、ハイパバイザによるソフトウェアエミュレーションとＣＰＵの仮想化支援機能との協働によって実現する、仮想ＣＰＵに対する仮想的な割込みである。この仮想割込みは、仮想ＣＰＵが有する仮想Local APICを介して、仮想ＣＰＵに伝達される。仮想割込みを受け取った仮想ＣＰＵでは、ゲストInterrupt Descriptor Table（IDT）を通して、割込みハンドラが実行される。
　ゲストＩＤＴとは、仮想ＣＰＵごとに１つ存在し、その仮想ＣＰＵに届いた割込みにゲストＯＳの割込みハンドラを関連付けるためのテーブルである。ゲストＯＳが、割込みに対してベクタ値を設定し、そのベクタ値に対応するゲストＩＤＴのエントリに割込みハンドラを設定することで、割込みと割込みハンドラとの関連付けが行われる。
　以上の従来技術を用いた外部割込み処理では、VM Exit、ハイパバイザによるエミュレーション、VM Entryという仮想化特有の処理を行う必要があるため、非仮想化環境に比べて大きな性能低下が生じる。そこで、ハイパバイザの介入なしに、ゲストＯＳに外部割込みを直接処理させる方法が考えられている。
　ゲストＯＳに外部割込みを直接処理させる方法を仮想計算機環境で実現するためには、任意の外部割込みの処理方式をハイパバイザが制御できるようにする必要がある。ハイパバイザが、「ゲストＯＳが直接処理する方式」または「ハイパバイザがエミュレーションする方式」のいずれかを制御できることが必須要件となる。なぜなら、仮想計算機環境では、必ず、ハイパバイザが介入すべき外部割込みとゲストが直接実行できる外部割込みとが混在しており、かつ、それらの外部割込みをゲストＯＳおよびハードウェアは判別できないからである。
　上記を実現する方法として、例えば、特許文献１の技術では、シャドウＩＤＴを用いた方法が提案されている。シャドウＩＤＴとは、ゲストＩＤＴを代替する形で、ハイパバイザがゲストＯＳのカーネル空間に用意した特別なＩＤＴである。シャドウＩＤＴの目的は、外部割込みの種類に応じて処理することにある。ハイパバイザの介入が必要ない割込みが届いた場合は、ゲストＯＳが設定した割込みハンドラに分岐させて、ゲストモードのままで、その外部割込みを処理する。これに対し、ハイパバイザの介入が必要な割込みが届いた場合は、ゲストモードからホストモードに遷移して、ハイパバイザのエミュレーションを介してその外部割込みを処理する。
　シャドウＩＤＴを用いることで、ハイパバイザの介入が必要な割込みが届いたときに、ホストモードに遷移してハイパバイザのエミュレーションを行う方法は、以下のように実現されている。
　ハイパバイザは、シャドウＩＤＴにおいて、ハイパバイザの介入が必要な割込みに対応したエントリだけPresentビットを0に設定する。物理ＣＰＵにハイパバイザの介入が必要な外部割込みが届き、割込みハンドラを実行するためにそのエントリにアクセスすると、物理ＣＰＵは例外を起こす。例外が発生すると強制的にホストモードに遷移する仮想化支援機能を利用することで、その割込みをハイパバイザが処理する。
United States Patent 8892802
"Intel 64 and IA-32 Architectures Software Developer’s Manual combined volumes 3A, 3B, 3C: System programming guide"、[online]、20１5年6月、Intel Corp、[平成27年8月１日検索]、インターネットhttp://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf
　特許文献１に記載の技術では、任意の外部割込みの処理方式をハイパバイザが制御するための、新たなデータ構造（シャドウＩＤＴ）を用意している。しかし、ハイパバイザは、ゲストＯＳによるゲストＩＤＴの書き換え時や、ＩＰＩ（Inter-processor interrupt）の受信時などの契機に、シャドウＩＤＴをメンテナンスする必要がある。このメンテナンスにおいて、処理コストが発生したり、他ＣＰＵとの相互干渉が発生したりする。
　そこで、本発明では、シャドウＩＤＴを用いることなく、外部割込みを、仮想プロセッサ上のゲストプログラムで処理したり、あるいはハイパバイザでエミュレーション処理したりすることができる計算機および計算機の制御方法を提供することにある。
　上記課題を解決すべく、本発明に従う計算機は、計算機であって、複数の物理プロセッサと、複数の物理プロセッサのうちの少なくとも一つの物理プロセッサにより実現されるハイパバイザと、ハイパバイザにより制御される少なくとも一つの仮想計算機であって、少なくとも一つの仮想プロセッサと、仮想プロセッサにより実行されるゲストプログラムとを含む仮想計算機と、を備え、ハイパバイザは、第１実行モードで外部割込みを処理する第１物理プロセッサと、第２実行モードで外部割込みを処理する第２物理プロセッサとを、複数の物理プロセッサから生成することができ、第１物理プロセッサは、受け付けた全ての外部割込みを、第１物理プロセッサに割り当てられた仮想プロセッサ上のゲストプログラムにより処理させ、第２物理プロセッサは、受け付けた全ての外部割込みを、ハイパバイザでエミュレーション処理させ、ハイパバイザは、外部割込みの宛先を第１物理プロセッサまたは第２物理プロセッサのいずれにするかを制御する。
　本発明によれば、ハイパバイザは、第１実行モードで外部割込みを処理する第１物理プロセッサと、第２実行モードで外部割込みを処理する第２物理プロセッサとを、複数の物理プロセッサから少なくとも１つずつ生成することができる。そして、第１物理プロセッサは、受け付けた全ての外部割込みを、第１物理プロセッサに割り当てられた仮想プロセッサ上のゲストプログラムにより処理させ、第２物理プロセッサは、受け付けた全ての外部割込みを、ハイパバイザでエミュレーション処理させることができる。
仮想計算機システムを動作させる物理計算機のブロック図。 物理計算機および仮想計算機システムの論理的構成を示すブロック図。 メモリ領域のデータ構造と、物理計算機および仮想計算機システムとの論理的な対応関係を示すブロック図。 仮想計算機システムの初期状態時から、仮想マシンを立ち上げて、外部割込み実行モードを各物理ＣＰＵに適用する例を示す説明図。 エミュレーションモード物理ＣＰＵにおける、ゲストへ外部割込みを直接伝達する様子を示すブロック図。 エミュレーションモード物理ＣＰＵにおける、ゲストへ外部割込みを伝達する処理を示すフローチャート。 直接実行モード物理ＣＰＵにおける、ゲストへ外部割込みを伝達する様子を示すブロック図。 直接実行モード物理ＣＰＵにおける、ゲストへ外部割込みを伝達する処理を示すフローチャート。 第２実施例に係り、仮想マシンの構成変更に伴って、外部割込み実行モードを動的に切り替える例を示す説明図。 物理ＣＰＵの縮退時に、ハイパバイザの介入が必要となる割込みの処理を負荷分散させるべく、外部割込み実行モードを動的に切り替える例を示す説明図。 ハイパバイザの介入が必要となる割込みの宛先を、複数の物理ＣＰＵ間で定期的に切り替えて負荷分散する場合すべく、外部割込み実行モードを動的に切り替える例を示す説明図。 外部割込み実行モードを切り替えるための契機を通知する処理を示すフローチャート。 直接実行モードからエミュレーションモードへの切替を判定する処理を示すフローチャート。 図１３中の外部割込み実行モード切替処理を示すフローチャート。 エミュレーションモードから直接実行モードへの切替を判定する処理を示すフローチャート。 図１５中の外部割込み実行モード切替処理を示すフローチャート。
　以下、図面に基づいて、本発明の実施の形態を説明する。以下に述べるように、本実施形態は、仮想計算機環境において、外部割込みをゲストで直接実行することのできる技術を開示する。
　本実施形態では、物理ＣＰＵ２を、「ゲストが直接実行可能な外部割込みのみを受け付けて、受け付けた外部割込みの全てをゲストに直接実行させる物理ＣＰＵ（第１物理プロセッサ）」と、「ゲストが直接実行可能な外部割込み以外の外部割込みも受け付け可能であり、受け付けた外部割込みの全てをハイパバイザにエミュレーションさせる物理ＣＰＵ（第２物理プロセッサ）」との２つに大別する。
　ハイパバイザ１０は、任意の外部割込みの宛先を、第１物理プロセッサと第２物理プロセッサの間で切り替えることによって、その外部割込みをゲストに直接実行させるか、ハイパバイザにエミュレーションさせるかを、制御することができる。
　さらに本実施形態では、ハイパバイザは、上記の２種類の物理ＣＰＵ形態（第１物理プロセッサ、第２物理プロセッサ）を、動的に切り替えることができる。これにより、本形態では、外部割込み処理の負荷を分散したり、仮想計算機の構成を変更したりすることができる。
　図１～図８を用いて第１実施例を説明する。
　＜１． ハードウェア構成＞
　図１は、仮想計算機システムを動作させる物理計算機１の構成を示す。物理計算機１は、後述のように、複数のＣＰＵ２（プロセッサと呼んでもよい）、ノースブリッジ３、メモリ４、サウスブリッジ５、Ｉ／Ｏデバイス６を備える。
　ＣＰＵ２は、仮想化支援機能をサポートしている。そのようなＣＰＵ２として、仮想化支援機能であるＩｎｔｅｌ ＶＴまたはＡＭＤ－Ｖをサポートしているx86（もしくはIA-32）互換のＣＰＵを挙げることができる。
　各ＣＰＵ２は、それぞれ一つの物理Local APIC（Advanced Programmable Interrupt Controller）７を持ち、バス８Ａを介してノースブリッジ３に接続される。ノースブリッジ３には、メモリバス８Ｂを介してメモリ４が接続されている。ノースブリッジ３には、バス８Ｃを介して、Ｉ／Ｏデバイス６（PCI Express（登録商標）デバイス）もしくはサウスブリッジ５が接続される。
　ノースブリッジ３は、IOxAPIC（図示せず）を有する。サウスブリッジ５には、Ｉ／Ｏデバイス６がバス８Ｄを介して接続される。Ｉ／Ｏデバイス６としては、例えば、ＰＣＩ（Peripheral Component Interconnect）デバイス、ＬＰＣ（Low Pin Count）デバイス、レガシーデバイスなどがある。
　＜２． ソフトウェア構成＞
　図２は、物理計算機１および仮想計算機システムの論理的な構成を示す図である。仮想計算機システムを採用した計算機は、仮想マシン１１と、仮想マシン１１を制御するハイパバイザ１０とを有する。「仮想計算機」としての仮想マシン１１は、仮想ＣＰＵ１２と、ゲスト１３とを有する。ゲスト１３は、ゲストＯＳおよびゲストＯＳ上で動作するソフトウェアの総称であり、「ゲストプログラム」に該当する。
　仮想ＣＰＵ１２は、仮想Local APIC１４を有する。仮想ＣＰＵ１２とは、ゲスト１３が認識する仮想的なＣＰＵであり、この仮想ＣＰＵ１２に対して物理ＣＰＵ２が割り当てられることで、ゲスト１３の処理が実行される。
　仮想Local APIC１４は、仮想マシン１１に割込みを認識させるために、ハイパバイザ１０および物理ＣＰＵ２の仮想化支援機能が仮想的に作り出したLocal APICである。仮想ＣＰＵに割り当てられる物理ＣＰＵ２には、ＣＰＵ占有仮想マシンの仮想ＣＰＵに割り当てられるものと、ＣＰＵ共有仮想マシンの仮想ＣＰＵに割り当てられるものとの２種類がある。
ＣＰＵ占有仮想マシンとは、その仮想マシンが有する一つ一つの仮想ＣＰＵに対して、特定の物理ＣＰＵが占有的に割り当てられるものである。ＣＰＵ共有仮想マシンとは、その仮想マシンが有する仮想ＣＰＵに対して、複数の物理ＣＰＵが時分割で割り当てられるものである。
　本実施例では、前者を占有割り当て物理ＣＰＵ２と呼び、後者を共有割り当て物理ＣＰＵ２と呼ぶ。また、ある物理ＣＰＵ２に対して、その時点で実行させる仮想ＣＰＵ１２を選ぶことを、仮想ＣＰＵ１２のディスパッチという。
　なお、図中では、複数の、物理ＣＰＵ２、仮想マシン１１、仮想ＣＰＵ１２、ゲスト１３などに対してかっこ付きの数字をそれぞれ添えているが、特に区別しない場合は、かっこ付きの数字を除いて説明する。
　図３は、本実施例で使用するデータ構造と、物理計算機１および仮想計算機システムとの論理的な対応関係を示した説明図である。仮想ＣＰＵ管理データＤ１１は、ハイパバイザ１０が仮想ＣＰＵ１２の挙動を制御するために設定するデータである。仮想ＣＰＵ管理データＤ１１は、ＩｎｔｅｌではＶＭＣＳ（Virtual Machine Control Structure）と呼ばれており、ＡＭＤではＶＭＣＢ（Virtual Machine Control Block）と呼ばれる。仮想ＣＰＵ管理データＤ１１は、仮想ＣＰＵ１２ごとに用意される。
　仮想ＡＰＩＣレジスタＤ１２とは、ゲスト１３による物理ＡＰＩＣレジスタＤ１５へのアクセスを仮想化するためのものである。仮想ＡＰＩＣレジスタＤ１５は、仮想割込みを管理するためのデータ構造である。仮想ＡＰＩＣレジスタＤ１２をハイパバイザ１０およびハードウェアが適切に管理することで、仮想Local APIC１４が実現する。
　外部割込み実行モード識別データＤ１３は、対応する物理ＣＰＵ２の外部割込み実行モードが何であるかを識別するためのデータである。切替通知フラグＤ１４とは、対応する物理ＣＰＵ２に対して、外部割込み実行モードの切替指示が出ていることを通知するためのフラグである。
　物理ＡＰＩＣレジスタＤ１５は、物理Local APIC７に届いた外部割込みを制御するためのレジスタ、もしくはＩＰＩの生成を制御するためのレジスタである。物理ＡＰＩＣレジスタＤ１５は、ＥＯＩ（End of Interrupt）レジスタ、ＩＳＲ（In Service Register）などを含む。
　割込みパラメータＤ１６とは、Ｉ／Ｏデバイス６のそれぞれの割込みの、ベクタ値や宛先ＣＰＵなどのパラメータを決定するデータ構造である。ゲストＯＳやハイパバイザ１０は、割込みパラメータＤ１６を書き換えることによって、Ｉ／Ｏデバイス６の割込みを制御する。
　なお、外部割込み実行モード識別データＤ１３と切替通知フラグＤ１４は、第２実施例において使用されるデータ構造であるため、詳細は後述する。
　＜３．外部割込み処理方式の概要＞
　本実施例では、物理ＣＰＵ２がゲストモードで実行中に、外部割込みが届いた場合の割込み処理方式を、外部割込み実行方式と呼ぶ。外部割込み実行方式として、直接実行方式とエミュレーション方式の２種類を定義する。ハイパバイザ１０は、任意の外部割込みの実行方式を、上述の２つの外部割込み実行方式のいずれとするか制御できる。
　直接実行方式では、物理Local APIC７に割込みが届いても、物理ＣＰＵ２はゲストモードのままである。その割込み（外部割込み）は、物理ＣＰＵ２上で実行中の仮想ＣＰＵ１２のゲストＩＤＴ１３０（図５参照）を通して、処理される。物理Local APIC７に対する外部割込み処理の終了通知（ＥＯＩの発行）も、ハイパバイザ１０の介入なしにゲスト１３が直接行う。つまり、直接実行方式では、物理ＣＰＵ２に届いた外部割込みは、ハイパバイザ１０を介さずに、ゲスト１３によって処理される。従って、直接実行方式の場合、物理ＣＰＵ２はゲストモードからホストモードへ移行する必要がなく、比較的短時間で外部割込みを処理できる。
　エミュレーション方式を説明する。エミュレーション方式では、物理Local APIC７に外部割込みが届くと、物理ＣＰＵ２はホストモードに遷移し、その割込みの処理がハイパバイザ１０に渡る。ハイパバイザ１０は、その割込みをエミュレーションし、適切な仮想ＣＰＵ１２へ割込みを伝達する。
　仮想ＣＰＵ１２へ伝達された割込みは、その仮想ＣＰＵ１２がゲストモードの物理ＣＰＵ２にディスパッチされた際に、ゲスト１３によって処理される。ゲスト１３によるＥＯＩ発行についてもハイパバイザ１０が介入する。ハイパバイザ１０は、物理Local APIC７に向けたＥＯＩではなく、仮想Local APIC１４へのＥＯＩ発行に変換する。このようにエミュレーション方式では、ハイパバイザ１０によるソフトウェア処理が入るため、直接実行方式に比べて、外部割込みの処理性能が低下する。
　これら２つの外部割込み実行方式は、仮想ＣＰＵ１２単位で指定できる。物理ＣＰＵ２に外部割込みが届いた場合、その外部割込みが直接実行方式またはエミュレーション方式のいずれで処理されるかは、その物理ＣＰＵ２にディスパッチされている仮想ＣＰＵ１２の設定によって決まる。
　直接実行方式では、物理ＣＰＵ２に届いた外部割込みのベクタ値がそのままゲスト１３に伝達される。従って、直接実行方式で処理可能な外部割込みとは、その外部割込みが届い物理ＣＰＵ２にディスパッチされている仮想ＣＰＵ１２のゲストＩＤＴ１３０に、事前に割り当てられている外部割込みである。ゲスト１３（詳しくはゲストＯＳ）は、ゲストＩＤＴ１３０に外部割込みを予め設定することができる。
　仮想ＣＰＵ１２の設定は、ハイパバイザ１０が仮想ＣＰＵ管理データＤ１１を書き換えることで行う。以下、仮想ＣＰＵ１２をどのように設定すれば、直接実行方式およびエミュレーション方式を実現できるかについて説明する。
　仮想ＣＰＵ１２の外部割込み実行方式をエミュレーション方式とする場合は、仮想ＣＰＵ１２を以下のように設定する。
（Ｅａ）ゲストモード時に外部割込みが届くと、ホストモードへの遷移が起こる。
（Ｅｂ）ゲストモード時に物理ＥＯＩレジスタへアクセスすると、ホストモードへの遷移が起こる。
（Ｅｃ）仮想割込みの扱いが有効である。
　仮想ＣＰＵ１２の外部割込み実行方式を直接実行方式とする場合は、仮想ＣＰＵ１２を以下のように設定する。
（Ｄａ）ゲストモード時に外部割込みが届いても、ホストモードへ遷移しない。
（Ｄｂ）ゲストモード時に物理ＥＯＩレジスタ（図示せず）へアクセスしても、ホストモードへ遷移しない。
（Ｄｃ）仮想割込みの扱いが無効である。
　物理ＥＯＩレジスタとは、物理ＡＰＩＣレジスタＤ１５に含まれるレジスタである。物理ＥＯＩレジスタに書き込むと、該当する物理Local APIC７にＥＯＩが発行される。仮想割込みとは、仮想Local APIC１４を通して仮想ＣＰＵ１２に伝達される、仮想的な割込みである。仮想割込みは、ハイパバイザ１０およびハードウェアの仮想化支援機能により生成される。
　上述した設定方法を、ＩｎｔｅｌのＣＰＵを例にあげて説明する。ゲストモード時に外部割込みが届くとホストモードへの遷移が起こる機能を有効にするためには、ＶＭＣＳの”external interrupt exiting” VM-execution controlというフィールドを１に設定する。逆にこの機能を無効にするためには、０を設定する。
　一般的には通常、物理ＡＰＩＣレジスタＤ１５へのアクセスはホストモードへの遷移を引き起こすように設定する。しかし、X2APICをサポートするＣＰＵの場合は、ＶＭＣＳの”use MSR bitmap” VM-execution controlフィールドを１に設定し、さらにMSR bitmapを適切に設定する。これにより、物理ＡＰＩＣレジスタＤ１５のうち物理ＥＯＩレジスタのみを、ホストモードへ遷移することなくアクセスできる。仮想割込みの扱いを有効にする場合はＶＭＣＳの”Virtual-interrupt delivery”を１に設定し、無効にする場合は０に設定する。
＜４．物理ＣＰＵの外部割込み実行モード＞
　外部割込み実行方式は、仮想ＣＰＵ１２ごとに設定可能である。本実施例では、物理ＣＰＵ単位で、外部割込み実行方式を制御する。すなわち、一つの物理ＣＰＵ２上で動作し得る全ての仮想ＣＰＵ１２の外部割込み実行方式は、直接実行方式かエミュレーション方式のどちらか一方に統一する。
　本実施例では、全ての外部割込みを直接実行方式で処理する物理ＣＰＵ２を、直接実行モード物理ＣＰＵと呼ぶ。全ての外部割込みをエミュレーション方式で処理する物理ＣＰＵを、エミュレーションモード物理ＣＰＵと呼ぶ。またこれら２つの、物理ＣＰＵ単位で設定する外部割込み実行方式を、外部割込み実行モードと呼ぶ。
　ある物理ＣＰＵ２において、その上で動作する仮想マシン１１が存在しない場合（言い換えれば、その物理ＣＰＵ２が割り当てられ得る仮想ＣＰＵ１２が無い場合）、その物理ＣＰＵの外部割込み実行モードはエミュレーションモード物理ＣＰＵとなる。なぜなら、そのような物理ＣＰＵはゲストモードで動作することはないため、その物理ＣＰＵに届く割り込みは、常にハイパバイザによって処理されるためである。このような物理ＣＰＵは、仮想計算機システムの初期状態のような、仮想マシンが一つも立ち上げられていない場合などに存在する。
　直接実行モード物理ＣＰＵは、「第１実行モードで外部割込みを処理する第１物理プロセッサ」に該当する。エミュレーションモード物理ＣＰＵとは、「第２実行モードで外部割込みを処理する第２物理プロセッサ」に該当する。
　外部割込みが上記２種類の外部割込み処理方式のうちいずれによって処理されるかは、その割込みの宛先となっている物理ＣＰＵ２の外部割込み実行モードにより定まる。ハイパバイザ１０は、任意の外部割込みの宛先ＣＰＵを制御できる。さらに、後述の実施例で述べるように、ハイパバイザ１０は、任意の物理ＣＰＵ２の外部割込み実行モードを動的に切り替えることができる。
　ハイパバイザ１０は、任意の外部割込みの宛先ＣＰＵを、直接実行モード物理ＣＰＵとエミュレーションモード物理ＣＰＵのいずれにするかを制御できる。複数の物理ＣＰＵ２のうち少なくともいずれか一つの物理ＣＰＵ２は、ホストモードで動作しているため、ハイパバイザ１０は、外部割込みの宛先となる物理ＣＰＵ２を決定できる。すなわち、ハイパバイザ１０は、外部割込みを処理する方式を制御することができる。
　本実施例では、各物理ＣＰＵ２がどちらの外部割込み実行モードで動作しているかを判別するために、外部割込み実行モード識別データＤ１３を用意している。外部割込み実行モード識別データＤ１３には、各物理ＣＰＵ２で現在実行中の外部割込み実行モードを識別するための情報が格納される。
まず、直接実行モード物理ＣＰＵについて説明する。直接実行モード物理ＣＰＵとは、その物理ＣＰＵが占有的に割り当てられている仮想ＣＰＵの外部割込み実行方式が直接実行方式である物理ＣＰＵである。
　直接実行モードが適用可能な物理ＣＰＵの条件は、以下の二つを満たすことである。
　・占有割り当て物理ＣＰＵである。
　・ハイパバイザの介入を必要とする外部割込みの宛先となっていない物理ＣＰＵである。
　また、外部割込み実行モード物理ＣＰＵでは、その物理ＣＰＵを宛先とする外部割り込みに関して、ハイパバイザの特別な処理が必要となるため、以下で説明する。
直接実行モード物理ＣＰＵでは、物理Local APIC７に届いた外部割込みは全て、ハイパバイザの処理を介すことなく、ゲストによって直接処理される。そのためゲストＯＳが、その直接実行モード物理ＣＰＵが割り当てられた仮想ＣＰＵに伝達されるよう設定した外部割込みは、全てその直接実行モード物理ＣＰＵを宛先としていなければならない。また、その直接実行モード物理ＣＰＵを宛先とする外部割込みは、その直接実行モード物理ＣＰＵが割り当てられた仮想ＣＰＵに伝達されるよう、ゲストＯＳが設定した割り込みだけでなければならない。
　そこで、ゲストＯＳが外部割込みを、直接実行モード物理ＣＰＵが割り当てられている仮想ＣＰＵに伝達されるように設定した場合、ハイパバイザはそれをトラップし、その外部割込みの宛先をその仮想ＣＰＵに割り当てられている直接実行モード物理ＣＰＵとするように、割り込みパラメータを変更する。
　また、直接実行モード物理ＣＰＵに届いた外部割込みのベクタ値は、ハイパバイザ１０のエミュレーションを介さずに、物理Local APIC７に届いたベクタ値がそのまま仮想マシンに伝達される。このため、物理Local APIC７に届く外部割込みのベクタ値と、ゲスト１３のゲストＯＳがその割込みに割り当てたベクタ値とは、必ず一致していなければならない。
　そこで、ゲストＯＳが、直接実行モード物理ＣＰＵが割り当てられている仮想ＣＰＵに伝達されるように設定されている外部割込みのベクタ値を設定した際は、ハイパバイザはそれをトラップし、そのベクタ値と同じベクタ値を、その外部割込みの割り込みパラメータに設定する
　次に、エミュレーションモード物理ＣＰＵについて説明する。エミュレーションモード物理ＣＰＵとは以下の二つを指す。
・割り当てられ得る全ての仮想ＣＰＵの外部割込み実行方式がエミュレーション方式である物理ＣＰＵ。
・割り当てられ得る仮想ＣＰＵがない物理ＣＰＵ。
エミュレーションモードが適用可能な物理ＣＰＵに特別な条件はない。
　図４は、仮想計算機システムの初期状態時から、仮想マシンを立ち上げて、外部割込み実行モードを各物理ＣＰＵに適用する例を表している。図中では、エミュレーションモードをＥモードと、直接実行モードをＤモードと、それぞれ略記する場合がある。
　図４（ａ）に示すように、ＣＰＵ共有仮想マシンを立ち上げた際は、その仮想マシンが動作する物理ＣＰＵは共有割り当て物理ＣＰＵとなる。図４（ｂ）に示すように、共有物理ＣＰＵは直接実行モードを適用することはできないため、生成する仮想ＣＰＵの外部割込み処理方式はエミュレーション方式とし、その仮想ＣＰＵに共有される物理ＣＰＵにはエミュレーションモード物理ＣＰＵを適用する。
[規則91に基づく訂正 24.12.2015]　
　図４（ｃ）に示すように、ＣＰＵ占有仮想マシンを立ち上げた際は、その仮想マシンが動作する物理ＣＰＵは占有割り当て物理ＣＰＵとなる。ハイパバイザの介入が必要な外部割込みを受け付けている物理ＣＰＵは直接実行モードを適用することはできないため、その物理ＣＰＵに割り当てるために生成する仮想ＣＰＵの外部割込み処理方式はエミュレーション方式とし、その物理ＣＰＵにはエミュレーションモード物理ＣＰＵを適用する。
　ハイパバイザの介入が必要な外部割込みを受け付けていない物理ＣＰＵは、直接実行モードを適用することができるため、その物理ＣＰＵに割り当てるために生成する仮想ＣＰＵの外部割込み処理方式は直接実行方式とし、その物理ＣＰＵには直接実行モードを適用する。仮想マシンの立ち上げ後に、仮想マシンが動作したまま外部割込み実行モードを動的に切り替える方法については、後述の実施例で述べる。
　図５は、ゲストモードで実行中のエミュレーションモード物理ＣＰＵ２に届いた外部割込みが、ハイパバイザ１０を介してゲスト１３へ伝達される様子を示す。図中では、エミュレーションモードをＥモードと、直接実行モードをＤモードと、それぞれ略記する場合がある。
　Ｉ／Ｏデバイス６からエミュレーションモード物理ＣＰＵの物理Local APIC７へ外部割込みが届くと、その外部割込みはいったんハイパバイザ１０に受け取られる。ハイパバイザ１０は、その外部割込みをエミュレーション処理して仮想割込みに変換し、その仮想割込みを仮想Local APIC１４に送る。このようにして、エミュレーションモード物理ＣＰＵへの外部割込みは、ハイパバイザ１０を介して、ゲスト１３に伝達される。
　図６は、図５で説明した処理の詳細を示すフローチャートである。図中では、割込みをＩＮＴと略記する場合がある。
　物理Local APIC７に外部割込みが届くと（Ｓ３１）、エミュレーションモード物理ＣＰＵ２はホストモードに遷移し（Ｓ３２）、ハイパバイザ１０に処理を引き渡す。ハイパバイザ１０が仮想Local APIC１４に仮想割込みを伝達すると（Ｓ３３）、その仮想割込みは実行されずに一旦仮想Local APIC１４に貯蔵される（Ｓ３４）。
　ハイパバイザ１０は、物理ＡＰＩＣレジスタＤ１５のＥＯＩレジスタに書き込んで、物理Local APIC７へＥＯＩを発行する（Ｓ３５）。ＥＯＩ発行により、物理Local APIC７は外部割込みの終了を検知する（Ｓ３６）。
　物理ＣＰＵ２はゲストモードに遷移し、ハイパバイザ１０からゲスト１３に処理が移る（Ｓ３７）。物理ＣＰＵ２がゲストモードに遷移すると、貯蔵されていた仮想割込みが検知され（Ｓ３８）、ゲスト１３の割込みハンドラの実行が開始される（Ｓ３９）。
　割込みハンドラは、ＥＯＩを実行するために、物理ＡＰＩＣレジスタＤ１５のＥＯＩレジスタにアクセスする。ここで、物理ＥＯＩレジスタへアクセスするとホストモードへ遷移するように、仮想ＣＰＵ１２は設定されている。従って、物理ＣＰＵ２はゲストモードからホストモードへ遷移し、ハイパバイザ１０に処理が移る（Ｓ４０）。
　ハイパバイザ１０は、物理ＡＰＩＣレジスタＤ１５のＥＯＩレジスタへの書き込みに代えて、仮想ＡＰＩＣレジスタＤ１２を操作する。このエミュレーション処理により、ハイパバイザ１０は、物理Local APIC７へのＥＯＩ発行を、仮想Local APIC１４へのＥＯＩ発行に変換する（Ｓ４１）。
　ハイパバイザ１０によるＥＯＩ発行エミュレーションによって、仮想Local APIC１４は仮想割込みの終了を検知する（Ｓ４２）。その後、物理ＣＰＵ２はゲストモードに遷移し（Ｓ４３）、ハイパバイザ１０からゲスト１３に処理が移る。ゲスト１３の処理が再開されると、ゲスト１３は割込みハンドラを終了する（Ｓ４４）。ゲスト１３は、外部割込みにより中断されていた処理を再開する（Ｓ４５）。
　上記で説明したように、エミュレーションモード物理ＣＰＵ２上で動作する仮想ＣＰＵ１２へ向けて外部割込みをエミュレーションする場合は、仮想割込みを用いる。これに対し、直接実行モード物理ＣＰＵ２に占有的に割り当てられている仮想ＣＰＵ１２に向けて外部割込みをエミュレーションする場合は、仮想割込みではなく、直接実行モード物理ＣＰＵ２の物理Local APIC７に向けたＩＰＩを用いる。これは、直接実行モード物理ＣＰＵ２上で動作する仮想ＣＰＵ１２への外部割込みの伝達は、全て直接実行モード物理ＣＰＵ２の物理Local APIC７を介した伝達とするためである。上記としなければならない理由は、直接実行モード物理ＣＰＵ２の説明にて後述する。
　図７は、直接実行モード物理ＣＰＵ２に外部割込みが届いたとき、ホストモードに遷移することなく、ゲストＩＤＴ１３０を通して割込みハンドラを直接実行する様子を示した説明図である。
　図８は、図７におけるゲスト１３、ハイパバイザ１０、物理Local APIC７、仮想Local APIC１４での各処理を示すフローチャートである。
　物理Local APIC７に外部割込みが届くと（Ｓ５１）、物理ＣＰＵ２はゲストモードのまま、ゲストＩＤＴ１３０を通して、割込みハンドラの実行を開始する（Ｓ５２）。割込みハンドラに渡されるベクタ値は、物理Local APIC７に届いた外部割込みのベクタ値をそのまま使用する。物理ＣＰＵ２から物理Local APIC７へのＥＯＩ発行も、ゲストモードのまま行われる（Ｓ５３）。物理Local APIC７は、ＥＯＩを受領すると、外部割込みが終了したことを検知する（Ｓ５４）。ゲスト１３はＥＯＩを発行した後、割込みハンドラを終了し（Ｓ５５）、割込み以前の処理を再開する（Ｓ５６）。
　物理Local APIC７のＥＯＩの発行を、ゲストモードのまま行うことができる理由は次の通りである。直接実行モード物理ＣＰＵ２上で動作する仮想ＣＰＵ１２を宛先とする割込みは、仮想割込みとして届くことはなく、全て物理Local APIC７に向けた外部割込みとして届く。さらに、直接実行モード物理ＣＰＵ２の物理Local APIC７に届く割込みは、全てその物理ＣＰＵ２上で動作するただ一つの仮想ＣＰＵ１２に向けた割込みであることが保証されている。すなわち、直接実行モード物理ＣＰＵ２の物理Local APIC７に届く割込みは、全て直接モード物理ＣＰＵ２上で動作するただ一つのゲストＯＳに認識される割込みとなる。
　また、直接実行モード物理ＣＰＵ２上で動作する仮想ＣＰＵ１２は、仮想割込みを扱うことはない。従って、直接実行モード物理ＣＰＵでは、外部割込みの優先度を、仮想Local APIC１４と物理Local APIC７とで調整する必要がない。
　以上の理由から、直接モード物理ＣＰＵでは、物理Local APIC７へ向けて発行する全てのＥＯＩの制御をゲスト１３（ゲストＯＳ）に委ねることができる。
　次に、直接実行モード物理ＣＰＵ２がホストモードで動作しているときに外部割込みが届いた場合について説明する。直接実行モード物理ＣＰＵ２においては、ホストモードで実行中は常にRFLAGS.IFおよびEFLAGS.IFがいずれも０となるようにハイパバイザ１０が制御する。RFLAGSおよびEFLAGSは、実行されているプログラムの状態を示すレジスタである。IFとは、これらレジスタのInterrupt Enable Flagビットを指す。
　RFLAGS.IFおよびEFLAGS.IFが１のときは、プログラムの状態が割込み可能であることを示し、０のときは、割込みが不可であることを示す。割込みが不可のときは、外部割込みが届いてもその処理は実行されず、Local APICに貯蔵される。そして、EFLAGS.IFおよびRFLAGS.IFが１となったとき、貯蔵されていた割込みの処理が実行される。
　直接実行モード物理ＣＰＵがホストモードで実行中の場合は、常にRFLAGS.IFおよびEFLAGS.IFを０に設定しておくことによって、ホストモードのときに届いた外部割込みを全て物理Local APIC７に保留させることができる。そして、直接実行モード物理ＣＰＵがホストモードからゲストモードに遷移し、RFLAGS.IFおよびEFLAGS.IFが１になったときに、保留状態に置かれた割込みは、図８のフローチャートに従って処理される。
　以上のように設定する理由は、直接実行モード物理ＣＰＵ２に届いた外部割込みは、ゲスト１３に直接処理させる以外に、その外部割込みをゲスト１３に認識させる方法がないためである。必ず全ての外部割込みをゲスト１３に直接実行させるため、上記のように各レジスタを制御する。
　このように構成される本実施例によれば、外部割込みを、仮想ＣＰＵ上のゲスト１３で処理したり、ハイパバイザ１０でエミュレーション処理したりできる。
　本実施例では、各物理ＣＰＵ２を、直接実行モード物理ＣＰＵとエミュレーションモード物理ＣＰＵとに分ける。さらに、本実施例の直接実行モード物理ＣＰＵは、受け付けた全ての外部割込みをゲスト１３に直接処理させるため、全ての割込みをエミュレーション処理する場合に比べて、割込み処理に要する時間を短縮でき、計算機の性能を向上することができる。
　本実施例では、従来技術のシャドウＩＤＴを用いないため、ハイパバイザ１０がシャドウＩＤＴをメンテナンスすることによる、コスト発生や他ＣＰＵとの相互干渉が生じるおそれがない。従って、本実施例の計算機は、従来技術に比べて高い信頼性を維持しつつ性能を向上することができる。
　図９～図１６を用いて第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に該当するため、第１実施例との差異を中心に説明する。本実施例では、物理ＣＰＵ２の外部割込み実行モードを、ハイパバイザ１０が任意のタイミングで動的に切り替える。
　＜１．仮想マシン動作中に動的に外部割込み実行モードを切り替える処理の概要＞
　本実施例では、外部割込み実行モードを仮想マシン動作中に動的に切り替える。外部割込み実行モードを動的に切り替えるとは、仮想マシン１１の動作中に、物理ＣＰＵ２の外部割込み実行モードを、直接実行モードとエミュレーションモードの間で相互に切り替えることである。
　任意の物理ＣＰＵ２の外部割込み実行モードを、エミュレーションモードから直接実行モードへ動的に切り替えるための、物理ＣＰＵ２の状態に関する条件は、その物理ＣＰＵ２が占有割り当て物理ＣＰＵ２であることである。一方、直接実行モードからエミュレーションモードへの切り替えに関しては、物理ＣＰＵ２の状態に関する条件はない。なお、切替対象物理ＣＰＵ２を宛先とする外部割込みの調整は、外部割込み実行モード切替処理の中で行う。
　外部割込み実行モードの動的切替が必要となる場合は、以下のような場合である。第１の場合は、仮想マシン１１やＩ／Ｏデバイス６の構成が動的に変更される場合である。仮想マシン１１やＩ／Ｏデバイス６の構成に変更があると、外部割込みに対するハイパバイザ１０の介入の必要性の有無も変更になることがあるため、それに伴って外部割込み実行モードも変更する必要がある。
　図９は、仮想マシン１１の動的な物理ＣＰＵ割り当て設定の変更に伴い、物理ＣＰＵ２の外部割込み実行モードが切り替わる例を示す。図９の上側では、３つの物理ＣＰＵ２（１）～２（３）の全てが共有割り当て物理ＣＰＵ２であり、エミュレーションモード物理ＣＰＵ２として動作している。これに対し、図９の下側では、３つの物理ＣＰＵ２のうち２つの物理ＣＰＵ２（１），２（２）は、占有割り当て物理ＣＰＵ２であるため、直接実行モード物理ＣＰＵ２として動作している。図９の上側に示す仮想計算機環境と下側に示す仮想計算機環境とは、外部割込み実行モードを動的に切り替えることにより、相互に遷移可能である。
　外部割込み実行モードの動的切替が必要となる第２の場合を説明する。第２の場合は、ハイパバイザ１０の介入が必要となる割込みを負荷分散する場合である。図１０は、複数のエミュレーションモード物理ＣＰＵ２（３），２（４）のうち、一部のエミュレーションモード物理ＣＰＵ２（３）が故障等で使用不可になった場合を示す。
　図１０の上側に示すように、エミュレーションモード物理ＣＰＵ２（３），２（４）は、仮想デバイス１０１に変換すべきＩ／Ｏデバイス６からの割込みを受け付けている。一方のエミュレーションモード物理ＣＰＵ２（３）が、故障などの要因により使用不可となった場合に、その物理ＣＰＵ２（３）で担当していた外部割込みを、他方のエミュレーションモード物理ＣＰＵ２（４）に割り当てるとすると、他方のエミュレーションモード物理ＣＰＵ２（４）の負荷が増大する。
　そこで、図１０の下側に示すように、直接実行モード物理ＣＰＵ２（１），２（２）のうち一方の物理ＣＰＵ２（２）の外部割込み実行モードをエミュレーションモードに切り替えて、エミュレーションモード物理ＣＰＵ２（２）とする。そして、故障等で使用できなくなったエミュレーションモード物理ＣＰＵ２（３）の担当していた外部割込みの宛先を、新たなエミュレーションモード物理ＣＰＵ２（２）に変更する。
　図１０では、一つのエミュレーション物理ＣＰＵ２（４）に、ハイパバイザ１０の介入が必要となる割込みを全て集中させるのではなく、直接実行モード物理ＣＰＵ２（２）をエミュレーションモード物理ＣＰＵに切り替えて、そのエミュレーションの必要な割込みを受け付ける。これにより、割込み処理の負荷分散を図っている。
　図１１に示すように、仮想デバイス１０１に変換すべきＩ／Ｏデバイス６（２）の割込みの宛先を、複数の物理ＣＰＵ２（１），２（２）間で定期的に変更して負荷分散を図る場合も、外部割込み実行モードの動的切替を用いる。
　図１１の上側では、一方の物理ＣＰＵ２（１）が直接実行モード物理ＣＰＵ、他方の物理ＣＰＵ２（２）がエミュレーションモード物理ＣＰＵとなっている。Ｉ／Ｏデバイス６（２）は仮想デバイス１０１に変換されるべきデバイスであり、そのＩ／Ｏデバイス６（２）からの外部割込みは、エミュレーションモード物理ＣＰＵで処理される。
　図１１の下側では、一方の物理ＣＰＵ２（１）を直接実行モードからエミュレーションモードへ切り替えると共に、他方の物理ＣＰＵ２（２）をエミュレーションモードから直接実行モードへ切り替える。ハイパバイザ１０は、外部割込み実行モードの切替に伴い、Ｉ／Ｏデバイス６（２）からの外部割込みの宛先を変更する。
　＜２．外部割込み実行モード動的切替契機の通知処理＞
　外部割込み実行モードを動的に切り替えるためには、任意の物理ＣＰＵ２を、任意のタイミングでホストモードに遷移させて、ハイパバイザ１０に外部割込み実行モード切替処理を行わせる必要がある。本実施例では、以上の処理を外部割込み実行モード切替契機の通知処理と呼ぶ。
　一般的に、仮想計算機システムでは、ＩＰＩを任意の物理ＣＰＵ２に発行してホストモードに遷移させることで、ハイパバイザ１０に特定の処理の実行を通知する。しかし、直接実行モード物理ＣＰＵ２では、ＩＰＩはホストモードへの遷移を引き起こさず、直接ゲスト１３に伝達されてしまうため、ＩＰＩ以外の方法で外部割込み実行モード切替契機を通知しなければならない。
　そこで本実施例では、外部割込み実行モードの切替契機を通知するに際して、ゲストモードで一定時間Ｔｐが経過したら定期的にホストモードに遷移するという、ハードウェア仮想化支援機能を用いる。この機能を以下、定期的なホストモード遷移機能と呼ぶ。
　例えばＩｎｔｅｌのＣＰＵでは、そのような機能がpreemption timer機能として提供されている。preemption timer機能とは、予めハイパバイザ１０が指定したカウント数を、ゲストモードの間、一定間隔でデクリメントしていき、カウント値が０になった時点でホストモードに遷移するという機能である。この機能を用いると、物理ＣＰＵ２を定期的にゲストモードからホストモードに遷移させることができる。
　任意の物理ＣＰＵを任意のタイミングでホストモードに遷移させる方法として、Non Maskable Interrupt（NMI）をその物理ＣＰＵに対して発行するなどの方法もある。しかし、本来のそれらの処理と、外部割込み実行モード切替処理とが競合することを防ぐために、本実施例では、定期的なホストモード遷移機能を用いる。
　定期的なホストモード遷移機能を用いることで、外部割込み実行モード切替契機の通知は、ハイパバイザ１０ではなく、ゲスト１３の処理に割り込んで行われることを保証することができる。これにより、本実施例では、切替契機の通知が外部割込み実行モードに依存するハイパバイザ１０の処理に割り込んで、外部割込み実行モードを切り替えてしまい、ハイパバイザ１０の処理に不整合が起きてしまうことを防ぐことができる。なお、定期的にホストモードに遷移することによる性能低下を極力小さくするために、遷移の間隔Ｔｐはできるだけ大きく設定するのが好ましい。
　以下、例えばpreemption timer機能のような機能を用いる場合を例にあげて、外部割込み実行モードを切り替える方法を説明する。
　最初に、直接実行モードからエミュレーショモードへの切替処理について説明する。前提として、エミュレーションモードへの切替処理は、ゲスト１３での外部割込み処理が中断中でない場合のみ行う。
　ゲスト１３の外部割込み処理が中断中である場合とは、ゲスト１３の外部割込み処理中にpreemption timerのカウントが０になり、ホストモードに遷移した場合である。理由は以下の通りである。ゲスト１３は、直接実行モードでは物理Local APIC７を介して外部割込みを制御するが、エミュレーションモードでは仮想Local APIC１４を介して外部割込みを制御する。従って、もしも割込みが中断されている状態でエミュレーションモードに切り替えると、中断されていた割込み処理の再開後に、物理Local APIC７ではなく仮想Local APIC１４にＥＯＩが発行されてしまう。これでは、物理Local APIC７が検知した外部割込みが正常に終了しなくなってしまう。
　図１２は、外部割込み実行モードの切替契機を通知する処理を示すフローチャートである。図１２は、直接実行モードからエミュレーションモードへの切替契機の通知と、エミュレーションモードから直接実行モードへの切替契機の通知との両方に用いる。
　切替契機を通知する物理ＣＰＵ２は、外部割込み実行モードの切替契機が到来すると（Ｓ１０１：ＹＥＳ）、切替対象の物理ＣＰＵ２の外部割込み実行モードを切り替えさせるための切替契機通知フラグをセットする（Ｓ１０２）。以下、切替対象の物理ＣＰＵ２を切替対象ＣＰＵ２と呼ぶことがある。
　＜３．直接実行モードからエミュレーションモードへの切替＞
　図１３は、切替対象ＣＰＵ２の実行する切替判定処理を示す。図１３および図１４は、切替対象物理ＣＰＵ２の外部割込み実行モードを直接実行モードからエミュレーションモードへ切り替える処理を示す。
　最初に、切替対象ＣＰＵ２では、カウンタＴｐの値を第１切替時間Ｔ１に設定されているものとする。カウンタＴｐは、例えばIntelのＣＰＵでは、VMCSの“VMX-preemption timer value“フィールドに設定した値となる。第１切替時間Ｔ１は、比較的大きい値に設定される。ゲストモードからホストモードへの遷移の頻度を抑えて、処理性能の低下を防止するためである。ここで、Preemption timerのように構成されるカウンタＴｐは、ゲストモードでは設定することができないため、必ず最初はTp＝T1となっている。
　カウンタＴｐが０になると（Ｓ１１１：ＹＥＳ）、切替対象の物理ＣＰＵ２は、ゲストモードからホストモードへ遷移する（Ｓ１１２）。
　ハイパバイザ１０は、切替契機通知フラグがセットされているかどうかを調べる（Ｓ１１３）。ここでは、切替契機通知フラグの値が１の場合、フラグはセットされたものとして説明する。
　切替契機でない場合は切替契機通知フラグがセットされていないため（Ｓ１１３：ＮＯ）、カウンタをＴ１に再設定し（Ｓ１１４）、再度ゲストモードに遷移して（Ｓ１１５）、ゲスト１３の処理に戻る。この流れの場合、カウンタＴｐの値は第１切替時間Ｔ１に戻される。一方、切替契機通知フラグがセットされている場合（Ｓ１１３：ＹＥＳ）、ハイパバイザ１０は、切替対象ＣＰＵ２が外部割込み実行モードの切替契機であることを検知する。
　ハイパバイザ１０は、切替対象ＣＰＵ２の物理Local APIC７のＩＳＲ（In Service Register）が０であるかチェックする（Ｓ１１６）。切替対象ＣＰＵ２の仮想ＣＰＵ１２で動作しているゲスト１３の割込み処理が中断中でないかどうかを判断するためである。ここで、ＩＳＲとは、物理ＡＰＩＣレジスタＤ１５の１つで、現在処理中の割込みを示すレジスタである。
　ＩＳＲが０の場合（Ｓ１１６：ＹＥＳ）、割込み処理は中断中でないため、カウンタＴｐの値を第１切替時間Ｔ１に戻し（Ｓ１１７）、外部割込み実行モードを切り替える処理を行う（Ｓ１１８）。ステップＳ１１８の外部割込み実行モード切替処理は、図１４で後述する。
　一方、ＩＳＲの値が０でない場合（Ｓ１１６：ＮＯ）、何らかの割込み処理の中断中である。そこで、ハイパバイザ１０は、カウンタＴｐを第２切替時間Ｔ２に変更し（Ｓ１１９）、ゲストモードへ遷移する（Ｓ１１５）。第２切替時間Ｔ２は、第１切替時間Ｔ１よりも短く設定される（Ｔ２＜Ｔ１）。ゲストモードへ遷移すると、中断していた割り込み処理が再開される。
　カウンタＴｐの設定値を第１切替時間Ｔ１から第２切替時間Ｔ２に変更して、切替周期を短縮する理由を説明する。ハイパバイザ１０は、外部割込み実行モードの切替契機であることを検知しているため、中断中の割込み処理が終了したら、なるべく早くホストモードに遷移して、外部割込み実行モード切替処理を実行するためである。
　＜４．外部割込み実行モード切替処理＞
　図１４は、直接実行モードからエミュレーションモードへ外部割込み実行モードを切り替える処理のフローチャートである。本処理は、図１３のステップＳ１１８の詳細な一例を示す。
　外部割込み実行モードを直接実行モードからエミュレーションモードへ切り替える場合、ゲスト１３（詳しくはゲストＯＳ）の割込みハンドラが直接処理していた割込みは、ハイパバイザ１０が介入してエミュレーションすることになる。そこで、ハイパバイザ１０の割込みハンドラを再設定する（Ｓ１２１）。
　次に、ハイパバイザ１０は、切替対象ＣＰＵ２が占有的に割り当てられている仮想ＣＰＵ１２の仮想ＣＰＵ管理データＤ１１を操作し、仮想ＣＰＵ１２の割込み処理方式をエミュレーション方式に変更する（Ｓ１２２）。
　最後にハイパバイザ１０は、切替通知フラグＤ１４をクリアし（Ｓ１２３）、ゲストモードに遷移する（Ｓ１２４）。
　＜５．エミュレーションモードから直接実行モードへの切替＞
　次に、エミュレーションモードから直接実行モードへの切替契機を通知する処理について説明する。
　まず前提として、外部割込み実行モード切替処理のためにホストモードに遷移してから、外部割込み実行モードの切替処理を終了して再度ゲストモードに遷移するまでは、常にRFLAGS.IFおよびEFLAGS.IFは０にする。
　任意の物理ＣＰＵ２を任意のタイミングでホストモードに遷移させるための方法としては、直接実行モードからエミュレーションモードへの切り替えの際と同様に、preemption timer機能を用いることができる。
　エミュレーションモード物理ＣＰＵ２は、外部割込みが届くとホストモードに遷移するため、ＩＰＩを用いて切替契機の通知を行うこともできる。しかし、本実施例では、あえて、preemption timerのようなカウンタＴｐを用いる。その理由は以下の通りである。
　外部割込み実行モード切替処理が始まってから、ゲストモードに戻るまでの間は、必ずRFALGS.IFおよびEFLAGS.IFが０でなければならない。もしもハイパバイザ１０での処理中に外部割込み実行モード切替処理が割り込むと、切替処理終了後にハイパバイザ１０の処理が再開されてしまう。この場合、RFLAGS.IFおよびEFLAGS.IFが０であるということを保証するのが難しい。そこで、本実施例では、外部割込み実行モード切替処理は必ずゲストモードからホストモードに遷移したときに行われることを保証するために、カウンタＴｐを用いて切替契機を伝える。なお、直接実行モードからエミュレーションモードへの切替処理も、ゲスト１３の外部割込み処理が中断中でないときのみ行う。
　図１５は、エミュレーションモードから直接実行モードへ外部割込み実行モードを切り替えるための契機を通知する処理を示すフローチャートである。
　図１５に示すエミュレーションモードから直接実行モードへの切替契機通知処理と、図１３で述べた直接実行モードからエミュレーションモードへの切替契機通知処理との違いは、ゲスト１３の割込み処理中断中であるか否かのチェックを行うレジスタにある。図１３の処理では物理ＡＰＩＣレジスタＤ１５のＩＳＲをチェックしたが、図１５の処理では仮想ＡＰＩＣレジスタＤ１２のＩＳＲをチェックする。
　つまり、図１５に示すステップＳ１３１～Ｓ１３５，Ｓ１３７～Ｓ１３９は、図１３に示すステップＳ１１１～Ｓ１１５，Ｓ１１７～Ｓ１１９と同一である。図１５のステップＳ１３６と図１３のステップＳ１１６とは、チェック対象のレジスタのみ異なる。従って、図１５の処理についてのこれ以上の説明は割愛する。ステップＳ１３８の外部割込み実行モード切替処理については後述する。
　＜６．外部割込み実行モード切替処理＞
　図１６は、エミュレーションモードから直接実行モードへ外部割込み実行モードを切り替える処理のフローチャートである。本処理は、図１５のステップＳ１３８の詳細な一例を示す。
　ハイパバイザ１０は、切替対象ＣＰＵ２を宛先とする外部割込みのうち、その物理ＣＰＵ２が直接実行可能な外部割込み以外の外部割込みを、他のエミュレーションモード物理ＣＰＵ２を宛先となるように、割込みパラメータＤ１６を変更する（Ｓ１４１）。すなわち、切替対象ＣＰＵ２が受け付けていた外部割込みのうち、他のエミュレーションモード物理ＣＰＵ２で処理可能な外部割込みの宛先を変更する。
　ハイパバイザ１０は、他の物理ＣＰＵ２を宛先とする外部割込み（Ｉ／Ｏデバイス６の外部割込み）のうち、切替対象ＣＰＵ２で直接実行可能な全ての割込みを、切替対象ＣＰＵ２を宛先とするように、割込みパラメータＤ１６を変更する（Ｓ１４２）。
　切替対象ＣＰＵ２で直接実行可能な割込みが仮想デバイス１０１からの割り込みである場合、その仮想デバイス１０１についてのエミュレーション処理は、切替対象ＣＰＵ２へのＩＰＩとなるように、ハイパバイザ１０の設定を変更する。
　ステップＳ１４１，Ｓ１４２の処理により、切替対象ＣＰＵ２で直接実行可能な外部割込みのみが、切替対象ＣＰＵ２を宛先とする。さらに、切替対象ＣＰＵ２で直接実行可能な割込みは全て、切替対象ＣＰＵ２を宛先とする。
　切替対象ＣＰＵ２で直接実行可能な外部割込みとは、その切替対象の物理ＣＰＵ２が占有的に割り当てられている仮想ＣＰＵ１２のＩＤＴにゲストＯＳが割り当てた外部割込みである。
　ハイパバイザ１０は、切替対象ＣＰＵ２を宛先とする外部割込みのベクタ値を、ゲストＯＳがそれぞれの割込みに設定したベクタ値と同一になるように、割込みパラメータＤ１６を変更する（Ｓ１４３）。
　ハイパバイザ１０は、ステップＳ１４１で他の物理ＣＰＵ２へ宛先を変更した割込みのうち、切替対象ＣＰＵ２の物理Local APIC７に保留されているものがあるか調べる（Ｓ１４４）。
　切替対象ＣＰＵ２の物理Local APIC７で保留中の割込みは、切替対象ＣＰＵ２を直接実行モードへ切り替えた後に、無効な割込みとして捨てられてしまう。そこで、ハイパバイザ１０は、宛先変更前のＣＰＵ２で保留中の割込みが処理されずに捨てられてしまうのを防止すべく、宛先変更後の物理ＣＰＵ２に対して、変更後のベクタ値を持ったＩＰＩを発行する（Ｓ１４５）。
　ハイパバイザ１０は、仮想Local APIC１４で保留されている仮想割込みがあるかを調べる（Ｓ１４６）。切替対象ＣＰＵ２を直接実行モードへ切り替えた後は、仮想Local APIC１４を用いた割込みの制御は行われないため、仮想Local APIC１４に保留された割込みはゲスト１３（ゲストＯＳ）に認識されなくなる。
　そこで、ハイパバイザ１０は、仮想Local APIC１４に保留された割込みがある場合、保留中の割込みと同一のベクタ値を持ったSelf-IPIを再発行する（Ｓ１４７）。ＩＰＩの再発行により、その割込みの保留先は、仮想Local APIC１４から物理Local APIC７へ変換される。
　外部割込み実行モード切替処理中は、RFLAGS.IFおよびEFLAGS.IFは０としているため、Self-IPIで受けた割込みはその時点では処理されず、ゲストモードに遷移するまで物理Local APIC７にペンディングされたままとなる。
　ハイパバイザ１０は、切替対象ＣＰＵ２が占有的に割り当てられている仮想ＣＰＵ１２の仮想ＣＰＵ管理データＤ１１を操作し、割込み処理方式を直接実行方式に変更する（Ｓ１４８）。最後にハイパバイザ１０は、外部割込みモード切替通知フラグＤ１４をクリアし（Ｓ１４９）、ゲストモードに遷移する（Ｓ１５０）。
　このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、任意の物理ＣＰＵ２の外部割込み実行モードを、直接実行モードとエミュレーションモードの間で動的に変更することができる。従って、本実施例では、物理ＣＰＵ２に発生する障害に対応することができ、物理ＣＰＵ２の負荷を分散させることもできる。これにより、第１実施例に比べて使い勝手が向上する。
　なお、本発明は、上記各実施例に限定されず、様々な変形例を含む。例えば、上記各実施例は本発明を分かりやすく説明したものであり、本発明は実施例で説明した全ての構成を備える必要はない。実施例で述べた構成の少なくとも一部を、他の構成に変更したり、削除したりすることができる。さらに、実施例に新構成を追加することもできる。
　実施例で述べた機能や処理などの一部または全部を、ハードウェア回路として実現してもよいし、ソフトウェアとして実現してもよい。コンピュータプログラムや各種データは、計算機内の記憶装置に限らず、計算機外部の記憶装置へ格納してもよい。
　１：物理計算機、２：物理ＣＰＵ、４：メモリ、６：Ｉ／Ｏデバイス、７：物理Ｌｏｃａｌ　ＡＰＩＣ、１０：ハイパバイザ、１１：仮想マシン、１２：仮想ＣＰＵ、１３：ゲスト、１４：仮想Ｌｏｃａｌ　ＡＰＩＣ

Claims (13)

  1. 　計算機であって、
    　複数の物理プロセッサと、
    　前記複数の物理プロセッサのうちの少なくとも一つの物理プロセッサにより実現されるハイパバイザと、
    　前記ハイパバイザにより制御される少なくとも一つの仮想計算機であって、少なくとも一つの仮想プロセッサと、前記仮想プロセッサにより実行されるゲストプログラムとを含む仮想計算機と、
    を備え、
    　前記ハイパバイザは、第１実行モードで外部割込みを処理する第１物理プロセッサと、第２実行モードで外部割込みを処理する第２物理プロセッサとを、前記複数の物理プロセッサから生成することができ、
    　前記第１物理プロセッサは、受け付けた全ての外部割込みを、前記第１物理プロセッサに割り当てられた前記仮想プロセッサ上の前記ゲストプログラムにより処理させ、
    　前記第２物理プロセッサは、受け付けた全ての外部割込みを、前記ハイパバイザでエミュレーション処理させ、
    　前記ハイパバイザは、前記外部割込みの宛先を前記第１物理プロセッサまたは前記第２物理プロセッサのいずれにするかを制御する、
    計算機。
  2. 　前記仮想プロセッサは、外部割込みを直接実行する直接実行方式、または、外部割込みを前記ハイパバイザによるエミュレーション処理を介して実行するエミュレーション方式のいずれかに設定することができ、
    　前記ハイパバイザは、
    　　前記複数の物理プロセッサから選択する所定の物理プロセッサに割り当てられた全ての仮想プロセッサを前記直接実行方式に設定することで、前記所定の物理プロセッサを前記第１実行モードで動作する前記第１物理プロセッサとし、
    　　前記複数の物理プロセッサから選択する他の所定の物理プロセッサに割り当てられた全ての仮想プロセッサを前記エミュレーション方式に設定することで、前記他の所定の物理プロセッサを前記第２実行モードで動作する前記第２物理プロセッサとする、
    請求項１に記載の計算機。
  3. 　前記ハイパバイザは、
    　　前記複数の物理プロセッサのうち、特定の仮想プロセッサに占有されて割り当てられている物理プロセッサを、前記所定の物理プロセッサとして選択する、
    請求項２に記載の計算機。
  4. 　前記ハイパバイザは、
    　　前記複数の物理プロセッサのうち、複数の仮想プロセッサに共有して割り当てられている物理プロセッサと、前記エミュレーション処理を必要とする外部割込みを１つ以上受け付ける物理プロセッサとを、前記他の所定の物理プロセッサとして選択する、
    請求項３に記載の計算機。
  5. 　前記複数の物理プロセッサは、前記ゲストプログラムを実行するための動作モードであるゲストモードと、前記ハイパバイザを実行するための動作モードであるホストモードとのいずれか一方の動作モードを選択することができ、
    　前記第１物理プロセッサは、外部割込みが届いた場合は、前記ゲストモードのままで、前記第１物理プロセッサに割り当てられた前記仮想プロセッサ上の前記ゲストプログラムにより処理させ、
    　前記第２物理プロセッサは、外部割込みが届いた場合は、前記ゲストモードから前記ホストモードへ遷移して、前記外部割込みを前記ハイパバイザに引き渡し、
    　前記ハイパバイザは、前記引き渡された外部割込みを前記エミュレーション処理し、各仮想プロセッサの中から選択した仮想プロセッサに前記外部割込みを伝達し、
    　前記外部割込みを伝達された仮想プロセッサは、前記複数の物理プロセッサのうち前記ゲストモードで動作する物理プロセッサが割り当てられた場合に、前記外部割込みを前記ゲストプログラムにより処理する、
    請求項４に記載の計算機。
  6. 　前記ハイパバイザは、前記第１物理プロセッサを前記第２物理プロセッサへ切り替えることができ、かつ、前記第２物理プロセッサを前記第１物理プロセッサへ切り替えることができる、
    請求項２～５のいずれか一項に記載の計算機。
  7. 　前記ハイパバイザは、前記第１物理プロセッサおよび前記第２物理プロセッサの中から選択した切替対象の物理プロセッサを指定した切替通知フラグをセットし、
    　前記切替対象の物理プロセッサは、前記ゲストプログラムを実行するための動作モードであるゲストモードから前記ハイパバイザを実行するための動作モードであるホストモードへ周期的に切り替えるための第１切替時間が経過すると、自プロセッサの動作モードを前記ゲストモードからホストモードへ切り替えてハイパバイザを実行し、
    　前記切替対象の物理プロセッサにより実行されるハイパバイザは、
    　　前記切替通知フラグがセットされているか判定し、前記切替通知フラグがセットされていないと判定した場合は、前記動作モードを前記ホストモードから前記ゲストモードへ移行し、
    　　前記切替通知フラグがセットされていると判定した場合は、前記切替対象の物理プロセッサに設けられた仮想プロセッサ上のゲストプログラムにより、外部割込みが処理中であるかを判定し、
    　　前記ゲストプログラムが外部割込みの処理中であると判定した場合は、前記第１切替時間よりも短い第２切替時間へ変更し、前記動作モードを前記ホストモードから前記ゲストモードへ移行し、前記第２切替時間が経過するのを待ち、
    　　前記ゲストプログラムが外部割込みを処理していないと判定した場合は、前記切替対象の物理プロセッサについて外部割込みを処理するモードを前記第１実行モードと前記第２実行モードとの間で切り替えるための実行モード切替処理を実行する、
    請求項６に記載の計算機。
  8. 　前記ハイパバイザは、前記実行モード切替処理において、前記第１実行モードから前記第２実行モードへ切り替える場合、前記切替対象の物理プロセッサに割り当てられている仮想プロセッサを前記エミュレーション方式に設定する、
    請求項７に記載の計算機。
  9. 　前記ハイパバイザは、前記実行モード切替処理において、前記第２実行モードから前記第１実行モードへ切り替える場合、
    　　前記切替対象の物理プロセッサで直接実行可能な割込み以外の割込みの宛先を、前記第２物理プロセッサのいずれかに変更し、
    　　前記第２物理プロセッサを宛先とする割込みのうち前記切替対象の物理プロセッサで直接実行可能な割込みの宛先を、前記切替対象の物理プロセッサへ変更し、
    　　処理中の割込みがある場合、その処理中の割込みを再発行し、
    　　前記切替対象の物理プロセッサに割り当てられている仮想プロセッサを前記直接実行方式に設定する、
    請求項７に記載の計算機。
  10. 　計算機の制御方法であって、
    　前記計算機は、複数の物理プロセッサと、前記複数の物理プロセッサのうちの少なくとも一つの物理プロセッサにより実現されるハイパバイザと、前記ハイパバイザにより制御される少なくとも一つの仮想計算機であって、少なくとも一つの仮想プロセッサと、前記仮想プロセッサにより実行されるゲストプログラムとを含む仮想計算機と、を備え、
    　第１実行モードで外部割込みを処理する第１物理プロセッサと、第２実行モードで外部割込みを処理する第２物理プロセッサとを、前記複数の物理プロセッサから生成することができ、
    　前記第１物理プロセッサが受け付けた全ての外部割込みを、前記第１物理プロセッサに割り当てられた前記仮想プロセッサ上の前記ゲストプログラムにより処理させ、
    　前記第２物理プロセッサが受け付けた全ての外部割込みを、前記ハイパバイザでエミュレーション処理させる、
    計算機の制御方法。
  11. 　　前記複数の物理プロセッサから選択する所定の物理プロセッサに割り当てられた全ての仮想プロセッサを、外部割込みを直接実行する直接実行方式に設定することで、前記所定の物理プロセッサを前記第１実行モードで動作する前記第１物理プロセッサとし、
    　　前記複数の物理プロセッサから選択する他の所定の物理プロセッサに割り当てられた全ての仮想プロセッサを、外部割込みを前記ハイパバイザによるエミュレーション処理を介して実行するエミュレーション方式に設定することで、前記他の所定の物理プロセッサを前記第２実行モードで動作する前記第２物理プロセッサとする、
    請求項１０に記載の計算機の制御方法。
  12. 　前記第１物理プロセッサは、外部割込みが届いた場合は、前記ゲストプログラムを実行するための動作モードであるゲストモードのままで、前記第１物理プロセッサに割り当てられた前記仮想プロセッサ上の前記ゲストプログラムにより処理させ、
    　前記第２物理プロセッサは、外部割込みが届いた場合は、前記ゲストモードから前記ハイパバイザを実行するための動作モードであるホストモードへ遷移して、前記外部割込みを前記ハイパバイザに引き渡し、
    　前記ハイパバイザは、前記引き渡された外部割込みを前記エミュレーション処理し、各仮想プロセッサの中から選択した仮想プロセッサに前記外部割込みを伝達し、
    　前記外部割込みを伝達された仮想プロセッサは、前記複数の物理プロセッサのうち前記ゲストモードで動作する物理プロセッサが割り当てられた場合に、前記外部割込みを前記ゲストプログラムにより処理する、
    請求項１１に記載の計算機の制御方法。
  13. 　前記ハイパバイザは、前記第１物理プロセッサを前記第２物理プロセッサへ切り替えることができ、かつ、前記第２物理プロセッサを前記第１物理プロセッサへ切り替えることができる、
    請求項１０～１２のいずれか一項に記載の計算機の制御方法。
PCT/JP2015/083846 2015-12-02 2015-12-02 計算機および計算機の制御方法 WO2017094132A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/083846 WO2017094132A1 (ja) 2015-12-02 2015-12-02 計算機および計算機の制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/083846 WO2017094132A1 (ja) 2015-12-02 2015-12-02 計算機および計算機の制御方法

Publications (1)

Publication Number Publication Date
WO2017094132A1 true WO2017094132A1 (ja) 2017-06-08

Family

ID=58796586

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/083846 WO2017094132A1 (ja) 2015-12-02 2015-12-02 計算機および計算機の制御方法

Country Status (1)

Country Link
WO (1) WO2017094132A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020008757A1 (ja) * 2018-07-03 2020-01-09 株式会社デンソー 仮想化環境におけるデバイスへのアクセス方法
CN113886018A (zh) * 2021-10-20 2022-01-04 北京字节跳动网络技术有限公司 虚拟机资源分配方法、装置、介质及设备
JP2022520160A (ja) * 2019-02-14 2022-03-29 インターナショナル・ビジネス・マシーンズ・コーポレーション フォールバックを伴う有向割り込みの仮想化方法、システム、プログラム
JP2022520526A (ja) * 2019-02-14 2022-03-31 インターナショナル・ビジネス・マシーンズ・コーポレーション 有向割り込みの仮想化のための割り込み信号伝達方法、システム、プログラム
US11822493B2 (en) 2019-02-14 2023-11-21 International Business Machines Corporation Directed interrupt for multilevel virtualization

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006209386A (ja) * 2005-01-27 2006-08-10 Hitachi Ltd 仮想計算機システム及びその外部割込み制御方法
US20110088030A1 (en) * 2005-02-25 2011-04-14 Vmware, Inc. Efficient Virtualization of Input/Output Completions for a Virtual Device
JP2012515995A (ja) * 2009-01-26 2012-07-12 アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド 各プロセッサに対して割り込み仮想化を支援するためのゲスト割り込み制御器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006209386A (ja) * 2005-01-27 2006-08-10 Hitachi Ltd 仮想計算機システム及びその外部割込み制御方法
US20110088030A1 (en) * 2005-02-25 2011-04-14 Vmware, Inc. Efficient Virtualization of Input/Output Completions for a Virtual Device
JP2012515995A (ja) * 2009-01-26 2012-07-12 アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド 各プロセッサに対して割り込み仮想化を支援するためのゲスト割り込み制御器

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020008757A1 (ja) * 2018-07-03 2020-01-09 株式会社デンソー 仮想化環境におけるデバイスへのアクセス方法
JP2020008933A (ja) * 2018-07-03 2020-01-16 株式会社デンソー 仮想化環境におけるデバイスへのアクセス方法
JP7196439B2 (ja) 2018-07-03 2022-12-27 株式会社デンソー 仮想化環境におけるデバイスへのアクセス方法
JP2022520160A (ja) * 2019-02-14 2022-03-29 インターナショナル・ビジネス・マシーンズ・コーポレーション フォールバックを伴う有向割り込みの仮想化方法、システム、プログラム
JP2022520526A (ja) * 2019-02-14 2022-03-31 インターナショナル・ビジネス・マシーンズ・コーポレーション 有向割り込みの仮想化のための割り込み信号伝達方法、システム、プログラム
JP7379502B2 (ja) 2019-02-14 2023-11-14 インターナショナル・ビジネス・マシーンズ・コーポレーション フォールバックを伴う有向割り込みの仮想化方法、システム、プログラム
US11822493B2 (en) 2019-02-14 2023-11-21 International Business Machines Corporation Directed interrupt for multilevel virtualization
US11829790B2 (en) 2019-02-14 2023-11-28 International Business Machines Corporation Directed interrupt virtualization with fallback
JP7398465B2 (ja) 2019-02-14 2023-12-14 インターナショナル・ビジネス・マシーンズ・コーポレーション 有向割り込みの仮想化のための割り込み信号伝達方法、システム、プログラム
CN113886018A (zh) * 2021-10-20 2022-01-04 北京字节跳动网络技术有限公司 虚拟机资源分配方法、装置、介质及设备

Similar Documents

Publication Publication Date Title
JP6130617B1 (ja) ハイパーバイザーを有するシステム
US8677356B2 (en) Adjunct partition work scheduling with quality of service attributes
JP5122597B2 (ja) 仮想プロセッサへの直接的なインタラプトの送信
WO2017094132A1 (ja) 計算機および計算機の制御方法
US9317453B2 (en) Client partition scheduling and prioritization of service partition work
US20160085568A1 (en) Hybrid virtualization method for interrupt controller in nested virtualization environment
CN107273199B (zh) 用于管理虚拟化环境中的中断的体系结构和方法
US8234429B2 (en) Monitoring interrupt acceptances in guests
US7222203B2 (en) Interrupt redirection for virtual partitioning
US9207939B2 (en) Performing shadowing function by virtual machine manager in two-level virtual machine environment
US8312195B2 (en) Managing interrupts using a preferred binding between a device generating interrupts and a CPU
JP2008305034A (ja) デバイス割り当て変更方法
WO2006039202A2 (en) Providing support for a timer assocated with a virtual machine monitor
US9424211B2 (en) Providing multiple virtual device controllers by redirecting an interrupt from a physical device controller
EP3704575A1 (en) A method, apparatus and system for real-time virtual network function orchestration
US20130054861A1 (en) Pessimistic interrupt affinity for devices
US11960924B2 (en) Inter-thread interrupt signal sending based on interrupt configuration information of a PCI device and thread status information
US20100174841A1 (en) Providing multiple virtual device controllers by redirecting an interrupt from a physical device controller
Li et al. Quest-V: A virtualized multikernel for high-confidence systems
US20230214245A1 (en) Online Migration Method and System for Bare Metal Server
CN114115703A (zh) 裸金属服务器在线迁移方法以及系统
WO2024008066A1 (zh) 一种基于云计算技术的服务器以及云系统
US20230251883A1 (en) Coordinating timer access for virtual machines using peripheral component interface cards
CN117215718A (zh) 一种国产处理器虚拟化适配调优方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15909762

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15909762

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP