CN101359312B - Input and output control system - Google Patents

Abstract

The present invention provides an input/output control system that takes into account efficiency, does not depend on the upper platform, and is usable. An input/output control device (100) for controlling input and output of input devices and output devices disposed on a computer in which at least two or more OSs are simultaneously running on a main system having a function of simultaneously executing a plurality of OSs includes: The request accepting part (110) accepts the switching request requesting to switch the OS of the input device or the output device; the control information generating part (120) generates input destination information (230) or output availability information ( 240) of control information (121); and a control information output unit (130) that outputs input destination information (230) or output permission information (240).

Description

Input and output control system

This application is a divisional application of an invention application filed on January 17, 2007, with application number 200710001947.4, and titled "Input-Output Control Device, Input-Output Control System, and Input-Output Control Method".

technical field

The present invention relates to an input/output control device, an input/output control system, and an input/output control method for controlling shared use of input/output devices based on a plurality of operating systems (hereinafter referred to as OS).

Background technique

In a computer running a single OS, the OS and the programs running on the OS can access the input and output devices of the computer through the control software (hereinafter referred to as device driver) of the input and output devices loaded in the OS at a proper time. output device.

Here, the computer has at least: an input device (keyboard, etc.) used to input information to the OS from outside the computer; and an output device (display, etc.) used to output information from the OS to the outside of the computer.

When the device driver is loaded into the OS, it registers the information of the device it controls to the OS. Such equipment information includes, for example, an insertion number for the equipment.

When information is input from outside the computer via the input device, first, the insertion controller notifies the CPU of an insertion signal and an insertion number.

Second, the CPU receives the interrupt signal, interrupts the current process, and calls the device driver corresponding to the interrupt number.

Third, the device driver accesses the corresponding device and transfers the input information to the OS.

In addition, when the OS outputs specific information, it specifies an appropriate output device according to the content of the specific information. After that, the OS calls a pre-registered device driver corresponding to the output device to output the specific information.

As described above, when a separate OS is running on a computer, the OS manages the use of the input/output device, as long as there is no conflict in which programs running on the OS simultaneously access the input/output device.

On the other hand, in recent years, environments in which a plurality of OSs can be simultaneously executed on computers are expanding. In such an environment, as shown in FIG. 12, a host system called a "virtual machine monitor (hereinafter referred to as VMM)" constitutes a guest system called a "virtual machine (hereinafter referred to as VM)". , implemented by running each OS on the VM (for example, refer to Patent Document 1, Non-Patent Document 1, and Non-Patent Document 2).

For example, as an example of utilization of this environment, a "real-time OS (hereinafter, referred to as RTOS)" specialized for real-time processing and a general-purpose "general-purpose OS (hereinafter, referred to as GPOS)" are installed on a single computer. An example of simultaneous operation on the server; an example of running multiple OSs on one server, and providing a service specialized for the OS in each OS to the client.

In such an environment, it is necessary to share limited hardware resources including input and output devices among a plurality of OSs.

One of the functions of the VMM is to statically or dynamically allocate hardware resources to each OS. For example, the VMM dynamically transfers the control right of the CPU to each OS, statically and logically divides the main memory and distributes it to each OS, thereby realizing simultaneous execution of a plurality of OSs.

In addition, among the VMMs, there is also a VMM that realizes data communication among a plurality of OSs that are executed simultaneously. A typical implementation method is a method of providing a shared memory that a plurality of OSs can refer to.

The VMM manages the shared memory and notifies the OS of writing or reading into the shared memory.

Such an inter-OS communication function is utilized not only for single data communication, but also for sharing hardware resources among a plurality of OSs.

For example, consider a case where a plurality of OSs communicate with the outside in a computer having only one network interface.

In this case, it is difficult to consider a structure in which each OS independently has a device driver for a network interface. The reason is that it is impossible to judge in advance which OS's driver should be called for hardware insertion that occurs at the time of data reception.

Therefore, it is necessary for a certain OS to be the sole holder of the device driver, and to perform data transmission and reception and distribution of data to each OS.

When sharing such hardware resources, it is necessary to have the above-mentioned inter-OS communication function.

[Patent Document 1]: US2004/0205755

[Non-Patent Document 1]: "Xen and the Art of virtulization" In Proc.of Symposium on operating systems Principles (SOSP) 2003 (http:/www.cl.cam.ac.uk/ReSearch/SRG/netos/papers/2003 -xensosp.pdf)

[Non-Patent Document 2]: "A 600MIPS 120mW 70μA Lcakage Triple-CPU MobileApplication Processor Chip" In Proc.of IEEE International Solid-State Circuits Conference (IS SCC) 2005

Contents of the invention

Consider a device exclusively occupied by a specific OS at any time in a plurality of OS environments implemented on the VMM.

An example of such a device is a human interface device (hereinafter referred to as HID). For example, a keyboard as an input device, a display as an output device, and the like can be mentioned as HID.

These devices need to be exclusively occupied by the OS that the user is utilizing.

For example, when the user is using a specific program, it is basically necessary to input the result of the user's keyboard input to the program and display the output result of the program on the display, so the input result from the keyboard must be transferred to the OS running the program. On, likewise, the output from the OS must be displayed on the monitor.

The fact that the CPU is controlled by the OS does not necessarily mean that the user is using a certain OS.

Even while the VMM is being used by the user, it is possible to perform context switching between OSes, allocate CPUs to other OSs, or perform processing of the VMM itself.

Since the VMM manages CPU allocation, it can grasp which OS is controlling the CPU at any time, but cannot grasp which OS the user is using at any time.

Therefore, for example, when the VMM is inserted after data is input from the keyboard, it cannot recognize which OS the insertion is for.

For example, when sharing a network interface, data for identifying a destination OS, such as an IP address or a port number, is assigned to received data, so that the data may be distributed once a certain OS receives the data.

However, it is difficult to perform the same processing on the data input by the keyboard.

Likewise, problems arise when outputting to a display.

All OSes individually store display driver programs, and if they are exported arbitrarily, a conflict with the display will inevitably occur.

Even when the data to be output for a certain OS is collected, if it is not possible to identify which OS should output the data at this point in time, the correct output result cannot be displayed to the user.

The plurality of OS environments described in Patent Document 1 do not provide special functions for the above-mentioned problems.

This is because Patent Document 1 assumes an environment where the RTOS and GPOS are executed simultaneously, and the GPOS always occupies the HID.

On the other hand, in the multiple OS environments described in Non-Patent Document 1 or Non-Patent Document 2, as shown in FIG. 13 , one main OS is prepared, and the GUI (Graphical User Interface) server of the main OS handles the The input and output of the HID of the OS, thereby realizing the sharing of the HID.

Specifically, only the main OS has a device driver for HID (HIDDD), and the device driver can only handle input and output from the GUI server of the main OS.

The GUI server of the host OS generates a window (Window) for each guest OS other than the host OS, and outputs an output result received from the GUI server of the corresponding guest OS through inter-OS communication of the VMM.

Also, when the window is activated, the input result from the input device is transferred to the GUI server of the corresponding client OS through the inter-OS communication.

However, there is a problem in such a solution through a GUI server.

The first problem is that since all GUI client applications of all OSes perform input and output processing separately, context switching across OSes often occurs.

Context switching between OSes in a plurality of OS environments takes time for context saving processing and restoring processing, and becomes a large bottleneck especially in output processing to a display where speed is important.

In addition, in an environment where power-saving processing is required, such as a portable terminal, it is also a factor that consumes a large amount of power.

The second problem greatly depends on the platform and application program of each OS.

In order to realize such input/output between GUI servers, both the GUI server of the host OS and the GUI server of the guest OS must support this function.

In addition, especially when the environments in which the GUI servers operate are significantly different, data conversion at the application level (1evel) is required for communication between the GUI servers.

The third problem is that there is a risk of secrecy because all input and output processing is entrusted to the GUI server.

Since the GUI server is a "non-privileged process (user authority)", it has weak tamper resistance (Tamper) compared with an OS which is a "privileged process (kernel authority)".

