JPH0290331A - Interprocessor communication instruction processing device for virtual computer system - Google Patents

Abstract

(57) [Abstract] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a virtual computer system, and particularly to processing of inter-processor communication commands issued in a virtual computer having a multiprocessor configuration.

[Conventional technology]

In the virtual computer system (hereinafter abbreviated as VMS),
One live-shooting computer is controlled in a time-sharing manner and operates as if it were a different computer in different time slots. A computer that is simulated in each time slot is called a virtual computer (hereinafter abbreviated as VM). What are the resources of the actual computer?

Required resources that are allocated to each VM in a time-division or space-division manner and are not provided in the actual computer are provided by simulation. Such allocation and simulation of resources is performed using a virtual computer controlled program.
This is realized by software called VMCP (hereinafter abbreviated as VMCP). One of the resources allocated in a time-sharing manner is a processor (so-called CPU). The real computer may be a multiprocessor system with multiple CPUs, or one or more VMs may be a multiprocessor system. V with multiprocessor configuration
An example of a processor allocation mechanism for constructing a VMS containing M on a real computer with a multiprocessor configuration is disclosed in Japanese Patent Laid-Open No. 5
It is described in 9-167756 and 62221041.

VMS is realized via VMCP, and VMS
MCP intervention creates overhead.

VM by reducing the overhead caused by VMCP intervention.
Various improvements have been proposed to speed up S. For example, Japanese Patent Publication No. 1-49352 describes speeding up processing of state control commands and interrupts;
No. 22825 describes speeding up address conversion, Japanese Patent Application Laid-Open No. 150140/1982 describes speeding up processing of input/output instructions, and Japanese Patent Application No. 62-1 filed by the present applicant describes speeding up the processing of input/output instructions.
No. 04131 describes speeding up timer interrupt control. However, these improvements are not directed to solving problems specific to multiprocessor configured VMs.

[Problem to be solved by the invention]

One of the instructions specific to multiprocessor systems is CP
All orders are sent between U. In a conventional VMS, all instructions issued between CPUs in a VM with a multiprocessor configuration are processed by simulation using the VMCP as described below.

Assume that a VM with a multiprocessor configuration is set on a real computer with a multiprocessor configuration.

When a first virtual CPU running on a real CPU (the logical CPU that constitutes a VM is hereinafter referred to as a virtual CPU) executes all instructions to the second virtual CPU, a trap occurs. , the running of the first virtual CPU is interrupted, and the VM
CP is called. The VMCP refers to the virtual CPU state information that it manages, checks the state of the second virtual CPU, and if it is not running, uses this inter-CPU communication for the state information that is being saved. After executing all command lines and reflecting the results in the state information of the first virtual CPU,
Let U resume running. On the other hand, if the second virtual CPU is running on another real CPU, the VMCP interrupts the running of this second virtual CPU, saves its state to the main memory, and then performs the same process as above. Then, the second virtual CPU is restarted.

Such simulation by VMCP introduces significant overhead, especially if the destination virtual CPU is running, adding the overhead of suspending and resuming its running.

The overall objective of the present invention is to
The purpose of the present invention is to process inter-CPU communication commands issued in a CPU with minimum overhead.

One specific object of the present invention is to process such inter-CPU communication commands without intervention from the VMCP.

Another specific object of the present invention is to use such a CPU.
The object of the present invention is to process intercommunication commands without interrupting the execution of a destination virtual CPU.

Another specific object of the present invention is to facilitate the start of running of a destination virtual CPU that is not running.

[Means to solve the problem]

According to the present invention, a mechanism for accessing virtual CPU tJ state information of a destination virtual CPU specified by an inter-CPU communication command and a running state of the destination virtual CPU indicated by the accessed virtual CPU state information are provided. The mechanism that executes the communication requested by the inter-CPU communication instruction to either the virtual CPU state information of the virtual CPU that is not the destination virtual CPU or the real CPU on which the destination virtual CPU is running is a part of the instruction execution circuit of the real processor. It is provided as hardware or firmware.

In addition, if the destination virtual CPU that is not running becomes able to run as a result of an interrupt request by an inter-CPU communication command, the destination virtual CPU
A mechanism for advancing U's activation priority can be provided in a similar manner.

Furthermore, a mechanism may be similarly provided to request the real CPU in an idle state to start a virtual processor. This mechanism is preferably configured to operate after the travel priority advancement mechanism described above.

[Effect]

