JP5846836B2

JP5846836B2 - 仮想計算機、仮想計算機システム、及び仮想計算機制御方法

Info

Publication number: JP5846836B2
Application number: JP2011223566A
Authority: JP
Inventors: 勇太澤; 直也服部; 雄次對馬
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2011-10-11
Filing date: 2011-10-11
Publication date: 2016-01-20
Anticipated expiration: 2031-10-11
Also published as: US8881150B2; US20130275972A1; JP2013084122A

Description

本発明は、仮想化計算機システムに関し、特に複数の仮想計算機がI/Oデバイスを共有しながら物理計算機上で稼働する仮想計算機システムにおいて、当該物理計算機のダウンを回避する技術に関する。

商用サーバやPersonal Computer (PC, パソコン)等により、物理計算機が普及している。従来の物理計算機においては、ひとつの物理計算機上には高々１つのOSしか動作できないことが問題であった。そこで、特許文献1が開示するように、ひとつの物理計算機上に複数の仮想計算機と、それら複数の仮想計算機を管理するHypervisorを動作させるVirtual Machine Monitor(VMM)技術が開発された。例えば特許文献1に記載の技術を用いれば、複数の仮想計算機で別々のOSを動作させることで単一の計算機上で複数のOSが同時に動作可能となった。

特許文献1では、複数の仮想計算機がそれぞれIO(Input/Output)デバイスを使用する目的で、物理計算機上にある単一のIOデバイスを共有する技術を開示している。共有を行う際には、VMMがIOデバイスを仮想化し、時分割で切り替えながら仮想的なIOデバイスとして各仮想計算機に割り当てて実現する。しかしこのIOデバイス共有時のオーバヘッドが大きかったため、2009年頃から非特許文献1に開示されているSR-IOV (Single Root I/O Virtualization)という標準化された技術を用いたオーバヘッド削減が行われるようになった。このSR-IOVの仕様書である非特許文献1によると、SR-IOVに対応したデバイスは、従来のIOデバイスが搭載する機能であるFunctionを拡張したPhysical Function(PF)とVirtual Function(VF)を有している。PFはIOデバイス全体の初期化やVFの生成等の制御が可能な機能を有する。一方、VFは従来のIOデバイスが提供する入出力機能を提供する。

米国特許第６４９６８４７号公報

Single Root I/O Virtualization and Sharing Specification Revision 1.0

例えば上述のSR-IOVデバイスのような共有機能を持った物理的なIO(Input/Output)デバイス(以下IOVデバイスと呼ぶ)を利用する仮想計算機システムにおいては、一つの物理計算機上で稼働する複数の仮想計算機が一つのIOVデバイスを利用してIO(Input/Output)処理を行う。この際に、例えば、ユーザ用の仮想計算機であるユーザ仮想計算機がIOVデバイスのVFを利用して稼働中である時に、システム管理者が利用する仮想計算機である管理用仮想計算機がメンテナンス等の為に当該IOデバイスのPFをリセット等して停止させると、当該VFを含むIOデバイス全体が停止する。あるいは、明示的にリセット等を行わない場合であっても、IOデバイスの設定変更時にデバイスの仕様によりリセットがかかり、IOデバイス全体が一時的に停止または再起動することがある。これらの場合、当該VFのIO処理は開始から完了までにタイムラグがあるため、当該IOVデバイスが接続されるRoot Bridgeには当該VF由来の仕掛中のIO処理が残ったままとなる。しかし、当該IOVデバイスは停止しているためVF由来の仕掛中のIO処理への応答が行えず、Root BridgeにVF由来の仕掛中のIO処理が滞留し続ける。そのため、最終的にはRoot Bridgeは仕掛中のIO処理のタイムアウトを検出し、システム障害と判断し当該物理計算機をダウンさせる。

このように、一つのIOVデバイスを複数の仮想計算機が共有してIO処理に利用すると、 PFを停止させた場合にVF由来の仕掛中のIO処理が滞留し続けることで物理計算機のダウンが発生し、仮想計算機や仮想計算機システムの信頼性が低下する恐れがあった。

本発明の目的は、上記の課題を解決し、複数の仮想計算機がI/Oデバイスを共有しながら物理計算機上で稼働する場合に、仮想計算機が稼働する物理計算機が、VF由来の仕掛中のIO処理が滞留し続けることによりダウンすることを防止する仮想計算機、仮想計算機システム、及びそれらの制御方法を提供することにある。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、第１の仮想計算機と、第２の仮想計算機と、第１、第２の仮想計算機を管理するハイパバイザと、を格納する記憶部と、第１、第２の仮想計算機が利用する共有IOデバイスと、を有する計算機装置を制御する際に、共有IOデバイスに、物理IOデバイスと、仮想IOデバイスと、を設け、物理IOデバイスが停止した場合に仮想IOデバイスは停止し、ハイパバイザが、第１の仮想計算機が送信した物理IOデバイスを停止させる信号を検出した場合に、仮想IOデバイスに対して第２の仮想計算機が送信した処理要求が完了したことを契機として物理IOデバイスの停止を行う。さらに、ハイパバイザは、第１のドライバが停止信号を物理IOデバイス宛に送信して以降に第２のドライバが仮想IOデバイスに対して送信する処理要求の物理IOデバイスへの到達を抑止する。

本発明により、複数の仮想計算機が共有して使用するIOVデバイスについて、VF由来のIO処理が全て完了した状態でPFを停止させることが出来る為、PFを停止させることに起因した物理計算機のダウンを防止し、仮想計算機や仮想計算機システムの信頼性を向上することが可能となる。

本発明のシステム構成の一例を示すブロック図障害処理部が行う処理の概要の例を示すフローチャート障害処理部が行うVFのIO処理遮断のためのアドレス保護機構設定のフローチャート障害処理部が行うVFのIO処理完了確認のためのダミーアクセスのフローチャートアドレス保護機構の構成例を示すテーブル図 VF割り当て表の構成例を示すテーブル図障害処理部が行うVFのIO処理遮断のための仮想CPUを停止のフローチャート VFのIO処理完了確認のためのVFの割り込みを利用のフローチャート障害処理部が行うVFのIO処理完了確認のためのVFに設定された待機時間分待つフローチャート VFに待機時間を設定するためのユーザインタフェースの構成例を示すブロック図デバイスに障害が発生しない場合のRoot Bridge動作のフローチャートデバイスに障害が発生した場合のRoot Bridgeの動作のフローチャート VFへのIO要求の直後にPFへのリセットが行われた場合のRoot Bridgeの動作のフローチャートアドレス保護機構の動作のフローチャート Root Bridgeが持つ通信規格のフローチャート仮想計算機スケジューラの動作例を示すフローチャート仮想計算機スケジュール表の構成例を示すブロック図未完了操作履歴の構成例を示すブロック図 IO要求を受けた際のRoot Bridgeの動作を示すフローチャート完了順序が保証されるIO要求のVFでの受信、処理完了のフローチャート IOVデバイスの構成例を示すブロック図

以下、本発明の各種の実施例を図面に従い説明する。