When the GUI server is tampered with, the input and output of the OS cannot be properly processed, and the input result may be transferred to a wrong input destination, or the output result of the OS that should not be displayed may be displayed.

In addition, in the switching of the OS that occupies the HID, several switching modes are considered in order to improve usability, and provision of switching methods, prevention of unauthorized switching, and HID occupation must be considered for each switching mode.

As the switching pattern, for example, the following examples are considered.

・When a specific program is started on a specific OS

・When a switching button prepared on a keyboard etc. is pressed

・An abnormality has occurred on the OS that is occupying the HID

・When a specific program is forcibly started from the outside for debugging, etc.

In addition, the following examples are considered as what must be considered at the time of OS switching.

Prevent improper HID occupation by specific OS and specific program

· Prevent loss of usability of repeated switching

・Prevent switching when using a program with high priority

Therefore, the present invention was made in view of the above problems, and an object of the present invention is to provide an input/output control device, an input/output control system, and an input/output control method in consideration of efficiency, independence from a host platform, and usability.

The first feature of the present invention is an input/output control device, which controls input devices and output devices configured on computers running at least two or more operating systems simultaneously on a main system having a plurality of operating systems simultaneously executing functions. The main idea is to have: a request accepting unit, which accepts a switching request requesting to switch the operating system occupying the input device or the output device; the control information generating unit, according to the switching request, generates control information including input destination information or output availability information; and a control information output unit that outputs the input destination information or the output availability information, the input destination information including at least Information on an input destination operating system of the input information, wherein the output availability information includes at least information for specifying whether output to the output device is allowed or not for the operating system.

In the first aspect of the present invention, the request accepting unit may accept a switching request from first control software that controls a first input device provided in advance in the computer.

In the first aspect of the present invention, the request accepting unit may accept a switching request from an operating system.

In the first aspect of the present invention, when a request rule defining processing of the switching request is given, the request accepting unit may accept or not accept the switching request according to the request rule.

In the first aspect of the present invention, the request rule may request input of secret information when the switching request is accepted, and the request accepting unit may accept the switching request only when the secret information is correct.

In the first aspect of the present invention, the request rule defines an invalid switching request, and the request accepting unit may not accept the switching request when the switching request is invalid.

In the first aspect of the present invention, the request rule requires a specific action from the user to determine permission/disapproval of the user in the acceptance of the switching request, and the request accepting unit may permission to accept the switching request.

In the first aspect of the present invention, the request accepting unit may accept the switching request when no determination of permission/non-permission of the specific action is obtained from the user within a predetermined time. In the first aspect of the present invention, the request rule defines a specific switching request as a privilege request, and the request accepting unit may not accept the request until a specific condition is satisfied after generating the control information based on the privilege request. The request for switching an input device or an output device that is occupied by a specific operating system is requested via the privilege.

In the first aspect of the present invention, the request accepting unit may accept a handover request from the master system.

In the first aspect of the present invention, the operating system may issue the switching request only when the switching request is permitted by the request rule.

In the first aspect of the present invention, the master system may issue the switching request only when the switching request is permitted by the request rule.

In the first aspect of the present invention, when the first operating system on the computer or the host system has a state change detection function for detecting a specific state change of the operating system running on the computer, the request The accepting unit may accept a switching request issued by the state change detection function in response to the state change of the second operating system occupying the input device or the output device.

The second characteristic of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The main system of the simultaneous execution function and the communication function between the plurality of operating systems, the gist of which is that the input and output control device has: a request accepting unit that requests switching of the input device or the output device The operating system switch request is accepted; the control information generation unit generates control information including input destination information or output availability information based on the switch request; and the control information output unit outputs the input destination information or the output The permission information specifies one of the plurality of operating systems running on the main system, and includes an input device control unit configured to specify an input from the input device based on the outputted input destination information. An operating system of an input destination of the input information, which inputs the input information to the operating system of the input destination; and an output device control unit that specifies an operating system that can be output to the output device based on the output availability information of the output, and outputs the input information to the output device. The output information received from the operating system is output to the output device, the input destination information includes at least information for specifying an input destination operating system of the input information from the input device, and the output availability information includes at least Information for specifying the possibility of output to the output device for the operating system.

In the second characteristic of the present invention, the first operating system different from the specific operating system includes a virtual input device control unit and a virtual output device control unit, and the virtual input device control unit receives The input information input by the input device control unit of the operating system is input to the program running on the first operating system, and the virtual output device control unit is configured to input information from the program running on the first operating system. output information, judging whether the first operating system can output the output information to the output device according to the output availability information, or only under the condition that the output information can be output to the output device, the The output device control unit of the specific operating system outputs the output information.

The third feature of the present invention is an input/output control system comprising: at least one input device; at least one output device; an input/output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The gist of the main system of the simultaneous execution function and the communication function among the plurality of operating systems is that the input and output control device includes a request accepting unit that occupies the input device or the output device for request switching. Accepting a switching request of the operating system; the control information generation unit generates control information including input destination information or output availability information according to the switching request; and a control information output unit outputs the input destination information and the In the output permission information, each of the plurality of operating systems running on the main system includes an input device control unit that determines whether to output data from the input device by referring to the input destination information output by the input and output control device. The input information of the device is input to the operating system; and the output device control unit determines whether to output the output information from the operating system based on the output availability information output by the input and output control means.

The fourth characteristic of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The gist of the main system of the simultaneous execution function and the communication function among the plurality of operating systems is that the input and output control device includes a request accepting unit that occupies the input device or the output device for request switching. Accepting a switching request of the operating system; the control information generation unit generates control information including input destination information or output availability information according to the switching request; and a control information output unit outputs the input destination information and the output permission information, each of the plurality of operating systems has: an input device control unit capable of controlling the input device; and an output device control unit capable of controlling the output device, the host system has an input output control unit, the input An output control unit that enables or disables the input device control unit of the operating system based on the input destination information output from the input-output control unit, and activates or disables the input device control unit based on the output availability information output by the input-output control unit. The output control unit of the operating system is enabled or disabled.

A fifth characteristic of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The main system of the simultaneous execution function and the communication function between the plurality of operating systems, the gist of which is that the input and output control device has: a request accepting unit that requests switching of the input device or the output device Accepting a switching request of an operating system; a control information generating unit generating control information including input destination information or output permission information based on the switching request; and a control information output unit outputting the input destination information and the output permission or non-existence information. information, the host system has an insertion notification unit that notifies the operating system of the insertion when the input device is inserted, and the insertion notification unit is configured according to the input/output control The input destination information output by the device specifies the interrupted notification destination.

The sixth characteristic of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The main system of the simultaneous execution function and the communication function between the plurality of operating systems, the gist of which is that the input and output control device has: a request accepting unit that requests switching of the input device or the output device Accepting a switching request of an operating system; a control information generating unit generating control information including input destination information or output permission information based on the switching request; and a control information output unit outputting the input destination information and the output permission or non-existence information. information, the host system has a QoS control unit that performs QoS control on the operating system based on the input destination information or output permission information output by the input and output control device.

The seventh feature of the present invention is an input/output control method, in which, on a host system having a plurality of operating systems simultaneously executing functions, control of an input device and an output device configured on a computer running at least two or more operating systems simultaneously The gist of controlling input and output is that it has the following steps: accepting a switching request requesting to switch the operating system occupying the input device or the output device; a step of controlling information of the permission information; and a step of outputting the input destination information including at least an input destination operating system for specifying the input information from the input device and the output permission information. information, the output availability information includes at least information for the operating system to specify whether output to the output device is allowed or not.

The eighth feature of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The gist of the main system performing functions simultaneously is that the input/output control device includes: a request accepting unit that accepts a request for switching an operating system occupying the input device or the output device; a control information generating unit , generating control information including input destination information or output availability information according to the switching request; and a control information output unit outputting the input destination information or the output availability information, a program running on the operating system , through the input destination information, only when the operating system running the program is the input destination operating system from the input device, issue a system call to the operating system requesting input, through the The output permission information is limited to the case where the operating system running the program can output to the output device, and a system call is issued to the operating system to request output, and the input destination information contains at least Information on an input destination operating system of the input information of the input device, and the output availability information includes at least information for specifying whether output to the output device is allowed or not for the operating system.