When an inter-CPU communication command is issued from a virtual CPU running on a certain real CPU, this command is executed by the virtual CPU according to the present invention.
The PU status information access mechanism and execution mechanism execute a single instruction execution process on a real CPU running by the destination virtual CPU or its saved status information. V
Therefore, the virtual CPU
The overhead for the execution of the VMCP, including suspending and resuming the running of the VMCP, is significantly reduced to the overhead only for accessing virtual CPU state information by hardware or firmware.

Similarly, raising the startup priority of the destination virtual CPU and requesting a real CPU in an idle state to start the virtual CPU is performed as part of the execution process of the inter-CPU communication command without intervention from the VMCP. This facilitates the running of destination virtual CPUs that were not running without significant overhead, thus improving the efficiency of the VMS.

〔Example〕

FIG. 1 shows in block diagram form one embodiment of the invention. The real computer includes a main memory 1 and a plurality of CPU10s that share the main memory 1. However, in order to prevent the diagram from becoming complicated, 1
Only one CPU is shown. Furthermore, to simplify the explanation, it is assumed that all CPUs have the same structure.

In the main memory 1, a VM program group 2, VMS management information 4, and VMCP 5 are stored. The VM program group 2 is a collection of programs executed by each VM. However, the VM program group 2 does not need to be resident in the main memory 1, and the necessary portions of the VM's program may be transferred from an auxiliary memory (not shown) when each VM starts running. The VMS management information 4 includes VP management information 6, an RP status table 7, and various virtual Cs, which will be detailed later.
It includes a VP queue 8 that determines the activation priority of PUs. V.M.
The CP 5 includes a dispatcher 9 which is a sequence of instructions for processing to start running the virtual CPU.

FIG. 2 shows details of the VP management information 6. Figure 2(a)
Referring to , a VP state descriptor address list (hereinafter referred to as VP list) 61 is prepared for each VM, and a vP state descriptor 62 is prepared for each virtual CPU that constitutes this VM. . The vP list 61 is
Identification number (VPNα) of each virtual CPU and corresponding vp
and a pointer to the state descriptor 62. The contents of the vP state descriptor 62 include, as shown in FIG. 2(b), a running flag 621 indicating whether the corresponding virtual CPU is running on the real CPU, and a running flag 621 that indicates whether the corresponding virtual CPU is running on the real CPU, and a running flag 621 that is assigned when the corresponding virtual CPU is running on the real CPU. Real CP
It includes an identification number (RPNα) 622 of U, a communication queue header 623 pointing to the head of the communication queue to be described later, a pointer 624 to the VP list 61, and a status save area 625. When the running of each virtual CPU is interrupted, the contents of the PSW and other registers, flip-flops, etc. in the real CPU indicating its status are stored in the save area 625,
Thereafter, when the virtual CPU resumes running, the contents of the save area 625 are restored into the real CPU.

As shown in FIG. 3, the RP status table 7 includes, for each real CPU, an active flag 71 that indicates whether it is in an active state or an idle state, and if it is active, a virtual CPU that is running there. identification number 72 of the virtual CPU, and identification number 7 of the VM to which the virtual CPU belongs.
3.

Returning to FIG. 2(a), the communication queue 63 is connected to each virtual CPU.
This is a queue for inter-CPU communication interrupts whose processing is pending in the communication queue element 631, and is made up of a chain of communication queue elements 631. Each communication queue element 631 is
In response to one interrupt request caused by an inter-CPU communication command,
It consists of the identification number of the virtual CPU that executed the corresponding inter-CPU communication instruction and a pointer to the subsequent queue element.

The communication queue ladder 623 in the vP status record link points to the first communication queue element.

In the main memory 1, a communication area 3 is further provided which is used for exchanging information between the CPUs. When an inter-CPU communication instruction is used to request a specific operation of the destination CPU, a code specifying this specific operation is written to a predetermined position in the communication area 3, and then the inter-CPU communication instruction A communication command is issued and causes an interrupt to the destination CPU. This destination CPU can learn the requested operation by accessing the predetermined location.

The real CPU 10 includes a main memory access circuit 11, an interrupt processing circuit 12, a register group 13, and an instruction execution circuit 14. The register group 13 holds information necessary for realizing VMS, and in particular, in relation to the present invention, the identification number 131 of the virtual CPU currently running on the CPU and the vp state descriptor 62 of this virtual CPU. address 132, address 133 of RP status table 7, and address 1 of vP queue 8.
34 and the address 135 of the dispatcher 9.

