JP2001236237A - Method for constituting multi-os - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method for constituting a multi-OS for reducing the generation of overhead without necessitating any special hardware. SOLUTION: A physical memory 102 is divided for each of plural operating systems. An interruption management program independent of the operating system accepts all outside interruption, and decides which the operating system interruption handler should be started according to an interruption factor. A timing in which the interruption handler should be started is decided according to the executed state of the operating system, and the interruption handler of each operating system is started based on that.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a multi-OS configuration method for operating a plurality of operating systems on a single computer.

[0002]

2. Description of the Related Art Generally, in a computer system, one operating system is operated on the computer, thereby managing computer resources such as a processor, a memory, and a secondary storage device of the computer, so that the computer can operate efficiently. The resource schedule is implemented as follows. There are various types of operating systems. There are various types such as those that are excellent in batch processing, those that are excellent in TSS (Time Sharing System), and those that are excellent in GUI (Graphical User Interface).

[0003] On the other hand, there is a need to execute these plural operating systems simultaneously on one computer. For example, in a large-scale computer, there is a demand that an operating system for executing online processing associated with actual work and an operating system for development be operated by one computer. Alternatively, the GUI
There is also a demand to run an operating system with a well-equipped operating system and an operating system with excellent real-time performance at the same time.

However, it is assumed that each operating system manages computer resources independently, and it is difficult to realize coexistence of a plurality of operating systems without any mechanism.

As a mechanism for operating a plurality of operating systems on one computer, there is a virtual computer system realized by a large computer. In the virtual machine method,
The virtual machine control program occupies and manages all hardware resources, and virtualizes them to form a virtual machine.
The control unit configuring the virtual machine virtualizes a physical memory, an input / output device, an external interrupt, and the like.

For example, the divided physical memory behaves as if it were a physical memory starting at address 0 for a virtual machine, and the device number for identifying an input / output device is also virtualized. Further, in the virtual computer system, the storage area of the magnetic disk is also divided to realize the virtualization of the magnetic disk device.

Each operating system is scheduled by a control program to be executed on a virtual machine constructed by the control program.

[0008]

In the virtual computer system of the conventional large computer as described above, since the computer resources are to be completely virtualized and divided, the control part constituting the virtual computer becomes complicated. There is a problem.

In addition, without special hardware support, privileged instructions such as control register setting and input / output instructions issued by an operating system operating on a virtual machine must be emulated by a virtual machine control program. . For this reason, there is also a problem that overhead increases. In fact, in a large-scale computer on which a virtual computer is mounted, a special processor function and hardware such as microcode are added for the virtual computer to reduce overhead.

As described above, the virtual computer system is complicated because it aims to completely virtualize computer resources, and requires a special hardware mechanism for improving the performance of the virtual computer. Become.

On the other hand, as a technique for providing an interface of a plurality of operating systems on one computer, there is a technique called a microkernel. In the microkernel, an operating system server that provides an operating system function to be shown to a user is built on the microkernel. The user utilizes computer resources via the server. By preparing a server for each operating system, various operating system environments can be provided to the user.

However, in the microkernel system, it is necessary to newly construct an operating system server according to the microkernel. Often, you will need to change your existing operating system to run on a microkernel, but scheduling,
The core part of the kernel, such as memory management, is also changed, so that there are many changes, and since the change extends to the core part of the operating system, the change operation is complicated and not easy.

The operating system server uses the service of the microkernel,
This is not a normal operating system, resulting in overhead and reduced performance.

[0014] An object of the present invention is to solve such problems in the prior art and realize simultaneous and parallel execution of a plurality of operating systems on one computer without using special hardware. It is in.

Another object of the present invention is to suppress the occurrence of overhead due to emulation of privileged instructions when operating a plurality of operating systems on one computer.

[0016]

In order to achieve the above-mentioned object, in the multi-OS configuration method according to the present invention, a physical memory is divided for each of a plurality of operating systems. An interrupt management program independent of the operating system accepts all external interrupts and determines which operating system's interrupt handler to activate based on the interrupt factor. The timing of activating the interrupt handler is determined according to the execution state of the operating system, and the interrupt handler of each operating system is activated based on the timing, whereby a plurality of operating systems are operated by one computer.

According to the present invention, a function that complements the first operating system can be easily added, and a high-performance computer system can be constructed. Furthermore, unlike the device driver, a function that operates completely independently of the first operating system can be incorporated, so that a high-reliability function independent of the first operating system can be added.

In a method of constructing a plurality of multi-operating system environments by a microkernel system,
There is a problem that it is difficult to construct an operating system server that provides an interface for each operating system. According to the present invention, a multi-operating system environment can be easily configured simply by adding an interrupt management part without changing the operating system.

[0019]

FIG. 1 is a block diagram showing a configuration of a computer 100 according to an embodiment of the present invention.

The computer 100 includes a processor 101, a main storage device 102, a bus 109, an interrupt signal line 110, a clock interrupt generator 111, and an interrupt control device 11.
2. It has a storage device 118 for storing a boot procedure, and an interrupt bus 119.

The interrupt signal line 110 connects an external input / output device and the interrupt control device 112. When an external device generates an interrupt, the interrupt control device 112 receives a signal via the interrupt signal line 110. The interrupt control device 112 converts this signal into a numerical value and passes it to the processor 101 via the interrupt bus 119.

The clock interrupt generator 111 generates a periodic interrupt.

The interrupt control device 112 receives an interrupt from an external device, generates a numerically-defined interrupt signal according to the request source, and sends it to the processor 101. Further, according to an instruction from the processor 101, an interrupt signal from a specific device may not be notified to the processor 101.

The processor 101 includes an arithmetic unit 103, an interrupt table register 104, a page table register 105, and an address translator 106.

The interrupt table register 104 indicates a virtual address of the interrupt table 107.
Although details of the interrupt table will be described later, the start address of the interrupt handler for each interrupt number is recorded. In FIG. 1, the connection between the interrupt register 104 and the interrupt table 107 is indicated by a broken line because the interrupt table register 104 indicates the interrupt table.

