JP5697609B2 - 仮想化により導入される待ち時間の管理 - Google Patents

Description

[001]本発明の１つ以上の実施形態は、一般に仮想コンピューティング、より詳細には仮想化により導入される待ち時間の管理に関する。

[002]仮想化技術は市場において一般的になっている。これらの技術の少なくともいくつかは、仮想ハードウェア抽象化をゲスト・オペレーティング・システムに提供し、それらがホストコンピュータ上の機能的に分離された環境の仮想計算機での実行を可能にする。仮想化によって、１つ以上の仮想（ゲスト）計算機が単一の物理的（ホスト）コンピュータで実行することが可能になり、機能的な及びパフォーマンス分離をプロセッサ、メモリ、記憶装置等に提供する。

[003]コンピュータサイエンスの分野において周知のように、仮想計算機は、実際の物理的コンピュータシステムの抽象化―「仮想化」―である。図１は、仮想化を実施するコンピュータシステム（コンピュータシステム７００）の１つの可能性がある配置を示す。図１に示すように、仮想計算機又は「ゲスト」２００は「ホスト・プラットフォーム」又は単に「ホスト」にインストールされ、それはシステムハードウェア、即ち、ハードウェア・プラットフォーム１００、及びシステム・レベルのソフトウェア、例えばオペレーティング・システム又は類似のカーネル、又は仮想計算機モニタ又はハイパーバイザ（下記参照）、又はこれらのいくつかの組合せから成る１つ以上の層又はコ・レジデント構成要素を含む。システムハードウェアは、通常、１つ以上のプロセッサ１１０、メモリ１３０、ある形の大容量記憶装置１４０、及びさまざまな他の装置１７０を含む。

[004]各仮想計算機２００は、通常、仮想システムハードウェア２０１及びゲスト・システム・ソフトウェア２０２の両方を有する。仮想システムハードウェアは、通常、少なくとも１つの仮想ＣＰＵ、仮想メモリ２３０、少なくとも１つの仮想ディスク２４０、及び１つ以上の仮想装置２７０を含む。ディスク―仮想又は物理的―が「装置」でもあるが、ディスクの重要な役割のため、通常、別に考慮されることに注意されたい。仮想計算機の仮想ハードウェア構成要素の全てが、対応する物理的構成要素をエミュレートするために、公知の技術を使用してソフトウェア内で実施可能である。ゲスト・システム・ソフトウェアは、さまざまな仮想装置２７０のために必要に応じて、ゲスト・オペレーティング・システム（ＯＳ）２２０及びドライバ２２４を含む。

[005]単一の仮想計算機２００が複数の仮想化されたプロセッサで構成されることがあることに注意されたい。コンピュータシステムがより大きい数の並行スレッドにスケール変更できるようにするために、複数のＣＰＵを備えるシステムが開発された。これらの対称的マルチプロセッサ（ＳＭＰ）システムは、ＰＣプラットフォームの拡張として、及び他のベンダーから利用できる。基本的に、ＳＭＰシステムは、複数のプロセッサを共有主メモリ及び共有入出力装置に接続するハードウェア・プラットフォームである。仮想計算機はＳＭＰ仮想計算機としても構成されていてもよい。図１は、例えば、仮想計算機２００内の複数の仮想プロセッサ２１０―０、２１０―１、．．．、２１０−ｍ（ＶＣＰＵ０、ＶＣＰＵ１、．．．、ＶＣＰＵｍ）を例示する。

[006]更に別の構成は、いわゆる「マルチコア」ホスト・アーキテクチャで見つかり、そこにおいて複数の物理的ＣＰＵは、それ自体の機能ユニット（例えば、浮動小数点ユニット及び算術論理演算ユニットＡＬＵ）のセットによって、単一チップに製造され、独立してスレッドを実行することが可能であり、マルチコア・プロセッサは、通常、非常に制約された資源、例えばいくつかのキャッシュのみを共有する。複数のスレッドの同時実行を提供する更に別の構成は「同時マルチスレッディング」と呼ばれ、そこでは複数の論理ＣＰＵ（ハードウェア・スレッド）は単一チップで同時に動作するが、しかし、そこでは論理ＣＰＵはいくつかの資源、例えばキャッシュ、バッファ、機能ユニット等を柔軟に共有する。本発明の１つ以上の実施形態は、仮想計算機に含まれるプロセッサのタイプ−物理的及び／又は論理的−又は数に関係なく使用されてもよい。

[007]多くの場合において、アプリケーションが少なくとも部分的に間接的に、即ちゲストＯＳ２２０及び仮想プロセッサを介して実行している場合であっても、仮想計算機２００上で実行するアプリケーション２６０は、「実際の」コンピュータで実行する場合のように機能する。実行可能ファイルは仮想ディスク２４０又は仮想メモリ２３０からゲストＯＳによってアクセスされ、それはその仮想計算機に割り当てられた実際の物理ディスク１４０又はメモリ１３０の部分である。一旦アプリケーションが仮想計算機内にインストールされると、丁度今あたかもファイルがアプリケーションの従来のインストールの結果として格納されたかのように、ゲストＯＳはファイルを仮想ディスクから検索する。仮想計算機の設計及び動作は、コンピュータサイエンスの分野では周知である。

