JP5584811B2 - 仮想計算機の制御方法、仮想化プログラム及び仮想計算機システム - Google Patents

Description

本発明は、仮想計算機システムに関し、特に、仮想化支援機能を備えたプロセッサを用いた仮想計算機システムに関する。

近年、オープンサーバの普及に伴い多数のサーバが企業の情報システムに導入された。特に価格性能比が高いｉＡ（Intel Architectures）−３２サーバの乱立は、電力やハードウェアの保守費用などを含むサーバの運用管理コストを増大させており、サーバを運用する企業において問題となっている。

サーバの運用管理コストを低減するため、複数台のサーバを１台の物理的なサーバ（物理サーバ）に集約するサーバ統合が有望である。サーバ統合の実現方法としては、計算機資源を仮想化する機能を提供する仮想化ソフトウェアが注目されている。仮想化ソフトウェアは１台の物理サーバのＣＰＵ（プロセッサ）やＩ／Ｏ等の計算機資源を分割し、複数の仮想的なサーバ（仮想サーバ）に分割した計算機資源を割付ける制御ソフトウェアである。各仮想サーバ上では各々１つのＯＳ（ゲストＯＳ）が稼動できる。仮想化ソフトウェアを用いると、従来、複数の物理的なサーバで稼動していたＯＳやアプリケーションを各仮想サーバに割当てて、一つの物理計算機で複数のサーバを提供するサーバ統合を実現することができる。

仮想化ソフトウェアにおける仮想サーバへの計算機資源の割付方針について説明する。計算機資源のうちＣＰＵの割付について、ｉＡ−３２向けの仮想化ソフトウェアではＶＴ−ｘ（Virtualization Technology for Xeon）機能（または、ＡＭＤ−Ｖ）等の仮想化支援機能を備えたプロセッサを用いる方法が主流である。ＶＴ−ｘは仮想化ソフトウェアとゲストＯＳに異なる動作権限を割当てる機能であり、プロセッサのハードウェアに実装されている（例えば、特許文献１または非特許文献１、２）。ＶＴ−ｘに対応したＣＰＵは、ゲストＯＳ間と仮想化ソフトウェアの動作権限の移行を検出してＣＰＵのレジスタ状態の退避や回復を行い、仮想サーバ毎に独立した動作環境を提供する。

一方、Ｉ／Ｏの割付方針は仮想化ソフトウェアによって異なる。仮想化ソフトウェアのＩ／Ｏの割り付けは、
（１）物理サーバのＩ／Ｏデバイスを直接使用させるＩ／Ｏ直接割付型と、
（２）物理サーバのＩ／Ｏデバイスの種類やリビジョンを隠蔽する仮想Ｉ／Ｏ割付型と、に大別される。

上記（１）のＩ／Ｏ直接割付型は、物理サーバで動作済みのＩ／Ｏについて、ファイルシステムの再構築等を行うことなく容易にサーバ統合を実現できる長所を有する。一方、上記（２）の仮想Ｉ／Ｏ割付型では、物理サーバのＩ／Ｏ種類に依らず一定の１／Ｏ構成をゲストＯＳに提供できる長所を有する。

ここで、上述のような仮想化ソフトウェアとしては、次のようなものが知られている。まず、ｉＡ−３２サーバ向けの仮想化ソフトウェアの１つとして、ＶＭｗａｒｅ（登録商標）のＥＳＸ Ｓｅｒｖｅｒが知られている。これは、ｉＡ−３２のＣＰＵを含む物理サーバで、上述したＶＴ−ｘ機能を利用して、既存のＯＳを複数動作させることが可能である。

汎用機の技術に基づく仮想化ソフトウェアとしては、論理分割運転機能が知られている（ＩＢＭ Ｓｙｓｔｅｍ３７０等）。これは、単一の物理計算機を複数の論理区画（ＬＰＡＲ）に分割し、各ＬＰＡＲ上で既存のＯＳ及び仮想化管理部（ＶＭＭ＝Virtual Machine Manager）を実行する。論理分割運転機能では、汎用機（物理計算機）が上記ｉＡ−３２のＶＴ−ｘに相当する機能（ＬＰＡＲモード）を用いて、仮想サーバ（ＬＰＡＲ）上での従来のＯＳおよびＶＭＭを稼動させている。

この他、シミュレータによってｉＡ−３２のＶＴ−ｘ機能を提供するものとしてＳｉｍＯＳ（http://simos.stanford.edu/introduction.html）等が知られている。この種のシミュレータは、仮想サーバ上のゲストＯＳの命令列を解釈して任意のサーバおよびＣＰＵ機能を提供するソフトウェアである。

さらに、ｉＡ−６４（ＩＰＦ＝Ｉｔａｎｉｕｍ Ｐｒｏｃｅｓｓｏｒ Ｆａｍｉｌｙ）のプロセッサに実装された仮想化支援機能としては、非特許文献３に記載されるＶＴ−ｉ機能が知られている。

特表２００５−５２９４０１号公報

「Intel 64 and IA-32 Architectures Software Developer’s Manual VOL 2B」、[online]、Intel corp. 発行、[平成１９年５月１日検索]、インターネット＜ＵＲＬ：http://www.intel.com/design/processor/manuals/253667.pdf＞ 「AMD-Virtualization（AMD-V）」、[online]、Advanced Micro Devices, Inc. 発行、[平成１９年５月１日検索]、インターネット＜ＵＲＬ：http://www.amd.com/jp-ja/assets/content_type/DownloadableAssets/jp-ja_AMD-V_general_200702.pdf＞ 「Intel Itanium Architecture Software Developer's Manual」、[online]、Intel corp. 発行、[平成１９年５月１日検索]、インターネット＜ＵＲＬ：ftp://download.intel.com/design/Itanium/manuals/24531705.pdf＞

ところで、近年のサーバ統合の要求から、新世代のサーバＯＳ（Windows Server 2008等）（Windowsは登録商標）では上述の（２）のような仮想Ｉ／Ｏ割付型の仮想化ソフトウェアの機能を搭載することが検討されている。

しかしながら、上記従来の仮想化ソフトウェアでは、次のような問題がある。

上記ＥＳＸサーバ等の従来の仮想化ソフトウェアでは、物理計算機を構成するＣＰＵの仮想化支援（ＶＴ−ｘ）機能を用いて、複数の仮想サーバ上で既存のＯＳを稼動させることは可能であるが、仮想サーバに対してＶＴ−ｘ機能を提供することはできない。このため、ＥＳＸサーバなどでは新世代のサーバＯＳのように仮想化ソフトウェア（仮想化機能）を統合したＯＳを実行することが難しい、という問題がある。

また、上記論理分割運転機能では、ＬＰＡＲ上のＯＳやＶＭＭがＬＰＡＲモードを利用することはできない。このため、仮想化ソフトウェアを統合したＯＳをＬＰＡＲ上で稼動させるのは難しい、という問題があった。

さらに、上記シミュレータの場合は、ＶＴ−ｘ機能を仮想サーバに対して提供することができ、仮想化ソフトウェアを統合した新世代のＯＳを稼動させることは可能である。しかしながら、上記シミュレータは、仮想サーバ（ゲストＯＳ）の命令列を解釈し、物理計算機のＣＰＵが実行可能な命令列に変換（バイナリトランスレーション）するためのオーバーヘッドが発生するため、仮想サーバの性能（処理能力）が低下する、という問題があり、複数の仮想サーバを稼働させるサーバ統合を行うことは現実的ではない。

また、仮想Ｉ／Ｏ割り付け型の仮想化機能を統合した新世代のＯＳでは、開発環境の提供など同一のＩ／Ｏ構成の仮想サーバを多数生成する用途には向いているが、既存のサーバで動作済みの従来のＯＳ（ＶＴ−ｘ機能を利用しないＯＳ＝ＮＴサーバ等）を統合する用途には不向きである。特に、現在、企業が運用するソフトウェア資産は、ほとんどが仮想化機能を含まないＯＳで稼動するソフトウェアである。このため、今後、サーバ統合を進めていく過程では、仮想化機能を含まない既存のＯＳと、新たに導入する仮想化機能を含んだ新世代ＯＳが混在するサーバ統合環境が必要となる。しかし、上述のように、従来例では仮想化機能を統合した新世代ＯＳを仮想計算機上に統合することは難しく、また、新世代ＯＳで既存のＯＳを統合することは難しい、という問題があった。

そこで本発明は、上記問題点に鑑みてなされたもので、仮想計算機の性能を低下させることなく、仮想化機能を統合したＯＳを仮想サーバで実行可能な仮想計算機を提供することを目的とする。

本発明は、物理プロセッサとメモリを備えた物理計算機上で複数の仮想プロセッサを提供する仮想計算機システムの制御方法であって、前記仮想計算機システムは、第１の仮想プロセッサを提供する第１の仮想化部と、前記第１の仮想プロセッサで実行されて第２の仮想プロセッサを提供する第２の仮想化部と、前記第２の仮想プロセッサで実行されるユーザプログラムと、を有し、前記第２の仮想化部が、当該第２の仮想化部または前記ユーザプログラムを実行する際の第１の仮想プロセッサの状態を含む第１のプロセッサ制御情報を前記メモリに保持するステップと、前記第１の仮想化部が、前記第２の仮想化部を実行する際の物理プロセッサの状態を含む第２のプロセッサ制御情報と、前記ユーザプログラムを実行する際の前記物理プロセッサの状態を含む第３のプロセッサ制御情報と、を前記メモリに保持するステップと、前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行うステップと、前記第１の仮想化部が、前記第２の仮想プロセッサ上で前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出するステップと、前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込むステップと、前記第１の仮想化部が、前記第１のプロセッサ制御情報から読み込んだデータを前記第３のプロセッサ制御情報に反映させるステップと、を含む。

したがって、本発明は、第２の仮想化部が第１のプロセッサ制御情報を参照する際に第２の仮想化部から第１の仮想化部へ制御が移るのを抑制して、仮想計算機の性能を低下させることなく、仮想化機能を統合したＯＳを仮想サーバで実行することが可能となる。そして、第１の仮想化部は、第１のプロセッサ制御情報のうち第２の仮想化部によって更新されたデータを読み込んで第３のプロセッサ制御情報に反映させておく。これにより、第１のプロセッサ制御情報のうち更新されたデータを読み込むので、第２の仮想化部から第１の仮想化部へ制御の移動が頻繁に発生するのを防いで、仮想計算機システムの性能の低下を防ぐことができる。

本発明の実施形態を示し、本発明を適用する計算機システムのハードウェアを示すブロック図である。 本発明を適用する仮想計算機システムの機能ブロック図である。 ホストＶＭＭとゲストＶＭＭの機能を示すブロック図である。 第１の実施形態を示し、ホストＶＭＭ保持データのシャドウＶＭＣＳの制御データの一例を示すブロック図である。 物理ＣＰＵ１０４が利用するシャドウＶＭＣＳ＃０、＃１とＶＴ−ｘ機能の動作モードの関係を示すマップである。 シャドウＶＭＣＳとＶＭ−ｅｘｉｔ情報領域の関係を示すブロック図である。 ＶＭ−ｅｘｉｔの要因リストの一例を示す説明図である。 ホストＶＭＭで行われる処理の一例を示すフローチャートで、ＶＭ−ｅｘｉｔの処理を示す。 先行読み出しエントリ情報１２３１の一例を示すマップで、前半部を示す。 先行読み出しエントリ情報１２３１の一例を示すマップで、後半部を示す。 更新ビットマップの一例を示すマップである。 図８のステップＳ１２でホストＶＭＭ１０３が実行するＶＭ−ｅｘｉｔ命令実行モジュール１２２５のエミュレーション処理のサブルーチンを示すフローチャートである。 ゲストＶＭＭ１０９で行われるエミュレータ処理の一例を示すフローチャートである。 図８のステップＳ９で行われるシャドウＶＭＣＳの更新処理の一例を示すサブルーチンのフローチャートである。 図８のステップＳ１６で行われるＶＭＲＥＡＤ命令処理の一例を示すフローチャートである。 シャドウＶＭＣＳ＃０，＃１とゲストＶＭＣＳ２２に対するホストＶＭＭ１０３とゲストＶＭＭ１０９のアクセスの一例を示すタイムチャートである。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、第１の実施形態を示し、本発明を適用する計算機システムのブロック図である。物理サーバ（物理計算機）１０１は、仮想化支援機能を備えて演算処理を実行する物理ＣＰＵ（プロセッサ）１０４、１０４ｎと、データやプログラムを格納するメモリ１０５と、物理サーバ１０１の外部の装置等とデータの送受信を行うためのＩ／Ｏ装置１０６と、を主体にして構成される。

物理ＣＰＵ１０４、１０４ｎは、メモリコントローラを備えたノースブリッジ４に接続されてメモリ１０５にアクセスする。ノースブリッジ４は、Ｉ／Ｏ装置１０６と接続するサウスブリッジ５に接続されており、物理ＣＰＵ１０４、１０４ｎは、Ｉ／Ｏ装置１０６にアクセスする。Ｉ／Ｏ装置１０６のひとつは接続線を介してハードディスクドライブ（ＨＤＤ）６に接続される。ＨＤＤ６には、後述する仮想マシンマネージャやＯＳまたはアプリケーション等のプログラムが格納されており、物理ＣＰＵ１０４、１０４ｎはＨＤＤ６のプログラムをメモリ１０５にロードし、実行イメージをメモリ１０５上に展開してから実行する。Ｉ／Ｏ装置１０６は、ネットワークインターフェースやホストバスアダプタ等で構成される。

また、物理ＣＰＵ１０４は、任意の数（ソケット）のＣＰＵで構成しても良いし、複数の演算コアを備えたプロセッサで構成しても良い。また、物理ＣＰＵ１０４の仮想化支援機能（ＶＭＸ：Virtual Machine Extensions）は、上述のＶＴ−ｘ（Virtualization Technology for IA−32 Processors）を含むものである。なお、仮想化支援機能を利用する動作モードをＶＭＸモードとし、仮想化支援機能を利用しない通常の特権レベルによる動作モードは通常動作モードとする。

図２は、本発明を適用する仮想計算機システムのブロック図である。図２において、図１に示した物理ＣＰＵ１０４で仮想計算機を実行する例を示す。

物理サーバ１０１では、複数の仮想サーバ１０２ａ、１０２ｂを稼動させるため、物理サーバ１０１の物理的な計算機資源を仮想化した計算機資源に変換し、各仮想サーバ１０２ａ、１０２ｂへ仮想計算機資源を割り当てるホストＶＭＭ（仮想マシンマネージャ：Virtual Machine Manager）１０３が実行される。このホストＶＭＭ１０３（第１の仮想化部）は、メモリ１０５に読み込まれて物理ＣＰＵ１０４で実行されるプログラムとして提供される。

ホストＶＭＭ１０３は、各仮想サーバ１０２ａ〜１０２ｂに対して、仮想ＣＰＵ１０８ａ〜１０８ｎを提供し、また、メモリ１０５とＩ／Ｏ装置１０６を各仮想サーバ１０２ａ〜１０２ｂに割り当てる。なお、各仮想サーバ１０２ａ〜１０２ｂに、物理サーバ１０１の計算機資源を割り当てる手法については、周知または公知のものを適宜用いればよいので、ここでは詳述しない。

