JP2013191155A - Information processing apparatus - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve data maintainability and user convenience, in an information processing apparatus having a plurality of arithmetic processing parts for virtually executing a plurality of OSs in parallel.SOLUTION: VMM 73 allocates hardware resources such as a storage region with regard to each of a plurality of OSs such as a first OS 71 or a second OS 72 according to a configuration file 77. When accepting a predetermined write request, during data-write by an application 75, the VMM 73 writes data into a spare memory area 85 in parallel with writing into a utilization memory area 82 for OS1 allocated to an OS. The spare memory area 85 is unallocated as a memory area where an OS is usable. When accepting a predetermined read request, the VMM 73 reads data in the spare memory area 85 and restores the data to a memory area allocated to each OS such as the utilization memory area 82 for OS1.

Description

  The present invention relates to an information processing apparatus that includes a plurality of arithmetic processing units and virtually executes a plurality of OSs (Operating Systems) in parallel by a VMM (Virtual Machine Monitor). It relates to technology that improves convenience.

  A virtualization technology for virtually realizing a computer on which an OS operates by software is used. A VM (Virtual Machine) is a virtual implementation of a computer on which a certain OS operates, using software. The VMM is software that enables a plurality of different OSs to be executed in parallel by virtualizing a computer and operating VMs corresponding to the respective OSs. A virtual computer is realized by software, and various applications are executed on the VM.

  In recent years, a system including a plurality of arithmetic processing units such as a multi-core system has become common (see Patent Document 1 below). Even in a multi-core system, a plurality of OSs are virtually operated by a VMM. The VMM manages the allocation of PC (Personal Computer) hardware resources such as which core is allocated to which OS.

  This assignment is made when the VMM is activated based on a setting file described in text data, for example. The VMM allocates hardware resources such as a CPU (Central Processing Unit) and an I / O (Input / Output) device to each OS according to the setting file.

  Hardware resources are managed by the VMM in order to avoid hardware resource contention between OSs. The VMM can also share hardware resources with each OS, for example, by securing a shared memory area accessible to each OS and managing access to this area. This makes it possible to exchange data between OSs.

JP 2009-266050 A

  Assuming that a plurality of OSs are operated, it is assumed that a general-purpose OS having a GUI (Graphical User Interface) and an RTOS (Real Time Operating System) are virtually operated in parallel in one information processing apparatus. The general-purpose OS accepts user operations via a GUI. The general-purpose OS is assumed to bear a function of displaying the result of processing by the RTOS mainly to the user using the GUI. The operation of RTOS is relatively stable. On the other hand, it is assumed that the operation of the general-purpose OS is relatively unstable.

  In this case, there is a problem in data integrity and convenience, such as a situation where data restoration is required due to an abnormal OS operation of the general-purpose OS. The OS operation abnormality means, for example, the following state, a state where there is no response from the OS, a state where the user cannot operate from the UI (User Interface), a state where a screen for notifying the abnormality of the OS is displayed, etc. Say.

  In addition, a plurality of types of screens may be prepared in order to browse the results of RTOS processing. For example, a screen for displaying predetermined data, a screen for accepting input of settings, and the like. Since the operation of the general-purpose OS is based on a memory area allocated to the general-purpose OS, information indicating which screen is displayed when the general-purpose OS displays these screens is lost due to an abnormal OS operation of the general-purpose OS. Therefore, each time the general-purpose OS is restarted, the user needs time and effort such as displaying a desired screen from the initial screen.

  An invention according to an embodiment that solves the above-described problem includes a hardware resource including a plurality of arithmetic processing units, a storage unit, and a plurality of I / O devices, and is virtually installed by a VMM (Virtual Machine Monitor) An information processing apparatus that executes a plurality of OSs (Operating Systems) in parallel, and a storage unit stores setting information indicating allocation of hardware resources for each of the plurality of OSs and a VMM. Based on the allocation indicated in the information, hardware resources are allocated to each OS to manage the operation of each OS, and in response to a request for writing predetermined data from the OS to the operating memory area allocated to the OS, the OS Is an information processing apparatus that writes predetermined data in parallel to an unallocated spare memory area.

  Preferably, the VMM may set a memory area not assigned to any of the plurality of OSs as a spare memory area.

  Preferably, the OS accepts a data write request by an application operating on the OS through a predetermined API (Application Programming Interface), and the VMM issues a data write request to the operating memory area through the predetermined API. In some cases, data may be written to the spare memory area in parallel.

  As a result, data integrity and user convenience can be improved when operating a plurality of OSs in cooperation.