[008]或るインタフェースが、通常、仮想計算機内のゲスト・ソフトウェアと下にあるハードウェア・プラットフォーム内のさまざまなハードウェア構成要素及び装置内で必要とされる。このインタフェース（それは一般に「仮想化ソフトウェア」又は「仮想化論理」と呼ばれることがある）は、１つ以上のソフトウェア及び／又はハードウェア構成要素及び／又は層を含むことができ、おそらく、「仮想計算機モニタ」（ＶＭＭ）、「ハイパーバイザ」、又は「仮想化カーネル」のように、仮想計算機技術の分野で知られているソフトウェア構成要素の１つ以上を含んでいてもよい。仮想化用語が時間と共に進化して、完全にはまだ標準化されていないので、これらの用語は、それらが照会するソフトウェア層と構成要素との間の明白な差異を必ずしも提供するわけではない。例えば、「ハイパーバイザ」という用語は、しばしば、ＶＭＭ及びカーネルを一緒に、別々であるが協同している構成要素としてか、或いは１つ以上のＶＭＭが完全に、又は部分的にカーネル自体に組み込まれて表すために用いられるが、しかしながら、「ハイパーバイザ」という用語は、それよりも、ＶＭＭだけの或る変形を意味するために用いられることがあり、それは仮想化を支援するために、いくつかの他のソフトウェア層又は構成要素とインタフェースする。その上、いくつかのシステムにおいて、ある仮想化コードが、他の仮想計算機の動作を容易にするために、少なくとも１つの「優れた」仮想計算機に含まれる。更にまた、仮想計算機の特定のソフトウェア支援をホストＯＳ自体に含まれていてもよい。特に明記しない限り、本願明細書において記載されている本発明の１つ以上の実施形態は、仮想化論理のいかなるタイプ又は構成も有している仮想化されたコンピュータシステムにおいて使用されてもよい。

[009]図１は、仮想化ソフトウェアの他の構成要素からの分離実体として現れる仮想計算機モニタを示す。更にまた、本発明の１つ以上の実施形態を実施するために用いられるいくつかのソフトウェア構成要素は、すべての仮想計算機と下にあるハードウェア・プラットフォームとの間に論理的に位置する「仮想化層」及び／又はシステム・レベルのホスト・ソフトウェア内にあるとして示されて記載される。専用ハードウェアのこの層の少なくとも一部を実施することが可能であるけれども、この仮想化層は全体の仮想化ソフトウェアの一部と考えてもよい。例示の実施形態は、簡単及び明確のために、そして実例としてだけ与えられ、--上記したように、差異は必ずしも非常に明確でない。また、他に指示がない限り、又は説明から明らかでなければ、本発明の１つ以上の実施形態が、仮想化ソフトウェアの全体の構造内のどこでも、そして仮想化のための特定のハードウェア支援を提供するシステムにおいてさえも実施できると仮定される。

[010]仮想計算機のさまざまな仮想化されたハードウェア構成要素、例えば、仮想ＣＰＵ２１０―０、２１０―１、．．．、２１０−ｍ、仮想メモリ２３０、仮想ディスク２４０、及び仮想装置２７０は、概念上の簡単のために仮想計算機２００の一部であるとして示される。実際には、これらの「構成要素」は、通常、ＶＭＭに含まれるソフトウェア・エミュレーション３３０として実施される。

[011]いろいろなシステムは様々な程度に仮想化を実施することができ−「仮想化」は一般に明快であるよりも一連の定義に関連があり、そして一方では速度と効率との間、他方では分離と一般性の間のトレードオフに関して設計選択をしばしば反映する。例えば、「全仮想化」は、いかなる形のソフトウェア構成要素も仮想化されないコンピュータで見つかるもの以外のゲストに含まれないシステムを意味するために用いられることがあり、従って、ゲストＯＳは、仮想化された環境における使用を支援するために特に含まれた構成要素を有さない、即納の市販のＯＳであってもよい。

[012]対照的に、まだ普遍的に認められた定義を達成していない別の用語は、「パラ仮想化」のそれである。用語が意味するように、「パラ仮想化された」システムは「完全に」仮想化されず、むしろゲストは何らかの方法で、仮想化を容易にする特定の特徴を提供するように構成される。例えば、いくつかのパラ仮想化されたシステムのゲストは、例えば、特定の特権命令、特定のメモリ・アドレス範囲などを回避すること等によって、仮想化するのが難しい動作及び構成を回避するように設計されている。別の例として、多くのパラ仮想化されたシステムは、仮想化ソフトウェアの他の構成要素への明示的な呼び出しを可能にするゲスト内にインタフェースを含む。

[013]ある場合、用語「パラ仮想化」は、ゲストＯＳ（特に、そのカーネル）がこの種のインタフェースを支援するように特に設計されていることを意味する。この見解によれば、例えば、ゲストＯＳとしてマイクロソフト・ウインドウＸＰ（商標）の市販バージョンを有することは、パラ仮想化の概念と整合していない。他は、情報を直接仮想化ソフトウェアの他の構成要素に提供することを特に目的とするコードを有するゲストＯＳも含むために、用語「パラ仮想化」をより大まかに定義する。この見解によれば、このようなゲストＯＳが仮想化されたコンピュータシステムを支援するように特に設計されていない即納の市販ＯＳである場合であっても、他の仮想化構成要素と通信するように設計されているドライバのようなモジュールをロードすることはシステムをパラ仮想化する。他に示されるか明らかでない限り、本発明の実施形態は仮想化の特定の「程度」を有するシステムの使用にも制限されずに、完全又は部分的な（「パラ」）仮想化の特定の概念にも限られていないことになっている。

[014]完全な仮想化と部分的な（パラ）仮想化との間の時々あいまいである差異に加え、中間システム・レベルソフトウェア層の２つの配列―「ホスト型」構成及び非ホスト型構成（それは図１に示される）が一般に使用される。ホスト型の仮想化されたコンピュータシステムにおいて、既存の多目的オペレーティング・システムは、同時に又は時々ＶＭＭの要求により、特定の入出力（Ｉ／Ｏ）動作を実行するために用いる「ホスト」ＯＳを形成する。

[015]図１に示したように、多くの場合、仮想計算機を支援するために特に構成されたソフトウェア層―カーネル６００―のトップにＶＭＭを配置することが有益であることがある。この構成はしばしば「非ホスト型」と呼ばれる。カーネル６００はまた、いくつかのアーキテクチャにおいて、システムを起動し、仮想化ソフトウェアとの特定のユーザ相互作用を促進するために用いるコンソール・オペレーティング・システムだけでなく、別にスケジュール可能な、その上でランするその他のアプリケーションも処理する。

