WO2014076799A1 - 仮想計算機システム - Google Patents

仮想計算機システム Download PDF

Info

Publication number
WO2014076799A1
WO2014076799A1 PCT/JP2012/079663 JP2012079663W WO2014076799A1 WO 2014076799 A1 WO2014076799 A1 WO 2014076799A1 JP 2012079663 W JP2012079663 W JP 2012079663W WO 2014076799 A1 WO2014076799 A1 WO 2014076799A1
Authority
WO
WIPO (PCT)
Prior art keywords
guest
host
control data
management unit
side management
Prior art date
Application number
PCT/JP2012/079663
Other languages
English (en)
French (fr)
Inventor
大 宮内
伊藤 孝之
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to US14/435,270 priority Critical patent/US20150277945A1/en
Priority to PCT/JP2012/079663 priority patent/WO2014076799A1/ja
Priority to JP2014546789A priority patent/JP5881852B2/ja
Priority to CN201280077074.4A priority patent/CN104823171A/zh
Publication of WO2014076799A1 publication Critical patent/WO2014076799A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45545Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/105Program control for peripheral devices where the programme performs an input/output emulation function
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45579I/O management, e.g. providing access to device drivers or storage
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45591Monitoring or debugging support

Definitions

  • the present invention relates to a virtual machine system.
  • Complete virtualization is a method in which an actual physical I / O device is completely emulated by a host OS, and the guest OS uses the emulated I / O device.
  • the guest OS controls the emulated I / O device with the standard device driver installed on the guest OS, and the emulated I / O device uses the standard device driver installed on the host OS. To control physical I / O devices.
  • Paravirtualization is a method in which a device driver serving as an interface with virtualization software (virtual machine monitor) is incorporated in both the guest OS and the host OS.
  • the device driver on the guest OS side is called a front end driver
  • the device driver on the host OS side is called a back end driver.
  • the back-end driver converts the device control data passed from the front-end driver into a data structure that can be used by a standard device driver installed on the host OS, and uses the converted control data to create a standard on the host OS.
  • a physical I / O device is controlled via a device driver.
  • the conventional I / O device virtualization using full virtualization and para-virtualization has a problem in that it is necessary to develop in accordance with the internal structure of the virtualization software for each physical I / O device to be virtualized. is there.
  • the main object of the present invention is to solve the above-described problems, eliminates the need for developing a back-end driver for each physical I / O device, and changes the environment on the guest OS side when updating H / W.
  • the main purpose is to realize a configuration in which the system can be updated without any problems.
  • the virtual machine system is Hardware including a physical processor, physical memory, and a plurality of physical I / O (Input / Output) devices; A host OS (Operating System) and a virtual machine monitor operating on the hardware; A virtual machine system having a guest OS operating on the virtual machine monitor, The virtual machine monitor is Relay data between the guest OS and the host OS, The guest OS is A plurality of front-end drivers, each of which corresponds to any one of the plurality of physical I / O devices and inputs control data for controlling the corresponding physical I / O device; A guest OS side management unit that inputs control data from each front-end driver and outputs the input control data to the virtual machine monitor; The host OS is Control data from a front-end driver in a corresponding relationship, each corresponding to one of the plurality of physical I / O devices and having a corresponding physical I / O device in common A plurality of device drivers that control the corresponding physical I / O device based on the input control data; A host OS that inputs control
  • the guest OS side management unit inputs control data from a plurality of front end drivers, outputs control data from the plurality of front end drivers to the virtual machine monitor, and the host OS side management unit outputs the virtual machine monitor.
  • the control data from a plurality of front-end drivers are input, and each control data is output to the corresponding device driver. Therefore, according to the present invention, it is not necessary to develop a back-end driver for each physical I / O device, and the system can be updated without changing the environment on the guest OS side when updating the H / W.
  • FIG. 1 is a diagram illustrating a configuration example of a virtual computer system according to a first embodiment. The figure explaining the problem which arises at the time of delivery of control data.
  • FIG. 3 is a diagram for explaining a control data delivery method according to the first embodiment.
  • FIG. 3 is a flowchart showing application processing according to the first embodiment.
  • FIG. 3 is a flowchart showing front end driver processing according to the first embodiment.
  • the flowchart figure which shows the mapping process (1) of the standard driver call mechanism (1) which concerns on Embodiment 1.
  • FIG. The flowchart figure which shows the mapping process (2) of the standard driver call mechanism (2) which concerns on Embodiment 1.
  • FIG. FIG. 3 is a flowchart showing processing of a standard driver call mechanism (1) according to the first embodiment.
  • FIG. 3 is a flowchart showing processing of a standard driver call mechanism (2) according to the first embodiment.
  • 2 is a diagram illustrating a hardware configuration example of a virtual machine system according to Embodiment 1.
  • FIG. 1
  • Embodiment 1 FIG.
  • the development that grasps the internal structure of the virtualization software for each physical I / O device is not required, and the system can be updated without changing the environment on the guest OS side when the H / W is updated.
  • the structure which can enjoy the merit of making it as it is will be described.
  • FIG. 1 shows a configuration example of a virtual machine system 100 according to the present embodiment.
  • the virtual computer system 100 includes hardware 40, and the host OS 30 and the virtualization software 20 operate using the hardware 40. Then, the guest OS 10 operates using the virtualization software 20.
  • the virtualization software 20 is also called a virtual machine monitor.
  • the virtualization software 20 relays data between the guest OS 10 and the host OS 30.
  • the virtualization software 20 includes a host OS type in which the virtualization software 20 operates as an application program on the host OS 30 and a hypervisor type in which the virtualization software 20 itself operates as the host OS 30.
  • the hardware 40 includes an I / O device A 401, an I / O device B 402, a CPU (Central Processing Unit) 403, and a RAM (Random Access Memory) 404.
  • the I / O device A 401 and the I / O device B 402 are, for example, a secondary storage device such as a magnetic disk device, a communication board, or the like. Although only two I / O devices A 401 and I / O devices B 402 are illustrated in FIG. 1, the number of I / O devices is not limited to two. Further, the hardware 40 of the virtual machine system 100 may include devices other than those shown in FIG.
  • the guest OS 10 includes a front-end driver A 121 and a front-end driver B 122 as device drivers dedicated to the virtualization software 20.
  • the front end driver A121 corresponds to the I / O device A401
  • the frontend driver B122 corresponds to the I / O device B402.
  • the guest OS 10 includes a standard driver call mechanism (1) 13 that is common to the I / O devices to be virtualized.
  • the standard driver call mechanism (1) 13 serves as an interface with the virtualization software 20 on the guest OS 10 side, accepts control data for all I / O devices, and virtualizes control data for all I / O devices. Output to the software 20.
  • the standard driver call mechanism (1) 13 corresponds to an example of a guest OS side management unit.
  • the guest OS 10 includes an application program 11.
  • the application program 11 issues control data for controlling the I / O device A 401 or the I / O device B 402.
  • the host OS 30 includes a standard device driver A 321 for the I / O device A 401 and a standard device driver B 322 for the I / O device B 402. Further, the host OS 30 includes a standard driver call mechanism (2) 31 that is common to the I / O devices to be virtualized.
  • the standard driver call mechanism (2) 31 is a mechanism that serves as an interface with the virtualization software 20 on the host OS 30 side, and receives control data for all I / O devices from the virtualization software 20.
  • the standard driver call mechanism (2) 31 corresponds to an example of a host OS side management unit.
  • the standard driver call mechanism (1) 13 and the standard driver call mechanism (2) 31 are responsible for the transfer of control data between the guest OS 10 and the host OS 30.
  • the virtualization software 20 is concealed from B322. Transfer of control data between the standard driver call mechanism (1) 13 and the standard driver call mechanism (2) 31 is performed using the internal communication mechanism of the virtualization software 20.
  • the I / O device A401 is controlled in cooperation by the front-end driver A121, the standard driver call mechanism (1) 13, the standard driver call mechanism (2) 31, and the standard device driver A321.
  • the front-end driver B122, the standard driver call mechanism (1) 13, the standard driver call mechanism (2) 31, and the standard device driver B322 are controlled in cooperation with the I / O device B402.
  • control data for controlling the I / O device A 401 and the I / O device B 402 is passed from the application program 11 to the front end driver A 121 and the front end driver B 122, respectively.
  • the control data passed from the application program 11 to the front-end driver A121 and the front-end driver B122 is the standard device driver A321, The interface is the same as that of the standard device driver B322.
  • control data is passed from the front-end driver A 121 and the front-end driver B 122 to the standard driver call mechanism (1) 13.
  • the control data passed from the front end driver A121 and the front end driver B122 to the standard driver call mechanism (1) 13 is:
  • the interfaces of the standard device driver A 321 and the standard device driver B 322 are the same.
  • the standard driver call mechanism (1) 13 outputs control data to the virtualization software 20.
  • the virtualization software 20 outputs the control data to the standard driver call mechanism (2) 31.
  • the standard driver call mechanism (2) 31 passes the input control data to the corresponding standard device driver A321 and standard device driver B322.
  • the standard device driver A 321 and the standard device driver B 322 control the I / O device A 401 and the I / O device B 402 based on the received control data.
  • the control data received by the standard device driver A321 and the standard device driver B322 is normal control data not specialized for virtualization, the standard device driver A321 and the standard device driver B322 need not be modified for virtualization. .
  • FIG. 2 shows details of data transfer.
  • control data for the I / O device A 401 is issued from the application program 11 to the front-end driver A 121.
  • the I / O device control data 501 generally includes a pointer 5013.
  • the pointer 5013 refers to data 5014 of a logical address (hereinafter referred to as “guest OS address”) assigned to the guest OS 10 (601). .
  • guest OS address a logical address assigned to the guest OS 10
  • the control data 501 is passed to the front-end driver A 121 and the standard driver call mechanism (1) 13 on the guest OS 10
  • the data 5014 can be referred to without any problem, but the standard driver call mechanism (2) 31 on the host OS 30 can be referred to.
  • the data cannot be referred to normally (602). Even if the control data is passed to the standard device driver A321, the standard device driver A321 cannot normally control the I / O device A401.
  • the front-end driver A 121 passes the pointer 5013 to the mapping processing unit (1) 131 of the standard driver call mechanism (1) 13.
  • the mapping processing unit (1) 131 is one of logical addresses (hereinafter referred to as “host OS address”) assigned to the host OS 30 via the mapping processing unit (2) 311 of the standard driver call mechanism (2) 31.
  • Data 5014 is mapped to (603).
  • the front-end driver A 121 acquires a host OS address that can be referred to from the host OS 30 via the mapping processing unit (2) 311 and the mapping processing unit (1) 131.
  • the front-end driver A 121 generates control data 502 by replacing the pointer 5013 of the control data 501 with a pointer 5015 indicating the acquired host OS address (604). By replacing the pointer 5013 with the pointer 5015, the host OS 30 can recognize that the data 5016 is stored in the host OS address (605). Note that the data 5014 and the data 5016 are the same because they are stored on the same physical address (the address of the RAM 404).
  • the front-end driver A121 passes the control data 502 to the standard device driver A321 via the standard driver call mechanism (1) 13, the virtualization software 20, and the standard driver call mechanism (2) 31.
  • the standard device driver A321 controls the I / O device A401 based on the passed control data 502.
  • the I / O device A 401 can be normally controlled. That is, the standard device driver A321 can read the data 5016 from the host OS address, and can control the I / O device A401 using the read data 5016.
  • the application program 11 passes control data to the front-end driver corresponding to the I / O device to be controlled (S10).
  • the case where the application program 11 issues control data for the I / O device A 401 to the front-end driver A 121 will be described as an example.
  • the front-end driver A121 determines whether or not a pointer is included in the control data when the control data from the application program 11 is input (S20). As described above, the guest OS address is described in the pointer.
  • the front-end driver A121 passes the pointer to the mapping processing unit (1) 131 of the standard driver call mechanism (1) 13 (S21). Then, the front-end driver A121 acquires the host OS address from the mapping processing unit (1) 131 of the standard driver call mechanism (1) 13 (S22). Further, the front-end driver A121 rewrites the original pointer in the control data with a pointer indicating the acquired host OS address, and generates new control data (S23).
  • the front-end driver A121 outputs new control data to the standard driver call mechanism (1) 13 (S24).
  • the front-end driver A121 outputs the input control data as it is to the standard driver call mechanism (1) 13 (S24).
  • mapping processor (1) 131 of the standard driver call mechanism (1) 13 receives the pointer output from the front-end driver A121 in S21 of FIG. 5, the virtualization software 20 is executed as shown in FIG. Then, a pointer is output to the mapping processing unit (2) 311 of the standard driver call mechanism (2) 31 (S30). Next, the mapping processing unit (1) 131 acquires the host OS address from the mapping processing unit (2) 311 of the standard driver call mechanism (2) 31 (S31), and sends the acquired host OS address to the front-end driver A121. Return (S32). The front-end driver A121 acquires the host OS address output from the mapping processing unit (1) 131 as shown in S22 (FIG. 5).
  • mapping processing unit (2) 311 of the standard driver call mechanism (2) 31 receives the pointer output from the mapping processing unit (1) 131 in S30 of FIG. 6, as shown in FIG.
  • the reference destination data is mapped to any logical address that can be referred from the host OS 30 (S40). That is, the mapping processing unit (2) 311 designates the logical address assigned to the host OS 30 corresponding to the physical address of the guest OS address described in the pointer as the host OS address.
  • the mapping processor (2) 311 returns the specified host OS address to the mapping processor (1) 131 of the standard driver call mechanism (1) 13 via the virtualization software 20 (S41).
  • the mapping processor (1) 131 acquires the host OS address output from the mapping processor (2) 311 as shown in S31 (FIG. 6).
  • the standard driver call mechanism (2) 31 When the standard driver call mechanism (2) 31 receives the control data output from the standard driver call mechanism (1) 13 in S50 of FIG. 8, the standard corresponding to the front-end driver A121 as shown in FIG. Control data is output to the device driver A321 (S60). Thereafter, the standard device driver A321 controls the I / O device A401 using the control data.
  • control data is not transferred to a plurality of I / O devices by using the standard driver call mechanism (1) 13 and the standard driver call instead of the unit of the front end driver and the back end driver.
  • Mechanism (2) 31 is used. This eliminates the need for complicated development in consideration of the internal structure of the virtualization software for each I / O device A401 and I / O device B402 to be virtualized, and is conscious of the interfaces of the standard device driver A321 and the standard device driver B322.
  • the I / O device A 401 and the I / O device B 402 can be virtualized only by developing the front end driver A 121 and the front end driver B 122. In other words, there is no need to develop a backend driver.
  • the redevelopment of the front-end driver A121, the front-end driver B122 and the standard driver call mechanism (1) 13 on the guest OS 10 side It is unnecessary. For this reason, it is not necessary to change the environment on the guest OS side when updating the H / W. Further, the redevelopment of the standard driver call mechanism (2) 31 is not required unless the specification of the host OS 30 is changed.
  • the logical address of the pointer that is, an example in which the logical address (guest OS address) assigned to the guest OS is replaced with the logical address (host OS address) assigned to the host OS has been described.
  • a parameter value (guest OS parameter value) assigned to the guest OS is described in the control data, and the guest OS parameter value cannot be referred to by the host OS, this embodiment will explain.
  • the guest OS parameter value in the control data may be replaced with a parameter value (host OS parameter value) assigned to the host OS.
  • FIG. 10 is a diagram illustrating an example of hardware resources of the virtual machine system 100 illustrated in this embodiment. Note that the configuration of FIG. 10 is merely an example of the hardware configuration of the virtual machine system 100, and the hardware configuration of the virtual machine system 100 is not limited to the configuration illustrated in FIG. Also good.
  • the virtual machine system 100 includes a CPU 911 (also referred to as a processor, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, or a microcomputer) that executes a program.
  • the CPU 911 corresponds to the CPU 403 in FIG.
  • the CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, a magnetic disk device 920, and a scanner device 907 via a bus 912. Control wear devices.
  • the RAM 914 corresponds to the RAM 404 in FIG.
  • the communication board 915 and the magnetic disk device 920 correspond to the I / O device A 401 and the I / O device B 402 in FIG.
  • the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), and a printer device 906.
  • FDD 904 Flexible Disk Drive
  • CDD compact disk device
  • SSD Solid State Drive
  • the RAM 914 is an example of a volatile memory.
  • the storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
  • a communication board 915, a keyboard 902, a mouse 903, an FDD 904, a scanner device 907, and the like are examples of input devices.
  • the communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.
  • the communication board 915 is connected to a LAN (Local Area Network).
  • the communication board 915 can be connected to, for example, the Internet, a WAN (Wide Area Network), or the like via a LAN.
  • the magnetic disk device 920 stores virtualization software 921, a host OS 922, a guest OS 923, a program group 924, and a file group 925.
  • the virtualization software 921 corresponds to the virtualization software 20 in FIG. 1
  • the host OS 922 corresponds to the host OS 30 in FIG. 1
  • the guest OS 923 corresponds to the guest OS 10 in FIG. 1 is included in the program group 924.
  • the virtualization software 921, the host OS 922, the guest OS 923, and the program group 924 are executed by the CPU 911.
  • the CPU 911 (the CPU 403 in FIG. 1) processes the front-end driver A121 and the front-end driver B122, and the processing of the guest OS side management unit (standard driver call mechanism (1) 13). Performs the processing of the guest OS side management processing unit, the host OS side management unit (standard driver call mechanism (2) 31), the standard device driver A321, and the standard device driver B322. Corresponds to the standard device driver processing unit.
  • the file group 925 includes “control of”, “determination of”, “acquisition of”, “change of”, “replacement of”, “notification of”, and “control” in the description of this embodiment. ”,“ Specify ”,“ Input of ”,“ Output of ”, etc.
  • Information, data, signal values, variable values, and parameters that indicate the results of the processing are“ It is stored as each item of “Database”.
  • the “ ⁇ file” and “ ⁇ database” are stored in a recording medium such as a disk or a memory.
  • Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, editing, output, printing, and display.
  • Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
  • the arrows in the flowchart described in this embodiment mainly indicate input / output of data and signals
  • the data and signal values are the RAM 914 memory, the FDD904 flexible disk, the CDD905 compact disk, and the magnetic disk device.
  • Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.
  • the virtual computer system 100 includes a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and a display device as an output device, a communication board, and the like.
  • the functions shown as the guest OS 10, the virtualization software 20, and the host OS 30 are realized using these processing devices, storage devices, input devices, and output devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

 フロントエンドドライバA121がI/OデバイスA401に対する制御データを入力し、標準ドライバ呼出し機構(1)13に出力する。フロントエンドドライバB122がI/OデバイスB402に対する制御データを入力し、標準ドライバ呼出し機構(1)13に出力する。標準ドライバ呼出し機構(1)13がI/OデバイスA401に対する制御データ及びI/OデバイスB402に対する制御データを入力し、標準ドライバ呼出し機構(2)31に出力する。標準ドライバ呼出し機構(2)31は、I/OデバイスA401に対する制御データを標準デバイスドライバA321に出力し、I/OデバイスB402に対する制御データを標準デバイスドライバA321に出力する。標準デバイスドライバA321は制御データに基づきI/OデバイスA401を制御し、標準デバイスドライバB322は制御データに基づきI/OデバイスB402を制御する。