物理サーバ１０１は、ユーザーインターフェースを提供する管理コンソール１０７に接続され、管理者などが仮想サーバ１０２ａ、１０２ｂに対する計算機資源の割り当てなどの設定をユーザーインターフェースを介してホストＶＭＭ１０３へ入力する。また、ユーザーインターフェースは、ホストＶＭＭ１０３から受信した設定状態等を管理コンソール１０７の表示装置へ出力する。

物理サーバ１０１のホストＶＭＭ１０３上で稼動する仮想サーバ１０２ａ〜１０２ｂは、ユーザプログラム１１０ａ〜１１０ｂとして、孫（ゲストＶＭＭ１０９のゲストＯＳ）ＯＳ１１１ａ〜１１１ｂがそれぞれ稼動し、各孫ＯＳ１１１ａ〜１１１ｂ上ではアプリケーション１１２ａ〜１１２ｂが実行されている。各孫ＯＳ１１１ａ〜１１１ｂは、ホストＶＭＭ１０３が提供する仮想ＣＰＵ１０８ａ〜１０８ｂ上で実行される。なお、仮想ＣＰＵ１０８ａ〜１０８ｂは、一つの仮想サーバに対して複数の仮想ＣＰＵを割り当てるようにすることができる。

仮想サーバ１０２ａでは、孫ＯＳ１１１ａとして仮想化機能（ゲストＶＭＭ１０９）を統合した新世代ＯＳが実行され、仮想サーバ１０２ｂでは、孫ＯＳ１１１ｂとして仮想化機能を利用しない既存のＯＳ（例えば、ＮＴサーバ）が実行される。

ホストＶＭＭ１０３は、既存のＯＳを実行する仮想サーバ１０２ｂに対しては、仮想ＣＰＵ１０８ｂと、管理コンソール１０７から設定された計算機資源を割り当て、既存の孫ＯＳ１１１ｂと、アプリケーション１１２ｂを実行する。

一方、ホストＶＭＭ１０３は、新世代ＯＳ１１１ａを実行する仮想サーバ１０２ａへ割り当てる仮想ＣＰＵ１０８ａに、仮想化支援機能を提供する。仮想ＣＰＵ１０８ａ上ではゲストＶＭＭ（第２の仮想化部）１０９が稼働し、このゲストＶＭＭ１０９は仮想ＣＰＵ２０８ａ〜２０８ｉを提供する。新世代ＯＳが稼働する仮想サーバ１０２ａでは、第１の仮想ＣＰＵ１０８ａ上で第２の仮想ＣＰＵ２０８ａ〜２０８ｉが複数提供され、各仮想ＣＰＵ２０８ａ〜２０８ｉでは、複数のユーザプログラム１１０ａ（孫ＯＳ１１１ａ及びアプリケーション１１２ａ）〜１１０ｉ（孫ＯＳ１１１ｉ及びアプリケーション１１２ｉ）が実行される。なお、ホストＶＭＭ１０３がゲストＶＭＭ１０９を生成するようにしてもよい。

以下、本第１実施形態では、物理ＣＰＵ１０４にＶＴ−ｘ機能を備え、仮想サーバ１０２ａの孫ＯＳ１１１ａが仮想化機能（ゲストＶＭＭ１０９）を統合した新世代ＯＳの例について説明する。

ＶＴ−ｘ機能を利用するホストＶＭＭ１０３は、メモリ１０５の所定の領域に仮想サーバ１０２ａ〜１０２ｂの状態と、物理ＣＰＵ１０４を制御するための制御情報を格納するホストＶＭＭ保持データ１１を格納する。そして、ホストＶＭＭ保持データ１１には、物理ＣＰＵ１０４を制御するための物理ＣＰＵ制御データ１３が格納される。物理ＣＰＵ制御データ１３は、仮想化支援機能を利用する仮想ＣＰＵ１０８ａのステータスを示すデータ構造で、ＶＭＣＳ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｃｏｎｔｒｏｌ Ｓｔｒｕｃｔｕｒｅ）という。なお、本実施形態では、ホストＶＭＭ保持データ１１内の物理ＣＰＵ制御データ１３を、図３で示すようにシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）とし、ゲストＶＭＭ１０９が操作する仮想ＣＰＵ制御データ１１４をゲストＶＭＣＳ２２（だい１のプロセッサ制御情報）として区別する。また、物理ＣＰＵ１０４は、物理ＣＰＵ制御データ１３のシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）を参照するためのポインタ１１５を備える。さらに、本発明のシャドウＶＭＣＳ１３０は、図５で示すように、一つのゲストＶＭＭ１０９に対して、ＶＭＸルートモードでアクセス可能なシャドウＶＭＣＳ＃０と、ＶＭＸノンルートモードでアクセス可能なシャドウＶＭＣＳ＃１を提供する。なお、以下の説明では、シャドウＶＭＣＳの総称をシャドウＶＭＣＳ１３０とし、個々のシャドウＶＭＣＳを特定するときには、シャドウＶＭＣＳ＃０〜＃ｎ−１として表記する。

ホストＶＭＭ１０３は、物理ＣＰＵ制御データ１３内のシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）を書き換えることで、物理ＣＰＵ１０４の動作モードを、ユーザプログラム１１０ａまたはゲストＶＭＭ１０９を実行する動作モード（ＶＭＸノンルートモード）と、ホストＶＭＭ１０３を実行する動作モード（ＶＭＸルートモード）の何れかに設定する。

仮想サーバ１０２ａでは、ホストＶＭＭ１０３が提供する仮想ＣＰＵ１０８ａ上で、新世代ＯＳである孫ＯＳ１１１ａに統合された仮想化機能（仮想化ソフトウェア）が、ゲストＶＭＭ１０９として稼動する。

ゲストＶＭＭ１０９には、仮想ＣＰＵ１０８ａの仮想化支援機能を制御するためのゲストＶＭＣＳ２２を含む仮想ＣＰＵ制御データ１１４と、シャドウＶＭＣＳ１３０の更新状態を示す更新ビットマップ２２７と、ゲストＶＭＣＳ２２に対する読み書きをエミュレートする命令コード２３０を備える。ゲストＶＭＣＳ２２と更新ビットマップ２２７は、ホストＶＭＭ１０３によって割り当てられたメモリ１０５上の所定の領域に格納される。

また、仮想ＣＰＵ１０８ａは、ゲストＶＭＭ１０９の仮想ＣＰＵ制御データ１１４（ゲストＶＭＣＳ２２）を参照するためのポインタ１１６を備える。このポインタ１１６は、ＶＴ−ｘ機能に対応する孫ＯＳ１１１ａが保持する仮想ＣＰＵ１０８ａの制御データ構造（ゲストＶＭＣＳ２２）へのポインタであり、孫ＯＳ１１１ａからのＶＭＰＴＲＬＤ（ＶＭＣＳ用に確保したメモリをプロセッサに読み込ませる命令）命令発行時に初期化される。なお、ポインタ１１６の初期化は、ゲストＶＭＭ１０９が実行する。

図２において、新世代ＯＳが稼動する仮想サーバ１０２ａの仮想ＣＰＵ２０８ａ〜２０８ｉは、新世代ＯＳ１１１ａに統合されたゲストＶＭＭ１０９が提供するものであり、各仮想ＣＰＵ２０８ａ〜２０８ｉ上でユーザプログラム１１０ａ〜１１０ｉを実行することができる。なお、仮想サーバ１０２ａのゲストＶＭＭ１０９は、孫ＯＳ１１１ａのアドインソフトウェアとして機能するものであっても良い。

＜本発明の概要＞
仮想化を支援するＶＴ−ｘ機能では、ホストＶＭＭ１０３が物理サーバ１０１のメモリ１０５上に確保するシャドウＶＭＣＳ１３０を用いて、物理ＣＰＵ１０４の動作モードを制御する。仮想化支援機能としてＶＴ−ｘ機能を備えた物理ＣＰＵ１０４は、通常の動作モードと仮想化支援機能を提供するＶＭＸ（Virtual Machine Extensions）モードを備え、ＶＭＸモードでは、ホストＶＭＭ１０３が動作するホストモード（以下、ＶＭＸルートモード）と、ゲストＶＭＭ１０９またはユーザプログラム（孫ＯＳ１１１ａまたはアプリケーション１１２ａ）が動作するゲストモード（以下、ＶＭＸノンルートモード）の何れかに切り替える。

物理ＣＰＵ制御データ１３のシャドウＶＭＣＳ１３０中には仮想サーバ１０２ａ上のユーザプログラム１１０ａの動作状態を規定するフィールド（ゲスト状態エリア１３１）が１種類しかなく、単純には新世代ＯＳの仮想化機能であるゲストＶＭＭ１０９と、ユーザプログラム１１０ａ（孫ＯＳ１１１ａまたはアプリケーション１１２ａ）を区分できない。

そこで、本発明では、１つの仮想ＣＰＵが、ゲストＶＭＭ１０９とユーザプログラム１１０ａを同時に実行することがないことに着目し、ホストＶＭＭ１０３が仮想化機能を統合した孫ＯＳ１１１ａを実行する仮想サーバ１０２ａのゲストＶＭＭ１０９と、ユーザプログラム１１０ａの実行の切替を監視して、動作モードの切替時にホストＶＭＭ保持データ１１のシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）内のゲスト状態エリア１３１を書き換えることにより、仮想サーバ１０２ａ上で仮想化機能を稼動させるものである。

このため、ホストＶＭＭ１０３は、仮想化機能を統合した新世代ＯＳである孫ＯＳ１１１ａを監視して、物理ＣＰＵ１０４の動作モードを、ホストＶＭＭ１０３が動作する期間ではＶＭＸルートモードに、ゲストＶＭＭ１０９またはユーザプログラム１１０ａが動作する期間ではＶＭＸノンルートモードとなるよう制御する。ホストＶＭＭ１０３は、所定の条件（ＶＭ−ｅｘｉｔ）でＶＭＸルートモードになるとホストＶＭＭ１０３がゲストＶＭＭ１０９や孫ＯＳの命令をエミュレートする。これにより、孫ＯＳ１１１ａに対して、仮想ＣＰＵ１０８ａが仮想化支援機能を提供するように見せかける。

また、物理ＣＰＵ１０４の、ＶＭＸルートモードからＶＭＸノンルートモードへの遷移をＶＭ−ｅｎｔｒｙといい、逆に、ＶＭＸノンルートモードからＶＭＸルートモードへの遷移は、ＶＭ−ｅｘｉｔという。このＶＭ−ｅｘｉｔは、孫ＯＳ１１１ａ〜１１１ｂが特権命令（例えば、ページフォルトなど）を発行したときなどの所定の要因で物理ＣＰＵ１０４がホストＶＭＭ１０３へＶＭ−ｅｘｉｔを通知する。ホストＶＭＭ１０３は、上記ＶＭ−ｅｘｉｔまたはＶＭ−ｅｎｔｒｙをイベントとして検出して所定の処理を行う。

ここで、ＶＭＸモードのＶＭＸルートモードとＶＭＸノンルートモードの遷移については、上記非特許文献１に記載されるとおりである。ここでは、概要のみについて説明する。通常動作モードからＶＭＸモードへ移行する際には、ホストＶＭＭ１０３がＶＭＸＯＮ命令を発行し、物理ＣＰＵ１０４の動作モードをＶＭＸモードに移行させる。そして、ＶＭＸモードへ移行したホストＶＭＭ１０３は、該当する仮想ＣＰＵ１０８ａ〜１０８ｂのシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）にユーザプログラム１１０ａを実行させるための情報を書き込んでからＶＭ−ｅｎｔｒｙ命令（ＶＭＬＡＵＮＣＨ命令またはＶＭＲＥＳＵＭＥ命令）を発行し、ＶＭＸルートモードからＶＭＸノンルートモードへ移行する。

一方、ＶＭ−ｅｘｉｔは孫ＯＳ１１１ａ〜１１１ｂが特権命令を発行したときなどの所定の要因で発生するイベントであり、本イベントを契機に物理ＣＰＵ１０４がホストＶＭＭ１０３へＶＭ−ｅｘｉｔを通知し、同時に動作モードをＶＭＸノンルートモードからＶＭＸルートモードに切り替える。

ホストＶＭＭ１０３のＣＰＵ制御部１２がＶＭ−ｅｘｉｔを検知すると、所定のエミュレーションを行ってゲストＶＭＭ１０９または孫ＯＳの処理を完了した後、シャドウＶＭＣＳ１３０を必要に応じて書き換えてから再びＶＭ−ｅｎｔｒｙ命令（第１制御命令）を発行してＶＭＸルートモードからＶＭＸノンルートモードへ切り替える。

上記のように、仮想サーバ１０２ａで実行されるユーザプログラム１１０ａがゲストＶＭＭ１０９と孫ＯＳ１１１ａの間で切り替わる際に、ゲストＶＭＣＳ２２の内容を、物理ＣＰＵ１０４のポインタ１１５で指示されるシャドウＶＭＣＳ１３０に同期させる。ゲストＶＭＭ１０９は仮想的なゲストＶＭＣＳ２２にアクセスすることで、シャドウＶＭＣＳ１３０にアクセスすることなくユーザプログラム１１０ａ中のステータスやイベントの内容を取得し、更新することができる。

ＶＴ−ｘ機能を備えた物理ＣＰＵ１０４は、シャドウＶＭＣＳ１３０に対する読み書きを行う命令として、シャドウＶＭＣＳ１３０を読み込むＶＭＲＥＡＤ命令と、シャドウＶＭＣＳ１３０に書き込みを行うＶＭＷＲＩＴＥ命令を提供している。ただし、これらのシャドウＶＭＣＳ１３０に対する読み込み（ＶＭＲＥＡＤ命令）と、書き込み（ＶＭＷＲＩＴＥ命令）は、ＶＭＸルートモードでのみ使用することができる。

ここで、ゲストＶＭＭ１０９からゲストＶＭＣＳ２２にアクセスする場合、物理的なＶＭＲＥＡＤ命令またはＶＭＷＲＩＴＥ命令でゲストＶＭＣＳ２２のアクセスを要求するのに代わって、ゲストＶＭＭ１０９内部の命令コード２３０に予め設定されたＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２を起動する。以下の説明では、ゲストＶＭＭ１０９がＶＭＲＥＡＤ命令またはＶＭＷＲＩＴＥ命令に代わってＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２を起動することを、仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令を発行する、という。本命令の実装は、ユーザ権限で動作する分岐命令や関数コール命令、ＳＹＳＣＡＬＬ／ＳＹＳＥＮＴＥＲ、ソフトウェア割込み（ＩＮＴ３、ＩＮＴＯ、ＩＮＴｘ）などが考えられるが、その他物理的なＶＭ−ｅｘｉｔを発生させない命令であれば代替可能である。

ゲストＶＭＭ１０９はゲストＶＭＣＳ２２を読み出す際に仮想ＶＭＲＥＡＤ命令を発行し、ゲストＶＭＣＳ２２に情報を書き込む際に仮想ＶＭＷＲＩＴＥ命令を発行する。