[016]カーネル６００がゲストＯＳ２２０内にあるであろうカーネルと同じでない−周知のように、あらゆるオペレーティング・システムがそれ自体のカーネルを有することに注意されたい。図１に示す構成が更に「非ホスト型」と一般に称される場合であっても、カーネル６００は上記の通り仮想計算機／ＶＭＭの「ホスト」プラットフォームの一部であり、カーネルは、ホストの一部及び仮想化ソフトウェア又は「ハイパーバイザ」の一部の両方かもしれないことにも注意されたい。用語の違いは、仮想化の技術において、まだ進化している見通し及び定義のうちの１つである。

[017]関連技術の当業者により理解されるように、仮想計算機２００がランしている間に、ハイパーバイザ（又はＶＭＭ等）は、しばしば、ゲスト動作を適切に仮想化するために、些細でない量の仕事を実行する。ある場合には、ハイパーバイザが初期の動作を非同期で処理する間に、例えばゲストＩ／Ｏ動作、システムアーキテクチャ、及びデバイスモデルによって、ゲストが他の有用な作業を続けることができる。非同期動作が、例えば、仮想Ｉ／Ｏ完了割り込みを通知し、非仮想化されたシステム内のハードウェアの動作をエミュレートすることによって完了するときに、ハイパーバイザは通常ゲストＯＳに通知する。

[018]ゲスト・オペレーティング・システムを含むオペレーティング・システムは、非同期技術を用いて公知のハイレイテンシー動作、例えば装置Ｉ／Ｏを許容するように通常は設計される。例えば、更なる実行（例えば、ファイルシステム・メタデータ書込み）の前に完了しなければならないディスクＩ／Ｏ要求を実行するプロセスは、Ｉ／Ｏが完了するまでスケジュールされず、他の無関係なプロセスがランすることを許容する。

[019]仮想化は、ゲストＯＳによって検出可能であるか又は不可能である有意な遅延を導入することもできる。遅延を引き起こす仮想化ベースの動作がゲストＯＳに可視ではない場合があるので、これらの遅延はゲストＯＳにより予想されない場合がある。例えば、ハイパーバイザは、他のＶＭのためのメモリを使用可能にするために、ディスクにゲストの「物理的な」メモリのページをスワップアウトすることができる。ゲストプロセスが後でこの「物理的な」メモリにアクセスするときに、ハイパーバイザは、プロセスが実行を続けることができる前にディスクからその内容を復元しなければならない。既存のシステムにおいて、ハイパーバイザは、全てのＶＭ、又は少なくともアクセスを実行したＶＣＰＵをスケジュールしない。スワップインが完了するまで、これはゲストが更に進行することを効果的にブロックする。

[020]具体例をより詳細に提供するために、ＯＳが仮想化されるときに、ゲストの物理ページ（ＧＰＰＮ）は、物理ホスト内のいくつかの実際の機械ページ（ＭＰＮ）にマップされなければならない。ハイパーバイザがメモリ圧力の下にあるときに、それは通常はゲストからＭＰＮを取り戻すことを必要とし、取り戻されたＭＰＮは通常はいくつかの作業用セット・アルゴリズムに基づいて（又はランダムに）選択される。次に、ハイパーバイザはそのページをハイパーバイザレベルのスワップ装置にスワップし、ＭＰＮを、例えば、別のゲストによって使用可能にする。第１ＶＭがそれからＧＰＰＮにアクセスすることがある場合、それはプロセッサ内のページ・フォールトを受けて、ハイパーバイザはコンテンツをスワップ装置から戻さなければならないだろう。このプロセスは非常に時間がかかることがある。より詳しくは、スワップ装置が通常はディスク・ドライブ等の機械装置であるので、典型的アクセス待ち時間は数ミリ秒であり、そこにおいて最新のＣＰＵは数百万の命令を実行できる。残念なことに、ハイパーバイザ及びその動作がゲストに可視ではないので、ゲストはその間に前進することができない。これは、ゲストが待ち時間の間に別のプロセスをスケジュールすることができずにハイパーバイザが長い動作を実行する多くの状況のわずかに１つの実施例である。

[021]ゲストが、ハイパーバイザがゲストに可視ではない仮想化タスクを実行している有用な作業を実行し続けることができることが望ましい。

[022]仮想化論理は、現在スケジュールされているゲストプロセスが、仮想化論理がゲスト・オペレーティング・システムに可視ではない仮想化ベースの動作を実行するために応答する機能を実行したことを判断する。仮想化論理によって、ゲスト・オペレーティング・システムは現在スケジュールされているゲストプロセスのスケジュールを中止せず、少なくとも１つの別のゲストプロセス（それはゲストＯＳアイドルループであってもよく、必ずしもならないわけではない）をスケジュールする。仮想化論理はそれから、少なくとも１つの別のゲストプロセスの実行と並行して、仮想化ベースの動作を実行する。仮想化ベースの動作の実行を完了することに応答して、仮想化論理によって、ゲスト・オペレーティング・システムはスケジュールを中止したゲストプロセスのスケジュールを変更する（即ち、（１）仮想化論理はランの準備をしているプロセスをマークし、（２）ある後の時点で、ゲストＯＳは、すべてのラン可能なプロセスの中からプロセスを選択し、実際にそれを実行する）。

[023]この概要及び以下の詳細な説明に記載されている特徴及び利点は全てを含むわけではなく、特に、多くの付加的な特徴及び利点が、図面、明細書、及びこの請求項を考慮して関連技術の当業者にとって明らかである。更に、本明細書において使用する用語が主に読みやすさ及び教育目的のために選択され、発明の主題を詳細に描写するか又は制限し、この種の発明の内容を決定するのに必要である請求項を用いるように選択されなかった点に留意する必要がある。