Description

仮想計算機システム
 本発明は、仮想計算機システムに関する。
 従来のI/O(Input/Output)デバイスの仮想化方式においては、完全仮想化と準仮想化の手法によって、仮想化を行なっている(例えば、特許文献1、特許文献2)。
 I/Oデバイスを仮想化することによって、ハードウェア(H/W)更新時にもゲストOS(Operating System)側の環境を変更することなく、システムを更新できるメリットが享受できる。
 完全仮想化とは、実在する物理I/OデバイスをホストOSで完全にエミュレートして、ゲストOSが、エミュレートされたI/Oデバイスを利用する方式である。
 ゲストOSからは、ゲストOS上に設置した標準デバイスドライバで、エミュレートされたI/Oデバイスを制御し、エミュレートされたI/Oデバイスが、ホストOS上に設置した標準デバイスドライバを利用して物理I/Oデバイスを制御する。
 準仮想化とは、ゲストOSとホストOSの双方に仮想化ソフトウェア(仮想マシンモニタ)とのインタフェースとなるデバイスドライバを組み込む方式である。
 このゲストOS側のデバイスドライバをフロントエンドドライバ、ホストOS側のデバイスドライバをバックエンドドライバと呼ぶ。
 ゲストOSからの物理I/Oデバイスの制御方法は、まず、フロントエンドドライバから、仮想化ソフトウェアの内部通信機構と共有メモリを利用して、バックエンドドライバに対してデバイスの制御データが渡される。
 バックエンドドライバは、フロントエンドドライバから渡されたデバイスの制御データをホストOS上に設置した標準デバイスドライバで利用可能なデータ構造に変換し、変換後の制御データを用いて、ホストOS上の標準デバイスドライバを介して物理I/Oデバイスを制御する。