本実施例では最初に、本発明を実施する際の装置構成の例を示した後に、全体の概要を示し、その後詳細を解説する。
図1に本実施例における物理計算機の構成を示す。b1の物理計算機内は内部に、代表部品としてb2の物理CPU、b300の物理主記憶、b40のRoot Bridge、b50のIOVデバイス(IO Virtualization デバイス)、b6のアドレス保護機構を持ち、物理計算機の外部にはb7のコンソールが接続されている。本実施例を実施するためにはこれらの構成と同様の機能を達成するモジュールがあれば良く、例えば近年ではb40のRoot Bridgeやb6のアドレス保護機構がCPUと同じチップ内に実装及び販売されることがある。あるいは実装によってはアドレス保護機構の一部または全てをソフトウェアとしてHypervisorに実装してもよい。また、物理計算機内にこれらの機能ブロックを複数搭載してもよい。本実施例中ではPCIの用語を用いて解説を行うが、本発明の全体はPCIやPCI-X、PCI ExpressといったPCI互換のプロトコルに限定されるものではない。各部位について順に解説を行う。
b2の物理CPUは内部にb21のタイマを備え、ある時刻からある時刻までの経過時間を測定すると共に、一定時間が経過したことを知ることができる。
b300の物理主記憶内にはb310のユーザ仮想計算機、b320の管理用仮想計算機、b330のHypervisorが格納されている。これらの中にはCPUが実行可能な命令プログラムが記述されており、これらの命令プログラムを物理CPU(b2)が実行することで動作する。b310のユーザ仮想計算機の中には、b311仮想CPUとb312の仮想主記憶があり、物理計算機と同様に動作可能である。b312の仮想主記憶の中にはb313のVFドライバが格納されている。b313のVFドライバは、通常はb312の仮想主記憶内に格納されているb314のOS(Operating System)と協調動作することが多いが、必ずしもOSに頼る必要はなく、例えばb312内に格納されたBasic Input/Output System (BIOS)やExtensible Firmware Interface (EFI)等をはじめとするファームウェアと強調動作してもよいし、あるいはb313のVFドライバ単体で動作してもよい。

さらには、b312の仮想主記憶内でVirtual Machine Monitor(VMM)が動作している場合には、そのVMMと協調動作してもよい。本実施例では代表的な構成である、b314のOSと協調動作する場合のみを記載するが、例えばBIOSと協調動作する場合にはb314のOSをBIOSと読み替えればよい。同様にb320の管理用仮想計算機には、b321の仮想CPUとb322の仮想主記憶があり、b310のユーザ仮想計算機と同様に動作可能である。b322の仮想主記憶にはb323のPFドライバが格納され、b324のOSと協調動作する。
b310のユーザ仮想計算機やb320の管理用仮想計算機は複数あってもよく、その場合は複数のb310のユーザ仮想計算機内には別々のb311の仮想CPUやb312の仮想主記憶を、複数のb320のユーザ仮想計算機内には別々のb321の仮想CPUやb322の仮想主記憶を持つ。ただし、b313のVFドライバやb323のPFドライバは最低1つずつあれば良い。すなわちb313のVFドライバを全てのb310ユーザ仮想計算機が持っている必要はなく、同様にb323のPFドライバを全てのb320管理用仮想計算機が持っている必要は無い。b310のユーザ仮想計算機が複数ある場合には、各ユーザ仮想計算機には固有のユーザ仮想計算機IDを持つ。

b320の管理用仮想計算機は、必ずしもb330のHypervisorと切り離された機能ブロックである必要はない。その場合、例えばHypervisor内にPFドライバが組み込まれる構成となる。さらに、b324のOSが存在しないこともある。

b330のHypervisorは、b1の物理計算機内でb310のユーザ仮想計算機やb320の管理用仮想計算機の複数の仮想計算機を動作させる機構である。b330のHypervisorはこの実施例では物理主記憶の中に格納されているが、必ずしも物理主記憶上に格納されていなくてもよく、例えば同様の機能を持つハードウェアが物理計算機内にある構成でも構わない。b330のHypervisor内には、b331の障害処理部、b332のVF割り当て表、b333の仮想計算機スケジューラ、b334の仮想計算機スケジュール表が格納されている。b331の障害処理部の挙動については、図2以降を用いて後述する。CPUは、これらプログラムを実行し、その処理結果を主記憶に格納する。

IOVデバイスb50や非IOVデバイスb53等のIO(input/output)デバイスは、IO(input/output)処理を行うためのデバイスであり、その例としては、ネットワーク通信を行うためのネットワークIOデバイスや、ストレージを操作するためのストレージIOデバイス、ディスプレイに出力するためのグラフィックIOデバイス等がある。これらのIOデバイスは、ディスプレイb56、ネットワークb55、外部記憶b54の機器等と接続する。ここで、IOVデバイスb50や非IOVデバイスb53等のIOデバイスが接続する機器は、ディスプレイ、ネットワーク、外部記憶に限らなくても良く、接続しない機器があっても良く、また同一の機器を複数接続していても良い。例えば、複数のIOデバイスがネットワークに接続しており、ディスプレイに接続しているIOデバイスが存在しない構成があっても良い。

SR-IOVデバイスのような共有機能を持った物理的なIOデバイスであるIOVデバイスb50は、少なくとも1つのb51のPhysical Function(PF)と少なくとも1つのb52のVirtual Function(VF)を備えている。PF(b51)及びVF(b52)は、それぞれがIOデバイスとしてIO処理を行える機能ブロックである。PF(b51)は、複数のVF(b52)を管理するための機能を持っており、例えばIOVデバイスb50内のVF数を変化させたり、IOVデバイスb50内のVF設定を変更する機能を持っていることがある。PF(b51)およびVF (b52)は、IOVデバイス内に実装された回路であっても、IOVデバイス内でソフトウェアプログラムによって実現されていてもよい。

各b52のVFは、必ず1つのb51のPFに関連付けられており、b51のPFをリセットすると関連付けられているb52のVFも同時にリセットされる。b51のPFをリセットしても、リセット対象のb51のPFに関連付けられていないb52のVFはリセットされない。また、b50のIOVデバイスの種類によってはb51のPFはb52のVFを制御することも可能である。b53の非IOVデバイスは、IOVに非対応のデバイスもしくはIOVとして使用されていない通常のIOデバイスを示している。b50のIOVデバイスはこの図に示すように複数あってもよいし、あるいはひとつだけであってもよい。また、b53の非IOVデバイスも複数あってもよいし、あるいは存在しなくてもよい。

非IOVデバイスは、各時刻においては単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機によってのみ操作される。例えば非IOVデバイスにネットワークが接続された場合は、ディスプレイ上には単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機のみがネットワークに接続される。IOVデバイスb50の場合は、IOVデバイス内の各PF(b51)や各VF (b52)が単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機によってのみ操作される。この構成の場合は、VF同士は異なるユーザ仮想計算機b310や管理仮想計算機によって操作されていてもよい。そのため、例えばIOVデバイスb50がネットワークに接続されている場合に、複数の管理用仮想計算機やユーザ仮想計算機b310が同時にネットワーク通信できる。

