(57)【要約】【課題】  親ＶＭＭの上で子ＶＭＭを稼動させる２レベル仮想計算機システムに於いて、ＣＰＵの半導体量及び消費電力の増加抑制と高性能を両立する。【解決手段】  ＣＰＵのＶＭＭアシスト機能を制御するＶＭＣＳ及びＶＭＣＢのフィールド更新の頻度は一様ではなく、エミュレーション結果の反映を要するＧフィールドは、Ｃフィールドより更新頻度が高い。またアシスト機能の拡張に半導体量及び消費電力については、条件判断に使用されるＣフィールドの方が、値を保持するだけのＧフィールドよりＣＰＵ動作に与える影響が大きいため、増加しやすいと考えられる。そこで、更新頻度が高く、アシスト機能拡張に伴う半導体量及び消費電力の増加が少ないＧフィールド関連のイベントは、アシスト機能を拡張してＣＰＵで対処する。一方、Ｃフィールド関連のイベントは、親ＶＭＭで対処する。【選択図】  図１
2011008559.tif 000002
【特許請求の範囲】
【請求項１】
物理ＣＰＵと記憶部とを備える物理計算機上で実行される複数の仮想計算機を提供する仮想計算機システムにおける制御方法であって、
前記仮想計算機システムは、
前記物理計算機上で動作して、前記仮想計算機を提供する第１の仮想マシンモニタと、
前記仮想計算機上で動作して、ユーザープログラムを実行する第２の仮想マシンモニタとを有し、
前記第２の仮想マシンモニタは、
前記ユーザープログラムの動作中に、前記第２の仮想マシンモニタを呼び出す条件となるイベントを規定する第１のデータ構造と、
前記ユーザープログラムの中断／再開に際して、物理ＣＰＵ状態の退避／回復先となる第３のデータ構造とを有し、
前記第１の仮想マシンモニタは、
前記ユーザープログラムの動作中に、前記第１の仮想マシンモニタを呼び出す条件となるイベントを規定する第２のデータ構造と、
前記第１のデータ構造及び前記第２のデータ構造を、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造とし、前記第３のデータ構造を、前記物理ＣＰＵが更新処理をするデータ構造として管理するフィールド区分表とを有し、
前記第２の仮想マシンモニタが前記データ構造を更新するに際し、
前記第１のデータ構造を更新する場合、
動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、前記フィールド区分表に基づき前記第１の仮想マシンモニタを呼び出し、
前記呼び出された第１の仮想マシンモニタは、前記第１のデータ構造を更新し、更新された第１のデータ構造に規定されるイベントの全てを前記第２のデータ構造に加え、
前記第３のデータ構造を更新する場合、
前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、前記フィールド区分表に基づき前記第３のデータ構造を更新する
ことを特徴とする仮想計算機システムにおける制御方法。
【請求項２】
前記フィールド区分表は、前記記憶部における第１のデータ構造のアドレスおよび第３のデータ構造のアドレスを保持し、
前記第２の仮想マシンモニタが前記データ構造を更新するに際し、前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、
前記フィールド区分表を参照して、更新の対象とされているデータ構造のアドレスが、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造のアドレス又は前記物理ＣＰＵが更新処理をするデータ構造のアドレスのうち、何れであるかを判定する
ことを特徴とするを請求項１記載の仮想計算機システムにおける制御方法。
【請求項３】
前記第１の仮想マシンモニタは、更に、
前記第２の仮想マシンモニタの動作中に、前記第１の仮想マシンモニタを呼び出す条件となるイベントを規定する第４のデータ構造と、
前記第２の仮想マシンモニタの中断／再開に際して、ＣＰＵ状態の退避／回復先となる第５のデータ構造とを有し、
前記フィールド区分表は、前記第１のデータ構造、前記第２のデータ構造及び前記第４のデータ構造を、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造とし、前記第３のデータ構造及び第５のデータ構造を、前記物理ＣＰＵが更新処理をするデータ構造として管理するフィールド区分表であり、
前記第４のデータ構造に、イベントとして前記第２の仮想マシンモニタによるＯＳ再開が含まれている場合、
前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵが、前記フィールド区分表に基づき前記第１の仮想マシンモニタを呼び出し、
前記呼び出された第１の仮想マシンモニタが、第１のデータ構造に規定されるイベントの全て及び第４のデータ構造に規定されるイベントの全てを前記第２のデータ構造に加え、
前記ユーザープログラムの動作中に、前記第２のデータ構造に記載のイベントが生じた場合、
前記ユーザープログラム動作中のＣＰＵ状態を、前記第３のデータ構造に退避し、
前記第１のデータ構造に記載のイベントが生じた場合、
前記第４のデータ構造及び前記第５のデータ構造を活性化して前記第２の仮想マシンモニタの動作を再開させ、
前記第２の仮想マシンモニタの動作中に、前記第４のデータ構造に記載のイベントが生じた場合、
前記第２の仮想マシンモニタ動作中のＣＰＵ状態を前記第５のデータ構造に退避し、
前記第２の仮想マシンモニタが前記ユーザープログラムの動作を再開させる場合、
前記第２のデータ構造及び前記第３のデータ構造を活性化して前記ユーザープログラムの動作を再開させる
ことを特徴とする請求項１に記載の仮想計算機システムにおける制御方法。
【請求項４】
前記第１のデータ構造が更新された場合、
前記第２の仮想マシンモニタから前記ユーザープログラムへの制御移行イベントを、前記第４のデータ構造に加え、
前記第２の仮想マシンモニタから前記ユーザープログラムへの制御移行時に、
前記第１のデータ構造に含まれるイベントを全て含む様に、前記第２のデータ構造を更新する手順を含む請求項３記載の仮想計算機システムにおける制御方法。
【請求項５】
前記ＣＰＵは、
前記第１の仮想マシンモニタを呼び出す条件を格納したメモリのアドレスを活性化する第１の手段と、
前記第１の仮想マシンモニタの呼び出しに際して、ＣＰＵ状態の退避／回復先となる領域のメモリアドレスを活性化する第２の手段とを有し、
前記第２の仮想マシンモニタは、前記第３のデータ構造を含み、
前記ユーザープログラムの動作開始時に、
前記第２のデータ構造を前記第１の手段で活性化させる手順と、
前記第３のデータ構造を前記第２の手段で活性化させる手順と、
前記第２の仮想マシンモニタの動作開始時に、
前記第４のデータ構造を前記第１の手段で活性化させる手順と、
前記第５のデータ構造を前記第２の手段で活性化させる手順と、
前記第２の仮想マシンモニタが前記第３のデータ構造を読み書きする命令を実行する際に、前記第３のデータ構造を読み書きさせる手順と、
を含む請求項３記載の仮想計算機システムにおける制御方法
【請求項６】
前記第１の仮想マシンモニタは、
前記第２のデータ構造と前記第３のデータ構造を含む第１の記憶部領域と、
前記第４のデータ構造と前記第５のデータ構造を含む第２の記憶部領域とを含み、
前記第２の仮想マシンモニタは、
前記ユーザープログラムの中断／再開に際してＣＰＵ状態の退避／回復先となる第６のデータ構造と、
前記第１のデータ構造と前記第６のデータ構造を含む第３の記憶部領域とを含み、
前記ＣＰＵは、
前記第１の仮想マシンモニタを呼び出す条件及び前記第１の仮想マシンモニタを呼び出す際にＣＰＵ状態の退避／回復先となる領域を含む記憶部領域のアドレスを活性化する第１の手段と
前記第２の仮想マシンモニタに読み書きさせるデータ構造のアドレスを活性化する第２の手段を含み、
前記ユーザープログラムの動作開始時に、
前記第１の記憶部領域のアドレスを前記第１の手段で活性化させる手順と、
前記第２の仮想マシンモニタの動作開始時に、
前記第２の記憶部領域のアドレスを前記第１の手段で活性化させる手順と、
前記第１の記憶部領域のアドレスを前記第２の手段で活性化させる手順と、
前記第２の仮想マシンモニタが前記第６のデータ構造を読み書きする命令を実行する際に、
前記第６のデータ構造の代わりに 前記第３のデータ構造を読み書きさせる手順とを有する請求項３記載の仮想計算機システムにおける制御方法。
【請求項７】
１つ以上の物理ＣＰＵと記憶部とを備える物理計算機上で実行される複数の仮想計算機を提供する仮想計算機システムにおいて、
前記仮想計算機システムは、前記物理計算機上で動作して、前記仮想計算機を提供する第１の仮想マシンモニタと、前記仮想計算機上で動作して、１つ以上のユーザープログラムを実行する第２の仮想マシンモニタとを有し、
前記第２の仮想マシンモニタは、
前記ユーザープログラムの動作中に、前記第２の仮想マシンモニタを呼び出す条件となるイベントを規定する第１のデータ構造と、
前記ユーザープログラムの中断／再開に際して、物理ＣＰＵ状態の退避／回復先となる第３のデータ構造とを有し、
前記第１の仮想マシンモニタは、
前記ユーザープログラムの動作中に、前記第１の仮想マシンモニタを呼び出す条件となるイベントを規定する第２のデータ構造と、
前記第１のデータ構造及び前記第２のデータ構造を、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造とし、前記第３のデータ構造を、前記物理ＣＰＵが更新処理をするデータ構造として管理するフィールド区分表とを有し、
前記第２の仮想マシンモニタが前記データ構造を更新するに際し、
前記第１のデータ構造を更新する場合、
動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、前記フィールド区分表に基づき前記第１の仮想マシンモニタを呼び出し、
前記呼び出された第１の仮想マシンモニタは、前記第１のデータ構造を更新し、更新された第１のデータ構造に規定されるイベントの全てを前記第２のデータ構造に加え、
前記第３のデータ構造を更新する場合、
前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、前記フィールド区分表に基づき前記第３のデータ構造を更新することを特徴とする仮想計算機システム。
【請求項８】
前記フィールド区分表は、前記記憶部における第１のデータ構造のアドレスおよび第３のデータ構造のアドレスを保持し、
前記第２の仮想マシンモニタが前記データ構造を更新するに際し、前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、
前記フィールド区分表を参照して、更新の対象とされているデータ構造のアドレスが、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造のアドレス又は前記物理ＣＰＵが更新処理をするデータ構造のアドレスのうち、何れであるかを判定する
ことを特徴とするを請求項７記載の仮想計算機システム。
【請求項９】
前記第１の仮想マシンモニタは、更に、
前記第２の仮想マシンモニタの動作中に、前記第１の仮想マシンモニタを呼び出す条件となるイベントを規定する第４のデータ構造と、
前記第２の仮想マシンモニタの中断／再開に際して、ＣＰＵ状態の退避／回復先となる第５のデータ構造とを有し、
前記フィールド区分表は、前記第１のデータ構造、前記第２のデータ構造及び前記第４のデータ構造を、前記物理ＣＰＵにより呼び出された前記第１の仮想マシンモニタが更新処理をするデータ構造とし、前記第３のデータ構造及び第５のデータ構造を、前記物理ＣＰＵが更新処理をするデータ構造として管理するフィールド区分表であり、
前記記憶部は、前記第２のデータ構造に、前記第１のデータ構造 又は 前記第４のデータ構造 の少なくとも一方に含まれるイベントを記載させる命令と、前記第１のデータ構造に記載のイベントが生じたかを判断させる命令と、前記第１のデータ構造に記載のイベントが生じた場合に前記第４のデータ構造及び前記第５のデータ構造を活性化して前記第２の仮想マシンモニタの動作を再開させる命令とを含み、
前記第４のデータ構造に、イベントとして前記第２の仮想マシンモニタによるＯＳ再開が含まれている場合、
前記動作主体を第２の仮想マシンモニタとされている物理ＣＰＵが、前記フィールド区分表に基づき前記第１の仮想マシンモニタを呼び出し、
前記呼び出された第１の仮想マシンモニタが、第１のデータ構造に規定されるイベントの全て及び第４のデータ構造に規定されるイベントの全てを前記第２のデータ構造に加え、
前記物理ＣＰＵは、更に、
前記ユーザープログラムの動作中に前記第２のデータ構造に記載のイベントが生じたかを判断し、前記第２のデータ構造に記載のイベントが生じた場合に、前記ユーザープログラムの状態を前記第３のデータ構造に退避し、
前記第２の仮想マシンモニタの動作中に前記第４のデータ構造に記載のイベントが生じたかを判断し、前記第４のデータ構造に記載のイベントが生じた場合に、前記第２の仮想マシンモニタの状態を前記第５のデータ構造に退避し、
前記第２の仮想マシンモニタが前記ユーザープログラムの動作を再開させる場合に、前記第２のデータ構造 及び 前記第３のデータ構造を活性化して前記ユーザープログラムの動作を再開させることを特徴とする請求項７記載の仮想計算機システム。
【請求項１０】
前記物理ＣＰＵは、更に、前記第１のデータ構造が更新された場合に、前記第２の仮想マシンモニタから前記ユーザープログラムへの制御移行イベントを、前記第４のデータ構造に加え、
前記記憶部は、更に、前記第２の仮想マシンモニタから前記ユーザープログラムへの制御移行時に、前記第１のデータ構造に含まれるイベントを全て含む様に、前記第２のデータ構造を更新させる命令を含むことを特徴とする請求項７記載の仮想計算機システム
【請求項１１】
前記第２の仮想マシンモニタが、前記第３のデータ構造を含み、
前記物理ＣＰＵが更に
前記第１の仮想マシンモニタを呼び出す条件を格納したメモリのアドレスを活性化する第１の手段と、
前記第１の仮想マシンモニタの呼び出しに際して、ＣＰＵ状態の退避／回復先となる領域のメモリアドレスを活性化する第２の手段とを含み、
前記物理ＣＰＵが更に、
前記ユーザープログラムの動作開始時に、前記第２のデータ構造を前記第１の手段で活性化させ、前記第３のデータ構造を前記第２の手段で活性化させ、
前記第２の仮想マシンモニタが前記第３のデータ構造を読み書きする命令を実行する際に、前記第３のデータ構造を読み書きさせ、
前記記憶部が更に、
前記第２の仮想マシンモニタの動作開始時に、前記第４のデータ構造を前記第１の手段で活性化させ、前記第５のデータ構造を前記第２の手段で活性化させる命令を含む
ことを特徴とする請求項７記載の仮想計算機システム
【請求項１２】
前記第２の仮想マシンモニタが、
前記ユーザープログラムの中断／再開に際してＣＰＵ状態の退避／回復先となる第６のデータ構造と、
前記第１のデータ構造と前記第６のデータ構造を含む第３の記憶部領域とを含み、
前記ＣＰＵが更に、
前記第１の仮想マシンモニタを呼び出す条件及び前記第１の仮想マシンモニタを呼び出す際に物理ＣＰＵ状態の退避／回復先となる領域を含む記憶部領域のアドレスを活性化する第１の手段と、
前記第２の仮想マシンモニタによるデータ構造の読み書き対象を活性化する第２の手段とを含み、
前記記憶部が更に、
前記第２のデータ構造と前記第３のデータ構造を含む第１の記憶部領域と、
前記第４のデータ構造と前記第５のデータ構造を含む第２の記憶部領域とを含み、
前記記憶部が更に、
前記第２の仮想マシンモニタの動作開始時に、前記第２の記憶部領域を前記第１の手段で活性化させる命令と、前記第１の記憶部領域を前記第２の手段で活性化させる命令を含み、
前記物理ＣＰＵが更に、
前記ユーザープログラムの動作開始時に、前記第１の記憶部領域を前記第１の手段で活性化させ、
前記第２の仮想マシンモニタが前記第６のデータ構造を読み書きする命令を実行する際に、前記第６のデータ構造の代わりに、前記第３のデータ構造を読み書きさせる
ことを特徴とする請求項７記載の仮想計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想計算機上で仮想計算機を稼動させる２レベル仮想計算機システムに関し、仮想計算機上でＣＰＵの仮想化支援機能を、低遅延でエミュレーションする技術に関する。特に、２レベル仮想計算機に於ける仮想化支援ＣＰＵのエミュレーション性能改善方法に関する。
【背景技術】
【０００２】
サーバ台数の増加と共に運用に関する複雑さが増加しており、運用コストが問題化し、運用コストを低減する技術として複数サーバを１台にまとめるサーバ統合が注目を集めている。サーバ統合を実現する技術として、一つのコンピュータを任意の割合で論理的に分割する仮想計算機技術が知られている。仮想計算機技術では、例えば、ハイパバイザなどのファームウェア（またはミドルウェア）が、物理計算機を複数の論理区画（ＬＰＡＲ：Logical PARtition）に分割し、各ＬＰＡＲに対して計算機資源（ＣＰＵ、メモリ、Ｉ／Ｏデバイス）を割り当て、各ＬＰＡＲ上でそれぞれＯＳを動作させる。あるいは、一つのサーバ上で一つのホストＯＳ（物理計算機を直接使用するＯＳ）を実行し、このホストＯＳ上稼動するハイパバイザが同様の分割処理を行って、複数のゲストＯＳ（ホストＯＳ上で稼動するＯＳ）を稼動させる。仮想計算機技術は、従来複数のサーバで稼動していたＯＳ及びＯＳ上で稼動するソフトウェアを、１台のサーバで稼動させることを可能にしており、サーバ統合を実現している。
【０００３】
また仮想計算機技術は、汎用機（MainFrame）等の大型計算機で用いられてきた技術であるが、近年のマイクロプロセッサの性能向上に伴いローエンドサーバでも普及しつつある。仮想計算機技術を採用したサーバ等の計算機は、ゲスト（ゲストＯＳ及び、ゲストＯＳ上で稼動するソフトウェアの総称）を稼動させる複数の仮想計算機（Virtual Machine）と、仮想計算機の制御を行う仮想計算機モニタ（Virtual Machine Monitor、以下ＶＭＭとする）とを有する。
【０００４】
ローエンドサーバの中でも特に、ｘ８６ＣＰＵはＶＭＭを支援する機能を提供・拡充しており、ｘ８６ＣＰＵを搭載するｘ８６サーバは仮想計算機の性能を改善している。今後もｘ８６サーバの性能は継続的に向上すると推測され、１サーバ上で稼動できるゲスト数は増加傾向にある。
【０００５】
本傾向が進むと、障害が発生した場合に、多数のゲストが一斉に停止する懸念が生じてくる。本懸念に対しては、計算機資源（ＣＰＵ、メモリ、Ｉ／Ｏデバイス）単一のゲストに占有させて、故障時の影響範囲を最小化し、信頼性を高める占有方式が有効である。一方でＶＭＭには、計算機資源を複数のゲストで共有させる共有方式も存在する。共有方式では、計算機資源の空き時間を活用するなど、計算機資源を柔軟に割当て可能であり、利便性が向上するメリットがある。
【０００６】
信頼性と利便性はいずれも重要であるため、今後はサーバとＯＳの間で、占有方式のＶＭＭ（親ＶＭＭ）と共有方式のＶＭＭ（子ＶＭＭ）を重ねて稼動させて、信頼性と利便性のバランスを取る方法が定着していくと考えられる。本形態を２レベル仮想計算機システムと呼ぶ。しかしながら、現在のｘ８６ＣＰＵは、１レベル仮想計算機システムにのみ対応している。以下、現在のｘ８６ＣＰＵで実装されている機能の概要と、２レベル仮想計算機システムを構築する場合の問題とについて述べる。
【０００７】
現在のｘ８６ＣＰＵは、ゲストの動作を監視して特定のイベントが発生した場合に、ゲストの動作を中断してＶＭＭを呼ぶアシスト機能を備えている。本アシスト機能は、Ｉｎｔｅｌ社のＣＰＵではＶＴ（Virtualization Technology）と呼ばれ、ＡＭＤ社のＣＰＵではＳＶＭ（Secure Virtual Machine）と呼ばれる。また、本中断はＶＭＥＸＩＴと呼ばれる。
本アシスト機能では、ゲスト動作の中断・再開時に、ゲスト動作中のＣＰＵの状態をメモリに退避・回復する。ＶＭＭは本機能を利用し、ゲストが他ゲストに影響する動作(例えば電源OFF)を行う場合に、サーバの電源をOFFする代わりに当該ゲストの実行を停止させる等のエミュレーション（代替処理）を行う。エミュレーションに際して、ＶＭＭはメモリ中のゲスト状態を変更する。
【０００８】
ＶＭＭを呼ぶ条件はＶＭＭのポリシーによって異なる。例えば共有方式では、ゲストがＩ／Ｏデバイスを操作すると他のゲストに影響するため、アクセスを制限する必要がある。しかし、占有方式であれば、ゲストがＩ／Ｏデバイスを操作しても構わない。そこで、ｘ８６ＣＰＵは、ＶＭＭのポリシーの違いに対応して、ＶＭＭ呼び出し条件を、細かく設定できる。また、ゲスト状態の退避・回復に使用する領域を、指定できる。ＶＭＭ呼び出し条件、及びゲスト状態の退避・回復に使用する領域は、Ｉｎｔｅｌ社のＣＰＵではＶＭＣＳ（Virtual Machine Control Structure）と呼ばれるデータ構造に含まれ、ＣＰＵ内のＶＭＣＳポインタから参照される。同様に、ＡＭＤ社のＣＰＵでは、ＶＭＣＢ（Virtual Machine Control Block）と呼ばれるデータ構造に含まれ、ＣＰＵ内のＶＭＣＢポインタから参照される。以下では、ＶＭＭ呼び出し条件をＣ（Condition）フィールドと略記し、ゲスト状態の退避・回復に使用する領域をＧ（Guest state）フィールドと略記する。
【０００９】
現在のｘ８６ＣＰＵは、１レベル仮想計算機システムにのみ対応しているため、２レベル仮想計算機システムを構築するためには、親ＶＭＭが前記アシスト機能をエミュレーションして子ＶＭＭを動作させる（特許文献１）。親ＶＭＭは、動作主体（子ＶＭＭ／ＯＳ）に対応した２種類のＶＭＣＳ（ＡＭＤ社のＣＰＵならばＶＭＣＢが該当：以下同様）を作成・管理する。また、子ＶＭＭが作成したＶＭＣＳも必要に応じて参照・更新する。以下ではそれぞれを、子ＶＭＭ用親ＶＭＣＳ、ＯＳ用親ＶＭＣＳ、子ＶＭＣＳと呼ぶ。
【００１０】
子ＶＭＭの動作中に、子ＶＭＣＳのＣフィールド及び子ＶＭＣＳのＧフィールドが更新される。このため、親ＶＭＭは、子ＶＭＭがＯＳを再開する際に、子ＶＭＣＳのＣフィールドを包含する様にＯＳ用親ＶＭＣＳのＣフィールドを作り直し、ＯＳ用親ＶＭＣＳのＧフィールドに子ＶＭＣＳのＧフィールドをコピーする。以上の処理が完了した後で、ＯＳ用親ＶＭＣＳを用いて、ＯＳを動作させる。しかし本方法では、ＯＳ動作の再開時に、性能が低下する問題がある。
【００１１】
ここで、特許文献２には、１レベル仮想計算機システムのページテーブルに関して、動作主体（ＯＳ／アプリケーション）に対応した２種類のデータ構造を作成・管理する技術が開示されている。本技術では、ＯＳがページテーブルを更新する際に、ＶＭＭがＯＳ／アプリケーションに対応した２種類のデータ構造を更新する。動作主体を切り替える際には、データ構造の活性化のみを行い、切り替えに伴う性能低下を軽減する。この技術は１レベル仮想計算機システム向けの技術であるが、ＯＳ／アプリケーション を 子ＶＭＭ／ＯＳ と読み替え、ページテーブル を ＶＭＣＳ と読み変えると、２レベル仮想計算機システムにも適用可能である。
【００１２】
特許文献３には、メインフレームを対象に、ＣＰＵのアシスト機能を拡張して２、レベル仮想計算機システムに対応させる技術が公開されている。本技術では、親ＶＭＭが１レベル目のアシスト機能を利用して動作し、子ＶＭＭが２レベル目のアシスト機能を利用して動作する。本技術を用いると、ソフトウェア処理が不要になるため、ＯＳ動作再開時の性能低下を軽減できる。
【００１３】
特許文献４には、ｘ８６ＣＰＵを対象に、ＣＰＵのアシスト機能を拡張してマルチレベル仮想計算機システムに対応させる技術が公開されている。本技術では、親ＶＭＭが１レベル目のアシスト機能を利用し、子ＶＭＭが２レベル目のアシスト機能を利用する。本技術も、特許文献５と同様に、ソフトウェア処理がなくなるため、ＯＳ動作再開時の性能低下を軽減できる。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開2009-3749
【特許文献２】特開2007-4661
【特許文献３】米国特許5,109,489
【特許文献４】米国特許2007/28238
【特許文献５】米国特許5381535
【発明の概要】
【発明が解決しようとする課題】
【００１５】
特許文献２の技術では、子ＶＭＣＳの更新時に親ＶＭＭが動作するため、性能低下が生じる。また、ＯＳ動作の再開時にも、親ＶＭＭの処理を必要とするため、性能低下が生じる。特許文献３及び特許文献４に記載される技術では、ＣＰＵに対して、アシスト機能を新規導入する場合と同程度の、大掛かりな機能拡張を必要とする。大掛かりな機能拡張はＣＰＵに搭載する半導体量及び消費電力の増加を招く。
【００１６】
以上より従来技術では、半導体量及び消費電力の増加、子ＶＭＣＳ更新時の性能低下、ＯＳ動作再開時の性能低下のうち、少なくともいずれかの問題が発生する懸念がある。
【課題を解決するための手段】
【００１７】
上述の課題を解決するために、本願発明に係る仮想計算機および仮想計算機の制御方法では、物理ＣＰＵと記憶部（例えばメモリ）とを備える物理計算機上で実行される複数の仮想計算機を提供する仮想計算機システムにおいて、以下の制御を行う。
【００１８】
ここで、仮想計算機システムは、物理計算機上で動作して、仮想計算機を提供する第１の仮想マシンモニタ（親ＶＭＭ）と、仮想計算機上で動作して、ユーザープログラム（例えばＯＳ）を実行する第２の仮想マシンモニタ（子ＶＭＭ）とを有する。第２の仮想マシンモニタは、ユーザープログラムの動作中に、第２の仮想マシンモニタを呼び出す条件となるイベントを規定する第１のデータ構造と、ユーザープログラムの中断／再開に際して、物理ＣＰＵ状態の退避／回復先となる第３のデータ構造とを有する。第１の仮想マシンモニタは、ユーザープログラムの動作中に、第１の仮想マシンモニタを呼び出す条件となるイベントを規定する第２のデータ構造と、第１のデータ構造及び第２のデータ構造を、物理ＣＰＵにより呼び出された第１の仮想マシンモニタが更新処理をするデータ構造とし、第３のデータ構造を、物理ＣＰＵが更新処理をするデータ構造として管理するフィールド区分表とを有する。第２の仮想マシンモニタがデータ構造を更新するに際し、第１のデータ構造を更新する場合、動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、フィールド区分表に基づき第１の仮想マシンモニタを呼び出し、呼び出された第１の仮想マシンモニタは、第１のデータ構造を更新し、更新された第１のデータ構造に規定されるイベントの全てを第２のデータ構造に加える。一方、第２の仮想マシンモニタがデータ構造を更新するに際し、第３のデータ構造を更新する場合、動作主体を第２の仮想マシンモニタとされている物理ＣＰＵは、フィールド区分表に基づき第３のデータ構造を更新する。
【００１９】
本願発明によれば、半導体量及び消費電力の増加を最小限に抑えつつ、子ＶＭＣＳ更新とＯＳ動作再開とのを両方とも高速化する方法が提供できる。
【発明の効果】
【００２０】
拡張するアシスト機能がＧフィールド関連イベントに限定されるため、半導体量及び消費電力の増加を最小限に抑えられる。また、Ｃフィールドが更新されない定常状態に於いて、子ＶＭＣＳ更新とＯＳ動作再開の両方を高速化できる。
【図面の簡単な説明】
【００２１】
【図１】実施例１及び３に於ける、子ＶＭＣＳ書き込みのフローチャート
【図２】実施例１〜４に於ける、仮想計算機システムを動作させる物理計算機のブロック図
【図３】実施例１に於ける、仮想計算機システムのソフトウェアとハードウェアの要部を示すスタック図
【図４】実施例１に於ける、主記憶の内容を示すブロック図
【図５】実施例１〜４に於ける、フィールド区分表の構成図
【図６ａ】実施例１〜２に於ける、（ａ）動作主体フラグの構成図
【図６ｂ】実施例３〜４に於ける、（ｂ）動作主体フラグの構成図
【図７】実施例１〜４に於ける、仮想計算機システムの動作概要を示すフローチャート
【図８ａ】実施例１に於ける（ａ）仮想計算機初期化のフローチャート
【図８ｂ】実施例１に於ける（ｂ）親ＶＭＭ呼び出しのフローチャート、
【図８ｃ】実施例１に於ける（ｃ）仮想計算機再開のフローチャート
【図９】実施例１に於ける、ＯＳ向け処理のフローチャート
【図１０】実施例１〜２に於ける、子ＶＭＭ向け処理のフローチャート
【図１１ａ】実施例１に於ける（ａ）ＶＭＥＮＴＲＹのフローチャート
【図１１ｂ】実施例１に於ける（ｂ）ＶＭＰＴＲＬＤのフローチャート
【図１２】実施例２に於ける、仮想計算機システムのソフトウェアとハードウェアの要部を示すスタック図
【図１３】実施例２に於ける、主記憶の内容を示すブロック図
【図１４ａ】実施例２に於ける（ａ）仮想計算機初期化のフローチャート
【図１４ｂ】実施例２に於ける（ｂ）親ＶＭＭ呼び出しのフローチャート
【図１４ｃ】実施例２に於ける（ｃ）仮想計算機再開のフローチャート
【図１５】実施例２に於ける、ＯＳ向け処理のフローチャート
【図１６】実施例２に於ける、ＶＭＥＮＴＲＹのフローチャート
【図１７ａ】実施例２及び４に於ける（ａ）子ＶＭＣＳ読み出しのフローチャート
【図１７ｂ】実施例２及び４に於ける（ｂ）子ＶＭＣＳ書き込みのフローチャート
【図１８ａ】実施例２に於ける（ａ）ＶＭＣＬＥＡＲのフローチャート、
【図１８ｂ】実施例２に於ける（ｂ）ＶＭＰＴＲＬＤのフローチャート
【図１８ｃ】実施例２に於ける（ｃ）ＶＭＰＴＲＳＴのフローチャート
【図１９】実施例３に於ける、仮想計算機システムのソフトウェアとハードウェアの要部を示すスタック図
【図２０】実施例３〜４に於ける、主記憶の内容を示すブロック図
【図２１ａ】実施例３に於ける（ａ）仮想計算機初期化のフローチャート
【図２１ｂ】実施例３に於ける（ｂ）親ＶＭＭ呼び出しのフローチャート
【図２１ｃ】実施例３に於ける（ｃ）仮想計算機再開のフローチャート
【図２２】実施例３に於ける、ＯＳ向け処理のフローチャート
【図２３】実施例３〜４に於ける、子ＶＭＭ向け処理のフローチャート
【図２４】実施例３に於ける、ＶＭＲＵＮのフローチャート
【図２５】実施例４に於ける、仮想計算機システムのソフトウェアとハードウェアの要部を示すスタック図
【図２６ａ】実施例４に於ける（ａ）仮想計算機初期化のフローチャート
【図２６ｂ】実施例４に於ける（ｂ）親ＶＭＭ呼び出しのフローチャート
【図２６ｃ】実施例４に於ける（ｃ）仮想計算機再開のフローチャート
【図２７】実施例４に於ける、ＯＳ向け処理のフローチャート
【図２８】実施例４に於ける、ＶＭＲＵＮのフローチャート
【図２９ａ】実施例１及び２に於ける（ａ）ＶＭＣＳのフォーマット
【図２９ｂ】実施例３及び４に於ける（ｂ）ＶＭＣＢのフォーマット
【発明を実施するための形態】
【００２２】
まず、本願発明に関し、発明者等が見出した点について、概要を説明する。ＶＭＣＳのフィールド更新の頻度は一様ではなく、エミュレーションの結果を反映する必要のあるＧフィールドは更新頻度が高い。また、条件判断に使用されるＣフィールドは、退避先として使用されるＧフィールドよりもＣＰＵ動作に与える影響が大きいため、Ｃフィールドに対するアシスト機能の拡張は半導体量及び消費電力が増加しやすいと考えられる。
【００２３】
そこで、更新頻度が高く、アシスト機能拡張に伴う半導体量及び消費電力の増加が少ないＧフィールドに関するイベントは、ＣＰＵのみで対処する。一方、更新頻度が低く、アシスト機能拡張に伴う半導体量及び消費電力の増加が多いＣフィールドに関するイベントは、親ＶＭＭが対処する。
【００２４】
ＶＭＣＳのフィールドは各々が数バイトの大きさであり４ＫＢのメモリ領域内に多数含まれているが、従来はＣＰＵのみで対処／親ＶＭＭで対処といった処理方針を４ＫＢ毎に１種類しか定められなかった。そこで本発明では、数バイト程度の細かい単位でＣフィールドとＧフィールドを区別して処理方針を定めるフィールド区分表と、フィールド区分表を参照して処理方針を決定するフィールド判断部を導入して、各フィールドに最適な処理を選択する。また、子ＶＭＣＳのＧフィールドとＯＳ用親ＶＭＣＳのＧフィールドとして共通メモリ領域を使用する。
【００２５】
ＯＳの動作中にＯＳ用親ＶＭＣＳのＣフィールドに記載のイベントが生じた場合には、ＣＰＵ状態を共通メモリ領域のＧフィールドに退避し、親ＶＭＭを呼ぶ。親ＶＭＭは、子ＶＭＣＳのＣフィールドに記載のイベントが生じたかを判断し、子ＶＭＣＳのＣフィールドに記載のイベントが生じた場合は、子ＶＭＭ用親ＶＭＣＳを使用して子ＶＭＭの動作を再開させる。
【００２６】
子ＶＭＭが子ＶＭＣＳを更新する場合には、ＣＰＵがフィールド区分表を参照して対象フィールドを判断し、Ｇフィールドが更新される場合は、ＣＰＵが共通メモリ領域のＧフィールドを更新する。一方で、Ｃフィールドが更新される場合は、ＣＰＵが親ＶＭＭを呼ぶ。親ＶＭＭは、子ＶＭＣＳのＣフィールドを更新すると供に、子ＶＭＣＳのＣフィールドのイベントを全て含む様に、ＯＳ用親ＶＭＣＳのＣフィールドを変更し、子ＶＭＭの動作を再開させる。
【００２７】
子ＶＭＭがＯＳの動作を再開させる場合には、ＣＰＵが、ＣＰＵ状態を共通メモリ領域のＧフィールドから復元して、ＯＳの動作を再開させる。
【００２８】
以下、本発明を適用した一実施形態について、図面を参照して詳細に説明する。
【実施例１】
【００２９】
本実施例では、子ＶＭＭにＶＴ機能を利用させる。また、子ＶＭＣＳのＧフィールドをＯＳ用親ＶＭＣＳのＧフィールドと兼用し、共通メモリ領域として使用する。本実施例では、子ＶＭＭによる子ＶＭＣＳの更新は、即時又は次回のＯＳ動作再開時に、ＯＳ用親ＶＭＣＳに反映される。
【００３０】
＜１．ハードウェア構成＞
図２は、本発明の第１実施形態に於ける、２レベル仮想計算機システムを動作させる物理計算機の構成を示す。
【００３１】
物理計算機は、ＶＴ機能に対応したＣＰＵ７０を１つ以上有し、これらのＣＰＵ７０はＦＳＢ（Front Side Bus）等に代表されるＣＰＵ間インタフェース８２０を介してノースブリッジ８００（またはメモリコントローラ）に接続される。
【００３２】
ノースブリッジ８００には、メモリバス８２０を介して主記憶９０が接続され、また、バス８４０を介してＩ／Ｏデバイス８５０が接続される。Ｉ／Ｏデバイス８５０は、ＬＡＮ８６０に接続されるネットワークアダプタ、ディスク装置８７０等に接続されるＳＣＳＩアダプタ、ＳＡＮ８９０（Storage  Area  Network）に接続されるファイバーチャネルアダプタなどで構成される。ＣＰＵ７０は、ノースブリッジ８００を介してメモリにアクセスし、ノースブリッジ８００からＩ／Ｏデバイス８５０にアクセスして所定の処理を行う。なお、ノースブリッジ８００は主記憶９０を制御するとともに、グラフィックコントローラを含んでコンソール８０にも接続され、画像の表示を行うことができる。主記憶９０には、２レベル仮想計算機システムの親ＶＭＭ２０（Virtual Machine Monitor）がロードされ、この親ＶＭＭ２０が実現する仮想計算機３０が、子ＶＭＭ４０を実行する。子ＶＭＭは仮想計算機３０上で、任意のＯＳ５０とＡＰ６０（Application）を実行する。
【００３３】
＜２．ソフトウェア構成＞
次に、物理計算機１０上で仮想計算機３０を実現するソフトウェアの構成の主要部と、制御対象となるハードウェア要素について、図３を参照しながら詳述する。
【００３４】
物理計算機１０は、１つ以上のＣＰＵ７０を搭載する。ＣＰＵ７０は、ＶＴ機能に対応したＣＰＵであり、ＶＴ機能を制御するデータ構造であるＶＭＣＳ（Virtual Machine Control Structure）を参照して動作する。ＶＴ機能ではＶＭＣＳを１つだけ活性化させる仕様であるが、本実施例ではＣＰＵ７０の機能を拡張し、用途の異なる４種類のＶＭＣＳのアドレスを保持させる。
【００３５】
ＧＲフィールドポインタ６００は、ゲスト動作時の状態を退避・回復するＧ（Guest state）フィールドとＶＭＭ呼び出しの原因となるイベントの情報を保持するＲ（exit Reason）フィールドを含むＶＭＣＳのアドレスを保持する。ＣＨフィールドポインタ６１０は、親ＶＭＭ呼び出し条件を保持するＣ（Condition）フィールドと、ホスト動作の初期状態を保持するＨ（Host state）フィールドを含むＶＭＣＳのアドレスを保持する。ＧＲスタンバイポインタ６２０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＧフィールド及びＲフィールドを含むＶＭＣＳのアドレスを保持する。ＣＨスタンバイポインタ６３０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＣフィールド及びＨフィールドを含むＶＭＣＳのアドレスを保持する。
【００３６】
ＶＭＥＸＩＴ判断部７００は、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作を監視し、CＨフィールドポインタ６１０の保持するアドレスに規定された親ＶＭＭ呼び出し条件が満たされたか否かを判断する。動作主体フラグ７１０は、ＣＰＵ７０上で稼動するソフトウェアが、親ＶＭＭ２０／子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれであるかを管理する。フィールド判断部７２０は、子ＶＭＭがＶＭＣＳのフィールドを更新する場合に、対象が、親ＶＭＭに変更を通知すべきフィールドであるかを判断する。ＶＭＭ支援命令処理部７３０は、ＶＭＣＳを参照／更新するＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ、ＶＭＣＳのアドレスを登録／参照するＶＭＰＴＲＬＤ／ＶＭＰＴＲＳＴ、ＶＭＣＳを用いてＯＳ５０及びＡＰ６０の動作を開始／再開するＶＭＬＡＵＮＣＨ／ＶＭＲＥＳＵＭＥ、ＶＭＣＳを最新の状態に更新するＶＭＣＬＥＡＲの各命令を処理する。
【００３７】
物理計算機１０上では、１つ以上の仮想計算機３０を管理する親ＶＭＭ２０が稼動する。親ＶＭＭ２０は、エミュレータ３００と、フィールド区分表４００と、仮想計算機に割り当てる仮想的なＣＰＵ毎に、ＣＰＵ仮想化データ２１０を保持する。
【００３８】
エミュレータ３００は、子ＶＭＭが実行するＶＭＭ支援命令を処理する子ＶＭＭ支援命令処理部３１０と、親ＶＭＭが呼び出された場合に、親ＶＭＭの呼び出しと子ＶＭＭ呼び出しのどちらを優先するか判断する呼び出し優先度判断部３２０と、子ＶＭＭの呼び出し条件に該当するかを判断する子ＶＭＭ呼び出し判断部から成る。フィールド区分表４００は、子ＶＭＭがＶＭＣＳを更新する場合に、親ＶＭＭを呼び出すべきか否かを規定する表である。ＣＰＵ仮想化データ２１０には、子ＶＭＭの稼動に用いる子ＶＭＭ用親ＶＭＣＳ１００とＯＳ及びＡＰの稼動に用いるＯＳ用親ＶＭＣＳ１１０が含まれる。子ＶＭＭ用親ＶＭＣＳ１００は、ＶＭＣＳのＧフィールド１０２、Ｈフィールド１０４、Ｃフィールド１０６、Ｒフィールド１０８を全て有する。ＯＳ用親ＶＭＣＳ１１０は、Ｈフィールド１１４とＣフィールド１１６のみを有する。
【００３９】
各仮想計算機３０では、子ＶＭＭ４０が稼動する。子ＶＭＭ４０上では、ＯＳ５０やＡＰ６０が稼動する。子ＶＭＭ４０は、ＯＳ５０に割り当てる仮想的なＣＰＵそれぞれに対して子ＶＭＣＳ５００を保持する。子ＶＭＣＳ５００はＶＭＣＳのＧフィールド５０２、Ｈフィールド５０４、Ｃフィールド５０６、Ｒフィールド５０８を全て有する。
【００４０】
ＧＲフィールドポインタ６００は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、子ＶＭＣＳ５００のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０の動作状態は、直接子ＶＭＣＳ５００を用いて退避・回復される。
【００４１】
ＣＨフィールドポインタ６１０は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、ＯＳ用親ＶＭＣＳ１１０のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０動作中の親ＶＭＭ呼び出し条件（親ＶＭＥＸＩＴ条件）は、子ＶＭＣＳ５００ではなく、ＯＳ用親ＶＭＣＳ１１０のＣフィールドが適用される。
【００４２】
ＧＲスタンバイポインタ６２０は、常に子ＶＭＣＳ５００のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＧＲフィールドポインタ６００に子ＶＭＣＳ５００のアドレスを供給する。
【００４３】
ＣＨスタンバイポインタ６３０は、常にＯＳ用親ＶＭＣＳ１１０のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＣＨフィールドポインタ６１０にＯＳ用親ＶＭＣＳ１１０のアドレスを供給する。
【００４４】
子ＶＭＭ用親ＶＭＣＳのＨフィールド１０４、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６（第４のデータ構造）、ＯＳ用親ＶＭＣＳのＨフィールド１１４は、親ＶＭＭ独自の設定を保持する。ＯＳ用親ＶＭＣＳのＣフィールド１１６（第２のデータ構造）は、子ＶＭＣＳのＣフィールド５０６（第１のデータ構造）で規定された子ＶＭＭ呼び出しの条件となるイベントを、全て含む。
【００４５】
図４に、親ＶＭＭ２０が管理する主記憶９０の一例を示す。親ＶＭＭ２０は、主記憶９０上に自身を配置する領域と、仮想計算機３０が使用する領域とを割り当てる。例えば図４のように、親ＶＭＭ２０は、自身にアドレスＡＤ０〜ＡＤ１を割り当て、仮想計算機３０−１にアドレスＡＤ１〜ＡＤ２を、仮想計算機３０−ｎにアドレスＡＤ３〜ＡＤ４を割り当てる。
【００４６】
親ＶＭＭ２０が使用する領域には、エミュレータ３００と、仮想化データ２００とフィールド区分表４００とが割り当てられる。エミュレータ３００は、ＶＭＭ支援命令処理部３１０と、ＶＭＭ呼び出し優先度判断部３２０と、子ＶＭＭ呼び出し判断部３３０とを含む。仮想化データ２００は、子ＶＭＭ用親ＶＭＣＳ１００とＯＳ用親ＶＭＣＳ１１０を含む。
【００４７】
各仮想計算機３０の領域には、子ＶＭＭ４０とＯＳ５０が含まれる。子ＶＭＭ４０はメモリ領域の一部を子ＶＭＣＳ５００として使用する。
【００４８】
図２９ａに、子ＶＭＣＳ５００のフォーマットを示す図を示す。ＶＭＣＳは４ＫＢの大きさを持ち、当該４ＫＢ内に２バイトから８バイトのフィールドが多数混在する。子ＶＭＭ用親ＶＭＣＳ１００も同じフォーマットである。また、ＯＳ用親ＶＭＣＳ１１０についてはＧフィールドとＲフィールドが使用されないが、フォーマットは同一である。
【００４９】
ｘ８６ＣＰＵのメモリ保護機構では、親ＶＭＭ２０の呼び出し条件を４ＫＢ単位でしか規定できない。本発明のように、フィールド毎に異なる更新処理を実行するためには、４ＫＢよりも小さな単位で、親ＶＭＭの呼び出し条件を指定する必要がなる。本実施例では、数バイトから成るフィールド毎に、親ＶＭＭ２０の呼び出し要否を規定するために、フィールド区分表４００とフィールド判断部７２０を用いる。
【００５０】
図５は、フィールド区分表４００の構成図の一例である。フィールド区分表４００は、４ＫＢのメモリで構成されるＶＭＣＳ内の各フィールドについて、当該フィールドが更新された場合の親ＶＭＭ２０呼び出しの要否を対応付ける。当該フィールドが更新された場合の親ＶＭＭ２０呼び出しの要否を、フィールド区分４１０と呼ぶ。本例ではデータの持ち方として、ＶＭＣＳ内に於ける先頭オフセット４０３とサイズ４０６から成る各領域とフィールド区分４１０を対応付ける。
【００５１】
先頭オフセット４０３は、ＶＭＣＳの先頭アドレスからフィールドの先頭アドレスを減算した値である。サイズ４０６は、同一のフィールド区分４１０となる連続フィールドについて、フィールドサイズの総和をバイト単位で保持する。なお、データの持ち方についてはフィールド区分４１０を１バイト毎に指定する実装も当然考えられる。実施例１では、ＶＭＣＳのＣフィールドのみを親ＶＭＭで処理し、Ｇフィールド／Ｈフィールド／ＲフィールドはＣＰＵのみで処理する様にフィールド区分表を作成する。
【００５２】
図６ａは、動作主体フラグ７１０の構成図である。動作主体フラグは、物理ＶＭＸモード７１２と、論理ＶＭＸモード７１４とＣＰＬ７１９から成る。物理ＶＭＸモード７１２は、動作主体がＶＭＭ２０である場合にＲｏｏｔを保持し、動作主体が子ＶＭＭ４０／ＯＳ５０／ＡＰ６０である場合にＮｏｎ−Ｒｏｏｔを保持する。論理ＶＭＸモード７１４は、物理ＶＭＸモード７１２がＮｏｎ−Ｒｏｏｔの場合のみに使用され、動作主体が子ＶＭＭ４０の場合にＲｏｏｔを保持し、動作主体がＯＳ５０／ＡＰ６０である場合にＮｏｎ−Ｒｏｏｔを保持する。ＣＰＬ７１９は、物理ＶＭＸモード７１２と論理ＶＭＸモード７１４が両方ともＮｏｎ−Ｒｏｏｔの場合にのみ使用され、動作主体がＯＳ５０の場合は０を、ＡＰ６０の場合は３を保持する。
【００５３】
なお、ＶＭＸ（Virtual-Machine eXtentions）モードとは、Intel社の仮想化支援機構(VT-x)の仕様で規定された、ＣＰＵの状態である。ＶＭＸモードがＲｏｏｔの場合は、ＶＭＭ専用命令が実行可能で、ＣＰＵがソフトウェアの動作を監視しない。ＶＭＸモードがＮｏｎ−Ｒｏｏｔの場合は、ＶＭＭ専用命令が実行不可で、ＣＰＵがソフトウェアの動作を監視する。
【００５４】
また、ＣＰＬ（Current Privilege Level）とは、x86 CPU のアーキテクチャ仕様で規定されている、ＣＰＵの特権レベルのことである。０〜３までの値域を取り、０が最高特権レベルでハードウェアに対するあらゆる操作が許される。３が最低特権レベルでハードウェア操作が大きく制限されます。通常は０と３のみが使用され、ＯＳ動作時は０、アプリケーション(一般プログラム)の動作時は３となる。
【００５５】
＜３．親ＶＭＭ及びＣＰＵによる仮想化処理＞
次に、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作に合わせて親ＶＭＭ２０及びＣＰＵ７０が行う仮想化処理の一例について、以下、フローチャートを参照しながら説明する。
【００５６】
＜３．１．親ＶＭＭ及びＣＰＵによる仮想化処理の概要＞
図７は、親ＶＭＭ２０上で子ＶＭＭ４０／ＯＳ５０／ＡＰ６０を実行するときの、全体的な処理を示すフローチャートである。本フローチャートは、複数ＣＰＵ７０の利用を前提としており、各ＣＰＵ７０は、本フローチャートに従って独立して動作する。
【００５７】
Ｓ１７００では、親ＶＭＭ２０が子ＶＭＭ用親ＶＭＣＳ１００等を作成し、仮想計算機３０上で子ＶＭＭ４０を稼動させる準備を行う。
【００５８】
Ｓ１７０５では、親ＶＭＭがゲスト（子ＶＭＭ４０／ＯＳ５０／ＡＰ６０）の動作再開処理を行う。仮想計算機３０が子ＶＭＭ４０を稼動する様に初期化されているため、本処理によって子ＶＭＭ４０の動作が開始される。
【００５９】
Ｓ１７１０では、ＣＰＵ７０が子ＶＭＭ４０の命令を実行する。
【００６０】
Ｓ１７１５では、ＣＰＵ７０が子ＶＭＭ４０がＶＭＲＥＳＵＭＥ等のＶＭＭ支援命令を実行したか判断する。ＶＭＭ支援命令を実行した場合はＳ１７４５に進み、そうでなければＳ１７２０に進む。
【００６１】
Ｓ１７２０では、ＣＰＵ７０がＣＨフィールドポインタ６１０を参照し、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６（子ＶＭＭの動作中に親ＶＭＭを呼び出す条件となるイベントを規定する第４のデータ構造）で規定されたイベントが発生したかどうかを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７１０に進む。
【００６２】
Ｓ１７２５では、ＣＰＵ７０がＣＰＵ状態を退避し、親ＶＭＭ２０を呼び出す。
【００６３】
Ｓ１７３０では、親ＶＭＭ２０が子ＶＭＭ４０に生じたイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【００６４】
Ｓ１７３５では、親ＶＭＭ２０がＣＰＵ７０を手放し、ゲストの動作を再開させる。
【００６５】
Ｓ１７４０では、再開したゲストについて動作主体を判断する。動作主体がＯＳ５０又はＡＰ６０であればＳ１７６０に進み、子ＶＭＭであればＳ１７１０に進む。
【００６６】
Ｓ１７４５では、子ＶＭＭ４０が実行したＶＭＭ支援命令に応じて、親ＶＭＭ２０又はＣＰＵ７０が仮想化処理を行う。
【００６７】
Ｓ１７５５では、Ｓ１７４５で行った仮想化処理の結果として、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７４０に進む。
【００６８】
Ｓ１７６０では、ＣＰＵ７０がＯＳ５０又はＡＰ６０の命令を実行する。
【００６９】
Ｓ１７６５では、ＣＰＵ７０がＣＨフィールドポインタ６１０を参照し、ＣＰＵ７０上で、ＯＳ用親ＶＭＣＳのＣフィールド１１６（ＯＳの動作中に親ＶＭＭを呼び出す条件となるイベントを規定する第２のデータ構造）で規定されたイベントが発生したか否かを判断する。該当するイベントが発生した場合はＳ１７７０に進み、そうでなければＳ１７６０に進む。
【００７０】
Ｓ１７７０では、ＣＰＵ７０がＣＰＵ状態を退避し、親ＶＭＭ２０を呼び出す。
【００７１】
Ｓ１７７５では、親ＶＭＭ２０がイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【００７２】
Ｓ１７８０では、親ＶＭＭ２０がＣＰＵ７０を手放し、ゲストの動作を再開させる。
【００７３】
＜３．２．初期化処理＞
上記図７のＳ１７００で行う仮想計算機の初期化処理に関して、図８ａを用いて説明する。
【００７４】
Ｓ１８００では、親ＶＭＭ２０がフィールド区分表４００を配置するメモリ領域を確保し、フィールド毎の親ＶＭＭ呼び出しの要否を、Ｃフィールドならば親ＶＭＭ呼び出し要、Ｇ／Ｒ／Ｈフィールドならば親ＶＭＭ呼び出し不要に設定する。
【００７５】
Ｓ１８１０では、ＣＰＵ７０にフィールド区分表４００を配置したメモリのアドレスを渡し、フィールド判断部７２０を初期化する。
【００７６】
Ｓ１８４０では、子ＶＭＭ用親ＶＭＣＳ１００を配置するメモリ領域を確保し、Ｇフィールド１０２にｘ８６ＣＰＵの初期状態の値を設定する。Ｈフィールド１０４及びＣフィールド１０６には、親ＶＭＭ２０の動作に必要な値を設定する。
【００７７】
Ｓ１８５０では、ＯＳ用親ＶＭＣＳ１１０を配置するメモリ領域を確保し、Ｈフィールド１１４に親ＶＭＭ２０の動作に必要な値を設定する。
【００７８】
Ｓ１８６０では、ＧＲフィールドポインタ６００に子ＶＭＭ用親ＶＭＣＳ１００のアドレスを格納し、子ＶＭＭ用親ＶＭＣＳ１００を活性化する。
【００７９】
Ｓ１８７０では、ＣＨフィールドポインタ６１０に子ＶＭＭ用親ＶＭＣＳ１００のアドレスを格納し、子ＶＭＭ用親ＶＭＣＳ１００を活性化する。
【００８０】
Ｓ１８７３では、ＧＲスタンバイポインタ６２０にＯＳ用親ＶＭＣＳ１１０のアドレスを格納する。
【００８１】
Ｓ１８７６では、ＣＨスタンバイポインタ６３０にＯＳ用親ＶＭＣＳ１１０のアドレスを格納する。
【００８２】
Ｓ１８８０では、論理ＶＭＸモード７１４にＲｏｏｔを設定し、物理ＶＭＸモード７１２がＮｏｎ−Ｒｏｏｔになった時に動作主体が子ＶＭＭ４０と認識される様にする。
【００８３】
＜３．３．親ＶＭＭ呼び出し処理＞
上記図７のＳ１７２５及びＳ１７７０などで行う親ＶＭＭ呼び出し処理に関して、図８ｂを用いて説明する。
【００８４】
Ｓ１９００では、ＧＲフィールドポインタ６００が指すＶＭＣＳのＧフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０の動作中は、ＧＲフィールドポインタ６００が子ＶＭＭ用親ＶＭＣＳ１００を指すため、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２（第５のデータ構造）にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０動作中は、ＧＲフィールドポインタ６００が子ＶＭＣＳ５００を指すため、子ＶＭＣＳのＧフィールド５０２（ＯＳの中断・再開に際してＣＰＵ状態の退避・回復先となる第３のデータ構造）にＣＰＵ状態が退避される。
【００８５】
Ｓ１９０５では、ＧＲフィールドポインタ６００が指すＶＭＣＳのＲフィールドに親ＶＭＭ２０を呼び出す原因となったイベントの情報を保存する。
【００８６】
Ｓ１９１０では、ＣＨフィールドポインタ６１０が指すＶＭＣＳのＨフィールドからＣＰＵ状態を復元する。子ＶＭＭ４０の動作中は、ＣＨフィールドポインタ６１０が子ＶＭＭ用親ＶＭＣＳ１００を指すため、子ＶＭＭ用親ＶＭＣＳのＨフィールド１０４からＣＰＵ状態が復元される。一方、ＯＳ５０／ＡＰ６０動作中は、ＣＨフィールドポインタ６１０がＯＳ用親ＶＭＣＳ１１０を指すため、ＯＳ用親ＶＭＣＳのＨフィールド１１４からＣＰＵ状態が復元される。
【００８７】
Ｓ１９２０では、物理ＶＭＸモード７１２をＲｏｏｔに設定し、動作主体を親ＶＭＭ２０に切り替える。
【００８８】
＜３．４．ゲスト再開処理＞
上記図７のＳ１７０５、Ｓ１７３５及びＳ１７８０などで行うゲスト再開処理に関して、図８ｃを用いて説明する。
【００８９】
Ｓ２０００では、ＧＲフィールドポインタ６００が指すＶＭＣＳのＧフィールドからＣＰＵ状態を復元する。子ＶＭＭ４０を再開する場合は、ＧＲフィールドポインタ６００が子ＶＭＭ用親ＶＭＣＳ１００を指すため、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２（ＶＭＭの中断・再開に際してＣＰＵ状態の退避・回復空先となる第５のデータ構造）からＣＰＵ状態が復元される。一方、ＯＳ５０／ＡＰ６０を再開する場合は、ＧＲフィールドポインタ６００が子ＶＭＣＳ５００を指すため、子ＶＭＣＳのＧフィールド５０２からＣＰＵ状態が復元される。
【００９０】
Ｓ２０１０では、物理ＶＭＸモード７１２をＮｏｎ−Ｒｏｏｔに設定し、論理ＶＭＸモード７１４とＣＰＬ７１９の組み合わせに応じて、動作主体を子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれかに切り替える。
【００９１】
＜３．５．ＯＳ向け処理＞
上記図７のＳ１７７５で行うＯＳ向け処理に関して、図９を用いて説明する。
【００９２】
Ｓ２１００では、親ＶＭＭ２０がＧＲフィールドポインタ６００が指すＶＭＣＳのＲフィールドを参照し、発生したイベントを把握する。続いて、親ＶＭＭ２０内の呼び出し優先度判断部３２０が、発生したイベントの種類に応じて、子ＶＭＭ４０での処理を優先するか、親ＶＭＭ２０での処理を優先するかを判断する。本手順では、発生したイベントが、ＯＳ５０の命令実行と同期して発生するページフォルトなどの割り込みであれば子ＶＭＭ４０での処理が優先と判断する。一方で、ＯＳ５０の命令実行と同期しないＩ／Ｏインタフェース８５０などの割り込みであれば親ＶＭＭ２０での処理が優先と判断する。子ＶＭＭ４０での処理を優先する場合はＳ２１１０に進み、親ＶＭＭ２０での処理を優先する場合はＳ２１５０に進む。
【００９３】
Ｓ２１１０では、親ＶＭＭ２０内の子ＶＭＭ呼び出し判断部３３０が、発生したイベントとＧＲフィールドポインタ６００が指す子ＶＭＣＳのＣフィールド５０６（ＯＳの動作中に子ＶＭＭを読み出す条件となるイベントを規定する第１のデータ構造）を照合し、子ＶＭＭ４０を呼び出す条件に該当するか判断する。子ＶＭＭ４０を呼び出す条件に該当する場合はＳ２１５０に進み、該当しない場合はＳ２１３０に進む。
【００９４】
Ｓ２１３０では、親ＶＭＭ２０がイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【００９５】
Ｓ２１４０では、Ｓ２１３０で行った処理の結果として、子ＶＭＣＳのＣフィールド５０６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ２１５０に進み、そうでなければ本手順を終了する。
【００９６】
Ｓ２１５０では、親ＶＭＭ２０が、ＧＲフィールドポインタ６００が指す子ＶＭＣＳのＨフィールド５０４を参照し、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２にコピーする。本処理によって、子ＶＭＭ４０の初期状態を保持する子ＶＭＣＳのＨフィールド５０４の設定値がＣＰＵに反映される様になる。
【００９７】
Ｓ２１６０では、論理ＶＭＸモード７１４をＲｏｏｔに変更し、次回のゲスト再開時に動作主体が子ＶＭＭ４０と認識される様にする。
【００９８】
Ｓ２１７０では、ＧＲフィールドポインタ６００に、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【００９９】
Ｓ２１８０では、ＣＨフィールドポインタ６１０に、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【０１００】
Ｓ２１９０では、子ＶＭＣＳのＲフィールド５０８を作成する。親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致する場合は、親ＶＭＭ２０を呼び出した時点でＣＰＵが子ＶＭＣＳのＲフィールド５０８に当該イベントの情報を保存しているため、本手順で行うべき処理は無い。一方、親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致しない場合は、親ＶＭＭ２０が当該イベントの情報を上書きする。
【０１０１】
＜３．６．子ＶＭＭ向け処理＞
上記図７のＳ１７４５で行う子ＶＭＭ向け処理に関して、図１０を用いて説明する。
【０１０２】
Ｓ２２００では、ＣＰＵ７０が、実行された命令がＯＳ５０／ＡＰ６０の再開命令であるＶＭＲＥＳＵＭＥかどうかを判断する。ＶＭＲＥＳＵＭＥの場合はＳ２２１０に進み、そうでなければＳ２２０５に進む。
【０１０３】
Ｓ２２０５では、ＣＰＵ７０が、実行された命令がＯＳ５０／ＡＰ６０の開始命令であるＶＭＬＡＵＮＣＨかどうかを判断する。ＶＭＬＡＵＮＣＨの場合はＳ２２１０に進み、そうでなければＳ２２１５に進む。
【０１０４】
Ｓ２２１０では、親ＶＭＭ２０又はＣＰＵ７０が、ＯＳ５０／ＡＰ６０を再開するためにＧＲフィールドポインタ及びＣＨフィールドポインタを切り替える処理を行う。
Ｓ２２１５では、ＣＰＵ７０が、実行された命令が子ＶＭＣＳ５００内のフィールドを参照するＶＭＲＥＡＤ命令かどうかを判断する。ＶＭＲＥＡＤ命令の場合はＳ２２２０に進み、そうでなければＳ２２２５に進む。
【０１０５】
Ｓ２２２０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の指す子ＶＭＣＳ５００の該当フィールドを読み出し、ＶＭＲＥＡＤ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０１０６】
Ｓ２２２５では、ＣＰＵ７０が、実行された命令が子ＶＭＣＳ５００内のフィールドを更新するＶＭＷＲＩＴＥ命令かどうかを判断する。ＶＭＷＲＩＴＥ命令の場合はＳ２２３０に進み、そうでなければＳ２２３５に進む。
【０１０７】
Ｓ２２３０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の指す子ＶＭＣＳ５００の該当フィールドを更新する。また必要に応じて子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６を更新し、ＶＭＬＡＵＮＣＨ及びＶＭＲＥＳＵＭＥ命令の実行を親ＶＭＭ２０呼び出し条件に追加する。
【０１０８】
Ｓ２２３５では、ＣＰＵ７０が、実行された命令が子ＶＭＣＳ５００を最新の状態に更新するＶＭＣＬＥＡＲかどうかを判断する。ＶＭＣＬＥＡＲの場合はＳ２２４０に進み、そうでなければＳ２２４５に進む。
【０１０９】
Ｓ２２４０では、ＣＰＵ７０が、命令パラメータで指定された子ＶＭＣＳ５００について、メモリへの書き込みが保留されているデータがあれば全てメモリに反映させ、当該子ＶＭＣＳを最新の状態に更新する。
【０１１０】
Ｓ２２４５では、ＣＰＵ７０が、実行された命令が活性な子ＶＭＣＳ５００のアドレスを参照するＶＭＰＴＲＳＴであるかを判断する。ＶＭＰＴＲＳＴの場合はＳ２２５０に進み、そうでなければＳ２２５５に進む。
Ｓ２２５０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０を読み出し、ＶＭＰＴＲＳＴ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０１１１】
Ｓ２２５５では、親ＶＭＭ２０が、ＶＭＰＴＲＬＤの実行に伴う子ＶＭＣＳ５００の不活性化／活性化に対応して、子ＶＭＣＳ５００の更新、ＯＳ用親ＶＭＣＳ１１０の更新、ＧＲスタンバイポインタ６２０の更新を行う。
【０１１２】
＜３．７．ＶＭＥＮＴＲＹ処理＞
上記図１０のＳ２２１０で行うＶＭＥＮＴＲＹ処理に関して、図１１ａを用いて説明する。
【０１１３】
ＶＭＥＮＴＲＹとは、ゲスト動作を開始／再開するＶＭＬＡＵＮＣＨ／ＶＭＲＥＳＵＭＥ命令の総称である。本処理では、ＯＳ／ＡＰを動作させるためのポインタの切り替えを行う。子ＶＭＣＢのＣフィールドが更新されていた場合には、ポインタ切り替えに先立って、更新後の子ＶＭＣＳに対応するＯＳ用親ＶＭＣＳを準備する。
【０１１４】
Ｓ２３００では、ＣＰＵ７０が、ＣＨフィールドポインタ６１０を参照し、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６の親ＶＭＭ呼び出し条件に、子ＶＭＭによるＶＭＬＡＵＮＣＨ／ＶＭＲＥＳＵＭＥの実行が含まれるか判断する。含まれる場合は含まれる場合は子ＶＭＣＳのＣフィールド５１６が更新されているためＳ２３５０に進み、含まれない場合はＳ２３１０に進む。
【０１１５】
Ｓ２３１０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の値を読み出して、ＧＲフィールドポインタ６００に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０１１６】
Ｓ２３２０では、ＣＰＵ７０が、ＣＨスタンバイポインタ６３０の値を読み出して、ＣＨフィールドポインタ６１０に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０１１７】
Ｓ２３３０では、ＣＰＵ７０が、論理ＶＭＸモード７１４をＮｏｎ−Ｒｏｏｔに変更し、ＣＰＬ７１９に応じて、動作主体をＯＳ５０又はＡＰ６０に切り替える。
【０１１８】
Ｓ２３４０では、ＣＰＵ７０が、ＧＲフィールドポインタ６００を参照し、子ＶＭＣＳのＧフィールド５０２からＣＰＵ状態を回復する。
【０１１９】
Ｓ２３５０では、ＣＰＵ７０が親ＶＭＭ２０を呼び出す。
【０１２０】
Ｓ２３６０では、親ＶＭＭ２０が、ＧＲスタンバイポインタ６２０の保持値に基づいて、子ＶＭＣＳのＣフィールド５０６を参照し、子ＶＭＣＳのＣフィールド５０６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＳのＣフィールド１１６を更新する。
【０１２１】
Ｓ２３６５では、親ＶＭＭ２０が、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６の親ＶＭＭ呼び出し条件から、子ＶＭＭによるＶＭＬＡＵＮＣＨ／ＶＭＲＥＳＵＭＥの実行を除去する。
【０１２２】
Ｓ２３７０では、親ＶＭＭ２０が、ＣＰＵ７０を手放して子ＶＭＭ４０にＶＭＥＮＴＲＹを再実行させる。
【０１２３】
＜３．８．ＶＭＷＲＩＴＥ処理＞
上記図１０のＳ２２２０で行うＶＭＷＲＩＴＥ処理に関して、図１を用いて説明する。
【０１２４】
Ｓ１１００では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０を参照して子ＶＭＣＳ５００のアドレスを取得し、ＶＭＷＲＩＴＥのパラメータで指定されたフィールドを更新する。
【０１２５】
Ｓ１１２０では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ１１４０に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断して本処理を終了する。
【０１２６】
Ｓ１１４０では、ＣＰＵ７０が、ＣＨフィールドポインタ６１０を参照して子ＶＭＭ用親ＶＭＣＳ１１０のアドレスを取得し、親ＶＭＭ２０を呼び出すイベントを規定する子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６に、子ＶＭＭ４０によるＶＭＬＡＵＮＣＨ／ＶＭＲＥＳＵＭＥの実行を追加する。
【０１２７】
＜３．９．ＶＭＰＴＲＬＤ処理＞
上記図１０のＳ２２５５で行うＶＭＰＴＲＬＤ処理に関して、図１１ｂを用いて説明する。本処理では、切り替え後の子ＶＭＣＳに対応するＯＳ用親ＶＭＣＳを準備する。
【０１２８】
Ｓ２４００では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０１２９】
Ｓ２４１０では、親ＶＭＭ２０が、ＧＲスタンバイポインタ６２０にＶＭＰＴＲＬＤ命令のパラメータをコピーする。
【０１３０】
Ｓ２４２０では、ＶＭＰＴＲＬＤ命令のパラメータで指定された子ＶＭＣＳのＣフィールド５０６に含まれるイベントと子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＳのＣフィールド１１６を更新する。
【０１３１】
Ｓ２４３０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲスト動作を再開させる。
【０１３２】
＜４．まとめ＞
以上に示した実施形態によれば、頻度の高い子ＶＭＣＳのＧフィールド更新に対して、更新内容を直接、子ＶＭＣＳに反映させ、後続のＶＭＥＮＴＲＹに対してＣＰＵ内のポインタを差し替えられる。以上の処理により、性能低下の原因となる親ＶＭＭの呼び出しを避けられるため、高速な更新とＶＭＥＮＴＲＹを実現できる。一方で、Ｃフィールドが更新された場合は、後続のＶＭＥＮＴＲＹを契機として、対応するＯＳ用親ＶＭＣＳを親ＶＭＭが用意するため、子ＶＭＭに対して仕様に準拠したＶＴ機能を提供できる。また、Ｇフィールドに対してのみＣＰＵの機能を拡張するため、ＣＰＵの半導体量及び消費電力の増加も抑制できる。
【実施例２】
【０１３３】
以下では、子ＶＭＭにＶＴ機能を利用させ、ＯＳ用親ＶＭＣＳのＧフィールドを子ＶＭＣＳのＧフィールドと兼用して共通メモリ領域とする実施形態を説明する。本実施例では、子ＶＭＭによる子ＶＭＣＳの更新は、即時ＯＳ用親ＶＭＣＳに反映される。また、ＯＳ用親ＶＭＣＳのＲフィールドを、子ＶＭＣＳのＲフィールド兼用して、共通メモリ領域とする。以下では、添付図面に基づいて実施例１との違いを説明する。
【０１３４】
＜１．ハードウェア構成＞
図２は、本発明の第２実施形態に於ける、２レベル仮想計算機システムを動作させる物理計算機の構成である。実施例１と同一であるため説明を省略する。
【０１３５】
＜２．ソフトウェア構成＞
次に、物理計算機１０上で仮想計算機３０を実現するソフトウェアの構成の主要部と、制御対象となるハードウェア要素について、図１２を参照しながら詳述する。
【０１３６】
物理計算機１０が搭載するＣＰＵ７０に関しては、ＶＭＣＳポインタ６５０と、スタンバイポインタ６６０のみが実施例１と異なる。本実施例ではＣＰＵ７０の機能を拡張し、用途の異なる２種類のＶＭＣＳのアドレスを保持させる。ＶＭＣＳポインタ６５０は、活性なＶＭＣＳのアドレスを保持する。スタンバイポインタ６６０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＶＭＣＳのアドレスを保持する。ＶＭＥＸＩＴ判断部７００は、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作を監視し、ＶＭＣＳポインタ６５０の保持するアドレスに規定された親ＶＭＭ呼び出し条件が満たされたか否かを判断する。
【０１３７】
物理計算機１０上で稼動する親ＶＭＭ２０に関しては、ＯＳ用親ＶＭＣＳ１１０、子ＶＭＣＳポインタ１４０、フィールド区分表４００のみが実施例１と異なる。ＯＳ用親ＶＭＣＳ１１０は、ＶＭＣＳのＧフィールド１１２、Ｈフィールド１１４、Ｃフィールド１１６、Ｒフィールド１１８を全て有する。子ＶＭＣＳポインタ１４０は、活性な子ＶＭＣＳ５００のアドレスを保持する。フィールド区分表４００は、子ＶＭＭがＶＭＣＳを参照／更新する場合に、親ＶＭＭを呼び出すべきか否かを規定する表である。各仮想計算機３０は実施例１と同一である。
【０１３８】
ＶＭＣＳポインタ６５０は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、ＯＳ用親ＶＭＣＳ１１０のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０の動作状態は、ＯＳ用親ＶＭＣＳ１１０を用いて退避・回復される。
【０１３９】
スタンバイポインタ６６０は、常にＯＳ用親ＶＭＣＳ１１０のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＶＭＣＳポインタ６５０にＯＳ用親ＶＭＣＳ１１０のアドレスを供給する。
【０１４０】
ＯＳ用親ＶＭＣＳのＧフィールド１１２及びＯＳ用親ＶＭＣＳのＲフィールド１１８は、子ＶＭＣＳのＧフィールド５０２及び子ＶＭＣＳのＲフィールド５０８の一時的な複製として使用され、必要に応じて子ＶＭＣＳのＧフィールド５０２及び子ＶＭＣＳのＲフィールド５０８と同期される。
【０１４１】
図１３は親ＶＭＭ２０が管理する主記憶９０の一例である。図１３は子ＶＭＣＳポインタ１４０のみが実施例１と異なる。仮想化データ２００は子ＶＭＭ用親ＶＭＣＳ１００とＯＳ用親ＶＭＣＳ１１０と子ＶＭＣＳポインタ１４０を含む。
【０１４２】
図２９ａは子ＶＭＣＳ５００のフォーマットを示す図であるが、実施例１と同一であるため説明を省略する。
【０１４３】
図５は、フィールド区分表４００の構成図の一例である。フィールド区分表４００の構成は実施例１と同一であるため説明を省略する。実施例２では、フィールド区分４１０がフィールドの更新だけでなく参照についても、親ＶＭＭの呼び出し要否を規定する。また実施例２では、ＶＭＣＳのＣフィールドとＨフィールドを親ＶＭＭで処理し、ＧフィールドとＲフィールドをＣＰＵのみで処理する様にフィールド区分７１０を作成する。
【０１４４】
図６ａは、動作主体フラグ７１０の構成図であるが、実施例１と同一であるため説明を省略する。
【０１４５】
＜３．親ＶＭＭ及びＣＰＵによる仮想化処理＞
次に、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作に合わせて親ＶＭＭ２０及びＣＰＵ７０が行う仮想化処理の一例について、以下、フローチャートを参照しながら説明する。
【０１４６】
＜３．１．親ＶＭＭ及びＣＰＵによる仮想化処理の概要＞
図７は、親ＶＭＭ２０上で子ＶＭＭ４０／ＯＳ５０／ＡＰ６０を実行するときの全体的な処理を示すフローチャートである。本フローチャートに関しては、Ｓ１７２０とＳ１７６５のみが実施例１と異なる。
【０１４７】
Ｓ１７２０では、ＣＰＵ７０がＶＭＣＳポインタ６５０を参照し、子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６（子ＶＭＭの動作中に親ＶＭＭを呼び出す条件となるイベントを規定する第４のデータ構造）で規定されたイベントが発生したかどうかを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７１０に進む。
【０１４８】
Ｓ１７６５では、ＣＰＵ７０がＶＭＣＳポインタ６５０を参照し、ＣＰＵ７０上で、ＯＳ用親ＶＭＣＳのＣフィールド１１６（ＯＳの動作中に子ＶＭＭを呼び出す条件となるイベントを規定する第２のデータ構造）で規定されたイベントが発生したか否かを判断する。該当するイベントが発生した場合はＳ１７７０に進み、そうでなければＳ１７６０に進む。
【０１４９】
＜３．２．初期化処理＞
上記図７のＳ１７００で行う仮想計算機の初期化処理に関して、図１４ａを用いて説明する。
【０１５０】
Ｓ１８００では、親ＶＭＭ２０がフィールド区分表４００を配置するメモリ領域を確保し、フィールド毎の親ＶＭＭ呼び出しの要否を、Ｃ／Ｈフィールドならば親ＶＭＭ呼び出し要、Ｇ／Ｒフィールドならば親ＶＭＭ呼び出し不要に設定する。
【０１５１】
Ｓ１８１０では、ＣＰＵ７０にフィールド区分表４００を配置したメモリのアドレスを渡し、フィールド判断部７２０を初期化する。
【０１５２】
Ｓ１８４０では、子ＶＭＭ用親ＶＭＣＳ１００を配置するメモリ領域を確保し、Ｇフィールド１０２にｘ８６ＣＰＵの初期状態の値を設定する。Ｈフィールド１０４及びＣフィールド１０６には、親ＶＭＭ２０の動作に必要な値を設定する。
【０１５３】
Ｓ１８５０では、ＯＳ用親ＶＭＣＳ１１０を配置するメモリ領域を確保し、Ｈフィールド１１４に親ＶＭＭ２０の動作に必要な値を設定する。
【０１５４】
Ｓ２７００では、ＶＭＣＳポインタ６５０に子ＶＭＭ用親ＶＭＣＳ１００のアドレスを格納し、子ＶＭＭ用親ＶＭＣＳ１００を活性化する。
【０１５５】
Ｓ２７１０では、スタンバイポインタ６６０にＯＳ用親ＶＭＣＳ１１０のアドレスを格納する。
【０１５６】
Ｓ１８８０では、論理ＶＭＸモード７１４にＲｏｏｔを設定し、物理ＶＭＸモード７１２がＮｏｎ−Ｒｏｏｔになった時に動作主体が子ＶＭＭ４０と認識される様にする。
【０１５７】
＜３．３．親ＶＭＭ呼び出し処理＞
上記図７のＳ１７２５及びＳ１７７０などで行う親ＶＭＭ呼び出し処理に関して、図１４ｂを用いて説明する。
【０１５８】
Ｓ２８００では、ＶＭＣＳポインタ６５０が指すＶＭＣＳのＧフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０の動作中は、ＶＭＣＳポインタ６５０が子ＶＭＭ用親ＶＭＣＳ１００を指すため、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２（第５のデータ構造）にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０動作中は、ＶＭＣＳポインタ６５０がＯＳ用親ＶＭＣＳ１１０を指すため、ＯＳ用親ＶＭＣＳのＧフィールド１１２（第３のデータ構造）にＣＰＵ状態が退避される。
【０１５９】
Ｓ２８１０では、ＶＭＣＳポインタ６５０が指すＶＭＣＳのＲフィールドに親ＶＭＭ２０を呼び出す原因となったイベントの情報を保存する。
【０１６０】
Ｓ２０２０では、ＶＭＣＳポインタ６５０が指すＶＭＣＳのＨフィールドからＣＰＵ状態を復元する。
【０１６１】
Ｓ１９２０では、物理ＶＭＸモード７１２をＲｏｏｔに設定し、動作主体を親ＶＭＭ２０に切り替える。
【０１６２】
＜３．４．ゲスト再開処理＞
上記図７のＳ１７０５、Ｓ１７３５０及びＳ１７８０などで行うゲスト再開処理に関して、図１４ｃを用いて説明する。
【０１６３】
Ｓ２９００では、ＶＭＣＳポインタ６５０が指すＶＭＣＳのＧフィールドからＣＰＵ状態を復元する。子ＶＭＭ４０を再開する場合は、ＶＭＣＳポインタ６５０が子ＶＭＭ用親ＶＭＣＳ１００を指すため、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２（ＶＭＭの中断・再開に際してＣＰＵ状態の退避・回復空先となる第５のデータ構造）からＣＰＵ状態が復元される。一方、ＯＳ５０／ＡＰ６０を再開する場合は、ＶＭＣＳポインタ６５０がＯＳ用親ＶＭＣＳ１１０を指すため、ＯＳ用親ＶＭＣＳのＧフィールド１１２からＣＰＵ状態が復元される。
【０１６４】
Ｓ２０１０では、物理ＶＭＸモード７１２をＮｏｎ−Ｒｏｏｔに設定し、論理ＶＭＸモード７１４とＣＰＬ７１９の組み合わせに応じて、動作主体を子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれかに切り替える。
【０１６５】
＜３．５．ＯＳ向け処理＞
上記図７のＳ１７７５で行うＯＳ向け処理に関して、図１５を用いて説明する。
【０１６６】
Ｓ２１００では、親ＶＭＭ２０がＶＭＣＳポインタ６５０が指すＶＭＣＳのＲフィールドを参照し、発生したイベントを把握する。続いて、親ＶＭＭ２０内の呼び出し優先度判断部３２０が、発生したイベントの種類に応じて、子ＶＭＭ４０での処理を優先するか、親ＶＭＭ２０での処理を優先するかを判断する。子ＶＭＭ４０での処理を優先する場合はＳ２１１０に進み、親ＶＭＭ２０での処理を優先する場合はＳ２１５０に進む。
【０１６７】
Ｓ２１１０では、親ＶＭＭ２０内の子ＶＭＭ呼び出し判断部３３０が、発生したイベントと子ＶＭＣＳポインタ１４０が指す子ＶＭＣＳのＣフィールド５０６（ＯＳの動作中に子ＶＭＭを呼び出す条件となるイベントを規定する第１のデータ構造）を照合し、子ＶＭＭ４０を呼び出す条件に該当するか判断する。子ＶＭＭ４０を呼び出す条件に該当する場合はＳ２１５０に進み、該当しない場合はＳ２１３０に進む。
【０１６８】
Ｓ２１３０では、親ＶＭＭ２０がイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【０１６９】
Ｓ２１４０では、Ｓ２１３０で行った処理の結果として、子ＶＭＣＳのＣフィールド５０６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ２１５０に進み、そうでなければ本手順を終了する。
【０１７０】
Ｓ２１５０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０が指す子ＶＭＣＳのＨフィールド５０４を参照し、子ＶＭＭ用親ＶＭＣＳのＧフィールド１０２にコピーする。本処理によって、子ＶＭＭ４０の初期状態を保持する子ＶＭＣＳのＨフィールド５０４の設定値がＣＰＵに反映される様になる。
【０１７１】
Ｓ２１６０では、論理ＶＭＸモード７１４をＲｏｏｔに変更し、次回のゲスト再開時に動作主体が子ＶＭＭ４０と認識される様にする。
【０１７２】
Ｓ３０００では、ＶＭＣＳポインタ６００に、子ＶＭＭ用親ＶＭＣＳ１００のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【０１７３】
Ｓ３０１０では、子ＶＭＭ４０によるＲフィールドの読み出しに備えて、子ＶＭＭに参照させるＯＳ用親ＶＭＣＳのＲフィールド１１８を作成する。親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致する場合は、親ＶＭＭ２０を呼び出した時点でＣＰＵがＯＳ用親ＶＭＣＳのＲフィールド１１８に当該イベントの情報を保存しているため、本手順で行うべき処理は無い。一方、親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致しない場合は、親ＶＭＭ２０が当該イベントの情報を上書きする。
【０１７４】
＜３．６．子ＶＭＭ向け処理＞
上記図７のＳ１７４５で行う子ＶＭＭ向け処理に関して、図１０を用いて説明する。本処理に関しては、Ｓ２２１０、Ｓ２２２０、Ｓ２２３０、Ｓ２２４０、Ｓ２２５０、Ｓ２２５５が実施例１と異なる。
【０１７５】
Ｓ２２１０では、ＣＰＵ７０が、ＯＳ５０／ＡＰ６０を再開するためにＶＭＣＳポインタ６５０を切り替える処理を行う。
【０１７６】
Ｓ２２２０では、親ＶＭＭ２０又はＣＰＵ７０が、子ＶＭＣＳポインタ１４０の指す子ＶＭＣＳ５００又はスタンバイポインタ６６０の指すＯＳ用親ＶＭＣＳ１１０の該当フィールドを読み出し、ＶＭＲＥＡＤ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０１７７】
Ｓ２２３０では、親ＶＭＭ２０又はＣＰＵ７０が、子ＶＭＣＳポインタ１４０の指す子ＶＭＣＳ５００又はスタンバイポインタ６６０の指すＯＳ用親ＶＭＣＳ１１０の該当フィールドを更新する。また、必要に応じて親ＶＭＭ２０が、ＯＳ用親ＶＭＣＳのＣフィールド１１６を更新する。
【０１７８】
Ｓ２２４０では、親ＶＭＭ２０又はＣＰＵ７０が、命令パラメータで指定された子ＶＭＣＳ５００について、メモリへの書き込みが保留されているデータがあれば全てメモリに反映させ、当該子ＶＭＣＳを最新の状態に更新する。
【０１７９】
Ｓ２２５０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を読み出し、ＶＭＰＴＲＳＴ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０１８０】
Ｓ２２５５では、親ＶＭＭ２０が、ＶＭＰＴＲＬＤの実行に伴う子ＶＭＣＳ５００の不活性化／活性化に対応して、子ＶＭＣＳ５００の更新、ＯＳ用親ＶＭＣＳ１１０の更新、子ＶＭＣＳポインタ１４０の更新を行う。
【０１８１】
＜３．７．ＶＭＥＮＴＲＹ処理＞
上記図１０のＳ２２１０で行うＶＭＥＮＴＲＹ処理に関して、図１６を用いて説明する。
【０１８２】
Ｓ３１００では、ＣＰＵ７０が、スタンバイポインタ６６０の値を読み出して、ＶＭＣＳポインタ６５０に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０１８３】
Ｓ２３３０では、ＣＰＵ７０が、論理ＶＭＸモード７１４をＮｏｎ−Ｒｏｏｔに変更し、ＣＰＬ７１９に応じて、動作主体をＯＳ５０又はＡＰ６０に切り替える。
【０１８４】
Ｓ３１１０では、ＣＰＵ７０が、ＶＭＣＳポインタ６５０を参照し、ＯＳ用親ＶＭＣＳのＧフィールド１１２（ＯＳの中断・再開に際してＣＰＵ状態の退避・回復先となる第３のデータ構造）からＣＰＵ状態を回復する。
【０１８５】
＜３．８．ＶＭＲＥＡＤ処理＞
上記図１０のＳ２２２０で行うＶＭＲＥＡＤ処理に関して、図１７ａを用いて説明する。
【０１８６】
Ｓ３２００では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ３２１０に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断してＳ３２４０に進む。
【０１８７】
Ｓ３２１０では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０１８８】
Ｓ３２２０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照して、活性な子ＶＭＣＳ５００の該当フィールドを読み出し、ＶＭＲＥＡＤのパラメータに従ってメモリ又はレジスタの値を更新する。
【０１８９】
Ｓ３２３０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲストの実行を再開させる。
【０１９０】
Ｓ３２４０では、ＣＰＵ７０が、スタンバイポインタ６６０を参照して、ＯＳ用親ＶＭＣＳ１１０の該当フィールドを読み出し、ＶＭＲＥＡＤのパラメータに従ってメモリ又はレジスタの値を更新する。
【０１９１】
＜３．９．ＶＭＷＲＩＴＥ処理＞
上記図１０のＳ２２２０で行うＶＭＷＲＩＴＥ処理に関して、図１７ｂを用いて説明する。
【０１９２】
Ｓ１１２０では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ３３００に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断してＳ３３５０に進む。
【０１９３】
Ｓ３３００では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０１９４】
Ｓ３３１０では、親ＶＭＭ２０が、子ＶＭＭ用親ＶＭＣＳのＲフィールド１０８を参照して更新対象を認識し、子ＶＭＣＳポインタ１４０を参照して活性な子ＶＭＣＳ５００の該当フィールドを更新する。
【０１９５】
Ｓ３３２０では、親ＶＭＭ２０が、更新対象がＣフィールドであるかを判断する。ＣフィールドであればＳ３３３０に進み、ＨフィールドであればＳ３３４０に進む。
【０１９６】
Ｓ３３３０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０の保持値に基づいて、子ＶＭＣＳのＣフィールド５０６を参照し、子ＶＭＣＳのＣフィールド５０６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＳのＣフィールド１１６を更新する。
【０１９７】
Ｓ３３４０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲストの動作を再開させる。
【０１９８】
Ｓ３３５０では、ＣＰＵ７０が、スタンバイポインタ６６０を参照して、ＯＳ用親ＶＭＣＳ１１０の該当フィールドを更新する。
【０１９９】
＜３．１０．ＶＭＣＬＥＡＲ処理＞
上記図１０のＳ２２４０で行うＶＭＣＬＥＡＲ処理に関して、図１８ａを用いて説明する。本処理では、子ＶＭＣＳ５００を最新の状態に更新し、子ＶＭＭによる一般のメモリ操作命令の実行に備える。
【０２００】
Ｓ３４００では、ＣＰＵ７０が、ＶＭＭ２０を呼び出す。
【０２０１】
Ｓ３４１０では、親ＶＭＭ２０が、ＶＭＣＬＥＡＲのパラメータと子ＶＭＣＳポインタ１４０の保持値を比較する。値が同一の場合はＳ３４２０に進み、不一致の場合はＳ３４４０に進む。
【０２０２】
Ｓ３４２０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＧフィールド５０２に対して、一時的な複製であるＯＳ用親ＶＭＣＳのＧフィールド１１２が保持している値を書き戻す。
【０２０３】
Ｓ３４３０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＲフィールド５０８に対して、一時的な複製であるＯＳ用親ＶＭＣＳのＲフィールド１１８が保持値している値を書き戻す。
【０２０４】
Ｓ３４４０では、ＣＰＵ７０が、スタンバイポインタ６６０を参照して、ＯＳ用親ＶＭＣＳ１１０の該当フィールドを更新する。
【０２０５】
＜３．１１．ＶＭＰＴＲＬＤ処理＞
上記図１０のＳ２２５５で行うＶＭＰＴＲＬＤ処理に関して、図１８ｂを用いて説明する。本処理では、切り替え前の子ＶＭＣＳを最新の状態に更新し、切り替え後の子ＶＭＣＳに対応するＯＳ用親ＶＭＣＳを準備する。
【０２０６】
Ｓ２４００では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０２０７】
Ｓ３５００では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＧフィールド５０２に対して、一時的な複製であるＯＳ用親ＶＭＣＳのＧフィールド１１２が保持している値を書き戻す。
【０２０８】
Ｓ３５１０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＲフィールド５０８に対して、一時的な複製であるＯＳ用親ＶＭＣＳのＲフィールド１１８が保持している値を書き戻す。
【０２０９】
Ｓ３５２０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０にＶＭＰＴＲＬＤのパラメタで指定された子ＶＭＣＳ５００のアドレスをコピーする。
【０２１０】
Ｓ２４２０では、親ＶＭＭ２０が、ＶＭＰＴＲＬＤ命令のパラメータで指定された子ＶＭＣＳのＣフィールド５０６に含まれるイベントと子ＶＭＭ用親ＶＭＣＳのＣフィールド１０６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＳのＣフィールド５０６を更新する。
【０２１１】
Ｓ３５３０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＧフィールド５０２が保持している値を、一時的な複製であるＯＳ用親ＶＭＣＳのＧフィールド１１２にコピーする。
【０２１２】
Ｓ３５４０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０を参照し、子ＶＭＣＳのＲフィールド５０８が保持している値を、一時的な複製であるＯＳ用親ＶＭＣＳのＲフィールド１１８にコピーする。
【０２１３】
Ｓ２４３０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲスト動作を再開させる。
【０２１４】
＜３．１２．ＶＭＰＴＲＳＴ処理＞
上記図１０のＳ２２５０で行うＶＭＰＴＲＳＴ処理に関して、図１８ｃを用いて説明する。
【０２１５】
Ｓ３６００では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０２１６】
Ｓ３６１０では、親ＶＭＭ２０が、子ＶＭＣＳポインタ１４０の保持値を取り出し、ＶＭＰＴＲＳＴ命令のパラメタに従ってレジスタ又はメモリに値をコピーする。
【０２１７】
Ｓ３６２０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲスト動作を再開させる。
【０２１８】
＜４．まとめ＞
以上に示した実施形態によれば、頻度の高い子ＶＭＣＳのＧフィールド更新に対して、更新内容を直接ＯＳ用親ＶＭＣＳに反映させ、後続のＶＭＥＮＴＲＹに対してＣＰＵ内のポインタを差し替えられる。以上の処理により性能低下の原因となる親ＶＭＭの呼び出しを避けられるため、高速な更新とＶＭＥＮＴＲＹを実現できる。一方でＣフィールドが更新された場合は、対応するＯＳ用親ＶＭＣＳを親ＶＭＭが即時用意する。また、Ｇフィールドに対してのみＣＰＵの機能を拡張するため、ＣＰＵの半導体量及び消費電力の増加も抑制できる。
【実施例３】
【０２１９】
以下では、子ＶＭＭにＳＶＭ機能を利用させ、子ＶＭＣＢのＧフィールドをＯＳ用親ＶＭＣＢのＧフィールドと兼用して共通メモリ領域とする実施形態を説明する。本実施例では、子ＶＭＭによる子ＶＭＣＢの更新は、即時又は次回のＯＳ動作再開時に、ＯＳ用親ＶＭＣＢに反映される。以下では、添付図面に基づいて実施例１との違いを説明する。
【０２２０】
＜１．ハードウェア構成＞
図２は、本発明の第３実施形態に於ける、２レベル仮想計算機システムを動作させる物理計算機の構成を示す。本実施例では、物理計算機１０がＳＶＭ機能に対応したＣＰＵ７０を１つ以上有する。残りの各要素は実施例１と同一である。
【０２２１】
＜２．ソフトウェア構成＞
次に、物理計算機１０上で仮想計算機３０を実現するソフトウェアの構成の主要部と、制御対象となるハードウェア要素について、図１９を参照しながら詳述する。
【０２２２】
物理計算機１０に関しては、ＣＰＵ７０の機能のみが実施例１と異なる。ＣＰＵ７０は、ＳＶＭ機能に対応したＣＰＵであり、ＳＶＭ機能を制御するデータ構造であるＶＭＣＢ（Virtual Machine Control Block）を参照して動作する。ＳＶＭ機能では、ＶＭＣＢを１つだけ活性化させる仕様であるが、本実施例では、ＣＰＵ７０の機能を拡張し、用途の異なる４種類のＶＭＣＢのアドレスを保持させる。ＧＲフィールドポインタ６００は、ゲスト動作時の状態を退避・回復するＧ（Guest state）フィールドとＶＭＭ呼び出しの原因となるイベントの情報を保持するＲ（exit Reason）フィールドを含むＶＭＣＢのアドレスを保持する。
【０２２３】
ＣＨフィールドポインタ６１０は、親ＶＭＭ呼び出し条件を保持するＣ（Condition）フィールドと、ホスト動作の状態を退避・回復するための予約領域であるＨ（Host state）フィールドを含むＶＭＣＢのアドレスを保持する。ＧＲスタンバイポインタ６２０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＧフィールド及びＲフィールドを含むＶＭＣＢのアドレスを保持する。ＣＨスタンバイポインタ６３０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＣフィールド及びＨフィールドを含むＶＭＣＢのアドレスを保持する。
【０２２４】
ＶＭＥＸＩＴ判断部７００は、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作を監視し、Ｃフィールドポインタ６１５の保持するアドレスに規定された親ＶＭＭ呼び出し条件が満たされたか否かを判断する。動作主体フラグ７１０は、ＣＰＵ７０上で稼動するソフトウェアが、親ＶＭＭ２０／子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれであるかを管理する。フィールド判断部７２０は、子ＶＭＭがＶＭＣＢのフィールドを更新する場合に、対象が、親ＶＭＭに変更を通知すべきフィールドであるかを判断する。ＶＭＭ支援命令処理部７３０は、ＶＭＣＢを参照／更新するメモリ操作命令、ＶＭＣＢのアドレスを指定してＯＳ５０及びＡＰ６０の動作を開始／再開するＶＭＲＵＮの各命令を処理する。
【０２２５】
親ＶＭＭ２０に関しては、フィールド区分表４００とＣＰＵ仮想化データ２１０の構成要素のみが、実施例１と異なる。フィールド区分表４００は、子ＶＭＭがＶＭＣＢを更新する場合に、親ＶＭＭを呼び出すべきか否かを規定する表である。ＣＰＵ仮想化データ２１０には、子ＶＭＭの稼動に用いる子ＶＭＭ用親ＶＭＣＢ１２０とＯＳ及びＡＰの稼動に用いるＯＳ用親ＶＭＣＢ１３０が含まれる。子ＶＭＭ用親ＶＭＣＢ１２０は、ＶＭＣＢのＧフィールド１２２、Ｈフィールド１２４、Ｃフィールド１２６、Ｒフィールド１２８を全て有する。ＯＳ用親ＶＭＣＢ１３０は、Ｈフィールド１３４及びＣフィールド１３６のみを有する。
【０２２６】
各仮想計算機３０では、子ＶＭＭ４０が稼動する。子ＶＭＭ４０上では、ＯＳ５０やＡＰ６０が稼動する。子ＶＭＭ４０は、ＯＳ５０に割り当てる仮想的なＣＰＵそれぞれに対して、子ＶＭＣＢ５１０を保持する。子ＶＭＣＢ５１０は、ＶＭＣＢのＧフィールド５１２、Ｈフィールド５１４、Ｃフィールド５１６、Ｒフィールド５１８を全て有する。
【０２２７】
ＧＲフィールドポインタ６００は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、子ＶＭＣＢ５１０のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０の動作状態は、直接、子ＶＭＣＢ５１０を用いて退避・回復される。
【０２２８】
ＣＨフィールドポインタ６１０は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、ＯＳ用親ＶＭＣＢ１３０のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０動作中の親ＶＭＭ呼び出し条件（親ＶＭＥＸＩＴ条件）は、子ＶＭＣＢ５１０ではなく、ＯＳ用親ＶＭＣＢ１３０のＣフィールドが適用される。
【０２２９】
ＧＲスタンバイポインタ６２０は、常に子ＶＭＣＢ５１０のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＧＲフィールドポインタ６００に子ＶＭＣＢ５１０のアドレスを供給する。
【０２３０】
ＣＨスタンバイポインタ６３０は、常にＯＳ用親ＶＭＣＢ１３０のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＣＨフィールドポインタ６１０にＯＳ用親ＶＭＣＢ１３０のアドレスを供給する。
【０２３１】
子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６（第４のデータ構造）は、親ＶＭＭ独自の設定を保持する。ＯＳ用親ＶＭＣＢのＣフィールド１３６（第２のデータ構造）は、子ＶＭＣＢのＣフィールド５１６（第１のデータ構造）で規定された子ＶＭＭ呼び出しの条件となるイベントを、全て含む。
【０２３２】
図２０に、親ＶＭＭ２０が管理する主記憶９０の一例を示す。ＳＶＭ機能を制御するＶＭＣＢのみが実施例１と異なる。仮想化データ２００は子ＶＭＭ用親ＶＭＣＢ１２０とＯＳ用親ＶＭＣＢ１３０を含む。各仮想計算機３０の領域には、子ＶＭＭ４０とＯＳ５０が含まれる。子ＶＭＭ４０はメモリ領域の一部を子ＶＭＣＢ５１０として使用する。
【０２３３】
図２９ｂに、子ＶＭＢＳ５１０のフォーマットを示す。ＶＭＣＢは４ＫＢの大きさを持ち、当該４ＫＢ内に２バイトから８バイトのフィールドが、多数混在する。子ＶＭＭ用親ＶＭＣＢ１２０も、同じフォーマットである。また、ＯＳ用親ＶＭＣＢ１３０については、ＧフィールドとＲフィールドが使用されないが、フォーマットは同一である。
【０２３４】
図５はフィールド区分表４００の構成図の一例である。フィールド区分表４００の構成は実施例１と同一であるため説明を省略する。実施例３では、ＶＭＣＢのＣフィールドのみを親ＶＭＭで処理し、Ｇフィールド／Ｈフィールド／ＲフィールドをＣＰＵのみで処理する様にフィールド区分表を作成する。
【０２３５】
図６ｂに、動作主体フラグ７１０の構成を示す。動作主体フラグは、物理ＳＶＭモード７１６と、論理ＳＶＭモード７１８とＣＰＬ７１９から成る。物理ＳＶＭモード７１６は、動作主体がＶＭＭ２０である場合にＨｏｓｔを保持し、動作主体が子ＶＭＭ４０／Ｏ  Ｓ５０／ＡＰ６０である場合にＧｕｅｓｔを保持する。論理ＳＶＭモード７１８は、物理ＳＶＭモード７１６がＧｕｅｓｔの場合のみに使用され、動作主体が子ＶＭＭ４０の場合にＨｏｓｔを保持し、動作主体がＯＳ５０／ＡＰ６０である場合にＧｕｅｓｔを保持する。ＣＰＬ７１９は、物理ＳＶＭモード７１６と論理ＳＶＭモード７１８が両方ともＧｕｅｓｔの場合にのみ使用され、動作主体がＯＳ５０の場合は０を、ＡＰ６０の場合は３を保持する。
【０２３６】
＜３．親ＶＭＭ及びＣＰＵによる仮想化処理＞
次に、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作に合わせて、親ＶＭＭ２０及びＣＰＵ７０が行う仮想化処理の一例について、以下、フローチャートを参照しながら説明する。
【０２３７】
＜３．１．親ＶＭＭ及びＣＰＵによる仮想化処理の概要＞
図７は、親ＶＭＭ２０上で子ＶＭＭ４０／ＯＳ５０／ＡＰ６０を実行するときの全体的な処理を示すフローチャートである。本フローチャートに関しては、ＶＭＣＢに関連する下記の手順のみが実施例１と異なる。
【０２３８】
Ｓ１７００では、親ＶＭＭ２０が子ＶＭＭ用親ＶＭＣＢ１２０等を作成し、仮想計算機３０上で子ＶＭＭ４０を稼動させる準備を行う。
【０２３９】
Ｓ１７１５では、ＣＰＵ７０が子ＶＭＭ４０がＶＭＲＵＮ等のＶＭＭ支援命令を実行したか判断する。ＶＭＭ支援命令を実行した場合はＳ１７４５に進み、そうでなければＳ１７２０に進む。
【０２４０】
Ｓ１７２０では、ＣＰＵ７０がＣＨフィールドポインタ６１０を参照し、子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６（子ＶＭＭの動作中に親ＶＭＭを呼び出す条件となるイベントを規定する第４のデータ構造）で規定されたイベントが発生したかどうかを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７１０に進む。
【０２４１】
Ｓ１７５５では、Ｓ１７４５で行った仮想化処理の結果として、子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７４０に進む。
【０２４２】
Ｓ１７６５では、ＣＰＵ７０がＣＨフィールドポインタ６１０を参照し、ＣＰＵ７０上で、ＯＳ用親ＶＭＣＢのＣフィールド１３６（ＯＳの動作中に子ＶＭＭを呼び出す条件となるイベントを規定する第２のデータ構造）で規定されたイベントが発生したか否かを判断する。該当するイベントが発生した場合はＳ１７７０に進み、そうでなければＳ１７６０に進む。
【０２４３】
＜３．２．初期化処理＞
上記図７のＳ１７００で行う仮想計算機の初期化処理に関して、図２１ａを用いて説明する。
【０２４４】
Ｓ１８００では、親ＶＭＭ２０がフィールド区分表４００を配置するメモリ領域を確保し、フィールド毎の親ＶＭＭ呼び出しの要否を、Ｃフィールドならば親ＶＭＭ呼び出し要、Ｇ／Ｒ／Ｈフィールドならば親ＶＭＭ呼び出し不要に設定する。
【０２４５】
Ｓ１８１０では、ＣＰＵ７０にフィールド区分表４００を配置したメモリのアドレスを渡し、フィールド判断部７２０を初期化する。
【０２４６】
Ｓ４０００では、子ＶＭＭ用親ＶＭＣＢ１２０を配置するメモリ領域を確保し、Ｇフィールド１２２にｘ８６ＣＰＵの初期状態の値を設定する。Ｃフィールド１２６には、親ＶＭＭ２０の動作に必要な値を設定する。
【０２４７】
Ｓ４０１０では、ＯＳ用親ＶＭＣＢ１３０を配置するメモリ領域を確保する。
【０２４８】
Ｓ４０２０では、ＧＲフィールドポインタ６００に子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを格納し、子ＶＭＭ用親ＶＭＣＢ１２０を活性化する。
【０２４９】
Ｓ４０３０では、ＣＨフィールドポインタ６１０に子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを格納し、子ＶＭＭ用親ＶＭＣＢ１２０を活性化する。
【０２５０】
Ｓ４０３３では、ＧＲスタンバイポインタ６２０にＯＳ用親ＶＭＣＢ１３０のアドレスを格納する。
【０２５１】
Ｓ４０３６では、ＣＨスタンバイポインタ６３０にＯＳ用親ＶＭＣＢ１３０のアドレスを格納する。
【０２５２】
Ｓ４０４０では、論理ＳＶＭモード７１８にＨｏｓｔを設定し、物理ＳＶＭモード７１６がＧｕｅｓｔになった時に動作主体が子ＶＭＭ４０と認識される様にする。
【０２５３】
＜３．３．親ＶＭＭ呼び出し処理＞
上記図７のＳ１７２５及びＳ１７７０などで行う親ＶＭＭ呼び出し処理に関して、図２１ｂを用いて説明する。
【０２５４】
Ｓ１９００では、ＧＲフィールドポインタ６００が指すＶＭＣＢのＧフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０の動作中は、ＧＲフィールドポインタ６００が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＧフィールド１２２（第５のデータ構造）にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０動作中は、ＧＲフィールドポインタ６００が子ＶＭＣＢ５１０を指すため、子ＶＭＣＢのＧフィールド５１２（第３のデータ構造）にＣＰＵ状態が退避される。
【０２５５】
Ｓ１９０５では、ＧＲフィールドポインタ６００が指すＶＭＣＢのＲフィールドに親ＶＭＭ２０を呼び出す原因となったイベントの情報を保存する。
【０２５６】
Ｓ４１００では、ＣＨフィールドポインタ６１０が指すＶＭＣＢのＨフィールドからＣＰＵ状態を復元する。子ＶＭＭ４０の動作中は、ＣＨフィールドポインタ６１０が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＨフィールド１２４からＣＰＵ状態が復元される。一方、ＯＳ５０／ＡＰ６０動作中は、ＣＨフィールドポインタ６１０がＯＳ用親ＶＭＣＢ１３０を指すため、ＯＳ用親ＶＭＣＢのＨフィールド１３４からＣＰＵ状態が復元される。
【０２５７】
Ｓ４１１０では、物理ＳＶＭモード７１６をＨｏｓｔに設定し、動作主体を親ＶＭＭ２０に切り替える。
【０２５８】
＜３．４．ゲスト再開処理＞
上記図７のＳ１７０５、Ｓ１７３５０及びＳ１７８０などで行うゲスト再開処理に関して、図２１ｃを用いて説明する。
【０２５９】
Ｓ４２００では、ＣＨフィールドポインタ６１０が指すＶＭＣＢのＨフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０を再開する場合は、ＣＨフィールドポインタ６１０が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＨフィールド１２４にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０を再開する場合は、ＣＨフィールドポインタ６１０がＯＳ用親ＶＭＣＢ１３０を指すため、ＯＳ用親ＶＭＣＢのＨフィールド１３４にＣＰＵ状態が退避される。
【０２６０】
Ｓ２０００では、ＧＲフィールドポインタ６００が指すＶＭＣＢのＧフィールドからＣＰＵ状態を復元する。子ＶＭＭ４０を再開する場合は、ＧＲフィールドポインタ６００が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＧフィールド１２２（ＶＭＭの中断・再開に際してＣＰＵ状態の退避・回復空先となる第５のデータ構造）からＣＰＵ状態が復元される。一方、ＯＳ５０／ＡＰ６０を再開する場合は、ＧＲフィールドポインタ６００が子ＶＭＣＢ５１０を指すため、子ＶＭＣＳのＧフィールド５１２からＣＰＵ状態が復元される。
【０２６１】
Ｓ４２１０では、物理ＳＶＭモード７１６をＧｕｅｓｔに設定し、論理ＳＶＭモード７１８とＣＰＬ７１９の組み合わせに応じて、動作主体を子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれかに切り替える。
【０２６２】
＜３．５．ＯＳ向け処理＞
上記図７のＳ１７７５で行うＯＳ向け処理に関して、図２２を用いて説明する。
【０２６３】
Ｓ２１００では、親ＶＭＭ２０がＧＲフィールドポインタ６００が指すＶＭＣＢのＲフィールドを参照し、発生したイベントを把握する。続いて、親ＶＭＭ２０内の呼び出し優先度判断部３２０が、発生したイベントの種類に応じて、子ＶＭＭ４０での処理を優先するか、親ＶＭＭ２０での処理を優先するかを判断する。子ＶＭＭ４０での処理を優先する場合はＳ２１１０に進み、親ＶＭＭ２０での処理を優先する場合はＳ４３００に進む。
【０２６４】
Ｓ２１１０では、親ＶＭＭ２０内の子ＶＭＭ呼び出し判断部３３０が、発生したイベントとＧＲフィールドポインタ６００が指す子ＶＭＣＢのＣフィールド５１６（ＯＳの動作中に子ＶＭＭを呼び出す条件となるイベントを規定する第１のデータ構造）を照合し、子ＶＭＭ４０を呼び出す条件に該当するか判断する。子ＶＭＭ４０を呼び出す条件に該当する場合はＳ２１５０に進み、該当しない場合はＳ２１３０に進む。
【０２６５】
Ｓ２１３０では、親ＶＭＭ２０がイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【０２６６】
Ｓ２１４０では、Ｓ２１３０で行った処理の結果として、子ＶＭＣＢのＣフィールド５１６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ４３００に進み、そうでなければ本手順を終了する。
【０２６７】
Ｓ４３００では、論理ＳＶＭモード７１８をＨｏｓｔに変更し、次回のゲスト再開時に動作主体が子ＶＭＭ４０と認識される様にする。
【０２６８】
Ｓ４３１０では、ＧＲフィールドポインタ６００に、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【０２６９】
Ｓ４３２０では、ＣＨフィールドポインタ６１０に、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【０２７０】
Ｓ４３３０では、子ＶＭＣＢのＲフィールド５１８を作成する。親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致する場合は、親ＶＭＭ２０を呼び出した時点でＣＰＵが子ＶＭＣＢのＲフィールド５１８に当該イベントの情報を保存しているため、本手順で行うべき処理は無い。一方、親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致しない場合は、親ＶＭＭ２０が当該イベントの情報を上書きする。
【０２７１】
＜３．６．子ＶＭＭ向け処理＞
上記図７のＳ１７４５で行う子ＶＭＭ向け処理に関して、図２３を用いて説明する。
【０２７２】
Ｓ４４００では、ＣＰＵ７０が、実行された命令がＧＲスタンバイポインタ６２０にアドレスを保持される活性な子ＶＭＣＢ５１０に対するメモリＲＥＡＤかどうかを、判断する。該当するメモリＲＥＡＤの場合はＳ４４２０に進み、そうでなければＳ４４１０に進む。
【０２７３】
Ｓ４４１０では、ＣＰＵ７０が、実行された命令がＧＲスタンバイポインタ６２０にアドレスを保持される活性な子ＶＭＣＢ５１０に対するメモリＷＲＩＴＥかどうかを、判断する。該当するメモリＷＲＩＴＥの場合はＳ４４３０に進み、そうでなければＳ４４４０に進む。
【０２７４】
Ｓ４４２０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の指す子ＶＭＣＢ５１０の該当フィールドを読み出し、メモリＲＥＡＤ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０２７５】
Ｓ４４３０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の指す子ＶＭＣＢ５１０の該当フィールドを更新する。また必要に応じて子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６を更新し、ＶＭＲＵＮ命令の実行を親ＶＭＭ２０呼び出し条件に追加する。
【０２７６】
Ｓ４４４０では、親ＶＭＭ２０又はＣＰＵ７０が、ＶＭＲＵＮの実行に伴う子ＶＭＣＢ５１０の不活性化／活性化に対応して、子ＶＭＣＳ５１０の更新、ＯＳ用親ＶＭＣＢ１３０の更新、ＧＲスタンバイポインタ６２０の更新を行う。また、ＯＳ５０／ＡＰ６０の再開に対応してＧＲフィールドポインタ６００及びＣＨフィールドポインタ６１０を切り替える。
【０２７７】
＜３．７．ＶＭＲＵＮ処理＞
上記図２３のＳ４４４０で行うＶＭＲＵＮ処理に関して、図２４を用いて説明する。
【０２７８】
本処理では、ＯＳ／ＡＰを動作させるためのポインタの切り替えを行う。子ＶＭＣＢのＣフィールドが更新されていた場合には、ポインタ切り替えに先立って、更新後の子ＶＭＣＢに対応するＯＳ用親ＶＭＣＢを準備する。また、子ＶＭＣＢが切り替わる場合には、ポインタ切り替えに先立って、切り替え前の子ＶＭＣＢを最新の状態に更新し、切り替え後の子ＶＭＣＢに対応するＯＳ用親ＶＭＣＢを準備する。
【０２７９】
Ｓ４５００では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０が保持する子ＶＭＣＢのアドレスと、ＶＭＲＵＮのパラメータで指定された子ＶＭＣＢのアドレスを比較する。両者が一致する場合にはＳ４５０５に進み、不一致の場合はＳ４５５０に進む。
【０２８０】
Ｓ４５０５では、ＣＰＵ７０が、ＣＨフィールドポインタ６１０を参照し、子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６の親ＶＭＭ呼び出し条件に、子ＶＭＭによるＶＭＲＵＮの実行が含まれるか判断する。含まれる場合は子ＶＭＣＢのＣフィールド５１６が更新されているためＳ２３５０に進み、含まれない場合はＳ２３１０に進む。
【０２８１】
Ｓ２３１０では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０の値を読み出して、ＧＲフィールドポインタ６００に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０２８２】
Ｓ２３２０では、ＣＰＵ７０が、ＣＨスタンバイポインタ６３０の値を読み出して、CＨフィールドポインタ６１０に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０２８３】
Ｓ４５１０では、ＣＰＵ７０が、論理ＳＶＭモード７１８をＧｕｅｓｔに変更し、ＣＰＬ７１９に応じて、動作主体をＯＳ５０又はＡＰ６０に切り替える。
【０２８４】
Ｓ２３４０では、ＣＰＵ７０が、ＧＲフィールドポインタ６００を参照し、子ＶＭＣＢのＧフィールド５１２（ＯＳの中断・再開に際してＣＰＵ状態の退避・回復先となる第３のデータ構造）からＣＰＵ状態を回復する。
【０２８５】
Ｓ２３５０では、ＣＰＵ７０が親ＶＭＭ２０を呼び出す。
【０２８６】
Ｓ４５１５では、親ＶＭＭ２０が、ＧＲスタンバイポインタ６２０の保持値に基づいて、子ＶＭＣＢのＣフィールド５１６を参照し、子ＶＭＣＢのＣフィールド５１６に含まれるイベントと子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＢのＣフィールド１３６を更新する。
【０２８７】
Ｓ４５２０では、親ＶＭＭ２０が、子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６の親ＶＭＭ呼び出し条件から、子ＶＭＭによるＶＭＲＵＮの実行を除去する。
【０２８８】
Ｓ２３７０では、親ＶＭＭ２０が、ＣＰＵ７０を手放して子ＶＭＭ４０にＶＭＲＵＮを再実行させる。
【０２８９】
Ｓ４５４０では、ＣＰＵ７０が親ＶＭＭ２０を呼び出す。
【０２９０】
Ｓ４５５０では、親ＶＭＭ２０が、ＧＲスタンバイポインタ６２０にＶＭＲＵＮ命令のパラメータをコピーする。
【０２９１】
Ｓ４５６０では、親ＶＭＭ２０が、ＶＭＲＵＮ命令のパラメータで指定された子ＶＭＣＢのＣフィールド５１６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＢのＣフィールド１３６を更新する。
【０２９２】
Ｓ４５７０では、親ＶＭＭ２０が、ＣＰＵ７０を手放して子ＶＭＭ４０にＶＭＲＵＮを再実行させる。
【０２９３】
＜３．８．ＶＭＣＢＷＲＩＴＥ処理＞
上記図２３のＳ４４３０で行うＶＭＣＢＷＲＩＴＥ処理に関して、図１を用いて説明する。
【０２９４】
Ｓ１１００では、ＣＰＵ７０が、ＧＲスタンバイポインタ６２０を参照して子ＶＭＣＢ５１０のアドレスを取得し、メモリＷＲＩＴＥのパラメータで指定されたフィールドを更新する。
【０２９５】
Ｓ１１２０では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ１１４０に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断して本処理を終了する。
【０２９６】
Ｓ１１４０では、ＣＰＵ７０が、ＣＨフィールドポインタ６１０を参照して子ＶＭＭ用親ＶＭＣＢ１３０のアドレスを取得し、親ＶＭＭ２０を呼び出すイベントを規定する子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６に、子ＶＭＭ４０によるＶＭＲＵＮの実行を追加する。
【０２９７】
＜４．まとめ＞
以上に示した実施形態によれば、頻度の高い子ＶＭＣＢのＧフィールド更新に対して、更新内容を直接、子ＶＭＣＢに反映させ、後続のＶＭＲＵＮに対してＣＰＵ内のポインタを差し替えられる。以上の処理により、性能低下の原因となる親ＶＭＭの呼び出しを避けられるため、高速な更新とＶＭＲＵＮを実現できる。一方でＣフィールドが更新された場合は、後続のＶＭＥＲＵＮを契機として、対応するＯＳ用親ＶＭＣＢを親ＶＭＭが用意するため、子ＶＭＭに対して仕様に準拠したＳＶＭ機能を提供できる。また、Ｇフィールドに対してのみＣＰＵの機能を拡張するため、ＣＰＵの半導体量及び消費電力の増加も抑制できる。
【実施例４】
【０２９８】
以下では、子ＶＭＭにＳＶＭ機能を利用させ、ＯＳ用親ＶＭＣＢのＧフィールドを子ＶＭＣＢのＧフィールドと兼用して共通メモリ領域とする実施形態を説明する。本実施例では、子ＶＭＭによる子ＶＭＣＢの更新は、即時ＯＳ用親ＶＭＣＢに反映される。また、ＯＳ用親ＶＭＣＢのＲフィールドを子ＶＭＣＢのＲフィールド兼用して、共通メモリ領域とする。以下では、添付図面に基づいて実施例３との違いを説明する。
【０２９９】
＜１．ハードウェア構成＞
図２は、本発明の第４実施形態に於ける、２レベル仮想計算機システムを動作させる物理計算機の構成を示すが、実施例３と同一であるため説明を省略する。
【０３００】
＜２．ソフトウェア構成＞
次に、物理計算機１０上で仮想計算機３０を実現するソフトウェアの構成の主要部と、制御対象となるハードウェア要素について、図２５を参照しながら詳述する。
【０３０１】
物理計算機１０に関しては、ＣＰＵ７０の機能のみが実施例３と異なる。ＣＰＵ７０は、ＳＶＭ機能に対応したＣＰＵであり、ＳＶＭ機能を制御するデータ構造であるＶＭＣＢ（Virtual Machine Control Block）を参照して動作する。ＳＶＭ機能では、ＶＭＣＢを１つだけ活性化させる仕様であるが、本実施例ではＣＰＵ７０の機能を拡張し、用途の異なる３種類のＶＭＣＢのアドレスを保持させる。ＶＭＣＢポインタ６９０は、活性なＶＭＣＢのアドレスを保持する。スタンバイポインタ６６０は、ＯＳ５０及びＡＰ６０を動作させる場合に使用するＶＭＣＢのアドレスを保持する。子ＶＭＣＢポインタ６７０は、子ＶＭＭ４０が管理する子ＶＭＣＢのアドレスを保持する。フィールド判断部７２０は子ＶＭＭがＶＭＣＢのフィールドを参照／更新する場合に、対象が、親ＶＭＭに変更を通知すべきフィールドであるかを判断する。
【０３０２】
親ＶＭＭ２０に関しては、フィールド区分表４００とＣＰＵ仮想化データ２１０の構成要素のみが実施例３と異なる。フィールド区分表４００は、子ＶＭＭがＶＭＣＢを参照／更新する場合に、親ＶＭＭを呼び出すべきか否かを規定する表である。ＣＰＵ仮想化データ２１０には、子ＶＭＭの稼動に用いる子ＶＭＭ用親ＶＭＣＢ１２０とＯＳ及びＡＰの稼動に用いるＯＳ用親ＶＭＣＢ１３０が含まれる。子ＶＭＭ用親ＶＭＣＢ１２０は、ＶＭＣＢのＧフィールド１２２、Ｈフィールド１２４、Ｃフィールド１２６、Ｒフィールド１２８を全て有する。ＯＳ用親ＶＭＣＢ１３０は、Ｇフィールド１３２、Ｈフィールド１３４、Ｃフィールド１３６、Ｒフィールド１３８を全て有する。
【０３０３】
各仮想計算機３０は実施例３と同一である。
【０３０４】
ＶＭＣＢポインタ６９０は、子ＶＭＭ４０が動作している間は、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持する。一方でＯＳ５０及びＡＰ６０が動作している間は、ＯＳ用親ＶＭＣＢ１３０のアドレスを保持する。即ち、ＯＳ５０及びＡＰ６０の動作状態は、ＯＳ用親ＶＭＣＢ１３０を用いて退避／回復される。
【０３０５】
スタンバイポインタ６６０は、常にＯＳ用親ＶＭＣＢ１３０のアドレスを保持し、動作主体が子ＶＭＭ４０からＯＳ５０／ＡＰ６０に変化する際に、ＶＭＣＢポインタ６９０にＯＳ用親ＶＭＣＢ１３０のアドレスを供給する。
【０３０６】
ＯＳ用親ＶＭＣＢのＧフィールド１３２及びＯＳ用親ＶＭＣＢのＲフィールド１３８は、子ＶＭＣＢのＧフィールド５１２及び子ＶＭＣＢのＲフィールド５１８の一時的な複製として使用され、必要に応じて子ＶＭＣＢのＧフィールド５１２及び子ＶＭＣＢのＲフィールド５１８と同期される。
【０３０７】
図２０は、親ＶＭＭ２０が管理する主記憶９０の一例であるが、実施例３と同一であるため説明を省略する。
【０３０８】
図２９ｂは、子ＶＭＢＳ５１０のフォーマットを示す図であるが、実施例３と同一であるため説明を省略する。
【０３０９】
図５はフィールド区分表４００の構成図の一例である。フィールド区分表４００の構成は実施例１と同一であるため説明を省略する。実施例４では、フィールド区分４１０がフィールドの更新だけでなく参照についても親ＶＭＭの呼び出し要否を規定する。また実施例４では、ＶＭＣＳのＣフィールドとＨフィールドを親ＶＭＭで処理し、ＧフィールドとＲフィールドをＣＰＵのみで処理する様にフィールド区分表を作成する。
【０３１０】
図６ｂは、動作主体フラグ７１０の構成図である、実施例３と同一であるため説明を省略する。
【０３１１】
＜３．親ＶＭＭ及びＣＰＵによる仮想化処理＞
次に、子ＶＭＭ４０／ＯＳ５０／ＡＰ６０の動作に合わせて親ＶＭＭ２０及びＣＰＵ７０が行う仮想化処理の一例について、以下、フローチャートを参照しながら説明する。
【０３１２】
＜３．１．親ＶＭＭ及びＣＰＵによる仮想化処理の概要＞
図７は、親ＶＭＭ２０上で子ＶＭＭ４０／ＯＳ５０／ＡＰ６０を実行するときの全体的な処理を示すフローチャートである。本フローチャートに関しては、Ｓ１７２０とＳ１７６５のみが実施例３と異なる。
【０３１３】
Ｓ１７２０では、ＣＰＵ７０がＶＭＣＢポインタ６９０を参照し、子ＶＭＭ用親ＶＭＣＳのＣフィールド１２６（子ＶＭＭの動作中に親ＶＭＭを呼び出す条件となるイベントを規定する第４のデータ構造）で規定されたイベントが発生したかどうかを判断する。当該イベントが発生した場合はＳ１７２５に進み、そうでなければＳ１７１０に進む。
【０３１４】
Ｓ１７６５では、ＣＰＵ７０がＶＭＣＢポインタ６９０を参照し、ＣＰＵ７０上で、ＯＳ用親ＶＭＣＳのＣフィールド１３６（ＯＳの動作中に子ＶＭＭを呼び出す条件となるイベントを規定する第２のデータ構造）で規定されたイベントが発生したか否かを判断する。該当するイベントが発生した場合はＳ１７７０に進み、そうでなければＳ１７６０に進む。
【０３１５】
＜３．２．初期化処理＞
上記図７のＳ１７００で行う仮想計算機の初期化処理に関して、図２６ａを用いて説明する。
【０３１６】
Ｓ１８００では、親ＶＭＭ２０がフィールド区分表４００を配置するメモリ領域を確保し、フィールド毎の親ＶＭＭ呼び出しの要否を、Ｃ／Ｈフィールドならば親ＶＭＭ呼び出し要、Ｇ／Ｒフィールドならば親ＶＭＭ呼び出し不要に設定する。
【０３１７】
Ｓ１８１０では、ＣＰＵ７０にフィールド区分表４００を配置したメモリのアドレスを渡し、フィールド判断部７２０を初期化する。
【０３１８】
Ｓ４０００では、子ＶＭＭ用親ＶＭＣＢ１２０を配置するメモリ領域を確保し、Ｇフィールド１２２にｘ８６ＣＰＵの初期状態の値を設定する。Ｃフィールド１２６には、親ＶＭＭ２０の動作に必要な値を設定する。
【０３１９】
Ｓ４０１０では、ＯＳ用親ＶＭＣＢ１３０を配置するメモリ領域を確保する。
【０３２０】
Ｓ４７００では、ＶＭＣＢポインタ６９０に子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを格納し、子ＶＭＭ用親ＶＭＣＢ１２０を活性化する。
【０３２１】
Ｓ４７１０では、スタンバイポインタ６６０にＯＳ用親ＶＭＣＢ１３０のアドレスを格納する。
【０３２２】
Ｓ４０４０では、論理ＳＶＭモード７１８にＨｏｓｔを設定し、物理ＳＶＭモード７１６がＧｕｅｓｔになった時に動作主体が子ＶＭＭ４０と認識される様にする。
【０３２３】
＜３．３．親ＶＭＭ呼び出し処理＞
上記図７のＳ１７２５及びＳ１７７０などで行う親ＶＭＭ呼び出し処理に関して、図２６ｂを用いて説明する。
【０３２４】
Ｓ４８００では、ＶＭＣＢポインタ６９０が指すＶＭＣＢのＧフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０の動作中は、ＶＭＣＢポインタ６９０が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＧフィールド１２２（ＶＭＭの中断・再開に際してＣＰＵ状態の退避・回復空先となる第５のデータ構造））にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０動作中は、ＶＭＣＢポインタ６９０がＯＳ用親ＶＭＣＢ１３０を指すため、ＯＳ用親ＶＭＣＢのＧフィールド１３２（第３のデータ構造）にＣＰＵ状態が退避される。
【０３２５】
Ｓ４８１０では、ＶＭＣＢポインタ６９０が指すＶＭＣＢのＲフィールドに親ＶＭＭ２０を呼び出す原因となったイベントの情報を保存する。
【０３２６】
Ｓ４８２０では、ＶＭＣＢポインタ６９０が指すＶＭＣＢのＨフィールドからＣＰＵ状態を復元する。
【０３２７】
Ｓ４１１０では、物理ＳＶＭモード７１６をＨｏｓｔに設定し、動作主体を親ＶＭＭ２０に切り替える。
【０３２８】
＜３．４．ゲスト再開処理＞
上記図７のＳ１７０５、Ｓ１７３５０及びＳ１７８０などで行うゲスト再開処理に関して、図２６ｃを用いて説明する。
【０３２９】
Ｓ４９００では、ＶＭＣＢポインタ６９０が指すＶＭＣＢのＨフィールドにＣＰＵ状態を退避する。子ＶＭＭ４０を再開する場合は、ＶＭＣＢポインタ６９０が子ＶＭＭ用親ＶＭＣＢ１２０を指すため、子ＶＭＭ用親ＶＭＣＢのＨフィールド１２４にＣＰＵ状態が退避される。一方、ＯＳ５０／ＡＰ６０を再開する場合は、ＶＭＣＢポインタ６９０がＯＳ用親ＶＭＣＢ１３０を指すため、ＯＳ用親ＶＭＣＢのＨフィールド１３４にＣＰＵ状態が退避される。
【０３３０】
Ｓ４９１０では、ＶＭＣＢポインタ６９０が指すＶＭＣＢのＧフィールドからＣＰＵ状態を復元する。
【０３３１】
Ｓ４２１０では、物理ＳＶＭモード７１６をＧｕｅｓｔに設定し、論理ＳＶＭモード７１８とＣＰＬ７１９の組み合わせに応じて、動作主体を子ＶＭＭ４０／ＯＳ５０／ＡＰ６０のいずれかに切り替える。
【０３３２】
＜３．５．ＯＳ向け処理＞
上記図７のＳ１７７５で行うＯＳ向け処理に関して、図２７を用いて説明する。
【０３３３】
Ｓ２１００では、親ＶＭＭ２０がＶＭＣＢポインタ６９０が指すＶＭＣＢのＲフィールドを参照し、発生したイベントを把握する。続いて、親ＶＭＭ２０内の呼び出し優先度判断部３２０が、発生したイベントの種類に応じて、子ＶＭＭ４０での処理を優先するか、親ＶＭＭ２０での処理を優先するかを判断する。子ＶＭＭ４０での処理を優先する場合はＳ２１１０に進み、親ＶＭＭ２０での処理を優先する場合はＳ４３００に進む。
【０３３４】
Ｓ２１１０では、親ＶＭＭ２０内の子ＶＭＭ呼び出し判断部３３０が、発生したイベントと子ＶＭＣＢポインタ６７０が指す子ＶＭＣＢのＣフィールド５１６（ＯＳの動作中に子ＶＭＭを読み出す条件となるイベントを規定する第１のデータ構造）を照合し、子ＶＭＭ４０を呼び出す条件に該当するか判断する。子ＶＭＭ４０を呼び出す条件に該当する場合はＳ４３００に進み、該当しない場合はＳ２１３０に進む。
【０３３５】
Ｓ２１３０では、親ＶＭＭ２０がイベントに応じて計算機の挙動をエミュレーションし、仮想計算機３０の状態を更新する。
【０３３６】
Ｓ２１４０では、Ｓ２１３０で行った処理の結果として、子ＶＭＣＢのＣフィールド５１６で規定されたイベントが発生したか否かを判断する。当該イベントが発生した場合はＳ４３００に進み、そうでなければ本手順を終了する。
【０３３７】
Ｓ４３００では、論理ＳＶＭモード７１８をＨｏｓｔに変更し、次回のゲスト再開時に動作主体が子ＶＭＭ４０と認識される様にする。
【０３３８】
Ｓ５０００では、ＶＭＣＢポインタ６９０に、子ＶＭＭ用親ＶＭＣＢ１２０のアドレスを保持させ、子ＶＭＭ４０の再開に備える。
【０３３９】
Ｓ５０１０では、ＯＳ用親ＶＭＣＢのＲフィールド１３８を作成する。親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致する場合は、親ＶＭＭ２０を呼び出した時点でＣＰＵがＯＳ用親ＶＭＣＢのＲフィールド１３８に当該イベントの情報を保存しているため、本手順で行うべき処理は無い。一方、親ＶＭＭ２０を呼び出したイベントと子ＶＭＭ４０を呼び出す要因となるイベントが一致しない場合は、親ＶＭＭ２０が当該イベントの情報を上書きする。
【０３４０】
＜３．６．子ＶＭＭ向け処理＞
上記図７のＳ１７４５で行う子ＶＭＭ向け処理に関して、図２３を用いて説明する。
【０３４１】
Ｓ４４００では、ＣＰＵ７０が、実行された命令が子ＶＭＣＢポインタ６７０にアドレスを保持される活性な子ＶＭＣＢ５１０に対するメモリＲＥＡＤかどうかを判断する。該当するメモリＲＥＡＤの場合はＳ４４２０に進み、そうでなければＳ４４１０に進む。
【０３４２】
Ｓ４４１０では、ＣＰＵ７０が、実行された命令が子ＶＭＣＢポインタ６７０にアドレスを保持される活性な子ＶＭＣＢ５１０に対するメモリＷＲＩＴＥかどうかを判断する。該当するメモリＷＲＩＴＥの場合はＳ４４３０に進み、そうでなければＳ４４４０に進む。
【０３４３】
Ｓ４４２０では、親ＶＭＭ２０又はＣＰＵ７０が、子ＶＭＣＢポインタ６７０の指す子ＶＭＣＢ５１０又はスタンバイポインタ６６０の指すＯＳ用親ＶＭＣＢ１３０の該当フィールドを読み出し、メモリＲＥＡＤ命令のパラメータに応じてレジスタ又はメモリに格納する。
【０３４４】
Ｓ４４３０では、親ＶＭＭ２０又はＣＰＵ７０が、子ＶＭＣＢポインタ６７０の指す子ＶＭＣＢ５１０又はスタンバイポインタ６６０の指すＯＳ用親ＶＭＣＢ１３０の該当フィールドを更新する。また、必要に応じて親ＶＭＭ２０が、ＯＳ用親ＶＭＣＢのＣフィールド１３６を更新する。
【０３４５】
Ｓ４４４０では、親ＶＭＭ２０又はＣＰＵ７０が、ＶＭＲＵＮの実行に伴う子ＶＭＣＢ５１０の不活性化／活性化に対応して、子ＶＭＣＳ５１０の更新、ＯＳ用親ＶＭＣＢ１３０の更新、子ＶＭＣＢポインタ６７０の更新を行う。また、ＯＳ５０／ＡＰ６０の再開に対応してＶＭＣＢポインタ６９０を切り替える。
【０３４６】
＜３．７．ＶＭＲＵＮ処理＞
上記図２３のＳ４４４０で行うＶＭＲＵＮ処理に関して、図２８を用いて説明する。
【０３４７】
本処理では、ＯＳ／ＡＰを動作させるためのポインタの切り替えを行う。子ＶＭＣＢが切り替わる場合には、ポインタ切り替えに先立って、切り替え前の子ＶＭＣＢを最新の状態に更新し、切り替え後の子ＶＭＣＢに対応するＯＳ用親ＶＭＣＢを準備する。
【０３４８】
Ｓ５１００では、ＣＰＵ７０が、スタンバイポインタ６６０が保持する子ＶＭＣＢのアドレスと、ＶＭＲＵＮのパラメータで指定された子ＶＭＣＢのアドレスを比較する。両者が一致する場合にはＳ５１１０に進み、不一致の場合はＳ４５４０に進む。
【０３４９】
Ｓ５１１０では、ＣＰＵ７０が、スタンバイポインタ６６０の値を読み出して、ＶＭＣＢポインタ６９０に値をコピーし、ＯＳ５０／ＡＰ６０の再開に備える。
【０３５０】
Ｓ４５１０では、ＣＰＵ７０が、論理ＳＶＭモード７１８をＧｕｅｓｔに変更し、ＣＰＬ７１９に応じて、動作主体をＯＳ５０又はＡＰ６０に切り替える。
【０３５１】
Ｓ５１２０では、ＣＰＵ７０が、ＶＭＣＳポインタ６９０を参照し、ＯＳ用親ＶＭＣＢのＧフィールド１３２（ＯＳの中断・再開に際してＣＰＵ状態の退避・回復先となる第３のデータ構造）からＣＰＵ状態を回復する。
【０３５２】
Ｓ４５４０では、ＣＰＵ７０が親ＶＭＭ２０を呼び出す。
【０３５３】
Ｓ５１３０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０を参照し、子ＶＭＣＢのＧフィールド５１２に対して、一時的な複製であるＯＳ用親ＶＭＣＢのＧフィールド１３２が保持している値を書き戻す。
【０３５４】
Ｓ５１４０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０を参照し、子ＶＭＣＢのＲフィールド５１８に対して、一時的な複製であるＯＳ用親ＶＭＣＢのＲフィールド１３８が保持している値を書き戻す。
【０３５５】
Ｓ５１５０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０にＶＭＲＵＮ命令のパラメータをコピーする。
【０３５６】
Ｓ４５６０では、親ＶＭＭ２０が、ＶＭＲＵＮ命令のパラメータで指定された子ＶＭＣＢのＣフィールド５１６に含まれるイベントと子ＶＭＭ用親ＶＭＣＢのＣフィールド１２６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＢのＣフィールド１３６を更新する。
【０３５７】
Ｓ５１６０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０を参照し、子ＶＭＣＢのＧフィールド５１２が保持している値を、一時的な複製であるＯＳ用親ＶＭＣＢのＧフィールド１３２にコピーする。
【０３５８】
Ｓ５１７０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０を参照し、子ＶＭＣＢのＲフィールド５１８が保持している値を、一時的な複製であるＯＳ用親ＶＭＣＢのＲフィールド１３８にコピーする。
【０３５９】
Ｓ４５７０では、親ＶＭＭ２０が、ＣＰＵ７０を手放して子ＶＭＭ４０にＶＭＲＵＮを再実行させる。
【０３６０】
＜３．８．ＶＭＣＢＲＥＡＤ処理＞
上記図２３のＳ４４２０で行うＶＭＣＢＷＲＩＴＥ処理に関して、図１７ａを用いて説明する。
【０３６１】
Ｓ３２００では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ３２１０に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断してＳ３２４０に進む。
【０３６２】
Ｓ３２１０では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
【０３６３】
Ｓ５４００では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０を参照して、活性な子ＶＭＣＢ５１０の該当フィールドを読み出し、メモリＲＥＡＤのパラメータに従ってメモリ又はレジスタの値を更新する。
【０３６４】
Ｓ３２３０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲストの実行を再開させる。
Ｓ３２４０では、ＣＰＵ７０が、スタンバイポインタ６６０を参照して、ＯＳ用親ＶＭＣＢ１３０の該当フィールドを読み出し、メモリＲＥＡＤのパラメータに従ってメモリ又はレジスタの値を更新する。
【０３６５】
＜３．９．ＶＭＣＢＷＲＩＴＥ処理＞
上記図２３のＳ４４３０で行うＶＭＣＢＷＲＩＴＥ処理に関して、図１７ｂを用いて説明する。
【０３６６】
Ｓ１１２０では、フィールド判断部７２０が、更新されたフィールドのオフセットを用いてフィールド判断表４００を参照し、当該オフセットが含まれる領域の先頭オフセット４０３とサイズ４０６に対応するフィールド区分４１０を求める。フィールド区分４１０が親ＶＭＭで処理の場合は、親ＶＭＭ２０の呼び出しが必要と判断してＳ３３００に進む。フィールド区分４１０がＣＰＵのみで処理の場合は、親ＶＭＭ２０の呼び出しが不要と判断してＳ３３５０に進む。
【０３６７】
Ｓ３３００では、ＣＰＵ７０が、親ＶＭＭ２０を呼び出す。
Ｓ３３１０では、親ＶＭＭ２０が、子ＶＭＭ用親ＶＭＣＢのＲフィールド１２８を参照して更新対象を認識し、子ＶＭＣＢポインタ６７０を参照して活性な子ＶＭＣＢ５１０の該当フィールドを更新する。
【０３６８】
Ｓ３３２０では、親ＶＭＭ２０が、更新対象がＣフィールドであるかを判断する。ＣフィールドであればＳ３３３０に進み、ＨフィールドであればＳ３３４０に進む。
【０３６９】
Ｓ３３３０では、親ＶＭＭ２０が、子ＶＭＣＢポインタ６７０の保持値に基づいて、子ＶＭＣＢのＣフィールド５１６を参照し、子ＶＭＣＢのＣフィールド５１６に含まれるイベントを全て含む様にＯＳ用親ＶＭＣＢのＣフィールド１３６を更新する。
【０３７０】
Ｓ３３４０では、親ＶＭＭ２０が、ＣＰＵ７０を手放してゲストの動作を再開させる。
【０３７１】
Ｓ３３５０では、ＣＰＵ７０が、スタンバイポインタ６６０を参照して、ＯＳ用親ＶＭＣＢ１３０の該当フィールドを更新する。
【０３７２】
＜４．まとめ＞
以上に示した実施形態によれば、頻度の高い子ＶＭＣＢのＧフィールド更新に対して、更新内容を直接ＯＳ用親ＶＭＣＳに反映させ、後続のＶＭＲＵＮに対してＣＰＵ内のポインタを差し替えられる。以上の処理により、性能低下の原因となる親ＶＭＭの呼び出しを避けられるため、高速な更新とＶＭＲＵＮを実現できる。一方でＣフィールドが更新された場合は、対応するＯＳ用親ＶＭＣＢを親ＶＭＭが即時用意するため、子ＶＭＭに対して仕様に準拠したＳＶＭ機能を提供できる。また、Ｇフィールドに対してのみＣＰＵの機能を拡張するため、ＣＰＵの半導体量及び消費電力の増加も抑制できる。
【符号の説明】
【０３７３】
１０ 物理計算機
２０ 親ＶＭＭ
３０ 仮想計算機
４０ 子ＶＭＭ
５０ ＯＳ
６０ ＡＰ（アプリケーション）
７０ ＣＰＵ
８０ コンソール
９０ 主記憶
１００ 子ＶＭＭ用親ＶＭＣＳ
１１２ 子ＶＭＭ用親ＶＭＣＳのＧ（Guest state）フィールド
１１４ 子ＶＭＭ用親ＶＭＣＳのＨ（Host state）フィールド
１１６ 子ＶＭＭ用親ＶＭＣＳのＣ（Condition）フィールド
１１８ 子ＶＭＭ用親ＶＭＣＳのＲ（exit Reason）フィールド
１１０ ＯＳ用親ＶＭＣＳ
１１２ ＯＳ用親ＶＭＣＳのＧ（Guest state）フィールド
１１４ ＯＳ用親ＶＭＣＳのＨ（Host state）フィールド
１１６ ＯＳ用親ＶＭＣＳのＣ（Condition）フィールド
１１８ ＯＳ用親ＶＭＣＳのＲ（exit Reason）フィールド
１２０ 子ＶＭＭ用親ＶＭＣＢ
１２２ 子ＶＭＭ用親ＶＭＣＢのＧ（Guest state）フィールド
１２４ 子ＶＭＭ用親ＶＭＣＢのＨ（Host state）フィールド
１２６ 子ＶＭＭ用親ＶＭＣＢのＣ（Condition）フィールド
１２８ 子ＶＭＭ用親ＶＭＣＢのＲ（exit Reason）フィールド
１３０ ＯＳ用親ＶＭＣＢ
１３２ ＯＳ用親ＶＭＣＢのＧ（Guest state）フィールド
１３４ ＯＳ用親ＶＭＣＢのＨ（Host state）フィールド
１３６ ＯＳ用親ＶＭＣＢのＣ（Condition）フィールド
１３８ ＯＳ用親ＶＭＣＢのＲ（exit Reason）フィールド
４００フィールド区分表
５００ 子ＶＭＣＳ
５０２ 子ＶＭＣＳのＧ（Guest state）フィールド
５０４ 子ＶＭＣＳのＨ（Host state）フィールド
５０６ 子ＶＭＣＳのＣ（Condition）フィールド
５０８ 子ＶＭＣＳのＲ（exit Reason）フィールド
５１０ 子ＶＭＣＢ
５１２ 子ＶＭＣＢのＧ（Guest state）フィールド
５１４ 子ＶＭＣＢのＨ（Host state）フィールド
５１６ 子ＶＭＣＢのＣ（Condition）フィールド
５１８ 子ＶＭＣＢのＲ（exit Reason）フィールド
６００ ＧＲフィールドポインタ
６１０ ＣＨフィールドポインタ
６２０ ＧＲスタンバイポインタ
６３０ ＣＨスタンバイポインタ
６５０ ＶＭＣＳポインタ
６６０ スタンバイポインタ
６７０ 子ＶＭＣＢポインタ
６９０ ＶＭＣＢポインタ
【図１】
2011008559.tif 000003
【図２】
2011008559.tif 000004
【図３】
2011008559.tif 000005
【図４】
2011008559.tif 000006
【図５】
2011008559.tif 000007
【図６ａ】
2011008559.tif 000008
【図６ｂ】
2011008559.tif 000009
【図７】
2011008559.tif 000010
【図８ａ】
2011008559.tif 000011
【図８ｂ】
2011008559.tif 000012
【図８ｃ】
2011008559.tif 000013
【図９】
2011008559.tif 000014
【図１０】
2011008559.tif 000015
【図１１ａ】
2011008559.tif 000016
【図１１ｂ】
2011008559.tif 000017
【図１２】
2011008559.tif 000018
【図１３】
2011008559.tif 000019
【図１４ａ】
2011008559.tif 000020
【図１４ｂ】
2011008559.tif 000021
【図１４ｃ】
2011008559.tif 000022
【図１５】
2011008559.tif 000023
【図１６】
2011008559.tif 000024
【図１７ａ】
2011008559.tif 000025
【図１７ｂ】
2011008559.tif 000026
【図１８ａ】
2011008559.tif 000027
【図１８ｂ】
2011008559.tif 000028
【図１８ｃ】
2011008559.tif 000029
【図１９】
2011008559.tif 000030
【図２０】
2011008559.tif 000031
【図２１ａ】
2011008559.tif 000032
【図２１ｂ】
2011008559.tif 000033
【図２１ｃ】
2011008559.tif 000034
【図２２】
2011008559.tif 000035
【図２３】
2011008559.tif 000036
【図２４】
2011008559.tif 000037
【図２５】
2011008559.tif 000038
【図２６ａ】
2011008559.tif 000039
【図２６ｂ】
2011008559.tif 000040
【図２６ｃ】
2011008559.tif 000041
【図２７】
2011008559.tif 000042
【図２８】
2011008559.tif 000043
【図２９ａ】
2011008559.tif 000044
【図２９ｂ】
2011008559.tif 000045