特開2010-205124号公報 特開2009-134601号公報
 従来の完全仮想化と準仮想化によるI/Oデバイスの仮想化には、仮想化の対象とする物理I/Oデバイスごとに仮想化ソフトウェアの内部構造に即した開発が必要であるという課題がある。
 従来の完全仮想化においては、物理I/Oデバイスを完全にエミュレートする機能を開発する必要があるが、これは、仮想化ソフトウェアの内部構造や対象の物理I/Oデバイスの詳細を把握した上での開発が必要である。
 そのため、仮想化の対象とする物理I/Oデバイスごとに複雑なエミュレート機能を開発する必要があるという課題がある。
 また、従来の準仮想化においては、仮想化の対象とする物理I/Oデバイスごとに、フロントエンドドライバとバックエンドドライバの組の開発が必要である。
 これは、フロントエンドドライバから仮想化ソフトウェアの内部通信機構を介してバックエンドドライバに渡された制御データを、バックエンドドライバが、標準デバイスドライバで利用可能なデータ構造に変換する必要があるためである。
 このため、対象のI/Oデバイスに特化したフロントエンドドライバとバックエンドドライバの組の開発が必要となる。
 つまり、完全仮想化と同じく、仮想化ソフトウェアの内部構造の詳細を把握した上でのフロントエンドドライバとバックエンドドライバの開発が、仮想化の対象となる物理I/Oデバイスごとに必要であるという課題がある。
 この発明は、上記のような課題を解決することを主な目的としており、物理I/Oデバイスごとのバックエンドドライバの開発を不要とし、H/W更新時にゲストOS側の環境変更を実施することなくシステムが更新できる構成を実現することを主な目的とする。
 本発明に係る仮想計算機システムは、
 物理プロセッサと、物理メモリと、複数の物理I/O(Input/Output)デバイスとを含むハードウェアと、
 前記ハードウェア上で動作するホストOS(Operating System)及び仮想マシンモニタと、
 前記仮想マシンモニタ上で動作するゲストOSとを有する仮想計算機システムであって、
 前記仮想マシンモニタは、
 前記ゲストOSと前記ホストOSとの間でデータの中継を行い、
 前記ゲストOSは、
 各々が、前記複数の物理I/Oデバイスのうちのいずれかの物理I/Oデバイスに対応し、対応する物理I/Oデバイスの制御のための制御データを入力する複数のフロントエンドドライバと、
 各フロントエンドドライバから制御データを入力し、入力した制御データを前記仮想マシンモニタに出力するゲストOS側管理部とを有し、
 前記ホストOSは、
 各々が、前記複数の物理I/Oデバイスのうちのいずれかの物理I/Oデバイスに対応し、対応する物理I/Oデバイスが共通している、対応関係にあるフロントエンドドライバからの制御データを入力し、入力した制御データに基づいて、対応する物理I/Oデバイスを制御する複数のデバイスドライバと、
 前記ゲストOS側管理部から出力された制御データを前記仮想マシンモニタから入力し、入力した制御データを、入力した制御データの出力元のフロントエンドドライバと対応関係にあるデバイスドライバに出力するホストOS側管理部とを有することを特徴とする。
 本発明では、ゲストOS側管理部が、複数のフロントエンドドライバからの制御データを入力し、複数のフロントエンドドライバからの制御データを仮想マシンモニタに出力し、ホストOS側管理部が仮想マシンモニタから複数のフロントエンドドライバからの制御データを入力し、各制御データを対応するデバイスドライバに出力する。
 このため、本発明によれば、物理I/Oデバイスごとにバックエンドドライバを開発する必要がなく、また、H/W更新時にゲストOS側の環境変更を実施することなくシステムが更新できる。