ユーザ仮想計算機b310もしくは管理用仮想計算機b320は、自身が操作している非IOVデバイスb53、PF(b51)、VF (b52)に対し、IO要求を出すことによって入出力を行う。このとき、直接非IOVデバイス、PF(b51)、VF (b52)に対してIO要求を行うのではなく、物理CPU(b2)に命令プログラムを実行させる。命令プログラム中には、非IOVデバイス、PF(b51)、VF (b52)のアドレスが記入されており、物理CPU(b2)は該当アドレスにアクセスしようとする。すると、そのアクセスをアドレス保護機構b6 は解釈し、ユーザ仮想計算機b310もしくは管理用仮想計算機が操作可能な非IOVデバイス、PF(b51)、VF (b52)である際にはRoot Bridge(b40) に対してアクセスを転送する。この手続きについては図14を用いて後述する。アクセスを受け取ったRoot Bridge(b40) は、該当する非IOVデバイス、PF(b51)、VF (b52)に対して操作を行う。この手続きについては図11を用いて後述する。

b40の中にはb41の未完了操作履歴があり、ここにはデバイスに対する仕掛中のIO処理が記録されている。

b7のコンソールはRoot Bridge(b40) に接続され、システム管理者、ユーザ等の人間がHypervisorの起動や、VFに対する設定値を設定するためのインタフェースを提供する。一般的に物理計算機には、このコンソールに代表されるような外部出力を行う機器が搭載されている。

これら図1で示した構成は、代表的な構成であるが、これらの機能を持っている構成であれば名称やブロックが違うものであってもよい。先立って、アドレス保護機構b6 及びRoot Bridge(b40) が持つ通信規格について解説する。この通信規格は、例えばPCIやUSBといった規格が存在する。この通信規格は、必ずしも標準化された規格に限られたものである必要はない。この通信規格を介して、物理CPUやユーザ仮想計算機、管理用仮想計算機、あるいはユーザ仮想計算機内のVFドライバや管理用仮想計算機内のPFドライバはIO要求を行うことができる。

図15を用いて通信規格でのIO要求の処理概要を示す。まず、物理CPU(b2)やユーザ仮想計算機b310、管理用仮想計算機等の仮想計算機、あるいはユーザ仮想計算機内のVFドライバb313や管理用仮想計算機内のPFドライバb323等のドライバ、が通信規格にのっとった電気信号をRoot Bridge(b40) 宛に送信することによりIO要求を発行する(a900)。このIO要求をまずアドレス保護機構b6 が処理する(a905)。アドレス保護機構b6 はそのIO要求が処理してもよいものであると判断すれば、手続きa910に、処理してはよくないものであると判断すれば手続きa920に進む。この手続きの詳細については図14を用いて後述する。

手続きa910では、アドレス保護機構b6 からRoot Bridge(b40) に対してIO要求を中継し、その後に続く手続きa915ではRoot Bridge(b40) がIOVデバイスb50や非IOVデバイスb53等のデバイスに対してさらにIO要求を中継する。手続きa920ではアドレス保護機構b6 はRoot Bridge(b40) に対してIO要求を中継しない。

次に、図5を用いてアドレス保護機構b6 が有するアドレス保護表b61 の例について説明する。アドレス保護表b61の要素として例えば、ユーザ仮想計算機b310を識別するための識別子であるc101のユーザ仮想計算機ID、ユーザ仮想計算機b310から見たPF(b51)またはVF (b52)の物理アドレスを意味するc102のゲスト物理アドレス範囲、ユーザ仮想計算機b310から見たPF(b51)またはVF (b52)の物理アドレスと、物理計算機から見たPF(b51)またはVF (b52)の物理アドレスの差分を意味するc103のOffset、ユーザ仮想計算機b310が該当するゲスト物理アドレス範囲にアクセス可能かどうかを判定するc104のアクセス可否フラグがある。アドレス保護表b61 は、Hypervisor(b330)が設定することができ、Hypervisor(b330)によって仮想計算機からのIO要求を制御するものである。

アドレス保護機構b6 がどのように動作するかについて図14を用いて解説する。ユーザ仮想計算機b310が、Root Bridge(b40) に対してIO要求を行うことを契機として、アドレス保護機構b6 の動作が開始される(手続きa800)。アドレス保護機構b6 は、ユーザ仮想計算機b310が行ったIO要求に対して、アドレス保護表b61を参照し、(1) IO要求元の仮想計算機ID、(2) IO要求のアドレスを調べ、(1)のIO要求元の仮想計算機IDがc101のユーザ仮想計算機IDと等しく、かつ(2)のIO要求のアドレスがc102のゲスト物理アドレス範囲に含まれる行があるかどうかを調べる(a805)。a805にて、発見された行があり、かつその行のアクセス可否フラグが許可になっている場合には、a810の手続きを、そうでない場合にはa820の手続きを行う。

例えば、図5中の例でa810に進む例としては、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x020000の場合(Line 1に含まれる)、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x407000の場合(Line 2に含まれる)、ユーザ仮想計算機IDが2かつIO要求が0x010000の場合(Line 4に含まれる)、などがある。一方、a820の手続きに進む例としては、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x800000の場合(該当する行がない)、ユーザ仮想計算機IDが3の場合(該当する行がない)、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x600000の場合(Line 3に含まれるがアクセス可否フラグが拒否)などがある。

a810の手続きについて、説明する。アドレス保護機構b6 はIO要求のアドレスに対して、c103のOffsetを足したアドレスが指し示すアドレスにアクセスする。その結果、当該アドレスをアドレス範囲に持つIOデバイスにアクセスする。例えばユーザ仮想計算機IDが1かつIO要求のアドレスが0x020000の場合(Line 1に含まれる)は、Line 1のOffsetが0x100000であるため、0x120000に対してアクセスする。別の例としてユーザ仮想計算機IDが1かつIO要求のアドレスが0x407000の場合(Line 2に含まれる)、Line 2のOffsetが-0x100000であるため、0x307000にアクセスをする。さらに別の例として、ユーザ仮想計算機IDが2かつIO要求が0x010000の場合(Line 4に含まれる)、Line 4のOffsetは0x200000であるため、0x210000にアクセスする。
a820の操作について説明する。手続きa805において、発見された行がなかった場合もしくは発見された行のアクセス可否フラグが拒否であった場合に、アドレス保護機構b6 はHypervisor(b330)に対して例外の割り込みをあげる。このことにより、不正なIO要求を仮想計算機が行ったことをHypervisor(b330)が知ることができる。しかし、実装形態によっては割り込みをあげずにHypervisor(b330)が定期的にアドレス保護機構b6 に問い合わせる、あるいは不正なIO要求をHypervisor(b330)が知らなくてもよい場合には何もしないことも許される。

次に、図6に示すVF割り当て表b332について説明する。VF割り当て表には、例えば、PF(b51)を識別するための識別子であるc201のPF識別番号、VF (b52)を識別するための識別子であるc202のVF識別番号、ユーザ仮想計算機b310を識別するための識別子であるc203のユーザ仮想計算機ID、PF識別番号とVF識別番号で識別されたVF(b52)が、ユーザ仮想計算機b310によって操作される際のアドレスを意味するc204のゲスト物理アドレス範囲、PF識別番号とVF識別番号で識別されたVF(b52) がIO要求を処理するのに必要な最大時間を意味するc205の待機時間を持つ。PF識別番号とVF識別番号の組み合わせは必ず一意である。すなわち、例えばPF識別番号が1でVF識別番号が1である行が複数存在しないように構成されている。