It is a functional block diagram of PC100 which comprises this invention. It is a figure which shows the logical correspondence of a hardware resource and a software resource. It is a figure which shows the setting file 77. FIG. 5 is a diagram showing a spare memory area 85. FIG. 5 is a flowchart showing an operation in which the VMM 73 writes data to the memory 70. 10 is a flowchart showing an operation of reading data from a spare memory area 85 by the VMM 73. It is a figure which shows the write-in and read-out operation | movement to the spare memory area | region 85 through API. It is a figure which shows the example in the case of performing writing and reading through API. It is a figure which shows the operation example by the example of a GUI screen.

The information processing apparatus of the present invention will be described below with reference to the drawings.
<1 configuration>
In this embodiment, an example of a PC as an information processing apparatus will be described. In this PC, a plurality of OSs are virtually executed in parallel by the VMM.

<1.1 PC configuration>
FIG. 1 is a functional block diagram of a PC 100 constituting the present invention.

  As shown in FIG. 1, the PC 100 includes a multi-core 10, a hard disk drive 30, an I / O unit 50, and a memory 70. The PC 100 is connected to an external device 200 or an external device 300 that is an external information processing apparatus by an I / O unit 50. An external information processing apparatus such as the external device 200 is a video display apparatus such as a monitor, for example. These external information processing apparatuses accept video output from the PC 100 and display a predetermined OS GUI (Graphical User Interface) screen. Further, the external information processing apparatus accepts an operation by the operator through a touch panel or the like and outputs it to the PC 100.

  The PC 100 includes a plurality of arithmetic processing units. The functions of the plurality of arithmetic processing units are exhibited by the multi-core 10 in the present embodiment. The multi-core 10 includes a plurality of processor cores (first core 11, second core 12,...), And executes arithmetic processing in parallel according to a program. The first core 11 and the second core 12 are respective processor cores provided in the multi-core 10. The VMM 73 assigns an OS to each processor core according to a setting file 77 described later.

  The hard disk drive 30 is a storage device having a large storage capacity, and stores predetermined programs (first OS 71, second OS 72, VMM 73, application 75, etc.) and data.

  The I / O unit 50 includes a plurality of I / O interfaces for exhibiting input / output functions in the PC 100. As illustrated, the I / O unit 50 includes a plurality of I / O devices (I / O device 51, I / O device 52,...). The I / O devices such as the I / O device 51 and the I / O device 52 are, for example, an output port for video output and a communication port for communicating with an external information processing apparatus.

  The memory 70 is a storage area temporarily used for executing a program. The memory 70 is realized, for example, as SDRAM (Synchronous Dynamic Random Access Memory). The first OS 71, the second OS 72, the VMM 73, the application 75, a setting file 77 described later, and the like are read and stored in the memory 70.

  Each core of the multi-core 10 reads VMs corresponding to each OS from the hard disk drive 30 and stores them in the memory 70 in order to virtually execute a plurality of OSs (first OS 71, second OS 72). ). In the present embodiment, it is assumed that the first OS 71 and the second OS 72 are executed in parallel in cooperation. In the present embodiment, the first OS 71 is a VM for virtually executing a general-purpose OS having a GUI display function. The second OS 72 is a VM for virtually executing an RTOS (Real Time Operating System), for example. A predetermined process is repeatedly executed by the RTOS of the second OS 72 and displayed on the external device 200 or the like by the GUI function of the first OS 71. For example, the RTOS mainly performs repetitive processing related to a factory automation system (FA system) and outputs a calculation result. The general-purpose OS mainly displays the result of processing by the RTOS using a GUI.

  The VMM 73 is a control program for controlling the VM for virtually executing each OS described above. As will be described later, the VMM 73 executes allocation of hardware resources to VMs corresponding to the respective OSs described above using a setting file 77 described later. The VMM 73 manages allocation of hardware resources to each OS and access to hardware resources by each OS.

  The setting application 74 is an application for accepting allocation of hardware resources to each OS from the user. In addition, the setting application 74 displays the assignment of each OS and hardware resources using a GUI. In the present embodiment, the setting application 74 is an application that operates on the first OS 71.

The application 75 is a plurality of applications that are executed in each OS.
<1.2 Logical configuration>
With the physical hardware resources as described above, the PC 100 virtually executes a plurality of OSs in parallel.

Next, a logical configuration in which each software operates will be described.
FIG. 2 is a diagram illustrating a logical correspondence between hardware resources and software resources.