ゲストＶＭＭ１０９が仮にＶＭＸノンルートモードでＶＭＲＥＡＤ命令またはＶＭＷＲＩＴＥ命令を発行した場合、上記従来例では、物理ＣＰＵ１０４でＶＭ−ｅｘｉｔが発生して、一旦、ＶＭＸルートモードに移行してからゲストＶＭＭ１０９がゲストＶＭＣＳ２２を読み込むことになる。そして、ゲストＶＭＭ１０９からＶＭＲＥＡＤ命令が複数発行されると、ＶＭＲＥＡＤ命令の度にＶＭ−ｅｘｉｔが発生してしまい、ＶＭＸルートモードへの切り換えが頻発することになり、物理ＣＰＵ１０４の負荷が増大する恐れがある。この結果、仮想計算機システムの性能の低下が懸念される。

シャドウＶＭＣＳ１３０には、多数の情報が格納されているが、ゲストＶＭＭ１０９からＶＭＲＥＡＤ命令またはＶＭＷＲＩＴＥ命令でアクセスされる情報は限られており、かつ、アクセスされる情報はＶＭ−ｅｘｉｔの要因情報（Ｂａｓｉｃ Ｒｅａｓｏｎ）から予測可能である。例えば、孫ＯＳ１１１ａでページフォルトなどの特権例外が発生した場合、ＶＭＲＥＡＤ命令で参照される情報は、Ｂａｓｉｃ Ｒｅａｓｏｎに加えてＩＤＴ Interruption Information、ＩＤＴ Vectoring information程度に限られる。

一方、ＶＭＷＲＩＴＥ命令でアクセスされる情報については、書き込みのタイミングと参照のタイミングが異なる。例えば、ゲストＶＭＭ１０９がＶＭＷＲＩＴＥ命令でゲストＶＭＣＳ２２へ書き込むと、次のＶＭ−ｅｎｔｒｙで孫ＯＳ１１１ａに遷移するときにゲストＶＭＣＳ２２が参照されることになる。

そこで、本発明では、ゲストＶＭＭ１０９に物理ＶＭＲＥＡＤ命令または物理ＶＭＷＲＩＴＥ命令に代わって仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令を発行させ、ゲストＶＭＭ１０９の命令コード２３０に用意されたＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２を起動し、ＶＭ−ｅｘｉｔを発生することなくゲストＶＭＣＳ２２のアクセスを実現する。

そして、ＶＭＲＥＡＤエミュレータ２３１は、ゲストＶＭＣＳ２２の値がシャドウＶＭＣＳ１３０の値で更新されていなかったときのみ、実際にＶＭ−ｅｘｉｔを発生してシャドウＶＭＣＳ１３０の値をゲストＶＭＣＳ２２に反映させて、仮想ＶＭＲＥＡＤ命令が要求するデータを所定のデスティネーションに反映させる。所定のデスティネーションとしては、汎用レジスタもしくはメモリが指定される。

上記ＶＭ−ｅｘｉｔが発生した際には、ホストＶＭＭ１０３は、ＶＭ−ｅｘｉｔの要因情報からアクセスする情報を予測して複数の情報を先読みしてゲストＶＭＣＳ２２に反映させておき、次回の仮想ＶＭＲＥＡＤ命令のときには、ＶＭ−ｅｘｉｔの発生を抑制する。

ＶＭ−ｅｘｉｔの発生後に、ＶＭＸノンルートモードで動作するゲストＶＭＭ１０９が仮想ＶＭＲＥＡＤ命令で要求するデータは、ユーザプログラム１１０ａの動作状態を示すデータである。本情報は、ＶＭ−ｅｘｉｔを契機にシャドウＶＭＣＳ＃１に格納されているため、ホストＶＭＭ１０３はシャドウＶＭＣＳ＃１を対象に先読みを行う。

ここで、図５は、物理ＣＰＵ１０４が利用するシャドウＶＭＣＳ＃０、＃１とＶＴ−ｘ機能の動作モードの関係を示すマップである。ホストＶＭＭ保持データ１１のシャドウＶＭＣＳ１３０には、仮想サーバ１０２ａが利用する領域として、ＶＭＸ（仮想機能）ルートモードのときに物理ＣＰＵ１０４が利用するシャドウＶＭＣＳ＃０と、ＶＭＸ（仮想機能）ノンルートモードのときに物理ＣＰＵ１０４が利用するシャドウＶＭＣＳ＃１が予め設定されている。

ホストＶＭＭ１０３は、物理ＣＰＵ１０４のポインタ１１５の値を切り替えることで、シャドウＶＭＣＳ＃０と＃１を切り替える。シャドウＶＭＣＳは＃０、＃１いずれもホストＶＭＭ１０３からのみアクセスできる。一方、ＶＭＸノンルートモードで動作するゲストＶＭＭはゲストＶＭＣＳ２２のみがアクセス可能である。

＜ＶＭＭの構成＞
図２において、ホストＶＭＭ１０３は、上述のホストＶＭＭ保持データ１１の他に、仮想サーバ１０２ａ〜１０２ｂを監視して、物理ＣＰＵ１０４の動作モードをＶＭＸルートモードとＶＭＸノンルートモードの何れかに切り替えるＣＰＵ（プロセッサ）制御部１２を備える。

さらに、ホストＶＭＭ１０３は、ＣＰＵ制御部１２が仮想サーバ１０２ａ〜１０２ｂの状態を取得し、各仮想サーバ１０２ａ〜１０２ｂへ指令を送信するためのインターフェースである制御・通信インターフェース１７ａ、１７ｂと、ＣＰＵ制御部１２が物理ＣＰＵ１０４へ命令を発行するための命令発行インターフェース１８と、物理ＣＰＵ１０４がメモリ１０５に格納された物理ＣＰＵ制御データ１３を参照または更新するための参照・更新インターフェース１９ａ、１９ｂと、Ｉ／Ｏ装置１０６からの割り込み要求などを受け付けて、この要求に応答するためのＩ／Ｏ要求・応答インターフェース１６を備える。

図３は、ホストＶＭＭ１０３とゲストＶＭＭ１０９の機能を示すブロック図である。ホストＶＭＭ１０３は、物理ＣＰＵ１０４の仮想化支援機能（ＶＴ−ｘ機能）を利用するため、メモリ１０５の所定の領域にホストＶＭＭ保持データ１１を設定する。

ホストＶＭＭ保持データ１１は、孫ＯＳ１１１ａ〜１１１ｂの仮想化支援機能の利用の有無や、仮想ＣＰＵ１０８ａ〜１０８ｎの状態を示すフラグ類を格納する領域と、仮想ＣＰＵ１０８ａ〜１０８ｂ毎のステータス等を格納するシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）を保持する物理ＣＰＵ制御データ１３の領域を含んで構成される。

ホストＶＭＭ保持データ１１の孫ＯＳや仮想ＣＰＵの状態を示すフラグとしては、例えば、孫ＯＳ１１１ａ〜１１１ｂ毎に物理ＣＰＵ１０４の仮想化支援機能を利用可能か否かを識別する仮想化機能有効フラグ１４１と、仮想ＣＰＵ１０８ａ〜１０８ｂ毎に仮想化支援機能を利用中か否かを設定するＶＭＸＯＮフラグ１４２と、仮想ＣＰＵ１０８ａ〜１０８ｂの仮想化支援機能がＶＭＸルートモードまたはＶＭＸノンルートモードの何れで動作しているのかを示す動作モードフラグ１４３が挙げられる。

仮想化機能有効フラグ１４１は、孫ＯＳ１１１ａ〜１１１ｂ毎に設定されて「１」であれば該当する孫ＯＳが仮想化支援機能を利用可能であることを示し、「０」であれば孫ＯＳが仮想化支援機能を利用しない（または利用できない）ことを示す。この仮想化機能有効フラグ１４１は、孫ＯＳ１１１ａ〜１１１ｂ毎に管理コンソール１０７から設定したり、あるいは、予め設定したファイルなどから設定する。

ＶＭＸＯＮフラグ１４２は、各仮想ＣＰＵ１０８ａ〜１０８ｂ毎にＶＭＸモードの動作状態を示すフラグで、「１」のときには該当する仮想ＣＰＵ１０８ａ〜１０８ｂの動作モードがＶＭＸモードであることを示し、「０」のときには該当する仮想ＣＰＵ１０８ａ〜１０８ｂの動作モードが仮想化支援機能を利用しない通常動作モードであることを示す。ＶＭＸＯＮフラグ１４２は、孫ＯＳ１１１ａ〜１１１ｂがＶＭＸＯＮ命令を発行したときにホストＶＭＭ１０３が「１」をセットし、孫ＯＳ１１１ａ〜１１１ｂがＶＭＸＯＦＦ命令を発行したときにホストＶＭＭ１０３が「０」にリセットする。

動作モードフラグ１４３は、仮想ＣＰＵ１０８ａ〜１０８ｂ上で動作するプログラムの動作モードを追跡するフラグである。この動作モードフラグ１４３は、孫ＯＳ１１１ａ〜１１１ｂへのＶＭ−ｅｎｔｒｙ時にホストＶＭＭ１０３が「１」にセットし、孫ＯＳのＶＭ−ｅｘｉｔ時にホストＶＭＭ１０３が「０」にリセットする。つまり、この動作モードフラグ１４３は、ＶＭＸＯＮフラグ１４２が「１」のときに各仮想ＣＰＵ１０８ａ〜１０８ｂ毎のＶＭＸモードの種別を示すもので、動作モードフラグ１４３が「０」のときには仮想ＣＰＵ１０８ａ〜１０８ｂがゲストＶＭＭ１０９を実行する状態（仮想ＣＰＵのＶＭＸルートモード）を示し、動作モードフラグ１４３が「１」のときには仮想ＣＰＵがユーザプログラム１１０ａ（孫ＯＳ１１１ａまたはアプリケーション１１２ａ）を実行する状態（仮想ＣＰＵのＶＭＸノンルートモード）を示す。

本発明では、新世代ＯＳである孫ＯＳ１１１ａのＶＭ−ｅｎｔｒｙの際に、ホストＶＭＭ１０３がゲストＶＭＣＳ２２のゲスト状態エリア２２１とホスト状態エリア２２２を読み込んで、孫ＯＳ１１１ａの動作に応じた一方のエリアの内容をシャドウＶＭＣＳ＃０のゲスト状態エリア１３１へ設定することで、仮想サーバ１０２ａで孫ＯＳ１１１ａの仮想化機能を実現するのである。

ＶＴ−ｘ機能では以上のような、ＶＭ−ｅｎｔｒｙとＶＭ−ｅｘｉｔの遷移により、ホストＶＭＭ１０３とゲストＶＭＭ１０９またはユーザプログラム１１０ａを切り替える。このため、ＶＭ−ｅｎｔｒｙとＶＭ−ｅｘｉｔの前後の物理ＣＰＵ１０４のステータス等を保持するために、物理ＣＰＵ制御データ１３のデータ構造であるシャドウＶＭＣＳ＃０〜＃ｎ−１を使用する。

物理ＣＰＵ制御データ１３は、仮想ＣＰＵ１０８ａ〜１０８ｂ毎にシャドウＶＭＣＳ＃０〜＃ｎ−１が設定され、上述したように、ホストＶＭＭ１０３は、ひとつのゲストＶＭＭ１０９に対して２つのシャドウＶＭＣＳ＃０と＃１を割り当てる。そして、ホストＶＭＭ１０３は、図５で示すように、ひとつのシャドウＶＭＣＳ＃０を仮想ＶＭＸルートモードで使用し、他方のシャドウＶＭＣＳ＃１を仮想ＶＭＸノンルートモードで使用する。すなわち、仮想ＶＭＸルートモードのときには、ホストＶＭＭ１０３がポインタ１１５にシャドウＶＭＣＳ＃０のアドレスを設定し、図５で示すように、ゲストＶＭＭ１０９の動作時にはシャドウＶＭＣＳ＃０の設定が物理ＣＰＵに反映される。一方、仮想ＶＭＸノンルートモードのときには、ホストＶＭＭ１０３がポインタ１１５にシャドウＶＭＣＳ＃１のアドレスを設定し、孫ＯＳ１１１ａ（またはアプリケーション１１２ａ）の動作時にはシャドウＶＭＣＳ＃１の設定が用いられる。

各シャドウＶＭＣＳ１３０には、ゲスト状態エリア１３１と、ホスト状態エリア１３２と、ＶＭ実行制御領域１３３と、ＶＭ−ｅｘｉｔ制御領域１３４と、ＶＭ−ｅｎｔｒｙ制御領域１３５と、ＶＭ−ｅｘｉｔ情報領域１３６を備える。

ゲスト状態エリア１３１には、図４で示すように、仮想ＣＰＵ１０８ａ〜１０８ｂのレジスタ状態や非レジスタ状態などのステータスが格納される。すなわち、後述するように、ゲストＶＭＭ１０９のステータスまたはユーザプログラム１１０ａのステータスが選択的に格納される。

ホスト状態エリア１３２には、図４で示すように、ホストＶＭＭ１０３の物理ＣＰＵ１０４のレジスタ状態などのステータスが格納される。ＶＭ実行制御領域１３３には、仮想サーバ１０２ａ〜１０２ｂの設定情報が格納され、例えば、例外ビットマップやＩ／Ｏビットマップなどの情報が含まれる。ＶＭ−ｅｘｉｔ制御領域１３４には、ＶＭ−ｅｘｉｔの発生要因（Exit Reason）やＩＤＴ−Ｖｅｃｔｏｒｉｎｇ ｉｎｆｏｍａｔｉｏｎなどの情報が格納される。ＶＭ−ｅｎｔｒｙ制御領域１３５には、ＶＭ−ｅｎｔｒｙの動作を制御するための情報が格納される。そして、ＶＭ−ｅｘｉｔ情報領域１３６には、ＶＭ−ｅｘｉｔを発生した要因（命令またはイベント）を格納する。ＶＭ−ｅｘｉｔを発生させる要因としては、例えば、図７に示す「description」に示すものがＶＭ−ｅｘｉｔ情報領域１３６に設定される。なお、図７は、図６に示すＶＭ−ｅｘｉｔ情報領域１３６のBasic VM-exit Informationに含まれる要因情報（Exit Reason）１３６０の詳細を示す。

以上のようなシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）により、ホストＶＭＭ１０３は各仮想サーバ１０２ａ〜１０２ｂの制御を行う。

次に、ホストＶＭＭ１０３のＣＰＵ制御部１２の構成について説明する。図３において、ＣＰＵ制御部１２は、管理コンソール１０７からの入力などに基づいて各仮想サーバ１０２ａ〜１０２ｂへ物理サーバ１０１の計算機資源を割り当てるリソース管理部（図示省略）に加えて、孫ＯＳ１１１ａの仮想化機能（ゲストＶＭＭ１０９）を稼動させるため、仮想ＣＰＵ１０８ａのステータスのアクセス先を選択する状態エリア選択部１２１と、エミュレータ１２２と、シャドウＶＭＣＳ参照・更新部１２３と、ＶＭ−ｅｘｉｔハンドラ１２４と、ＶＭ−ｅｎｔｒｙ命令発行部１２５と、ユーザインターフェースとを備える。なお、リソース管理部については、上述のように公知または周知の技術を適用すればよいので、本実施形態では詳述しない。

ＶＭ−ｅｘｉｔハンドラ１２４は、物理ＣＰＵ１０４からＶＭ−ｅｘｉｔを受信して、エミュレータ１２２を起動する。