このVF割り当て表b332はHypervisor( b330 )が設定できるものである。Hypervisor( b330 )はこのVF割り当て表b332を用い、PF(b51)やVF(b52)の関係を管理する。例えば、PF(b51)のPF識別番号が1でVF識別番号が2であるVF(b52)は、この表によるとユーザ仮想計算機IDが1のユーザ仮想計算機b310に割り当てられており、ユーザ仮想計算機IDが1のユーザ仮想計算機b310がこのVF(b52)にIO要求を出す際には0x010000から0x03ffffまでのアドレスを用いてIO要求を行う。

本実施例は、障害処理部b331がVFドライバb313のアクセスを停止し、その後VFドライバb313の全てのIO処理が完了したことを確認する。この処理を説明するため、まずPCIのRoot Bridge(b40) の挙動について説明する。

Root Bridge(b40) の動作は大きく3つある。このそれぞれの詳細を次に述べる。
(1)ユーザ仮想計算機b310、管理用仮想計算機、Hypervisor( b330 )からのデバイスIO処理要求があった場合、Root Bridge(b40) は内部の未完了操作履歴b41に履歴を格納した後、IOVデバイスb50や非IOVデバイスb53等のIOデバイスに操作IDと共にIO処理の処理要求を送信する。

未完了操作履歴b41の持つデータ構成の例について、図18を用いて説明する。未完了操作履歴b41は、例えば操作を一意に特定するための操作ID(c401)とその操作を行った主体を特定するための操作主体(c402)、操作を行った時刻である操作時刻(c403)を持つ2次元の表である。操作を行った主体としては、例えばユーザ仮想計算機b310や管理用仮想計算機、あるいはHypervisor(b330)がありうる。

Root Bridge(b40) が未完了操作履歴b41に履歴を格納する手続きを、図19を用いて示す。図19の手続きは、Hypervisor(b330)または仮想計算機が出したIO要求がRoot Bridge(b40) に到着することで開始される(a2100)。その後手続きa2105として、Root Bridge(b40) は一意なIDとして、未完了操作履歴b41中で使用されていない操作IDを一つ決定する。その後、Root Bridge(b40) は手続きa2105で決定された操作IDと、手続きa2100で到着したIO要求の操作主体、そしてその際の時刻をそれぞれ未完了操作履歴b41内の操作ID、操作主体、捜査時刻に格納する(手続きa2110)。

ここで使用された操作IDは、IOデバイスに対しても送信され、次の手続きではIOデバイスはこの操作IDと共に応答を返す。

(2)先のデバイスIO処理要求に対して、操作IDと共に応答がデバイスから返ると、その応答をユーザ仮想計算機b310、管理用仮想計算機b320、Hypervisorb330へ中継する。またこの際、その応答に対応するIO処理を未完了操作履歴b41から探し、削除する。
より詳細に述べると、Root Bridge(b40) は未完了操作履歴b41から操作IDが該当する行を読み出し、該当行に記録されている操作主体に対して応答を中継する。さらに、中継すると共に、該当行を削除する。
このRoot Bridge(b40) の(1)(2)の動作は、例えば図11のように説明される。まず、デバイスドライバがデバイスに対してIO要求を発行する場合、このIO要求はRoot Bridge(b40) が受け取る(手続きa1000)。Root Bridge(b40) は、このIO要求が未完了操作履歴b41に記録される類の操作であるかどうかを判定する(手続きa1002)。未完了操作履歴b41に記録する操作であった場合には、Root Bridge(b40) はこのIO要求を未完了操作履歴b41に記録する(手続きa1005)。その後Root Bridge(b40) はIO要求をデバイスに対して中継する(手続きa1010)。手続きa1010で中継されたIO要求を、デバイスは処理し(手続きa1015)、処理の完了をもって完了をRoot Bridge(b40) に通知する(手続きa1020)。通知を受けたRoot Bridge(b40) はa1005で記録された未完了操作履歴b41内にある、a1005のIO要求を削除する(a1025)。

(3)一方、操作時刻から一定時間たっても未完了操作履歴b41から削除されないIO処理があった場合、デバイスにエラーが発生したと判定し、安全のため物理計算機をダウンさせる。これには、デバイスにエラーが発生すると、主記憶をはじめとするシステム全体をデバイスが破壊し続ける可能性があるためで、その破壊を食い止めるために物理計算機をダウンさせる。

この動作によって、デバイスの障害を発見し、物理計算機を停止する契機とすることができる。ここで、物理計算機を停止される契機としての当該障害発見についての正当性を、図12を用いて説明する。

図12は、デバイスによるIO要求の処理(手続きa1015)中に、デバイスに障害が発生した場合のRoot Bridge(b40) の動作を示すフロー図である。手続きa1000、a1005、a1010、a1015については図11と差異がないため、説明を省略する。

手続きa1100で障害が発生した場合、図11においては行われたRoot Bridge(b40) に対する完了報告(図11中の手続きa1020)が行われないまま、一定時間が経過(手続きa1105)する。これにより、手続きa1110において、未完了操作履歴b41に対する完了が書かれていないため、完了報告が無いと判定して物理計算機を停止する。

図12はデバイスによるIO要求の処理(手続きa1015)中に、デバイスに障害が発生した場合を想定したが、IO要求の発行前に障害があった場合においても、図11においては行われたRoot Bridge(b40) に対する完了報告(図11中の手続きa1020)が行われないまま、一定時間が経過(手続きa1105)するため、同様の動作となる。これにより、IOデバイスの障害をRoot Bridge(b40) が検知することができ、IOデバイスによる物理計算機への破壊(主記憶の内容書き換え、他のデバイスへの障害波及、不正プログラムの実行)を食い止めることが可能である。

次に、図１３を用いて、IOVデバイスb50においてVFドライバb313によるIO処理の直後にPFドライバb323によるPFリセットを同時に行った場合のRoot Bridge(b40) の挙動を説明する。ここでは、VFドライバb313がVF(b52)に対してIO処理を行い、デバイスから応答が返る前にPFドライバb323がPF(b51)をリセットした場合のRoot Bridge(b40) の挙動を記述する。VFドライバb313がVF(b52)に対するIO処理を行うと、(1)のデバイスIO処理要求が発生し、Root Bridge(b40) 内の未完了IO処理履歴に履歴が残る。ここで、デバイスからの応答前にPF(b51)をリセットすると、同時にVF(b52)もリセットされるため、(2)のデバイスからの応答が返ってくることはなくなる。したがって、一定時間後にRoot Bridge(b40) は(3)のエラー判定を行い、物理計算機をダウンさせる。

図13中の手続きa1200、a1205、a1210、a1215は、図11及び図12中のa1000、a1005、a1010、a1015とほぼ同等であるが、IOVデバイスb50内のVF(b52)に対してIO要求を行っている点のみが異なるため、改めて解説する。
手続きa1200では、VFドライバb313がIOVデバイスb50内のVF(b52)に対してIO要求を行う際に、Root Bridge(b40) に対してIO要求を出す。このIO要求をRoot Bridge(b40) が受け取り、未完了操作履歴b41に記録する(手続きa1205)。その後手続きa1210では、Root Bridge(b40) はIOVデバイスb50内のVF(b52)に対して中継する。