When an interrupt occurs, the processor 101
Receives a digitized interrupt number from the interrupt controller 112. The processor 101 acquires the interrupt handler address from the interrupt table 107 using this number as an index, and passes control to the interrupt handler.

The page table register 105 points to the page table 108. The page table register 105 stores the physical address of the page table 108.

The address translator 106 receives the instruction address requested by the arithmetic unit or the address where the operand is stored, and
The virtual-to-real address conversion is performed based on the contents of the page table 108 pointed to by reference numeral 05.

The computer 100 is connected to a keyboard 113, a display 114, a magnetic disk 115, other external devices 116, and 117 as external input / output devices. Devices other than the display 114 are connected to an interrupt control device 112 by an interrupt signal line 110.

The contents of the main storage device 102 will be briefly described. Here, it is assumed that two operating systems are operating on the computer 101. These will be referred to as a first operating system and a second operating system, respectively. The first operating system is set to start when the computer is started, and the external devices 116 and 117 are devices managed by the second operating system. Hereinafter, the first operating system is referred to as a first OS, and the second operating system is referred to as a second OS.
It is written.

The first OS reserves a physical memory area for other operating systems, in this case, for the second OS in initialization processing at the time of startup. That is, the physical memory area is reserved so that the first OS cannot use the physical memory area reserved for the second OS. FIG. 1 shows a state in which the second OS is loaded in the deprived area.

The main storage device 102 has a common area that can be referred to from all operating systems.
The common area stores an interrupt table 107, an interrupt management program, an interrupt handler, an interface module that can be called from each operating system, and the like.

An outline of the operation of the present embodiment will be described.
In the present embodiment, the second OS operates prior to the first OS. To operate with priority means that the first OS can operate only when the second OS is in the idle state. Unless the processing of the second OS is completed, the first OS cannot operate.

When a device managed by the second OS generates an interrupt, the processing of the first OS is interrupted, and control is transferred to the second OS. While the second OS is running, the first OS
Even if an interrupt occurs, the interrupt processing is postponed until the first OS is executed.

Further, the first OS and the second OS are clearly separated, and are configured so as to be inaccessible to each other except for a common area where an interrupt handler and the like are arranged. This prevents the two operating systems from accidentally accessing each other's area and causing a failure.

FIG. 2 is a schematic diagram conceptually showing the relationship between two operating systems in this embodiment.

Each operating system:
Each has an independent address space. 201 is a virtual space of the first OS, and 202 is a virtual space of the second OS. Here, the real storage corresponding to the space 202 of the second OS is the area of the second OS in the main storage device 102 in FIG.

A common area 203 is mapped to a part of the virtual space. The real storage corresponding to the common area 203 is an area shown as a common area of the main storage 102 in FIG.

FIG. 2 shows hardware managed by each operating system. First OS
Is a keyboard 113, a display 114, and
The magnetic disk 115 is used as the second OS and the input / output device 11
6, and 117 are managed. The clock 111 and the interrupt control device 112 are originally hardware managed by the first OS, but are managed by a program in the common area 203.

FIG. 3 shows the configuration of the page table in this embodiment.

The page table 300 is stored in the processor 10
Each virtual page in one virtual address space has an entry describing each virtual page. Each entry has a valid bit 301 and a physical page number 30
2 is included.

The valid bit 301 indicates whether a physical page corresponding to the virtual page is allocated, that is, whether virtual-real address conversion is possible. For example, the virtual page 3 of the page table 300 has no valid bit set, indicating that there is no physical page corresponding to the virtual page 3. Valid bit 301
When an access to a virtual page for which is not set occurs, the processor generates a page fault.

The physical memory number 302 records a physical page number corresponding to a virtual page.

The address translation unit 106 translates a virtual address generated by the arithmetic unit 103 into a real address with reference to the contents of the page table pointed to by the page table register 105. The processor 101 refers to the main storage device 102 based on the real address obtained by the conversion.

By switching the page tables, an independent space can be constructed, and the space of the first OS and the space of the second OS shown in FIG. 2 can be constructed. The common area 203 can be realized by setting the same physical page to be mapped to a portion corresponding to the common area of the page tables of both operating systems.

FIG. 4 shows the structure of the interrupt table.

The interrupt table 400 indicates that the processor 1
01 records the virtual address 401 of the interrupt handler for each interrupt number received from the interrupt controller 112. When receiving the interrupt request from the interrupt control device 112, the processor 101 stores the address of the interrupt handler corresponding to the interrupt number in the interrupt table 400 indicated by the interrupt table register 104.
And transfers control to that address to start interrupt processing.

FIG. 5 shows the configuration of the interrupt control device 112.

The interrupt control device 112 has an interrupt mask register 501 and a selection device 502.

An input / output device that generates an interrupt is connected to an interrupt control device 112 by an interrupt signal line 110. The priority of the interrupt generated by the input / output device is determined depending on which signal line of the interrupt signal line 110 is connected. Here, it is assumed that the interrupt signal corresponding to the interrupt 0 is the interrupt having the highest priority.

The interrupt signal line 110 is connected to the selection device 502
It is connected to the. Upon receiving the interrupt signal, the selecting device 502 records that there is an unprocessed interrupt until the processor notifies that the interrupt has been received.

The interrupt mask register 501 records whether an interrupt generated by an input / output device may be notified to the processor. The interrupt mask register 501 can be set by an input / output instruction from the processor 101.

The selection device 502 is connected to the interrupt signal line 110
When the interrupt request is received from the CPU and when the contents of the interrupt mask register 501 are rewritten,
2 and the contents of the interrupt mask register 502 are compared to determine whether to notify the processor of the interrupt. Specifically, the selection device 5
02, among the unprocessed interrupts recorded in 02, the interrupt mask register 501 is set to enable interrupts, and
Notify the processor in order from the interrupt with the highest priority. For the selected interrupt, the selecting device 502 sends a numerical signal corresponding to the interrupt signal to be notified to the processor 101 via the interrupt bus 119.