エミュレータ１２２は、ＶＭ−ｅｘｉｔハンドラ１２４から受信したＶＭ−ｅｘｉｔの発生要因となった命令またはイベントを特定し、後述するように特定した発生要因に対応するモジュールを起動してゲストＶＭＭ１０９やユーザプログラム１１０ａに代わって処理を実行する。

エミュレータ１２２が、仮想ＣＰＵ１０８ａの動作モードの変更（ＶＭＸルートとＶＭＸノンルートの切り替え）を検出した場合は、特定した要因に応じたモジュール（ＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１、ＶＭＣＬＥＡＲ命令実行モジュール１２２３、ＣＰＵＩＤ命令実行モジュール１２２４、ＶＭ−ｅｘｉｔ命令実行モジュール１２２２）を起動して、状態エリア選択部１２１を起動する。

一方、エミュレータ１２２が、ＶＭ−ｅｘｉｔハンドラ１２４から受信したＶＭ−ｅｘｉｔの発生要因が、ゲストＶＭＣＳ２２を読み込むＶＭＲＥＡＤ命令またはゲストＶＭＣＳ２２に情報を書き込むＶＭＷＲＩＴＥ命令の場合は、シャドウＶＭＣＳ＃１の内容を一括して読み書きを行うＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５を起動する。なお、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５の詳細については後述するように、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１から呼び出すことができる。

シャドウＶＭＣＳ参照・更新部１２３は、状態エリア選択部１２１が選択したアクセス先に対応するシャドウＶＭＣＳ＃１３０にアクセスを行い、アクセス結果をエミュレータ１２２へ通知する。

シャドウＶＭＣＳ参照・更新部１２３は、エミュレータ１２２のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５で利用する先行読み出しエントリ情報１２３１と、仮想ＶＭ−ｅｘｉｔ契機情報１２３２を含む。

仮想ＶＭ−ｅｘｉｔ契機情報１２３２は、後述するようにＶＭ−ｅｘｉｔ命令実行モジュール１２２２がシャドウＶＭＣＳ１３０から取得したＶＭ−ｅｘｉｔの発生要因を記憶する。

図９、図１０は、先行読み出しエントリ情報１２３１の一例を示すマップである。先行読み出しエントリ情報１２３１は、図９、図１０で示すように、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５が、シャドウＶＭＣＳ１３０から一括して読み込む要素を予め定義したビットマップで構成され、メモリ１０５に保持される。

先行読み出しエントリ情報１２３１は、図３に示したゲスト状態エリア２２１〜ＶＭ−ｅｘｉｔ情報領域２２６に対応するエリア名１２３１１と、エリア名１２３１１を構成するフィールド名１２３１２と、ＶＭ−ｅｘｉｔの発生要因（Exit Reason）毎のエントリ１２３１３から構成され、各エントリには０または１が設定される。なお、図９、図１０では、シャドウＶＭＣＳ１３０のフィールドの一部を省略したが、ＶＴ−ｘで規定されるフィールドを適宜設定することができる。

先行読み出しエントリ情報１２３１は、発生要因（Exit Reason）毎のエントリ１２３１３の値に「１」が設定されたフィールド名１２３１２またはエリア名１２３１１を、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５でまとめて読み出すことを示している。一方、エントリ１２３１３の値が「０」の場合には、該当するフィールド名１２３１２の値を読み出す必要がないことを示している。

例えば、ＶＭ−ｅｘｉｔの発生要因が「ＣＰＵＩＤ」のエントリ１２３１３では、ゲスト状態エリア１３１の「ＲＦＬＡＧＳ」、「ＲＩＰ」のフィールドと、ＶＭ−ｅｘｉｔ情報領域１３６の「Exit Reason」、「ＶＭ−ｅｘｉｔ instruction length」のフィールドに対応するエントリ１２３１３の値に「１」が設定されており、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５が一括して読み込むべきフィールドであることを示している。

また、先行読み出しエントリ情報１２３１は、後述するホストＶＭＭ１０３のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実モジュール１２２５が読み出したフィールドを学習し、ＶＭ−ｅｘｉｔの発生要因に対して読み込むべきフィールド名１２３１２を追加することができる。

本例では、先読み対象エントリをＥｘｉｔ Ｒｅａｓｏｎ毎に定義することとしたが、更に詳細な条件を設定する実施例があっても構わない。例えば、Ｅｘｉｔ Ｒｅａｓｏｎに加えて、ＩＤＴ−ｖｅｃｔｏｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎをキーとした場合、例外および外部割込みのベクタ番号別に先読み対象を詳細に設定可能である。紙面の都合上詳細は割愛するが、いずれも同業者であれば容易に理解できる変形例であり本発明に含むものとする。

なお、先行読み出しエントリ情報１２３１は、上述のようにメモリ１０５に保持して書き換え可能とした例を示したが、先行読み出しエントリ情報１２３１を固定データとしてホストＶＭＭ１０３のプログラムに組み込んでも良いし、あるいは、物理サーバ１０１のＲＯＭ（図示省略）にハードコードとして実装しても良い。

＜ゲストＶＭＭの構成＞
一方、仮想サーバ１０２ａのゲストＶＭＭ１０９が管理する仮想ＣＰＵ制御データ１１４には、上記物理ＣＰＵ制御データ１３のシャドウＶＭＣＳ＃０と同様のデータ構造であるゲストＶＭＣＳ２２が格納される。

ゲストＶＭＭ１０９は、ユーザプログラム１１０ａ（孫ＯＳ１１１ａまたはアプリケーション１１２ａ）を実行する仮想ＣＰＵ１０８ａのレジスタ状態などのステータス等を格納するゲスト状態エリア２２１と、ゲストＶＭＭ１０９を実行する仮想ＣＰＵ１０８ａのレジスタ状態などのステータスを格納するホスト状態エリア２２２と、仮想サーバ１０２ａの設定情報を格納するＶＭ実行制御領域２２３と、仮想サーバ１０２ａにおけるＶＭ−ｅｘｉｔの要因などの情報を格納するＶＭ−ｅｘｉｔ制御領域２２４と、仮想サーバ１０２ａにおけるＶＭ−ｅｎｔｒｙの動作を制御するための情報を格納するＶＭ−ｅｎｔｒｙ制御領域２２５と、仮想サーバ１０２ａにおけるＶＭ−ｅｘｉｔの原因を特定する情報を格納するＶＭ−ｅｘｉｔ情報領域２２６とを備える。

ゲスト状態エリア２２１には、上記図４と同様に、仮想ＣＰＵ１０８ａのレジスタ状態などのステータスが格納される。すなわち、後述するように、孫ＯＳ１１１ａのステータスまたはアプリケーション１１２ａのステータスが選択的に格納される。

仮想サーバ１０２ａの状態を制御するホストＶＭＭ１０３のシャドウＶＭＣＳ＃０では、ゲスト状態エリア１３１にゲストＶＭＭ１０９のステータスまたはユーザプログラム１１０ａ（孫ＯＳ１１１ａまたはアプリケーション１１２ａ）のステータスが格納され、ホスト状態エリア１３２にはホストＶＭＭ１０３のステータスが格納される。

一方、ゲストＶＭＭ１０９のゲストＶＭＣＳ２２では、ゲスト状態エリア２２１に孫ＯＳ１１１ａのステータスまたはアプリケーション１１２ａのステータスが格納され、ホスト状態エリア２２２にはゲストＶＭＭ１０９のステータスが格納される点でシャドウＶＭＣＳ１３０と相違する。

ゲストＶＭＭ１０９は、さらに、ゲストＶＭＣＳ２２への読み書きを行う命令コード２３０として、ＶＭＲＥＡＤエミュレータ２３１と、ＶＭＷＲＩＴＥエミュレータ２３２を備える。

これらのＶＭＲＥＡＤエミュレータ２３１、ＶＭＷＲＩＴＥエミュレータ２３２はＶＭＸノンルートモードでゲストＶＭＣＳ２２の読み書きを代行し、ＶＭ−ｅｘｉｔの発生を抑止する。

また、ゲストＶＭＭ１０９は、ＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２にゲストＶＭＣＳ２２がシャドウＶＭＣＳ１３０からの更新状況を通知するための更新ビットマップ２２７を備える。

更新ビットマップ２２７は、ホストＶＭＭ１０３によって更新され、図１１で示すようにゲストＶＭＣＳ２２の各エリアを構成するフィールド毎に更新状況が格納される。

図１１は、更新ビットマップ２２７の一例を示すマップである。更新ビットマップ２２７は、図３に示したゲスト状態エリア２２１〜ＶＭ−ｅｘｉｔ情報領域２２６に対応するエリア名２２７１と、エリア名２２７１を構成するフィールド名２２７２と、当該エントリのフィールド名２２７２またはエリア名２２７１に対応するゲストＶＭＣＳ２２の値に、シャドウＶＭＣＳ＃０の値がホストＶＭＭ１０３によって更新されたか否かを示すアップデート状態（図中Updated）２２７３と、当該エントリのフィールド名２２７２またはエリア名２２７１に対応するゲストＶＭＣＳ２２の値がゲストＶＭＭ１０９によって更新されたか否かを示すダーティ状態（図中Dirty）２２７４からひとつのエントリが構成される。なお、図１１では、シャドウＶＭＣＳ１３０のフィールドの一部を省略したが、ＶＴ−ｘで規定されるフィールドを適宜設定することができる。

フィールド名２２７２またはエリア名２２７１に対応するゲストＶＭＣＳ２２の値がホストＶＭＭ１０３によって更新されていればアップデート状態２２７３には「１」がセットされ、更新されていなければ「０」が格納される。

フィールド名２２７２またはエリア名２２７１に対応するゲストＶＭＣＳ２２の値がゲストＶＭＭ１０９によって更新されていればダーティ状態２２７４には「１」がセットされ、更新されていなければ「０」が格納される。

エミュレータを提供する命令コード２３０のＶＭＲＥＡＤエミュレータ２３１は、更新ビットマップ２２７を参照して、ホストＶＭＭ１０３によって更新済の値をゲストＶＭＣＳ２２から読み込んで、ゲストＶＭＭ１０９に応答する。

また、ＶＭＲＥＡＤエミュレータ２３１は、更新ビットマップ２２７を参照してゲストＶＭＣＳ２２の更新状況を確認する。ホストＶＭＭ１０３によって更新されていないゲストＶＭＣＳ２２の要素についてはホストＶＭＭ１０３にシャドウＶＭＣＳ１３０の読み込みを依頼する。この場合は、ＶＭ−ｅｘｉｔを発生してホストＶＭＭ１０３にシャドウＶＭＣＳ１３０を読み込ませ、ＶＭＲＥＡＤの対象となるフィールドに対応するゲストＶＭＣＳ２２の値、およびアップデート状態２２７３を更新する。以上により、ＶＭＲＥＡＤエミュレータ２３１は、ゲストＶＭＣＳ２２の全ての要素についてシャドウＶＭＣＳ１３０の値で更新済の値をゲストＶＭＭ１０９に応答する。

エミュレータを提供する命令コード２３０のＶＭＷＲＩＴＥエミュレータ２３２は、仮想ＶＭＷＲＩＴＥ命令が指示する値をゲストＶＭＣＳ２２に書き込む。そして、ゲストＶＭＣＳ２２に書き込んだエリア名２２７１及びフィールド名２２７２に対応するエントリのダーティ状態２２７４を１にセットし、ホストＶＭＭ１０３が参照したときにゲストＶＭＭ１０９が更新したことを明示する。

なお、ゲストＶＭＭ１０９からのＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２を呼び出す方法としては、ＶＭＭコードのバイナリ変換（例えば、ＶＭＲＥＡＤ命令やＶＭＷＲＩＴＥ命令をＭＯＶＥ命令に置き換えてシャドウＶＭＣＳを読み込む）、もしくは準仮想化によるＶＭＭコードの静的改変によってＶＭＲＥＡＤ命令及びＶＭＷＲＩＴＥ命令を変換しておき、物理ＣＰＵ１０４でＶＭ−ｅｘｉｔの発生を抑止する。

＜ホストＶＭＭの動作の概要＞
ここで、ＶＭ−ｅｘｉｔの発生要因は、図６、図７に示すように、シャドウＶＭＣＳ＃０のＶＭ−ｅｘｉｔ情報領域１３６の「Ｅｘｉｔ ｒｅａｓｏｎ」に設定されたものである。図７に示すＶＭ−ｅｘｉｔの要因リストには、ＶＭ−ｅｎｔｒｙ命令の発行に起因する要因１３６１と、ＶＭＣＬＥＡＲ命令（第４制御命令）の発行に起因する要因１３６２と、ゲストＶＭＭ１０９へのＶＭ−ｅｘｉｔ通知の有無を設定した通知条件１３６３が予め設定される。なお、図７では、ＶＭＲＥＡＤ命令、ＶＭＷＲＩＴＥ命令等を省略したが、ＶＴ−ｘで規定されるＶＭ−ｅｘｉｔの発生要因を適宜設定することができる。

例えば、仮想ＣＰＵ１０８ａの動作モードを切り替える際のＶＭ−ｅｘｉｔの要因として、ＶＭ−ｅｎｔｒｙ命令（ＶＭＬＡＵＮＣＨ命令またはＶＭＲＥＳＵＭＥ命令）を検出した場合には、図７の要因１３６１に該当するので、ホストＶＭＭ１０３はＶＭ−ｅｎｔｒｙ命令実行モジュールでエミュレーションを行い、ゲストＶＭＭ１０９またユーザプログラム１１０ａに代わって処理を行う。

あるいは、ＶＭ−ｅｘｉｔの要因が、図７の通知条件１３６３に該当するゲストＶＭＭへの通知条件の場合には、ＶＭ−ｅｘｉｔ命令実行モジュール１２２２を起動して同様にエミュレーションを行う。

状態エリア選択部１２１は、ホストＶＭＭ保持データ１１からＶＭ−ｅｘｉｔを発生した仮想ＣＰＵ（この例では１０８ａ）の動作モードフラグ１４３を読み込んで、ＶＭＸルートモードとＶＭＸノンルートモードの何れであるかを判定する。動作モードフラグ１４３が「０」のＶＭＸルートモードであればゲストＶＭＭ１０９が動作していたので、状態エリア選択部１２１は、ＶＭ−ｅｘｉｔを発生した仮想サーバ（この例では１０２ａ）のゲストＶＭＣＳ２２からホスト状態エリア２２２を読み込む。

一方、動作モードフラグ１４３が「１」のＶＭＸノンルートモードであればユーザプログラム１１０ａが動作していたので、状態エリア選択部１２１は、該当する仮想サーバ１０２ａのゲストＶＭＣＳ２２からゲスト状態エリア２２１を読み込む。

ゲストＶＭＣＳ２２からの読み込みが完了すると、ＣＰＵ制御部１２ではシャドウＶＭＣＳ参照・更新モジュール１２３を起動する。シャドウＶＭＣＳ参照・更新モジュール１２３は、状態エリア選択部１２１が読み込んだゲストＶＭＣＳ２２の情報を、ＶＭ−ｅｘｉｔの処理対象である仮想ＣＰＵ１０８ａに対応するシャドウＶＭＣＳ＃０のゲスト状態エリア１３１に書き込んでシャドウＶＭＣＳを更新する。