IOVデバイスb50内のVF(b52)は、a1210で中継されたIO要求を実行する(a1215)が、その最中にPFドライバb323がIOVデバイスb50に対してリセットを発行する(a1220)と、PF(b51)とVF(b52)がともにリセットされる。このとき、VF(b52)が処理中であったa1200のIO要求についてもリセットに伴い廃棄される。すると、図12中でデバイスに障害が発生した場合(図12中の手続きa1105)と同様に、一定時間が経過し(a1225)、a1200のIO要求に対する完了報告をVFから受信していないことを理由にRoot Bridge(b40) は物理計算機を停止させる(a1230)。

図13では物理計算機がダウンしたが、実際にはデバイス不良でないため、物理計算機への破壊(主記憶の内容書き換え、他のデバイスへの障害波及、不正プログラムの実行)が行われることはなく、本来は物理計算機をダウンさせる必要はない。

そこで本実施例においては、このダウンを防ぐために、障害処理部b331が後続のVFドライバb313のアクセスを停止し、その後VFドライバb313の全てのIO処理が完了したことを確認、そして最後にIOVデバイスb50をリセットする。この手続きについて、図2を用いて説明する。

図2はb311の障害処理部b331が行う手続きについて記載したフローチャートの例である。物理計算機のダウンを防ぐためには、PFドライバb323が発行するリセット時に、全てのVFドライバb313によるIO要求への応答が完了していれば良い。そのため、PFドライバb323が発行したリセットを障害処理部b331が検知したことを契機として動作する(手続きa100)。この手続きにはいくつかの方法があるが、代表的なものとしてはアドレス保護表b61 中の、リセットを行うアドレスへのアクセス可否を拒否に設定しておき、該当アドレスにアクセスがあった場合にはHypervisorが処理を行うなどの方法がある。リセットを行うアドレスについては、多くの場合は通信規格によって定められているため、Hypervisor( b330 )はPFドライバやVFドライバのようなデバイス固有の仕様を持ったソフトウェアを用いなくともリセットが検知できる。ただし、デバイス固有のリセット仕様をHypervisor( b330 )が知っている場合には、そのデバイス固有のリセットを検知してもよい。本検知後に、障害処理部b331はVF割り当て表b332を用いてリセット対象のPF(b51)と同一IOVデバイス内のVF(b52)を列挙する(手続きa102)。すなわち、図6のVF割り当て表b332中で、PF識別番号がリセット対象のPF(b51)の識別番号と同一の行を全て選択し、それらの行の中のVF識別番号を全て記録する。この手続きによって列挙されるVF(b52)は、例えば、図6のようなVF割り当て表b332であり、かつ手続きa100でリセットを行う対象であったPF(b51)のPF識別番号が1であれば、VF識別番号が1及び2のVF(b52)である。また、手続きa100でリセットを行う対象であったPFのPF識別番号が2であれば、VF識別番号が3及び4のVFである。

手続きa102が完了すると、VFドライバb313による後続のIO要求を停止する(手続きa105)。次に手続きa105でIO要求を停止する以前に行われた、全てのIO要求への応答が完了したことを確認(手続きa110)する。さらにHypervisor( b330 )が改めてPF(b51)をリセットする(手続きa115)。リセット手続きについては、多くの場合は通信規格によって定められているため、PFドライバb323やVFドライバb313を介さずに行うことが可能である。ただし、デバイス固有のリセット仕様をHypervisor( b330 )が知っている場合には、そのデバイス固有のリセットを発行してもよい。さらには、Hypervisor(b330)は管理用仮想計算機に対して、改めてリセット発行を頼む等してもよい。この際にはHypervisor(b330)はアドレス保護表b61 を書き換える等の方法で、リセットを許可する。

手続きa105、手続きa110、手続きa115をこの順で実行することが重要であり、例えば仮に手続き110がなかった場合、VFドライバb313によるIO要求が仕掛中であり、その間にa115のリセットを発行すると物理計算機のダウンにつながる。そのため、本手続きをこの順で実行することが本発明の効果を得ることが可能となる。

さらに、本実施例では図3を用いて図2中の手続きa105の詳細を示す。図3は手続きa105に示したVFドライバb313による後続のIO要求を停止する手続きとして、b6のアドレス保護機構b6 を用いる例である。図3は図1と比較すると手続きa105が手続きa200に変更されただけであるため、手続きa200のみについて説明する。

手続きa102でリストアップされたVF(b52)のそれぞれについて、図６のVF割り当て表を用いて説明したc204のゲスト物理アドレス範囲を元に、アドレス保護機構b6 内のc102ゲスト物理アドレス範囲を抽出する。この際、図6のVF割り当て表を参照する。例えば、VF識別番号が1のVF(b52)が抽出された場合、そのゲスト物理アドレスは0x010000-0x03ffffである。このゲスト物理アドレスに該当するゲスト物理アドレスと、VF識別番号1のVF(b52)が割り当てられているユーザ仮想計算機IDが1のユーザ仮想計算機b310から、アドレス保護機構b6 内の表のLine 1が該当すると判定する。この場合、図５においてアドレス保護機構b6 のLine 1のアクセス可否フラグc104を拒否に設定することで、VFドライバb313による後続のIO要求を停止する。このように後続のIO要求を遮断し、新たにVF(B52)がIO要求を受け付けることを防止することによって、a110の確認に要する時間を最小限に抑えることが可能になるとともに、図４や図２０を用いて後述する完了順序が保証されるIO要求を用いた完了確認を適正に開始することが可能となる。

アクセス可否フラグによる拒否の方法としては、大きく2種類の方法が存在する。アドレス保護機構b6 が該当アドレスへのアクセスを拒否できる場合、その機能を有効にする。この場合は単純にアクセス可否フラグを拒否に設定するだけでよい。そうでない場合には、アドレス変換後のアドレスが、無効なアドレスになるように設定する。例えば、物理計算機が使用しているアドレスが0x0-0xafffffffであれば、0xb0000000-0xffffffffのアドレスは無効であり、このアドレスに変換すれば実質的に無効化される。このようにアドレス保護機構b6 や、アドレス保護機構b6 が管理するアドレスを制御・変更することで、IO要求の完了/未完了を管理するRoot Bridge(b40) にIO要求が到達することを防ぐことができる。

手続きa200の後、b311の仮想CPUに対して仮想的に割り込みをあげ、VFが使用不可能となったことをユーザ仮想計算機b310に知らせてもよい。例えば、Root Bridge(b40) に対してb314のOSが割り込み番号を設定していた場合には、その割り込み番号を用いてb311の仮想CPUに対して仮想的な割り込みをあげることで、b314のOSに通知を行う。その他、システム由来の割り込み番号を用いて通知を行ってもよいし、OSが自動認識するのであれば特に通知を行わなくてもよい。これらの手続きにより、VFドライバb313による後続のIO要求が停止する。

図4を用いて、手続きa110のVFドライバb313のIO処理完了を確認する具体的手続きについて説明する。図4は図2中のa110の手続きを手続きa300、a305で置き換えたものであり、その他の部分は図2と同じであるため、手続きa300とa305のみについて説明する。

それに先立ち、完了順序が保証されるIO要求について説明する。完了順序が保証されるIO要求とは例えば、PCI互換のプロトコル(PCI/PCI-X/PCI Express)のPCI Configuration spaceに対するread/writeリクエスト、Memory Mapped I/Oに対するreadリクエスト等は、Non-Postedリクエストと呼ばれ、実行を行った順で完了されるという特徴がある。これらのNon-PostedアクセスをIO要求として用い、IO要求の完了を待つと、そのIO要求以前に行われた全てのNon-Postedリクエストは、完了したことが保証されている。図20を用いてその具体例を説明する。