実施の形態1に係る仮想計算機システムの構成例を示す図。 制御データの受け渡し時に生じる問題を説明する図。 実施の形態1に係る制御データの受け渡し方法を説明する図。 実施の形態1に係るアプリケーション処理を示すフローチャート図。 実施の形態1に係るフロントエンドドライバ処理を示すフローチャート図。 実施の形態1に係る標準ドライバ呼出し機構(1)のマッピング処理(1)を示すフローチャート図。 実施の形態1に係る標準ドライバ呼出し機構(2)のマッピング処理(2)を示すフローチャート図。 実施の形態1に係る標準ドライバ呼出し機構(1)の処理を示すフローチャート図。 実施の形態1に係る標準ドライバ呼出し機構(2)の処理を示すフローチャート図。 実施の形態1に係る仮想計算機システムのハードウェア構成例を示す図。
 実施の形態1.
 本実施の形態では、個々の物理I/Oデバイスごとの仮想化ソフトウェアの内部構造を把握した開発を不要とし、H/W更新時にゲストOS側の環境変更を実施することなくシステムが更新できる仮想化のメリットをそのまま享受できる構成を説明する。
 図1は、本実施の形態に係る仮想計算機システム100の構成例を示す。
 仮想計算機システム100は、ハードウェア40を備え、ホストOS30および仮想化ソフトウェア20がハードウェア40を用いて動作する。
 そして、仮想化ソフトウェア20を用いてゲストOS10が動作する。
 仮想化ソフトウェア20は、仮想マシンモニタともいう。
 仮想化ソフトウェア20は、ゲストOS10とホストOS30の間でデータの中継を行う。
 なお、仮想化ソフトウェア20には、ホストOS30上で仮想化ソフトウェア20がアプリケーションプログラムとして動作するホストOS型と仮想化ソフトウェア20そのものがホストOS30として動作するハイパーバイザ型がある。
 ハードウェア40には、I/OデバイスA401、I/OデバイスB402、CPU(Central Processing Unit)403、RAM(Random Access Memory)404が含まれる。
 I/OデバイスA401、I/OデバイスB402は、例えば、磁気ディスク装置等の二次記憶装置、通信ボード等である。
 なお、図1では、I/OデバイスA401、I/OデバイスB402の2つのみを図示しているが、I/Oデバイスの個数は2つに限らない。
 また、仮想計算機システム100のハードウェア40には、図1に示す以外のデバイスが含まれていてもよい。
 ゲストOS10には、仮想化ソフトウェア20専用のデバイスドライバとしてフロントエンドドライバA121、フロントエンドドライバB122が含まれる。
 フロントエンドドライバA121はI/OデバイスA401に対応し、フロントエンドドライバB122はI/OデバイスB402に対応する。
 さらに、ゲストOS10には、仮想化する対象のI/Oデバイスで共通となる標準ドライバ呼出し機構(1)13が含まれる。
 標準ドライバ呼出し機構(1)13は、ゲストOS10側で仮想化ソフトウェア20とのインタフェースとなる機構であり、全てのI/Oデバイスに対する制御データを受け付け、全てのI/Oデバイスに対する制御データを仮想化ソフトウェア20に出力する。
 標準ドライバ呼出し機構(1)13は、ゲストOS側管理部の例に相当する。
 また、ゲストOS10には、アプリケーションプログラム11が含まれる。
 アプリケーションプログラム11は、I/OデバイスA401又はI/OデバイスB402を制御するための制御データを発行する。
 ホストOS30には、I/OデバイスA401の標準デバイスドライバA321、I/OデバイスB402の標準デバイスドライバB322が含まれる。
 また、ホストOS30には、仮想化する対象のI/Oデバイスで共通となる標準ドライバ呼出し機構(2)31が含まれる。
 標準ドライバ呼出し機構(2)31は、ホストOS30側で仮想化ソフトウェア20とのインタフェースとなる機構であり、仮想化ソフトウェア20から全てのI/Oデバイスに対する制御データを受け付ける。
 標準ドライバ呼出し機構(2)31は、ホストOS側管理部の例に相当する。
 ゲストOS10とホストOS30間の制御データの受け渡しは標準ドライバ呼出し機構(1)13と標準ドライバ呼出し機構(2)31が受け持ち、フロントエンドドライバA121、フロントエンドドライバB122と標準デバイスドライバA321、標準デバイスドライバB322からは仮想化ソフトウェア20を隠蔽する。
 標準ドライバ呼出し機構(1)13と標準ドライバ呼出し機構(2)31の間の制御データの受け渡しは、仮想化ソフトウェア20の内部通信機構を利用して行われる。
 次に動作について説明する。
 I/OデバイスA401は、フロントエンドドライバA121、標準ドライバ呼出し機構(1)13、標準ドライバ呼出し機構(2)31、標準デバイスドライバA321が協調しながら制御する。
 同様に、I/OデバイスB402は、フロントエンドドライバB122、標準ドライバ呼出し機構(1)13、標準ドライバ呼出し機構(2)31、標準デバイスドライバB322が協調しながら制御する。
 まず、アプリケーションプログラム11からI/OデバイスA401、I/OデバイスB402を制御するための制御データがフロントエンドドライバA121、フロントエンドドライバB122にそれぞれ渡される。
 このとき、アプリケーションプログラム11のI/Oデバイス制御処理ではアプリケーションプログラム11に仮想化を意識させないために、アプリケーションプログラム11からフロントエンドドライバA121、フロントエンドドライバB122に渡す制御データは、標準デバイスドライバA321、標準デバイスドライバB322のインタフェースと同じものとする。
 次に、フロントエンドドライバA121、フロントエンドドライバB122から標準ドライバ呼出し機構(1)13に制御データを渡す。
 このとき、フロントエンドドライバA121、フロントエンドドライバB122に仮想化ソフトウェア20の内部構造を意識させないために、フロントエンドドライバA121、フロントエンドドライバB122から標準ドライバ呼出し機構(1)13に渡す制御データは、標準デバイスドライバA321、標準デバイスドライバB322のインタフェースと同じものとする。
 続いて、標準ドライバ呼出し機構(1)13は、仮想化ソフトウェア20に制御データを出力する。
 仮想化ソフトウェア20は、制御データを標準ドライバ呼出し機構(2)31に出力する。
 標準ドライバ呼出し機構(2)31は、入力した制御データを、対応する標準デバイスドライバA321、標準デバイスドライバB322に渡す。
 標準デバイスドライバA321、標準デバイスドライバB322は受け取った制御データを基にしてI/OデバイスA401、I/OデバイスB402をそれぞれ制御する。
 このとき、標準デバイスドライバA321、標準デバイスドライバB322が受け取る制御データは仮想化に特化しない通常の制御データであるため、標準デバイスドライバA321、標準デバイスドライバB322の仮想化向けの改変は必要としない。
 図2にデータの受け渡しの詳細を図示する。
 以下では、アプリケーションプログラム11からI/OデバイスA401に対する制御データがフロントエンドドライバA121に発行された場合を例にして説明を行う。
 I/Oデバイスの制御データ501には一般的にポインタ5013が含まれることがあるが、この場合、次の問題が発生する。
 I/Oデバイスの制御データ501はゲストOS10上のデータであるため、ポインタ5013はゲストOS10に割り当てられた論理アドレス(以下、「ゲストOSアドレス」という)のデータ5014を参照している(601)。
 制御データ501がゲストOS10上のフロントエンドドライバA121、標準ドライバ呼出し機構(1)13に渡されたときは、問題なくデータ5014が参照できるが、ホストOS30上の標準ドライバ呼出し機構(2)31に渡されたときには、ポインタ5013がゲストOSアドレスを指し示しているため、正常にデータを参照できない(602)。
 このまま、標準デバイスドライバA321に制御データを渡しても、標準デバイスドライバA321ではI/OデバイスA401の制御が正常に行なえない。
 本実施の形態では、この問題を解決するため、図3に示す動作を行う。
 I/Oデバイスの制御データ501にポインタ5013が含まれる場合、フロントエンドドライバA121がポインタ5013を標準ドライバ呼出し機構(1)13のマッピング処理部(1)131に渡す。
 マッピング処理部(1)131は、標準ドライバ呼出し機構(2)31のマッピング処理部(2)311を介して、ホストOS30に割り当てられたいずれかの論理アドレス(以下、「ホストOSアドレス」という)にデータ5014をマッピングする(603)。
 フロントエンドドライバA121は、マッピング処理部(2)311とマッピング処理部(1)131を介して、ホストOS30から参照可能なホストOSアドレスを取得する。
 そして、フロントエンドドライバA121は、制御データ501のポインタ5013を、取得したホストOSアドレスを指し示すポインタ5015に置き換えて、制御データ502を生成する(604)。
 ポインタ5013からポインタ5015への置き換えにより、ホストOS30では、ホストOSアドレスにデータ5016が格納されていると認識することができる(605)。
 なお、データ5014とデータ5016は同一の物理アドレス(RAM404のアドレス)上に保持されているため同一のものである。
 フロントエンドドライバA121は制御データ502を標準ドライバ呼出し機構(1)13と仮想化ソフトウェア20と標準ドライバ呼出し機構(2)31を介して、標準デバイスドライバA321に渡す。
 標準デバイスドライバA321は、渡された制御データ502を基にして、I/OデバイスA401を制御する。
 このとき、制御データ502のポインタ5015はホストOS30から参照可能なホストOSアドレスを参照しているため、正常にI/OデバイスA401の制御が可能となる。
 つまり、標準デバイスドライバA321は、ホストOSアドレスからデータ5016を読み出し、読み出したデータ5016を用いてI/OデバイスA401を制御することができる。
 次に、本実施の形態に係る仮想計算機システム100の動作を、図4~9のフローチャートを用いて説明する。
 アプリケーションプログラム11は、図4に示すように、制御の対象とするI/Oデバイスに対応するフロントエンドドライバに制御データを渡す(S10)。
 なお、以下では、アプリケーションプログラム11がI/OデバイスA401に対する制御データをフロントエンドドライバA121に発行した場合を例にして説明を行う。
 フロントエンドドライバA121は、図5に示すように、アプリケーションプログラム11からの制御データを入力した場合に、制御データにポインタが含まれるか否かを判断する(S20)。
 ポインタには、前述したように、ゲストOSアドレスが記述されている。
 入力した制御データにポインタが含まれる場合(S20でYES)は、フロントエンドドライバA121は、標準ドライバ呼出し機構(1)13のマッピング処理部(1)131に、ポインタを渡す(S21)。
 そして、フロントエンドドライバA121は、標準ドライバ呼出し機構(1)13のマッピング処理部(1)131からホストOSアドレスを取得する(S22)。
 更に、フロントエンドドライバA121は、取得したホストOSアドレスを指し示すポインタで、制御データ内の元のポインタを書き換えて、新たな制御データを生成する(S23)。
 更に、フロントエンドドライバA121は、新たな制御データを標準ドライバ呼出し機構(1)13に出力する(S24)。
 一方、入力した制御データにポインタが含まれない場合(S20でNO)は、フロントエンドドライバA121は、入力した制御データをそのまま標準ドライバ呼出し機構(1)13に出力する(S24)。
 標準ドライバ呼出し機構(1)13のマッピング処理部(1)131が、図5のS21においてフロントエンドドライバA121から出力されたポインタを入力した場合は、図6に示すように、仮想化ソフトウェア20を介して標準ドライバ呼出し機構(2)31のマッピング処理部(2)311にポインタを出力する(S30)。
 次に、マッピング処理部(1)131は、標準ドライバ呼出し機構(2)31のマッピング処理部(2)311からホストOSアドレスを取得し(S31)、取得したホストOSアドレスをフロントエンドドライバA121に返す(S32)。
 フロントエンドドライバA121では、前述のS22(図5)に示すとおり、マッピング処理部(1)131から出力されたホストOSアドレスを取得する。
 標準ドライバ呼出し機構(2)31のマッピング処理部(2)311が、図6のS30においてマッピング処理部(1)131から出力されたポインタを入力した場合は、図7に示すように、ポインタの参照先のデータをホストOS30から参照可能ないずれかの論理アドレスにマッピングする(S40)。
 つまり、マッピング処理部(2)311は、ポインタに記述のゲストOSアドレスの物理アドレスに対応する、ホストOS30に割り当てられている論理アドレスをホストOSアドレスとして指定する。
 次に、マッピング処理部(2)311は、指定したホストOSアドレスを仮想化ソフトウェア20を介して標準ドライバ呼出し機構(1)13のマッピング処理部(1)131に返す(S41)。
 マッピング処理部(1)131では、前述のS31(図6)に示すとおり、マッピング処理部(2)311から出力されたホストOSアドレスを取得する。
 標準ドライバ呼出し機構(1)13が、図5のS24においてフロントエンドドライバA121から出力された制御データを入力した場合は、図8に示すように、仮想化ソフトウェア20を介して標準ドライバ呼出し機構(2)31に制御データを出力する(S50)。
 標準ドライバ呼出し機構(2)31が、図8のS50において標準ドライバ呼出し機構(1)13から出力された制御データを入力した場合は、図9に示すように、フロントエンドドライバA121に対応する標準デバイスドライバA321に制御データを出力する(S60)。
 その後、標準デバイスドライバA321では、制御データを用いてI/OデバイスA401を制御する。
 以上のように、本実施の形態では、複数のI/Oデバイスに対する制御データの受け渡しを、フロントエンドドライバとバックエンドドライバの組の単位ではなく、標準ドライバ呼出し機構(1)13と標準ドライバ呼出し機構(2)31で行っている。
 このため、仮想化する対象のI/OデバイスA401、I/OデバイスB402ごとに仮想化ソフトウェアの内部構造を意識した複雑な開発が不要となり、標準デバイスドライバA321、標準デバイスドライバB322のインタフェースを意識したフロントエンドドライバA121、フロントエンドドライバB122の開発のみでI/OデバイスA401、I/OデバイスB402を仮想化することができる。
 つまり、バックエンドドライバを開発する必要がない。
 また、H/W更新時にも標準デバイスドライバA321、標準デバイスドライバB322のインタフェースは変わらないため、ゲストOS10側のフロントエンドドライバA121、フロントエンドドライバB122と標準ドライバ呼出し機構(1)13の再開発は不要である。
 このため、H/W更新時のゲストOS側の環境変更は不要である。
 また、標準ドライバ呼出し機構(2)31についてもホストOS30の仕様変更がない限り、再開発は不要である。
 なお、以上では、ポインタの論理アドレスを置き換える例、すなわち、ゲストOSに割り当てられている論理アドレス(ゲストOSアドレス)をホストOSに割り当てられている論理アドレス(ホストOSアドレス)に置き換える例を説明した。
 論理アドレス以外にも、制御データにゲストOSに割り当てられているパラメータ値(ゲストOSパラメータ値)が記述されており、ホストOSではゲストOSパラメータ値を参照できない場合には、本実施の形態で説明した手法により、制御データ内のゲストOSパラメータ値をホストOSに割り当てられているパラメータ値(ホストOSパラメータ値)に置き換えるようにしてもよい。
 最後に、本実施の形態に示した仮想計算機システム100のハードウェア構成例について説明する。
 図10は、本実施の形態に示す仮想計算機システム100のハードウェア資源の一例を示す図である。
 なお、図10の構成は、あくまでも仮想計算機システム100のハードウェア構成の一例を示すものであり、仮想計算機システム100のハードウェア構成は図10に記載の構成に限らず、他の構成であってもよい。
 図10において、仮想計算機システム100は、プログラムを実行するCPU911(プロセッサ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータともいう)を備えている。
 CPU911は図1のCPU403に対応する。
 CPU911は、バス912を介して、例えば、ROM(Read Only Memory)913、RAM914、通信ボード915、表示装置901、キーボード902、マウス903、磁気ディスク装置920、スキャナ装置907と接続され、これらのハードウェアデバイスを制御する。
 RAM914は図1のRAM404に対応する。
 また、通信ボード915及び磁気ディスク装置920は、図1のI/OデバイスA401及びI/OデバイスB402に対応する。
 更に、CPU911は、FDD904(Flexible Disk Drive)、コンパクトディスク装置905(CDD)、プリンタ装置906と接続していてもよい。
 また、磁気ディスク装置920の代わりに、SSD(Solid State Drive)を用いてもよい。
 RAM914は、揮発性メモリの一例である。
 ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。
 これらは、記憶装置の一例である。
 通信ボード915、キーボード902、マウス903、FDD904、スキャナ装置907などは、入力装置の一例である。
 また、通信ボード915、表示装置901、プリンタ装置906などは、出力装置の一例である。
 通信ボード915は、LAN(Local Area Network)に接続される。
 通信ボード915は、LANを介して、例えば、インターネット、WAN(Wide Area Network)などに接続することが可能である。
 磁気ディスク装置920には、仮想化ソフトウェア921、ホストOS922、ゲストOS923、プログラム群924、ファイル群925が記憶されている。
 仮想化ソフトウェア921は図1の仮想化ソフトウェア20に対応し、ホストOS922は図1のホストOS30に対応し、ゲストOS923は図1のゲストOS10に対応する。
 また、図1のアプリケーションプログラム11は、プログラム群924に含まれる。
 仮想化ソフトウェア921、ホストOS922、ゲストOS923、プログラム群924は、CPU911により実行される。
 この意味で、CPU911(図1のCPU403)は、フロントエンドドライバA121、フロントエンドドライバB122の処理を行うフロントエンドドライバ処理部と、ゲストOS側管理部(標準ドライバ呼出し機構(1)13)の処理を行うゲストOS側管理処理部と、ホストOS側管理部(標準ドライバ呼出し機構(2)31)の処理を行うホストOS側管理処理部と、標準デバイスドライバA321、標準デバイスドライバB322の処理を行う標準デバイスドライバ処理部に相当する。
 更に、ファイル群925には、本実施の形態の説明において、「~の判断」、「~の取得」、「~の変更」、「~の置き換え」、「~の通知」、「~の制御」、「~の指定」、「~の入力」、「~の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「~ファイル」や「~データベース」の各項目として記憶されている。
 「~ファイル」や「~データベース」は、ディスクやメモリなどの記録媒体に記憶される。
 ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのCPUの動作に用いられる。
 抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
 また、本実施の形態で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ブルーレイ(登録商標)ディスク、DVD等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
 また、本実施の形態で説明した仮想計算機システム100の動作を例えばデータ処理方法として把握することも可能である。
 このように、本実施の形態に示す仮想計算機システム100は、処理装置たるCPU、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、ゲストOS10、仮想化ソフトウェア20、ホストOS30として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
 10 ゲストOS、11 アプリケーションプログラム、13 標準ドライバ呼出し機構(1)、20 仮想化ソフトウェア、30 ホストOS、31 標準ドライバ呼出し機構(2)、40 ハードウェア、100 仮想計算機システム、121 フロントエンドドライバA、122 フロントエンドドライバB、131 マッピング処理部(1)、311 マッピング処理部(2)、321 標準デバイスドライバA、322 標準デバイスドライバB、401 I/OデバイスA、402 I/OデバイスB、403 CPU、404 RAM。