[024]従来技術の仮想化技術の実施例を示しているブロック図である。 [025]本発明のいくつかの実施形態による、仮想化により導入される待ち時間の管理を例示しているブロック図である。 [026]本発明の他の実施形態による、仮想化により導入される待ち時間の管理を例示しているブロック図である。 [027]本発明の更に他の実施形態による、仮想化により導入される待ち時間の管理を例示しているブロック図である。

[028]図は説明の目的のみに本発明の実施形態を示す。当業者は、以下の説明から、本願明細書において例示される構成及び方法の別の実施形態が本願明細書において記載されている本発明の原理を逸脱しない範囲で使用できることが容易に分かるだろう。

[029]図２は、本発明のいくつかの実施形態による、ハイパーバイザ２０１（又はＶＭＭ等）が仮想化により導入される待ち時間を管理するシステム２００を例示する。各種の構成要素が個体として図２に示されているけれども、各図示の構成要素は、ソフトウェア、ハードウェア、ファームウェア、又はこれらのいかなる組合せとしても実施可能な機能の一群を表すことを理解すべきである。構成要素がソフトウェアとして実行される場合、それはスタンドアロン・プログラムとして実行できるが、例えば、より大きいプログラムの一部として、複数の別々のプログラムとして、カーネル・ロード可能なモジュールとして、１つ以上のデバイス・ドライバとして、あるいは１つ以上の静的又は動的に連係されたライブラリとして、他の方法で実行できる。

[030]図２に示される実施形態において、ハイパーバイザ２０１は現在スケジュールされているゲストプロセス２６０にコード２０３を注入するためにアップコール技法を使用し、それにより、注入されたコード２０３がゲストプロセス２６０文脈において実行されるときに、そのゲストプロセス２６０はブロックし、ゲスト・オペレーティング・システム２２０に別のプロセス２６０をスケジュールさせる。ゲストプロセス２６０にコード２０３を注入するためにアップコール技法を使用する実施機構は、２００８年１０月３０日に出願された、現在出願番号第１２／２６１，６２３号が付されている、「透過なＶＭＭ支援ユーザモード実行制御転送」というタイトルの同一出願人による特許出願に詳述されていて、それはその内容全体を参照によって本願明細書に引用したものとする。引用された出願で詳細に説明されているように、このアップコールベースの方法は、例えば、ハイパーバイザ２０１がアップコールを実行するために使用できるメモリの１つ以上のページを登録しているゲストによって、又は既存のゲストコードページを修正しているハイパーバイザ２０１によって、ゲスト文脈へのコード２０３の注入を必要とする。

[031]一実施形態において、ハイパーバイザ２０１によって、ゲスト・オペレーティング・システム２２０は、例えばブート時間に、仮想装置２０５（例えば、周辺構成要素相互接続（ＰＣＩ）装置）をロードする。ハイパーバイザ２０１がゲストＯＳ２２０が読取るＢＩＯＳの動作を制御するので、それはゲストＯＳ２２０にこの種のロード動作を実行させることが可能である。仮想装置２０５用のドライバ２０７は、装置２０５を開く少量のコード（例えば、ページ）のみを含み、単純なブロッキング動作（例えば、装置２０５から１バイトを読取る）を実行して、ブロッキング動作から戻ると、呼び出し側に制御を戻す。もちろん、書込み、アイオクトル（ｉｏｃｔｌ）等の、いかなるブロッキング動作も読取りの代わりに使用できる。

[032]現在スケジュールされているゲストプロセス２６０がハイパーバイザ２０１内の長い待ち時間のエミュレーション活動をトリガーするときに、上記の通りに、ハイパーバイザ２０１はゲストプロセス２６０にアップコールを実行する。アップコールは、ドライバ２０７を呼び出すゲストコード２０３（例えば、特別な事前に配列されたゲストページから）を実行する。より詳しくは、プロセス２６０は、それに渡されるファイル記述子に基づいて装置２０５に向けられるシステムコール（例えば、リナックス（登録商標）「読取り」又は「アイオクトル」）を実行できる。システムコールは制御をゲストＯＳ２２０へ転送し、それは要求されたブロッキング動作を実行するためにドライバ２０７内のコードを呼び出す。このように、ドライバ２０７は、実質的に、現在スケジュールされているゲストプロセス２６０によって呼び出される。上述の通り、ドライバ２０７は仮想装置２０５をオープンし、例えば、それから１バイトを読取る。この読取りはブロッキング動作であり、読取り要求が満たされるまで、それはゲストＯＳ２２０にプロセス２６０のスケジュールを中止させる。換言すれば、現在スケジュールされているゲストプロセス２６０はブロックし、単にスケジュールされているままであるよりはむしろ、ハイパーバイザ２０１がその長い待ち時間タスクを実行する間に有用な作業を実行しない。ゲストプロセス２６０がブロックするので、ゲストＯＳ２２０は有用な作業を実行するために別のプロセスを自動的にスケジュールする。並行して、ハイパーバイザ２０１は初期の高い待ち時間エミュレーション要求を満たし続ける。本特許における説明は、「プロセス」がスケジュールされる、スケジュールを中止するなどに関して行われる。しかしながら、当業者は、本発明が「スレッド」、「タスク」、「ジョブ」、「文脈」、「スケジュール可能な実体」、及び使用可能な他の類似の用語に関してもあてはまることを理解するだろう。従って、用語「プロセス」は通常、その用語が本願明細書において使われるように、ＯＳ又は他のシステム・レベルのソフトウェアによって、「スケジュールされた」いかなる実体として本願明細書において広く解釈されなければならない。

[033]ハイパーバイザがなされて高い待ち時間動作を実行しているときに、それは、例えば、装置２０５がブート時間にゲストと共に登録されたときに事前に決定されたＩＲＱ番号を用いて、ゲスト装置２０５に仮想割り込みを発する。割り込みに応答して、ドライバ２０７は、読取られた呼び出しを「完了し」、呼び出しプロセス２６０に制御を戻す。これによって、ブロックされたゲストプロセス２６０はスリープを解除し、実行を再開する。