図20は、上述のような完了順序が保証されるIO要求のVF(b52)での受信、処理完了のフローの一例を示している。この例では、IO要求P1, IO要求P2, IO要求P3, IO要求P4, IO要求P5がこの順でVFドライバb313やHypervisor(b330)等から発行されていることを前提とする。まず、手続きa2200において、VF(b52)はIO要求P1を受信する。次に、手続きa2201において、VF(b52)はIO要求P2を受信する。次に、手続きa2202において、VF(b52)は手続きa2200で受信したIO要求P1の処理を行ってIO要求P1を処理完了する。次に、手続きa2203において、VF(b52)はIO要求P3を受信する。次に、手続きa2204において、VF(b52)はIO要求P4を受信する。次に、手続きa2205において、VF(b52)は手続きa2201で受信したIO要求P2の処理を行ってIO要求P2を処理完了する。次に、手続きa2206において、VF(b52)は手続きa2203で受信したIO要求P3の処理を行ってIO要求P3を処理完了する。次に、手続きa2207において、VF(b52)はIO要求P5を受信する。次に、手続きa2208において、VF(b52)は手続きa2204で受信したIO要求P4の処理を行ってIO要求P4を処理完了する。次に、手続きa2209において、VF(b52)は手続きa2207で受信したIO要求P5の処理を行ってIO要求P5を処理完了する。

このように、VF(b52)では一つのIO要求の完了を待たずに、次のIO要求を受信することは可能であるが、完了順序はIO要求の受信順序と同様にP1, P2, P3, P4, P5である。

このように完了順序が保証されるIO要求を用いると、例えばP5のIO要求の完了を観測すれば、P5に先立って行われたIO要求であるP1, P2, P3, P4のIO要求についても完了が保証されることになる。

図４に戻って、この完了順序が保証されるIO要求を用いた手続きである、手続き300, 305について解説する。すでに図２で示したa105の手続きが完了した上で、障害処理部b331はそれぞれのVFに対して上述のような完了順序が保証されるIO要求を行う(手続きa300)。そして、a300のIO要求の完了を確認する(手続きa305)ことで、a300のIO要求の発行以前にa102で列挙されたVFが受信していたNon-PostedのIO要求が全て完了したことを確認する。例えば、a300のIO要求としてPCIの中のNon-Postedの要求の一つであるPCI Configuration readを用いた場合であれば、Hypervisor(b330)が値を読み終えたことを持って、a300以前に発行されたNon-PostedなIO要求の完了を判断できる。また、例えばPCIであれば、Non-Postedリクエストでないリクエスト(Postedリクエスト)は、未完了操作履歴b41に格納されない特性があるため、例え完了していないとしても物理計算機のダウンにはつながらない。

例えば、Hypervisor(b330)の障害処理部b331が図３の手続きa200でアクセス可否フラグを拒否に設定するまでに発行されたIO要求P1, IO要求P2, IO要求P3, IO要求P4をa102で列挙したVF(b52)が受信していた場合、手続きa300において障害処理部b331が、IO要求P5を当該VFに対して発行し、手続きa305において障害処理部b331がa2209のIO要求P5の処理完了を確認することで、当該VFがa200でアクセス可否フラグを拒否に設定するまでに発行されたIO要求P1, IO要求P2, IO要求P3, IO要求P4の処理を完了していることを確認することができる。

以上、実施例１について説明した物理計算機、仮想計算機、仮想計算機システムの構成・動作によって、複数の仮想計算機がI/Oデバイスを共有しながら物理計算機上で稼働する場合に、仮想計算機が稼働する物理計算機がVF由来の仕掛中のIO処理が滞留し続けることによりダウンすることを防止することが可能である。また、手続きa102においてリセットの発行されたPFに対応するVFのみを列挙し、手続きa300及びa305においては列挙されたVFのみに対してIO要求を発行し、完了を確認することにより、リセットの影響するVFのみを選択的に停止することが出来、停止する必要のないIOVデバイスや、IOVに非対応のデバイスについては停止させないことが可能となる。さらに、本実施例の場合、例えばSR-IOV規格に準拠したIOVデバイスとそのドライバがあれば装置を実現できる。

実施例２では、実施例１と異なり、図2 の手続きa102及びa105の異なる実現方式について、図7を用いて説明する。それに先立ち、図16及び図17を用いて、仮想計算機のスケジューリングについて解説を行う。

まず図17を用いてHypervisor(b330)が持つ仮想計算機スケジュール表b334の例について解説する。仮想計算機スケジュール表b334は、各ユーザ仮想計算機b310が物理計算機上でどの程度動作するか、を保持している表である。

仮想計算機スケジュール表b334は例えば、c301のユーザ仮想計算機ID、c302の連続走行時間、c303の実行可否フラグ、c304の実行状態を持つ。各仮想計算機は、実行可否フラグが「可」の場合のみ、連続走行時間分だけ実行状態となる。例えば図17に示した仮想計算機スケジュール表b334の場合は、ユーザ仮想計算機1が10msec、ユーザ仮想計算機2が10msec、ユーザ仮想計算機3が5msec、ユーザ仮想計算機1が10msec、ユーザ仮想計算機2が10msec、ユーザ仮想計算機3が5msecというように、ユーザ仮想計算機1,2,3の3つが順に動作する。ユーザ仮想計算機4は、実行可否フラグが「不可」のため動作しない。次にこれを実現するためのプログラムである、仮想計算機スケジューラb333の動作について図16を用いて解説する。

図16を用いてHypervisor(b330)内の仮想計算機スケジューラb333が行う動作について説明する。まずHypervisor(b330)は、手続きa2000として仮想計算機スケジュール表b334の中の全ての実行状態を「中断」とする。次にa2005として、仮想計算機スケジュール表b334の中で実行可否フラグが可である行を一行選択し、実行状態を「実行中」とする。この際に選択する行は実行可否フラグが可であればどれでもよく、例えば一番上にある行や一番下にある行、あるいはランダムで選択した行等を用いる。その後手続きa2010として、実行状態が「実行中」となっている行の連続走行時間だけCPU(b2)内のタイマb21を設定する。手続きa2005の直後に手続きa2010が行われている際には、手続きa2005で選択された行の連続走行時間が用いられるが、後述するa2040が実行された直後に手続きa2010が実行されている際には手続きa2040で選択された行の連続走行時間が用いられる。

次に手続きa2015として、実行状態が「実行中」となっている行の仮想計算機を動作させる。その後手続きa2020では、手続きa2010で設定したタイマb21が完了したことを契機として、手続きa2025に進む。なお、タイマb21が完了したことを監視するには、例えば定期的にCPU(b2)内のタイマb21を監視しておく方法、タイマb21の機能としてタイマb21が完了した際に割り込みを挙げる仕組みを持っている場合には、その割り込みを設定する方法等がある。

手続きa2025では、実行状態が「実行中」となっている行の実行状態を「中断」とする。その後手続きa2030で、次の行へ移動する。手続きa2035では、手続きa2030で見ることになった行の実行可否フラグが「可」であるかどうかを判定する。仮に、「不可」であった場合には再度手続きa2035に戻り、次々と先の行へ移動する。これを、実行可否フラグが「可」の行を発見するまで続ける。