<1.2.1 Software resources>
The VMM 73 allocates hardware resources to each OS at startup according to a setting file 77 described later. As illustrated in FIG. 2, the VMM 73 provides an interface function for accessing each OS (first OS 71 and second OS 72) executed as a VM and hardware resources. Even if the access procedure to the hardware resource is different for each OS, it is absorbed by the VMM 73. Thereby, the VMM 73 comprehensively manages access between each OS and hardware resources.

  In each OS (first OS 71, second OS 72) executed as a VM, applications (application 75a, application 75b) that can be executed on each OS are operating.

<1.2.2 Hardware resources>
As described above, which OS is allocated to the first core 11 and the second core 12 of the multi-core 10 is managed by the VMM 73.

<1.2.3 Allocation of memory 70>
The VMM 73 allocates a storage area to each OS by partitioning the storage area in the memory 70 or the like. The OS1 working memory area 82 indicates a memory area allocated to the first OS 71. The OS2 working memory area 83 indicates a memory area allocated to the second OS 72. This allocation and access to the memory 70 by each OS is also managed by the VMM 73.

  The VMM 73 allocates a shared memory area 84 that can be accessed by each OS in the memory 70. Thereby, a virtual network that can communicate between the cores (the first core 11 and the second core 12) assigned to each OS is formed.

  The VMM 73 manages a spare memory area 85 which is an area different from the memory area allocated to each OS in the memory 70. The spare memory area 85 stores data used for processing in the first OS 71 and the like in an area different from the OS 1 operating memory area 82 and the OS 2 operating memory area 83 assigned to each OS. This is a memory area for backup. Details will be described later.

  In addition, data is input to each core (the first core 11 and the second core 12) by the I / O device (I / O device 51, I / O device 52). The result of the arithmetic processing in each core is output by the I / O device (I / O device 51, I / O device 52).

<2 data>
Next, data in the present embodiment will be described.

FIG. 3 is a diagram showing the setting file 77.
The setting file 77 is read by the VMM 73 when the VMM 73 is activated. In accordance with this setting file 77, the VMM 73 allocates the hardware resources of the PC 100 to each OS. FIG. 3 shows a part of the setting file 77. As shown in the figure, for example, the setting file 77 indicates the allocation of hardware resources in units of OS or in units of individual hardware resources.

  The setting file 77 includes OS1 setting information 81a for starting the OS. The first OS 71 is shown as “OS1”. In the OS1 setting information 81a, the core assigned to the OS, the name of the OS, the order of booting the OS, the memory area assigned to the OS, and the like are set. In the example shown in the figure, for example, the # 1 core among a plurality of processor cores is assigned to the OS1.

  The CPU setting information 81b indicates OS allocation in units of processor cores as hardware resources.

  The IRQ setting information 81c indicates allocation of the OS in units of I / O devices (indicated as “IRQ (Interrupt ReQuest)” in the illustrated example) as hardware resources.

<2.2 Spare memory area 85>
FIG. 4 is a diagram showing the spare memory area 85.

  The spare memory area 85 includes an OS1 spare memory area 86 and an OS2 spare memory area 87. The OS1 spare memory area 86 is a memory area for holding data used in the first OS 71. The OS2 spare memory area 87 is a memory area for holding data used in the second OS72.

  The memory size and the like of the spare memory area 85 are shown in the setting file 77. The VMM 73 reserves the spare memory area 85 according to the setting file 77 at the time of activation.

<3 operation>
Next, the operation in the PC 100 will be described. In the present embodiment, a predetermined API (Application Programming Interface) is prepared for the first OS 71 and the like. The API is used to write data to a spare memory area 85 different from the area assigned to each OS. The application 75 makes a predetermined write request to each OS such as the first OS 71 through the API. As a result, the VMM 73 writes data to the spare memory area 85 as well as to the memory areas (OS1 working memory area 82 and OS2 working memory area 83) assigned to each OS.

<3.1 Write operation>
FIG. 5 is a flowchart showing an operation in which the VMM 73 writes data to the memory 70.

  As shown in FIG. 5, the OS (first OS 71, second OS 72) accepts a write request involving writing to the spare memory area 85 by the API (S51). Each OS receives a write request through the API, and writes to a predetermined address range in the memory area (OS1 operating memory area 82, OS2 operating memory area 83) allocated to each OS. Through.

  The VMM 73 writes data to a predetermined address range in the memory areas (the OS1 operating memory area 82 and the OS2 operating memory area 83) allocated to each OS when each OS receives a write request through the API (S53). .

  The VMM 73 performs writing to the spare memory area 85 in parallel by detecting writing of data to a predetermined address range as described above (S55).

  In this manner, data integrity is improved by realizing data backup to the spare memory area 85 in response to an application request through the API. If the API is generally not disclosed, the development of an application using a backup using the spare memory area 85 is likely to be limited to a developer who knows the existence of the API.