A ninth feature of the present invention is an input-output control system comprising: at least one input device; at least one output device; an input-output control device for controlling the input and output of the input device and the output device; and including a plurality of operating systems The gist of the main system performing functions simultaneously is that the input/output control device includes: a request accepting unit that accepts a request for switching an operating system occupying the input device or the output device; a control information generating unit , generating control information including input destination information or output availability information according to the switching request; and a control information output unit outputting the input destination information or the output availability information, a program running on the operating system requesting the operating system to issue a switching request to the input/output control device, the input destination information includes at least information for specifying an input destination operating system of input information from the input device, and the output The admissibility information includes at least information for the operating system to specify whether output to the output device is allowed or not.

In the ninth aspect of the present invention, the program may request the operating system to issue a switching request to the input/output control device only when the switching request is permitted by the request rule.

As described above, according to the present invention, it is possible to provide an input/output control device, an input/output control system, and an input/output control method that take into account efficiency, do not depend on a host platform, and are usable.

Description of drawings

FIG. 1 is a block diagram showing the configuration of an input/output control system according to a first embodiment.

FIG. 2 is a flowchart showing an input/output control method according to the first embodiment.

Fig. 3 is a block diagram (Part 1) showing the configuration of an input/output control system according to a second embodiment.

Fig. 4 is a block diagram (part 2) showing the configuration of an input/output control system according to a second embodiment.

Fig. 5 is a block diagram (Part 1) showing the configuration of an input/output control system according to a third embodiment.

Fig. 6 is a block diagram (part 2) showing the configuration of an input/output control system according to a third embodiment.

Fig. 7 is a block diagram showing the configuration of an input/output control system according to a third embodiment (Part 3).

Fig. 8 is a block diagram (Part 4) showing the configuration of an input/output control system according to a third embodiment.

Fig. 9 is a block diagram (part 5) showing the configuration of an input/output control system according to a third embodiment.

Fig. 10 is a block diagram showing the configuration of an input/output control system according to a fourth embodiment.

Fig. 11 is a block diagram showing the configuration of an input/output control system according to a fifth embodiment.

Fig. 12 is a structural block diagram (1) of a conventional input/output control system.

Fig. 13 is a block diagram (Part 2) of a conventional input/output control system.

Symbol Description

100 input and output control devices

110 Request Acceptance Department

120 Control Information Generation Department

121 control information

130 control information output unit

210 switch request

211 external input

212 OS processing

213 VMM processing

214OS state change

220 input and output device table

230 input destination information

240 output whether information

250 request rule

310, 410, 510 input device

320, 420, 520 output devices

330, 430, 530VMM

331, 433 debugging function

340, 350, 440, 450, 540, 550OS

341, 441, 451, 541 input device control department

342, 442, 452, 542 output device control department

343, 444 switch button control driver

351A, 443, 453 virtual input and output control devices

351 Virtual Input Device Control Section

352 Virtual Output Device Control Section

360, 370, 460, 470 programs

431 Input and output control unit

432 Insertion Notification Division

434 QOS Control Department

560, 570GUI server

580, 590 GUI client

Detailed ways

Embodiments of the present invention will be described below with reference to the drawings. In the following description of the drawings, the same or similar parts are denoted by the same or similar symbols. However, it should be noted that the drawings are schematic diagrams only.

[the first embodiment]

(Input and output control system)

FIG. 1 is a system configuration of an input/output control device 100 according to the first embodiment. For example, when a plurality of OSs are running on the VMM, and a specific OS among the plurality of OSs occupies and uses a specific device at any time, the input/output control device 100 performs processing such as determination and switching of the OS occupying the specific device. .

As such a specific device, for example, HID is a typical input device such as a keyboard or an output device such as a display.

For example, when the user presses a switch button prepared in advance on the computer while using a program running on another OS, the input/output control device 100 detects the result and generates control information for running the program. The OS of the program occupies the input and output devices.

Specifically, the input/output control device 100 outputs input destination information 230 specifying an input destination OS of input information from an input device, and output availability information 240 specifying an OS capable of outputting output information to an output device.

As shown in FIG. 1 , the input/output control device 100 includes a request accepting unit 110 , a control information generating unit 120 , and a control information output unit 130 . Hereinafter, the processing of each unit will be described.

The request accepting unit 110 performs the following processing when a switch request 210 requesting to switch the OS of the occupied input/output device is issued from a specific request source.

1. Detection of handover request 210

The request accepting unit 110 detects a switching request 210 issued from a specific request source.

The reasons for issuing such a switching request 210 include, for example, an external input 211 , an OS process 212 , a VMM process 213 , and an OS state change 214 .

For example, when the user presses a switch button prepared in advance on the computer, a switch request 211 with "external input 211" as the main cause is generated as hardware insertion.

When hardware insertion occurs, according to the operation of the existing VMM described in the chapters of "Interrupt and Event Handling" starting from [0138] of Patent Document 1, the control based on the device driver that controls the switching button is started, so by The device driver issues the switch request 210 .

Also, for example, if there is no OS occupying the input/output device at this time, or a program running on the OS requests to occupy the input/output device, the OS issues a switching request 210 with "OS processing 212" as the main reason.

The VMM switches the OS occupying the input/output device as necessary by detecting inter-OS events and other OS lower layer processes, so it issues a switching request 210 with "VMM processing 213" as the main reason.

For example, the VMM issues the switching request 210 when executing the OS debugging function of the VMM described in the chapter "Debugging" starting from [0159] of Patent Document 1.

When a specific state change occurs in the OS occupying the input/output device, a switching request 210 is generated with an "OS state change 214" as the main cause.

In particular, when the OS or other OS or VMM has a state change detection function, the state change detection function issues the switching request 210 .

As an example of such a state change, restart of the OS or unplanned shutdown of the OS can be considered.

In addition, an example of the state change detection function is described in the chapter "Hot Reboot of Secondary Operating System" starting from [0122] of Patent Document 1.

Specifically, how to notify the request accepting unit 110 of the switching request 210 issued by each program, each OS, device driver, or VMM depends on the arrangement method of the device driver and the input/output control device 100 .

The details are described in the second to fourth embodiments, but the switching request 210 includes at least information that can identify the request source and the content of the request (for example, which OS occupies the input/output device, or which input/output device requests, etc.).

2. Acceptance/non-acceptance of switching request 210

The request accepting unit 110 cannot accept all the detected switching requests 210 .

This is because, for example, when a malicious program continuously issues switching requests 210 and the request accepting unit 110 accepts all of the switching requests, there is a possibility that switching of the screen occurs after multiple issuances, or the input/output device is occupied for a long time on a specific OS. , which significantly reduces usability.

When given a request rule 250 for judging whether or not a detected handover request 210 should be accepted, the request accepting unit 110 makes an acceptance judgment for the handover request 210 based on the request rule 250 .

Table 1 shows an example of the request rule 250 .

In the example shown in Table 1, a low-reliability general OS and a high-reliability security OS are run, only general programs are run in the general OS, and general programs and privileged programs are run in the security OS.

The difference between the secure OS and the normal OS is that very strong security is ensured in the secure OS, whereas there may be inappropriateness or maliciousness in the OS or programs running on the normal OS.

[Table 1]

The request accepting unit 110 always accepts the switching request 210 from the VMM unconditionally.

This is because the switching request 210 from the VMM is an urgent request issued due to activation of the debugging function as described above.

In addition, it is because the VMM is assumed to be free from program errors and vulnerabilities similarly to the safe OS.

Similarly, the request accepting unit 110 unconditionally accepts the switching request 210 issued by the privileged program of the secure OS.

As the privileged program, for example, a program assumed to be started when the state of the system changes. Specifically, examples of privileged programs include a program that notifies a user of a hardware failure, a program that notifies a user of a decrease in battery power, and a program that notifies a user of a virus detection.

