(57)【要約】  ハイパバイザの他に、簡易ハイパバイザを計算機上で稼動させる。簡易ハイパバイザ上で、ハイパバイザ障害時にも動作継続を保証したいゲストＯＳが動作し、ハイパバイザ上では、それ以外のゲストＯＳが動作する。資源スケジューリング（各ゲストＯＳについて割り当てる又は回収する資源の決定）はハイパバイザが行い、動作継続を保証したいゲストＯＳについて資源の割当て又は回収は、簡易ハイパバイザがハイパバイザに代わって実行する。
2015122007.tif 000002
【特許請求の範囲】
【請求項１】
１以上の物理メモリと複数の物理ＣＰＵ（Central  Processing  Unit）とを含んだ複数の資源を有し、
前記複数の物理ＣＰＵが、ハイパバイザ、簡易ハイパバイザ、第１のゲストＯＳ（Operating  System）、及び第２のゲストＯＳを実行し、
前記複数の資源において、前記ハイパバイザに使用される資源と、前記簡易ハイパバイザに使用される資源は、異なっており、
前記１以上の物理メモリが、前記ハイパバイザに使用されない第１の物理メモリ領域と前記ハイパバイザに使用される第２の物理メモリ領域とを有し、
前記第１のゲストＯＳは、前記第１の物理メモリ領域を基に、前記簡易ハイパバイザ上で実行され、
前記第２のゲストＯＳは、前記第２の物理メモリ領域を基に、前記ハイパバイザ上で実行され、
前記ハイパバイザは、前記複数の資源を複数の仮想資源に仮想化する機能であるエミュレート機能と、前記第１及び第２のゲストＯＳの各々について動的に割り当てる又は回収する資源を決定する機能である資源スケジューリング機能とを有し、
前記簡易ハイパバイザは、前記ハイパバイザの前記資源スケジューリング機能に従い前記第１のゲストＯＳに対する資源割当て又は資源回収を前記ハイパバイザに代わって行う機能であるスケジューリングエージェント機能を有し、
前記ハイパバイザは、資源の割当て又は回収に関する要求を発行し、前記簡易ハイパバイザが、前記要求を取得し、前記要求に従い処理を実行する、
計算機。
【請求項２】
前記要求は、記憶領域に書き込まれ、
前記簡易ハイパバイザが、前記要求を前記記憶領域から取得する、
請求項１記載の計算機。
【請求項３】
前記ハイパバイザを実行する第１の物理ＣＰＵとは別の第２の物理ＣＰＵが前記簡易ハイパバイザを実行し、
前記要求の発行は、トラップ命令の発行、又は、前記第２の物理ＣＰＵに対する割込みの通知である、
請求項２記載の計算機。
【請求項４】
前記記憶領域は、要求ログ情報を記憶する不揮発領域であり、
前記要求は、ログとして前記要求ログ情報に追加され、
前記簡易ハイパバイザが、前記要求ログ情報内の前記ログを、前記要求に従う処理の実行に基づき更新する、
請求項２記載の計算機。
【請求項５】
前記要求が、ＣＰＵ割当て要求の場合、前記簡易ハイパバイザが、割当て対象の物理ＣＰＵ上で動作を開始し、前記第１のゲストＯＳに、前記割当て対象の移りＣＰＵが利用可能になったことを通知し、
前記要求が、ＣＰＵ回収要求の場合、前記簡易ハイパバイザが、前記第１のゲストＯＳに割り当てられている物理ＣＰＵのうち回収対象の物理ＣＰＵを前記第１のゲストＯＳに通知し、前記回収対象の物理ＣＰＵ上での動作を停止する、
請求項１記載の計算機。
【請求項６】
前記ＣＰＵ割当て要求の発行は、トラップ命令の発行であり、
前記ＣＰＵ回収要求の発行は、前記利用不可能にある物理ＣＰＵに対する割込み通知である、
請求項５記載の計算機。
【請求項７】
前記要求が、メモリ割当て要求の場合、前記簡易ハイパバイザが、前記１以上の物理メモリのうちの割当て対象のメモリ領域を、前記第１のゲストＯＳからアクセス可能となるよう、前記第１のゲストＯＳから指定される論理アドレスであるゲストアドレスと、前記１以上の物理メモリにおけるメモリ領域の物理アドレスであるホストアドレスとの対応付けを表すアドレス変換情報を更新し、前記割当て対象のメモリ領域が利用可能になったことを前記第１のゲストＯＳに通知し、
前記要求が、メモリ回収要求の場合、前記簡易ハイパバイザが、前記第１のゲストＯＳに割り当てられているメモリ領域のうち利用不可能なメモリ領域を前記第１のゲストＯＳに通知し、前記利用不可能なメモリ領域を前記第１のゲストＯＳからアクセス不可能となるよう前記アドレス変換テーブルを更新する、
請求項１記載の計算機。
【請求項８】
前記要求ログ情報内の各ログは、そのログに対応した要求に従う処理の進捗状況を含み、
前記不揮発領域は、更に、前記複数の資源の割当て状態を表す割当て状態情報を記憶し、
前記ハイパバイザは、再起動した場合、前記不揮発領域内の前記要求ログ情報及び前記割当て状態情報を参照し、処理中の要求については処理が完了するまで待ち、前記要求ログ情報を基に前記割当て状態情報を更新し、更新後の割当て状態情報を基に、前記複数の資源のうち前記第１のゲストＯＳに割り当てられていない資源を用いて、前記ハイパバイザ及び前記第２のゲストＯＳの初期化を実行する、
請求項４記載の計算機。
【請求項９】
前記第１のゲストＯＳ、前記簡易ハイパバイザ、及び、前記第１のゲストＯＳから指定される論理アドレスであるゲストアドレスと前記１以上の物理メモリにおけるメモリ領域の物理アドレスであるホストアドレスとの対応付けを表すアドレス変換情報は、前記第１のメモリ領域に配置され、
前記第１のメモリ領域は、前記ハイパバイザ及び前記第２のゲストＯＳから書き込み不可能な領域である、
請求項１記載の計算機。
【請求項１０】
前記簡易ハイパバイザが、前記第１のゲストＯＳから特権命令が発行された場合、前記特権命令に基づきレジスタの値を更新することを前記ハイパバイザに代わって実行する、
請求項１記載の計算機。
【請求項１１】
前記ハイパバイザが、各ゲストＯＳについて、
使用可能な資源量の範囲を特定し、
発行対象の要求に従う資源割当て又は資源回収が実行されると、割り当てられている資源量が前記特定した範囲外の資源量となる場合、前記要求の発行を中止する、
請求項１記載の計算機。
【請求項１２】
前記ハイパバイザが、各ゲストＯＳについて、割り当てられている資源の量である割当て資源量を管理し、
前記ハイパバイザが、各ゲストＯＳついて、資源割当て又は資源回収に伴い、前記割当て資源量を更新する、
請求項１記載の計算機。
【請求項１３】
前記ハイパバイザが、前記第２のゲストＯＳからアクセス可能なメモリ領域を制御するためのアドレス設定要求を発行し、
前記簡易ハイパバイザが、前記アドレス変更要求に従い前記アドレス変換情報を更新する、
請求項９記載の計算機。
【請求項１４】
前記要求ログ情報内の各ログは、そのログに対応した要求に従う処理の進捗状況を含み、
前記要求が、ＣＰＵ回収要求の場合、前記簡易ハイパバイザが、前記第１のゲストＯＳに割り当てられている物理ＣＰＵのうち回収対象の物理ＣＰＵを前記第１のゲストＯＳに通知し、前記回収対象の物理ＣＰＵ上での動作を停止し、
前記ハイパバイザが、
前記ＣＰＵ回収要求に従い前記簡易ハイパバイザが動作を停止した後、割込み通知を待ち、
前記ＣＰＵ回収要求に対応した処理の進捗情報を前記要求ログ情報から特定し、
前記特定した進捗状況が完了を表している場合、前記回収対象の物理ＣＰＵに対して割込み通知を行う、
請求項４記載の計算機。
【請求項１５】
１以上の物理メモリと複数の物理ＣＰＵ（Central  Processing  Unit）とを含んだ複数の資源を有する計算機においてハイパバイザにより資源スケジューリングを行う資源スケジューリング方法であって、
前記１以上の物理メモリに、前記ハイパバイザに使用されない第１の物理メモリ領域と、前記ハイパバイザに使用される第２の物理メモリ領域とを設け、前記複数の資源のうちの、前記ハイパバイザに使用される資源とは異なる資源を用いて、簡易ハイパバイザを実行し、
前記簡易ハイパバイザ上で、前記第１の物理メモリ領域を基に、第１のゲストＯＳ（Operating  System）を実行し、前記ハイパバイザ上で、前記第２の物理メモリ領域を基に、第２のゲストＯＳを実行し、前記ハイパバイザは、前記複数の資源を複数の仮想資源に仮想化する機能であるエミュレート機能と、前記第１及び第２のゲストＯＳの各々について動的に割り当てる又は回収する資源を決定する機能である資源スケジューリング機能とを有し、前記簡易ハイパバイザは、前記ハイパバイザの前記資源スケジューリング機能に従い前記第１のゲストＯＳに対する資源割当て又は資源回収を前記ハイパバイザに代わって行う機能であるスケジューリングエージェント機能を有し、
前記ハイパバイザにより、資源の割当て又は回収に関する要求を発行し、
前記簡易ハイパバイザにより、前記要求を取得し、前記要求に従い処理を実行する、
資源スケジューリング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ハイパバイザによる資源スケジューリングに関する。
【背景技術】
【０００２】
ハイパバイザを用いて複数のゲストＯＳを動作させる計算機が知られている。このような計算機では、ハイパバイザにおける動的な資源スケジューリング機能を使用し、負荷に応じて各ゲストＯＳに割り当てる資源量が調節される。資源としては、物理メモリ及び物理ＣＰＵ（Central  Processing  Unit）が一般的である。また、同一筐体上に複数のゲストＯＳが共存する計算機もある。【０００３】
このような計算機が適用される用途によっては、高可用性の保証が必須になる。そのような用途の一例は、ミッションクリティカルな用途である。ハイパバイザは、多くの機能を有する機構（典型的にはコンピュータプログラムでよいが、コンピュータプログラムが実装されたハードウェア回路）であり、故に、ハイパバイザの可用性をミッションクリティカルな用途に適用可能なレベルまで高めることは難しい。そのため、ミッションクリティカル向け計算機には、一般にハイパバイザを搭載できない。【０００４】
ハイパバイザによる資源スケジューリング方法として、非特許文献１に記載の方法が知られている。その方法によれば、ハイパバイザが有するＣＰＵスケジューラ（資源スケジューラの一例）は、ＯＳ（Operating  System）のＣＰＵスケジューラと同様の動作を行う。【０００５】
ハイパバイザは、仮想的な実行環境（仮想計算機）を提供し、各仮想計算機の仮想ＣＰＵ上で動作するゲストＯＳの処理をプロセスとして扱う。そして、ＣＰＵスケジューラが物理ＣＰＵ上でどのゲストＯＳ（プロセス）をスケジューリングするか決定する。さらに、ハイパバイザは、物理ＣＰＵ上の実行コンテキストの切り替え処理（資源のディスパッチ/プリエンプト処理）も実行する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】VMware Inc., ”The CPU scheduler in VMware vSphere 5.1”, VMware technical white paper, 2013.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記方法では、ハイパバイザに障害が発生した場合、すべてのゲストＯＳの動作継続が不可能になる。なぜなら、ハイパバイザ障害により、ゲストＯＳへの資源のディスパッチ/プリエンプト処理（割り当て/回収処理）が実行されなくなるためである。あらゆるゲストＯＳは、動作するために必要な資源（ＣＰＵやメモリなど）を利用不可能になり、動作継続は不可能になる。
【課題を解決するための手段】
【０００８】
ハイパバイザの他に、簡易ハイパバイザを計算機上で稼動させる。ハイパバイザは、１以上の物理メモリ及び複数の物理ＣＰＵを含んだ複数の資源のエミュレートの機能と、資源スケジューリング（各ゲストＯＳについて割り当てる又は回収する資源の決定）の機能を有するが、簡易ハイパバイザは、ゲストＯＳに対する資源割当て又は資源回収をハイパバイザに代わって行うエージェント機能を有している。簡易ハイパバイザ上で、第１のゲストＯＳ（例えば、ハイパバイザ障害時にも動作継続を保証したいゲストＯＳ）が動作し、ハイパバイザ上では、第２のゲストＯＳ（第１のゲストＯＳ以外のゲストＯＳ）が動作する。資源スケジューリングはハイパバイザが行い、第１のゲストＯＳについて資源の割当て又は回収は、簡易ハイパバイザがハイパバイザに代わって実行する。
【発明の効果】
【０００９】
ハイパバイザに障害が発生しても第１のゲストＯＳの動作継続を保証することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態で想定するシステム構成
【図２】本発明の実施例で想定するハードウェア構成
【図３】ディスパッチ/プリエンプト要求ログのデータ構造
【図４】ＣＰＵ割り当て状態のデータ構造
【図５】メモリ割り当て状態のデータ構造
【図６】ハイパバイザコンテキスト保存領域のデータ構造
【図７】ハイパバイザエージェントコンテキスト保存領域のデータ構造
【図８】ディスパッチ/プリエンプト処理時に使用するコード領域及びスタック領域の配置を示す図
【図９】アドレス変換テーブルのデータ構造
【図１０】ＣＰＵ利用履歴管理テーブルのデータ構造
【図１１】メモリ利用履歴管理テーブル（１００１）のデータ構造
【図１２】ＣＰＵスケジューラの動作フロー（定期起動時）
【図１３】ＣＰＵスケジューラの動作フロー（ＣＰＵディスパッチエージェントからのトラップリターン時）
【図１４】ＣＰＵディスパッチエージェント及び第１のゲストＯＳ ＣＰＵスケジュラの動作フロー（ディスパッチ要求時）
【図１５】ＣＰＵディスパッチエージェント及び第１のゲストＯＳ ＣＰＵスケジュラの動作フロー（プリエンプト要求時）
【図１６】メモリスケジューラの動作フロー
【図１７】メモリディスパッチエージェント及び第１のゲストＯＳ メモリスケジューラの動作フロー
【図１８】特権命令実行部及びステートレスＣＰＵエミュレータの動作フロー
【図１９】再起動制御の動作フロー（定期起動時）
【図２０】再起動制御の動作フロー（再起動時）
【発明を実施するための形態】
【００１１】
以下、一実施形態を説明する。
【００１２】
なお、以下の説明では、「ｋｋｋテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｋｋｋテーブル」を「ｋｋｋ情報」と呼ぶことができる。
【００１３】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、物理ＣＰＵによって実行されることで、定められた処理を、適宜に記憶資源（例えば、メモリ）及び／又は通信インターフェイスデバイス（例えば、通信ポート）を用いながら行うため、処理の主語が物理ＣＰＵとされてもよい。逆に、物理ＣＰＵが主語となっている処理は、１以上のプログラムを実行することにより行われると解釈することができる。また、物理ＣＰＵは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよいし、マルチコアプロセッサの各コアの意味であってもよい。コンピュータプログラムは、プログラムソースから各計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであってもよい。
【００１４】
図１は、実施形態の概要を示す。
【００１５】
計算機２０１が、複数の物理ＣＰＵ（１１１）と、物理メモリ（１１２）及び（１１３）とを含んだ複数の資源（物理資源）を有する。物理メモリ（１１２）は、第１物理メモリ領域の一例であり、物理メモリ（１１３）は、第２物理メモリ領域の一例である。物理メモリ（１１２）及び（１１３）は、一体の物理メモリのメモリ領域から確保された複数のメモリ領域でもよい。
【００１６】
計算機２０１において、ハイパバイザ（１０１）の他にハイパバイザエージェント（１０２）が存在し、仮想計算機環境が提供される。ハイパバイザエージェント（１０２）は、簡易ハイパバイザの一例である。ハイパバイザエージェント（１０２）が提供する仮想計算機上で第１のゲストＯＳ（１０３）が稼働し、ハイパバイザ（１０１）が提供する仮想計算機上で第２のゲストＯＳ（１０４）が稼動する。第１のゲストＯＳ（１０３）と第２のゲストＯＳ（１０４）の各々に対して、動的に資源を割り当てる又は回収する資源スケジューリングが行われる。本実施形態では、動的に割り当てられる又は回収される資源として、物理ＣＰＵと、メモリ領域（本実施形態では「ページ」と言うこともある）がある。
【００１７】
ハイパバイザエージェント（１０２）の動作に利用される資源は、複数の資源のうち、第１のゲストＯＳ（１０３）が利用可能な（ハイパバイザ（１０１）が利用しない）資源のみでよい。ハイパバイザエージェント（１０２）は、ゲストＯＳから指定される論理アドレス（本実施形態ではゲスト物理ページ番号）とその論理アドレスに対応した物理アドレス（本実施形態ではホスト物理ページ番号）との対応付けを表すアドレス変換テーブル（１３４）を更新することにより、メモリ仮想化を行うことができる。これにより、第１のゲストＯＳ（１０３）がアクセス可能なメモリ領域（ページ）を制御することができる。なお、アドレス変換テーブル（１３４）は、例えば、ＥＰＴ（拡張ページテーブル）、又は、ＤＷＡＲ（DMA（Direct  Memory  Access）  Remapping）テーブルでよい。
【００１８】
資源スケジューリングを決定するのはハイパバイザ（１０１）であるが、第１のゲストＯＳ（１０３）に対する資源割当て又は資源回収は、ハイパバイザエージェント（１０２）がハイパバイザに代わって実行する。
【００１９】
ハイパバイザ（１０１）は、資源のディスパッチ／プリエンプト（割当て／回収）要求発行を不揮発領域（不揮発性の記憶領域）（１１４）への書き込みにより行う。ハイパバイザエージェント（１０２）は、その要求を不揮発領域（１１４）から読み出し、その要求に従う処理を実行する。不揮発領域（１１４）に代えて揮発性の記憶領域が採用されてもよい。また、不揮発領域（１１４）は、計算機（２０１）の外に存在してもよい（図２参照）。
【００２０】
要求が、ＣＰＵのディスパッチ要求であれば、ディスパッチ対象の物理ＣＰＵのコンテキストが、ハイパバイザ（１０１）からハイパバイザエージェント（１０２）に切り替えられ、当該物理ＣＰＵ上でハイパバイザエージェント（１０２）が動作する。さらに、ハイパバイザエージェント（１０２）は、第１のゲストＯＳ（１０３）に当該物理ＣＰＵが利用可能になったことを通知する。この結果、第１のゲストＯＳ（１０３）が当該物理ＣＰＵ上で動作し始めることができる。
【００２１】
要求が、物理ＣＰＵのプリエンプト要求であれば、ハイパバイザエージェント（１０２）が、第１のゲストＯＳ（１０３）に当該物理ＣＰＵが利用不可能になったことを通知する。この結果、第１のゲストＯＳ（１０３）が当該物理ＣＰＵ上で動作することはなくなる。さらに、プリエンプト対象の物理ＣＰＵのコンテキストが、ハイパバイザエージェント（１０２）からハイパバイザ（１０１）に切り替わる。
【００２２】
要求が、メモリディスパッチ要求又はメモリプリエンプト要求であれば、第１のゲストＯＳ（１０３）による指定されたメモリ領域へのアクセスを可能、もしくは不可能とするように、アドレス変換テーブル（１３４）の更新処理が実行される。この際に、ハイパバイザエージェント（１０２）は、第１のゲストＯＳ（１０３）に通知を行い、第１のゲストＯＳ（１０３）も当該メモリ領域へのアクセスが可能、もしくは不可能になったことを認識する。
【００２３】
ハイパバイザエージェント（１０２）が提供する仮想計算機環境では、物理ＣＰＵは仮想化されないが物理メモリ（１１２及び１１３）は仮想化される。すなわち、第１のゲストＯＳ（１０３）は、物理ＣＰＵ（１１１）上のレジスタ（１１５）を直接更新しながら占有実行する。しかし、第１のゲストＯＳ（１０３）は、物理メモリ（１１２及び１１３）にアドレス変換テーブル（１３４）を介してアクセスする。この際、物理メモリのアドレス空間は変換され、一部の物理メモリ（領域）の存在は第１のゲストＯＳ（１０３）からは認識できない。
【００２４】
動的資源スケジューリングを実現するため、ハイパバイザ（１０１）は、ＣＰＵスケジューラ（１２１）及びメモリスケジューラ（１２２）を有する。これらのスケジューラが、物理ＣＰＵ（１１１）や物理メモリ（１１２及び１１３）の第１のゲストＯＳ（１０３）や第２のゲストＯＳ（１０４）への割り当てを決定する。
【００２５】
ハイパバイザエージェント（１０２）は、ＣＰＵディスパッチエージェント（１２６）、メモリディスパッチエージェント（１２５）及びステートレスＣＰＵエミュレータ１２４を有する。
【００２６】
物理ＣＰＵ（１１１）や物理メモリ（１１２及び１１３）の第１のゲストＯＳへのディスパッチ処理を上記スケジューラは直接行わず、不揮発領域（１１４）を介して資源のディスパッチ/プリエンプト要求を発行する。この要求を参照して、ハイパバイザエージェント（１０２）のＣＰＵディスパッチエージェント（１２６）やメモリディスパッチエージェント（１２５）がＣＰＵ/メモリのディスパッチ処理を行う。
【００２７】
ＣＰＵのディスパッチ処理では、物理ＣＰＵ（１１１）の実行コンテキストの切り替え処理が行われる。これにより、物理ＣＰＵ（１１１）上で動作するゲストＯＳが切り替わる。また、メモリのディスパッチ処理では、アドレス変換テーブル（１３４）の設定処理（更新処理）が行われる。これにより、物理メモリ（１１２）の一部を新たに第１のゲストＯＳ（１０３）からアクセス可能にしたり不可能にしたりすることができる。第１のゲストＯＳ（１０３）は、ゲストＣＰＵスケジューラ（１２９）、ゲストメモリスケジューラ（１２８）及び特権命令実行部（１２７）を有するが、ディスパッチ処理の実現のため、ハイパバイザエージェント（１０２）は、ゲストＣＰＵスケジューラ（１２９）及びメモリスケジューラ（１２８）との連携を行う。
【００２８】
以上のような構成を取ることにより、第１のゲストＯＳ（１０３）と第２のゲストＯＳ（１０４）が使用するＣＰＵ/メモリ資源の動的スケジューリングが実現できる。
【００２９】
本実施形態で想定するシステム構成では、第１のゲストＯＳ（１０３）は物理ＣＰＵ（１１１）上で直接実行する。しかし、物理ＣＰＵ（１１１）によっては、アドレス変換テーブル（１３４）によるメモリ仮想化機能を有効にした場合、第１のゲストＯＳ（１０３）の特権命令実行時にトラップが発生してしまう場合がある。この場合においても直接実行を保証するため、ハイパバイザエージェント（１０２）は、前述のステートレスＣＰＵエミュレータ（１２４）を有する。ステートレスＣＰＵエミュレータ（１２４）は、トラップした特権命令に応じて、物理ＣＰＵ（１１１）上のレジスタ（１１５）の更新処理を実行する。
【００３０】
また、ハイパバイザ（１０１）に障害が発生しても、第１のゲストＯＳ（１０３）及びハイパバイザエージェント（１０２）の動作を継続しつつ、ハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）の再起動及び処理継続を可能にするため、ハイパバイザエージェント（１０２）及び第１のゲストＯＳ（１０３）は、物理メモリの保護領域（１１２）、すなわち、ハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）からは書き込み不可能な領域に配置される。ハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）が、この領域のデータやコードを破壊できない。また、ハイパバイザ（１０１）は、再起動制御（１２３）を有する。不揮発領域（１１４）は、要求ログテーブル（１３１）、ＣＰＵ割当て状態テーブル（１３２）及びメモリ割り当て状態テーブル（１３３）を記憶するが、再起動制御（１３１）は、不揮発領域（１１４）に格納されているそれらの情報（１３１）〜（１３３）を参照する。そして、再起動制御（１２３）は、要求ログテーブル（１３１）に登録してある発行中の要求の処理が完全に完了するまで待つ。さらに、再起動制御（１２３）は、ＣＰＵ/メモリの割り当て状態に応じ、ハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）が利用可能なＣＰＵ/メモリのみを利用して、これらの起動処理を行う。
【００３１】
第１のゲストＯＳ（１０３）が利用する資源のディスパッチは、ハイパバイザエージェント（１０２）がハイパバイザ（１０１）に代わって行う。また、第１のゲストＯＳ（１０３）の実行中に介在してＣＰＵエミュレーションを行うのも、ハイパバイザエージェント（１０２）でありハイパバイザ（１０１）ではない。すなわち、ハイパバイザ（１０１）に障害が発生しても、第１のゲストＯＳ（１０３）及びハイパバイザエージェント（１０２）は動作を継続できる。ハイパバイザエージェント（１０２）の提供機能はハイパバイザ（１０１）に比べると少なく（例えば、はるかに少なく）、故に、ハイパバイザ（１０１）に障害が発生しても第１のゲストＯＳ（１０３）の動作を継続することは難しくないと考えられる。
【００３２】
また、要求ログテーブル（１３１）、ＣＰＵ割当て状態テーブル（１３２）及びメモリ割り当て状態テーブル（１３３）が不揮発領域（１１４）に保存され、ハイパバイザ（１０１）再起動後にも参照可能な構成にすることにより、ハイパバイザ障害発生後にも、第２のゲストＯＳ（１０４）及びハイパバイザ（１０１）のみの再起動及び処理継続も可能になる。
【００３３】
以下、本実施形態を詳細に説明する。
【００３４】
図２は、計算機２０１のハードウェア構成を示す。
【００３５】
第１のゲストＯＳ（１０３）、ハイパバイザエージェント（１０２）、第２のゲストＯＳ（１０４）及びハイパバイザ（１０１）のようなプログラムは、計算機（２０１）の物理メモリ（１１２及び１１３）上に配置される。物理メモリ（１１２及び１１３）は、ＣＰＵバス（２０２）を介して複数の物理ＣＰＵ（１１１）に通信可能に接続される。複数の物理ＣＰＵ（１１１）のうちの少なくとも１つが、上述のプログラムを読み込んで実行する。アドレス変換テーブル（１３４）は、物理メモリ（１１２及び１１３）上に配置され、第１のゲストＯＳ（１０３）や第２のゲストＯＳ（１０４）実行時のメモリアクセスにおけるアドレス変換の制御に使用される。要求ログテーブル（１３１）、ＣＰＵ割当て状態テーブル（１３２）、メモリ割り当て状態テーブル（１３３）は、不揮発領域（１１４）に配置される。計算機（１０２）は、Ｉ／Ｏ（Input/Output）コントローラ（２０３）を有し、不揮発領域（１１４）には、Ｉ／Ｏコントローラ（２０３）及びＩ／Ｏケーブル（２０４）を介して、物理ＣＰＵ（１１１）上で実行するプログラムからアクセスできる。例えば、読み込み処理を行う場合には、プログラムが、Ｉ／Ｏコントローラ（２０３）に対してＩ／Ｏ要求を発行する。Ｉ／Ｏコントローラ（２０３）は、Ｉ／Ｏケーブル（２０４）を介して不揮発領域（１１４）上のデータを読み込み、読み込んだデータを、ＣＰＵバス（２０２）を介して物理メモリ（１１２及び１１３）に書き込む。物理ＣＰＵ（１１１）上で動作するプログラムは、ＣＰＵバス（２０２）を介して、その書き込まれたデータを取得する。Ｉ／Ｏケーブル（２０４）は、通信ネットワークにおけるケーブルでもよい。
【００３６】
図３は、要求ログテーブル（１３１）の構成を示す。
【００３７】
要求ログテーブル（１３１）は、ＣＰＵスケジューラ（１２１）やメモリスケジューラ（１２２）が発行する資源ディスパッチ/プリエンプト要求と、その要求のＣＰＵディスパッチエージェント（１２６）及びメモリエージェント（１２５）により処理状況とを含んだログを管理するためのテーブルである。本テーブルは、要求毎に、資源種別（３０１）、番号（３０２）、旧状態（３０３）、新状態（３０４）、ゲスト物理番号（３０５）及び処理状態（３０６）のフィールドを有する。１つのカラムが、１つの要求のログに対応する。
【００３８】
資源種別（３０１）は、ディスパッチ/プリエンプト対象がＣＰＵであるかメモリであるかを表す。
【００３９】
番号（３０２）は、ディスパッチ/プリエンプトの対象となる資源の番号（識別番号）を表す。ＣＰＵがディスパッチ対象の場合、番号（３０２）は、ディスパッチ対象の物理ＣＰＵの番号を表し、メモリがディスパッチ対象の場合、ディスパッチ対象のメモリ領域（ページ）のホスト物理ページ番号、ページを識別する番号を表す。
【００４０】
旧状態（３０３）及び新状態（３０４）はディスパッチ/プリエンプト処理の前及び後において対象資源を利用可能なゲストＯＳの番号を表す。対象資源がどのゲストＯＳにも割り当てられず空き状態になる場合には、旧状態（３０３）及び新状態（３０４）の少なくとも一方の値は、空き状態を意味する値「Ｆ」でよい。
【００４１】
ゲスト物理番号（３０５）はハイパバイザ（１０１）による資源ディスパッチ/プリエンプト要求ではなく、ハイパバイザ（１０１）がアドレス変換テーブル（１３４）の設定をハイパバイザエージェント（１０２）に依頼する特殊ケースでのみ使用される。本実施形態では、アドレス変換テーブル（１３４）は、ハイパバイザ（１０１）とハイパバイザエージェント（１０２）で共有される。この際、ハイパバイザ（１０１）によるアドレス変換テーブル（１３４）破壊を防止するため、アドレス変換テーブル（１３４）が、物理メモリ（保護領域）（１１２）に配置される。ハイパバイザ（１０１）が、アドレス変換テーブル（１３４）を更新する際には、設定に必要な情報（例えば、番号（３０２）及び新状態（３０４））が指定されたアドレス変更要求をメモリディスパッチエージェント（１２５）に発行する。
【００４２】
処理状態（３０６）は、要求に従うディスパッチ/プリエンプト処理の処理状況を表す。ＣＰＵスケジューラ（１２１）やメモリスケジューラ（１２２）は、要求を発行すると、その要求に対応した処理状態（３０６）を「処理中」に更新する。また、ＣＰＵディスパッチエージェント（１２６）やメモリディスパッチエージェント（１２５）は、要求に従う処理を完了すると、その要求に対応した処理状態（３０６）を「完了」に更新する。
【００４３】
要求の種類によっては、上記フィールドのうち一部のフィールドのみが使用される。例えば、要求が、ＣＰＵのディスパッチ/プリエンプト要求の場合、ゲスト物理番号（２０５）のフィールドは使用されない。
【００４４】
また、メモリのディスパッチ/プリエンプト要求としては、第１のゲストＯＳ（１０３）にメモリ領域（ページ）を割り当てるディスパッチ要求、第１のゲストＯＳ（１０３）からメモリ領域を回収するプリエンプト要求、及び、ハイパバイザ（１０１）によるアドレス変換テーブル（１３４）のアドレス更新要求、の３種類がある。ディスパッチ要求の場合には、ゲスト物理番号（３０５）のフィールドが使用されない。プリエンプト要求の場合には、番号（３０２）及びゲスト物理番号（３０５）のフィールドが使用されない（第１のゲストＯＳ（１０３）が現在利用している任意の１ページの回収が要求されてよい）。また、アドレス変換要求の場合には、旧状態（３０３）のフィールドが使用されない（要求の前後で資源の所有者は変更されないためである）。
【００４５】
図４は、ＣＰＵ割当て状態テーブル（１３２）の構成を示す。
【００４６】
ＣＰＵ割当て状態テーブル（１３２）は、物理ＣＰＵ毎に、ＣＰＵ番号（４０１）のフィールドと割り当て先（４０２）のフィールドとを有する。ＣＰＵ番号（４０１）は、物理ＣＰＵ（１１１）の番号（識別番号）を表し、割り当て先（４０２）は、対応する物理ＣＰＵ（１１１）が割り当てられているゲストＯＳの番号（識別番号）を表す。割り当て先のゲストＯＳがなく空き状態である物理ＣＰＵ（１１１）について、割り当て先（４０２）の値は、空き状態を意味する値「Ｆ」でよい。また、ディスパッチ/プリエンプト処理中である物理ＣＰＵ（１１１）について、割り当て先（４０２）の値は、処理中を意味する値「＃」でよい。
【００４７】
図５は、メモリ割り当て状態テーブル（１３３）の構成を示す。
【００４８】
メモリ割り当て状態テーブル（１３３）、ページ毎に、ホスト物理ページ番号（５０１）のフィールドと、ゲスト物理ページ番号（５０２）のフィールドと、割り当て先（５０３）のフィールドとを有する。ホスト物理ページ番号（５０１）は、ページの番号（識別番号）を表し、物理アドレスに相当する。ゲスト物理ページ番号（５０２）は、ゲストＯＳが認識しているページ番号を表し、論理アドレスに相当する。割り当て先（５０３）は、ページの割り当て先のゲストＯＳの番号を表す。割り当て先のゲストＯＳがなく空き状態のページについて、ゲスト物理ページ番号（５０２）及び割り当て先（５０３）は、それぞれ、空き状態を意味する値「Ｆ」でよい。また、ディスパッチ/プリエンプト処理中のページについて、ゲスト物理ページ番号（５０２）及び割り当て先（５０３）は、それぞれ、処理中を意味する値「＃」でよい。
【００４９】
図６は、第１のコンテキスト保存領域（６０１）を示す。
【００５０】
第１のコンテキスト保存領域（６０１）は、物理メモリ（１１３）の一部領域でよい。ＣＰＵスケジューラ（１２１）が、ＣＰＵディスパッチ/プリエンプト処理を行う際に、第１のコンテキスト保存領域（６０１）が使用される。ＣＰＵスケジューラ（１２１）は、第１のコンテキスト保存領域（６０１）を使用して、ハイパバイザエージェント（１０２）の実行コンテキストの退避及び回復を行う。
【００５１】
図７は、第２のコンテキスト保存領域（７０１）を示す。
【００５２】
第２のコンテキスト保存領域（７０１）は、物理メモリ（１１２）の一部領域でよい。ＣＰＵディスパッチエージェント（１２６）が、ＣＰＵディスパッチ要求を発行する前に、本データ構造にハイパバイザ（１０１）の実行コンテキストを退避する。また、プリエンプト要求処理が完了した後に、第２のコンテキスト保存領域（７０１）からハイパバイザ（１０１）の実行コンテキストが回復する。
【００５３】
図８は、コード領域及びスタック領域の配置を示す。
【００５４】
コード領域及びスタック領域は、物理ＣＰＵ（１１１）のディスパッチ/プリエンプト処理時に使用される。ＣＰＵのディスパッチ/プリエンプト要求は、ＣＰＵスケジューラ（１２１）により発行される。その処理を行うためのコードが、ＣＰＵスケジューラコード領域（１）（８１３）に配置される。また、その処理を行う際に使用するスタックは、ＣＰＵスケジューラスタック領域（８１５）に配置される。これらの領域は物理メモリ（１１３）上にある。
【００５５】
物理ＣＰＵ（１１１）のディスパッチ要求発行は、トラップ命令発行により行う。この際のジャンプ先は、ハイパバイザ（１０１）が管理する割り込みハンドラテーブル（８０１）に登録されており、そのテーブル（８０１）により、ＣＰＵディスパッチエージェント（１２６）へのジャンプが実現する。ＣＰＵディスパッチエージェント（１２６）により行われる処理のコードは、ＣＰＵディスパッチエージェントコード領域（８１２）に配置される。また、この時にスタックの切り替えも同時に起こり、新たなスタックは、ＣＰＵディスパッチエージェントスタック領域（８１１）に配置される。これらの領域は、物理メモリ（保護領域）（１１２）に配置される。
【００５６】
ＣＰＵプリエンプト要求発行は、プリエンプト対象の物理ＣＰＵ（１１１）への割り込み通知により行われる。プリエンプト対象の物理ＣＰＵ（１１１）に対する割り込みの発生後は、上記と同様に、割り込みハンドラテーブル（８０１）の参照、ジャンプ、スタック切り替えが起こり、ＣＰＵディスパッチエージェント（１２６）が起動される。
【００５７】
ＣＰＵディスパッチエージェント（１２６）がプリエンプト処理を完了すると、ＣＰＵスケジューラ（１２１）にトラップリターンにより制御が戻る。この後に実行される処理のコードは、ＣＰＵスケジューラコード領域（２）（８１４）に配置される。また、この際、使用スタックも、ＣＰＵスケジューラスタック領域（８１５）にあるスタックに変更される。これらの領域は、物理メモリ（１１３）上にある。
【００５８】
ＣＰＵディスパッチエージェント（１２６）が、ディスパッチ処理を完了すると、以降、ディスパッチされた物理ＣＰＵ（１１１）はハイパバイザエージェント（１０２）及び第１のゲストＯＳ（１０３）が占有実行するため、ＣＰＵスケジューラ（１２１）には制御は戻らない。上記プリエンプト処理完了により、ＣＰＵスケジューラ（１２１）に制御が戻る。
【００５９】
図９は、アドレス変換テーブル（１３４）の構成を示す。
【００６０】
アドレス変換テーブル（１３４）は、エントリ（レコード）毎に、エントリが有効か無効かを示す値（Ｖ）（９０１）を格納するフィールドと、ページの割当先のゲストＯＳの番号を表すゲストＯＳ番号（９０２）のフィールドと、ゲストＯＳから指定されるページ番号を表すゲスト物理ページ番号（９０３）のフィールドと、ゲスト物理ページ番号に対応付けられたホスト物理ページ番号（９０４）のフィールドとを有する。
【００６１】
図１０は、ＣＰＵ利用履歴管理テーブル（１００１）の構成を示す。
【００６２】
ＣＰＵ利用履歴管理テーブル（１００１）は、ＣＰＵスケジューラ（１２１）により管理されるテーブルであり、例えば、物理メモリ１１３に配置される。ＣＰＵ履歴管理テーブル（１００１）は、ゲストＯＳ毎に、ゲストＯＳ番号（１０１１）、最小ＣＰＵ量（１０１２）、最大ＣＰＵ量（１０１３）及び割り当てＣＰＵ累計（１０１４）のそれぞれのフィールドを有する。ゲストＯＳ番号（１０１１）は、ゲストＯＳの番号を表し、最小ＣＰＵ量（１０１２）は、そのゲストＯＳに割り当てられるＣＰＵ量の下限値を表し、最大ＣＰＵ量（１０１３）は、そのゲストＯＳに割り当てられるＣＰＵ量の上限値を表し、割り当てＣＰＵ累計（１０１４）は、割り当てられているＣＰＵ量の累積値を表す。ＣＰＵ量は、例えば、物理ＣＰＵの数でよい。最小ＣＰＵ量（１０１２）及び最大ＣＰＵ量（１０１３）の組合せは、ゲストＯＳに割り当てられるＣＰＵの量の範囲を表す。
【００６３】
図１１は、メモリ利用履歴管理テーブル（１１０１）の構成を示す。
【００６４】
メモリ利用履歴管理テーブル（１１０１）は、メモリスケジューラ（１２２）により管理されるテーブルであり、例えば、物理メモリ１１３に配置される。メモリ利用履歴管理テーブル（１１０１）は、ゲストＯＳ毎に、ゲストＯＳ番号（１１１１）、最小メモリ量（１１１２）、最大メモリ量（１１１３）及び割り当てメモリ累計（１１１４）のそれぞれのフィールドを有する。ゲストＯＳ番号（１１１１）は、ゲストＯＳの番号を表し、最小メモリ量（１１１２）は、そのゲストＯＳに割り当てられるメモリ量の下限値を表し、最大メモリ量（１１１３）は、そのゲストＯＳに割り当てられるメモリ量の上限値を表し、割り当てメモリ累計（１１１４）は、割り当てられているメモリ量の累積値を表す。メモリ量は、例えば、ページの数、又は、ページの総容量でよい。最小メモリ量（１１１２）及び最大メモリ量（１１１３）の組合せは、ゲストＯＳに割り当てられるメモリの量の範囲を表す。
【００６５】
ＣＰＵ履歴管理テーブル（１００１）及びメモリ履歴管理テーブル（１１０１）は、それぞれ、不揮発領域（１１４）に格納される。テーブル（１００１）／（１１０１）は、ＣＰＵ／メモリの各ゲストＯＳに割り当て可能な最大／最小の資源量、及び、割り当てられている資源の総量（累計）を表す。ＣＰＵスケジューラ（１２１）／メモリスケジューラ（１２２）は、資源スケジューリングを行う際に、テーブル（１００１）／（１１０１）に登録されている最大／最小の資源量を参照し、それを超える／下回るスケジューリングを実行しようとしている場合、当該割り当てを中止する。また、ゲストＯＳ毎に割り当て資源量（累計）が管理されているため、資源利用実績に応じた課金が可能である。
【００６６】
図１２は、ＣＰＵスケジューラ（１２１）の定期起動による動作フローを示す。
【００６７】
ステップ１２０１にて、ＣＰＵスケジューラ（１２１）は、ＣＰＵ利用履歴管理テーブル（１００１）の更新処理を行う。具体的には、例えば、ＣＰＵスケジューラ（１２１）は、ＣＰＵ割当て状態テーブル（１３２）を参照し、各ゲストＯＳについて、割り当てＣＰＵ数を算出する。そして、ＣＰＵスケジューラ（１２１）は、各ゲストＯＳについて、ＣＰＵ利用履歴管理テーブル（１００１）の割り当てＣＰＵ累計（１０１４）に、算出した割り当てＣＰＵ数を加える。この処理により、ＣＰＵ利用実績の累計値を管理でき、この累計値に応じた課金等が可能になる。
【００６８】
以下、説明を分かり易くするために、資源がディスパッチ又はプリエンプトされるゲストＯＳである対象ゲストＯＳを、「第１のゲストＯＳ」とする。
【００６９】
ステップ１２０２にて、ＣＰＵスケジューラ（１２１）は、第１のゲストＯＳに対するスケジューリング対象ＣＰＵ（ディスパッチ又はプリエンプトされる物理ＣＰＵ）を決定する。この決定の際に、ＣＰＵスケジューラ（１２１）は、ＣＰＵ利用履歴管理テーブル（１００１）から、第１のゲストＯＳ（１０３）について、ＣＰＵ量範囲（最小ＣＰＵ量（１０１２）及び最大ＣＰＵ量（１０１３）の組合せ）を特定する。そして、第１のゲストＯＳ（１０３）に対応した割り当てＣＰＵ累計（１０１４）に、スケジューリング対象ＣＰＵの量を加える又は減らすと、特定したＣＰＵ量範囲の上限を超える、又は、特定したＣＰＵ量範囲の下限を下回る場合、ＣＰＵスケジューラ（１２１）は、当該割り当てを中止する。
【００７０】
ステップ１２０３にて、ＣＰＵスケジューラ（１２１）は、ステップ１２０２にて決定したスケジューリング状態（第１のゲストＯＳ（１０３）とスケジューリング後の物理ＣＰＵとの組合せ）と、ＣＰＵ割当て状態テーブル（１３２）とを比較することにより、割当てに変化があるか否か（第１のゲストＯＳと物理ＣＰＵの組合せに変更があるか否か）を判定する。
【００７１】
変化がなければ、ＣＰＵスケジューラ（１２１）は、ステップ１２０４にて処理を終了する。
【００７２】
変化があれば、ＣＰＵスケジューラ（１２１）は、ステップ１２０５にて、ＣＰＵ割当て状態テーブル（１３２）を更新、具体的には、例えば、第１のゲストＯＳ（１０３）に対応した割り当て先（４０２）を「＃」に更新する。
【００７３】
さらにステップ１２０６にて、ＣＰＵスケジューラ（１２１）は、要求ログテーブル（１３１）の更新を行う。具体的には、例えば、ＣＰＵスケジューラ（１２１）は、資源種別（３０１）として「ＣＰＵ」を設定し、番号（３０２）として第１のゲストＯＳ（１０３）についてのスケジューリング対象ＣＰＵ（１１１）の番号を設定し、旧状態（３０３）及び新状態（３０４）として、スケジューリング実行前後で当該物理ＣＰＵ（１１１）を占有すべきゲストＯＳの番号を設定し、処理状態（３０６）として「処理中」を設定する。
【００７４】
ステップ１２０７にて、ＣＰＵスケジューラ（１２１）は、ＣＰＵディスパッチエージェント（１２６）に発行する必要のある要求がディスパッチかプリエンプトかの判別を行う。要求がディスパッチ要求であれば、ステップ１２０９に進み、要求がプリエンプト要求であれば、ステップ１２０８に進む。
【００７５】
ステップ１２０８にて、ＣＰＵスケジューラ（１２１）は、スケジューリング対象ＣＰＵ（１１１）に対する割り込み通知を行う。スケジューリング対象ＣＰＵ（１１１）上で動作している第１のゲストＯＳ（１０３）及びハイパバイザエージェント（１０２）は、動作を中断し、以降、ＣＰＵディスパッチエージェント（１３０）に制御が渡る。またスタック変更も行われ、ＣＰＵディスパッチエージェントスタック領域（８１１）をスタックとして利用した動作が行われる。そして、ステップ１２１２に進む。
【００７６】
ステップ１２０９にて、ＣＰＵスケジューラ（１２１）は、キャッシュ／ＴＬＢ（Translation  Lookaside  Buffer）のフラッシュ処理、具体的には、キャッシュ／ＴＬＢのフラッシュ（キャッシュ及びＴＬＢ内のデータを所定の格納先（例えば不揮発領域１１４）へ吐き出す処理）を指示する特権命令の発行を行う。この特権命令は、現在の物理ＣＰＵ（１１１）（ハイパバイザ１０１を実行する物理ＣＰＵ（１１１））が受けて、その物理ＣＰＵ（１１１）が、キャッシュ／ＴＬＢのフラッシュを行う。ここでのキャッシュ及びＴＬＢは、物理メモリ１１３内の領域でよい。
【００７７】
ステップ１２１０にて、ＣＰＵスケジューラ（１２１）は、第１のコンテキスト保存領域（６０１）への実行コンテキストの退避を行う。実行コンテキストは、例えば、現在の物理ＣＰＵ（１１１）（ハイパバイザ１０１を実行する物理ＣＰＵ（１１１））のレジスタ（１１５）の値を格納する。
【００７８】
ステップ１２１１にて、ＣＰＵスケジューラ（１２１）は、トラップ命令を発行する。これにより、実行している物理ＣＰＵ（１１１）上でＣＰＵディスパッチエージェント（１３０）が動作しはじめる。この際、使用スタック領域も変更され、以降のＣＰＵディスパッチエージェント（１３０）の処理は、ＣＰＵディスパッチャエージェントスタック領域（８１１）のスタックを使用しながら動作する。
【００７９】
ステップ１２１２にて、ＣＰＵスケジューラ（１２１）は、処理を完了する。
【００８０】
図１３は、ＣＰＵディスパッチエージェント（１２６）からのトラップリターンを契機に起動したＣＰＵスケジューラ（１２１）の動作フローを示す。
【００８１】
ステップ１３０１にて、ＣＰＵスケジューラ（１３０１）は、hlt命令を発行する。本hlt命令発行により、後述する再起動制御（１２３）による割り込み通知が発行されるまで、ＣＰＵスケジューラ（１３０１）は、待つ。ＣＰＵディスパッチャエージェント（１２６）が物理ＣＰＵ（１１１）のディスパッチ／プリエンプト処理代行を行っている最中にハイパバイザ（１０１）の障害によりハイパバイザ（１０１）が再起動する可能性がある。この場合、ステップ１２１０で退避されたコンテキストも無効になる。このコンテキスト回復前にこの待ち合わせを行うことで、この無効コンテキストの使用を回避し、ハイパバイザ（１０１）の再起動後の動作継続が可能である。
【００８２】
ステップ１３０２にて、ＣＰＵスケジューラ（１２１）は、ハイパバイザコンテキスト保存領域（３０１）からコンテキストを回復する。これにより、当該領域（３０１）内のコンテキストが有する各値が、物理ＣＰＵ（１１１）（ハイパバイザ１０１を実行する物理ＣＰＵ（１１１））のレジスタ（１１５）にロードされる。これ以降、当該物理ＣＰＵをハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）が専有し、動作を行う。
【００８３】
ステップ１３０３にて、ＣＰＵスケジューラ（１２１）は、処理を完了する。
【００８４】
さて、ＣＰＵディスパッチエージェント（１２６）は、定期的に要求ログテーブル（１３１）を参照することによりディスパッチ要求を検知した場合（ディスパッチの場合）、もしくは、ＣＰＵスケジューラ（１２９）からの割り込み通知を受信した場合（プリエンプトの場合）、動作を開始する。ＣＰＵのディスパッチ要求が検知された場合、図１４が示す動作フローが行われ、ＣＰＵのプリエンプト要求が検知された場合、図１５が示す動作フローが行われる。
【００８５】
図１４は、ＣＰＵのディスパッチ要求を検知したＣＰＵディスパッチエージェント（１２６）とゲストＣＰＵスケジューラ（１２９）の動作フローを示す。
【００８６】
図１４では、ステップ１４０１にて、ＣＰＵディスパッチエージェント（１２６）は、第２のコンテキスト保存領域（７０１）からコンテキストを回復する。具体的には、例えば、ＣＰＵディスパッチエージェント（１２６）は、第２のコンテキスト保存領域（７０１）内のコンテキストが有する各値を、物理ＣＰＵ（１１１）のレジスタ（１１５）にロードする。その物理ＣＰＵ（１１１）は、ハイパバイザエージェント（１０２）を実行する物理ＣＰＵ（１１１）、言い換えれば、第１のゲストＯＳ１０３を実行する物理ＣＰＵ（１１１）である。
【００８７】
ステップ１４０２にて、ＣＰＵディスパッチエージェント（１２６）は、第１のゲストＯＳ（１０３）のゲストＣＰＵスケジューラ（１２９）に対して、ＣＰＵの構成情報を更新する要求であるＣＰＵ更新要求を送信する。
【００８８】
ステップ１４０３にて、ゲストＯＳスケジューラ（１２９）が、そのＣＰＵ更新要求を受信する。この際に、ディスパッチ対象となる物理ＣＰＵ（１１１）の番号が、ゲストＯＳスケジューラ（１２９）に通知される。具体的には、例えば、ＣＰＵ更新要求が、ディスパッチ対象となる物理ＣＰＵ（１１１）の番号を含んでいてもよいし、ディスパッチ対象となる物理ＣＰＵ（１１１）の番号が、その要求と共にゲストＯＳスケジューラ（１２９）に通知されてもよい。
【００８９】
ステップ１４０４にて、ゲストＣＰＵスケジューラ（１２９）は、第１のゲストＯＳ（１０３）のスケジューリング対象のＣＰＵリストに、通知された物理ＣＰＵ番号を加える。以降、当該物理ＣＰＵ（１１１）を、第１のゲストＯＳ（１０３）が利用することが可能になる。
【００９０】
ステップ１４０５にて、ゲストＣＰＵスケジューラ（１２９）は、ＣＰＵ更新の完了をＣＰＵディスパッチエージェント（１２６）に対して送信する。
【００９１】
ステップ１４０６にて、ＣＰＵディスパッチエージェント（１２６）が、上記完了を受信する。
【００９２】
ステップ１４０７にて、ＣＰＵディスパッチエージェント（１２６）が、要求ログテーブル（１３１）の更新、具体的には、例えば、検知されたＣＰＵディスパッチ要求に対応した処理状態（３０６）の値を「完了」に更新する。
【００９３】
そして、ステップ１４０８にて、ＣＰＵディスパッチエージェント（１２６）が、処理を完了する。
【００９４】
図１５は、ＣＰＵのプリエンプト要求を検知したＣＰＵディスパッチエージェント（１２６）とゲストＣＰＵスケジューラ（１２９）の動作フローを示す。
【００９５】
ステップ１５０１にて、ＣＰＵディスパッチエージェント（１２６）は、第１のゲストＯＳ（１０３）のゲストＣＰＵスケジューラ（１２９）に対し、ＣＰＵ更新要求を送信する。
【００９６】
ステップ１５０２にて、ゲストＣＰＵスケジューラ（１２９）が、ＣＰＵ更新要求を受信する。この際、図１４と同様の方法で、プリエンプト対象となる物理ＣＰＵ（１１１）の番号がゲストＣＰＵスケジューラ（１２９）に通知される。
【００９７】
ステップ１５０３にて、ゲストＣＰＵスケジューラ（１２９）は、第１のゲストＯＳ（１０３）のスケジューリング対象のＣＰＵリストから、通知された物理ＣＰＵ番号を削除する。以降、当該物理ＣＰＵ（１１１）を、第１のゲストＯＳ（１０３）を利用できない。
【００９８】
ステップ１５０４にて、ゲストＣＰＵスケジューラ（１２９）が、ＣＰＵ更新の完了をＣＰＵディスパッチエージェント（１２６）に対して送信する。
【００９９】
ステップ１５０５にて、ＣＰＵディスパッチエージェント（１２６）が、上記完了を受信する。
【０１００】
ステップ１５０６にて、ＣＰＵディスパッチエージェント（１２６）が、要求ログテーブル（１３１）の更新、具体的には、例えば、検知されたＣＰＵプリエンプト要求に対応した処理状態（２０６）の値を「完了」に更新する。
【０１０１】
ステップ１５０７にて、ＣＰＵディスパッチエージェント（１２６）が、第２のコンテキスト保存領域（７０１）へのコンテキストの退避を行う。具体的には、例えば、ＣＰＵディスパッチエージェント（１２６）が、物理ＣＰＵ（１１１）のレジスタ（１１５）に記録されている値を含んだコンテキストを、第２のコンテキスト保存領域（７０１）に格納する。その物理ＣＰＵ（１１１）は、ハイパバイザエージェント（１０２）を実行する物理ＣＰＵ（１１１）、言い換えれば、第１のゲストＯＳ１０３を実行する物理ＣＰＵ（１１１）である。
【０１０２】
ステップ１５０８にて、ＣＰＵディスパッチエージェント（１２６）が、トラップリターン命令（図８参照）を発行する。本トラップリターン命令発行により、スタックが切り替わり、以降動作するＣＰＵスケジューラ（１２１）はＣＰＵスケジューラスタック領域（８１５）を利用して動作するようになる。
【０１０３】
ステップ１５０９にて、動作が完了する。
【０１０４】
図１６は、メモリスケジューラ（１２２）の動作フローを示す。メモリスケジューラは定期動作する。
【０１０５】
ステップ１６０１にて、メモリスケジューラ（１２２）は、メモリ利用履歴管理テーブル（１１０１）の更新処理を行う。具体的には、例えば、メモリスケジューラ（１２２）は、メモリ割り当て状態テーブル（１３３）を参照し、各ゲストＯＳについて、割り当てメモリ量を算出する。そして、メモリスケジューラ（１２２）は、各ゲストＯＳについて、メモリ用履歴管理テーブル（１１０１）の割り当てメモリ累計（１１１４）に、算出された割り当てメモリ量を加える。この処理により、メモリ利用実績の累計値を管理でき、この累計値に応じた課金等が可能になる。
【０１０６】
ステップ１６０２にて、メモリスケジューラ（１２２）が、第１のゲストＯＳ対するスケジューリング対象メモリ領域（ディスパッチ又はプリエンプトされるメモリ領域（ページ））を決定する。この決定の際に、メモリスケジューラ（１２２）は、メモリ利用履歴管理テーブル（１１０１）から、第１のゲストＯＳ（１０３）について、メモリ量範囲（最小メモリ量（１１１１）及び最大メモリ量（１１１２）の組合せ）を特定する。そして、第１のゲストＯＳ（１０３）に対応した割り当てメモリ累計（１１１４）に、スケジューリング対象メモリ領域の量を加える又は減らすと、特定したメモリ量範囲の上限を超える、又は、特定したメモリ量範囲の下限を下回る場合、メモリスケジューラ（１２２）は、当該割り当てを中止する。
【０１０７】
ステップ１６０３にて、メモリスケジューラ（１２２）が、第１のゲストＯＳへのメモリ割り当て量の変更があるか否かをチェックする。
【０１０８】
変更がなければ、ステップ１６０４にて、メモリスケジューラ（１２２）が、処理を完了する。
【０１０９】
変更があれば、ステップ１６０５にて、メモリスケジューラ（１２２）が、メモリ割り当て状態テーブル（１３３）の更新を行う。メモリスケジューラ（１２２）は、発行する要求が、第１のゲストＯＳ（１０３）へのメモリディスパッチ（割り当てメモリ量の増大）が必要であれば、割り当て対象となるメモリ領域（物理ページ）を決定する。当該物理ページは、割り当て先がなく空き状態になっている物理ページ、又は、第２のゲストＯＳ（１０４）に割り当てられている物理ページのうちプリエンプト可能なページである。そして、当該物理ページについて、メモリ割り当て状態テーブル（１３３）に、ゲスト物理ページ番号（５０２）及び割り当て先（５０３）がそれぞれ「＃」に更新される。一方、発行する要求が、第１のゲストＯＳへのプリエンプト要求やアドレス変更要求である場合には、本ステップでの更新処理は行わない。
【０１１０】
ステップ１６０６にて、メモリスケジューラ（１２２）が、要求ログテーブル（１３１）への登録処理を行う。具体的には、例えば、メモリスケジューラ（１２２）が、要求に対応した資源種別（３０１）及び処理状態（３０６）を、それぞれ、「メモリ」及び「処理中」に更新する。要求が、第１のゲストＯＳ（１０３）へのメモリディスパッチ要求であれば、番号（３０２）は、対象となる物理ページ番号であり、旧状態（３０３）及び新状態（３０４）は、それぞれ、ディスパッチ処理前後で当該物理ページが割り当てられるゲストＯＳの番号である。要求が、第１のゲストＯＳ（１０３）へのメモリプリエンプト要求であれば、旧状態（３０３）及び新状態（３０４）は、それぞれ、ディスパッチ処理前後で当該物理ページが割り当てられるゲストＯＳの番号である。
【０１１１】
ステップ１６０７にて、処理が完了する。
【０１１２】
図１７は、メモリディスパッチエージェント（１２５）及びゲストメモリスケジューラ（１２８）の動作フローを示す。
【０１１３】
ステップ１７０１にて、メモリディスパッチエージェント（１２５）が、要求ログテーブル（１３１）から、資源種別（３０１）が「メモリ」であり処理状態（３０６）が「処理中」である要求を抽出する。
【０１１４】
そして、ステップ１７０２にて、メモリディスパッチエージェント（１２５）が、抽出した要求（カラム）の判別を行う。番号（３０２）、旧状態（３０３）及び新状態（３０４）がすべて設定されていれば、要求はメモリディスパッチ要求であり、旧状態（３０３）及び新状態（３０４）が設定されているが番号（３０２）が設定されていなければ、要求はメモリプリエンプト要求であり、番号（３０２）及び新状態（３０４）が設定されているが旧状態（３０３）が設定されていなければ、要求はアドレス変更要求だと判別される。要求がメモリディスパッチ/プリエンプト要求であればステップ１７０３に進み、要求がアドレス変更要求であればステップ１７０８に進む。
【０１１５】
ステップ１７０３にて、メモリディスパッチエージェント（１２５）が、第１のゲストＯＳのゲストメモリスケジューラ（１２８）に対して、メモリの構成情報を更新する要求であるメモリ更新要求を送信する。
【０１１６】
ステップ１７０４にて、ゲストメモリスケジューラ（１２８）が、上記要求を受信する。
【０１１７】
ステップ１７０５にて、ゲストメモリスケジューラ（１２８）が、上記要求に応答して、第１のゲストＯＳが使用可能なゲスト物理ページ番号の一覧である物理ページリストに対しページ番号の追加/削除を行う。この際、ゲストメモリスケジューラ（１２８）が、追加/削除したいゲスト物理ページ番号を決定する。要求がメモリディスパッチ要求であれば、ゲストメモリスケジューラ（１２８）が、リストに追加するゲスト物理ページ番号を決める。要求がメモリプリエンプト要求であれば、ゲストメモリスケジューラ（１２８）が、リストから削除するゲスト物理ページ番号を決める。
【０１１８】
ステップ１７０６にて、ゲストメモリスケジューラ（１２８）が、メモリディスパッチエージェント（１２５）に対して、メモリ更新の完了を送信する。この際、ステップ１７０５で決定したゲスト物理ページ番号がメモリディスパッチエージェント（１２５）に通知される。ゲスト物理ページ番号は、完了（応答）に含まれていてもよいし、完了（応答）とは別に通知されてもよい。
【０１１９】
ステップ１７０７にて、メモリディスパッチエージェント（１２５）が、上記完了とゲスト物理ページ番号を受信する。
【０１２０】
ステップ１７０８にて、メモリディスパッチエージェント（１２５）が、アドレス変換テーブル（１３４）の更新を行う。要求がメモリディスパッチ要求の場合、メモリディスパッチエージェント（１２５）が、その要求に対応する新状態（３０４）が表すゲストＯＳ番号と、ステップ１７０７で受信したゲスト物理ページ番号と、要求に対応した番号（３０２）が表すホスト物理ページ番号（６０３）を、アドレス変換テーブル（１３４）のゲストＯＳ番号（９０２）、ゲスト物理ページ番号（９０３）及びホスト物理ページ番号（９０４）として登録し、それらが登録されたエントリ中のＶ（９０１）の値を「１」（有効）に更新する。要求がメモリプリエンプト要求の場合、メモリディスパッチエージェント（１２５）が、要求に対応した新状態（３０４）が表すゲストＯＳ番号と、ステップ１７０７で受信したゲスト物理ページ番号とをゲストＯＳ番号（９０２）及びゲスト物理ページ番号（９０３）に持つエントリをアドレス変換テーブル（１３４）から探し、見つかったエントリのＶ（９０１）の値を「０」（無効）に更新する。さらに、メモリディスパッチエージェント（１２５）が、見つかったエントリ中のホスト物理ページ番号（９０４）に対応するゲスト物理ページ番号（５０２）及び割り当て先（５０３）（図５参照）を、それぞれ「＃」に更新する。要求がアドレス変更要求の場合は、メモリディスパッチエージェント（１２５）が、要求に対応した新状態（３０４）が表すゲストＯＳ番号、要求に対応したゲスト物理ページ番号（３０５）が表すゲスト物理ページ番号、要求に対応した番号（３０２）が表すホスト物理ページ番号（６０３）を、アドレス変換テーブル（１３４）のゲストＯＳ番号（９０２）、ゲスト物理ページ番号（９０３）及びホスト物理ページ番号（９０４）として登録し、それらの値が登録されたエントリ中のＶ（９０１）の値を「１」（有効）に更新する。
【０１２１】
ステップ１７０９にて、メモリディスパッチエージェント（１２５）が、キャッシュ／ＴＬＢのパージ処理、具体的には、キャッシュ／ＴＬＢのパージ（キャッシュ及びＴＬＢ内のデータの消去）を指示する特権命令の発行を行う。この特権命令は、物理ＣＰＵ（１１１）（バイザエージェント１０を実行する物理ＣＰＵ（１１１））が受けて、その物理ＣＰＵ（１１１）が、キャッシュ／ＴＬＢのパージを行う。ここでのキャッシュ及びＴＬＢは、物理メモリ１１２（保護領域）内の領域でよい。
【０１２２】
ステップ１７１０にて、メモリディスパッチエージェント（１２５）が、要求ログテーブル（１３１）の更新を行う。具体的には、例えば、メモリディスパッチエージェント（１２５）が、要求に対応した処理状態（３０６）の値を「完了」に更新する。また、メモリディスパッチエージェント（１２５）が、ゲスト物理ページ番号（３０５）の値を、ステップ１７０６で受信した値に更新する。さらに、要求がメモリプリエンプト要求の場合は、ステップ１７０８で読み出したホスト物理ページ番号（９０４）の値が、対応する番号（３０２）として登録される。
【０１２３】
ステップ１７１１にて、処理が完了する。
【０１２４】
図１８は、特権命令実行部（１２７）及びステートレスＣＰＵエミュレータ（１２４）の動作フローを示す。
【０１２５】
ステップ１８０１にて、特権命令実行部（１２７）は、特権命令の実行を行う。この結果、物理ＣＰＵ（１１１）上でトラップが発生し、ステートレスＣＰＵエミュレータ（１２４）に制御が移る。例えば、或るベンダの物理ＣＰＵは、メモリエミュレーション機能とＣＰＵエミュレーション機能の両方を有しているが、これらの機能は両方とも有効になるか両方とも無効になるかであり、片方の機能だけを有効にすることができないものがある。本実施形態では、メモリの仮想化の実現手段として、物理ＣＰＵが有するメモリエミュレーション機能を呼び出すこと（有効にすること）があるが、メモリエミュレーション機能だけを有効にすることができないので、ＣＰＵエミュレーション機能も有効になる。これが、特権命令（実行に伴うトラップ）が生じる一例である。
【０１２６】
ステップ１８０２にて、ステートレスＣＰＵエミュレータ（１２４）は、実行中の命令を読み出す。
【０１２７】
ステップ１８０３にて、ステートレスＣＰＵエミュレータ（１２４）は、上記で読み出した命令に応じて、物理メモリ（１１２）や、物理ＣＰＵ（１１１）（第１のゲストＯＳ１０３を実行する物理ＣＰＵ（１１１））のレジスタ（１１５）の更新処理を行う。
【０１２８】
ステップ１８０４にて、ステートレスＣＰＵエミュレータ（１２４）は、トラップリターン命令を発行し、特権命令実行部（１２７）に制御を戻す。
【０１２９】
ステップ１８０５にて、特権命令実行部（１２７）は、処理を継続し、ステップ１８０６にて処理を完了する。
【０１３０】
図１９は、再起動制御（１２３）の定期動作のフローを示す。
【０１３１】
ステップ１９０１にて、再起動制御（１２３）は、要求ログテーブル（１３１）から、処理状態（３０６）が「完了」になっているエントリを探す。
【０１３２】
ステップ１９０２にて、再起動制御（１２３）は、上記のエントリが見つかったか否かを判別する。当該エントリがあれば、ステップ１９０３に進み、なければ、ステップ１９０６に進む。
【０１３３】
ステップ１９０３にて、再起動制御（１２３）は、ＣＰＵ割当て状態テーブル（１３２）及びメモリ割り当て状態テーブル（１３３）を更新する。具体的には、例えば、再起動制御（１２３）は、ステップ１９０１により見つかったエントリがＣＰＵディスパッチ/プリエンプト要求に対応したエントリの場合、当該エントリの番号（３０２）に対応する割り当て先（４０２）の値を、当該エントリの新状態（３０４）が表す値に更新する。また、例えば、再起動制御（１２３）は、ステップ１９０１により見つかったエントリがメモリディスパッチ要求に対応したエントリの場合、当該エントリの番号（３０２）に対応するエントリ中の割り当て先（５０２）の値を、当該エントリの新状態（３０４）が表す値に更新する。さらに、再起動制御（１２３）は、当該エントリの番号（３０２）に対応するエントリ中のゲスト物理ページ番号（５０２）の値を、当該エントリのゲスト物理番号（３０５）が表す値に更新する。また、例えば、再起動制御（１２３）は、ステップ１９０１により見つかったエントリがメモリプリエンプト要求に対応したエントリの場合、当該エントリの番号（３０２）に対応するエントリ中のゲスト物理ページ番号（５０２）及び割り当て先（５０３）の値をそれぞれ「Ｆ」に更新する。また、例えば、再起動制御（１２３）は、ステップ１９０１により見つかったエントリがアドレス更新要求に対応したエントリ場合、何もしないでよい。上記更新処理の後、再起動制御（１２３）は、要求ログテーブル（１３１）の当該エントリ（見つかったエントリ）を削除する。
【０１３４】
ステップ１９０４にて、再起動制御（１２３）は、ステップ１９０１で見つかったエントリに、ＣＰＵプリエンプト完了要求が含まれているか否かを判別する。含まれていれば、ステップ１９０５に進み、含まれていなければ、ステップ１９０６に進む。
【０１３５】
ステップ１９０５にて、再起動制御（１２３）は、対象となる物理ＣＰＵ（１１１）に割り込みを送信する。この割り込み送信により、ステップ１３０１にて停止しているＣＰＵスケジューラ（１２１）の動作を安全に再開させることができる。
【０１３６】
ステップ１９０６にて処理が完了する。
【０１３７】
図２０は、障害に伴うハイパバイザ再起動後の再起動制御（１２３）の動作フローを示す。
【０１３８】
ステップ２００１にて、再起動制御（１２３）は、要求ログテーブル（１３１）において、処理状態（３０６）が「処理中」のエントリがあれば、当該処理状態が「完了」になるまで待つ。
【０１３９】
ステップ２００２にて、再起動制御（１２３）は、待ちの時間長がタイムアウトになるか否かを判別する。タイムアウトになれば、ステップ２００３に進み、ならなければ、ステップ２００４に進む。
【０１４０】
ステップ２００３にて、再起動制御（１２３）は、タイムアウトが発生した要求のキャンセル処理を行う。具体的には、例えば、タイムアウトした要求がＣＰＵディスパッチ/プリエンプト要求の場合、再起動制御（１２３）は、タイムアウトした要求に対応する対象エントリ中の番号（３０２）を特定し、特定した番号（３０２）に対応する割り当て先（４０２）の値を、上記対象エントリ中の旧状態（３０３）の値に更新する。また、タイムアウトした要求がメモリディスパッチ要求の場合、再起動制御（１２３）は、タイムアウトした要求に対応する対象エントリ中の番号（３０２）を特定し、特定した番号（３０２）に対応するゲスト物理ページ番号（５０２）及び割り当て先（５０３）の値を、それぞれ「Ｆ」に更新する。タイムアウトした要求がメモリプリエンプト要求やアドレス変更要求の場合、再起動制御（１２３）は、何もしないでよい。上記キャンセル処理が完了した場合、再起動制御（１２３）は、要求ログテーブル（１３１）から、タイムアウトした要求に対応したエントリを削除する。
【０１４１】
ステップ２００４にて、再起動制御（１２３）は、ＣＰＵ/メモリ割り当て状態の更新処理を行う。本更新処理では、ステップ１９０３と同様に、要求ログテーブル（１３１）の処理状態（３０６）が「完了」になっているエントリの登録内容に従って、ＣＰＵ割当て状態テーブル（１３２）及びメモリ割り当て状態テーブル（１３３）が更新される。
【０１４２】
ステップ２００５にて、上記処理の結果を基に、再起動制御（１２３）は、ハイパバイザ（１０１）や第２のゲストＯＳ（１０４）が利用可能なＣＰＵ/メモリを確定し、この利用可能なＣＰＵ/メモリのみを使用して（言い換えれば、ハイパバイザエージェント（１０２）や第１のゲストＯＳ（１０３）が使用する資源を使用することなく）、ハイパバイザ（１０１）及び第２のゲストＯＳ（１０４）の初期化処理（ブート処理）を実行する。これにより、ハイパバイザエージェント（１０２）や第１のゲストＯＳ（１０３）に影響を与えずに、ハイパバイザ１０１）及び第２のゲストＯＳ（１０４）の再起動が可能になる。
【０１４３】
ステップ２００６にて、再起動制御（１２３）は、第１のコンテキスト保存領域（６０１）の初期化処理を行う。本初期化により、ステップ１３０２のコンテキスト回復処理を安全に行うことが保証される。
【０１４４】
以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
【符号の説明】
【０１４５】
１０１…ハイパバイザ、１０２…ハイパバイザエージェント（１０２）３…第１のゲストＯＳ、１０４…第２のゲストＯＳ、１１１…物理ＣＰＵ、１１２…物理メモリ（保護領域）、１１３…物理メモリ
【図１】
2015122007.tif 000003
【図２】
2015122007.tif 000004
【図３】
2015122007.tif 000005
【図４】
2015122007.tif 000006
【図５】
2015122007.tif 000007
【図６】
2015122007.tif 000008
【図７】
2015122007.tif 000009
【図８】
2015122007.tif 000010
【図９】
2015122007.tif 000011
【図１０】
2015122007.tif 000012
【図１１】
2015122007.tif 000013
【図１２】
2015122007.tif 000014
【図１３】
2015122007.tif 000015
【図１４】
2015122007.tif 000016
【図１５】
2015122007.tif 000017
【図１６】
2015122007.tif 000018
【図１７】
2015122007.tif 000019
【図１８】
2015122007.tif 000020
【図１９】
2015122007.tif 000021
【図２０】
2015122007.tif 000022
【国際調査報告】
2015122007.tif 000023
2015122007.tif 000024
2015122007.tif 000025
2015122007.tif 000026