シャドウＶＭＣＳ＃０のゲスト状態エリア１３１の更新が完了すると、ＣＰＵ制御部１２は仮想ＣＰＵ１０８ａの動作モードをＶＭＸルートモードからＶＭＸノンルートモードへ切り替えるため、動作モードフラグ１４３を「１」に更新し、物理ＣＰＵ１０４のポインタ１１５に操作対象の仮想ＣＰＵ１０８ａのシャドウＶＭＣＳ＃０のアドレスをセットする。

そして、ＣＰＵ制御部１２は、ＶＭ−ｅｎｔｒｙ命令発行モジュール１２５を起動して、物理ＣＰＵ１０４に対してＶＭ−ｅｎｔｒｙ命令（ＶＭＲＥＳＵＭＥ命令）を発行する。

物理ＣＰＵ１０４はＶＭ−ｅｎｔｒｙ命令を受け付けると、ポインタ１１５が指し示すシャドウＶＭＣＳ＃０のゲスト状態エリア１３１を読み込んで、状態エリア選択部１２１が選択した仮想サーバ１０２ａのゲストＶＭＭ１０９またはユーザプログラム１１０ａを実行する。

一方、上記ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１がゲストＶＭＣＳ２２を参照したときに、仮想ＶＭＲＥＡＤ命令で指定されたデータがシャドウＶＭＣＳ１３０の値で更新されていなければ（更新ビットマップのアップデート状態２２７３が「０」）には、ゲストＶＭＭ１０９がＶＭＸルートモードでＶＭＲＥＡＤ命令を発生要因とするＶＭ−ｅｘｉｔが発生する。

この場合には、ホストＶＭＭ１０３のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５でエミュレータ処理が行われ、シャドウＶＭＣＳ＃１からデータを読み込んで、ゲストＶＭＣＳ２２に反映する。そして、ゲストＶＭＣＳ２２に反映したデータについて先行読み出しが行われていなかったので、先行読み出しエントリ情報１２３１の該当フィールドに「１」をセットして、次回以降の仮想ＶＭＲＥＡＤ命令でＶＭ−ｅｘｉｔが発生するのを抑止する。

また、ユーザプログラム１１０ａからＶＭＸノンルートモードでＶＭ−ｅｘｉｔが発生し、かつゲストＶＭＭに対するＶＭ−ｅｘｉｔ通知条件を満たしている場合には、ホストＶＭＭ１０３のＶＭ−ｅｘｉｔ命令実行モジュール１２２３により先行読み出しが行われる。これにより、ゲストＶＭＭ１０９のゲストＶＭＣＳ２２がシャドウＶＭＣＳ１３０の最新の値で更新される。

上記のような仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令によるＶＭ−ｅｘｉｔの発生を抑制するための処理は、図１６で示すようになる。図１６は、シャドウＶＭＣＳ＃０，＃１とゲストＶＭＣＳ２２に対するホストＶＭＭ１０３とゲストＶＭＭ１０９のアクセスの一例を示すタイムチャートである。

時刻Ｔ１では、ユーザプログラム１１０ａの命令実行中に仮想ＣＰＵ１０８ａの動作モードを切り替える仮想的なＶＭ−ｅｘｉｔに相当する、物理的なＶＭ−ｅｘｉｔが発生した場合を示す。仮想的なＶＭ−ｅｘｉｔの例としては、ユーザプログラム１１０ａによるゲストＶＭＭ１０９の明示的な呼び出し命令であるＶＭＣＡＬＬ命令の発行が挙げられる。

このＶＭＸノンルートモードでのＶＭ−ｅｘｉｔによりホストＶＭＭ１０３へ制御が移る。ホストＶＭＭ１０３は、ＶＭ−ｅｘｉｔの発生要因がゲストＶＭＭ１０９に対するＶＭ−ｅｘｉｔの通知条件に一致するので、図３のＶＭ−ｅｘｉｔ命令実行モジュール１２２２を起動する。

ＶＭ−ｅｘｉｔ命令実行モジュール１２２２は、後述の図１２で示すようにシャドウＶＭＣＳ＃１の一括読み出しを実行する。すなわち、ＶＭ−ｅｘｉｔ命令実行モジュール１２２２は、ＶＭ−ｅｘｉｔの発生要因から先行読み出しエントリ情報１２３１を参照し、シャドウＶＭＣＳ＃１からエントリ１２３１３の値が「１」のフィールドを一括して読み込む。ホストＶＭＭ１０３のＶＭ−ｅｘｉｔ命令実行モジュール１２２２は、一括して読み込んだフィールドの値をゲストＶＭＣＳ２２に書き込んでから、更新ビットマップ２２７のアップデート状態２２７３を「１」にセットする。

この後、時刻Ｔ３では、ホストＶＭＭ１０３は、物理ＣＰＵ１０４に対してＶＭ−ｅｎｔｒｙを発行してゲストＶＭＭ１０９に制御を移す。

時刻Ｔ４〜Ｔ５の間では、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１またはＶＭＷＲＩＴＥエミュレータ２３２が動作した例を示し、仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令によって、ゲストＶＭＣＳ２２の読み込みまたは書き込みが行われる。すなわち、仮想ＶＭＲＥＡＤ命令の場合には、時刻Ｔ２〜Ｔ３の先行読み出しによって、仮想ＶＭＲＥＡＤ命令を代行するＶＭＲＥＡＤエミュレータ２３１は、ＶＭ−ｅｘｉｔを発生することなくゲストＶＭＣＳ２２の読み込みを実施できる。

また、仮想ＶＭＷＲＩＴＥ命令を代行するＶＭＷＲＩＴＥエミュレータ２３２は、ＶＭ−ｅｘｉｔを発生することなくゲストＶＭＣＳ２２に書き込みを行う。このとき、ＶＭＷＲＩＴＥエミュレータ２３２は、更新したフィールドについて、更新ビットマップ２２７のダーティ状態２２７４を「１」にセットする。

次に、時刻Ｔ５でゲストＶＭＭ１０９の動作中にＶＭ−ｅｎｔｒｙ命令が発行されてＶＭ−ｅｘｉｔが発生したとする。この場合、ＶＭＸルートモードであるので、ホストＶＭＭ１０３はＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１を起動する。

ＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１は、時刻Ｔ６でゲストＶＭＣＳ２２のゲスト状態エリア２２１を読み込む。そして、ＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１は、操作対象の仮想ＣＰＵに対応するシャドウＶＭＣＳ＃１をアクティブに設定し、上記読み込んだゲスト状態エリア２２１の情報で操作対象のシャドウＶＭＣＳ＃１のゲスト状態エリア１３１を更新する。このとき、ＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１は、更新ビットマップ２２７のダーティ状態２２７４が「１」のフィールドのみを更新することで、シャドウＶＭＣＳ＃１のゲスト状態エリア１３１の更新を高速で実行することが可能となる。

この後、時刻Ｔ７でＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１は、ＶＭ−ｅｎｔｒｙ命令を発行して、制御をホストＶＭＭ１０３からユーザプログラム１１０ａに移す。

以上のように、時刻Ｔ２でシャドウＶＭＣＳ＃１のデータを先行読み出しエントリ情報１２３１の定義によって一括して読み込んで、ゲストＶＭＣＳ２２を更新しておくことで、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１はＶＭ−ｅｘｉｔを発生させることなくゲストＶＭＣＳ２２の読み込みを実現できる。

また、ゲストＶＭＭ１０９のＶＭＷＲＩＴＥエミュレータ２３２はＶＭ−ｅｘｉｔを発生させることなくゲストＶＭＣＳ２２への書き込みを実現できる。そして、次回のユーザプログラム１１０ａへの制御移行時に、ゲストＶＭＣＳ２２に書き込んだデータをシャドウＶＭＣＳ＃１に反映させることができるのである。

＜ホストＶＭＭの処理の詳細＞
次に、ホストＶＭＭ１０３のＣＰＵ制御部１２で行われる処理について、図８を参照しながら以下に説明する。図８は、ホストＶＭＭ１０３のＣＰＵ制御部１２が仮想サーバ１０２ａ〜１０２ｂの稼動稼働中に物理ＣＰＵ１０４からのＶＭ−ｅｘｉｔを受信したときに実行する処理の一例を示すフローチャートである。

まず、ステップＳ１では、ホストＶＭＭ１０３のＣＰＵ制御部１２は、ホストＶＭＭ保持データ１１の仮想化機能有効フラグ１４１を参照し、ＶＭ−ｅｘｉｔを発生した孫ＯＳ１１１ａ〜１１１ｂ（以下、孫ＯＳとする）がＶＴ−ｘ機能を利用可能であるか否かを判定する。操作対象の孫ＯＳがＶＴ−ｘ機能を利用可能である場合にはステップＳ２へ進む。一方、操作対象の孫ＯＳがＶＴ−ｘ機能を利用しない（または利用できない）場合（ＮＴサーバまたは２０００サーバなど）には、ステップＳ１５へ進んで、ホストＶＭＭ１０３は前記従来例に示した特許文献１または非特許文献１に記載されるような仮想マシン処理を行う。

ステップＳ２では、ホストＶＭＭ１０３がＶＭＸＯＮフラグ１４２を参照し、ＶＭ−ｅｘｉｔの要因となった仮想ＣＰＵ１０８ａ〜１０８ｂ（以下、仮想ＣＰＵとする）がＶＭＸモードであるか否かを判定する。ＶＭＸＯＮフラグ１４２が「１」であれば仮想ＣＰＵはＶＭＸモードであるのでステップＳ３へ進む。一方、ＶＭＸＯＮフラグ１４２が「０」の場合には、仮想ＣＰＵが通常の動作モードであるので、上記と同様にステップＳ１５へ進み、ホストＶＭＭ１０３は既存の仮想マシン処理を実行する。

ステップＳ３では、ホストＶＭＭ１０３のＣＰＵ制御部１２が、操作対象の仮想ＣＰＵの動作モードフラグ１４３を参照し、仮想ＣＰＵの動作モードがＶＭＸルートモードとＶＭＸノンルートモードの何れであるかを判定する。動作モードフラグ１４３が「０」の場合には仮想ＣＰＵがＶＭＸルートモードであると判定してステップＳ４へ進む。一方、動作モードフラグ１４３が「１」の場合には、仮想ＣＰＵがＶＭＸノンルートモードであると判定してＳ１１へ進む。

ステップＳ４では、ＣＰＵ制御部１２が物理ＣＰＵ１０４から受信したＶＭ−ｅｘｉｔの発生要因を特定する。ステップＳ４では、仮想ＣＰＵの動作モードがＶＭＸルートモードであるので、ＣＰＵ制御部１２は、ゲストＶＭＭ１０９の状態（ステータス）を格納したシャドウＶＭＣＳ１３０（この例ではシャドウＶＭＣＳ＃０とする）を特定し、シャドウＶＭＣＳ＃０のゲスト状態エリア１３１を参照して、ＶＭ−ｅｘｉｔの発生要因を特定する。ＣＰＵ制御部１２は、ＶＭ−ｅｘｉｔの発生要因としてＶＭ−ｅｎｔｒｙ命令（仮想ＶＭ−ｅｎｔｒｙ命令＝第１のイベント）を検出した場合にはステップＳ５の処理へ進み、ＶＭ−ｅｘｉｔの発生要因としてＶＭＲＥＡＤ命令を検出した場合にはステップＳ１６の処理へ進み、その他の場合にはステップＳ１１の処理へ進む。

ＶＭ−ｅｘｉｔの発生要因がＶＭ−ｅｎｔｒｙ命令の場合のステップＳ５では、ＣＰＵ制御部１２は、エミュレータ１２２からＶＭ−ｅｎｔｒｙ命令実行モジュール１２２１を実行し、操作対象の仮想ＣＰＵをＶＭＸノンルートモードへ切り替えるのに必要な所定の処理（状態エリア選択部１２１の起動など）をゲストＶＭＭ１０９に代わってエミュレートする。

次に、ステップＳ６ではホストＶＭＭ１０３のＣＰＵ制御部１２は、仮想ＣＰＵの動作モードをＶＭＸルートモードからＶＭＸノンルートモードへ移行させるので、操作対象の仮想ＣＰＵの動作モードフラグ１４３を「１」に更新する。

ステップＳ７では、ＣＰＵ制御部１２が操作対象のゲストＶＭＭ１０９の仮想ＣＰＵ制御データ１１４のゲストＶＭＣＳ２２からゲスト状態エリア２２１に格納されている孫ＯＳまたはアプリケーションのステータスを読み込む。

次に、ステップＳ８において、ＣＰＵ制御部１２は、物理ＣＰＵ１０４に対してＶＭＰＴＬＤＲ命令を発行して、操作対象の仮想ＣＰＵに対応するシャドウＶＭＣＳ＃０をアクティブに設定し、アクティブにしたシャドウＶＭＣＳ＃０のアドレスをポインタ１１５に設定する。このＶＭＰＴＬＤＲ命令（第２制御命令）により、ホストＶＭＭ１０３は、複数のシャドウＶＭＣＳ＃０〜＃ｎ−１の中から操作対象の仮想ＣＰＵ（仮想サーバ）のシャドウＶＭＣＳを選択する。

ステップＳ９では、ＣＰＵ制御部１２が、上記ステップＳ７で読み込んだゲスト状態エリア２２１の情報と後述する更新ビットマップ２２７に基づいて、操作対象のシャドウＶＭＣＳ＃０のゲスト状態エリア１３１を更新する。このシャドウＶＭＣＳ＃０の更新処理については、図１４のサブルーチンにて詳述する。

そして、Ｓ１０でＣＰＵ制御部１２は、物理ＣＰＵ１０４に対してＶＭ−ｅｎｔｒｙ命令を発行する。

ＶＭ−ｅｎｔｒｙ命令を受け付けた物理ＣＰＵ１０４は、ポインタ１１５で指定されたシャドウＶＭＣＳ＃０のゲスト状態エリア１３１の内容に基づいて、操作対象の仮想サーバのゲストＶＭＭ１０９またはユーザプログラム１１０ａ（以下、ユーザプログラムとする）を実行する。

一方、上記Ｓ３で動作モードフラグ１４３が「１」と判定された場合は、操作対象の仮想ＣＰＵがユーザプログラムを実行中のＶＭＸノンルートモードであるので、Ｓ１１の処理を行う。

Ｓ１１では、ＣＰＵ制御部１２が図７のＶＭ−ｅｘｉｔの要因リストを参照し、ゲストＶＭＭへのＶＭ−ｅｘｉｔ通知条件１３６３を検索する。ユーザプログラムを実行中のＶＭ−ｅｘｉｔの発生要因がＶＭ−ｅｘｉｔ通知条件１３６３に一致していれば、ゲストＶＭＭ１０９にＶＭ−ｅｘｉｔの通知を行うためステップＳ１２へ進む。一方、ユーザプログラムを実行中のＶＭ−ｅｘｉｔの発生要因がＶＭ−ｅｘｉｔ通知条件１３６３に一致していなければ、ステップＳ１５に進んで従来と同様の仮想マシン処理を行う。