Regarding the interior of the instruction execution circuit 14, only the parts directly related to the present invention are shown. In this example, C
The communication command between PUs is SIGP (Signal Proc
essor) command. A 5IGP decode output from an instruction decoder (not shown) activates a 5IGP sequence circuit 141.

The 5IGP sequence circuit 141 communicates with the VP test circuit 142 that tests the VP management information 6 and performs communication operations specified by the 5IGP command (sending interrupt requests, extracting state information, etc.)
5 IGP simulation circuit 1 that executes VP management information 6
43, a priority advance circuit 144 that advances the running priority of the virtual CPU, an RP test circuit 145 that tests the RP status table 7, and executes the communication operation specified by the 5IGP command to the real CPU. SIGP communication circuit 1
46.

Next, processing of an inter-CPU communication (SIGP) command by the apparatus shown in FIG. 1 will be described. FIG. 4 is a flowchart 1 of this process, and in this flowchart, "vp"
"RP" means a virtual CPU, and "RP" means a real CPU.

When the virtual CPU running on the real CPU 10-H encounters a 5IGP instruction, an instruction decoder (not shown) executes the 5IGP instruction.
The 5IGP sequence circuit 141 is activated by the P output. The operation sequence described below proceeds under the control of the 5IGP sequence circuit 141. First, the vP test circuit 142 uses the current Vl state descriptor address 132 to check the vp state descriptor 62 corresponding to the running virtual CPU.
and furthermore, pointer 624 to that vP list 1.
The vP list 61 is accessed according to the 5IGP command to search for the destination virtual CPU specified in the 5IGP command (101).

If the destination virtual CPU is not found in the vp list 1-61, the absence of the destination CPU is reported to the VM program (102), for example by setting a particular flip-flop, and the execution of the 5IGP instruction is then terminated. do. In other words, the same result as when the destination CPU does not exist in the actual computer can be obtained.

If the destination virtual CPU exists, the vp test circuit 142 accesses the vp state descriptor corresponding to the destination virtual CPU according to the pointer in the vP list, and checks its running flag 621 (103).

If this running flag indicates "running", the destination virtual CPU
The 5IGP instruction is executed on the real CPU that is running (104.). To be more specific, the ■P test circuit 142 is as follows.
VT) Reads the real CPU identification number 622 from the state descriptor of the destination virtual CPU, and the SiGP communication circuit 146 secures a communication path to the real CPU identified by this identification number and transmits the communication via it. and executes a predetermined communication operation (sending an interrupt request, extracting status information, etc.). Extraction of state information is performed by extracting specified state information of the destination real CPU (for example, PS
5IGP communication circuit 146
is accomplished by direct reading. At this point, execution of the 5IGP instruction ends. When an interrupt request is issued,
In the destination real CPU, if the running virtual CPU is in an interrupt-enabled state, one interrupt is generated and access to communication area 3 is performed, and if it is in an interrupt-disabled state, the interrupt request is put on hold. Ru. In this way, except for the replacement of the destination address, the 5IGP instruction is processed in the same manner as in a real computer.

If the destination virtual CPU is not running, the corresponding ■P
5 IGP communication is executed for the state descriptor 62 (1
05). Specifically, if state information extraction is specified, the SIGP simulation circuit 143 accesses the state save area 625 of the destination vp state descriptor and reads the desired state information therefrom. On the other hand, if sending an interrupt request is specified, the interrupt request is placed in the communication queue 63 because a virtual CPU that is not running cannot immediately respond to it. That is, the 5IGP simulation circuit 143 reads the current VPNα 131, generates a communication queue element 631 containing it as an element, and adds this to the end of the communication queue 63 chained to the vP state descriptor of the destination virtual CPU. Thereafter, when the virtual CPU starts running, the dispatcher 9 takes out the queue element from the communication queue 63 and sets its contents in the interrupt pending circuit in the interrupt processing circuit 11 of the real CPU. If the virtual CPtJ becomes interrupt-enabled while it is running, the pending interrupts are processed sequentially, and when running is interrupted, the interrupts left in the pending state are saved by a state saving mechanism (not shown). It is saved as the communication queue 63 again.

Next, the vP test circuit 143 determines whether the destination virtual CPU that is not running is in an interrupt-enabled state and is in a wait state.
) state (106).