The secure OS itself guarantees security and is designed to avoid usability degradation caused by unnecessary switching as much as possible. Therefore, the request accepting unit 110 unconditionally accepts the switching request 210 from a program that notifies such important information.

The request accepting unit 110 accepts the switching request 210 issued by the general program of the secure OS only when the user permits it.

For example, consider a case in which the switching request 210 is issued to notify the user of the fact when the mail recipient on the secure OS side receives the mail.

At this time, the user is using a specific program of the general OS, and it is possible to avoid interfering with the use of the specific program by switching the OS.

Therefore, once the request accepting unit 110 holds the received switching request 210 , it notifies the general OS for the user to determine whether or not to switch the OS.

Specifically, the request accepting unit 110 activates a user acceptance program existing on the OS that inquires about an acceptance to the user, and the user acceptance program inquires about the above-mentioned determination of the user.

The inter-OS communication function described in "Inter-operating System Communication S-Virtual buS" starting from [149] of Patent Document 1 is used for communication with such a specific OS.

When the user approves OS switching, the request accepting unit 110 accepts the remaining switching request 210 .

In addition, when the user does not approve the OS switching, the request accepting unit 110 does not accept the remaining switching request 210 .

Here, a case is considered in which the user does not respond to whether or not OS switching is permitted.

For example, a case where a user-approved program running on a general OS does not normally run due to an unsuitable situation is considered.

In order to cope with such a situation, the request accepting unit 110 may be configured to accept the switching request 210 when the switching request 210 remains for a certain period of time. Thereby, it is possible to prevent a situation where the reserved switching request 210 is still stored.

The request accepting unit 110 basically performs the same determination as the general program of the secure OS with respect to the switching request 210 issued by the general program of the general OS.

That is, the request accepting unit 110 accepts the switching request 210 when the user approves the OS switching.

However, the request accepting unit 110 does not accept the switching request 210 even if it holds the switching request 210 for a certain period of time.

Since the user-approved program on the secure OS does not unexpectedly shut down due to unsuitable conditions, etc., as long as the user is using the computer, the switching request 210 is basically not held.

In addition, as a general program running on a general OS, a program such as a user downloading from an arbitrary web page can also be assumed.

At this time, it is considered that the program is inappropriate or malicious, or that the switching request 210 is issued illegally.

For example, assume a case where the program continuously issues the switching request 210, or a case where the switching request 210 is also issued when the input/output device does not need to be occupied.

The user can refuse the switching of the OS through the user approval program, but each judgment whether to allow the switching of the OS results in a decrease in usability.

In order to prevent unauthorized switching requests 210 as described above, the user etc. preliminarily sets the conditions for the switching requests 210 to be regarded as unauthorized, and the request accepting unit 110 may automatically not accept the switching requests 210 matching the conditions.

For example, the request accepting unit 110 may not accept the switching request 210 from a program that issues the switching request 210 more than a certain number of times within a certain period of time.

In addition, when the program is installed, the user can set whether or not to reject the switching request 210 issued by the program, so that the conditions for not accepting the switching request 210 can be automatically generated.

At this time, the general OS may rewrite the request rule 250 so that the switch request 210 from the program is not accepted by using the inter-OS communication function or the like according to the designation by the user during the program installation.

Since the switch request 210 issued by the switch button is based on the user's intention, the request accepting unit 110 basically accepts the switch request 210 .

However, there is also a possibility that a third party starts a privileged program related to the root of the system by arbitrarily starting a program on the secure OS.

Therefore, when switching to a secure OS, input of a password (secret information) from the user is prompted. Thus, only authorized users of the computer can switch to the secure OS.

In addition, the calling method and processing method of the program prompting password input are the same as those of the user authorization program.

In addition, the request rule 250 may specify the requested input/output device differently from the rule specified by the request source as described above.

For example, it is common for programs to utilize both the keyboard as standard input and the monitor as standard output.

Thus, for example, the request rule 250 may not accept the switch request 210 when only the keyboard is requested.

Thereby, it is possible to avoid a dead lock state in which a specific program requests to occupy the display while occupying the keyboard, and at the same time, other programs request to occupy the keyboard while occupying the display.

In addition, the request rule 250 may handle the switching request 210 issued by the VMM and the privileged program of the secure OS as a privileged request.

The so-called privilege request is defined as a switching request that unconditionally does not accept the switching request 210 that another OS occupies the input/output device until a specific condition is satisfied when the input/output device is occupied by the specific OS according to the privilege request.

For example, when virus detection software, which is a privileged program of a secure OS, is occupying an input/output device, the privileged program is unconditionally not subject to switching by a general program in order to occupy the input/output device before explicitly opening the input/output device. Request 210.

In addition, the explicit open notification is realized by the same configuration as the notification of the switching request 210 such as an inter-OS communication function.

In addition, the above-mentioned VMM, OS, or program can judge whether the switching request 210 can be issued by referring to the request rule 250 in advance. As a result, issuance of invalid switching requests 210 can be restricted.

When the issue switching request 210 is issued, switching between the OS that the input/output control device 100 operates or the OS of the VMM occurs.

Therefore, by judging in advance whether or not to accept the switching request 210 before issuing it, it is possible to reduce useless switching between OSes and reduce overhead.

However, since the above-mentioned general program may issue the switch request 210 even if it is known to be unacceptable, the request accepting unit 110 may need to recheck the request rule 250 depending on the source of the switch request 210 .

3. Notification of switching request 210

The request accepting unit 110 notifies the control information generating unit 120 of the accepted switching request 210 .

The control information generating unit 120 generates the control information 121 based on the switching request 210 accepted by the request accepting unit 110 .

Here, the control information 121 is state information specifying which OS is currently occupying the input/output device.

The control information generation unit 120 has at least an input/output device table 220 as an input.

For example, as shown in Table 2, the control information 121 specifies which OS occupies all the devices specified by the input/output device table 220 at the current time.

The switching request 210 specifies at least an I/O device for updating control information and an OS occupying the I/O device, so the control information generator 120 can generate the control information 121 according to the switching request 210 .

Here, as described above, the mask state indicates a state in which the switching request 210 of changing the control information 121 by issuance of a privilege request is unconditionally rejected.

[Table 2]

Types of control information Input and output devices occupancy OS Shield status Enter destination information keyboard Security OS Shield Enter destination information mouse Security OS Shield Output whether or not information display Security OS Shield output admissibility information Field speaker General OS

The control information output unit 130 outputs the generated control information 121 .

Specifically, the control information output unit 130 outputs the import destination information 230 for specifying the import destination OS, and the export permission information 240 for determining the export permission for the OS to an appropriate component.

As an output destination, a device driver, a program for a GUI server such as a VMM or a window manager (WindowManager), or the like can be assumed.

In addition, the operation of the control information output unit 130 will be described later.

(Input and output control method)

The input/output control method of the first embodiment will be described using FIG. 2 . Specifically, a method of controlling input and output of an input device or an output device included in a computer in which at least two or more OSs are simultaneously running on a main system having a plurality of OSs that execute functions simultaneously will be described.

As shown in FIG. 2 , in step S101 , the input/output control device 100 accepts a switching request 210 requesting switching of an OS occupying an input device or an output device.

Here, the input/output control device 100 may accept the switching request 210 from the first control software (device driver) of the first input device provided in advance in the control computer, may also accept the switching request 210 from the OS, or may accept the switching request 210 from the main system. The switching request 210 of .

In addition, in step S101 , when the request rule 250 defining the processing of the switching request 210 is given, the input/output control device 100 decides whether to accept or not to accept the switching request 210 according to the request rule 250 .

Also, when the request rule 250 requests input of secret information (password) when accepting the switching request 210, the input/output control device 100 accepts the switching request 210 only when the secret information is correct in step S101.

Alternatively, when the request rule 250 defines an invalid switching request, in step S101 , the input/output control device 100 does not accept the switching request 210 when the detected switching request 210 is invalid.

Here, the "unauthorized switching request" includes, for example, continuous switching requests 210 within a certain period of time, or switching requests 210 issued by an OS for which issuance of the switching requests 210 is not permitted, and the like.

