JPH0363768B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to a dispatch method to a host system and a virtual machine in an integrated virtual machine system. A virtual computer is generally a plurality of virtual computers created on a real computer, each of which can independently run a different operating system at the same time. That is, in a virtual computer system, multiple virtual computers can be realized on one real computer. This is effectively used for the following purposes.

1. Improving the efficiency of operating system development 2. Supporting system migration 3. Easier system operation management In some cases, it may be necessary to partially modify the hardware. There are two ways to implement VMC: directly on a real computer (Figure 1) and under a general-purpose operating system (Figure 2).

IBM's virtual computer system as shown in Figure 1
According to VM/370, it is called a CP type virtual computer system, and a virtual computer system like the one shown in Figure 2 is called an integrated virtual computer system. In the integrated type, as shown in Figure 2, the general-purpose operating system that runs on the actual computer is called the host OS, the processes that are directly executed under its control are called the host processes, and the entire system is called the host system.

Conventionally, most virtual computer systems have been developed as CP types, including the widely used VM/370. However, although integrated virtual computer systems also have problems with the integrity of hardware virtualization, they have virtually no problems in practice, and have the following advantages over CP systems.

1. Since the host OS and host processes are executed on real hardware, business processes assigned to the host system can be executed without the overhead of virtualization.

2. When developing and modifying the VMC, you can benefit from the various program development facilities of the host OS, and since the VMC itself can use the functions of the host OS, it is easy to implement, resulting in significant labor savings in development and maintenance. can be expected.

In particular, runtime overhead due to virtualization is a major problem with the CP type, and various improvements have been made, but it is essentially impossible to eliminate with the CP type. For example, when migrating a system, if a new system is being developed on the same hardware while continuing online service on the old system, it is desirable to provide maximum performance for the system currently in service. . In this case, the CP type cannot avoid extra overhead, but if the integrated type is executed as a host system, this system can avoid the overhead of virtualization.

Although integrated virtual computer systems have the above-mentioned advantages, conventionally there has been a problem in the distribution of processing power between the host system and the virtual computers. That is, conventionally, dispatch, which is the allocation of real CPU resources to virtual machines, has been performed by treating individual host processes and virtual machines in the same way.
Specifically, is a host process representative of the virtual machine prepared, and when this process is dispatched, the corresponding virtual machine runs as an extension of that process? A method was used in which the VMC and all virtual machines were represented as a whole by one process, and when a dispatch was made to that process, the dispatch was dispatched to an individual virtual machine within that process. For this reason, it was not possible to allocate processing power by treating individual virtual machines and the entire host process group, which should originally be on the same level, on the same level. Even if an attempt was made to use time slicing to equally distribute processing power to the entire host process group and to individual virtual machines, it was difficult to achieve this using only the conventional time slicing mechanism. The inability to freely control the distribution of processing power between the host system and the virtual machine has narrowed the scope of application of the integrated virtual machine system.

An object of the present invention is to make it possible to divide host processes into a high-priority group and a low-priority group in realizing an integrated virtual computer system having the above-mentioned advantages. A typical job running on a virtual machine receives the same level of service as any other virtual machine as a whole, and only processes that are required for control within the host, especially those that are part of the host operating system, receive the same level of service as any other virtual machine. The goal is to provide a method that allows you to receive priority services. By implementing this method, an integrated virtual computer system can either use the host as a low-overhead virtual computer with top priority, or use a single virtual computer with low overhead but on the same level as other virtual computers. It can also be used as a server, making it possible to realize the desired distribution of processing power.

In this invention, a boundary value is set for the dispatching priority of a host process, and a host process with a higher priority is called a privileged process, other host processes are called a general process, and only the general process is executed. Consider a virtual computer that can be used to host computers, and this is called a host virtual computer. Then, the privileged process is given real CPU resources with priority over all virtual machines, and only when the privileged process is not requesting real CPU resources, it is given to the host virtual machine or a general virtual machine.
Real CPU according to its virtual machine priority
The above objectives can be achieved by providing a dispatch mechanism that provides resources.