[034]最適化として、第１アップコールは仮想装置２０５を開き／読取ることができ、装置２０５を開いたままにする。このようにして、次のアップコールは単に装置２０５を再開せずに読取ることができる。この場合には、仮想装置２０５のためのファイル記述子はプロセス出口で自動的に閉じる。別の実施形態では、セマフォベースの技法がブロッキング動作の使用の代わりに実施される。セマフォベースの技法は下記の図４に関連してより詳細に説明される。一実施形態において、ドライバ２０７によって、プロセス２６０は、ゲストＯＳ２２０内でそのスケジューリング優先順位を下げることによって、スケジュールを中止される。同様に、ドライバ２０７は、ゲストＯＳ２２０にそれのスケジュールを変更させる待ち時間を減らすためにプロセス２６０のスケジューリング優先順位を上げる（即ち、それを実行可能であるとマークすることと、ゲストＯＳスケジューラに実行のためにそれを実際に選択させることとの間の時間を減らす）。

[035]ここで図３に戻ると、特別な装置２０５を利用しない他の実施形態が例示されている。図２に示される実施形態と同様に、現在スケジュールされているゲストプロセス２６０がハイパーバイザ２０１内の長い待ち時間エミュレーション活動をトリガーするときに、ハイパーバイザ２０１はゲストプロセス２６０にアップコールを実行する。しかしながら、図３に示したように、本実施形態において、アップコールは、指定された期間にスリープ動作を実行するコード２０３を実行するだけであり（例えば、リナックス（登録商標）の下でｎａｎｏｓｌｅｅｐ（）システム・コールを呼び出すことによって）、次に呼び出し側に戻る。スリープしようとしている現在スケジュールされているゲストプロセス２６０によって、指定された時間が経過するまで、ゲストＯＳ２２０はそのプロセス２６０のスケジュールを中止し、別のものをスケジュールする。その時、ゲストＯＳ２２０はスリーピングプロセス２６０のスリープを解除し、それは、スリープ解除すると、初期の長い待ち時間仮想化動作を生じた命令を再実行する。ハイパーバイザ２０１がその動作をまだ完了しなかった場合は、それはプロセス２６０をスリープに戻すためにアップコールを再び利用する。ゲストプロセス２６０のスリープ解除の後、仮想化動作が完了するまで、同じシーケンスが繰り返される。各繰り返しの間、ゲストＯＳ２２０はスリーピングプロセス２６０以外の何かをスケジュールし、ハイパーバイザ２０１が長い待ち時間仮想化動作を実行している間に、有用な作業がゲストレベルで実行可能である。別の実施形態では、スリーピングプロセス２６０をスリープ解除させるよりはむしろ、ハイパーバイザ２０１は高い待ち時間動作が完了したスリープループ内のコードに指示する（例えば、フラグをプロセスに可視であるように設定することによって、又はアップコール・コード・ページのコードを変えることによって）。場合によっては、例えば、高い待ち時間動作に副作用がある場合、再実行は可能ではないかもしれないことに注意されたい。この場合には、コードはフラグを点検して、実行を続けるべきであるか又は他の繰り返しのためにスリープするべきかどうか決めることができる。

[036]上記のサイクルが、ゲストプロセス２６０をスリープさせるために選択される時間、及びそれがハイパーバイザ２０１がそのタスクを完了するためにかかる時間に依存して、複数回繰り返されることがあることに注意されたい。加えて、スリープ時間がそれがハイパーバイザがその作業を完了するためにかかる時間にどれだけ密接にマッチしているかに依存して、ハイパーバイザ２０１の仮想化動作が完了した後、プロセス２６０はしばらくの間スリープしたままであってもよい。いくつかの実施形態では、デフォルト期間が使われ、その場合、使用する特定のデフォルト値は可変的な設計パラメータである。いくつかの実施形態では、ハイパーバイザ２０１は、それがその仮想化動作を実行するために必要とする時間の長さの評価に基づいたパラメータを有するスリープコマンドを出すことができる。評価がより正確であるほど、関連するポーリング動作の計算費用はより低い。それらの状況の下で、プロセス２６０がスリープ解除した後にしばらくの間ゲストラン待ち行列に留まる可能性があるので、ゲストＯＳ２２０が重いＣＰＵ負荷の下にある場合、反復ポーリングのコストが低下できる点にも注意されたい。

[037]図２に関連して説明されている方法によって、ハイパーバイザ２０１は、仮想装置２０５及び割り込みベースの通知を使用して、ゲストプロセス２６０依存を非常に明確に表す。例えば、遅延が長いか予測不可能であると思われるとき、これはよく機能する。この割り込みベースのシナリオの負の側面は、それが少しヘビーウエイトであるということであり、仮想装置２０５はゲストＯＳ２２０にインストールされ、ブロックされたゲストプロセス２６０が再開する前に、完全な仮想割り込み経路は実行されることを必要とする。割り込み経路自体の実行は計算的に高価な場合がある。対照的に、図３に関連して説明されているシナリオは明確な依存を表さずに、その代わりにポーリング・ベースの技術を使用する。このポーリング方法は、仮想装置２０５の使用と関連するオーバーヘッドを有さずに、割り込む。しかしながら、それは割り込みベースの方法と同じ時間的管理のレベルを提供しないので、例えば、遅延が短いか又は予測可能である場合には適切である。これらの２つの方法は両方共、いろいろな状況の下で有用である。

[038]図４は他の実施形態を例示する。図４に示すように、ハイパーバイザ２０１は、２つのＩＲＱと共に、一般的なドライバ４０１をゲストＯＳ２２０にインストールすることができる。現在実行中のゲストプロセス２６０が高い待ち時間動作を開始するときに、ハイパーバイザ２０１は第１ＩＲＱをゲストに出し、それはドライバ４０１によってインターセプトされる。関連技術の当業者により理解されるように、ゲストのＩＲＱハンドラは割り込み時に現在実行中であったゲストプロセス２６０の文脈において実行する。換言すれば、標準割り込み処理に従って、これらの状況の下で、スケジュールを変更する事象がＩＲＱ送出経路に沿ってはない。関連技術の当業者に知られているように、一般的なドライバ４０１の「上半分」４０３は割り込みされたゲストプロセス２６０の文脈を実行し、実行制御をゲストＯＳ２２０に引き渡す前に、そのプロセス２６０の識別子（ＩＤ）４０５をセーブし、それは、割り込みされたプロセス２６０に制御を戻す前に、（ゲスト）ＯＳ空間のドライバ４０１の「下半分」４０７を実行する。