ゲストＶＭＭ１０９にＶＭ−ｅｘｉｔの通知を行うステップＳ１２では、ＣＰＵ制御部１２が図３のＶＭ−ｅｘｉｔ命令実行モジュール１２２２を実行し、操作対象の仮想ＣＰＵをＶＭＸルートモードへ切り替えるのに必要な所定の処理（状態エリア選択部１２１の起動など）をエミュレートする。

図１２は、上記ステップＳ１２でホストＶＭＭ１０３が実行するＶＭ−ｅｘｉｔ命令実行モジュール１２２２のエミュレーション処理のサブルーチンを示すフローチャートである。このフローチャートは、ＶＭＸノンルートモードで、図３に示したＶＭ−ｅｘｉｔ命令実行モジュール１２２２が行う処理を示す。

ステップＳ２１では、ホストＶＭＭ１０３のＶＭ−ｅｘｉｔ命令実行モジュール１２２２が、仮想ＣＰＵ制御データ１１４の更新ビットマップ２２７のアップデート状態２２７３とダーティ状態２２７４の全エントリを０でクリアする。

ステップＳ２２では、ホストＶＭＭ１０３がＶＭ−ｅｘｉｔの発生要因となったユーザプログラムに対応するシャドウＶＭＣＳ＃１から発生要因１３６０を取得する。なお、ＶＭＸノンルートモードのときに、図８のステップＳ１２の処理が行われるので、ホストＶＭＭ１０３は、ＶＭＸノンルートモードで用いるシャドウＶＭＣＳ＃１を読み込む。

そして、ホストＶＭＭ１０３は、ＣＰＵ制御部１２のシャドウＶＭＣＳ参照・更新部１２３の仮想ＶＭ−ｅｘｉｔ契機情報１２３２に、上記取得した発生要因１３６０を格納する。

次に、ステップＳ２３ではホストＶＭＭ１０３が、シャドウＶＭＣＳ参照・更新部１２３の先行読み出しエントリ情報１２３１を参照し、上記取得した発生要因１３６０に対応する列（対象エントリ１２３１３）を取得する。

ステップＳ２４ではホストＶＭＭ１０３が、ステップＳ２３で取得した先行読み出しエントリ情報１２３１の列の先頭のエントリ（例えば、図９のゲスト状態エリアのＣＳに対応するエントリ１２３１３）を参照する。

そして、ステップＳ２５では、ホストＶＭＭ１０３が参照したエントリの値が「１」であるか否かを判定する。当該エントリの値が「１」であればステップＳ２６に進む。

ステップＳ２６では、ホストＶＭＭ１０３が先行読み出しエントリ情報１２３１のエリア名１２３１１及びフィールド名１２３１２で指定されるシャドウＶＭＣＳ＃１のフィールドの値を取得する。すなわち、図１２の処理は、図８のステップＳ３、Ｓ１１、Ｓ１２で行われるので、ＶＭＸノンルートモードでのＶＭ−ｅｘｉｔであり、図５で示したように、シャドウＶＭＣＳ＃１を参照する。一方、当該エントリの値が「０」であればステップＳ３０に進んで、ホストＶＭＭ１０３は次のエントリを参照して上記ステップＳ２５の処理を繰り返す。

ステップＳ２７では、ホストＶＭＭ１０３が上記Ｓ２６で取得したフィールドの値を、先行読み出しエントリ情報１２３１のエリア名１２３１１及びフィールド名１２３１２で指定されるゲストＶＭＣＳ２２の該当フィールドに書き込んで更新する。

次に、ステップＳ２８では、ホストＶＭＭ１０３は現在参照している先行読み出しエントリ情報１２３１に対応する更新ビットマップ２２７のアップデート状態２２７３を「１」にセットして、ゲストＶＭＣＳ２２の該当フィールドを更新したことを明示する。

そして、ステップＳ２８では、ステップＳ２３で取得した先行読み出しエントリ情報１２３１の列のエントリ１２３１３のうち値が「１」に設定された全てのエントリについて、シャドウＶＭＣＳ＃１の値でゲストＶＭＣＳ２２の値を更新したか否かをホストＶＭＭ１０３が判定する。取得した列の全てのエントリについて処理が完了していれば図１２のサブルーチンを終了して、図８の処理に戻る。一方、取得した列の全てのエントリについて処理が完了していなければステップＳ３０に進んで、次のエントリを参照してから上記Ｓ２５〜Ｓ２８の処理を繰り返す。

上記図１２の処理によって、ＶＭＸノンルートモードでＶＭ−ｅｘｉｔが発生した場合、かつ発生要因１３６０がゲストＶＭＭへのＶＭ−ｅｘｉｔ通知条件１３６１に合致する場合には、図１２のＶＭ−ｅｘｉｔ命令実行モジュール１２２２によって、ＶＭ−ｅｘｉｔの発生要因に応じた先行読み出しエントリ情報１２３１の列（エントリ１２３１３）を選択し、当該列の値が「１」のエントリの全てのフィールドについて、シャドウＶＭＣＳ＃１から一括して読み出して、ゲストＶＭＣＳ２２を更新することができる。

すなわち、ＶＭ−ｅｘｉｔの発生要因からシャドウＶＭＣＳ＃０のどのフィールドを読み出す必要があるか否かを先行読み出しエントリ情報１２３１に定義しておくことで、ＶＭＸノンルートモードのときに１回のＶＭ−ｅｘｉｔの発生でシャドウＶＭＣＳ＃１の複数のフィールドの値を一括して読み込んでおき、ゲストＶＭＣＳ２２をシャドウＶＭＣＳ＃１の値で更新することができる。これにより、ＶＭ−ｅｘｉｔの発生要因から、ゲストＶＭＭ１０９が仮想ＶＭＲＥＡＤ命令で参照する確率の高いシャドウＶＭＣＳ＃１のフィールドの値をゲストＶＭＣＳ２２に書き込んでおくことでゲストＶＭＣＳ２２を参照する際のＶＭ−ｅｘｉｔ多発を抑止できる。

上記図１２のサブルーチンが完了すると、図８のステップＳ１３の処理に進む。

次に、Ｓ１３では、操作対象の仮想ＣＰＵの動作モードをＶＭＸノンルートモードからＶＭＸルートモードへ移行させるため、ＣＰＵ制御部１２が操作対象の仮想ＣＰＵの動作モードフラグ１４３を「１」から「０」にリセットする。そして、ステップＳ１４では、ＣＰＵ制御部１２が操作対象のゲストＶＭＭ１０９の仮想ＣＰＵ制御データ１１４からホスト状態エリア２２１に格納されているゲストＶＭＭ１０９のステータスを読み込む。

ステップＳ１４の処理が完了すると、ステップＳ８ｂ、Ｓ９ｂ、Ｓ１０の処理を順に実施する。Ｓ８ｂでは、ＶＭＰＴＲＬＤ命令を発行してシャドウＶＭＣＳ＃１から＃０に切り替える。Ｓ９ｂでは、上記Ｓ１４で読み込んだホスト状態エリア２２２の情報で操作対象のシャドウＶＭＣＳ１３０のゲスト状態エリア１３１を更新し、ゲストＶＭＭ１０９のステータスをセットする。なお、ゲストＶＭＭ１０９がホスト状態エリアを変更しないことが判明している場合、本処理をスキップする実装があっても構わない。

Ｓ１０で物理ＣＰＵ１０４に対してＶＭ−ｅｎｔｒｙ命令を発行する。

この結果、ＶＭ−ｅｎｔｒｙ命令を受け付けた物理ＣＰＵ１０４は、ポインタ１１５で指定されたシャドウＶＭＣＳ１３０のゲスト状態エリア１３１の内容に基づいて、操作対象の仮想サーバのゲストＶＭＭ１０９を実行する。

上記処理により、孫ＯＳ１１１ａが仮想化機能を統合した新世代ＯＳである場合、ホストＶＭＭ１０３は、仮想ＣＰＵ１０８ａの動作モードと、発生したＶＭ−ｅｘｉｔの要因に応じてシャドウＶＭＣＳ１３０のゲスト状態エリア１３１に書き込むステータスを、ゲストＶＭＭまたはユーザプログラムの何れか一方から選択する。そして、ホストＶＭＭ１０３が物理ＣＰＵ１０４（第１の仮想ＣＰＵ）に対してＶＭ−ｅｎｔｒｙ命令を発行することで、仮想サーバ上でゲストＶＭＭと、このゲストＶＭＭが提供する第２の仮想ＣＰＵ上で稼動するユーザプログラムを切り替えて実行することが可能となり、ゲストＶＭＭは仮想サーバ上に複数の仮想化環境（ユーザプログラム）を提供することができる。

次に、ゲストＶＭＭ９０２による仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令によってＶＭ−ｅｘｉｔが多発するのを抑制するための処理について以下に説明する。

上記図８のステップＳ４では、ＶＭＸルートモードで、かつＶＭ−ｅｘｉｔの発生要因がＶＭＲＥＡＤ命令の場合には、ステップＳ１６に進んで、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５のエミュレータ処理を実行する。なお、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５のエミュレータ処理ついては、図１５のサブルーチンにて詳述する。

ステップＳ１６でシャドウＶＭＣＳ＃１の読み出しが終了すると、上記ステップＳ１０に進んで、ゲストＶＭＭ１０９のステータスをセットしてから物理ＣＰＵ１０４に対してＶＭ−ｅｎｔｒｙ命令を発行する。本ＶＭ−ｅｎｔｒｙ命令の発行後、物理ＣＰＵ１０４は図１３のＳ４５からＶＭＲＥＡＤエミュレータの処理を再開する。

図１４は、上記図８のステップＳ９で行われるシャドウＶＭＣＳの更新処理の一例を示すサブルーチンのフローチャートである。この処理は、図８のステップＳ５に続いて実行され、ステップＳ６でＶＭＸノンルートモードに変更されるので、ホストＶＭＭはシャドウＶＭＣＳ＃１を参照する。

仮想ＶＭＷＲＩＴＥ命令でゲストＶＭＣＳ２２に書き込まれたデータを、シャドウＶＭＣＳ１３０のゲスト状態エリア１３１に書き込んで更新する処理が行われる。この処理は、ＣＰＵ制御部１２のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５が行う。

ステップＳ５１では、ホストＶＭＭ１０３がゲストＶＭＭ１０９の更新ビットマップ２２７を参照する。ステップＳ５２では、ホストＶＭＭ１０３が更新ビットマップ２２７の先頭エントリ（例えば、図１１のＣＳ）のダーティ状態２２７４を参照する。ステップＳ５３では、参照したダーティ状態２２７４が「１」であるか否かを判定する。ホストＶＭＭ１０３は、参照したダーティ状態２２７４が「０」であれば、ゲストＶＭＣＳ２２の該当フィールドは更新されていないので、ステップＳ５７で次のエントリを参照してからステップＳ５３の処理を繰り返す。

一方、ホストＶＭＭ１０３は、参照したダーティ状態２２７４が「１」であれば、ゲストＶＭＣＳ２２の該当フィールドが更新されているので、ステップＳ５４に進んで、ダーティ状態２２７４に対応するフィールドの値をゲストＶＭＣＳ２２から読み込む。

次に、ステップＳ５５では、ホストＶＭＭ１０３が上記ステップＳ５４で読み込んだフィールドの値を、シャドウＶＭＣＳ１３０の該当フィールドに書き込んで更新する。

ステップＳ５６では、ホストＶＭＭ１０３が更新ビットマップ２２７の全てのエントリについて処理が完了していればサブルーチンを終了して図８に復帰する。一方、更新ビットマップ２２７の全てのエントリについて処理が完了していなければ、ステップＳ５７に進んで、上記ステップＳ５３〜Ｓ５６の処理を繰り返す。

上記の処理により、更新ビットマップ２２７のダーティ状態２２７４が「１」となっているゲストＶＭＣＳ２２のフィールドの値が、シャドウＶＭＣＳ１３０に反映される。

次に、図１５は上記図８のステップＳ１６で行われるＶＭＲＥＡＤ命令処理の一例を示すフローチャートである。このフローチャートは、図３のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５で行われる処理を示す。この処理は、後述するゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１によってＶＭ−ｅｘｉｔが発生した場合に実行される処理で、ＶＭＸルートモードで発生したＶＭ−ｅｘｉｔの発生要因がＶＭＲＥＡＤ命令である。

ステップＳ６１では、ホストＶＭＭ１０３のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５がシャドウＶＭＣＳ＃０のＶＭ−ｅｘｉｔ情報領域１３６を参照し、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１が発行したＶＭＲＥＡＤ命令の命令アドレスを取得する。

ステップＳ６２では、ホストＶＭＭ１０３が上記ステップＳ６１で取得した命令アドレスのＶＭＲＥＡＤ命令をデコードして、オペランド情報を取得する。ここで、オペランド情報は、例えば、第１のオペランド情報がＶＭＲＥＡＤ命令の結果を返すレジスタ番号を示し、第２のオペランド情報がＶＭＲＥＡＤ命令で参照すべきシャドウＶＭＣＳ＃０のフィールド情報を示す。

ステップＳ６３では、上記ステップＳ６２で取得した第２のオペランド情報からＶＭＲＥＡＤ命令で読み込むシャドウＶＭＣＳ＃０のフィールドを特定する。

ステップＳ６４では、ホストＶＭＭ１０３がＶＭＰＴＲＬＤ命令を物理ＣＰＵ１０４に発行して、シャドウＶＭＣＳ１３０をユーザプログラム用であるＶＭＸノンルートモードのシャドウＶＭＣＳ＃１に切り替える。すなわち、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１は、ユーザプログラム１１０ａがどのように動いていたか、というステータスを取得したいので、ホストＶＭＭ１０３は読み込む対象のシャドウＶＭＣＳ１３０をＶＭＸノンルートモードのシャドウＶＭＣＳ＃１に切り替える。

ステップＳ６５では、ホストＶＭＭ１０３がＶＭＲＥＡＤ命令を発行し、上記ステップＳ６３で特定したフィールドの情報を、上記切り替えたシャドウＶＭＣＳ＃１から読み込む。

次に、ステップＳ６６では、ホストＶＭＭ１０３は、ステップＳ６５で取得したシャドウＶＭＣＳ＃１のフィールドの値をゲストＶＭＣＳ２２に書き込んでフィールドの情報を更新する。

ステップＳ６７では、ホストＶＭＭ１０３がＶＭＰＴＲＬＤ命令を物理ＣＰＵ１０４に発行して、シャドウＶＭＣＳ１３０をゲストＶＭＭ１０９用であるＶＭＸルートモードで用いるシャドウＶＭＣＳ＃０に切り替えて、本来ホストＶＭＭ１０３が操作すべきシャドウＶＭＣＳ１３０に戻す。

ステップＳ６８では、ホストＶＭＭ１０３が上記ステップＳ６３で特定したフィールドに対応する更新ビットマップ２２７のアップデート状態２２７３を「１」にセットし、シャドウＶＭＣＳ＃１の値をゲストＶＭＣＳ２２に反映したことを記録する。

ステップＳ６９、Ｓ７０では、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１からのＶＭ−ｅｘｉｔの発生要因は、上記ステップＳ６３で特定したフィールドが先行読み出しエントリ情報１２３１で「１」になっていないため、と推定される。このため、次回のＶＭＲＥＡＤ命令でＶＭ−ｅｘｉｔが発生しないように、学習を行う。