First and second embodiments of the present invention will be described below with reference to the drawings. In the first embodiment, a virtual computer having exactly the same architecture is installed on a real computer in which a process dispatcher that dispatches processes is realized as part of the real calculation function by microprogram control. This is an example of implementation.

Here, a process dispatcher, which is part of the real computer functions, is used not only for the host system but also for the virtual machine. In this architecture, all software runs as processes, so
When an interrupt or the like occurs, the system state is saved by hardware to the process control block corresponding to the process that was running at the time. Therefore, if you assign a real CPU to a virtual machine, that is, dispatch it, that virtual machine will always start running from the process dispatcher.
First you need to run a process dispatch.

FIG. 3 is a block diagram showing the first embodiment. The CPU 2 is provided with a register 21 for storing the number of the virtual machine under execution, a register 22 for holding the ID of the process under execution, and a register 23 for holding the boundary value of the dispatching priority for the host process. A boundary value can be specified as an operand of an instruction to activate the virtual machine mechanism, and when this instruction is executed by the host system, the specified value is set in the register 23. A host process that is given a higher (lower) priority than the value held by the register 23 is treated as a privileged process, and a host process that is given a priority that is equal to or lower (larger) than the value held in the register 23 is treated as a general process. Become. The storage device 1 has a dedicated area for the host system and an area for each virtual machine. A ready virtual machine list RVML for managing virtual machines executable by the CPU 2 is prepared in the host system exclusive area. This list includes virtual machine control blocks representing virtual machines 1 to n.
In addition to VMCB1 to VMCBn, VMCB0 representing the host virtual machine can be registered. In the ready virtual machine list, among VMCB0 to n, only those that are in a state where the corresponding virtual machine can be executed if a real machine is allocated, that is, in a ready state, are listed.
They are linked in descending order of priority value listed on the VMCB. First VMCB
(which generally corresponds to a running virtual machine) is pointed to by the ready virtual machine top pointer RVT. Generally, a host virtual machine is treated as being in a ready state if at least one process is in a ready state. In addition, the host system dedicated area contains the host system ready process list.
RPL _h is also retained. This is a process control block that corresponds to a process between host systems that can be executed if a real computer is allocated.
PCB with high (small) process priority
This is a list that is managed by linking in order. The first PCB is the ready process top pointer RPT.
It is pointed from. Similar ready process list
RPL _i is held in each storage area for each virtual machine. Each PCB has a dispatching priority for the corresponding process, and finally
The values of registers, etc. at the time the CPU was taken away are stored.

The virtual machine control block VMCB holds information such as the location of the storage area for the numerical virtual machine, which indicates the priority of the corresponding virtual machine. This priority value is given as an operand of a virtual machine startup instruction, which is an instruction for starting the virtual machine for the first time, and is set as the above instruction is executed. When a virtual machine that was in an idle state becomes executable due to an input/output end interrupt, etc., it responds to that virtual machine.
VMCB _i (i≠0) is held on top of VMCB i (i≠0), and if an executable general process is generated by a V operation from a privileged process when no general process is in an executable state, VMCB0 is held above it. The virtual machines are registered on the ready virtual machine list RVML according to their priority values.

Then, the virtual machine dispatcher is activated. The virtual machine dispatcher is also activated when the virtual machine that was being executed becomes idle due to waiting for input/output to complete, or when the time slice is used up. When the virtual machine dispatcher is activated, the address space has been switched to the host system.