In addition, when the request rule 250 accepts the switching request 210, when it is necessary to determine the user's permission/disapproval based on a specific action from the user, in step S101, the input/output control device 100 The switching request 210 is accepted with permission of the action.

In addition, when the user has not received any determination of permission/non-permission based on a specific action within a certain period of time, in step S101 , the input/output control device 100 accepts the switching request 210 .

In addition, when the request rule 250 sets the specific switching request 210 as a "privilege request", in step S101, the input/output control device 100 generates the control information based on the privilege request and before satisfying a specific condition, according to the privilege request. The switching request 210 for an input device or an output device occupied by a specific OS is not accepted.

Here, the term "specific condition" includes, for example, the case where the processing of the program that issued the privilege request has been completed.

In addition, when the first OS or the main system on the computer has a state change detection function for detecting a specific state change of the OS running on the computer, in step S101, the input/output control device 100 may input or output The state change of the second OS of the device accepts a switching request 210 issued by the state change detection function.

Here, the "state change" is, for example, a change to a state in which the second OS cannot be normally operated due to unexpected shutdown or termination as described above.

In step S102, the input/output control device 100 generates input destination information 230 including at least information specifying the input destination OS from the input device, or at least information specifying whether or not to output to the output device for the OS, based on the switching request 210. The output availability information 240 of the information.

In step S103, the input/output control device 100 outputs the input destination information 230 and the output availability information 240 to appropriate components. The output destination is a GUI server program such as a device driver, VMM, or window manager.

(function and effect)

According to this embodiment, for switching requests 210 generated due to various reasons, control information 121 is generated one by one, so that OSs occupying input and output devices can be switched one by one.

As a result, with regard to input and output performed at arbitrary timing, input information from the input device can be input to an appropriate OS, and only output information from the appropriate OS can be output to the output device.

In addition, since the input and output from other than the occupying OS are not processed after the switching of the OS, context switching between OSes can be reduced and performance can be improved.

In addition, since only the interface between the input/output device and the OS is switched, there is an advantage that it does not depend on the upper-level application program.

In addition, according to the present embodiment, the request accepting unit 110 of the input/output control device 100 accepts the switching request 210 from the first control software (device driver) of the first input device provided in advance in the control computer, so The control information 121 is generated by inputting an input device provided in the computer.

As a result, in the simplest example, in a computer having a special switch button, the OS can be switched by pressing the switch button by the user. Here, a specific button of the keyboard can be allocated and used as the switching button.

In addition, according to the present embodiment, since the request accepting unit 110 of the input/output control device 100 accepts the switching request 210 from the OS, it is possible to generate the control information 121 according to the specific processing of the OS.

As a result, for example, when a specific GUI application program is running on the OS, control of the HID can be transferred to the specific GUI application program.

In addition, according to the present embodiment, when the request accepting unit 110 of the input/output control device 100 is given the request rule 250 specifying the processing for the switching request 210, it judges whether to accept the switching request 210 according to the request rule 250, so that it is possible to prevent Threats such as degradation of usability or risk of confidentiality due to acceptance of all switching requests 210 generated for various reasons.

In addition, according to the present embodiment, in the input/output control device 100, the request rule 250 requests the input of secret information (password) during the acceptance of the switching request 210, and the request accepting unit 110 accepts the switching request only when the secret information is correct. Switching to a specific OS can be restricted by a password or the like.

For example, when a secure OS is prepared for basic computer settings, switching to the secure OS by a third party can be restricted by a password set in advance by the user of the computer.

In addition, according to the present embodiment, in the input/output control device 100, the request rule 250 defines an illegal switching request, and the request accepting unit 110 does not accept the switching request 210 when the switching request 210 is illegal, so that the illegal switching can be restricted. Request 210.

In particular, unauthorized switching requests 210 due to erroneous or malicious operations of an unauthorized OS can be restricted, and occupation of a device with a specific OS and degradation of usability due to repeated OS switching can be prevented.

In addition, according to the present embodiment, in the input/output control device 100, the request rule 250 needs to determine the permission/non-permission of the user based on the user's specific action in the acceptance of the switching request 210, and the request accepting unit 110 performs a decision based on the switching request 210. The switching request 210 is accepted by the permission of the specific operation, so that the switching of the OS can be performed based on the user's permission/non-permission determination.

As a result, when a user utilizes a specific application program, it is possible to prevent deterioration of usability due to sudden OS switching.

Here, when no determination of permission/non-permission is obtained from the user, some abnormality may occur in the part of the program that asks for the permission/non-permission.

For example, it is possible for a GUI application to shut down unexpectedly, or to intentionally not ask the user for the purpose of device hogging.

Therefore, according to the present embodiment, in the input/output control device 100, the request accepting unit 110 accepts the switching request 210 because the user has not received any determination of permission/non-permission of a specific action within a certain period of time, that is, because Since a time-out (time-out) is set in the permission/non-permission response, occurrence of the above-mentioned problem can be prevented.

In addition, according to the present embodiment, in the input/output control device 100, the request rule 250 defines the specific switching request 210 as a privilege request, and the request accepting unit 110 executes the request according to This privilege request does not accept the switch request 210 for the input device or output device occupied by the specific OS. Therefore, the specific switch request 210 is regarded as a privilege request, and the input/output device can be allocated with the highest priority according to the privilege request.

Such a privilege request occurs, for example, at the time of program startup in consideration of forced startup such as a security check on a terminal or a debugging check. In addition, this privilege request has priority over the general switching request 210 that occurs later, and the occupation of the input/output device is not released until the processing is completed.

In addition, according to the present embodiment, since the request accepting unit 110 of the input/output control device 100 accepts the switching request 210 from the main system, it is possible to accept the switching request 210 issued by the main system such as VMM.

As a result, the control information 121 can be generated by the processing of the lower layer of each OS controlled by the VMM.

In addition, according to the present embodiment, in the input/output control device 100, when the first OS or the main system on the computer has a state change detection function for detecting a specific state change of the OS running on the computer, the request accepting unit 110 The state change detection function accepts the switching request 210 issued by the state change of the second OS occupying the input device or output device, so when the OS or VMM detects a state change of a specific OS, it can generate control information 121 based on the state change .

As such a state change, the end of the OS and the unplanned shutdown of the OS are considered, and the state change detection mechanism itself is described in detail in Patent Document 1. As a result, it is possible to prevent the occupation of the input/output device by the OS that is not operating normally.

In addition, according to this embodiment, the OS reads the request rule 250 before issuing the switching request 210, and issues the switching request 210 only when the switching request 210 is accepted by the request accepting unit 110 of the input/output control device 100. The processing cost of inter-OS switching related to the switching request 210 and the processing cost of the main system such as OS and VMM executed by the input/output control device 100 .

In addition, according to this embodiment, before issuing the switching request 210, the host system reads the request rule 250, and issues the switching request 210 only when the switching request 210 is accepted by the request accepting unit 110 of the input/output control device 100. The processing cost of switching between OSes related to the switching request 210 and the processing cost of a main system such as an OS or a VMM operated by the input/output control device 100 can be reduced.

In addition, according to this embodiment, before the program running on the OS that does not occupy the input/output device requests the OS to issue the switching request 210, the read request rule 250 is limited to the switching request 210 that is input to the request accepting unit 110 of the output control device 100. In the case of acceptance, the switch request 210 is issued, so the processing cost of the program on the OS related to the switch request 210 and context switching between the OS and the OS or VMM that the input/output control device 100 runs can be reduced. The processing cost of the main system.

[the second embodiment]

(Input and output control system)

FIG. 3 is a system configuration of a plurality of OS environments including the input/output control device 100 according to the second embodiment.

The input/output control system of the second embodiment includes OS340, OS350, a program 360 running on the OS340, a program 370 running on the OS350, an input device 310, an output device 320, and a VMM330.

Moreover, OS340 has the input-output control apparatus 100, the output device control part 342 which can control the output device 320, and the input device control part 341 which can control the input device 310. FIG.

In addition, the OS 350 has a virtual input device control unit 351 and a virtual output device control unit 352 .