When receiving an interrupt, the processor 101 can eliminate the unprocessed interrupt recorded in the selecting device 502 by the input / output instruction.

Next, a description will be given of a computer boot procedure in this embodiment.

The beginning of the boot procedure is stored in read-only storage device 118. Storage device 118
Are connected to the processor 101 via the bus 109 so as to be mapped to a predetermined address in the physical address space of the processor. In this procedure, a hardware configuration is detected, and a program for loading an operating system is loaded into a main memory.

When the processor 101 is reset, the processor 101 transfers control to a predetermined physical address. The storage device 118 stores a program to be executed at this time, and is mapped to a physical address space so that control can be passed to the program when the processor 101 is reset.

The program stored in the storage device 118 loads the kernel loader of the first OS stored in the magnetic disk device 112 into the main storage device 102 and executes it. The kernel loader is used for the magnetic disk drive 112
The program stored in the storage device 118 at a predetermined position can easily find the program.

FIG. 6 is a flowchart showing the processing procedure of the kernel loader of the operating system in the present embodiment.

The kernel loader is configured to understand the file system structure of the operating system, specify the storage location of the file by the file name, and read the file into the main memory.

First, the kernel loader initializes a main memory list 801, a load module list 804, and a device list 802 to be passed to the kernel as parameters, and allocates a page table area for the kernel (step 601).

The main storage list 801 is stored in the main storage 102
This is a data structure that indicates the usage status of the memory. When the kernel loader allocates a physical memory in the subsequent processing, the kernel loader refers to the main storage list 801 and changes the physical memory.

Next, an inspection of the hardware configuration for the kernel (step 602) and the creation of hardware configuration data (step 603) are performed. Step 60
In 2, the hardware checks which hardware device is connected to the computer 100. In the following step 603, a device list 802, which is a data structure relating to the hardware configuration, is created based on the result of step 602. The kernel of the operating system refers to the device list 802 to execute kernel initialization.

Next, the configuration information 700 of the operating system is read from the magnetic disk device 112, and the address of the configuration information is set in the parameter table 810 (step 604). The kernel of the operating system may be composed of a plurality of files such as a file of the kernel itself and a file of another device driver. The configuration information 700 is stored in the magnetic disk device 112 with a predetermined file name, and the load program can find this.

FIG. 7 shows the data structure of the kernel configuration information in this embodiment.

The kernel configuration information 700 stores data referred to by a kernel loader and an operating system. The stored data is given a name, and the program can obtain the corresponding data from the name. In the example of FIG. 7, there is an entry 701 whose name is memory size, and data indicating the memory size is stored as the contents. Also, the name is se
An entry 705 called condary OS stores data for the second OS.

After reading the kernel configuration information 700,
The kernel loader determines the physical memory size to be allocated to the first OS based on the value of the data stored in the memory size 701 in the kernel configuration information 700 (Step 605). Next, all the kernel configuration files set in the object file 703 are read into the main storage device 102, and an entry is added to the load module list 804 (steps 606 to 608). Here, kernel, driver1, and drive
Load the object file with the file name r2.

Next, a page table for the kernel corresponding to the memory size obtained in step 605 is set (step 609). The address of the page table set in step 609 is set in the page table register 105, the processor is shifted to the virtual address mode (step 610), and the constructed main memory list 801, device list 802, kernel configuration information table 803, and Control is passed to the kernel initialization routine using the parameter table 810, which is a set of the load object list 804, as a parameter (step 611). Kernel entry points are recorded in data in the kernel file.

Next, the hardware configuration data created by the boot procedure starting from step 601 and the configuration of load object data will be described. FIG. 8 is a diagram showing the configuration of hardware configuration data and load object data.

The parameter table 800 is a data structure created by the kernel loader. The three lists starting from the parameter table 800 are arranged in the virtual space of the kernel constructed by the loader and can be referred to from the kernel.

The parameter table 800 holds a pointer to the head of the three lists constructed by the loader and a pointer to one table. The three lists are
A main storage list 801, a device list 802, and
In the load object list 804, one table is a kernel configuration information table 803. Each will be described.

The main storage list 801 is a list of main storage block description data 810. The main storage block description data 810 includes a base address 811, a block size 812, a block use state 813, and a pointer 814 to the next main storage block description data.

The main storage block description data 810 records the usage status of a certain continuous main storage area. The base address 811 indicates the start physical address of the continuous area, the block size 812 stores the size of the continuous area, and the block usage status 813 indicates that the continuous area is unused or has been assigned by the loader. Is stored. Then, a list is constituted by the pointer 814 to the next entry. FIG.
Then, the next entry after 810 is 820. By referring to the main storage list 801, the use state of the physical memory can be known.

The device list 802 stores data on hardware devices detected by the kernel loader, and is created in step 603. The device list 802 is a list including device data 850. The device data 850 includes a device type 851,
It comprises device information 852 and a pointer 853 to the next device data.

In the device type 851, a value indicating the type of the device described by the device data entry 850 is stored. The device information 852 stores data unique to the type of device. For example,
An interrupt number, an I / O address, and the like correspond thereto.
The list is constituted by the pointer 853 to the next entry.

Pointer 8 to kernel configuration information table
03 indicates the contents of the kernel configuration information file 700 read by the kernel loader into the main storage device 102.

The load object list 804 holds data relating to the object file loaded into the main memory by the kernel loader. The load object list is a list of the load object data 830. The load object data 830 includes an object file name 831, an object address 832, and a pointer 833 to the next load object data.
Consists of

The object file name 831 is the file name of the object file described by the load object 830. Object address 8
Reference numeral 32 stores the address of the kernel space where the header area of the object file is loaded.
Then, a list is constituted by the pointer 833 to the next entry.