[039]下半分４０７は、ゲストＯＳ２２０に割り込みされたプロセス２６０にスケジュールを中止させる措置をとる。一実施形態において、下半分４０７は、実行可能であることからセマフォ４０９上で待つことにゲストプロセス２６０の状態を変え、そこにおいてセマフォ４０９はドライバ４０１の広域変数である。別の実施形態では、図２に関連して上述したように、下半分は、ブロッキング動作がプロセス２６０の空間において実行されることによって、ゲストプロセス２６０とドライバ４０１に関連した仮想装置４１１との間の明確な依存関係を確立する。どちらにしても、上半分４０３がプロセスＩＤ４０５を格納していたので、それがその文脈で実行していない場合であっても、下半分４０７はゲストプロセス２６０の一致を知っていることを理解すべきである。セマフォ４０９ベースのシナリオ及びブロッキングシナリオの両方において、ドライバ４０１の下半分４０７の動作によって、ゲストＯＳ２２０は割り込みされたプロセス２６０のスケジュールを中止し、有用な作業をするために他のものをスケジュールする。セマフォ４０９が同期のために使用可能なデータ構造のわずかに１つの実施例であることを理解すべきである。

[040]ハイパーバイザ２０１が後でその動作を完了するときに、それは別のＩＲＱを出し、ＩＲＱハンドラ（又は下半分４０７）は関連したゲストプロセス２６０を再開させるために適切な措置をとる。セマフォ４０９ベースの方法において、セマフォ４０９は効果的に信号を送られ、それは機能を停止したプロセス２６０のスリープを解除する。ブロッキング実施形態において、ブロックされたプロセス２６０と仮想装置４１１との間の明確な依存は終わり、ゲストＯＳ２２０にプロセス２６０のスケジュールを変更させる。

[041]一実施形態において、２つのＩＲＱ方式は、仮想装置４０１の状態レジスタを用いて単一ＩＲＱに最適化される。別の実施形態では、「しばらくスリープ（ｓｌｅｅｐ ｆｏｒ ａ ｗｈｉｌｅ）」セマンティックが、純粋にＩＲＱベースの方法の代わりに使われ、それは所定の短時間の後に機能を停止したプロセス２６０のスリープを解除する。「上半分、下半分」装置アーキテクチャは、リナックス（登録商標）及びウインドウ（商標）のようなオペレーティング・システム特有であると更に理解される。他のオペレーティング・システム・アーキテクチャの下で、類似の技法は、ドライバ４０１から割り込みされたプロセス２６０へ制御を戻す前に、同じブロッキング及び／又はセマフォ４０９ベースの機能を提供するために利用でき、それによりゲストＯＳ２２０は別のプロセス２６０をスケジュールする。

[042]上記の実施形態はかなり一般的であり、いかなる任意のプロセス２６０のゲストＯＳ内での実行をストールするために、ハイパーバイザ２０１により使用可能である。関連技術の当業者により理解されるように、ハイパーバイザ２０１が特定の感知可能な段階でプロセス２６０を止めた場合には、それはゲスト内での実行課題を引き起こす可能性がある。例えば、カーネル・スレッドを中断することは、良くない面倒な問題を引き起こすことがある。一般に、上記の実施形態は、いかなるユーザ・モード・プロセス２６０もストールすることに適している（即ち、ゲストＯＳ２２０は、いかなる点でもユーザ・モード・プロセス２６０を先取りすることができる）。しかしながら、さまざまな実施形態によれば、カーネルがスピンロックを保持しているか、又はある割り込み不可能な危険地域を実行していることがあるので、ハイパーバイザ２０１は通常はアップコールをゲスト・カーネルモード・コードにしない。ハイパーバイザ２０１がアップコールをゲスト・カーネルモード・コードにする場合に、それは、この種の課題を考慮するために、オペレーティング・システム・インターナル及び割り込み処理の分野の当業者に公知の特別な処理技術を使用する。

[043]前記説明が「ハイパーバイザ」２０１という用語を全体を通して使用するが、しかし、上記の如く、用語ハイパーバイザ２０１はＶＭＭのような他の用語によって、いわば取り換えられて使用でき、いずれの種類の仮想化構成要素の使用も本発明の範囲内であることを理解すべきである。更にまた、本発明のさまざまな実施形態は、上の背景セクションで述べたさまざまな仮想化シナリオの下で実施可能である。本発明の実施形態はマルチコア・アーキテクチャのコンテンツに非常に有用でありえて、それによりハイパーバイザ２０１は１つのコアでその長い待ち時間動作を実行することができ、その一方でゲストＯＳ２２０は別のプロセス２６０をスケジュールし、別のコアにおいて並行して実行する点に留意する必要がある。