Here, OS 340 is, for example, the secure OS described in the first embodiment, and OS 350 is a general OS.

The input device control unit 341 and the output device control unit 342 have functions as device drivers for controlling devices, and implement extensions for cooperating with the input/output control device 100 .

In addition, the virtual input device control unit 351 and the virtual output device control unit 352 operate as device drivers for the OS 350 and the program 370 .

Actually, the virtual input device control unit 351 is an interface between the input device control unit 341 and the OS 350 , and relays data exchange between the input device 310 and the OS 350 .

In addition, the virtual output device control unit 352 is an interface between the output device control unit 342 and the OS 350 , and relays data exchange between the output device 320 and the OS 350 .

That is, the virtual input device control unit 351 inputs input information from the input device 310 transferred from the input device control unit 341 to the OS 350 .

Also, the virtual output device control unit 352 transfers output information from the OS 350 to the output device control unit 342 .

In fact, the inter-OS communication function provided by the VMM 330 is used to exchange data across these OSs.

In the second embodiment, first, how the input device control unit 341 and the output device control unit 342 operate using the input destination information 230 and the output availability information 240 will be described.

The input/output control device 100 outputs the input destination information 230 to the input device control unit 341 , and outputs the output availability information 240 to the output device control unit 342 .

The input device control unit 341 is driven by inputting input information to the input device 310 from the outside.

The process after the insertion of hardware related to input and before the control of the operation is transferred to the input device control unit 341 depends on the operation of the VMM330. An example of this is described in detail in "Interrupt and Event Handling" starting from [0138] of Patent Document 1. superior.

The input device control unit 341 can specify which OS is currently occupying the input device 310 based on the input destination information 230 , and thus input input information to the OS.

For example, when the OS340 is occupying the input device 310, the input device control unit 341 performs the same operation as a normal device driver, and when the OS350 is occupying the input device 310, the input device control unit 341 inputs an input to the virtual input device control unit 351. information.

The output device control unit 342 can specify which OS is currently occupying the output device 320 by outputting the availability information 240 .

When the OS 340 is occupying the output device 320 , the output device control unit 342 performs the same operation as a normal device driver.

In addition, when the OS 350 is occupying the output device 320 , the output device control unit 342 notifies the virtual output device control unit 352 of the OS 350 of the fact, receives the output information of the OS 350 from the virtual output device control unit 352 and outputs it to the output device 320 .

In addition, the input/output control device 100 may output the input destination information 230 or the output availability information 240 to the virtual input device control unit 351 or the virtual output device control unit 352 , respectively.

At this time, only when the OS 350 is occupying the input device 310, the virtual input device control unit 351 receives input information from the input device control unit 340, and only when the OS 350 is occupying the output device 320, the virtual output device control unit 352 sends The output device control unit 342 outputs output information.

As a result, invalid inter-OS communication can be prevented from occurring between the input device control unit 341 and the virtual input device control unit 351 or between the output device control unit 342 and the virtual output device control unit 352 .

Next, in the configuration of the input/output control system of the second embodiment, how to issue the switching request 210 requesting to switch the occupied OS of the input/output device will be described with reference to FIG. 4 .

In FIG. 4, OS350 also has a virtual input/output control device 351A. As described in the first embodiment, the switch request 210 is largely divided into: a switch request mainly caused by the external input 211, a switch request mainly caused by the OS process 212, a switch request mainly caused by the VMM process 213, and handover requests with OS state change 214 as the main reason.

For example, when the user presses a switch button that the computer has in advance, a switch request 210 is issued due to an external input 211 to switch the occupied OS.

In this case, the switch button control driver 343 which controls the switch button detects that the switch button has been pressed and notifies the input/output control device 100 of the fact.

When the switch button is the same as the input device, the switch button control driver 343 issues the switch request 210 if the input information is related to the switch request 210 , and operates as the input device control unit 341 otherwise.

As for the switching request 210 mainly caused by the OS processing 212 , consider a case where the OS is issued by the program 360 or 370 using the GUI, for example.

When the program 360 issues the switching request 210 , the switching request 210 is issued by issuing a system call to the input/output control device 100 because it is within the same OS.

For example, when a UNIX (registered trademark) OS is assumed, the input/output control device 100 is preliminarily abstracted as a device file (/dev/ioctrl, etc.), the OS 340 is abstracted, and the program 360 issues an ioctrl system call to the device file.

The ioctrl system call can send an individual request to each device file, so the switching request 210 as described in Embodiment 1 can be generated and issued.

Since the program 370 exists in an OS different from that of the input/output control device 100, it cannot issue a system call directly.

Therefore, the virtual input/output control device 351A that relays the switching request 210 is provided to the OS 350 , and the virtual input/output control device 351A notifies the input/output control device 100 of the switching request 210 by using the inter-OS communication function.

The communication between the program 370 and the virtual input/output control device 351 can be realized by the same means as that of the program 360 and the input/output control device 100 .

When issuing the switching request 210 mainly caused by the VMM process 213 , the VMM 330 uses a single communication means such as signal.

Alternatively, the virtual exceptions issued from the VMM to the OS described in the chapter "Handling Virtualized Processor Exceptions" starting from [0095] of Patent Document 1 can be used.

Since VMM330 exists only in one system, it does not matter even if such signals etc. are fixedly defined.

The input/output control device 100 only needs to confirm that the source of the signal is the VMM330.

Regarding the switching request 210 whose main reason is an OS state change, it is assumed that there is a state change detection function in a specific OS or VMM. In this case, the notification of the switching request 210 can be realized by any of the above-mentioned means.

(function and effect)

According to the present embodiment, the specific OS 340 has means for controlling the input device 310 and the output device 320 (the input device control unit 341 and the output device control unit 342), so that all the OSs 340 and 350 can share the input device 310 and the output device 320.

In addition, according to the present embodiment, as long as a specific OS 340 operates safely, it is possible to prevent improper occupation of the input device 310 or the output device 320 due to misoperation or malicious operation of other OS 350 .

In addition, according to the present embodiment, by the virtual input device control unit 351 or the virtual output device control unit 352 of each OS, only when the OS is occupying the input device 310 or the output device 320 , a 341 or the inter-OS communication of the communication of the output device control unit 342 can suppress useless inter-OS communication.

Also, according to the present embodiment, a program running on an OS that does not occupy an input/output device can request the OS to issue the switching request 210 .

For example, when a certain program outputs output information such as images or characters on a display, the switching request 210 is issued to the OS.

Upon receiving the request, the OS issues the switching request 210 to the input/output control device 100 .

As a result, even while the program is running, other OS can occupy the I/O device until an I/O event occurs.

(third embodiment)

In the third embodiment, a case where each OS has an input/output device control unit will be described.

The input/output control system of the third embodiment has, as shown in FIG.

OS 440 has an input device control unit 441 and an output device control unit 442 , and OS 450 has an input device control unit 451 and an output device control unit 452 .

In addition, the VMM 430 has the input/output control device 100 .

In the third embodiment, all OSs 440 and 450 have an input device control unit 441 or an output device control unit 442 that controls input and output devices, respectively.

By adopting such a configuration, compared with the system described in the second embodiment, the performance of input and output is improved. Specifically, an increase in the speed of input and output and a reduction in resource usage can be expected.

The reason is that each device driver does not need to care about other OSs other than the OS to which it belongs, and can directly control the input and output devices, which can omit the processing related to switching between OSes.

In such a system configuration, it is necessary to resolve a so-called hardware conflict state in which input device control units or output device control units belonging to multiple OSs simultaneously refer to a single input/output device.

Therefore, when the input/output control device 100 generates the control information 121 , it outputs the input destination information 230 or the output availability information 240 to all the input device control units 441 and 451 or the output device control units 442 and 452 .

For example, a method of outputting the input destination information 230 or outputting the availability information 240 to all main storage devices that are readable by the OS 440 and 450 and readable by the VMM 430 is conceivable.