Note that the virtual machine priority described above can be changed at any time after starting the virtual machine. This makes it possible to dynamically control the distribution of processing power between virtual machines according to the operating status of each virtual machine, and to temporarily give priority to a particular virtual machine to increase its processing speed only during that time. It becomes possible. The virtual machine priority changing function is provided as a command, and the target virtual machine number and new priority are specified as operands. This command is executed as follows. First, correspond to the specified virtual machine.
Change the virtual machine priority in VMCB to the specified value. The target VMCB has been removed from the virtual machine ready list RVML. In other words, if it was in an idle state, it ends now.
If it is not idle, if there is a running virtual machine, it is returned to the ready state, and then the target VMCB is removed from the virtual machine ready list RVML and inserted into the location corresponding to the new priority. Next, control is transferred to the virtual machine dispatcher.

Next, the operation of the virtual machine dispatcher (VM dispatcher) will be explained with reference to the flowchart shown in FIG. When the virtual machine dispatcher is started, the host system's ready list RPL _h
If there is a PCB on the list, get the priority of the first registered process. If this value is smaller than the value held in the register 23, -1 is set in the register 21 and control is transferred to the beginning of the process dispatcher (this means that the VM has been dispatched to the host system). If the priority of the head process is equal to or greater than the value held in the register 23, or if RPL _h is empty, the VMCB registered at the head of the ready VM list RVML is obtained. The number (any one of 0 to n) of the virtual machine pointed to by the obtained VMCB is set in the register 21, the address space is switched according to the contents of the VMCB, and control is transferred to the beginning of the process dispatcher. This means that the virtual machine has been dispatched. If no VMCB is registered on RVML, control is returned to the beginning of the virtual machine dispatcher, and while looping,
Wait for VMCB to be registered.

In this example, the process dispatcher is a part of the virtualized computer function, so even in a virtual computer environment, it can perform the same function as a conventional dispatcher on a real computer from the perspective of the program executed within it. Must do. It is assumed that the conventional dispatcher of the actual computer has the function shown within the dotted line in FIG. In this embodiment, the functions shown in FIG. 4 are added to this system to provide a dispatcher in a virtual computer environment. A conventional process dispatcher searches the process ready list and, if no process is registered, repeats the search and waits for one to be registered. If there are registered processes, the first one is extracted and dispatched to that process. In other words, set the process ID in the register 22, and write the corresponding process control block PDB.
The values of the registers that were saved are restored and the execution of the process is resumed.

In this embodiment, when the ready process to be dispatched is selected, the contents of register 21 is -1 (privileged process running), and the priority of this process is not smaller than the value held in register 23 (privileged process ), then
Control is transferred to the virtual machine dispatcher without executing the process dispatch. Also, register 21
If the content of is 0 (general process in progress) and the priority of the selected process is lower than the value held in register 23 (privileged process), register 21 is set to -1 and the process is transferred directly to the selected process. Dispatch.

The above case may occur when a process is switched while the host system is running.

In other cases, it operates as a conventional process dispatcher. When control is passed from the above process dispatcher to the VM dispatcher, the host system (virtual machine 0)
When a process is selected as a dispatch target, the register 21 is set to 0 and then it enters the process dispatcher again, so this time the first process (general process) on the host system's ready process list is dispatched. Become. Also, when the process ready list is empty, instead of repeating the search for ready processes, the running virtual machine is removed from RVML, the address space is switched to the host, and control is immediately transferred to the virtual machine dispatcher (Figure 4). By doing so, when a virtual computer becomes idle, it is possible to immediately switch to running another virtual computer without wasting real computer time.

Next, a second embodiment will be described. This embodiment can be applied to a case where each virtual machine is provided with a process dispatcher, such as a case where the process dispatcher is created as software. Here, the process dispatcher of the host OS is modified to add virtual machine dispatcher functionality. Since there is no need to modify the process dispatcher in a general virtual machine,
It is possible to operate a virtual machine controlled by an OS with an arbitrary process dispatcher.

The block diagram shown in FIG. 3 basically has the same configuration as the first embodiment, but the method for configuring the ready process list RPL _i of a general virtual machine,
The format, contents, etc. of the process control block PCB may be different from the host's ready process list RPL _h and the PCB. In addition, the virtual machine control block
VMCB has a save area for the state of the virtual machine. When control is taken away from a virtual machine other than the host virtual machine, the state of the virtual machine at that time is saved to the VMCB.