<3.2 Read operation>
The VMM 73 restarts a part of the OS due to an OS operation abnormality of the general-purpose OS. In this case, the data is restored based on the contents held in the spare memory area 85 in response to the read request from the application 75. A read operation in this case will be described.

  FIG. 6 is a flowchart showing an operation of reading data from the spare memory area 85 by the VMM 73.

The VMM 73 restarts one OS (S61).
The VMM 73 receives a read request accompanied by a read from the spare memory area 85 by the predetermined application API of the restarted OS application 75 (S63). Each OS receives a read request through the API, and reads from a predetermined address range in the memory area (OS1 operating memory area 82, OS2 operating memory area 83) allocated to each OS, by the VMM 73. (S63).

  The VMM 73 reads the data from the spare memory area 85 by receiving the data read from the predetermined address range as described above (S65).

  The VMM 73 restores the data by writing the read data to the memory areas (OS1 operating memory area 82, OS2 operating memory area 83) assigned to each OS (S67).

As described above, the write and read operations to the spare memory area 85 have been described.
FIG. 7 is a diagram showing write and read operations to the spare memory area 85 through the API.

  As illustrated, the applications 75a and 75b write and read data to and from the spare memory area 85 through the API 88 and API 89 of each OS (first OS 71 and second OS 72).

FIG. 8 is a diagram illustrating an example of writing and reading through the API.
As shown in the figure, a data name and a variable to be written to the spare memory area 85 are specified through an API by a command such as “backup1”.

FIG. 9 is a diagram illustrating an operation example based on an example of a GUI screen.
The first OS 71, which is a general-purpose OS, has various HMI (Human machine interface) screens for displaying the processing results of the second OS 72, which is an RTOS, and for accepting user operations. It is assumed that which display screen is selected by the user is held by the first OS 71.

  In the example of FIG. 9A, a case where there is no parallel writing process of data to the spare memory area 85 as in the present embodiment is shown. In the first OS 71, information indicating which display screen the user has selected is lost due to an OS operating abnormality of the OS. In the illustrated example, the operation screen 95 is displayed by the first OS 71, but the initial screen 96 is displayed when the first OS 71 is restarted.

  In the example of FIG. 9B, as in the present embodiment, the parallel data writing process to the spare memory area 85 is performed for which screen the user is displaying (S55). Assume that it is necessary to restart the first OS 71 while the operation screen 95 is displayed. After the restart, the screen information displayed by the user is read from the spare memory area 85 and restored. Thereby, even if the first OS 71 is restarted, the user can browse the restoration screen 97 which is the screen before the restart again.

  If there are many types of display screens, a complicated operation is required until the user displays a desired display screen. On the other hand, according to the said embodiment, such a complicated operation can be made unnecessary and a user's convenience can be improved.

  The embodiment has been described as described above. The present invention may be a combination of the above embodiments.

  The embodiment disclosed this time must be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the description above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

  The present invention can be used in an information processing apparatus that virtually executes a plurality of OSs in parallel using a VMM.

  10 multi-core, 11 first core, 12 second core, 30 hard disk drive, 50 I / O unit, 51 I / O device, 52 I / O device, 70 memory, 71 first OS, 72 second OS, 73 VMM, 75 application, 77 setting file, 81a OS1 setting information, 81b CPU setting information, 81c IRQ setting information, 82 OS1 operating memory area, 83 OS2 operating memory area, 84 common memory area, 85 spare memory area 86 OS1 spare memory area, 87 OS2 spare memory area, 95 operation screen, 96 initial screen, 97 restoration screen, 100 PC, 200 external device, 300 external device.

Claims (3)

Information processing that includes hardware resources including a plurality of arithmetic processing units, a storage unit, and a plurality of I / O devices, and virtually executes a plurality of operating systems (OS) in parallel by a virtual machine monitor (VMM). A device,
The storage unit
Setting information indicating allocation of hardware resources for each of the plurality of OSs;
Storing the VMM;
The VMM allocates hardware resources to each OS based on the allocation indicated in the setting information and manages the operation of each OS.
In response to a request to write predetermined data from the OS to the operating memory area allocated to the OS, the predetermined data is written in parallel to a spare memory area not allocated to the OS.
Information processing device. The VMM sets a memory area not assigned to any of the plurality of OSs as the spare memory area.
The information processing apparatus according to claim 1. The OS receives a data write request by an application operating on the OS by a predetermined API (Application Programming Interface),
The VMM writes the data in parallel to the spare memory area when the OS has a data write request to the working memory area through the predetermined API.
The information processing apparatus according to claim 1.

Images