[044]当業者により理解されるように、本発明はその精神又は基本的な特徴を逸脱しない範囲で他の特定の形で実施可能である。同様に、部分、モジュール、エージェント、管理者、構成要素、機能、手順、動作、層、特徴、属性、技法、及び他の態様についての特定の名前付け及び区分は必須又は重要でなく、本発明を実施する機構又はその特徴は異なる名前、区分、及び／又はフォーマットを有していてもよい。更に、関連技術の当業者にとって明らかであるように、本発明の部分、モジュール、エージェント、管理者、構成要素、機能、手順、動作、層、特徴、属性、技法、及び他の態様は、ソフトウェア、ハードウェア、ファームウェア、又は３つのいかなる組合せとしても実施可能である。もちろん、本発明の構成要素がソフトウェアとして実施される場合はいつでも、構成要素は、スクリプトとして、スタンドアロン・プログラムとして、より大きいプログラムの一部として、複数の個別スクリプト及び／又はプログラムとして、静的又は動的に連係されたライブラリとして、カーネル・ロード可能なモジュールとして、デバイス・ドライバとして、及び／又はコンピュータ・プログラミングの当業者に現在又は将来周知のあらゆるその他の方法で実施可能である。加えて、本発明は、いかなる特定のプログラミング言語の実施にも、或いはいかなる特定のオペレーティング・システム又は環境のためにも決して制限されていない。更にまた、本発明がソフトウェアで全体的に或いは部分的に実施される場合に、そのソフトウェア構成要素がコンピュータ・プログラム製品としてコンピュータ可読の媒体に格納可能なことは、関連技術の当業者にとって容易に明らかである。磁気又は光学記憶媒体のような、コンピュータ可読の媒体のいかなる形も、この文脈で使用可能である。従って、本発明の開示は、以下の特許請求の範囲に記載される本発明の範囲について例証を示すが、制限することを目的としない。

Claims (28)

1. 仮想計算機を支援するための仮想化論理を有するコンピュータにおいて実施される方法であって、
   前記仮想化論理による長い待ち時間のエミュレーション要求をトリガーした命令を現在スケジュールされているゲストプロセスが実行したと前記仮想化論理が識別する段階と、
   前記仮想化論理によって、前記ゲスト・オペレーティング・システムは前記現在スケジュールされているゲストプロセスのスケジュールを一時的に中止して、現在スケジュールが中止されているゲストプロセスと異なる少なくとも１つの別のゲストプロセスをスケジュールする段階と、
   前記仮想化論理は、前記少なくとも１つの別のゲストプロセスの実行と並行して前記長い待ち時間のエミュレーション要求を実行する段階と、
   前記仮想化論理は、前記長い待ち時間のエミュレーション要求の前記実行を完了することに応答して、前記ゲスト・オペレーティング・システムに前記スケジュールを中止されたゲストプロセスのスケジュールを変更させる段階と、
   を含み、前記長い待ち時間のエミュレーション要求は、前記仮想化論理に、遅延を有する仮想化による動作を実行させ、前記動作はゲスト・オペレーティング・システムに可視ではない方法。
2. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる段階が、前記現在スケジュールされているゲストプロセスにコードを加え、前記加えられたコードを実行し、前記ゲスト・オペレーティング・システムが現在スケジュールされているゲストプロセスのスケジュールを中止し、少なくとも１つの別のゲストプロセスをスケジュールさせる段階を含む請求項１に記載の方法。
3. 制御を前記加えられたコードへ転送するために、前記仮想化論理がアップコールを使用する段階を更に含む請求項２に記載の方法。
4. 前記現在スケジュールされているゲストプロセスにコードを加える段階が、前記仮想化論理がアップコールを実行するために使用できるメモリページを登録する段階を更に含む請求項２に記載の方法。
5. 前記ゲスト・オペレーティング・システムに仮想装置のためのデバイス・ドライバをロードさせる段階を更に含む請求項１に記載の方法。
6. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させて、少なくとも１つの別のゲストプロセスをスケジュールさせる段階が、
   前記現在スケジュールされているゲストプロセスにコードを加え、前記加えられたコードを実行し、前記現在スケジュールされているゲストプロセスは前記仮想装置と関連したドライバを呼び出すためにシステムコールを実行する段階と、
   前記ドライバは、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させて、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行する段階と、
   を更に含む請求項５に記載の方法。
7. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる段階が、
   前記仮想化論理が仮想割り込みを前記仮想装置に通知する段階と、
   前記仮想割り込みに応答して、前記仮想装置と関連したドライバが、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させて、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行する段階と、
   を更に含む請求項５に記載の方法。
8. 前記仮想割り込みに応答して、前記ドライバの一部が前記現在スケジュールされているプロセスの文脈において実行し、対応するプロセス識別子を保存する段階と、
   前記ドライバの一部が前記プロセス識別子を使用して、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行する段階と、
   を更に含む請求項７に記載の方法。
9. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる段階が、前記仮想装置と関連したドライバが、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行する段階を更に含む請求項５に記載の方法。
10. 前記ドライバが、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行させる段階が、前記ドライバが、前記現在スケジュールされているゲストプロセスを前記仮想装置上でブロックさせる段階を更に備える請求項９に記載の方法。
11. 前記仮想化論理が仮想割り込みを前記仮想装置に通知する段階と、
    前記仮想割り込みに応答して、前記ドライバが前記現在スケジュールされているゲストプロセスを前記仮想装置上でブロックさせる前記段階を完了し、前記スケジュールを中止したプロセスが前記仮想装置上でもはやブロックしない段階と、
    を更に含む請求項１０に記載の方法。
12. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる段階が、
    前記現在スケジュールされているゲストプロセスにコードを加え、前記加えられたコードを実行し、前記現在スケジュールされているゲストプロセスは指定された期間停止する段階と、
    前記指定された期間の後に、それに応答して前記仮想化論理が前記長い待ち時間のエミュレーション要求を実行する命令を現在スケジュールされているゲストプロセスが実行したと前記仮想化論理に判断させた前記命令を再実行する段階と、
    を更に含む請求項１に記載の方法。
13. 前記命令を再実行した後に、前記仮想化論理が、前記長い待ち時間のエミュレーション要求の実行を完了しなかったと判断する段階と、
    前記判断に応答して、前記仮想化論理は再び、現在スケジュールされているゲストプロセスに指定された期間の間停止させる段階と、
    を更に含む請求項１２に記載の方法。