手続きa2035で実行可否フラグが「可」となっている行を見つけた場合、手続きa1040として該当行の実行状態を「実行中」とし、手続きa2010に移動する。

このように、実行可否フラグが「可」となっているユーザ仮装計算機のみを順に稼動させることにより、実行可否フラグが「不可」となっている行に記載されているユーザ仮想計算機b310には処理が移さないことが可能になる。

図7は、図1と比較するとa102、a105の手続きの代わりにa500、a510の手続きを用いている点と、a115の手続き後にa525の手続きが行われる点が異なるだけであるため、この3つの手続きのみについて説明する。

手続きa500について説明を行う。本実施例においては、障害処理部b331は、図２の手続き100でPF(b51)のリセットを検知すると、VF割り当て表b332からリセット対象のPFと同一IOVデバイスb50内のVF(b52)を使用している仮想計算機を列挙する。例えば障害処理部b331は、図6のVF割り当て表を参照し、リセット対象のPF(b51)のPF識別番号が1であった場合は、Line 1とLine 2が該当する。この場合、ユーザ仮想計算機IDは1のみであるため、列挙される仮想計算機は仮想計算機IDが1の仮想計算機だけである。一方、リセット対象のPF(b51)のPF識別番号が2であった場合は、Line 3とLine 4が該当する。この場合、ユーザ仮想計算機IDは1と2の二つがあるため、列挙される仮想計算機は仮想計算機IDが1の仮想計算機と仮想計算機IDが2の仮想計算機である。

次に手続きa510においては、列挙された仮想計算機が使用している仮想CPUの動作を止める。Hypervisor(b330)の具体的な動作としては例えば仮想計算機を動作させるためのスケジューラのスケジューリングから、列挙された仮想計算機をはずす、などの方法がある。例えば前述した図17の仮想計算機スケジュール表b334を用いている場合であれば、列挙された仮想計算機の実行可否フラグを全て「不可」とすればよい。既に述べたように、実行可否フラグが不可であれば、スケジューリングからはずれ、実行中とならなくなる。

最後に手続きa525について説明する。手続きa510で停止させたユーザ仮想計算機の仮想CPUを、再開させる。この手続きとしては、a510で行った処理の逆を行えばよく、例えば仮想計算機を動作させるためのスケジューラのスケジューリングから仮想計算機をはずした場合、その仮想計算機を再度スケジューリングに追加する。この手続きは、例えば列挙された仮想計算機の実行可否フラグを「可」とすればよい。

実施例２について説明した物理計算機、仮想計算機、仮想計算機システムの構成・動作によって、Hypervisor(b330)がユーザ仮想計算機b310のスケジューリングを行っている仮想計算機システムであれば適用でき、例えばアドレス保護機構b6 を持っていないシステムにおいても物理計算機のダウンを避けることが可能となる。

第3の実施例では、第1の実施例と異なり、図2の手続きa110の異なる実現方式について図8を用いて説明する。本実施例はIOVデバイスの中でも特殊な構成を持つデバイスを前提とした手法である。図8は、a110の代わりに手続きa600、a605、a610、a615、a620、a625、a630が増えている点が図1と異なるため、手続きとしてはこの新たに加わったこれらの手続きについてのみ説明を行う。

まず、特殊なIOVデバイスの構成について、図21を用いて解説する。IOVデバイスb50内のVF(b52)には、IO要求完了割り込み番号記録領域b54を持つ。VF(b52)のIO要求完了割り込み番号記録領域b54に割り込み番号を設定すると、その割り込み番号を用いて適切なタイミングで仮想計算機やHypervisor(b330)に割り込みがあげる。このIO要求完了割り込み番号記録領域に割り込み番号を設定した場合の適切なタイミングとは、各VFに対するIO要求が完了した際である。

次に、図8を用いて障害処理部b331による手続きについて解説する。手続きa600では、手続きa105で列挙した全てのVFに対し、まずIO要求が完了した際にHypervisor(b330)に対してあげる割り込みを設定する。すなわち、IO要求完了割り込み記録領域に、割り込み番号を設定する。こうすることで、列挙したそれぞれのVFへのIO要求が完了した時点でHypervisor(b330)に割り込みがあがる。次に手続きa605でカウンタをVF数に設定する。これは、全てのVFについて割り込みがあがったことを確認するために用意する。

手続きa610では、手続きa600で設定した割り込みが届くのを待ち、a620で割り込みを受信する。割り込みを受信すると、a625で先に設定したカウンタの値を一つ減らす。手続きa630では、a620で受け取った割り込みでa600で設定した割り込みが全て届いたかどうかを確認するため、カウンタの値が0かどうかをチェックする。カウンタの値が0であれば、全ての割り込みが届いていると判断して手続きa115へ、そうでなければ手続きa610へ戻る。例えば、a600で10個のVFに対して割り込みを設定した場合には、a630では9回NOに進んだ後、10回目でYESに進む。

実施例３について説明した物理計算機、仮想計算機、仮想計算機システムの構成・動作によって、PCIのような特定の通信規格を用いなくとも、デバイスが特殊な割り込みに対応するだけで実現できる点が有益である。
以上で実施例３の説明を終える。

第4の実施例では、第1または第3の実施例と異なり、図2の手続きa110の異なる実現方式について図9を用いて説明する。そのため、a110に代わる手続きである、a715のみについて詳細に説明を行う。

a715では、a102でリストアップされたVF(b52)において、VF割り当て表b332を参照し、VF割り当て表b332からリセット対象であったPF(b51)に対応する待機時間c205を取得し、その最大値分だけ待つ。例えば、図6に示したVF割り当て表b332の場合について説明する。a100でリセット対象であったPFのPF識別番号が1の場合には、Line 1とLine 2が該当し、その二つの行の待機時間の最大値分待つ。すなわちこの場合は10msecである。A100でリセット対象であったPFのPF識別番号が2の場合には、Line 3とLine 4が該当するが、この場合には100msec待つ。この待つ時間については、最低でもその時間だけ待てばよく、それ以上の時間待ってもよい。

VF割り当て表内の待機時間を設定するためのユーザインタフェースの例として、例えば図10に示すコンソール画面を用いる方法がある。このコンソールには、VF割り当て表内のPF識別番号とVF識別番号が出力され、VF割り当て表の待機時間のみを更新することができる。ここでは、PF識別番号とVF識別番号を用いたが、VFごとに値を設定できるのであれば別の値を用いてもよい。また、PF単位で待機次官を設定するインタフェースにしてもよい。

ユーザは、デバイスの仕様や経験等から適切な値を入力することが可能である。どの程度待てばよいかどうかはデバイスや物理計算機などの構成に大きく依存するが、例えば1秒程度待てば十分に全てのIO処理が完了したとみなせる、などとユーザは判断する。

実施例４について説明した物理計算機、仮想計算機、仮想計算機システムの構成・動作によって、PCIのような特定の通信規格を用いなくともよいし、実施例3のようにデバイスが対応する必要すらなく、ユーザが値を指定するだけで障害処理部を動作させることが可能となる。