Claims (6)

  1.  物理プロセッサと、物理メモリと、複数の物理I/O(Input/Output)デバイスとを含むハードウェアと、
     前記ハードウェア上で動作するホストOS(Operating System)及び仮想マシンモニタと、
     前記仮想マシンモニタ上で動作するゲストOSとを有する仮想計算機システムであって、
     前記仮想マシンモニタは、
     前記ゲストOSと前記ホストOSとの間でデータの中継を行い、
     前記ゲストOSは、
     各々が、前記複数の物理I/Oデバイスのうちのいずれかの物理I/Oデバイスに対応し、対応する物理I/Oデバイスの制御のための制御データを入力する複数のフロントエンドドライバと、
     各フロントエンドドライバから制御データを入力し、入力した制御データを前記仮想マシンモニタに出力するゲストOS側管理部とを有し、
     前記ホストOSは、
     各々が、前記複数の物理I/Oデバイスのうちのいずれかの物理I/Oデバイスに対応し、対応する物理I/Oデバイスが共通している、対応関係にあるフロントエンドドライバからの制御データを入力し、入力した制御データに基づいて、対応する物理I/Oデバイスを制御する複数の標準デバイスドライバと、
     前記ゲストOS側管理部から出力された制御データを前記仮想マシンモニタから入力し、入力した制御データを、入力した制御データの出力元のフロントエンドドライバと対応関係にある標準デバイスドライバに出力するホストOS側管理部とを有することを特徴とする仮想計算機システム。
  2.  各フロントエンドドライバは、
     入力した制御データに前記ゲストOSに割り当てられているパラメータ値であるゲストOSパラメータ値が記述されているか否かを判断し、
     前記制御データに前記ゲストOSパラメータ値が記述されている場合に、前記仮想マシンモニタ及び前記ゲストOS側管理部を介して前記ホストOS側管理部から、前記ゲストOSパラメータ値に対応する、前記ホストOSに割当てられているパラメータ値をホストOSパラメータ値として取得し、
     前記制御データの前記ゲストOSパラメータ値の記述を前記ホストOSパラメータ値の記述に変更し、前記ホストOSパラメータ値が記述される制御データを前記ゲストOS側管理部及び前記仮想マシンモニタ及び前記ホストOS側管理部を介して、対応関係にある標準デバイスドライバに出力し、
     各標準デバイスドライバは、
     前記ゲストOSパラメータ値に代えて前記ホストOSパラメータ値が記述される制御データを前記ホストOS側管理部から入力し、入力した制御データに基づいて、対応する物理I/Oデバイスを制御することを特徴とする請求項1に記載の仮想計算機システム。
  3.  各フロントエンドドライバは、
     前記制御データに前記ゲストOSパラメータ値が記述されている場合に、前記ゲストOS側管理部及び前記仮想マシンモニタを介して前記ホストOS側管理部に、前記ゲストOSパラメータ値を通知し、
     前記ホストOS側管理部は、
     前記ゲストOS側管理部及び前記仮想マシンモニタを介して、いずれかのフロントエンドドライバから前記ゲストOSパラメータ値が通知された場合に、
     通知された前記ゲストOSパラメータ値に対応する、前記ホストOSに割当てられているパラメータ値をホストOSパラメータ値として前記仮想マシンモニタ及び前記ゲストOS側管理部を介して、前記ゲストOSパラメータ値の通知元のフロントエンドドライバに通知し、
     各フロントエンドドライバは、
     前記仮想マシンモニタ及び前記ゲストOS側管理部を介して、前記ホストOS側管理部から前記ホストOSパラメータ値が通知された場合に、
     前記制御データの前記ゲストOSパラメータ値の記述を前記ホストOSパラメータ値の記述に変更し、前記ホストOSパラメータ値が記述される制御データを前記ゲストOS側管理部及び前記仮想マシンモニタ及び前記ホストOS側管理部を介して、対応関係にある標準デバイスドライバに出力することを特徴とする請求項2に記載の仮想計算機システム。
  4.  各フロントエンドドライバは、
     前記ゲストOSパラメータ値として、入力した制御データに前記ゲストOSに割り当てられている論理アドレスであるゲストOSアドレスが記述されているか否かを判断し、
     前記制御データに前記ゲストOSアドレスが記述されている場合に、前記ゲストOSアドレスの物理アドレスに対応する、前記ホストOSに割り当てられている論理アドレスをホストOSアドレスとして、前記仮想マシンモニタ及び前記ゲストOS側管理部を介して前記ホストOS側管理部から取得し、
     前記制御データの前記ゲストOSアドレスの記述を前記ホストOSアドレスの記述に変更し、前記ホストOSアドレスが記述される制御データを前記ゲストOS側管理部及び前記仮想マシンモニタ及び前記ホストOS側管理部を介して、対応関係にある標準デバイスドライバに出力し、
     各標準デバイスドライバは、
     前記ゲストOSアドレスに代えて前記ホストOSアドレスが記述される制御データを前記ホストOS側管理部から入力し、入力した制御データに基づいて、対応する物理I/Oデバイスを制御することを特徴とする請求項2又は3に記載の仮想計算機システム。
  5.  各フロントエンドドライバは、
     前記制御データに前記ゲストOSアドレスが記述されている場合に、前記ゲストOS側管理部及び前記仮想マシンモニタを介して前記ホストOS側管理部に、前記ゲストOSアドレスを通知し、
     前記ホストOS側管理部は、
     前記ゲストOS側管理部及び前記仮想マシンモニタを介して、いずれかのフロントエンドドライバから前記ゲストOSアドレスが通知された場合に、
     前記ゲストOSアドレスの物理アドレスに対応する、前記ホストOSに割り当てられている論理アドレスをホストOSアドレスとして、前記仮想マシンモニタ及び前記ゲストOS側管理部を介して、前記ゲストOSアドレスの通知元のフロントエンドドライバに通知し、
     各フロントエンドドライバは、
     前記仮想マシンモニタ及び前記ゲストOS側管理部を介して、前記ホストOS側管理部から前記ホストOSアドレスが通知された場合に、
     前記制御データの前記ゲストOSアドレスの記述を前記ホストOSアドレスの記述に変更し、前記ホストOSアドレスが記述される制御データを前記ゲストOS側管理部及び前記仮想マシンモニタ及び前記ホストOS側管理部を介して、対応関係にある標準デバイスドライバに出力することを特徴とする請求項4に記載の仮想計算機システム。
  6.  前記物理プロセッサは、
     各フロントエンドドライバの処理を行うフロントエンドドライバ処理部と、
     前記ゲストOS側管理部の処理を行うゲストOS側管理処理部と、
     前記ホストOS側管理部の処理を行うホストOS側管理処理部と、
     各標準デバイスドライバの処理を行う標準デバイスドライバ処理部とを有することを特徴とする請求項1~5のいずれかに記載の仮想計算機システム。