14. 仮想計算機を支援するための仮想化論理を有するコンピュータにおいて実行可能な命令を備えるコンピュータ・プログラムを含むコンピュータ可読記憶媒体において、
    前記仮想化論理による長い待ち時間のエミュレーション要求をトリガーした命令を現在スケジュールされているゲストプロセスが実行したと識別し、前記長い待ち時間のエミュレーション要求は、前記仮想化論理に、遅延を有する仮想化による動作を実行させ、前記動作はゲスト・オペレーティング・システムに可視でなく、
    前記ゲスト・オペレーティング・システムに現在スケジュールされているゲストプロセスのスケジュールを一時的に中止させ、現在スケジュールが中止されているゲストプロセスと異なる少なくとも１つの別のゲストプロセスをスケジュールさせ、
    前記少なくとも１つの別のゲストプロセスの前記実行と並行して前記長い待ち時間のエミュレーション要求を実行し、
    前記長い待ち時間のエミュレーション要求の前記実行を完了することに応答して、前記ゲスト・オペレーティング・システムに前記スケジュールを中止したゲストプロセスのスケジュールを変更させるようプロセッサに命令するコンピュータ・プログラムを含むコンピュータ可読記憶媒体。
15. 前記ゲスト・オペレーティング・システムに現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせるよう前記プロセッサに命令する命令が、前記現在スケジュールされているゲストプロセスにコードを加えるよう命令することを更に備え、前記加えられたコードを実行し、前記ゲスト・オペレーティング・システムが現在スケジュールされているゲストプロセスのスケジュールを中止する請求項１４に記載のコンピュータ可読記憶媒体。
16. 前記加えられたコードへ制御を転送するために、前記仮想化論理によって、アップコールを使用するよう前記命令が前記プロセッサに命令する請求項１５に記載のコンピュータ可読記憶媒体。
17. 前記ゲスト・オペレーティング・システムに仮想装置のためのデバイス・ドライバをロードさせるための命令を更に備える請求項１４に記載のコンピュータ可読記憶媒体。
18. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせることが、
    前記現在スケジュールされているゲストプロセスにコードを加え、前記加えられたコードを実行し、前記現在スケジュールされているゲストプロセスは前記仮想装置と関連したドライバを呼び出すためにシステムコールを実行し、
    前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行することと、
    を更に備える請求項１７に記載のコンピュータ可読記憶媒体。
19. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせることが、
    仮想割り込みを前記仮想装置に通知することと、
    前記仮想割り込みに応答して、前記仮想装置と関連したドライバが、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行することと、
    を更に備える請求項１７に記載のコンピュータ可読記憶媒体。
20. 前記仮想割り込みに応答して、前記ドライバの一部に前記現在スケジュールされているプロセスの文脈において実行させ、対応するプロセス識別子を保存することと、
    前記ドライバの一部に、前記プロセス識別子を使用して、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行させることと、
    を前記命令が更に前記プロセッサに命令する請求項１９に記載のコンピュータ可読記憶媒体。
21. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせることが、前記仮想装置と関連したドライバに、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行させることを更に備える請求項１７に記載のコンピュータ可読記憶媒体。
22. 前記ドライバが、前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行することが、前記現在スケジュールされているゲストプロセスに前記仮想装置上でブロックさせることを更に備える請求項２１に記載のコンピュータ可読記憶媒体。
23. 仮想割り込みを前記仮想装置に通知することと、
    前記仮想割り込みに応答して、前記現在スケジュールされているゲストプロセスに前記仮想装置上でブロックさせる段階を完了し、前記スケジュールを中止したプロセスが前記仮想装置上でもはやブロックしないことと、
    を更に備える請求項２２に記載のコンピュータ可読記憶媒体。
24. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせることが、
    前記現在スケジュールされているゲストプロセスにコードを加え、前記加えられたコードを実行し、前記現在スケジュールされているゲストプロセスは指定された期間停止し、
    前記指定された期間の後に、前記仮想化論理に現在スケジュールされているゲストプロセスが前記仮想化論理が仮想化により生じた前記動作を実行するために応答する命令を実行したと判断させた前記命令を再実行することと、
    を更に備える請求項１４に記載のコンピュータ可読記憶媒体。
25. 前記命令が、
    仮想化により生じた前記動作が完了しなかったと判断することと、
    前記判断に応答して、再び現在スケジュールされているゲストプロセスを前記指定された期間停止させることと、
    を前記プロセッサに更に命令する請求項２４に記載のコンピュータ可読記憶媒体。
26. 仮想計算機を支援するための仮想化論理を有するコンピュータシステムであって、
    前記仮想化論理による長い待ち時間のエミュレーション要求をトリガーした命令を現在スケジュールされているゲストプロセスが実行したと識別するための手段と、
    前記ゲスト・オペレーティング・システムに現在スケジュールされているゲストプロセスのスケジュールを一時的に中止させ、現在スケジュールが中止されているゲストプロセスと異なる少なくとも１つの別のゲストプロセスをスケジュールさせるための手段と、
    前記少なくとも１つの別のゲストプロセスの前記実行と並行して前記長い待ち時間のエミュレーション要求を実行するための手段と、
    前記長い待ち時間のエミュレーション要求の前記実行を完了することに応答して、前記ゲスト・オペレーティング・システムに前記スケジュールを中止したゲストプロセスのスケジュールを変更させるための手段と、
    を備え、前記長い待ち時間のエミュレーション要求は、前記仮想化論理に、遅延を有する仮想化による動作を実行させ、前記動作はゲスト・オペレーティング・システムに可視ではない、コンピュータシステム。
27. 前記ゲスト・オペレーティング・システムに前記現在スケジュールされているゲストプロセスのスケジュールを中止させ、少なくとも１つの別のゲストプロセスをスケジュールさせる動作を実行する前記仮想装置と関連した前記ドライバが、スケジュールを中止するために前記ゲストプロセスのスケジューリング優先順位を下げる段階を更に含む請求項９に記載の方法。
28. スケジュールを変更するために前記ドライバが前記ゲストプロセスのスケジューリング優先順位を上げる段階を更に含む請求項２７に記載の方法。
    

Images