Each input device control unit 441, 451 or output device control unit 442, 452 specifies whether the OS 440, 450 to which it belongs is occupying the input device 410 or the output device 420 through the input destination information 230 or the output permission information 240. In case of occupancy, the input device 410 or the output device 420 is controlled.

The input device control unit 441 is driven in response to occurrence of hardware insertion from the input device 410 as in the second embodiment.

In the VMM described in Patent Document 1 or Non-Patent Document 1, if one IRQ (Interrupt ReQuest) line (line) corresponds to an input device control unit operating on a plurality of OSs like this system structure, the sequence When these input device control units are driven, it can be judged whether or not the called input device control unit refers to the input device 410 .

With this configuration, the driven input device control section 441 drives processing as a corresponding device driver if the OS 440 is occupying the input device 410 based on the input destination information 230 . In addition, the input device control unit 451 also performs the same operation.

The output device control unit 442 outputs the output information of the OS 440 to the output device 420 when the OS 440 is occupying the output device 420 based on the output availability information 240 . In addition, the output device control unit 452 also performs the same operation.

As another configuration in which each OS has an input device control unit or an output device control unit, the configuration shown in FIG. 6 is also conceivable. The configuration shown in FIG. 6 is almost the same as the configuration shown in FIG. 5 described above, but the VMM 430 newly includes an input/output control unit 431 .

The input/output control unit 431 has communication means with each OS such as signal or virtual exception, and enables or disables the input device control units 441 and 451 or the output device control units 442 and 452 of each OS based on these communication functions.

For example, when OS 440 or 450 is Linux, Linux can dynamically install or uninstall the device driver during the kernel operation.

Therefore, for example, when the OS 440 occupies the input device 410 by the input/output control device 100 , the input/output control unit 431 notifies the OS 440 to enable the input device control unit 441 of the OS 440 .

OS 440 , upon receiving the notification, loads the input device control unit 441 into the kernel code.

The same processing is performed on the input device control unit 451 or the output device control units 451 and 452 of the other OS 450 .

In addition, the structure shown in FIG. 7 is also considered as another structural example. In the configuration shown in FIG. 7 , VMM 430 newly includes an insertion notification unit 432 .

The interrupt notification unit 432 is obtained by extending the interrupt handler generally included in the VMM described in Patent Document 1 or Non-Patent Document 1 or the like.

A general plug-in processing program, when hardware plug-in occurs, judges the existence of a device driver corresponding to which OS based on the plug-in serial number, and notifies the OS of the plug-in.

When there are multiple devices corresponding to the IRQ numbers and the device drivers controlling the devices are distributed among multiple OSes, the interrupt processing program sequentially notifies the OS of the interrupt.

The interrupt notification unit 432 uses the input destination information 230 in the input/output control device 100 to specify an OS for notification of the interrupt when a interrupt request is generated from the input device 410 .

That is, the interrupt notification unit 432 specifies the OS occupying the input device 410 when the interrupt occurs, and notifies the OS of the interrupt.

Next, in the system configuration of the third embodiment, how to issue the switching request 210 requesting to switch the OS of the occupied input/output device will be described with reference to FIG. 8 .

In FIG. 8 , OS440 and 450 newly include virtual input/output control devices 443 and 453 , and OS440 further includes a switching button control driver 444 as a device driver for switching buttons.

The processing of the programs 460 and 470 to issue the switching request 210 to the virtual input/output control devices 443 and 453 is the same as the processing of the program 370 to issue the switching request 210 to the virtual input/output control device 351 in the second embodiment.

Note that the switching button control driver 444 issues the switching request 210 to the virtual I/O control device 443 in the same manner as the switching button control driver 343 issues the switching request 210 to the I/O control device 100 in the second embodiment.

Furthermore, since the debug function 433 of the VMM and the input/output control device 100 exist in the same memory space controlled by the VMM 430 , no special function is required for issuing the switching request 210 .

When the virtual input/output control devices 443 and 453 issue the switching request 210 to the input/output control device 100 , the VMM 430 uses "hyper call" which is an interface provided to the OS 440 .

The "hyper call" is described in Section 3.1 of Non-Patent Document 1 with the same name, and it is described in [0062] of Patent Document 1 with the name "trap call".

These VMM-OS interfaces are used in the same way as system calls in the prior art. That is, the VMM-OS interface issues a privileged command that cannot be handled by the authority of the OS on the VM when it depends on the VMM.

The hyper call in this embodiment uses the interface functions of these existing technologies.

The information actually notified in the hyper call is as described in the first embodiment.

If the input/output control device 100 accepts the switching request 210 for the received hypercall, it performs the processing described in the first embodiment, and returns an error to the OS if it is rejected for some reason.

Next, an operation example when the VMM 430 has the QOS control unit 434 that operates in conjunction with the input/output control device 100 will be described based on FIG. 9 .

The QOS control unit 434 is an extension of the CPU scheduler described in, for example, chapters of scheduler starting from [0093] of Patent Document 1, and determines hardware resources allocated to each OS based on the priority of each OS process.

For example, the CPU scheduler exists to allocate CPU control according to the priority of each OS process.

The QOS control unit 434 of this embodiment sets a high priority for the OS occupying the input device 410 or the output device 420 based on the input destination information 230 and the output availability information 240 output by the input and output control device 100, and assigns hardware such as a CPU with priority. resource.

As a result, for example, the HID is occupied, and the processing of the OS actually used by the user is prioritized, thereby improving usability.

(function and effect)

According to the present embodiment, each OS 440, 450 has a unit (input device control unit 441, 451 and output device control unit 442, 452) capable of controlling the input/output device, so In the case of , the input device control units 441 and 451 input the input information from the input device 410 to the OS 440 and 450, and only when it is determined that the input and output control device 100 can output the information, the output device control units 442 and 452 output The device 420 outputs the output information from the OS 440, 450, and can prevent the conflict state of the input and output devices of the control object.

In addition, each OS 440 and 450 can directly control the input and output devices, so that the speed of input and output can be increased.

In addition, the VMM 430 has an input-output control unit 431 that enables or disables the input device control units 441 and 451 of the OS 440 and 450 based on the input destination information 230 output from the input-output control device 100 . The output availability information 240 output by the input/output control device 100 enables or disables the output device control units 442 and 452 of the OS440 and 450 .

As a result, when each OS 440, 450 has an input device control unit 441, 451 capable of controlling a specific input device 410 or an output device control unit 442, 452 capable of controlling an output device 420, only by determining that the input and output can be The OS that controls the input and output of the apparatus 100 occupies the input device 410 or the output device 429 to prevent conflicting states of the input device 410 or the output device 420 .

In addition, each OS 440 and 450 can directly control the input and output devices, so that the speed of input and output can be increased.

Furthermore, occupation of the input device 410 or the output device 420 is possible only when the main system permits it, so that illegal occupation of the input device 410 or the output device 420 due to OS malfunction or the like can be prevented.

In addition, VMM 430 has insertion notification unit 432 that notifies OS 440 and 450 of the insertion when input device 410 is inserted. The notification destination for this insertion.

Therefore, when an insertion occurs from the input device 410 , the host system can select an OS that notifies the insertion using the input/output control device 100 .

As a result, each OS 440, 450 can directly control the input device 410, and the speed at the time of input can be improved.

In addition, since the input information from the input device 410 is reliably input to the OS occupying the input device 410, it is possible to prevent unauthorized use of the input device 410 due to malfunction of the OS or the like.

In addition, the VMM 430 has a QOS control unit 434 that performs QOS control on the OS based on the input destination information 230 or the output availability information 240 output by the input/output control device 100 .

Therefore, the host system can perform QOS control for each OS based on the input destination information 230 or the output availability information 240 output by the input/output control device 100 . For example, a high CPU priority is assigned to the processing of the OS occupying the HID.

As a result, a high CPU priority is assigned to a program actually operated by the user, thereby improving usability.

(fourth embodiment)

FIG. 10 is a system configuration of a plurality of OS environments including the input/output control device 100 according to the fourth embodiment.

The input/output control system of the fourth embodiment includes: OS540, OS550, GUI server 560 running on the OS540, GUI server 570 running on the OS550, GUI client 580 running on the GUI server 560, GUI client 590 , input device 510 , output device 520 and VMM 530 running on GUI server 570 .