A CPU in a state such as 1 can transition to an execution state in response to the arrival of an interrupt request. Therefore, the destination virtual CPU
If the vehicle is in such a state, it is desirable to move up its activation priority to facilitate the start of driving. Therefore, the priority advance circuit 144 accesses the vP queue 8 by referring to the VP queue address 134, and
The activation priority (in-queue ranking) of is raised to the highest possible value (107).

Additionally, the RP test circuit 145 accesses the RP state table 7 using the RP state table address 133;
A real CPU in an idle state is searched for (108). If a real CPU in an idle state is found, the RP test circuit 145 writes a code specifying execution of the dispatcher 9 to the communication area 3, and the 5IGP communication circuit 146 sends an interrupt request to the real CPU (109). ,5IGP
Execution of the instruction ends. The real CPU that received this interrupt request
executes the dispatcher 9 by referring to the dispatcher address 135, and as a result, the virtual CPU waiting at the head of the vP queue 8 starts running on this real CPU.

The various circuits 141 to 146 for executing the 5IGP instructions are:
It can be replaced with a microprogram and a group of circuits controlled by it. Also, if a sufficient number of registers or equivalent internal memory is available, vP
The list pointer or the VP list itself may be kept inside the CPU, which further reduces the overhead.

〔Effect of the invention〕

As is clear from the above, according to the present invention, all instructions issued from a VM between CPUs are processed by hardware or firmware as a single instruction execution process,
There is no intervention by VMCP.

Similarly, raising the startup priority of a virtual CPU that becomes runnable as a result of passing all command lines between CPUs, and requesting virtual CPU startup to a real CPU that is in an idle state,
As part of the entire CPU-to-CPU instruction line process, it is performed without VMCP intervention.

Therefore, the overhead associated with issuing CI) U-U communication instructions is significantly reduced and the throughput of the VMS is improved.

[Brief explanation of the drawing]

FIG. 1 is a block diagram of an embodiment of the present invention, FIG. 2 is a diagram showing an example of VP management information, FIG. 3 is a diagram showing an example of an RP status table, and FIG. 1 is a flowchart of all instructions executed by the apparatus of FIG. 1; FIG. 5... Virtual computer control program, 6... Virtual CP
U state information, 7... Real CPU state information, 8... Virtual c
Queue indicating pu startup priority, 132...Address of virtual CPU status information of running virtual CPU, 133.
- Address of real CPU status table, 134... Address of startup priority queue, 141... Processing sequence control circuit for all instructions passed between CPUs, 142... Virtual CPU status information inspection circuit, 143 - Virtual A circuit that performs inter-CPU communication regarding CPU status information, 144... A circuit that advances the startup priority of the virtual CPU, 145...
Real CPU status information inspection circuit, 146... A circuit that performs inter-CPU communication with respect to the real CPU.

Claims (1)

[Scope of Claims] 1. A virtual machine system including a virtual machine having a plurality of virtual processors under the control of a virtual machine control program that manages resource allocation to each virtual machine. In a computer having a storage device for holding virtual processor state information including a running state and a saved processor state, and a plurality of processors sharing this storage device, each processor responds to decoding of an inter-processor communication command. means for accessing virtual processor state information of a destination virtual processor specified by this instruction, and when said accessed virtual processor state information indicates that said destination virtual processor is running on another processor; first execution means operative to perform communication requested by the inter-processor communication instruction to the other processor; and when the accessed virtual processor state information indicates that the destination virtual processor is not running; a second execution means operable to perform the communication required by the inter-processor communication instruction with respect to the virtual processor state information, thereby processing the inter-processor communication instruction without intervention of a virtual machine control program; Interprocessor communication instruction processing device. 2. In claim 1, the second execution means reads required information from the accessed virtual processor state information when the inter-processor communication instruction requests acquisition of processor state information; An interprocessor communication instruction processing device that adds a record of the arrival of a corresponding interrupt request to the accessed virtual processor state information when requesting an interrupt request. 3. In claim 1 or 2, the accessed virtual processor state information indicates that the destination virtual processor is not running and becomes capable of running due to the arrival of an interrupt request, and the inter-processor communication command is An inter-processor communication instruction processing device, further comprising means that operates when requesting an interrupt to advance the activation priority of the destination virtual processor. 4. In claim 3, the storage device further stores real processor state information indicating whether or not each processor is in an idle state, and the real processor state information is checked and a virtual processor is assigned to a processor in an idle state. An inter-processor communication command processing device, further comprising means for requesting activation of a processor. 5. The inter-processor communication command processing device according to claim 4, wherein the activation requesting means operates after the activation priority raising means.