PCT/JP2012/079663 2012-11-15 2012-11-15 仮想計算機システム WO2014076799A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US14/435,270 US20150277945A1 (en) 2012-11-15 2012-11-15 Virtual computer system
PCT/JP2012/079663 WO2014076799A1 (ja) 2012-11-15 2012-11-15 仮想計算機システム
JP2014546789A JP5881852B2 (ja) 2012-11-15 2012-11-15 仮想計算機システム
CN201280077074.4A CN104823171A (zh) 2012-11-15 2012-11-15 虚拟计算机系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/079663 WO2014076799A1 (ja) 2012-11-15 2012-11-15 仮想計算機システム

Publications (1)

Publication Number Publication Date
WO2014076799A1 true WO2014076799A1 (ja) 2014-05-22

Family

ID=50730739

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/079663 WO2014076799A1 (ja) 2012-11-15 2012-11-15 仮想計算機システム

Country Status (4)

Country Link
US (1) US20150277945A1 (ja)
JP (1) JP5881852B2 (ja)
CN (1) CN104823171A (ja)
WO (1) WO2014076799A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017123153A (ja) * 2015-11-24 2017-07-13 シトリックス・システムズ・インコーポレイテッドCitrix Systems,Inc. 一般的なデバイスリダイレクションを介したリモートセッションキーボードおよびマウス入力

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107278293B (zh) * 2017-05-08 2020-11-06 深圳前海达闼云端智能科技有限公司 虚拟机的传感器实现装置及其方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007334572A (ja) * 2006-06-14 2007-12-27 Nec Corp Os切り替えシステム、仮想計算機システム、os切り替え方法及びos切り替え用プログラム
JP2010040043A (ja) * 2008-08-06 2010-02-18 Samsung Electronics Co Ltd 仮想化装置の制御方法及び仮想化装置
JP2010205124A (ja) * 2009-03-05 2010-09-16 Nec Corp 仮想化装置におけるpciデバイスのコンフィグレーション処理方法及びコンピュータシステム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7272831B2 (en) * 2001-03-30 2007-09-18 Intel Corporation Method and apparatus for constructing host processor soft devices independent of the host processor operating system
US20070061441A1 (en) * 2003-10-08 2007-03-15 Landis John A Para-virtualized computer system with I/0 server partitions that map physical host hardware for access by guest partitions
US20050251806A1 (en) * 2004-05-10 2005-11-10 Auslander Marc A Enhancement of real-time operating system functionality using a hypervisor
JP5210730B2 (ja) * 2007-11-28 2013-06-12 株式会社日立製作所 仮想マシンモニタ及びマルチプロセッサシステム
US7904914B2 (en) * 2008-09-30 2011-03-08 Microsoft Corporation On-the-fly replacement of physical hardware with emulation
US8473947B2 (en) * 2010-01-18 2013-06-25 Vmware, Inc. Method for configuring a physical adapter with virtual function (VF) and physical function (PF) for controlling address translation between virtual disks and physical storage regions
US9514507B2 (en) * 2011-11-29 2016-12-06 Citrix Systems, Inc. Methods and systems for maintaining state in a virtual machine when disconnected from graphics hardware
US9280378B2 (en) * 2011-11-30 2016-03-08 Red Hat, Inc. Adjustment during migration to a different virtualization environment
US9880868B2 (en) * 2011-11-30 2018-01-30 Red Hat, Inc. Modifying an OS installer to allow for hypervisor-specific adjustment of an OS
US9009702B2 (en) * 2011-11-30 2015-04-14 Red Hat Israel, Ltd. Application-driven shared device queue polling in a virtualized computing environment
US8631408B2 (en) * 2011-11-30 2014-01-14 Red Hat, Inc. Configuring parameters of a guest operating system based on detected events
US20140019964A1 (en) * 2012-07-13 2014-01-16 Douglas M. Neuse System and method for automated assignment of virtual machines and physical machines to hosts using interval analysis

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007334572A (ja) * 2006-06-14 2007-12-27 Nec Corp Os切り替えシステム、仮想計算機システム、os切り替え方法及びos切り替え用プログラム
JP2010040043A (ja) * 2008-08-06 2010-02-18 Samsung Electronics Co Ltd 仮想化装置の制御方法及び仮想化装置
JP2010205124A (ja) * 2009-03-05 2010-09-16 Nec Corp 仮想化装置におけるpciデバイスのコンフィグレーション処理方法及びコンピュータシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017123153A (ja) * 2015-11-24 2017-07-13 シトリックス・システムズ・インコーポレイテッドCitrix Systems,Inc. 一般的なデバイスリダイレクションを介したリモートセッションキーボードおよびマウス入力