b1 物理計算機
b2 物理CPU
b300 物理主記憶
b310 ユーザ仮想計算機
b311 仮想CPU
b312 仮想主記憶
b313 VFドライバ
b314 OS
b320 管理用仮想計算機
b321 仮想CPU
b322 仮想主記憶
b323 PFドライバ
b324 OS
b330 Hypervisor
b331 障害処理部
b332 VF割り当て表
b333 仮想計算機スケジューラ
b334 仮想計算機スケジュール表
b40 Root Bridge
b41 未完了操作履歴
b50 IOVデバイス
b51 PF
b52 VF
b6 アドレス保護機構
b7 コンソール

Claims

第１の仮想計算機と、第２の仮想計算機と、前記第１、第２の仮想計算機を管理するハイパバイザと、を格納する記憶部と、前記第１、第２の仮想計算機が利用する共有IOデバイスと、を有する計算機装置であって、
前記共有IOデバイスは、
物理IOデバイスと、前記物理IOデバイスが制御する仮想IOデバイスと、を備え、
前記第１の仮想計算機は、
物理IOデバイスを制御する第１のドライバを備え、
前記第２の仮想計算機は、
仮想IOデバイスを制御する第２のドライバを備え、
前記ハイパバイザは、
前記物理IOデバイスを停止させる停止信号の前記第１のドライバによる送信を検出した場合に、
前記停止信号の前記共有IOデバイスへの伝達を抑止し、
前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了しているか否かを判定し、
前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了したことを契機として前記物理IOデバイスの停止を行い、
前記第１のドライバが前記停止信号を前記物理IOデバイス宛に送信して以降に前記第２のドライバが前記仮想IOデバイスに対して送信する処理要求の前記物理IOデバイスへの到達を抑止する、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
前記第１の仮想計算機から前記物理IOデバイスへの第１の接続と、前記第２の仮想計算機から前記仮想IOデバイスへの第２の接続と、を管理するルートブリッジを更に有し、
前記ルートブリッジは、
前記前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が所定の期間内に完了しない場合に前記計算機装置の停止処理を行う、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
前記仮想IOデバイスは、
受信した処理要求を受信順序に従って実行し、
前記ハイパバイザは、
前記仮想IOデバイスに対して処理要求を送信し、前記ハイパバイザが前記仮想IOデバイスに対して送信した処理要求の完了を検知した場合に、前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了していると前記判定する、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
前記ハイパバイザは、
前記第２の仮想計算機から前記仮想IOデバイスへの接続を制御する際に用いる仮想IOデバイスのアドレスを管理し、
前記管理するアドレスを変更することで、前記停止信号の前記共有IOデバイスへの伝達を抑止する、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
複数の前記共有IOデバイスを備え、
前記ハイパバイザは、
前記物理IOデバイスと、前記物理IOデバイスが制御する前記仮想IOデバイスと、を対応付けて管理し、
前記停止信号の送信を検出した場合に、
前記対応付けに基づいて、前記停止信号の宛先である前記物理IOデバイスに前記対応付けられた前記仮想IOデバイスを抽出し、
前記抽出した前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了しているか否かの前記判定を行い、
前記抽出した前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了したことを契機として前記停止信号の宛先である前記物理IOデバイスの停止を行う、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
前記仮想IOデバイスは、
受信した処理要求が完了した場合に前記ハイパバイザに対して割り込みをあげ、
前記ハイパバイザは、
前記割り込みに基づいて、前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了していると前記判定する、
ことを特徴とする計算機装置。
請求項１に記載の計算機装置であって、
前記共有IOデバイスはSR-IOVに対応したデバイスであり、
前記物理IOデバイスは前記SR-IOVに対応したデバイスのPhysical Functionであり、
前記仮想IOデバイスは前記SR-IOVに対応したデバイスのVirtual Functionである、
ことを特徴とする計算機装置。
第１の仮想計算機と、第２の仮想計算機と、前記第１、第２の仮想計算機を管理するハイパバイザと、を格納する記憶部と、前記第１、第２の仮想計算機が利用する共有IOデバイスと、を有する計算機装置の制御方法であって、
前記共有IOデバイスに、物理IOデバイスと、仮想IOデバイスと、を設け、
前記物理IOデバイスが前記仮想IOデバイスを制御し、
前記第１の仮想計算機に、物理IOデバイスを制御する第１のドライバを設け、
前記第２の仮想計算機に、仮想IOデバイスを制御する第２のドライバを設け、
前記ハイパバイザが、
前記第１のドライバによる前記物理IOデバイスを停止させる停止信号の送信を検出した場合に、前記リセット信号の前記共有IOデバイスへの伝達を抑止し、
前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了しているか否かを判定し、
前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了したことを契機として前記物理IOデバイスの停止を行い、
前記第１のドライバが前記停止信号を前記物理IOデバイス宛に送信して以降に前記第２のドライバが前記仮想IOデバイスに対して送信する処理要求の前記物理IOデバイスへの到達を抑止する、
ことを特徴とする計算機装置の制御方法。
請求項８に記載の計算機装置の制御方法であって、
前記計算機装置が備えるルートブリッジによって、前記第１の仮想計算機から前記物理IOデバイスへの第１の接続と、前記第２の仮想計算機から前記仮想IOデバイスへの第２の接続と、を管理し、
前記ルートブリッジが、前記前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が所定の期間内に完了しない場合に前記計算機装置の停止処理を行う、
ことを特徴とする計算機装置の制御方法。
請求項８に記載の計算機装置の制御方法であって、
前記仮想IOデバイスが、受信した処理要求を受信順序に従って実行し、
前記ハイパバイザが、前記仮想IOデバイスに対して処理要求を送信し、前記ハイパバイザが前記仮想IOデバイスに対して送信した処理要求の完了を検知した場合に、前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了していると前記判定する、
ことを特徴とする計算機装置の制御方法。
請求項８に記載の計算機装置の制御方法であって、
前記ハイパバイザが、
前記第２の仮想計算機から前記仮想IOデバイスへの接続を制御する際に用いる仮想IOデバイスのアドレスを管理し、
前記管理するアドレスを変更することで、前記停止信号の前記共有IOデバイスへの伝達を抑止する、
ことを特徴とする計算機装置の制御方法。
請求項８に記載の計算機装置の制御方法であって、
前記計算機装置が複数の前記共有IOデバイスを備え、
前記ハイパバイザは、
前記物理IOデバイスと、前記物理IOデバイスが制御する前記仮想IOデバイスと、を対応付けて管理し、
前記停止信号の送信を検出した場合に、
前記対応付けに基づいて、前記停止信号の宛先である前記物理IOデバイスに前記対応付けられた前記仮想IOデバイスを抽出し、
前記抽出した前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了しているか否かの前記判定を行い、
前記抽出した前記仮想IOデバイスに対して前記第２のドライバが送信した処理要求が完了したことを契機として前記停止信号の宛先である前記物理IOデバイスの停止を行う、
ことを特徴とする計算機装置の制御方法。
請求項８に記載の計算機装置の制御方法であって、
前記共有IOデバイスはSR-IOVに対応したデバイスであり、
前記物理IOデバイスは前記SR-IOVに対応したデバイスのPhysical Functionであり、
前記仮想IOデバイスは前記SR-IOVに対応したデバイスのVirtual Functionである、
ことを特徴とする計算機装置の制御方法。