The load object list 804 is created at the same time that the kernel loader reads the object file constituting the kernel (step 60).
8).

Next, a procedure for loading a device driver in this embodiment will be described. The device driver is software for controlling a hardware device connected to the computer 100, and can be loaded during the initialization of the kernel of the operating system described with reference to FIG. 6 or after the operating system is started. .

First, the device management table will be described. FIG. 9 is a diagram showing the structure of the device management table of the first OS. The device management table includes an interrupt management table 900 and an I / O address management list 9
It consists of ten data structures.

The interrupt management table 900 stores, for each interrupt number accepted by the processor 101, a value indicating whether the first OS uses the interrupt number. When the device driver requests an interrupt number at the time of loading, the kernel
Check 00 and give the device driver the right to use the requested interrupt number only if it is not being used. If it is described that the hardware device has already been used, the hardware device cannot be used from the first OS. For example, in the case of the interrupt number 3, a value indicating whether the data 902 corresponding to the number 3 has been allocated or not used is held.

The same applies to the I / O address management list 910. The I / O address management list 910 is
This is a list including entries 920 representing / O addresses. The entry 920 is an I / O used by the first OS.
It comprises an O address 921 and a pointer 922 to the next entry for composing the list. As in the case of the interrupt vector management table 900, when the device driver requests an I / O address range, the kernel checks whether the address range is already used or not.
10 and if not used, this list 91
An entry is added to 0 to give use permission.

FIG. 10 is a flowchart showing a procedure for loading a device driver.

In the device driver loading process, first, device driver information is obtained (step 1).
001). The device driver information is the object file name of the device driver. If the device driver is loaded at the time of kernel initialization of the operating system, the device driver information is obtained from the entry name object file 703 of the kernel configuration information file 700. When the device driver is loaded after startup, the object file name that the operator instructed to load is used.

Next, the designated object file is checked, and the memory size required for loading the object is checked (step 1002). A request is made to the operating system for a memory on the main storage device 102 necessary for the checked memory size (step 100).
3) The device driver is read into the memory (step 1004).

Next, an entry point for the device driver initialization process is obtained from the object file of the device driver, and the device driver initialization process is executed (step 1005). In the initialization processing of step 1005, it is checked whether the hardware device targeted by the device driver is connected to the computer 100 by referring to the device list 802 (step 1006).

If the hardware device is connected, initialization of the hardware device and initialization of a table necessary for device driver processing are executed (step 1007). If the hardware device requires an interrupt number or an I / O address, the device driver sends an interrupt number or an I / O address to the operating system.
Signals the use of the O address range. The operating system that has received the notification checks the interrupt management table 900 and the I / O address management list 910 in FIG. 9 and, if the requested resource is available, gives permission to use the device driver, and manages the device driver. By updating the table, other device drivers are set not to use this resource (step 10).
08). If permission to use the interrupt number is obtained, the address of the interrupt handler process for processing the interrupt is registered in the operating system (step 1009). Further, if necessary, a process specific to the device driver is executed (step 1010).

In the device driver loading process, when all of the processes in steps 1001 to 1009 are correctly performed, the object file information of the device driver is added to the load object list 804 (step 1011), and the device driver operates the operating system. It operates as a part of and controls hardware devices.

FIG. 11 is a flowchart of a device driver unloading process.

The unloading of the device driver is performed to stop the use of the hardware device. When the operating system is started, the loaded device driver is unloaded according to an instruction, or the hardware device is unloaded from the computer. Executed when removed.

In the unload processing of the device driver,
First, termination processing of the device driver is called by the operating system (step 110).
1).

In the termination processing of the device driver, the registration of the interrupt handler and the use of the used interrupt number or I / O address range are released (steps 1102 and 1103). As a result, the released interrupt number or I / O address range becomes unused and can be used by another device driver. Next, the memory used by the device driver is released (step 1104), and the termination processing of the device driver is completed.

After the end processing of the device driver, the operating system releases the memory on the main storage device 102 into which the object file of the device driver has been loaded (step 1105), and reads the object file of the device driver from the load object list 804. Is deleted (step 1106).

Next, a processing procedure for executing a plurality of operating systems on one PC will be described. In the present embodiment, control for executing the multi-OS is performed by a device driver of the first OS (hereinafter referred to as a multi-OS).
Driver)).

FIG. 12 shows the processing structure of the multi-OS driver.

The structure of the multi-OS driver is roughly divided into two parts, and includes an entry function part 1201 executed by a call from the operating system and an execution function part 1202 executed by a call from the entry function part 1201.

All entry functions of the multi-OS driver hold the addresses of the corresponding execution functions, and when the entry function is called from the operating system,
Call the corresponding execution unit function (step 1203),
The called execution function executes the actual processing of the function (step 1204). The reason that the multi-OS driver has such a two-part structure is that the operating system can change the address of the execution function part 1202 after loading the device driver.

FIG. 13 shows a flowchart of the procedure for loading the multi-OS driver. The multi-OS driver is also a kind of device driver, and the operating system operates in a multi-O
Load the S driver object file. Therefore, only the details of the device driver-specific processing (step 1010) of the multi-OS driver are shown here.

In FIG. 13, first, a physical memory for a common area that can be referred to from all operating systems is secured (step 1301). The common area stores an interrupt table 107, an interrupt management program, an interrupt handler, an interface module that can be called from each operating system, and the like as a part of the multi-OS driver. To secure the physical memory for the common area, refer to the main storage list 801 and
Secure free space. In the present embodiment, only the first OS is loaded in the physical memory, and a memory having a larger address among the free physical memories is secured in a necessary capacity.

Next, a virtual address space of the first OS for the common area is secured (step 1302). Since this virtual address space needs to be the same in all operating systems, it is assumed that addresses determined in advance in all operating systems are assigned. In the present embodiment, a necessary capacity is secured from a space having the largest address in the virtual address space of the first OS.

