(57)【要約】  一実施例では、バーチャルマシーン（ＶＭ）に制御を移行する要求が、バーチャルマシーンモニタ（ＶＭＭ）に受付され、ＶＭＭがＶＭへのフォルトの送信を要求したか判断する。当該判定が肯定される場合、ＶＭに制御が移行される際に、フォルトがＶＭに送信される。
2007506162.tif 000002
【特許請求の範囲】
【請求項１】
バーチャルマシーンモニタ（ＶＭＭ）からバーチャルマシーン（ＶＭ）に制御を移行する要求を受け付けるステップと、
前記ＶＭＭが前記ＶＭへのフォルトの送信を要求したか判断するステップと、
前記ＶＭＭが前記ＶＭへのフォルトの送信を要求していた場合、前記ＶＭへの制御の移行の際に前記ＶＭに前記フォルトを送信するステップと、
から構成されることを特徴とする方法。
【請求項２】
請求項１記載の方法であって、
前記ＶＭに制御を移行する要求は、前記ＶＭＭにより実行される命令を介し受け付けられることを特徴とする方法。
【請求項３】
請求項１記載の方法であって、
前記ＶＭＭが前記ＶＭにフォルトの送信を要求したか判断するステップは、
前記ＶＭＭにより維持されるフォルト指標にアクセスするステップと、
前記フォルト指標が送信値に設定されているか判断するステップと、
から構成されることを特徴とする方法。
【請求項４】
請求項１記載の方法であって、さらに、
前記フォルトの識別子及び前記フォルトのタイプを判断するステップと、
前記フォルトが該フォルトに係るハンドラに与えられるべきエラーコードに係るものであるか判断するステップと、
を有することを特徴とする方法。
【請求項５】
請求項４記載の方法であって、さらに、
前記フォルトが該フォルトに係るハンドラへの前記エラーコードの送信を求める場合、前記エラーコードを抽出し、前記エラーコードを前記ハンドラに提供するステップを有することを特徴とする方法。
【請求項６】
請求項４記載の方法であって、
前記フォルト指標、前記フォルト識別子及び前記フォルトタイプは、第１フィールドに格納され、
前記エラーコードは、第２フィールドに格納される、
ことを特徴とする方法。
【請求項７】
請求項６記載の方法であって、
前記第１フィールド及び前記第２フィールドは、バーチャルマシーン制御構成（ＶＭＣＳ）に備えられることを特徴とする方法。
【請求項８】
請求項１記載の方法であって、さらに、
前記フォルトの送信は不成功であったと判断するステップと、
新たなフォルトが前記ＶＭＭへの制御の移行を要するか判断するステップと、
前記新たなフォルトが前記移行を要する場合、前記ＶＭＭに制御を移行するステップと、
を有することを特徴とする方法。
【請求項９】
請求項８記載の方法であって、さらに、
前記新たなフォルトが前記ＶＭＭへの制御の移行を要しないと判断するステップと、
前記新たなフォルトを前記ＶＭに送信するステップと、
を有することを特徴とする方法。
【請求項１０】
バーチャルマシーンモニタ（ＶＭＭ）と、
前記ＶＭＭにより制御され、フォルト指標を格納するデータ構造と、
前記ＶＭＭからバーチャルマシーン（ＶＭ）に制御を移行する要求を受け付け、前記ＶＭＭが前記フォルト指標を用いて前記ＶＭへのフォルトの送信を要求したか判断し、前記ＶＭＭが前記ＶＭへのフォルトの送信を要求していた場合、前記ＶＭへの制御の移行の際に前記ＶＭに前記フォルトを送信するフォルト送信ロジックと、
から構成されることを特徴とする装置。
【請求項１１】
請求項１０記載の装置であって、
前記ＶＭに制御を移行する要求は、前記ＶＭＭにより実行される命令を介し受け付けられることを特徴とする装置。
【請求項１２】
請求項１０記載の装置であって、
前記フォルト送信ロジックはさらに、前記ＶＭＭにより維持されるフォルト指標にアクセスし、前記フォルト指標が送信値に設定されているか判断することによって、前記ＶＭＭが前記ＶＭへのフォルトの送信を要求したか判断することを特徴とする装置。
【請求項１３】
請求項１０記載の装置であって、
前記フォルト送信ロジックはさらに、前記フォルトの識別子及び前記フォルトのタイプを判断し、前記フォルトが該フォルトに係るハンドラに与えられるべきエラーコードに係るものであるか判断することを特徴とする装置。
【請求項１４】
請求項１３記載の装置であって、
前記フォルト送信ロジックはさらに、前記フォルトが該フォルトに係るハンドラへの前記エラーコードの送信を求める場合、前記エラーコードを抽出し、前記エラーコードを前記ハンドラに提供することを特徴とする装置。
【請求項１５】
請求項１３記載の装置であって、
前記フォルト指標、前記フォルト識別子及び前記フォルトタイプは、第１フィールドに格納され、
前記エラーコードは、第２フィールドに格納される、
ことを特徴とする装置。
【請求項１６】
請求項１５記載の装置であって、
前記第１フィールド及び前記第２フィールドは、バーチャルマシーン制御構成（ＶＭＣＳ）に備えられることを特徴とする装置。
【請求項１７】
請求項１０記載の装置であって、
前記フォルト送信ロジックはさらに、前記フォルトの送信は不成功であったと判断し、新たなフォルトが前記ＶＭＭへの制御の移行を要するか判断し、前記新たなフォルトが前記移行を要する場合、前記ＶＭＭに制御を移行することを特徴とする装置。
【請求項１８】
請求項１７記載の装置であって、
前記フォルト送信ロジックはさらに、前記新たなフォルトが前記ＶＭＭへの制御の移行を要しないと判断し、前記新たなフォルトを前記ＶＭに送信することを特徴とする装置。
【請求項１９】
ゲストソフトウェアを格納するメモリと、
前記メモリに接続され、バーチャルマシーンモニタ（ＶＭＭ）から前記ゲストソフトウェアに制御を移行する要求を受け付け、前記ＶＭＭが前記ゲストソフトウェアへのフォルトの送信を要求していたと判断し、前記ゲストソフトウェアへの制御の移行の際に前記ゲストソフトウェアに前記フォルトを送信するプロセッサと、
から構成されることを特徴とするシステム。
【請求項２０】
請求項１９記載のシステムであって、
前記プロセッサはさらに、前記ＶＭＭにより維持されるフォルト指標にアクセスし、前記フォルト指標が送信値に設定されているか判断することによって、前記ＶＭへのフォルトの送信を要求したか判断することを特徴とするシステム。
【請求項２１】
請求項１９記載のシステムであって、
前記プロセッサはさらに、前記フォルトの識別子及び前記フォルトのタイプを判断し、前記フォルトが該フォルトに係るハンドラに与えられるべきエラーコードに係るものであるか判断することを特徴とするシステム。
【請求項２２】
請求項２１記載のシステムであって、
前記プロセッサはさらに、前記フォルトが該フォルトに係るハンドラへの前記エラーコードの送信を求める場合、前記エラーコードを抽出し、前記エラーコードを前記ハンドラに提供することを特徴とするシステム。
【請求項２３】
処理システムによる実行時、
バーチャルマシーンモニタ（ＶＭＭ）からバーチャルマシーン（ＶＭ）に制御を移行する要求を受け付けるステップと、
前記ＶＭＭが前記ＶＭへのフォルトの送信を要求したか判断するステップと、
前記ＶＭＭが前記ＶＭへのフォルトの送信を要求していた場合、前記ＶＭへの制御の移行の際に前記ＶＭに前記フォルトを送信するステップと、
から構成される方法を前記処理システムに実行させる命令を有することを特徴とするマシーン可読媒体。
【請求項２４】
請求項２３記載のマシーン可読媒体であって、
前記ＶＭに制御を移行する要求は、前記ＶＭＭにより実行される命令を介し受け付けられることを特徴とする媒体。
【請求項２５】
請求項２３記載のマシーン可読媒体であって、
前記ＶＭＭが前記ＶＭにフォルトの送信を要求したか判断するステップは、
前記ＶＭＭにより維持されるフォルト指標にアクセスするステップと、
前記フォルト指標が送信値に設定されているか判断するステップと、
から構成されることを特徴とする媒体。
【請求項２６】
請求項２３記載のマシーン可読媒体であって、
前記方法はさらに、
前記フォルトの識別子及び前記フォルトのタイプを判断するステップと、
前記フォルトが該フォルトに係るハンドラに与えられるべきエラーコードに係るものであるか判断するステップと、
を有することを特徴とする媒体。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
［発明の技術分野］
本発明は、一般にバーチャルマシーンに関し、より詳細には、バーチャルマシーン環境におけるフォルト（ｆａｕｌｔ）の処理に関する。
【０００２】
［発明の背景］
従来のバーチャルマシーンモニタ（ＶＭＭ）は、典型的にはコンピュータ上で実行され、他のソフトウェアに１以上のバーチャルマシーンのアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）を提供する。各バーチャルマシーンは、ゲストソフトウェアとして総称されるそれ自身の「ゲストオペレーティングシステム」（すなわち、ＶＭＭによりホストされるオペレーティングシステム（ＯＳ））及び他のソフトウェアを実行させることにより、自己完結したプラットフォームとして機能するかもしれない。ゲストソフトウェアは、それがバーチャルマシーンでなく専用コンピュータ上で実行されているかのように動作すると期待される。すなわち、ゲストソフトウェアは、各種イベントを制御し、ハードウェアリソースにアクセスすると期待される。ハードウェアリソースは、プロセッサ常駐リソース（制御レジスタなど）、メモリ常駐リソース（記述子テーブルなど）、及び基礎となるハードウェアプラットフォームに常駐するリソース（入出力装置など）を有するかもしれない。イベントは、内部割込、外部割込、例外処理、プラットフォームイベント（初期化（ＩＮＩＴ）やシステムマネージメント割込（ＳＭＩ）など）、特定の命令の実行などを含むものであってもよい。
【０００３】
バーチャルマシーン環境では、ＶＭＭは、バーチャルマシーン上で実行されるゲストソフトウェアの適切な処理を提供し、バーチャルマシーン上で実行されるゲストソフトウェアからと、それらの間の保護のため、上記イベントに対する最終的な制御及びハードウェアリソースを有することが可能となるべきである。これを実現するため、ゲストソフトウェアがプロテクトされたリソースにアクセスするとき、あるいは他のイベント（割込や例外処理など）が発生するとき、ＶＭＭは典型的に制御を受け付ける。例えば、ＶＭＭによりサポートされるバーチャルマシーンにおける処理がシステム装置に割込の生成をさせると、現在実行中のバーチャルマシーンは割り込みされ、プロセッサの制御はＶＭＭにわたされる。その後、ＶＭＭは割込を受付け、当該割込自体を処理するか、あるいは適切なバーチャルマシーンを呼び出し、割込を当該バーチャルマシーンに送る。
【０００４】
［実施例の説明］
ＶＭＭにより与えられるフォルト情報を用いてバーチャルマシーン環境においてフォルトを処理する方法及び装置が説明される。以下の説明では、説明のため、本発明の完全なる理解を提供するために多数の具体的詳細が与えられる。しかしながら、本発明がこれら具体的詳細なしに実現可能であるということは当業者には明らかであろう。
【０００５】
以下の詳細な説明の一部は、コンピュータシステムのレジスタ又はメモリ内のデータビットに対する記号表現及びアルゴリズムに関して与えられる。このようなアルゴリズム的記述及び表現は、データ処理分野における当業者によって、自らの研究の本質を最も効果的に他の当業者に伝えるのに使用される手段である。アルゴリズムは、ここでは、また一般には、所望の結果をもたらす自己矛盾のない処理シーケンスであると考えられる。当該処理は、物理量の物理的操作を要するものである。通常、必要でなくても、これらの量は、格納、転送、合成、比較あるいは操作することが可能な電気又は磁気信号の形態をとる。主として通常の利用のため、上記信号をビット、値、要素、シンボル、文字、項、数字などと呼ぶことが場合によっては便利であるとかわる。
【０００６】
しかしながら、上記及び類似の用語のすべてが適切な物理量に関連付けされるべきであり、当該量に適用される単なる便利なラベルであるということに留意すべきである。特段の断りがない場合、以下の説明から明らかなように、本発明を通じて、「処理」、「計算」、「決定」などの用語を用いた説明は、コンピュータシステムのレジスタ及びメモリ内の物理（電子）量として表されるデータを、コンピュータシステムメモリ、レジスタ又は他の情報ストレージ、送信又は表示装置内の物理量として同様に表される他のデータに変換及び操作するコンピュータシステム又は類似の電子計算装置のアクション及びプロセスを表すかもしれない。
【０００７】
実施例についての以下の詳細な説明では、例示により本発明が実現される具体的実施例を示す添付された図面が参照される。図面では、同様の番号は、いくつかの図面を通じて実質的に同様のコンポーネントを示す。これらの実施例は、当業者が本発明を実現可能となるのに十分詳細に説明される。他の実施例が利用されてもよく、本発明の範囲から逸脱することなく、構成、論理及び電気的変更がなされてもよい。さらに、異なるものではあるが、本発明の各種実施例が必ずしも互いに相容れないものである必要はないということは理解されるべきである。例えば、一実施例に記載される特定の機能、構成又は特徴は、他の実施例に含まれてもよい。
【０００８】
以下の例は実行ユニット及びロジック回路に関して本発明の実施例を説明しているが、本発明の他の実施例は、ソフトウェアにより実現することも可能である。例えば、一部の実施例では、本発明は、本発明によるプロセスを実行するようコンピュータ（又は他の電子装置）をプログラムするのに利用可能な命令を格納するコンピュータ可読媒体又はマシーンを有するソフトウェア若しくはコンピュータプログラムプロダクトとして提供されてもよい。他の実施例では、本発明の各ステップは、当該ステップを実行する配線ロジックを含む特定のハードウェアコンポーネント、又はプログラムされたコンピュータコンポーネントとカスタムハードウェアコンポーネントの任意の組み合わせにより実行されるかもしれない。
【０００９】
従って、マシーン可読媒体は、以下に限定されるものではないが、フロッピー（登録商標）ディスケット、光ディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、光磁気ディスク、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気又は光カード、フラッシュメモリ、インターネットを介した送信、電気、光、音響又は他の形態の伝搬信号（搬送波、赤外線信号、デジタル信号など）など、マシーン（コンピュータなど）により可読な形態による情報の格納又は送信を行う任意の機構を有するものであってもよい。
【００１０】
さらに、作成からシミュレーション又は製造までの各種段階をデザインは経過する。デザインを表すデータは、いくつかの方法により当該デザインを表すかもしれない。まず、シミュレーションに有用なように、ハードウェアはハードウェア記述言語又は他の機能記述言語を用いて表されるかもしれない。さらに、ロジック及び／又はトランジスタゲートを有する回路レベルモデルが、設計プロセスの一部の段階において生成されるかもしれない。さらに、一部の段階では、ほとんどのデザインが、ハードウェアモデルによる各種装置の物理的配置を表すデータレベルに到達する。従来の半導体製造技術が利用される場合、ハードウェアモデルを表すデータは、集積回路を製造するのに用いられるマスクの各マスクレイヤ上の各種特徴の有無を指定するデータであってもよい。デザインの何れの表現においても、上記データは任意の形態のマシーン可読媒体に格納されてもよい。このような情報を伝送するのに生成又は変調される光又は電気波、あるいはディスクなどの磁気又は光ストレージが、マシーン可読媒体であるかもしれない。上記媒体の何れも、デザイン又はソフトウェア情報を搬送又は示すものであってもよい。コード又はデザインを搬送又は示す電気搬送波が伝送されると、電気信号の複製、バッファリング又は再送が実行される程度まで、新たなコピーが行われる。従って、通信プロバイダ又はネットワークプロバイダは、本発明の技術を実現する物（搬送波）をコピーしてもよい。
【００１１】
図１は、本発明のいくつかの実施例が動作可能なバーチャルマシーン環境１００を示す。バーチャルマシーン環境１００では、ベアプラットフォームハードウェア１１０は、標準的なオペレーティングシステム（ＯＳ）及び／又はバーチャルマシーンモニタ（ＶＭＭ）１１２などのＶＭＭを実行可能な計算プラットフォームから構成される。ＶＭＭ１１２は、典型的にはソフトウェアにより実現されるが、より高いレベルのソフトウェアとのベアマシーンインタフェースをエミュレート及びエクスポートする。このようなハイレベルソフトウェアは、このようなハイレベルソフトウェアは、標準的又はリアルタイムＯＳから構成されてもよいし、限定されたオペレーティングシステムの機能を有するストリップダウン（ｓｔｒｉｐｐｅｄ  ｄｏｗｎ）されたオペレーティング環境であってもよいし、従来のＯＳファシリティなどを有しないものであってもよい。あるいは、ＶＭＭ１１２は、他のＶＭＭの内部又はその上で実行されてもよい。ＶＭＭ及びそれらの典型的な特徴及び機能は、当業者には周知であり、例えば、ハードウェア、ソフトウェア、ファームウェア、各種技術の組み合わせにより実現されてもよい。
【００１２】
プラットフォームハードウェア１１０は、プロセッサ１１８とメモリ１２０とを有する。プロセッサ１１８は、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラなど、ソフトウェアを実行可能な任意のタイプのプロセッサとすることができる。図１には１つのプロセッサ１１８のみが示されているが、プラットフォームハードウェア１１０は、当該プロセッサを１以上有するものであってもよい。
【００１３】
メモリ１２０は、任意のタイプの記録可能／記録不可媒体（例えば、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気ディスク、記憶媒体、光記憶媒体、フラッシュメモリ装置など）と共に、電気、光、音響又は他の形態の伝搬信号（搬送波、赤外線信号、デジタル信号など）、上記装置の任意の組み合わせ、又はプロセッサ１１８により読み出し可能な他の任意のタイプのマシーン媒体とすることができる。メモリ１２０は、本発明の方法の実施例を実行するための命令を格納するようにしてもよい。
【００１４】
プラットフォームハードウェア１１０は、パーソナルコンピュータ（ＰＣ）、メインフレーム、形態装置、ポータブルコンピュータ、セットトップボックス、又は他の何れかの計算システムを有することができる。
【００１５】
ＶＭＭ１１２は、他のソフトウェア（すなわち、「ゲスト」ソフトウェア）に、同一又は異なるアブストラクションを各種段階に提供する１以上のバーチャルマシーン（ＶＭ）のアブストラクションを提供する。図１は、３つのＶＭ１３０，１４０及び１５０を示す。各ＶＭ上で実行されるゲストソフトウェアは、ゲストＯＳ１５４、１６０又は１７０などのゲストＯＳと、各種ゲストソフトウェアアプリケーション１５２、１６２及び１７２を有するようにしてもよい。
【００１６】
ゲストＯＳ１５４、１６０及び１７０は、ゲストＯＳが実行される対応するＶＭ（ＶＭ１３０、１４０、１５０など）内の物理的リソース（プロセッサレジスタ、メモリ、入出力（Ｉ／Ｏ）装置など）にアクセスし、他の機能を実行すると予想される。例えば、ゲストＯＳは、ＶＭに与えられるプラットフォーム及びプロセッサのアーキテクチャに従って、すべてのレジスタ、キャッシュ、構成、Ｉ／Ｏ装置、メモリなどのすべてにアクセすると予想される。ゲストソフトウェアによりアクセス可能なリソースは、「特権」又は「非特権」として分類されてもよい。特権リソースについて、ＶＭＭ１１２は、特権リソースに対する最終的な制御を維持しながら、ゲストソフトウェアにより所望される機能を容易にする。非特権リソースは、ＶＭＭ１１２により制御される必要はなく、ゲストソフトウェアによりアクセス可能である。
【００１７】
さらに、各ゲストＯＳは、例外処理（ページフォルト、一般的プロテクトフォルトなど）、割込（ハードウェア割込、ソフトウェア割込など）、プラットフォームイベント（初期化（ＩＮＩＴ）、システムマネージメント割込（ＳＭＩ）など）などの各種フォルトイベントを処理することが期待される。上記フォルトイベントのいくつかは、それらがＶＭ１３０〜１５０の適切な処理を保証し、ゲストソフトウェアから、及びそれらの間の保護のためＶＭＭ１１２により処理される必要があるという理由から、「特権的」である。
【００１８】
特権フォルトイベントが発生し、あるいは、ゲストソフトウェアが特権リソースにアクセスしようとすると、制御はＶＭＭ１１２に移行されるかもしれない。ゲストソフトウェアからＶＭＭ１１２への制御の移行は、ここではＶＭイグジットと呼ばれる。リソースアクセスを容易にし、あるいは、イベントを適切に処理した後、ＶＭＭ１１２はゲストソフトウェアに制御を返すようにしてもよい。ＶＭＭ１１２からゲストソフトウェアへの制御の移行は、ＶＭエントリと呼ばれる。一実施例では、ＶＭＭ１１２は、ＶＭエントリ命令を実行することによりＶＭエントリを実行するようプロセッサ１１８に要求する。
【００１９】
一実施例では、プロセッサ１１８は、バーチャルマシーン制御構成（ＶＭＣＳ）１２６に格納されているデータに従って、ＶＭ１３０、１４０及び１５０の動作を制御する。ＶＭＣＳ１２６は、ゲストソフトウェアの状態、ＶＭＭ１１２の状態、ＶＭＭ１１２がゲストソフトウェアの動作の制御をどのように所望するかについて示す実行制御情報、ＶＭＭ１１２とＶＭとの間の移行を制御する情報などを含む構成である。いくつかの実施例では、複数のＶＭＣＳ構成を用いて、複数のＶＭをサポートする。
【００２０】
特権フォルトイベントが発生すると、ＶＭＭ１１２は、フォルトを自ら処理するか、あるいは、当該フォルトは適切なＶＭにより処理される必要があるか判断するようにしてもよい。ＶＭＭ１１２によりフォルトがＶＭにより処理されるべきであると判断された場合、ＶＭＭ１１２は、プロセッサ１１８に当該ＶＭを呼び出し、フォルトを当該ＶＭに送信するよう要求する。一実施例では、ＶＭＭ１１２は、フォルト指標を送信値に設定し、ＶＭエントリ要求を生成することによって、これを実現する。一実施例では、フォルト指標はＶＭＣＳ１２６に格納される。
【００２１】
一実施例では、プロセッサ１１８は、ＶＭエントリに対するＶＭＭ１１２の要求を受信し、ＶＭＭ１２２がフォルトの送信をＶＭに要求したか判断するフォルト送信ロジック１２４を有する。一実施例では、フォルト送信ロジック１２４は、ＶＭＣＳ１２６に格納されるフォルト指標の現在値に基づきこの判断をする。フォルト送信ロジック１２４によりＶＭＭがフォルトの送信をＶＭに要求したと判断されると、フォルト送信ロジック１２４は、当該ＶＭへの制御の移行時に、フォルトをＶＭに送信する。
【００２２】
一実施例では、フォルトの送信は、フォルトが送信されることに関するエントリをリダイレクション構成から検索し、当該エントリからこのフォルトを処理するよう指定されたルーチンの場所の記述子を抽出し、当該記述子を用いてルーチンの先頭にジャンプすることを伴う。対応する割込、例外処理又は他の何れかのフォルトを処理するよう指定されたルーチンは、ハンドラと呼ばれる。いくつかのインストラクションセットアーキテクチャ（ＩＳＡ）では、特定のフォルトは、ハンドラの先頭にジャンプする前に、スタックに置かれる（又は、ハードウェアレジスタに、あるいは他の手段を介し与えられる）必要があるかもしれないエラーコードに関連付けされる。
【００２３】
フォルトの送信中、プロセッサ１１８は、仮想形式から物理形式にアドレスを変換する１以上のアドレス変換を実行するようにしてもよい。例えば、割込テーブルのアドレス又は関連付けされたハンドラのアドレスは、仮想アドレスであるかもしれない。プロセッサはまた、フォルトの送信中に各種チェックを実行する必要があるかもしれない。例えば、プロセッサは、セグメンテーションレジスタ及びアクセスアドレスの検証（制限違反フォルト、セグメント不存在フォルト、スタックフォルトなど）、プロテクトフォルトを生じさせるパーミッションレベルチェック（一般的プロテクトフォルトなど）などの一貫性チェックを実行するようにしてもよい。
【００２４】
フォルトベクトル処理中のチェック及びアドレス変換は、ページフォルト、一般的プロテクトフォルトなどの各種フォルトを生じさせるかもしれない。現在のフォルトの送信中に発生するフォルトは、ＶＭイグジットを発生させるかもしれない。例えば、ＶＭＭ１１２がページフォルトに対するＶＭイグジットが物理メモリのプロテクト及び視覚化を行うよう求める場合、現在フォルトのＶＭへの送信中に発生したページフォルトは、ＶＭイグジットを生じさせるであろう。
【００２５】
一実施例では、フォルト送信ロジック１２４は、現在フォルトの送信が成功したかチェックすることによって、追加的なフォルトの上記可能性のある発生を解決する。フォルト送信ロジック１２４が送信が不成功であったと判断する場合、さらに、結果としてのフォルトがＶＭイグジットを生じさせるか判断する。ＶＭイグジットを生じさせる場合、フォルト送信ロジック１２４はＶＭイグジットを生成する。そうでない場合、フォルト送信ロジック１２４は、追加的フォルトをＶＭに送信する。
【００２６】
図２は、バーチャルマシーン環境においてフォルトを処理するプロセス２００の一実施例のフロー図である。当該プロセスは、ハードウェア（回路、専用ロジック、プログラマブルロジック、マイクロコードなど）、ソフトウェア（汎用コンピュータシステム又は専用マシーン上で実行されるような）、又は両者の組み合わせからなる処理ロジックにより実行されてもよい。
【００２７】
図２を参照するに、プロセス２００は、処理ロジックがＶＭＭからＶＭに制御を移行する要求を受け取ることから開始される（処理ブロック２０２）。一実施例では、制御を移行する要求は、ＶＭＭにより実行されるＶＭエントリ命令を介し受信される。
【００２８】
判定ブロック２０４において、処理ロジックは、ＶＭＭが呼び出しされるＶＭにフォルトの送信を要求したか判断する。フォルトは、内部割込（ソフトウェア割込など）、外部割込（ハードウェア割込など）、例外処理（ページフォルトなど）、プラットフォームイベント（初期化（ＩＮＩＴ）やシステムマネージメント割込（ＳＭＩ）など）、他の何れかのフォルトイベントであってもよい。一実施例では、処理ロジックは、ＶＭＭがＶＭＭにより維持されるフォルト指標の現在値を読むことによって、フォルトの送信を要求したか判断する。フォルト指標は、ＶＭＣＳ又はＶＭＭ及び処理ロジック２００にアクセス可能な他の何れかのデータ構造に配置されているかもしれない。一実施例では、ＶＭＭがフォルトのＶＭへの送信を所望する場合、ＶＭＭはフォルト指標を送信値に設定し、その後、当該ＶＭに制御を移行する要求を生成する。ＶＭエントリ中にフォルト送信が必要でない場合、ＶＭＭは、ＶＭへの制御の移行の要求前に、フォルト指標を非送信値に設定する。このことは、図３に関して以下で説明される。
【００２９】
処理ロジックが、ＶＭＭはフォルトの送信を要求したと判断する場合、処理ロジックは、ＶＭに制御を移行しながら、フォルトをＶＭに送信する（処理ブロック２０６）。その後、処理ロジックは、フォルトの送信が成功したかチェックする（判定ボックス２０８）。成功した場合、プロセス２００は終了する。不成功の場合、処理ロジックは、結果として生じた追加的なフォルトがＶＭイグジットを発生させるか判断する（判定ボックス２１０）。ＶＭイグジットを生じさせる場合、処理ロジックは、ＶＭイグジットを生成する（処理ブロック２１２）。そうでない場合、処理ロジックは、追加的フォルトをＶＭに送信し（処理ブロック２１４）、処理ブロック２０８に戻って、この追加的フォルトの送信が成功したかチェックする。成功した場合プロセス２００は終了する。そうでない場合、処理ロジックは、判定ボックス２１０に戻る。
【００３０】
処理ロジックがＶＭＭはフォルトの送信を要求していないと判断する場合、処理ロジックは、フォルト関連処理を実行することなく、ＶＭへ制御を移行する（処理ブロック２１８）。
【００３１】
一実施例では、処理ロジックがＶＭへのフォルトの送信を必要とするとき、それは、フォルトの送信に関するエントリをリダイレクション構成（例えば、Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）４のインストラクションセットアーキテクチャ（ＩＳＡ）（ここでは、ＩＡ−３２ＩＳＡと呼ぶ）の割込記述子テーブルなど）から検索し、当該エントリからフォルトに関するハンドラの記述子を抽出し、当該記述子を用いてハンドラの先頭にジャンプする。割込記述子テーブルは、フォルト識別子及びフォルトタイプ（外部割込、内部割込、非マスカブル（ｎｏｎ−ｍａｓｋａｂｌｅ）割込（ＮＭＩ）、例外処理など）などのフォルト識別情報を用いて検索されてもよい。一実施例では、特定のフォルト（一部の例外処理など）は、ハンドラの先頭へのジャンプ前に、スタックに置かれる必要がある（又はハードウェアレジスタに、又は他の手段を介し備えられる）エラーコードと関連付けされる。一実施例では、フォルト識別情報と関連するエラーコードは、指定されたデータ構造を用いてＶＭＭにより与えられる。一実施例では、指定されたデータ構造はＶＭＣＳの一部である。図３は、フォルト識別情報を格納するＶＭＣＳフィールドの一例となるフォーマットを示す。このＶＭＣＳフィールドは、フォルト情報フィールドと呼ばれる。
【００３２】
図３を参照するに、一実施例では、フォルト情報フィールドは、最初の８ビットがフォルト（割込、例外処理など）の識別子を格納し、次の２ビットがフォルトのタイプ（内部割込、ソフトウェア割込、ＮＭＩ、例外処理など）を特定し、ビット１１が当該フォルトに関するエラーコードが（存在する場合）、（スタックに置かれ、ハードウェアレジスタに格納されるなど）対応するハンドラに与えられるべきか示し、ビット３１が上述のようにフォルトがＶＭに送信されるべきかを指定するフォルト指標となる３２ビットフィールドである。
【００３３】
フォルト情報フィールドのビット１１によりエラーコードがハンドラに与えられるべきであると判断されると、第２のＶＭＣＳフィールドが、当該フォルトに関するエラーコードを取得するためアクセスされる。第２ＶＭＣＳフィールドは、フォルトエラーコードフィールドと呼ばれる。
【００３４】
一実施例では、ＶＭＭがＶＭへのフォルトの送信を所望するとき、ＶＭＭは、フォルト情報フィールドのフォルト識別子及びフォルトタイプを格納し、フォルト指標（ビット３１）を送信値に設定する（例えば、ビット３１＝１など）。さらに、フォルトがハンドラに与えられる必要があるエラーコードに関する場合、ＶＭＭはビット１１を送信値に設定し（ビット１１＝１など）、エラーコードをＶＭＣＳのフォルトエラーコードフィールドに格納する。
【００３５】
図４は、ＶＭＭにより与えられるフォルト情報を用いてバーチャルマシーン環境においてフォルトを処理するプロセス４００の一実施例のフロー図である。当該プロセスは、ハードウェア（回路、専用ロジック、プログラマブルロジック、マイクロコードなど）、ソフトウェア（汎用コンピュータシステム又は専用マシーン上で実行されるような）、又は両者の組み合わせからなる処理ロジックにより実行されてもよい。一実施例では、プロセス４００は、図１のフォルト送信ロジック１２４により実行される。
【００３６】
図４を参照するに、プロセス４００は、処理ロジックがＶＭＭによるＶＭエントリ命令の実行を検出することにより開始される（処理ブロック４０２）。これに応答して、処理ロジックは、ＶＭＭにより制御されるフォルト指標ビットにアクセスし（処理ブロック４０３）、フォルトが呼び出しされるＶＭに送信されるべきか判断する（判定ボックス４０４）。フォルトが送信されるべきでない場合、処理ロジックは、残りのフォルト情報を無視し、要求されたＶＭエントリを実行する（処理ブロック４０６）。送信される場合、処理ロジックは、ＶＭＣＳのフォルト情報フィールドからフォルト情報を取得し（処理ブロック４０８）、当該フォルトに関するエラーコードがフォルトのハンドラに提供されるべきか判断する（判定ブロック４１０）。提供されるべきである場合、処理ロジックは、ＶＭＣＳのフォルトエラーコードフィールドからエラーコードを取得する（処理ブロック４１２）。そうでない場合、処理ロジックは、処理ブロック４１４に直接移行する。
【００３７】
処理ブロック４１４において、処理ロジックは、ＶＭエントリを実行しながら、ＶＭにフォルトを送信する。その後、処理ロジックは、フォルトの送信が成功したかチェックする（判定ボックス４１６）。成功している場合、プロセス４００は終了する。不成功であった場合、処理ロジックは、結果として生じる追加的フォルトがＶＭイグジットを生じさせるか判断する（判定ボックス４１８）。そうである場合、処理ロジックは、追加的フォルトをＶＭに送信し（処理ブロック４２２）、処理ブロック４１６に戻って、この追加的フォルトの送信が成功したかチェックする。成功している場合、プロセス４００は終了する。不成功である場合、処理ロジックは判定ボックス４１８に戻る。
【００３８】
以上、バーチャルマシーン環境においてフォルトを処理する方法及び装置が説明された。上記説明は、例示的なものであって、限定的なものではないということが理解されるべきである。他の多くの実施例が、上記説明を読み理解することにより、当業者に明らかとなるであろう。本発明の範囲は、添付された請求項及び当該請求項に権利付与される均等物の完全な範囲を参照することにより決定されるべきである。
【図面の簡単な説明】
【００３９】
【図１】図１は、本発明が動作可能なバーチャルマシーン環境の一実施例を示す。
【図２】図２は、バーチャルマシーン環境においてフォルトを処理するプロセスの一実施例のフロー図である。
【図３】図３は、フォルト識別情報を格納するＶＭＣＳフィールドの一例となるフォーマットを示す。
【図４】図４は、ＶＭＭにより与えられるフォルト情報を用いてバーチャルマシーン環境においてフォルトを処理するプロセスの一実施例のフロー図である。
【図１】
2007506162.tif 000003
【図２】
2007506162.tif 000004
【図３】
2007506162.tif 000005
【図４】
2007506162.tif 000006
【国際調査報告】
2007506162.tif 000007
2007506162.tif 000008