(57)【要約】  一実施形態では、方法は、仮想マシンモニタ（ＶＭＭ）から要求を受け取ったことに応じて制御を仮想マシン（ＶＭ）に移行することと、制御を移行させる前記要求はオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定することと、ＶＭのイベント・ウィンドウがオープンであるかどうかを判定するためにイベント・ウィンドウ確認を実行することと、イベント・ウィンドウ確認がＶＭのイベント・ウィンドウはオープンであることを示す場合にＶＭＭに制御を移行することを含む。
2007528084.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシン（ＶＭ）に制御を移行させる要求を仮想マシンモニタ（ＶＭＭ）から受け取ることと、
制御を移行させる前記要求は、前記ＶＭのオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定することと、
前記ＶＭに制御を移行することと、
前記ＶＭがオープン・イベント・ウィンドウを有するかどうかを判定するためにイベント・ウィンドウ確認を実行することと、
前記イベント・ウィンドウ確認が、前記ＶＭはオープン・イベント・ウィンドウを有することを示す場合、制御を前記ＶＭＭに移行することと
を備える方法。
【請求項２】
前記ＶＭＭに制御を移行することは、前記ＶＭのオープン・イベント・ウィンドウにより制御が前記ＶＭＭに移行されたことを、前記ＶＭＭに通知することを備える請求項１に記載の方法。
【請求項３】
制御を移行させる前記要求がオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定することは、
前記ＶＭＭによって維持される待機イベント・インジケータにアクセスすることと、
前記待機イベント・インジケータが伝達値にセットされていることを判定することと
を備える請求項１に記載の方法。
【請求項４】
前記ＶＭがオープン・イベント・ウィンドウを有しないことを判定することと、
前記ＶＭがオープン・イベント・ウィンドウを有すると判定されるまで、前記ＶＭによって実行される各命令の後に前記イベント・ウィンドウ確認を繰り返すことと
を更に備える請求項１に記載の方法。
【請求項５】
前記イベント・ウィンドウ確認は、前記ＶＭが命令を実行する前に、最初に実行される請求項４に記載の方法。
【請求項６】
前記イベント・ウィンドウ確認は、前記ＶＭが最初の命令を実行した後に、最初に実行される請求項４に記載の方法。
【請求項７】
前記ＶＭがオープン・イベント・ウィンドウを有することを判定する前に、
前記ＶＭＭへの制御の移行に関連する高い優先度を有するイベントを検知することと、
前記ＶＭＭに制御を移行することと、
前記高い優先度を有するイベントにより制御が移行されたことを前記ＶＭＭに通知することと
を更に備える請求項１に記載の方法。
【請求項８】
仮想マシン（ＶＭ）のイベント・ウィンドウのオープンを示す通知を受け取る意図を示すために、待機イベント・インジケータを伝達値にセットすることと、
前記ＶＭへの制御の移行を要求することと
を備える方法。
【請求項９】
前記待機イベント・インジケータを伝達値にセットする前に、
前記ＶＭはオープン・イベント・ウィンドウを有するかどうかを判定することと、
前記ＶＭがオープン・イベント・ウィンドウを有し、前記ＶＭに伝達されるべき待機イベントが存在する場合、前記待機イベント・インジケータを非伝達値にリセットし、前記ＶＭへの前記待機イベントの前記伝達を要求することと
を更に備える請求項８に記載の方法。
【請求項１０】
前記ＶＭから移行された制御を受け取ることと、
制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものであったかどうかを判定することと、
前記制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものであり、かつ、前記ＶＭに伝達されるべき待機イベントが存在する場合、前記ＶＭへの前記待機イベントの前記伝達を要求することと
を更に備える請求項８に記載の方法。
【請求項１１】
前記制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものではなかったことを判定することと、
前記制御の移行に関連する１つ以上の処理を実行することと
を更に備える請求項１０に記載の方法。
【請求項１２】
前記制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものではなかったことを判定することと、
前記制御の移行に関連する１つ以上の処理を実行することと、
待機イベントが前記ＶＭに伝達されるべきである場合、前記ＶＭが前記待機イベントを受け取る準備ができているかどうかを判定することと
を更に備える請求項１０に記載の方法。
【請求項１３】
前記ＶＭが前記待機イベントを受け取る準備ができていることを判定することと、
前記待機イベント・インジケータを非伝達値にリセットすることと、
前記ＶＭへの前記待機イベントの前記伝達を要求することと
を更に備える請求項１２に記載の方法。
【請求項１４】
前記ＶＭは前記待機イベントを受け取る準備ができていないことを判定することと、
前記ＶＭへの制御の移行を要求することと
を更に備える請求項１２に記載の方法。
【請求項１５】
仮想マシンモニタ（ＶＭＭ）と、
前記ＶＭＭによって制御され、待機イベントに関連する待機イベント・インジケータを格納するデータ構造と、
仮想マシン（ＶＭ）に制御を移行させる要求を前記ＶＭＭから受け取ったことに応じて制御を前記ＶＭに移行し、前記待機イベント・インジケータが伝達値にセットされていることを判定し、前記ＶＭのイベント・ウィンドウがオープンであるかどうかを判定し、前記ＶＭの前記イベント・ウィンドウがオープンである場合に制御を前記ＶＭＭに移行するオープン・ウィンドウ監視ロジックと
を備える装置。
【請求項１６】
前記オープン・ウィンドウ監視ロジックは、更に、前記ＶＭのオープン・イベント・ウィンドウにより、前記ＶＭＭに制御が移行されたことを前記ＶＭＭに通知する請求項１５に記載の装置。
【請求項１７】
前記オープン・ウィンドウ監視ロジックは、更に、前記ＶＭの前記イベント・ウィンドウがクローズであることを判定し、前記ＶＭの前記イベント・ウィンドウがオープンであると判定されるまで前記ＶＭによって各命令が実行された後に前記ＶＭの前記イベント・ウィンドウがオープンであるかどうかの判定を実行する請求項１５に記載の装置。
【請求項１８】
前記ＶＭの前記イベント・ウィンドウがオープンであるかどうかの前記判定は、前記ＶＭが命令を実行する前に最初に実行される請求項１５に記載の装置。
【請求項１９】
１つ以上のインジケータを格納するメモリと、
仮想マシン（ＶＭ）への制御の移行が前記ＶＭのイベント・ウィンドウのオープンを通知されるべき要求に関連することを判定するために前記１つ以上のインジケータを使用し、前記ＶＭの前記イベント・ウィンドウがオープンであるかどうかを判定するためにイベント・ウィンドウ確認を実行し、前記イベント・ウィンドウ確認が前記ＶＭの前記イベント・ウィンドウがオープンであることを示す場合に、仮想マシンモニタ（ＶＭＭ）に制御を移行する、前記メモリに接続されたプロセッサと
を備えるシステム。
【請求項２０】
前記プロセッサは、更に、前記ＶＭのオープン・イベント・ウィンドウにより制御が前記ＶＭＭに移行されたことを、前記ＶＭＭに通知する請求項１９に記載のシステム。
【請求項２１】
前記プロセッサは、前記ＶＭＭによって維持される待機イベント・インジケータにアクセスし、前記待機イベント・インジケータが伝達値にセットされていることを判定することによって、制御を移行させる前記要求が前記ＶＭのオープン・イベント・ウィンドウに関連することを判定する請求項１９に記載のシステム。
【請求項２２】
１つ以上のインジケータを格納するメモリと、
仮想マシン（ＶＭ）のイベント・ウィンドウのオープンを示す通知を受け取る意図を示すために前記１つ以上のインジケータを伝達値にセットし、前記ＶＭに制御を移行させる要求を受け取り、前記ＶＭに制御を移行する、前記メモリに接続されたプロセッサと
を備えるシステム。
【請求項２３】
前記プロセッサは、前記待機イベント・インジケータが伝達値にセットする前に前記ＶＭがオープン・イベント・ウィンドウを有するかどうかを判定し、前記ＶＭがオープン・イベント・ウィンドウを有し、かつ、前記ＶＭに伝達されるべき待機イベントが存在する場合は、前記待機イベント・インジケータを非伝達値にリセットし、前記ＶＭに前記待機イベントを伝達させる要求を受け取る請求項２２に記載のシステム。
【請求項２４】
前記プロセッサは、更に、前記ＶＭに制御を移行し、制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものであったかどうかを判定し、前記制御の移行が前記ＶＭがオープン・イベント・ウィンドウを有することによるものであり、かつ、前記ＶＭに伝達されるべき待機イベントが存在する場合に、前記待機イベントを前記ＶＭに伝達させる要求を受け取る請求項２２に記載のシステム。
【請求項２５】
命令群を記録したマシン読み取り可能な媒体であって、
前記命令群は、処理システムによって実行されることにより、
仮想マシン（ＶＭ）に制御を移行させる要求を仮想マシンモニタ（ＶＭＭ）から受け取ったことに応じて前記ＶＭに制御を移行することと、
制御を移行させる前記要求は前記ＶＭのオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定することと、
前記ＶＭの前記イベント・ウィンドウがオープンであるかどうかを判定するためにイベント・ウィンドウ確認を実行することと、
前記イベント・ウィンドウ確認が前記ＶＭの前記イベント・ウィンドウがオープンであることを示す場合に、前記ＶＭＭに制御を移行することと
を備える媒体。
【請求項２６】
前記ＶＭＭに制御を移行することは、前記ＶＭのオープン・イベント・ウィンドウにより制御が前記ＶＭＭに移行されたことを前記ＶＭＭに通知することを備える請求項２５に記載のマシン読み取り可能な媒体。
【請求項２７】
制御を移行させる前記要求が前記ＶＭのオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定することは、
前記ＶＭＭによって維持される待機イベント・インジケータにアクセスすることと、前記待機イベント・インジケータが伝達値にセットされていることを判定することと
を備える請求項２５に記載のマシン読み取り可能な媒体。
【請求項２８】
命令群を記録したマシン読み取り可能な媒体であって、
前記命令群は、処理システムによって実行されることにより、
仮想マシン（ＶＭ）のイベント・ウィンドウのオープンを示す通知を受け取る意図を示すために待機イベント・インジケータを伝達値にセットすることと、
前記ＶＭに制御を移行させる要求をすることと
を備える媒体。
【請求項２９】
前記命令群は、
前記待機イベント・インジケータを伝達値にセットする前に、
前記ＶＭがオープン・イベント・ウィンドウを有するかどうかを判定することと、
前記ＶＭがオープン・イベント・ウィンドウを有し、かつ、前記ＶＭに伝達されるべき待機イベントが存在する場合、前記待機イベント・インジケータを非伝達値にリセットし、前記ＶＭに前記待機イベントを前記伝達させる要求をすることと
を更に備える請求項２８に記載のマシン読み取り可能な媒体。
【請求項３０】
前記命令群は、
前記ＶＭから移行された制御を受け取ることと、
制御の移行は前記ＶＭがオープン・イベント・ウィンドウを有することによるものであったかどうかを判定することと、
前記制御の移行が前記ＶＭがオープン・イベント・ウィンドウを有することによるものであって、前記ＶＭに伝達されるべき待機イベントが存在する場合、前記ＶＭに前記待機イベントを前記伝達させる要求をすることと
を更に備える請求項２８に記載のマシン読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、概して、仮想マシンに関する。本発明の実施形態は、特に、仮想マシン環境においてゲストソフトウェアの実行中にオープン・イベント・ウィンドウの認識を容易にすることに関する。
【背景技術】
【０００２】
クローズド割り込みウィンドウは、割り込みがソフトウェアに伝達されない、ソフトウェア実行中の時間間隔である。また、オープン割り込みウィンドウは、割り込みがソフトウェアに伝達されることができる、ソフトウェア実行中の時間間隔である。割り込みウィンドウのオープンおよびクローズは、多くの手段によって発生しうる。
【０００３】
割り込みウィンドウは、ソフトウェアが割り込みを回避することを目的として、クローズされうる。例えば、命令セット・アーキテクチャ（ＩＳＡ）は、ビットのマスキングまたは他の手法によって、ソフトウェアが外部の割り込みをブロックすることを可能にする。特に、Ｉｎｔｅｌ（登録商標）  Ｐｅｎｔｉｕｍ（登録商標）４のＩＳＡ（本明細書ではＩＡ−３２  ＩＳＡと呼ぶ）では、ＥＦＬＡＧＳレジスタのＩＦビットがクリアされている場合、ハードウェア割り込みはブロックされる。ＩＦビットは、ＥＦＬＡＧＳレジスタをロードする命令群（例：ＰＯＰＦ）、または、ＩＦビットを明示的にセットまたはクリアする命令群（例：ＳＴＩ、ＣＬＩ）によって、セットまたはクリアされうる。更に、特定のマシン状態推移は、ＩＦビットに変更を加えうる（例：割り込みおよび例外ベクタ処理は、ＩＦビットをクリアしうる）。
【０００４】
割り込みウィンドウは、ソフトウェアが割り込みの伝達を妨げるマシン状態推移の過程にあることを理由として、クローズされうる。ＩＡ−３２  ＩＳＡでは、例えば、適切な割り込みベクタ処理は、スタック・セグメントおよびスタック・ポインタが整合性を保つことを必要とするので、スタック・セグメントおよびスタック・ポインタのソフトウェア更新（ＭＯＶＳＳ／ＰＯＰＳＳ）が実行されている間、ＣＰＵは、自動的に割り込みベクタ処理をブロックすることができる。更に、ＩＡ−３２  ＩＳＡは、ＳＴＩの次の命令が完了するまで効力を発しないＩＦビットをセットする、ＳＴＩ命令の実行を指示する。このため、割り込みウィンドウは、ＳＴＩの後の１つの命令に対してオープンする。
【０００５】
追加のイベント、例えば、マスク不可能割り込み（ＮＭＩ）、システム管理割り込み（ＳＭＩ）などは、同様のイベントブロック動作を有してもよい。クローズド・イベント・ウィンドウは、関連するイベントがソフトウェアに伝達されない、ソフトウェアの実行中の時間間隔である。また、オープン・イベント・ウィンドウは、関連するイベントがソフトウェアに伝達されることができる、ソフトウェアの実行中の時間間隔である。
【０００６】
特定のＩＳＡに従って、イベント・ウィンドウの条件は複雑であってもよく、ソフトウェアがあるイベントに対してオープン・イベント・ウィンドウを有するかどうかを判定することを目的として、プロセッサの状態を示す情報についての詳細な調査が必要としてもよい。
【０００７】
本発明は、参照番号が同様の要素を指す添付図面における図を、本発明を限定するものとしてではなく、本発明の一例として使用することによって、説明される。
【図面の簡単な説明】
【０００８】
【図１】本発明が動作しうる仮想マシン環境の一実施形態を示す図である。
【０００９】
【図２】ゲストソフトウェアの動作中における、オープン・イベント・ウィンドウの認識を容易にする処理の一実施形態を示すフロー図である。
【００１０】
【図３】本発明の一実施形態による、リオーダー・バッファ・ロジックの単純化された動作を示す図である。
【００１１】
【図４】ＶＭのイベント・ウィンドウの状態を判定する処理の一実施形態を示すフロー図である。
【００１２】
【図５】ゲストソフトウェアにイベントを伝達する処理の一実施形態を示すフロー図である。
【発明を実施するための最良の形態】
【００１３】
ゲストソフトウェアの動作中にオープン・イベント・ウィンドウの認識を容易にする方法および装置について説明する。以下の説明において、本発明を説明することを目的に、本発明の理解を提供するために多くの特定の詳細が提示される。しかし、当業者にとっては、本発明がこれらの詳細を必要とすることなく実施可能であることは明白である。
【００１４】
以下の詳細な説明のいくつかの部分は、コンピュータシステムのレジスタまたはメモリ内のデータビットの操作に関するアルゴリズムおよび記号表現の形で説明される。これらのアルゴリズムの説明および表現は、データ処理分野の当業者によって、技術の内容の本質を他の当業者に最も効率的に伝えるために使用される方法である。アルゴリズムは、本明細書では、また一般的に、期待される結果に至る自己矛盾無き順序であると考えられる。操作は、物理的な数量に対する物理的な操作を必要とするものである。通常、必ずしも必要ではないが、これらの数量は、格納、転送、結合、比較、および他の操作がされうる、電気または磁気の信号の形態をとる。これらの信号を、ビット、値、要素、記号、文字、言葉、数字などとして参照することは、主に広く使われていることを理由として、便利であることがたびたび証明されている。
【００１５】
しかし、上述および同様の用語は、適切な物理的な数量に関連付けられたものであって、これらの数量に適用される単に便利なラベルであると理解されるべきである。特に記述が無い限り、下記の説明から明白であるように、本発明において、説明は、コンピュータシステムのレジスタおよびメモリ内の物理的な（電子的な）数量として表現されるデータを操作して、コンピュータシステムメモリまたはレジスタ、または、その他の情報を格納、送信、または表示するデバイス内の物理的な数量として同様に表現されるその他のデータに変換する、コンピュータシステムまたは同様の電子コンピューティングデバイスの動作および処理を指す、「処理」、「コンピューティング」、「計算」、「判定」などの言葉を使用する。
【００１６】
実施形態に関する以下の詳細な説明では、本発明を説明する手段として、本発明が実施されうる特定の実施形態を示す添付図面への参照がなされる。添付図面では、数字などは、いくつかの図において一貫して実質的に同様のコンポーネントを説明する。これらの実施形態は、当業者による本発明の実施を可能にするために十分な詳細まで説明される。本発明の範囲から逸脱することなく、他の実施形態が使用されてもよく、また、構造的、論理的、および電気的な変更が加えられてもよい。更に、本発明の種々の実施形態は、それぞれ異なっているが、必ずしも相互排他的ではないと理解されるべきである。例えば、一実施形態において説明される特定の機能、構造、または性質は、他の実施形態に含まれうる。このため、下記の詳細な説明は、本発明を限定するものとして理解されるべきではなく、本発明の範囲は、添付の特許請求の範囲および特許請求の範囲の均等物の全ての範囲のみによって決定される。
【００１７】
下記の例は、実行ユニットおよび論理回路と関連して、仮想マシンの動作中におけるオープン・イベント・ウィンドウの検出を説明するが、本発明の他の実施形態は、ソフトウェアによって実施されることができる。例えば、いくつかの実施形態では、本発明は、本発明による処理を実行するためにコンピュータ（またはその他の電子デバイス）をプログラムするために使用されうる命令群が格納された、マシンまたはコンピュータによって読み取り可能な媒体を含むコンピュータプログラム製品またはソフトウェアとして提供されてもよい。他の実施形態では、本発明の方法は、本発明の方法を実行するハードウェアに制御された論理を含む特定のハードウェアコンポーネント、または、プログラムされたコンピュータコンポーネントおよびカスタム・ハードウェアコンポーネントのいかなる組み合わせによっても実行されうる。
【００１８】
このように、マシン読み取り可能な媒体は、マシン（例：コンピュータ）によって読み取り可能な形態で情報を格納または送信するいかなる機構を含んでもよい。これらの機構は、フロッピーディスク、光ディスク、コンパクト・リード・オンリー・メモリ（ＣＤ−ＲＯＭ）、磁気光ディスク、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、消去可能プログラマブル・リード・オンリー・メモリ（ＥＰＲＯＭ）、電気的消去可能リード・オンリー・メモリ（ＥＥＰＲＯＭ）、磁気または光カード、フラッシュメモリ、インターネットによる送信、電気、光、音波、またはその他の形態の伝播信号（例：搬送波、赤外線信号、デジタル信号、など）などを含み、しかし、これらに限定されない。
【００１９】
更に、デザインは、創造からシミュレーション、そして製造に至る種々の段階を経てもよい。デザインを表すデータは、多くの方法によってデザインを表しうる。最初に、シミュレーションにおいて便利であるように、ハードウェアは、ハードウェア記述言語または他の機能記述言語を使用して表現されうる。更に、ロジックおよび／またはトランジスタゲートを有する回路レベルモデルは、デザインプロセスのいくつかの段階において作成されうる。また、いくつかの段階における多くのデザインは、ハードウェアモデル内の種々のデバイスの物理的な配置を表すデータのレベルに到達する。従来の半導体製造技術が使用される場合、ハードウェアモデルをあらわすデータは、集積回路の製造に使用されるマスクの異なるマスクレイヤ上における種々の特徴の存在または不在を指定するデータであってもよい。デザインの全ての表現において、データは、いかなる形式のマシン読み取り可能な媒体に格納されてもよい。これらの情報を送信するために調節または生成される光波または電波、メモリ、または、ディスクのような磁気または光ストレージは、マシン読み取り可能な媒体であってもよい。これらの媒体の全ては、デザインまたはソフトウェア情報を「伝送」または「表現」してもよい。コードまたはデザインを表現または伝送する電気搬送波が送信されると、電気搬送波のコピー、バッファリング、または再送信が実行される形で、新規のコピーが作成される。このように、通信プロバイダまたはネットワークプロバイダは、本発明の技法を具体化する物（搬送波）のコピーを生成しうる。
【００２０】
図１は、本発明が動作しうる、仮想マシン環境１００の一実施形態を示す。本実施形態では、最小限のプラットフォーム・ハードウェア１１６は、例えば、標準的なオペレーティングシステム（ＯＳ）またはＶＭＭ１１２のような仮想マシン・モニタ（ＶＭＭ）を実行することができる、コンピュータ・プラットフォームを含む。
【００２１】
ＶＭＭ１１２は、概してソフトウェアによって実装されるが、上位のソフトウェアに対して最小限のマシン・インタフェースをエミュレートおよびエクスポートしてもよい。そのような上位ソフトウェアは、通常のまたはリアルタイムＯＳを含んでもよく、限定されたオペレーティングシステムの機能を有する大きく機能を取り除かれた動作環境であってもよく、また、従来のＯＳの機能を有しなくてもよい。あるいは、例えば、ＶＭＭ１１２は、他のＶＭＭの中または上において実行されうる。ＶＭＭは、例えば、ハードウェア、ソフトウェア、ファームウェア、または種々の技法の組み合わせによって実装されてもよい。
【００２２】
プラットフォーム・ハードウェア１１６は、パーソナル・コンピュータ（ＰＣ）、メインフレーム、ハンドヘルド・デバイス、ポータブル・コンピュータ、セットアップ・ボックス、または他のいかなるコンピューティング・システムでもよい。プラットフォーム・ハードウェア１１６は、プロセッサ１１８およびメモリ１２０を含む。
【００２３】
プロセッサ１１８は、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラなどのような、ソフトウェアを実行することができるいかなるタイプのプロセッサであってもよい。プロセッサ１１８は、本発明の実施形態の方法を実行するために、マイクロコード、プログラマブル・ロジック、またはハードウェアによって制御されたロジックを含んでもよい。図１は、プロセッサ１１８を１つだけ示しているが、システム内には１つ以上のプロセッサが存在してもよい。
【００２４】
メモリ１２０は、ハードディスク、フロッピーディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、フラッシュメモリ、または上記のデバイスの組み合わせ、またはプロセッサ１１８によって読み取り可能ないかなる他のタイプのマシン媒体であってもよい。メモリ１２０は、本発明の実施形態の方法を実行するために、命令群および／またはデータを格納してもよい。
【００２５】
ＶＭＭ１１２は、種々のゲストに対して同一または異なるアブストラクションを提供しうる、１つ以上の仮想マシン（ＶＭ）のアブストラクションを他のソフトウェア（すなわち、「ゲスト」ソフトウェア）に対して提供する。図１は、２つのＶＭ１０２および１１４を示す。各ＶＭで実行されるゲストソフトウェアは、ゲストＯＳ１０４または１０６のようなゲストＯＳと、種々のゲストソフトウェア・アプリケーション１０８および１１０とを含んでもよい。ゲストＯＳ１０４および１０６のそれぞれは、ゲストＯＳ１０４または１０６が実行されるＶＭ１０２および１１４内の物理リソース（例：プロセッサ・レジスタ、メモリ、およびＩ／Ｏデバイス）にアクセスすること、および、他の機能を実行することを想定する。例えば、ゲストＯＳは、プロセッサのアーキテクチャおよびＶＭにおいて提供されるプラットフォームによって、全てのレジスタ、キャッシュ、ストラクチャ、Ｉ／Ｏデバイス、メモリなどへのアクセスを有すると想定する。ゲストソフトウェアによってアクセスされるこれらのリソースは、「特権的」または「非特権的」に分類されることができる。特権的リソースついては、ＶＭＭ１１２は、これらの特権的リソースに対する完全な制御を保持しつつ、ゲストソフトウェアによって要求される機能を容易にする。非特権的リソースは、ＶＭＭ１１２によって制御される必要はなく、ゲストソフトウェアによってアクセスされることができる。
【００２６】
更に、各ゲストＯＳは、例外（例：ページフォルト、一般保護違反、など）、割り込み（例：ハードウェア割り込み、ソフトウェア割り込み）、およびプラットフォームイベント（例：初期化（ＩＮＩＴ）およびシステムマネージメント割り込み（ＳＭＩｓ））のような種々のイベントを処理することを想定する。これらの例外、割り込み、およびプラットフォームイベントは、本明細書内では集合的および個別的に「イベント」と呼ぶ。これらのイベントのうちのいくつかは、ＶＭ１０２および１１４の正常な動作を保証するため、および、ゲストソフトウェアから保護するために、ＶＭＭ１１２によって処理される必要があることから、「特権的」である。
【００２７】
特権的イベントが発生したとき、または、ゲストソフトウェアが特権的リソースにアクセスしたとき、制御は、ＶＭＭ１１２に移行される。ゲストソフトウェアからＶＭＭ１１２への制御の移行は、本明細書ではＶＭ  ｅｘｉｔと呼ぶ。リソースへのアクセスを容易にした後、または、イベントを適切に処理した後、ＶＭＭ１１２は、制御をゲストソフトウェアに戻してもよい。ＶＭＭ１１２からゲストソフトウェアへの制御の移行は、ＶＭ  ｅｎｔｒｙと呼ぶ。
【００２８】
一実施形態では、プロセッサ１１８は、仮想マシン制御構造（ＶＭＣＳ）１２４に格納されたデータに従って、ＶＭ１０２および１１４の動作を制御する。ＶＭＣＳ１２４は、ゲストソフトウェアの状態、ＶＭＭ１１２の状態、ＶＭＭ１１２がゲストソフトウェアの動作をどのように制御したいのかを示す実行制御情報、ＶＭＭ１１２とＶＭの間の移行を制御する情報などを含んでもよい。プロセッサ１１８は、ＶＭの実行環境を判定するため、および、その動作を抑制するために、ＶＭＣＳ１２４から情報を読み取る。一実施形態では、ＶＭＣＳは、メモリ１２０に格納される。いくつかの実施形態では、複数のＶＭをサポートすることを目的として、複数のＶＭＣＳ構造が使用される。
【００２９】
ＶＭＭ１１２が、例えば、割り込み（例：ＶＭＭ１１２の動作中に割り込みが発生、または、ＶＭの動作中にＶＭ  ｅｘｉｔとなる割り込みが発生）のようなイベントの後に制御を受け取ると、ＶＭ１１２は、イベント自体を処理する、または、イベントが適切なＶＭによって処理されるべきであることを判定する。イベントがＶＭによって処理されるべきである場合、イベントは、ＶＭがイベントを受け取る準備ができたとき（例：イベントが割り込みである場合は、ＶＭがオープン割り込みウィンドウを有するとき）にのみ、伝達される。一実施形態では、ＶＭＭ１１２は、ＶＭの関連するイベント・ウィンドウがオープンであるかどうかを判定し、関連するイベント・ウィンドウがオープンではない場合は、関連するイベント・ウィンドウがオープンするまでＶＭへのイベントの伝達を遅らせる待機イベントモジュール１３０を含む。
【００３０】
一実施形態では、待機イベントモジュール１３０は、プロセッサ１１８からインジケータを受け取ったときに、イベント・ウィンドウがオープンされたことを判定する。一実施形態では、待機イベントモジュール１３０は、オープン・イベント・ウィンドウを要する待機イベントをＶＭに伝達するかどうかを判定することを目的として、イベント・ウィンドウ状態のインジケータを使用する。他の実施形態では、待機イベントモジュール１３０は、オープン・イベント・ウィンドウを要する待機イベントの伝達以外の機能を容易にするために、イベント・ウィンドウ状態のインジケータを使用する。例えば、待機イベントモジュール１３０は、ＶＭスケジュールの判断を下すことを目的として、ＶＭのイベント・ウィンドウの状態に関する情報を使用してもよい（例：現在のＶＭがクローズド割り込みウィンドウを有する場合、ＶＭＭは、スケジュールポイントにおいて、他のＶＭにスイッチしないことを選択してもよい）。待機イベントモジュール１３０は、ＶＭＭ１１２が他のＶＭを実行するようにスケジュールことを選択するまでの間、ＶＭがオープン・イベント・ウィンドウを有する限り実行される、ＶＭへのＶＭ  ｅｎｔｒｙを生成することを目的として、待機イベント・インジケータを使用してもよい。
【００３１】
一実施形態では、プロセッサ１１８は、待機イベントモジュール１３０にそのようなインジケータを提供するイベント・ウィンドウ監視ロジック１２２を含む。特に、待機イベントモジュール１３０は、ＶＭのイベント・ウィンドウがクローズされていることを判定した場合、待機イベント・インジケータを伝達値にセットして、このＶＭに対してＶＭ  ｅｎｔｒｙを要求する。一実施形態では、待機イベント・インジケータは、ＶＭＣＳ１２４に格納される。１つ以上のイベントに関連する、１つ以上のこのような待機イベント・インジケータが存在してもよい。例えば、ＶＭＣＳ１２４は、それぞれ割り込みおよびＳＭＩイベントに対応する、待機割り込みインジケータおよび待機ＳＭＩインジケータを含んでもよい。あるいは、待機イベント・インジケータは、プロセッサ１１８、メモリ１２０およびプロセッサ１１８の組み合わせ、またはいかなる他のストレージ・ロケーションに存在してもよい。
【００３２】
ＶＭ  ｅｎｔｒｙ要求に応じて、イベント・ウィンドウ監視ロジック１２２は、ＶＭに制御を移行してＶＭの関連するイベント・ウィンドウの監視を開始する。ＶＭの関連するイベント・ウィンドウがオープンであることを検知すると、イベント・ウィンドウ監視ロジック１２２は、制御をＶＭＭ１１２に移行する。一実施形態では、イベント・ウィンドウ監視ロジック１２２は、ＶＭ  ｅｘｉｔがオープン・イベント・ウィンドウによって生じたことを、（ＶＭ  ｅｘｉｔのソースを示す、指定されたリーズン・コードを使用して）ＶＭＭ１１２に通知する。一実施形態では、各イベントタイプに対して、１つのそのような指定されたリーズン・コードが存在してもよい。
【００３３】
一実施形態では、イベント・ウィンドウ監視ロジック１２２は、ＶＭＭ１１２によって発行されたＶＭ  ｅｎｔｒｙ要求を実行するとＶＭのイベント・ウィンドウ状態の監視を開始し、ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべき要求に関連することを判定する。一実施形態では、イベント監視ロジック１２２は、待機イベント・インジケータの現在値に基づいて、ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべき要求に関連するかどうかを判定する。１つ以上のイベントのそれぞれに対応する、１つ以上のそのような待機イベント・インジケータが存在してもよい。例えば、一実施形態では、割り込みに対応する待機割り込みインジケータおよびＳＭＩに対応する待機ＳＭＩインジケータが存在してもよい。
【００３４】
一実施形態では、イベント・ウィンドウが割り込みに対してオープンであるかどうかの判定は、ゲストソフトウェアの割り込みを受け入れる能力の状態が変化したときにゲストソフトウェアによって更新されることができる割り込みフラッグの現在値に基づく。例えば、ＩＡ−３２  ＩＳＡでは、ＥＦＬＡＧＳレジスタは、割り込みがソフトウェアに伝達されるかどうかを一部として制御する、ＩＦ割り込みフラッグビットを有する（上述の通り、ＩＡ−３２  ＩＳＡでは、割り込みウィンドウがオープンであるかどうかを判定するために、割り込みをブロックしうる他の要因が検討される）。あるいは、ＶＭの割り込みウィンドウがオープンであるかどうかを判定するために、他のいかなる従来技術の技法も使用されることができる。他のイベントは、関連するイベント・ウィンドウの状態を判定するために、同様の機構を有してもよい。
【００３５】
ＶＭＭ１１２がＶＭのイベント・ウィンドウはオープンであるというインジケータを受け取ると、ＶＭＭ１１２は、一実施形態では、ＶＭに待機イベントを伝達するようにプロセッサ１１８に要求する。他の実施形態では、ＶＭＭ１１２は、ソフトウェアによってイベントの伝達をエミュレートすることによってイベントをＶＭに伝達（例：割り込みの場合は、ＶＭの割り込みディスクリプタ・テーブルにアクセスすることによって、アクセスおよびフォルト確認を実行することによって、など）し、ＶＭのイベントハンドラの最初の命令から実行が開始するように、ゲストへのＶＭ  ｅｎｔｒｙを実行する。更に他の実施形態では、ＶＭＭ１１２は、上述のように、オープン・イベント・ウィンドウのインジケータに基づいて、スケジューリングの判断を下す。
【００３６】
図２は、ゲストソフトウェアの動作中にオープン・イベント・ウィンドウの認識を容易にする、処理２００の一実施形態を示すフロー図である。この処理は、ハードウェア（例：回路、専用ロジック、プログラマブル・ロジック、マイクロコード、など）、ソフトウェア（汎用コンピュータシステムまたは専用マシン上で実行するソフトウェア）、またはハードウェアおよびソフトウェアの組み合わせを含む、処理ロジックによって実行されてもよい。一実施形態では、処理２００は、図１のイベント・ウィンドウ監視ロジック１２２によって実行される。
【００３７】
図２を参照すると、処理２００は、処理ロジックがＶＭＭからＶＭ  ｅｎｔｒｙ要求を受け取る、処理ブロック２０２から開始する。一実施形態では、ＶＭ  ｅｎｔｒｙ要求は、ＶＭＭによって実行されるＶＭ  ｅｎｔｒｙ命令によって受け取られる。
【００３８】
次に、処理ロジックは、処理ブロック２０４において、ＶＭに制御を移行し、処理ブロック２０６において、ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべきＶＭＭ要求に関連するかどうかを判断する。一実施形態では、処理ロジックは、待機イベント・インジケータが伝達値にセットされているかどうかを判定することによって、ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべきＶＭＭ要求に関連するかどうかを判断する。
【００３９】
ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべきＶＭＭ要求に関連しない場合、処理ロジックは、処理ブロック２０８において、ＶＭが通常通り実行することを許可する（すなわち、特権的イベントがＶＭ  ｅｘｉｔを生じるまで実行する（図２には図示されない））。
【００４０】
ＶＭ  ｅｎｔｒｙ要求がオープン・イベント・ウィンドウを通知されるべきＶＭＭ要求に関連する場合、処理ロジックは、判定ボックス２１０において、ＶＭのイベント・ウィンドウがオープンであるかどうかを判定するためにイベント・ウィンドウ確認を実行する（例：待機割り込みに対しては、割り込みウィンドウがオープンであるかどうかを確認）。一実施形態では、処理ロジックは、ＶＭが命令を実行する前に、イベント・ウィンドウ確認を実行する。あるいは、処理ロジックは、ＶＭがその最初の命令を実行した後に、イベント・ウィンドウ確認を実行する。
【００４１】
イベント・ウィンドウ確認がＶＭの関連するイベント・ウィンドウがオープンであることを示す場合、処理ロジックは、処理ブロック２１２において、ＶＭ  ｅｘｉｔを生成し、一実施形態では、ＶＭ  ｅｘｉｔがオープン・イベント・ウィンドウによって生じたことを（例：関連するリーズン・コードを提供することによって）ＶＭＭに通知する。
【００４２】
イベント・ウィンドウ確認がＶＭの関連するイベント・ウィンドウがクローズであることを示す場合、処理ロジックは、処理ブロック２１４において、ＶＭに１つの命令を実行することを許可し、イベント・ウィンドウ確認を再度実行するために、判定ボックス２１０に戻る。このループは、処理ロジックがＶＭのイベント・ウィンドウがオープンであると判定するまで、または、（例：特権状態のＶＭのアクセスにより）他のＶＭ  ｅｘｉｔが発生するまで繰り返される。
【００４３】
いくつかの実施形態では、ゲスト命令の実行は、フォルト（例：ページ・フォルト、一般保護フォルトなど）によって割り込みされうる。いくつかのフォルトは、ＶＭ  ｅｘｉｔを生じさせうる。例えば、ＶＭＭが物理メモリを保護および仮想化するためにページ・フォルトの際にＶＭ  ｅｘｉｔを必要とする場合、ＶＭでの命令の実行中にページ・フォルトが発生し、結果としてＶＭ  ｅｘｉｔが生じる。したがって、フォルトによって生じるＶＭ  ｅｘｉｔは、イベント・ウィンドウ確認を実行する前に発生しうる。更に、特定の条件（例：ＩＮＩＴ、ＳＭＩＴ、など）がイベント・ウィンドウ確認より高い優先度を有する場合、これらの条件は、ＶＭ命令の実行の後に、しかし、イベント・ウィンドウ確認を実行する前に評価されてもよい。これらの条件のうちのいくつかは、イベント・ウィンドウ確認が実行される前にＶＭ  ｅｘｉｔも生じうる。ＶＭＭがイベント・ウィンドウのオープン以外のイベントによって生じたＶＭ  ｅｘｉｔにより制御を受け取ると、ＶＭＭは、下記に詳細に説明されるように、ＶＭのイベント・ウィンドウの状態を確認する、または、ＶＭ  ｅｎｔｒｙを要求してプロセッサのインジケータがイベント・ウィンドウはオープンされたことを示すのを待つ。
【００４４】
一実施形態では、待機イベント機能は、ハードウェア・リオーダ・バッファ（ＲＯＢ）の拡張ロジックによって、割り込みに対して実装される。図３は、本発明の一実施形態によるＲＯＢロジックの単純化された動作を示す。
【００４５】
図３を参照すると、ＲＯＢロジック３００は、割り込みウィンドウ状態信号３０２、ＶＭＭ／ＶＭ割り込み制御信号３０４、および割り込み信号３０６を受け取ることによって、動作する。割り込みウィンドウ状態信号３０２は、現在動作しているＶＭの割り込みウィンドウがオープンであるかどうかを示す。割り込み信号３０６は、待機状態のハードウェア割り込みを示す。例えば、この信号は、プロセッサのハードウェア割り込み要求（ＩＮＴＲ）ピンに直接的または間接的に関連付けられてもよい。一実施形態では、割り込み信号３０６は、プロセッサに接続された割り込みコントローラによって提供される。ＶＭＭ／ＶＭ割り込み制御信号３０４は、割り込みがＶＭＭまたはＶＭによって制御されるかどうかを示す。一実施形態では、ＶＭＭ／ＶＭ割り込み制御信号３０４は、ＶＭＭによって維持されてＶＭＣＳに格納される。
【００４６】
ＶＭＭ／ＶＭ制御信号３０４が現在の割り込みはＶＭＭによって制御されていることを示し、割り込み信号３０６が割り込みを示す場合、ＲＯＢロジック３００は、割り込みによってＶＭ  ｅｘｉｔが発生すべきであることを示す信号３１０をアサートする。この信号は、このようなＶＭ  ｅｘｉｔを容易にすることを目的として、マイクロコード、専用ハードウェア、またはソフトウェアを起動してもよい。
【００４７】
ＶＭＭ／ＶＭ制御信号３０４が現在の割り込みがＶＭによって制御されることを示し、割り込み信号３０６が割り込みを示し、割り込みウィンドウ状態信号３０２がＶＭの割り込みウィンドウがオープンであることを示す場合、ＲＯＢロジック３００は、割り込みがＶＭに伝達されるべきことを示す信号３１２をアサートする。この信号は、ＶＭへの割り込みの伝達を容易にするために、マイクロコード、専用ハードウェア、またはソフトウェアを起動してもよい。
【００４８】
更に、拡張ＲＯＢロジック３００は、ＶＭＭによってＶＭに伝達されるべき待機割り込みが存在するかどうかを示す、待機割り込み信号３０８を入力として受け取る。本発明の一実施形態では、待機割り込み信号３０８は、ＶＭＭによって維持されてＶＭＣＳに格納される。待機割り込み信号３０８が待機割り込みの存在を示し、割り込みウィンドウ状態信号３０２がＶＭのウィンドウがオープンであることを示す場合、ＲＯＢロジック３００は、オープン割り込みウィンドウによりＶＭ  ｅｘｉｔが生成されるべきことを示す信号３１４をアサートする。この信号は、そのようなＶＭ  ｅｘｉｔを容易にするために、マイクロコード、専用ハードウェア、またはソフトウェアを起動してもよい。
【００４９】
下記に示す表１は、ＲＯＢロジック３００の入力および出力を要約したものである。ここに示される実施形態では、ハードウェア割り込みによるＶＭ  ｅｘｉｔは、オープン割り込みウィンドウによるＶＭ  ｅｘｉｔより高い優先度を有する。両方のＶＭ  ｅｘｉｔの原因は、ＶＭへの割り込みの伝達に対して優先される。他の実施形態は、これらのイベントに対して異なる優先順位付けを有してもよい。表では、Ｘはドントケア値（１でも０でもよい）を示し、表内の１は、アサートされた信号を示す。
【表１】
2007528084.tif 000003
【００５０】
図４は、ＶＭのイベント・ウィンドウの状態を判定する、処理４００の一実施形態を示すフロー図である。この処理は、ハードウェア（例：回路、専用ロジック、プログラマブル・ロジック、マイクロコード、など）、ソフトウェア（汎用コンピュータシステムまたは専用マシン上で実行するソフトウェア）、またはハードウェアおよびソフトウェアの組み合わせを含む、処理ロジックによって実行されてもよい。一実施形態では、処理４００は、図１の待機イベントモジュール１３０によって実行される。
【００５１】
図４を参照すると、処理４００は、処理ロジックが、ＶＭイベント・ウィンドウがオープンされたことを通知される必要性を確認する、処理ブロック４０２から開始する。上述の通り、このような情報は、いつ待機イベントをＶＭに伝達するか、いつスケジュールの判断を下すか、またはその他の理由を判定するために必要とされうる。
【００５２】
処理ブロック４０４において、処理ロジックは、ＶＭイベント・ウィンドウがオープンであることを示す通知を受け取る意図を示すために、待機イベント・インジケータを伝達値にセットする。一実施形態では、待機イベント・インジケータは、ＶＭＣＳに含まれる。
【００５３】
処理ブロック４０６において、処理ロジックは、プロセッサに対して、制御をＶＭに移行するように要求する。一実施形態では、ＶＭ  ｅｎｔｒｙ命令の実行によって、制御を移行させる要求がプロセッサに送信される。
【００５４】
次に、処理ロジックは、処理ブロック４０８において、ＶＭ  ｅｘｉｔの際にＶＭから制御を受け取り、処理ブロック４１０において、ＶＭ  ｅｘｉｔがＶＭイベント・ウィンドウのオープンによるものかどうかを（例：ＶＭ  ｅｘｉｔに関連付けられたリーズン・コードに基づいて）判定する。もしそうである場合、処理ロジックは、処理ブロック４１２において、待機イベント・インジケータを非伝達値にリセットし、処理ブロック４１４において、オープン・イベント・ウィンドウを必要とする操作（例：ＶＭへの待機イベントの伝達）を実行する。
【００５５】
イベント・ウィンドウのオープンによってＶＭ  ｅｘｉｔが発生しなかった場合、処理ロジックは、処理ブロック４１６において、その原因に従ってＶＭ  ｅｘｉｔを処理し、ＶＭに対してＶＭ  ｅｎｔｒｙを要求するために処理ブロック４０８に戻る。
【００５６】
図５は、待機イベントをＶＭに伝達する、処理５００の一実施形態を示すフロー図である。この処理は、ハードウェア（例：回路、専用ロジック、プログラマブル・ロジック、マイクロコード、など）、ソフトウェア（汎用コンピュータシステムまたは専用マシン上で実行するソフトウェア）、またはハードウェアおよびソフトウェアの組み合わせを含む、処理ロジックによって実行されてもよい。一実施形態では、処理４００は、図１の待機イベントモジュール１３０によって実行される。
【００５７】
処理５００は、処理ロジックがＶＭに伝達されるべきイベントを特定する、処理ブロック５０２から開始し、処理ブロック５０４において、このＶＭの対応するイベント・ウィンドウがオープンであるかどうかを判定する。例えば、ＶＭに伝達されるべきイベントが割り込みである場合は、処理ロジックは、ＶＭの割り込みウィンドウの状態を確認する。
【００５８】
イベント・ウィンドウがオープンである場合、処理ロジックは、一実施形態では、処理ブロック５０６において、プロセッサに対してイベントをＶＭへ伝達するように要求する。この要求は、ＶＭ  ｅｎｔｒｙ命令の実行によって開始されるＶＭ  ｅｎｔｒｙ要求の一部であってもよい。他の実施形態では、ＶＭＭは、ソフトウェアの技法を使用してイベントのＶＭへの伝達をエミュレートし、最初に実行される命令がＶＭのイベントハンドラの最初の命令となるようにＶＭへのＶＭ  ｅｎｔｒｙを実行してもよい。
【００５９】
イベント・ウィンドウがオープンでない場合、処理ロジックは、処理ブロック５０８において、待機イベントのために、待機イベント・インジケータを伝達値にセットする。例えば、ＶＭＣＳ内に待機イベント・インジケータ用の１つのビットが存在する場合は、処理ロジックは、それをアサート値にセットしてもよい（例：１にセット）。次に、処理ロジックは、処理ブロック５１０において、ＶＭ  ｅｎｔｒｙ要求をプロセッサに送信する。ある実施形態では、待機イベント・インジケータは、ＶＭＣＳ内の１つのビットである。ある実施形態では、ＶＭ  ｅｎｔｒｙ要求は、ＶＭ  ｅｎｔｒｙ命令を実行することによって、プロセッサに送信される。
【００６０】
次に、処理ロジックは、処理ブロック５１２において、ＶＭ  ｅｘｉｔ時にＶＭから制御を受け取り、処理ブロック５１４において、ＶＭ  ｅｘｉｔがＶＭのイベント・ウィンドウのオープンによるものであるかどうかを（例：ＶＭ  ｅｘｉｔに関連付けられたリーズン・コードに基づいて）判定する。もしそうである場合、処理ロジックは、処理ブロック５１８において、待機イベント・インジケータを非伝達値にリセットし、処理ブロック５１６において、プロセッサに対して待機イベントをＶＭへ伝達するように要求する。この要求は、ＶＭ  ｅｎｔｒｙ命令の実行によって開始されるＶＭ  ｅｎｔｒｙ要求の一部であってもよい。他の実施形態では、ＶＭＭは、ソフトウェアの技法を使用して、ＶＭへの待機イベントの伝達をエミュレートしてもよい。ＶＭ  ｅｘｉｔが、イベント・ウィンドウのオープンによって生じなかった場合、処理ロジックは、処理ブロック５２０において、その原因に従ってＶＭ  ｅｘｉｔを処理し、一実施形態では、ＶＭにＶＭ  ｅｎｔｒｙを要求するために処理ブロック５１０に戻る。この要求に応じて、プロセッサは、制御をＶＭに移行して、ＶＭの最初の命令が実行される前に、ＶＭのイベント・ウィンドウがオープンであるかどうかを確認する。
【００６１】
他の実施形態では、処理ロジックは、処理ブロック５２０において、ＶＭ  ｅｘｉｔを処理した後にＶＭのイベント・ウィンドウがオープンであるかどうかを判定し、ＶＭのイベント・ウィンドウがクローズであることを判定すると、処理ブロック５１０に戻る。処理ロジックは、ＶＭの関連する状態を調査することによって、この判定を行う。例えば、待機割り込みの場合、処理ロジックは、ＥＦＬＡＧＳレジスタのＩＦビット、および、ＶＭの割り込みウィンドウの状態を示す他の状態を調査してもよい。本実施形態では、プロセッサは、ＶＭに制御を移行し、ＶＭにその最初の命令の実行を許可し、そしてＶＭのイベント・ウィンドウがオープンであるかどうかを確認することによって、ＶＭ  ｅｎｔｒｙ要求に応答する。
【００６２】
一実施形態では、処理ロジックは、前のＶＭ  ｅｘｉｔがイベント・ウィンドウのオープンより高い優先度を有するイベントによって生じた場合にのみ、ＶＭのイベント・ウィンドウがオープンであるかどうかを判定するために追加の確認を実行する。換言すると、処理ロジックは、ＶＭ  ｅｘｉｔを生じさせた高い優先度を有するイベントにより、イベント・ウィンドウのオープンがプロセッサによって認識されなかった可能性がある場合にのみ、追加のイベント・ウィンドウ確認を実行する。
【００６３】
上述の通り、他の実施形態では、ＶＭＭは、オープン・イベント・ウィンドウを必要とする待機イベントの伝達以外の機能を容易にするために、待機イベント・インジケータを使用してもよい。例えば、そのようなＶＭＭは、ＶＭのスケジュールの判断を行うために、ＶＭのイベント・ウィンドウの状態に関する情報を使用してもよい（例：現在のＶＭがクローズド割り込みウィンドウを有する場合、ＶＭＭは、スケジュールポイントにおいて、他のＶＭにスイッチしないことを選択してもよい）。そのようなＶＭＭは、ＶＭ  ｅｘｉｔが生成され制御がＶＭＭに移行されるまでの間、ＶＭがオープン・イベント・ウィンドウを有する限り実行される、ＶＭへのＶＭ  ｅｎｔｒｙを生成することを目的として待機イベント・インジケータを使用してもよい。このＶＭ  ｅｘｉｔに続いて、ＶＭＭは他のＶＭの実行をスケジュールすることを選択してもよい。
【００６４】
このように、仮想マシン環境においてゲストソフトウェアの動作中にオープン・イベント・ウィンドウの認識を容易にする方法および装置が説明された。上述の説明は、本発明を説明することを意図したものであって、本発明を限定することは意図していないと理解されるべきである。上記の説明を読解することにより、当業者には多くの他の実施形態が明白となる。このため、本発明の範囲は、添付の特許請求の範囲および特許請求の範囲の均等物の全ての範囲によって決定される。
【図１】
2007528084.tif 000004
【図２】
2007528084.tif 000005
【図３】
2007528084.tif 000006
【図４】
2007528084.tif 000007
【図５】
2007528084.tif 000008
【国際調査報告】
2007528084.tif 000009
2007528084.tif 000010