If the area of the physical memory and the virtual address space can be secured, the page table of the first OS is set so that the virtual address secured in step 1302 can access the physical memory secured in step 1301. (Step 1303).

Next, the multi-OS driver copies the object and data in the area where the first OS is loaded to the common area (step 1304), and the multi-OS driver transmits the object and data from the multi-OS driver function described in FIG. The address of the execution function held by the called entry function is updated to the address of the execution function copied to the common area (step 1305). When the function of the multi-OS driver is called from the first OS by changing the address of the execution function, the object of the execution function in the common area is executed.

FIG. 14 shows the correspondence between the virtual address space and the physical memory of the main storage device 102.

Reference numeral 1401 denotes a physical memory, and 1402 denotes a virtual address space of the first OS. It is assumed that the address increases from the bottom to the top in the figure. The virtual address space 1402 of the first OS is divided into a kernel space 1404 accessible only by the operating system and a user space accessible by the operating system and user programs. The lower address side 1408 of the kernel space 1404 is the memory 140 allocated to the first OS in the physical memory 1401.
9 indicates that the page map table has been set so as to be accessible.

The multi-OS driver is loaded by the first OS into a partial area 1413 of the physical memory 1409 and mapped to the multi-OS driver A area 1412 in the virtual address space 1404. Multi OS driver A
The area 1412 cannot be predicted in advance because it changes depending on the usage status of the virtual address space of the operating system.

Since the multi-OS driver includes objects and data used in all operating systems, it can be secured in all operating systems, and the area of the matched virtual address space (multi-OS driver)
The object and the data are moved to the S driver B area 1415). As a result, the multi-OS driver can be accessed at a common address in all operating systems. Also, by moving the physical memory of the multi-OS driver B area 1415 from the area 1413 in the physical memory allocated to the first OS to the common area 203, erroneous memory access due to a malfunction of the operating system can be prevented. .

FIG. 15 is a flowchart showing a procedure for loading the second OS.

In this processing, first, it is necessary to read the object file of the second OS into the physical memory area allocated for the second OS. However, since the physical memory area of the second OS cannot be written from the first OS as it is, the allocated physical memory area is temporarily mapped in the virtual space of the first OS (step 1501).

In step 1502, the file is read into the mapped area by using the file read procedure of the first OS.
The object file of the second OS is read.

Next, a page table for the second OS is created (step 1503). This page table is also created in the area for the second OS. At this time, a page table is constructed so that the area of the common area 203 can be referred to from the space of the second OS.

Multi-O mapping common area 203
The S driver C area 1416 is a multi-OS of the first OS.
The value is set to be the same value as the virtual address of the driver B area 1415.

Next, the address of the interface module is written in the second OS area so that the second OS can call the interface module of the multi-OS driver arranged in the multi-OS driver C area 1416. It is passed to the second OS as an argument (step 1504). Similarly, the address of a function necessary for calling the second OS from the multi-OS driver is acquired from the object file and stored in the common area 203 (step 1505).

Thus, the setting of the second OS area is completed.
The mapping of the physical memory area for the second OS, which has been mapped to the first OS, is released (step 1506).

Next, the OS context table 1610
And the OS identification variable 1630
Is set (step 1507). OS context is
A data structure that is referred to when switching the execution operating system, and includes a page table address value and an initial value of a stack pointer. Here, the address of the page table that maps the second OS is set as the page table register value, and the initial address of the kernel stack of the second OS is set as the stack pointer value. The OS identification variable 1630 stores a value indicating that the first OS is running. The OS context table 1610 and the OS identification variable 1630 will be described later.

Next, the initialization module of the second OS is executed (Step 1508). This involves switching the operating system space. The switching of the operating system will be described with reference to another flowchart.

Finally, in step 1509, the address of the first OS interrupt handler registered in the current interrupt table register 104 is copied to the handler column 1622 of the interrupt identification table 1620, and the interrupt table register value is set. Is changed to the address of the interrupt table assigned to the multi-OS driver. This is performed by changing the interrupt table register 104 of the processor 101.

The reason why the interrupt table is changed to the table in the multi-OS driver is that the interrupt table must always exist in the virtual address space of the processor 101 regardless of which operating system is executing when the interrupt occurs. It is. The interrupt handler registered in the interrupt table is also arranged in the multi-OS driver. Step 1
At 503, the virtual area of the second OS is also mapped to the common area 203, so that it can be referred to at any time. The interrupt processing of the multi-OS driver will be described later.

FIG. 16 is a diagram showing a data structure of data stored in the data area 1600 of the common area 203.

Reference numeral 1610 denotes an OS context table. The OS context table 1610 stores the first O
Data necessary for switching between S and the second OS is held. In the present embodiment, it is assumed that the first OS can run only when the second OS is in the idle state. In this case, the switching to the second OS occurs at a certain time during the execution of the first OS, and the control may be returned to the first OS when the execution of the second OS ends.

Therefore, the context may be one set unless it is stored individually. For the context of the first OS, if the page table register value 1611 and the stack pointer value 1612 at the time when the OS switching is requested are stored, the first OS is controlled by the first OS after the execution of the second OS is completed. Can be restored.

When the control is switched from the first OS to the second OS, the second OS is not operating. Therefore, the context of the second OS may be a fixed address for both the page table address and the stack pointer. The page table register 1613 and the stack pointer value 1614 of the second OS are set when loading the second OS (Step 1507).

Reference numeral 1620 denotes an interrupt identification table. In the interrupt identification table 1620, a value 1621 indicating which operating system processes the interrupt process and an address 1622 of the interrupt handler are recorded for each interrupt number of the external interrupt. When an external interrupt occurs, the interrupt handler in the common area 203 captures the interrupt and refers to the processing OS 1621 in the interrupt identification table 1620 to determine which operating system is to be processed, and the handler 1
Control is passed to the address 622. Details of the interrupt processing will be described later.