Moreover, OS540 has the input-output control apparatus 100, the output-device control part 542 which can control the output device 520, and the input-device control part 541 which can control the input device 510. FIG.

Here, since the system configuration of the fourth embodiment is the same as that described in the second embodiment, differences between the two will be mainly described.

In the system of the fourth embodiment, GUI servers 560 , 570 and GUI clients 580 , 590 exist on the respective OS 540 , 550 .

The GUI servers 560 and 570 correspond to window managers, and collectively process the input and output of all GUI programs on the OS 540 and 550 .

GUI clients 580 and 590 are arbitrary GUI programs that entrust input and output to GUI servers 560 and 570 .

The GUI server 560 processes the input and output according to the input and output processing request received from the GUI client 580 .

That is, the GUI server 560 inputs input information from the input device 510 to the GUI client 580 , and outputs output information from the GUI client 580 to the output device 520 .

Furthermore, the GUI server 560 performs the same processing as the GUI client 580 using the GUI server 570 as a GUI client.

Communication between the GUI server 560 and the GUI server 570 is realized by the inter-OS communication function of the VMM 530 .

The GUI server 570 processes the input and output according to the input and output request received from the GUI client 590 .

That is, GUI server 570 inputs input information received from input device 510 via GUI server 560 to GUI client 590 , and outputs output information from GUI client 590 to output device 520 via GUI server 560 .

The GUI server 560 also operates based on the input destination information 230 or the output availability information 240 in the input/output control device 100 .

That is, when the OS 540 occupies the input device 510 or the output device 520 according to these information, the GUI server 560 processes the input and output of the GUI client 580 .

Also, when the OS 550 occupies the input device 510 or the output device 520 , the GUI server 560 notifies the GUI server 570 of the fact.

Through this notification, the GUI server 570 requests the OS 550 for input/output processing only when it is recognized that the OS 550 occupies the input device 510 or the output device 520 .

Conversely, when the OS 550 does not occupy the device, the OS 550 is not entrusted with the input and output of the GUI client 590 .

For example, the communication between the GUI server 560 and the input-output control device 100 is realized through a system call.

(fifth embodiment)

FIG. 11 is a system configuration of a plurality of OS environments including the input/output control device 100 according to the fifth embodiment.

The input/output control system of the fifth embodiment has almost the same configuration as the input/output control system shown in the second embodiment.

That is, the OS 650 and the program 670 running on the OS 650 receive input information from the input device 610 to be controlled through the virtual input device control software 651, and output output information to the output device control software 642 through the virtual output device control software 652.

The difference between this embodiment and the second embodiment is the program 660 and the program 670 . The operation of the program 660 and the program 670 of this embodiment will be described below.

In addition, the program 660 will be described below as an object, and the relationship between the program 660 and the input device control software 641 or the relationship between the program 660 and the output device control software 642 is replaced by the program 670 and the virtual input device control software 651. The relationship of the program 670, or the relationship of the program 670 and the virtual output device control software 652 may also apply to the program 670.

Linux, Windows (registered trademark), etc., which are general-purpose OSs, have interfaces for receiving requests from programs and executing privileged processes executable only with OS authority. The program issues a system call to this interface.

In order to receive input information and output output information via the input device control software 641 or the output device control software 642, the program 660 requires a system call dedicated to each.

For example, the system call used to receive input information in Linux is equivalent to the read system call, and the system call used to output output information is equivalent to the write system call.

The processing of these system calls requires a context switch between the program that issued the system call and the OS, and therefore requires a large processing cost.

In this embodiment, the program 660 performs special processing to reduce the number of system calls issued, thereby reducing the overhead of the entire system.

The input/output control device 100 in this embodiment outputs the control information 121 to an area that the program 660 can refer to. For example, the input/output control device 100 outputs the control information 121 to the shared memory used for inter-OS communication as described above.

As a result, the program 660 can read the control information 121, and can determine whether to issue a system call based on the contents of the control information 121.

That is, based on the control information 121, the program 660 issues a corresponding system call only when the OS 640 is occupying the input device 610 or the output device 620 to be controlled.

As a result, when the I/O to the I/O device cannot be performed because there is no occupation right even if the system call is issued, the issuance of the system call can be suppressed, and overhead can be reduced.

An example of a device capable of reducing the issuance of such a system call is an audio device.

Normally, the output to the audio device should occur in real time according to the program.

That is, in normal use, it is difficult to consider storing the music data when the music data cannot be output because the OS does not occupy the audio device at a certain time, and outputting the audio device when the OS occupies the audio device.

Therefore, the program 660 that outputs music information ignores the music information that should be output when the OS 640 does not occupy the audio device, and does not need to issue an invalid system call.

On the other hand, as a device that cannot reduce the issuance of such a system call, a display is mentioned.

The output information to the display of each OS needs to be stored and updated in the frame buffer memory of the OS when the OS occupies the display or does not occupy the display.

In this way, even when the right to occupy the display is switched, the user can accurately grasp the status of the OS at that time from the display.

In order to achieve the above-mentioned purpose, the OS must constantly update the self-frame buffer, regardless of the content of the control information 121, it must continue to receive output information from the program 660.

As described above, in order to change the operation with reference to the control information 121, the program 660 may be modified.

That is, the program 660 only needs to include the steps of: referring to the control information 121 for the code of the part where input and output occurs;

However, changing the content of the program 660 according to the system is a heavy burden on the programmer, and the advantage of being able to run such a VMM without changing the program 660 is lost.

In addition, it is very difficult for programmers to judge whether to make modifications based on the above-mentioned device differences.

The actual method after installing this embodiment is not to modify the program 660 directly, but to modify the API 661 called by the program 660 during input and output.

Generally, a programmer does not directly incorporate a system call into a code, but calls an API prepared by the system, thereby generating a program to indirectly issue a system call.

Utilizing the API facilitates program design and improves convenience compared to codes that directly call system calls.

In addition, such an API is prepared on each device. Therefore, only the API for invoking a device that needs to determine whether to issue a system call is modified, and the API only needs to have the following steps: a step of referring to the control information 121; a step of determining whether to issue a system call based on the result of the reference; and The decision to issue a step in the system call.

As a result, the creator of the program 660 does not need any changes in the present embodiment, but the number of system calls issued can be suppressed, thereby improving the performance of the entire system.

(function and effect)

According to the present embodiment, the program 660 running on the OS 640 refers to the control information 121 to determine whether the OS 640 is occupying the input device 610 or the output device 620 at the moment, and only when the OS 640 is occupying it, issues information about input and output to the OS. system calls, thereby reducing processing costs required for issuance of invalid system calls.

As mentioned above, although this invention was demonstrated in detail using the said embodiment, it is clear for those skilled in the art that this invention is not limited to embodiment demonstrated in this specification. The present invention can be carried out by correcting and changing the embodiments without departing from the gist and scope of the present invention defined by the claims. Therefore, the description in this specification is for the purpose of illustration and does not have any limiting meaning to the present invention.

Claims (1)

1. input/output control system, have the input-output control unit of input and output of at least one input equipment, at least one output device, the described input equipment of control and described output device and the main system of carrying out function when containing a plurality of operating system, it is characterized in that

Described input-output control unit has: portion is accepted in request, and the handoff request of request being switched the operating system that takies described input equipment or described output device is accepted;

The control information generating unit according to described handoff request, generates and to contain the control information that input destination information or output could information; With

The control information efferent, exporting described input destination information or described output could information,

The program of on described operating system, moving,

According to described input destination information, be only limited to operating system in the described program of operation and be under the situation from the input destination operating system of described input equipment, distribution is to the system call of described operating system request input,

Could information according to described output, be only limited to the operating system of the described program of operation can situation to described output device output under, distribution is to the system call of described operating system request output,

Described input destination information contains the information of determining from the input destination operating system of the input information of described input equipment that is useful at least,

Described output could information contain at least at operating system, being used for determining could be to the information of described output device output.

Images