まず、ステップＳ６９では、仮想ＶＭＲＥＡＤ命令による仮想ＶＭ−ｅｘｉｔの発生要因を仮想ＶＭ−ｅｘｉｔ契機情報として特定する。そしてホストＶＭＭ１０３は、先行読み出しエントリ情報１２３１のうち、仮想ＶＭ−ｅｘｉｔ契機情報に対応するエントリ１２３１３の列を特定する。

次に、ステップＳ７０では、上記特定された列のうち、上記ステップＳ６３で特定したフィールドに対応するエントリ１２３１３を「１」にセットとして終了する。

上記の処理により、まず、ゲストＶＭＭ１０９のＶＭＲＥＡＤエミュレータ２３１が発行したＶＭＲＥＡＤ命令をＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５で実行し、シャドウＶＭＣＳ＃１の値をゲストＶＭＣＳ２２に反映させる。次に、ＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５は、先行読み出しエントリ情報１２３１のうち、ゲストＶＭＭ１０９がＶＭＲＥＡＤ命令を発行する契機となった仮想ＶＭ−ｅｘｉｔ契機情報に対応するエントリ１２３１３に「１」をセットすることで、今回ホストＶＭＭ１０３で実行したＶＭＲＥＡＤ命令の対象フィールドを、先行読み出しの対象に設定することで、次回以降のＶＭ−ｅｘｉｔの発生を抑止する。

＜ゲストＶＭＭの処理の詳細＞
図１３は、ゲストＶＭＭ１０９で行われるエミュレータ処理の一例を示すフローチャートである。図１３は、図３に示したゲストＶＭＭ１０９の命令コード２３０のＶＭＲＥＡＤエミュレータ２３１及びＶＭＷＲＩＴＥエミュレータ２３２の処理の一例を示し、図１３において、ステップＳ４２〜Ｓ４５がＶＭＲＥＡＤエミュレータ２３１を示し、ステップＳ４６〜Ｓ４８がＶＭＷＲＩＴＥエミュレータ２３２を示す。この処理では、ゲストＶＭＭ１０９がＶＭＲＥＡＤ命令またはＶＭＷＲＩＴＥ命令の実行に代わってこれらのエミュレータを起動する。

ゲストＶＭＭ１０９は仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令のいずれであるかを判定し、仮想ＶＭＲＥＡＤ命令であればステップＳ４２へ進んでＶＭＲＥＡＤエミュレータ２３１を起動し、仮想ＶＭＷＲＩＴＥ命令であればステップＳ４６に進んでＶＭＷＲＩＴＥエミュレータ２３２を起動する。

ＶＭＲＥＡＤエミュレータ２３１の処理では、ステップＳ４２でゲストＶＭＭ１０９は、仮想ＣＰＵ制御データ１１４の更新ビットマップ２２７を参照する。次に、ステップＳ４３では、仮想ＶＭＲＥＡＤ命令が指定する読み込み対象のフィールドについてアップデート状態２２７３が「１」であるか否かを判定する。

アップデート状態２２７３が「１」であれば、仮想ＶＭＲＥＡＤ命令の対象フィールドは、先行読み出しによってシャドウＶＭＣＳ１３０の最新の値でゲストＶＭＭ１０９が更新されているので、ステップＳ４５に進む。

一方、アップデート状態２２７３が「０」であればゲストＶＭＣＳ２２の該当フィールドは、シャドウＶＭＣＳ１３０の最新の値が反映されていないので、ステップＳ４４に進む。

ステップＳ４４では、ゲストＶＭＭ１０９が上記仮想ＶＭＲＥＡＤ命令で指定されたフィールドをシャドウＶＭＣＳ１３０から読み込むため、実際のＶＭＲＥＡＤ命令（物理ＶＭＲＥＡＤ命令）を物理ＣＰＵ１０４に対して発行する。

ゲストＶＭＭ１０９がＶＭＲＥＡＤ命令を実際に発行することで、物理ＣＰＵ１０４はＶＭ−ｅｘｉｔを発生して、ホストＶＭＭ１０３に制御を移す。そして、上記図１５の処理によって、仮想ＶＭＲＥＡＤ命令で要求されたフィールドの値を、シャドウＶＭＣＳ＃１からゲストＶＭＣＳ２２に反映し、上述の学習制御を行ってからＶＭ−ｅｎｔｒｙ命令でゲストＶＭＭ１０９に制御を移す。

ゲストＶＭＭ１０９は、次に、ステップＳ４５でシャドウＶＭＣＳ１３０の値で更新されたゲストＶＭＣＳ２２の対象フィールドの値を読み込んで、所定のデスティネーションに反映させる。所定のデスティネーションとしては、汎用レジスタもしくはメモリが指定される。

一方、仮想ＶＭＷＲＩＴＥ命令の発行時には、ステップＳ４６で、ゲストＶＭＭ１０９は仮想ＣＰＵ制御データ１１４の更新ビットマップ２２７を参照する。ステップＳ４７でゲストＶＭＭ１０９が仮想ＶＭＷＲＩＴＥ命令で指定されたフィールドに対応するダーティ状態２２７４を「１」にセットする。

そして、ゲストＶＭＭ１０９は、仮想ＶＭＷＲＩＴＥ命令で指定されたゲストＶＭＣＳ２２のフィールドに、仮想ＶＭＷＲＩＴＥ命令で指定されたデータを書き込む。

以上の処理により、ゲストＶＭＭ１０９はＶＭＲＥＡＤエミュレータ２３１もしくはＶＭＷＲＩＴＥエミュレータ２３２を介して、ＶＭ−ｅｘｉｔを発生することなくゲストＶＭＣＳ２２の読み込みまたは書き込みを行う。ただし、更新ビットマップ２２７が「０」の場合のみ、ゲストＶＭＭ１０９がＶＭＲＥＡＤ命令を発行し、これにより物理ＣＰＵ１０４はＶＭ−ｅｘｉｔを発生してホストＶＭＭ１０３が上述のＶＭＲＥＡＤ／ＶＭＷＲＩＴＥ命令実行モジュール１２２５を起動してシャドウＶＭＣＳ＃１の値でゲストＶＭＣＳ２２を更新するのである。

＜まとめ＞
なお、上記Ｓ１の判定で孫ＯＳが仮想化機能を利用しない場合、または上記Ｓ２の判定で、仮想ＣＰＵが物理ＣＰＵ１０４のＶＴ−ｘ機能を利用しない場合は、Ｓ１５において、前記従来例に示した特許文献１または非特許文献１の記載に準じた仮想マシン処理をホストＶＭＭ１０３で行えばよい。

Ｓ１５の仮想マシン処理は、例えば、図２に示した仮想サーバ１０２ｂの孫ＯＳ１１１ｂは、既存のＯＳであり、この孫ＯＳ１１１ｂまたはアプリケーション１１２ｂ（ユーザプログラム）が特権命令などの所定の命令を実行すると、上述したように物理ＣＰＵ１０４はＶＭ−ｅｘｉｔの発生をホストＶＭＭ１０３に通知する。

ホストＶＭＭ１０３は、物理ＣＰＵ１０４からのＶＭ−ｅｘｉｔの通知を受けると、ユーザプログラム（仮想ＣＰＵ１０８ｂ）のステータスをシャドウＶＭＣＳ＃ｎ−１のゲスト状態エリア１３１に格納する。そして、ホストＶＭＭ１０３は、ポインタ１１５のアドレスをホストＶＭＭ１０３のステータスを格納したホスト状態エリアに設定して、所定の処理を実行する。

ホストＶＭＭ１０３は、特権命令など所定の処理が完了すると、ホストＶＭＭ１０３のステータスをホスト状態エリア１３２へ格納し、ポインタ１１５のアドレスにゲスト状態エリア１３１を設定してから、ＶＭ−ｅｎｔｒｙ命令（ＶＭＲＥＳＵＭＥ命令）を発行して、制御を仮想ＣＰＵ１０８ｂに移動してユーザプログラムの実行を再開する。

このように、本発明によれば、仮想化機能を統合した新世代ＯＳと、既存のＯＳをひとつの物理サーバ１０１へ統合することが可能となって、物理サーバの数を削減してサーバの運用管理コストを削減することが可能となる。

さらに、上述のように、ホストＶＭＭ１０３は新世代ＯＳに対して仮想ＣＰＵがＶＴ−ｘ機能を提供するように見せかけることができ、仮想化ソフトウェアを統合したＯＳを確実に稼動稼働させることが可能となる。また、本発明のホストＶＭＭ１０３によれば、前記従来例のシミュレータのように、命令列の変換などのオーバーヘッドがなく、仮想計算機の性能を低下させることなく、仮想化機能を統合したＯＳを仮想サーバで実行することが可能となるのである。

そして、ゲストＶＭＣＳ２２を参照または更新する際には仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令を発行し、ＶＭ−ｅｘｉｔが頻繁に発生するのを抑制しながらアクセスを行うことが可能となって、仮想サーバの処理能力を向上させることができる。

そして、ＶＭ−ｅｘｉｔが発生したときには、ＶＭＸノンルートモードのときに先行読み出しを行ってゲストＶＭＣＳ２２の内容をシャドウＶＭＣＳ＃１の内容で一括して更新し、さらに、今回のＶＭ−ｅｘｉｔの発生要因についても先行読み出しを実施するように先行読み出しエントリ情報１２３１で学習を行うことで、ＶＭ−ｅｘｉｔの発生を低減できるのである。

また、本発明では、複数の仮想ＣＰＵ１０８ａ〜１０８ｂに対応して、複数のシャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）を設けたので、物理サーバ１０１で複数のゲストＶＭＭ１０９を実行する場合でも、シャドウＶＭＣＳ１３０（＃０〜＃ｎ−１）を切り替えるだけで迅速に処理を切り替えることが可能となる。これにより、物理サーバ１０１に複数の新世代ＯＳを統合した場合でも、仮想サーバの性能を維持することが可能となる。

以上のように、本発明によれば、ホストＶＭＭ１０３が孫ＯＳやアプリケーションの状態と仮想ＣＰＵの状態を監視してシャドウＶＭＣＳ１３０のゲスト状態エリア１３１を書き換えることで、仮想サーバの性能を低下させることなく、仮想化ソフトウェアを統合したＯＳを確実に稼動させることが可能となる。そして、ひとつの物理サーバ１０１で仮想化機能を統合した新世代ＯＳと、既存のＯＳを共存させることが可能となって、サーバ統合を効率よく行うことで、サーバの運用コストを削減することが可能となる。

また、仮想ＶＭＲＥＡＤ命令または仮想ＶＭＷＲＩＴＥ命令を用いることで、物理ＣＰＵ１０４がＶＭ−ｅｘｉｔを発生する頻度を抑制し、仮想サーバの処理能力を向上させることができる。

なお、上記各実施形態において、物理ＣＰＵ１０４、１０４ｂとして記載したプロセッサは、マルチコアプロセッサの構成でも良く、また、ホモジニアスなプロセッサやヘテロジニアスのプロセッサを採用することができる。すなわち、物理ＣＰＵ１０４、１０４ａ、１０４ｂとして複数の汎用プロセッサコア（ＣＰＵ）と特定用途プロセッサコアを含むヘテロジニアス・マルチコア・プロセッサを用いる場合は、汎用プロセッサコアが仮想化支援機能を備えていれば本発明を適用することができる。

＜補足＞
１．物理プロセッサとメモリを備えた物理計算機上で複数の仮想プロセッサを提供する仮想計算機システムの制御方法であって、
前記仮想計算機システムは、
第１の仮想プロセッサを提供する第１の仮想化部と、前記第１の仮想プロセッサで実行されて第２の仮想プロセッサを提供する第２の仮想化部と、前記第２の仮想プロセッサで実行されるユーザプログラムと、を有し、
前記第２の仮想化部が、当該第２の仮想化部または前記ユーザプログラムを実行する際の第１の仮想プロセッサの状態を含む第１のプロセッサ制御情報を保持するステップと、
前記第１の仮想化部が、前記第２の仮想化部を実行する際の物理プロセッサの状態を含む第２のプロセッサ制御情報と、前記ユーザプログラムを実行する際の前記物理プロセッサの状態を含む第３のプロセッサ制御情報と、前記第３のプロセッサ制御情報から一括して先読みを行う情報を予め設定した先行読出しエントリ情報と、を保持するステップと、
前記第１の仮想化部が、前記第２の仮想プロセッサ上で前記ユーザプログラムから前記第２の仮想化部へ制御を移行させる第１のイベントを検出するステップと、
前記第１の仮想化部が、前記第１のイベントを検出したときに前記第３のプロセッサ制御情報のうち前記先行読出しエントリ情報に設定された情報を読み込むステップと、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち、前記先行読出しエントリ情報に基づいて読み込んだ情報を更新するステップと、
前記第１の仮想化部が、前記物理プロセッサに対して、前記第２のプロセッサ制御情報を設定して前記第２の仮想化部へ制御を移行させるステップと、
前記第２の仮想化部が、前記第１のプロセッサ制御情報を参照するステップと
を含むことを特徴とする仮想計算機システムの制御方法。

２．上記１．に記載の仮想計算機システムの制御方法において、
前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行うステップと、
前記第１の仮想化部が、前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出するステップと、
前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記更新されたデータを読み込むステップと、
前記第１の仮想化部が、前記読み込んだデータを前記第３のプロセッサ制御情報に反映させるステップと、
を更に含むことを特徴とする仮想計算機システムの制御方法。

３．上記１．に記載の仮想計算機システムの制御方法において、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち、前記先行読出しエントリ情報に基づいて読み込んだ情報を更新するステップは、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち更新した情報について更新ビットマップを設定するステップを含み、
前記第２の仮想化部が、前記第１のプロセッサ制御情報を参照するステップは、
前記第１のプロセッサ制御情報のうち参照の対象を特定するステップと、
前記更新ビットマップを参照して前記特定された参照対象の情報が更新されたか否かを判定するステップと、
前記更新ビットマップで前記情報が更新されていると判定したときには、前記第１のプロセッサ制御情報を読み込むステップと、
前記更新ビットマップで前記情報が更新されていないと判定したときには、第１の制御命令を発行して、前記第１の仮想化部に前記第３のプロセッサ制御情報から前記特定された参照対象の情報を前記第１のプロセッサ制御情報に反映させるステップと、
をさらに含むことを特徴とする仮想計算機システムの制御方法。

４．
前記請求項３に記載の仮想計算機の制御方法において、
前記物理プロセッサは、インテル・アーキテクチャー３２の命令セットに準拠するプロセッサであって、
前記第１のプロセッサ制御情報と第２のプロセッサ制御情報及び第３のプロセッサ制御情報が、前記インテル・アーキテクチャー３２に規定されるVirtual Machine Control Structureであり、
前記第１の制御命令が、インテル・アーキテクチャー３２の命令セットに規定されるＶＭＲＥＡＤ命令であり、
前記第１のイベントが、インテル・アーキテクチャー３２の命令セットに規定されるＶＭＲＥＳＵＭＥ命令またはＶＭＬＡＵＮＣＨ命令に起因するＶＭ−ｅｘｉｔ命令であることを特徴とする仮想計算機システムの制御方法。

５．
前記上記１．に記載の仮想計算機の制御方法において、
前記第１の仮想化部は、前記先行読出しエントリ情報を前記メモリに固定データとして保持することを特徴とする仮想計算機システムの制御方法。