An OS identification variable 1630 stores a value indicating the operating system being executed. O
The S identification variable 1630 is obtained by
It is set every time the OS is switched in the S switching procedure. In the interrupt processing, an interrupt processing procedure is determined with reference to the OS identification variable 1630.

Reference numeral 1640 denotes a delayed interrupt status variable indicating whether an interrupt of a device managed by the first OS has occurred during execution of the second OS. The delay interrupt status variable 1640 records which interrupt number has occurred. The OS switching procedure is the second OS
Interrupt status variable 1640 when execution of
Is checked to determine whether to start interrupt processing (step 1708).

Reference numeral 1660 denotes a variable indicating that the device driver operating on the second OS has requested the use or release of the resources in the interrupt number or the I / O address range. When a resource is requested during execution of the second OS, it is necessary to notify the first OS not to use this resource, but the second OS directly calls the processing of the first OS. Can not. Therefore, the multi-OS driver receives a request for resources from the second OS, creates a provisional reservation state, and checks the variable 1660 when the execution of the second OS is completed. Again, a request for resources is made to the first OS. While the second OS is running, the first OS is always in a stopped state, so even if the resources are temporarily reserved by the multi-OS driver, the first OS does not use the resources.

FIG. 17 shows an embodiment of the present invention.
6 is a flowchart illustrating a procedure for switching an operating system. This switching procedure is called during the execution of the first OS, and switches to the second OS.

In the procedure shown in FIG. 17, the second OS executed after switching to the second OS also receives the address of the module and the arguments to be passed to the module as arguments.
The address of the module of the second OS is stored in step 150
Assume that it has been acquired in 5.

First, in step 1701, the current stack pointer value and page table register value are stored as the first OS context in the OS context table 1610. In step 1701, the current stack pointer value is stored in 1612, and the current page table register value is stored in 1611. Other register contexts do not need to be stored in the OS context table 1610. If necessary, it may be stored in the stack of the first OS.

After storing the stack pointer value and the page table register value, in step 1702, the page table register 105 is set with the address of the page table that maps the second OS to the virtual space. This is O
It is recorded in 1613 of the S context table 1610. Further, a stack pointer is set for the second OS. This is also stored in the stack pointer 1614 of the second OS in the table 1610.

In the next step 1703, the delay interrupt status variable 1640 indicating the interrupt status of the first OS and the request variable 1660 of the interrupt resource are cleared, and the contents of the interrupt management table 900 and the I / O address management list 910 are shared. It is copied in the area 203. Then, the OS identification variable 1630 indicating the currently executing OS is rewritten to a value indicating the second OS (step 1704). Stack pointer, page table register 105, and
Since the OS identification variable 1630 must always have a consistent value, all of the steps 1701 to 1704 up to this point must be executed with external interrupts disabled.

In the following step 1705, control is transferred to the address of the module passed as an argument, and control is passed to the second OS. In the present embodiment, the first OS is the second OS
When the OS of the second OS is not operating, that is, when the processing of the second OS is completed, the control returns to step 1706.

In step 1706, step 1701
The page table register value 1611 stored in the OS context table 1610 and the stack pointer value 1
Recover each of 612. Following step 1707
Then, the OS identification variable 1630 is changed to a value indicating that the first OS is running. These two steps must also be executed with interrupts disabled.

Next, an external interrupt of a device managed by the first OS, which occurs during execution of the second OS, is processed. First, in step 1708, the delay interrupt status variable 1640 is checked to determine whether an interrupt has occurred. If not, step 1711 is executed. If an interrupt has occurred, step 1709
Execute In this step, the fact that there is an unprocessed interrupt is recorded in the delayed interrupt state variable managed by the first OS for the interrupt that occurred while the second OS was executing. Subsequently, the interrupt processing of the first OS is started (step 1710). When all the interrupt processes have been completed, step 1711 is executed.

In step 1711, it is checked whether the use state of the resource of the interrupt number or the I / O address range required by the hardware device has changed due to the loading or unloading of the device driver during the execution of the second OS. That is, while the second OS is being executed, FIG.
When the corresponding device driver is loaded in order to control the hardware device used by the second OS according to the processing procedure described in and the resource use request is notified from the device driver to the second OS, The second OS notifies the multi-OS driver that the use of the resource has been requested. The multi-OS driver that has received the notification checks the interrupt management table 900 and the I / O address management list 910 copied to the common area 203 in step 1703, and if resources can be used, the table (900, 900) in the common area 203 910), the second OS is given permission to use the resources. At the same time, the fact that the usage status of the resource has changed is recorded in a variable 1660. This is the same as the case where the device driver is unloaded during execution of the second OS. A request is transmitted from the device driver to the second OS, and further, the request is transmitted from the second OS to the multi-OS driver. The change is recorded at 1660.

In step 1711, by examining the variable 1660, it is detected that a change has occurred in the use state of the resource in the interrupt number or the I / O address range. Interrupt management table 900 and I / O address management list 91
0 is written back to the interrupt management table 900 and the I / O address management list 910 managed by the first OS (step 1712).

As a result, the resources of the hardware device used by the second OS are also set in the first OS, so that the resources can be prevented from being allocated to the device driver of the first OS. From the perspective of the first OS, the second O
The resource of the hardware device used by S is the first O
By showing it as a resource used by the multi-OS driver loaded in S, the consistency of management in the operating system is maintained.

FIG. 18 is a flowchart showing an interrupt processing procedure according to this embodiment. The module that executes this procedure is registered in the interrupt table 107 of the processor 101 as an interrupt handler. Further, this interrupt handler is arranged in the common area 203 which can be referred to from any operating system.