Also Published As

Publication number Publication date
CN104823171A (zh) 2015-08-05
US20150277945A1 (en) 2015-10-01
JP5881852B2 (ja) 2016-03-09
JPWO2014076799A1 (ja) 2016-09-08

Similar Documents

Publication Publication Date Title
US10496613B2 (en) Method for processing input/output request, host, server, and virtual machine
US7434003B2 (en) Efficient operating system operation on a hypervisor
JP2009187368A (ja) Usbポートの共有制御方法
US10169075B2 (en) Method for processing interrupt by virtualization platform, and related device
US8732427B2 (en) Systems and methods for collapsing a derivative version of a primary storage volume
US10977191B2 (en) TLB shootdowns for low overhead
CN108139937B (zh) 多根i/o虚拟化系统
US20140298330A1 (en) Information processing device, transmission control method, and computer-readable recording medium
JP5372262B2 (ja) 割込み信号受付け装置及びコンピュータ装置
JP5881852B2 (ja) 仮想計算機システム
JP6716645B2 (ja) ハードウェア内で変換索引バッファ(tlb)シュートダウンを指示および追跡するための方法およびシステム、並びに非一時的なコンピュータ可読媒体
US8752046B2 (en) Virtual calculating machine system, virtual calculating machine control apparatus and virtual calculating machine control method
US20140215467A1 (en) Method and Virtualization Controller for Managing a Computer Resource With at Least Two Virtual Machines
KR20220048311A (ko) 가상화 환경에서 사용자 가상머신의 화면을 미러링하는 방법
US20200348962A1 (en) Memory-fabric-based processor context switching system
US20240168785A1 (en) Remote desktop composition
US11106543B2 (en) Application image cloning system
JPWO2018173300A1 (ja) I/o制御方法およびi/o制御システム
US10642625B2 (en) Branch rewriting device feature optimization
US10394512B2 (en) Multi-monitor alignment on a thin client
WO2014155693A1 (ja) 仮想マシンイメージ管理サーバ、及び仮想マシンイメージ管理方法
JP2015215782A (ja) 情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12888487

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014546789

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14435270

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12888487

Country of ref document: EP

Kind code of ref document: A1