The virtual machine dispatch in this embodiment is as follows:
This is achieved by restoring the state saved in the VMCB to the registers of the actual computer. Unlike the first embodiment, it is not necessary to restart execution of the virtual machine by activating a process dispatcher within the virtual machine. However, for the host virtual machine, the execution of the virtual machine is restarted by executing the process dispatcher of the host system.

This embodiment uses the dispatcher function (referred to as HVP dispatcher) shown in the flowchart of FIG.
Characterized by. This will be explained below with reference to FIG. The HVP dispatcher is accessed at the same trigger as when control is passed to the process dispatcher in a conventional host system (such as when a process being executed in the host system completes an interrupt process that is in a wait state). First, refer to the ready process list RPL _h of the host system, and if there is a PCB on the list, look at the first process, and if the priority of this is smaller than the value held in register 23 (privileged process), Dispatch this process.

The priority of the head process is in register 23
equal to or greater than the value held by (general process)
Or, if the host's ready process list is empty, check whether the virtual machine control block VMCB is registered on the ready virtual machine list RVML. If none are registered, the process returns to the HVP dispatcher entrance and loops until an interrupt occurs. If VMCB exists, get the first one and this VMCB
If it is not VMCB0, dispatch to the corresponding virtual machine. If it is VMCB0, check whether the process is registered in the host ready process list RPL _h . If it is registered, dispatch to the first process. If RPL _h is empty, remove VMCB0 from the ready virtual machine list RVML and return to the RVML search to dispatch to another virtual machine.

As explained above, according to the present invention, it is possible to realize a virtual computer system that can freely control the distribution of processing power between a host system and a general virtual computer in an integrated virtual computer system with low overhead. It becomes possible.

[Brief explanation of drawings]

Fig. 1 is a block diagram showing the conceptual configuration of a CP type virtual computer system, Fig. 2 is a block diagram showing the conceptual configuration of the integrated virtual computer system targeted by the present invention, and Fig. 3 is a block diagram showing the conceptual configuration of the integrated virtual computer system targeted by the present invention. FIG. 4 is a block diagram showing the configuration of an embodiment of the invention, FIG. 4 is a flowchart showing the operation of the virtual machine dispatcher and process dispatcher in the first embodiment, and FIG. 5 is a virtual diagram of the host system in the second embodiment. 3 is a flowchart showing the operation of a computer and a process dispatcher. In the figure, 1 is a storage device, 2 is a CPU, 21
22 is an executing process ID holding register, and 23 is a boundary priority holding register.

Claims (1)

[Scope of Claims] 1. In an integrated virtual computer system in which a plurality of processes (host processes) and a plurality of virtual machines are executed under the control of a host operating system executed on a real computer, the host process means for setting and maintaining a boundary value regarding the dispatching priority of a single virtual computer (host virtual A means for setting a virtual machine priority for each virtual machine including this virtual machine and maintaining said priority, and a means for maintaining said priority for each virtual machine, and if a host process with a dispatch priority higher than the above boundary value is waiting for dispatch, all virtual machines are Dispatch is given to the host system with priority over the computer, and if there is no host process with a dispatch priority higher than the above-mentioned boundary value, all virtual machines waiting for dispatch, including the host virtual machine, are dispatched to the host system. 1. A dispatch control method in an integrated virtual computer system, comprising a virtual machine dispatch mechanism that dispatches based on computer priority. 2. In the integrated virtual machine system according to claim 1, the virtual machine dispatch mechanism has a function of detecting that a virtual machine running becomes idle and immediately starting a virtual machine dispatcher. Dispatch control method. 3. A dispatch control method in an integrated virtual computing system according to claim 1, further comprising a virtual machine priority change command and its execution function as means for setting the virtual machine priority and holding the priority.