When an external interrupt occurs, the processor 10
When the interrupt handler is activated by step 1, the interrupt handler checks the cause of the interrupt and determines whether the hardware device that generated the interrupt is a hardware device associated with the first OS or a hardware device managed by the second OS. A determination is made (step 1801). This determination is made by referring to the OS column 1621 in the interrupt identification table 1620 using the interrupt number as an index. If it is the hardware device of the first OS, the process proceeds to step 1802; if it is the hardware device of the second OS, the process proceeds to step 1805. For example, FIG.
In other words, if the interrupt number is 1, it is an interrupt of the first OS, and if the interrupt number is 4, it is an interrupt of the second OS.

If the interrupt is a hardware device interrupt of the first OS, step 1802 is executed. In step 1802, the operating system that was being executed when the interrupt occurred is determined. This determination is made with reference to the OS identification variable 1630. If the OS being executed is the first OS, the process proceeds to step 1803, and if it is the second OS, the process proceeds to step 1804.

The process starting from step 1803 is a process performed when a hardware device managed by the first OS generates an interrupt while the first OS is being executed.

At step 1803, it is as if 1801
, And the context is set such that the interrupt handler of the first OS appears to be directly controlled by the processor 101. Here, the context indicates the contents of the stack and the contents of the register. The address of the interrupt handler of the first OS is stored in the handler column 1622 of the interrupt identification table 1620. For example, if the interrupt is interrupt number 1, the address of the handler is obtained by referring to the interrupt identification table using 1 as an index. In this case, the control does not return to the procedure starting from step 1801, and the first OS continues the processing.

If the hardware device managed by the first OS generates an interrupt while the second OS is running, step 1804 is executed. In step 1804, the interrupt number of the hardware device that generated the interrupt is recorded in the delay interrupt status variable 1640. This completes the processing of the interrupt handler. The interruption process in this case is executed when the execution OS is switched to the first OS (step 1708).

If the generated external interrupt is an interrupt of a hardware device managed by the second OS, the flow advances to step 1805 to check which OS is being executed. Here, the OS under execution is determined by the OS identification variable 1630. If the first OS is running, the process proceeds to step 1806; if the second OS is running, the process proceeds to step 1811.

When an interrupt of a hardware device managed by the second OS occurs during execution of the second OS,
Step 1811 is executed. Step 1811 activates the interrupt handler of the second OS. The address of the interrupt handler of the second OS is recorded in the handler column 1622 of the interrupt identification table 1620. When the second OS interrupt handler process ends and returns, this interrupt handler also ends, recovers the context at the time of the interrupt, and returns control.

If an external interrupt of a hardware device managed by the second OS occurs during the execution of the first OS, step 1806 is executed. In this case, the process of the second OS is executed with priority over the execution of the first OS.

First, in step 1806, the context is saved. Here, the context indicates the contents of the stack and the contents of the registers necessary for restoring the interrupted state when returning control to the first OS after the end of the interrupt processing. This context is stored in the stack of the kernel of the first OS.

Subsequently, the switching of the execution OS and the second OS
Of the interrupt processing is executed (step 1807,
1808). This is performed by a procedure starting from step 1701.

When the processing of the second OS is completed, switching to the first OS is executed (step 1809), the context at the time of interruption is restored (step 1810), and the processing of the first OS is restarted. I do. The processing in step 1809 does not necessarily have to be executed by the same module as the processing starting from step 1801. The process returns to this module by switching to the first OS.

The processing of a clock interrupt shared by two operating systems will now be described.

The clock interrupt is captured by an interrupt handler in the common area 203. In this interrupt handler, first, an interrupt handler for a clock interrupt of the second OS is executed. The interrupt handler of the second OS is stored in the handler column 1623. Second O
When the S interrupt handler ends, the first OS interrupt process is executed by the process starting from step 1802 in FIG. The address of the interrupt handler of the first OS is stored in the handler column 1622.

As described above, two operating systems can be operated simultaneously by one computer.

Further, in the above-described embodiment, in FIG.
By adding step 1510 as shown in the flowchart of FIG. 19 to the loading procedure of the second OS shown in 5, it becomes possible to cause the second OS to monitor the operating state of the first OS. The processing procedure of FIG. 19 will be described below.

In the processing procedure of FIG.
Steps 1 to 1509 are the same as the processing in the flowchart of FIG. 15, and additionally include a step 1510 for performing a new monitoring process.

When a failure occurs during execution and it is determined that the processing cannot be continued, the operating system executes an error handling function of the operating system to execute all the hardware devices connected to the computer. Stop, and finally the processor of the computer. In this embodiment, since a plurality of operating systems are operated on one computer, it is not always necessary to stop the entire computer due to a failure of one operating system. Can continue the operation of the computer.

In this embodiment, it is assumed that a failure has occurred in the first OS and the second OS has detected the failure. In step 1510, at the end of the loading processing of the second OS, the first instruction of the error processing function called by the first OS is rewritten to an instruction that generates an interrupt. For example, in the state of the interrupt identification table 1620 shown in FIG.
When an instruction for generating the interrupt number 5 is written, if a failure that cannot be continued occurs in the first OS, the interrupt number 5 is generated in the processor 101 before the error processing function of the first OS is executed. Interrupt number 5 is the second OS
, And the handler of the second OS is called in accordance with the contents of the handler column 1623 of the interrupt number 5. That is, before the error processing function of the first OS is executed, the second OS can detect that a failure has occurred in the first OS. In the interrupt handler process of interrupt number 5, the first O
By notifying that S has gone down and operating only the second OS thereafter, the processing of the second OS can be continued. The second OS that continues the process can diagnose and recover from the failure of the first OS and notify the operator. Accordingly, in an environment where a plurality of operating systems are simultaneously operated by one computer, a system in which one operating system monitors a failure that has occurred in another operating system can be realized.