６．
前記３．に記載の仮想計算機制御方法において、
前記第１の仮想化部は、前記先行読出しエントリ情報を前記メモリ上で書き換え可能なデータとして保持し、
前記第１の仮想化部に前記第３のプロセッサ制御情報から前記特定された参照対象の情報を前記第１のプロセッサ制御情報に反映させるステップは、
前記第１の仮想化部が、前記更新ビットマップで前記第１のプロセッサ制御情報のうち更新ビットマップで更新されていないと判定された情報を、前記第３のプロセッサ制御情報から読み込んで前記第１のプロセッサ制御情報に反映するステップと、
前記第１の仮想化部が、前記第３のプロセッサ制御情報から読み込んで前記第１のプロセッサ制御情報に反映した情報について、前記先行読出しエントリ情報に追加するステップと、
を含むことを特徴とする仮想計算機システムの制御方法。

７．物理プロセッサとメモリを備えた物理計算機で実行されて、複数の仮想プロセッサを提供する仮想化プログラムにおいて、
第１の仮想化部が第１の仮想プロセッサを生成する手順と、
第２の仮想化部が第２の仮想プロセッサを生成し、当該第２の仮想プロセッサでてユーザプログラムを実行させる手順と、
前記第２の仮想化部が、当該第２の仮想化部または前記ユーザプログラムを実行する際の第１の仮想プロセッサの状態を含む第１のプロセッサ制御情報を保持する手順と、
前記第１の仮想化部が、前記第２の仮想化部を実行する際の物理プロセッサの状態を含む第２のプロセッサ制御情報と、前記ユーザプログラムを実行する際の前記物理プロセッサの状態を含む第３のプロセッサ制御情報と、前記第３のプロセッサ制御情報から一括して先読みを行う情報を予め設定した先行読出しエントリ情報と、を保持する手順と、
前記第１の仮想化部が、前記第２の仮想プロセッサ上で前記ユーザプログラムから前記第２の仮想化部へ制御を移行させる第１のイベントを検出する手順と、
前記第１の仮想化部が、前記第１のイベントを検出したときに前記第３のプロセッサ制御情報のうち前記先行読出しエントリ情報に設定された情報を読み込む手順と、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち、前記先行読出しエントリ情報に基づいて読み込んだ情報を更新する手順と、
前記第１の仮想化部が、前記物理プロセッサに対して、前記第２のプロセッサ制御情報を設定して前記第２の仮想化部へ制御を移行させる手順と、
前記第２の仮想化部が、前記第１のプロセッサ制御情報を参照する手順と
を物理プロセッサに実行させることを特徴とする仮想化プログラム。

８．上記７．に記載の仮想化プログラムにおいて、
前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行う手順と、
前記第１の仮想化部が、前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出する手順と、
前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記更新されたデータを読み込む手順と、
前記第１の仮想化部が、前記読み込んだデータを前記第３のプロセッサ制御情報に反映させる手順と、
を更に含むことを特徴とする仮想化プログラム。

９．上記７．に記載の仮想化プログラムにおいて、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち、前記先行読出しエントリ情報に基づいて読み込んだ情報を更新する手順は、
前記第１の仮想化部が、前記第１のプロセッサ制御情報のうち更新した情報について更新ビットマップを設定する手順を含み、
前記第２の仮想化部が、前記第１のプロセッサ制御情報を参照する手順は
前記第１のプロセッサ制御情報のうち参照の対象を特定する手順と、
前記更新ビットマップを参照して前記特定された参照対象の情報が更新されたか否かを判定する手順と、
前記更新ビットマップで前記情報が更新されていると判定したときには、前記第１のプロセッサ制御情報を読み込む手順と、
前記更新ビットマップで前記情報が更新されていないと判定したときには、第１の制御命令を発行して、前記第１の仮想化部に前記第３のプロセッサ制御情報から前記特定された参照対象の情報を前記第１のプロセッサ制御情報に反映させる手順と、
をさらに含むことを特徴とする仮想化プログラム。

１０．上記９．に記載の仮想化プログラムにおいて、
前記物理プロセッサは、インテル・アーキテクチャー３２の命令セットに準拠するプロセッサであって、
前記第１のプロセッサ制御情報と第２のプロセッサ制御情報及び第３のプロセッサ制御情報が、前記インテル・アーキテクチャー３２に規定されるVirtual Machine Control Structureであり、
前記第１の制御命令が、インテル・アーキテクチャー３２の命令セットに規定されるＶＭＲＥＡＤ命令であり、
前記第１のイベントが、インテル・アーキテクチャー３２の命令セットに規定されるＶＭＲＥＳＵＭＥ命令またはＶＭＬＡＵＮＣＨ命令に起因するＶＭ−ｅｘｉｔ命令であることを特徴とする仮想化プログラム。

１１．上記７．に記載の仮想化プログラムにおいて、
前記第１の仮想化部は、前記先行読出しエントリ情報を前記メモリに固定データとして保持することを特徴とする仮想化プログラム。

１２．上記９．に記載の仮想化プログラムにおいて、
前記第１の仮想化部は、前記先行読出しエントリ情報を前記メモリ上で書き換え可能なデータとして保持し、
前記第１の仮想化部に前記第３のプロセッサ制御情報から前記特定された参照対象の情報を前記第１のプロセッサ制御情報に反映させる手順は、
前記第１の仮想化部が、前記更新ビットマップで前記第１のプロセッサ制御情報のうち更新ビットマップで更新されていないと判定された情報を、前記第３のプロセッサ制御情報から読み込んで前記第１のプロセッサ制御情報に反映する手順と、
前記第１の仮想化部が、前記第３のプロセッサ制御情報から読み込んで前記第１のプロセッサ制御情報に反映した情報について、前記先行読出しエントリ情報に追加する手順と、
を含むことを特徴とする仮想化プログラム。

１３．物理プロセッサとメモリを備えた物理計算機上で複数の仮想プロセッサを提供する仮想計算機システムにおいて、
前記物理プロセッサ上で動作して、第１の仮想プロセッサを提供する第１の仮想化部と、
前記第１の仮想プロセッサ上で動作して、ユーザプログラムを実行する第２の仮想プロセッサを提供する第２の仮想化部と、を備え、
前記第２の仮想化部は、
前記ユーザプログラムまたは第２の仮想化部を実行する際の第１の仮想プロセッサの状態を保持する第１のプロセッサ制御情報と、
前記第１のプロセッサ制御情報の参照を行う読み込み代行部と、
前記第１のプロセッサ制御情報への書込みを行う書込み代行部と、を有し、
前記第１の仮想化部は、
前記第２の仮想化部を実行する際の物理プロセッサの状態を保持する第２のプロセッサ制御情報と、
前記ユーザプログラムを実行する際の前記物理プロセッサの状態を保持する第３のプロセッサ制御情報と、
前記第３のプロセッサ制御情報から一括して先読みを行う情報を予め設定した先行読出しエントリ情報と、
前記第２の仮想プロセッサ上で前記ユーザプログラムから前記第２の仮想化部へ制御を移行させる第１のイベントを検出したときに前記第３のプロセッサ制御情報のうち前記先行読出しエントリ情報に設定された情報を読み込んで、前記第１のプロセッサ制御情報のうち、前記先行読出しエントリ情報に基づいて読み込んだ情報を更新する一括読み込み部と、
を有することを特徴とする仮想計算機システム。

以上のように、本発明は、複数の仮想サーバを提供する仮想計算機システムに適用することができる。また、本発明は、物理計算機上で複数の仮想サーバを提供する仮想化管理（ＶＭＭ）ソフトウェアに適用することができる。

１０３ ホストＶＭＭ
１１ ホストＶＭＭ保持データ
１２ ＣＰＵ制御部
１３ 物理ＣＰＵ制御データ
１０９ ゲストＶＭＭ
１１４ 仮想ＣＰＵ制御データ
１０１ 物理サーバ（物理計算機）
１０２ａ〜１０２ｂ 仮想サーバ
１０８ａ〜１０８ｂ 仮想ＣＰＵ
１０４ 物理ＣＰＵ
１０５ メモリ
１１０ａ、１１０ｂ ユーザプログラム
１１１ａ、１１１ｂ 孫ＯＳ
１１２ａ、１１２ｂ アプリケーション
２０８ａ 仮想ＣＰＵ

Claims (9)

1. 物理プロセッサとメモリを備えた物理計算機上で複数の仮想プロセッサを提供する仮想計算機システムの制御方法であって、
   前記仮想計算機システムは、
   第１の仮想プロセッサを提供する第１の仮想化部と、前記第１の仮想プロセッサで実行されて第２の仮想プロセッサを提供する第２の仮想化部と、前記第２の仮想プロセッサで実行されるユーザプログラムと、を有し、
   前記第２の仮想化部が、当該第２の仮想化部または前記ユーザプログラムを実行する際の第１の仮想プロセッサの状態を含む第１のプロセッサ制御情報を前記メモリに保持するステップと、
   前記第１の仮想化部が、前記第２の仮想化部を実行する際の物理プロセッサの状態を含む第２のプロセッサ制御情報と、前記ユーザプログラムを実行する際の前記物理プロセッサの状態を含む第３のプロセッサ制御情報と、を前記メモリに保持するステップと、
   前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行うステップと、
   前記第１の仮想化部が、前記第２の仮想プロセッサ上で前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出するステップと、
   前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込むステップと、
   前記第１の仮想化部が、前記第１のプロセッサ制御情報から読み込んだデータを前記第３のプロセッサ制御情報に反映させるステップと、
   を含むことを特徴とする仮想計算機システムの制御方法。
2. 請求項１に記載の仮想計算機システムの制御方法であって、
   前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行うステップは、
   前記第１のプロセッサ制御情報のうち更新した情報について更新ビットマップを設定するステップを含み、
   前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込むステップは、
   前記第１の仮想化部が、前記更新ビットマップに基づいて前記第１のプロセッサ制御情報のうち前記更新されたデータを読み込むことを特徴とする仮想計算機システムの制御方法。
3. 請求項１に記載の仮想計算機の制御方法であって、
   前記物理プロセッサは、インテル・アーキテクチャー３２の命令セットに準拠するプロセッサであって、
   前記第１のプロセッサ制御情報と第２のプロセッサ制御情報及び第３のプロセッサ制御情報が、前記インテル・アーキテクチャー３２に規定されるVirtual Machine Control Structureであり、
   前記第２のイベントが、インテル・アーキテクチャー３２の命令セットに規定されるＶＭ−ｅｎｔｒｙ命令であることを特徴とする仮想計算機システムの制御方法。
4. 物理プロセッサとメモリを備えた物理計算機で実行されて、複数の仮想プロセッサを提供する仮想化プログラムにおいて、
   第１の仮想化部が第１の仮想プロセッサを生成する手順と、
   第２の仮想化部が第２の仮想プロセッサを生成し、当該第２の仮想プロセッサでユーザプログラムを実行させる手順と、
   前記第２の仮想化部が、当該第２の仮想化部または前記ユーザプログラムを実行する際の第１の仮想プロセッサの状態を含む第１のプロセッサ制御情報を前記メモリに保持する手順と、
   前記第１の仮想化部が、前記第２の仮想化部を実行する際の物理プロセッサの状態を含む第２のプロセッサ制御情報と、前記ユーザプログラムを実行する際の前記物理プロセッサの状態を含む第３のプロセッサ制御情報と、を前記メモリに保持する手順と、
   前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行う手順と、
   前記第１の仮想化部が、前記第２の仮想プロセッサ上で前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出する手順と、
   前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込む手順と、
   前記第１の仮想化部が、前記第１のプロセッサ制御情報から読み込んだデータを前記第３のプロセッサ制御情報に反映させる手順と、
   を前記物理プロセッサに実行させることを特徴とする仮想化プログラム。
5. 請求項４に記載の仮想化プログラムであって、
   前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行う手順は、
   前記第１のプロセッサ制御情報のうち更新した情報について更新ビットマップを設定する手順を含み、
   前記第１の仮想化部が、前記第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込むステップは、
   前記第１の仮想化部が、前記更新ビットマップに基づいて前記第１のプロセッサ制御情報のうち前記更新されたデータを読み込むことを特徴とする仮想化プログラム。
6. 請求項４に記載の仮想化プログラムであって、
   前記物理プロセッサは、インテル・アーキテクチャー３２の命令セットに準拠するプロセッサであって、
   前記第１のプロセッサ制御情報と第２のプロセッサ制御情報及び第３のプロセッサ制御情報が、前記インテル・アーキテクチャー３２に規定されるVirtual Machine Control Structureであり、
   前記第２のイベントが、インテル・アーキテクチャー３２の命令セットに規定されるＶＭ−ｅｎｔｒｙ命令であることを特徴とする仮想化プログラム。
7. 物理プロセッサとメモリを備えた物理計算機上で複数の仮想プロセッサを提供する仮想計算機システムにおいて、
   前記物理プロセッサ上で動作して、第１の仮想プロセッサを提供する第１の仮想化部と、
   前記第１の仮想プロセッサ上で動作して、ユーザプログラムを実行する第２の仮想プロセッサを提供する第２の仮想化部と、を備え、
   前記第２の仮想化部は、
   前記ユーザプログラムまたは第２の仮想化部を実行する際の第１の仮想プロセッサの状態を前記メモリ上に保持する第１のプロセッサ制御情報と、
   前記第１のプロセッサ制御情報の参照を行う読み込み代行部と、
   前記第１のプロセッサ制御情報への書込みを行う書込み代行部と、
   前記第１の仮想化部は、
   前記第２の仮想化部を実行する際の物理プロセッサの状態を前記メモリ上に保持する第２のプロセッサ制御情報と、
   前記ユーザプログラムを実行する際の前記物理プロセッサの状態を前記メモリ上に保持する第３のプロセッサ制御情報と、
   前記第２の仮想化部が、前記第１のプロセッサ制御情報へ書き込みを行った後に、前記第２の仮想プロセッサ上で前記第２の仮想化部から前記ユーザプログラムへ制御を移行させる第２のイベントを検出したときに前記第１のプロセッサ制御情報のうち前記第２の仮想化部によって更新されたデータを読み込んで、前記読み込んだ第１のプロセッサ制御情報を前記第３のプロセッサ制御情報に反映させる一括更新部と、
   を有することを特徴とする仮想計算機システム。
8. 請求項７に記載の仮想計算機システムであって
   前記第２の仮想化部は、
   前記第１のプロセッサ制御情報のうち更新した情報について更新ビットマップを設定し、
   前記一括更新部は、
   前記更新ビットマップに基づいて前記第１のプロセッサ制御情報のうち前記更新されたデータを読み込むことを特徴とする仮想計算機システム。
9. 請求項７に記載の仮想計算機システムであって
   前記物理プロセッサは、インテル・アーキテクチャー３２の命令セットに準拠するプロセッサであって、
   前記第１のプロセッサ制御情報と第２のプロセッサ制御情報及び第３のプロセッサ制御情報が、前記インテル・アーキテクチャー３２に規定されるVirtual Machine Control Structureであり、
   前記第２のイベントが、インテル・アーキテクチャー３２の命令セットに規定されるＶＭ−ｅｎｔｒｙ命令であることを特徴とする仮想計算機システム。

Images