In the above-described embodiment, the function of operating a plurality of operating systems on one computer is implemented by a device driver called a multi-OS driver. However, the function is loaded into the operating system loaded by the boot process of the computer. It is also possible to incorporate a function for implementing a multi-OS. In this embodiment, FIG.
By executing the process (steps 1301 to 1306) for executing the multi-OS shown in FIG. 13 in the process of step 611 of the boot process of the second OS, when the first OS starts up, the second OS Loading is enabled. Also in this embodiment, FIGS.
6, the processing procedures shown in FIGS. 17, 18 and 19 are not changed. As a result, an operating system capable of operating an operating system other than the own operating system simultaneously on one computer is realized, and a plurality of operating systems can be operated simultaneously.

[0158]

According to the embodiment described above, a plurality of operating systems can be operated simultaneously by one computer without special hardware support. First OS
Can be easily introduced, and the function can be operated completely independently of the first OS.

Further, by realizing the function of executing the multi-OS as a device driver, the processing of the first OS is not changed, so that the function can be easily added to the existing operating system. In addition, 1
In an environment in which a plurality of operating systems are simultaneously operated on one computer, one operating system can monitor the failure of another operating system, and the monitoring operating system diagnoses and recovers from the failure of the monitored operating system. Thereby, the reliability and maintainability of the entire computer can be improved.

Furthermore, by dynamically allocating an interrupt resource used by a hardware device among a plurality of operating systems, the hardware device allocated to one operating system can be
After the use of this operating system is completed, another operating system can use it.

[0161]

According to the present invention, a plurality of operating systems can be run simultaneously and in parallel on a single computer without using special hardware and without emulating privileged instructions such as input / output processing. Can be operated.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a computer configuration according to an embodiment of the present invention.

FIG. 2 is a schematic diagram showing a computer configuration.

FIG. 3 is a diagram showing a configuration of a page table.

FIG. 4 is a diagram showing a configuration of an interrupt table.

FIG. 5 is a diagram illustrating a configuration of an interrupt control device.

FIG. 6 is a flowchart illustrating a boot processing procedure of the computer.

FIG. 7 is a diagram illustrating a configuration of a kernel configuration information file of a first OS.

FIG. 8 is a diagram showing a data structure of a kernel startup parameter.

FIG. 9 is a diagram illustrating a data structure of a device management table of the first OS.

FIG. 10 is a flowchart illustrating a procedure for loading a device driver of the operating system.

FIG. 11 is a flowchart illustrating a procedure for unloading a device driver of the operating system.

FIG. 12 is a diagram illustrating a processing structure of a multi-OS driver.

FIG. 13 is a flowchart of a multi-OS driver load processing procedure.

FIG. 14 is a diagram showing the correspondence between the virtual address space and the physical memory of the main storage device 102;

FIG. 15 is a flowchart illustrating a load processing procedure of a second OS.

FIG. 16 is a diagram illustrating a data structure shared by a first OS and a second OS.

FIG. 17 is a flowchart illustrating a procedure for switching an execution OS.

FIG. 18 is a flowchart illustrating an interrupt processing procedure.

FIG. 19 is a flowchart illustrating a load processing procedure of a second OS for adding a monitoring function to the second OS.

[Explanation of symbols]

 100: Computer 101: Processor 102: Main storage device 103: Arithmetic device 104: Interrupt table register 105: Page table register 106: Address conversion device 107: Interrupt table 108: page table 109: bus 110: signal line 111: clock interrupt generator 112: interrupt controller 113: keyboard 114: display 115: magnetic disk 116, 117 ... External equipment 118 ... Storage device 119 ... Interrupt bus

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Masahide Sato 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Inside System Development Laboratory, Hitachi, Ltd. F-term in the Information Technology Division of Hitachi, Ltd. (reference) 5B042 GA22 GA23 GA25 GC07 GC12 JJ01 JJ05 5B076 AA13 AA14 AB14 CA08 5B098 BA06 BB11 EE02 EE06 GA02 GC01 GD02 GD20 GD22 HH04 HH07 JJ08

Claims (5)

[Claims] 1. A method for controlling an operating system in a computer system, wherein a procedure for excluding hardware resources of the computer from a management target of the first operating system to another operating system and an area shared by a plurality of operating systems are provided. With the common processing procedure and data arranged, the interrupt processing unit of the common processing procedure schedules execution of each operating system, so that a plurality of operating systems can be executed without emulating privileged instructions executed by each operating system. In a multi-OS configuration method in which a system is operated by one computer, a common processing procedure arranged in an area shared by a plurality of operating systems is used as a device driver of a first operating system. An incorporation procedure, a procedure in which the device driver switches control from an interrupt processing unit of the first operating system to an interrupt processing unit in the common processing procedure, and a step in which the device driver loads the second operating system and executes the first operating system. Starting the second operating system in a virtual address space different from the system, and the interrupt processing unit of the common processing procedure schedules the execution of each operating system, thereby executing the processing of the first operating system. A multi-OS configuration method characterized by operating a plurality of operating systems on one computer without changing the procedure. 2. The multi-OS configuration method according to claim 1, wherein one operating system requires an interrupt resource to prevent another operating system from accessing an interrupt resource used by one operating system. And making a reservation so that other operating systems cannot be accessed. 3. The multi-OS configuration method according to claim 1, wherein after assigning an interrupt resource to one operating system, another operating system assigns the interrupt resource when the operating system no longer needs the interrupt resource. A multi-OS configuration method, which releases reservation of an interrupt resource of another operating system so that it can be used. 4. A multi-OS configuration method according to claim 1, wherein a common processing procedure and a common data address arranged in an area shared by a plurality of operating systems are matched in a virtual address space of all operating systems. Multi-OS characterized by having
Configuration method. 5. The multi-OS configuration method according to claim 1, further comprising: a step of acquiring address information of a function group of the monitored operating system; A procedure for extracting, a procedure for writing an interrupt generation instruction at an address of the extracted error function, and, when the interrupt occurs, an interrupt processing unit of a common processing procedure arranged in an area shared by a plurality of operating systems, Steps to notify
A method for configuring a multi-OS, comprising a procedure for performing a fault diagnosis or a fault recovery process of a monitored operating system by the monitored operating system by notification.