JP6383518B2 - 仮想マシンモニター及び仮想マシンモニターのスケジューリング方法 - Google Patents

Description

本発明は、多数の運用体制を同時に駆動するための仮想化技術及びリアルタイム保証のためのスケジューリング技術に関する。

仮想化（ｖｉｒｔｕａｌｉｚａｔｉｏｎ）とは、自体の運用体制を有している多数の仮想マシン（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）が一つのホストコンピュータ上で動作できるようにする技術を言う。

このような仮想化によってホストコンピュータは、仮想マシンモニター（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｍｏｎｉｔｏｒ）を実行し、該実行された仮想マシンモニターは、複数個の仮想マシンを生成する。該生成された仮想マシンは、同時に実行されることが可能であり、それぞれの仮想マシンは、仮想化されたハードウェア資源を有する。例えば、それぞれの仮想マシンは、物理ＣＰＵを仮想化した１つ以上のｖｉｒｔｕａｌ ＣＰＵ（ＶＣＰＵ）を有し、メモリ領域の一部を占有することができる。

仮想化環境でスケジューリングは、ＶＣＰＵ単位からなるためにスケジューリング時にただＶＣＰＵに割り当てられたＴｉｍｅ Ｑｕａｎｔｕｍのみを考慮してスケジューリングをする。したがって、リアルタイム応用を支援するのに適しない。

本発明は、仮想マシンモニター及び仮想マシンモニターのスケジューリング方法を提供することを目的とする。

本発明の一態様による仮想マシンモニターは、少なくとも二つのドメインを駆動する仮想マシンモニターにおいて、少なくとも一つの実行キューと、相異なるスケジュールの特性を有する多数のスケジューラと、ドメインから受信されたタスクを実行キューに挿入し、イベントの類型によって実行キューに挿入されたタスクをスケジューリングするスケジューラを多数のスケジューラのうちから選択する制御部と、を含む。

また、仮想マシンモニターは、イベントの類型によるタスクの優先順位の加重値が記録された加重値テーブルと、タスクの実行制限時間が記録されたタイムテーブルと、イベント類型によって選択されるスケジューラが記録されたスケジューラリストのうち少なくとも一つ以上を保存するテーブル保存部と、をさらに含みうる。

また、制御部は、受信されたタスクを実行キューに挿入し、タスクの属性及び加重値テーブルを用いてタスクの優先順位を決定することが可能である。

また、制御部は、受信されたタスクを前記実行キューに挿入し、タイムテーブルを生成または更新することが可能である。

また、制御部は、選択されたスケジューラを呼び出し、実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされうる。

一方、本発明の一態様による仮想マシンモニターのスケジューリング方法は、少なくとも二つのドメインを駆動する仮想マシンモニターのスケジューリング方法において、ドメインから受信されたタスクを少なくとも一つの実行キューに挿入する段階と、イベントの類型によって実行キューに挿入されたタスクをスケジューリングするスケジューラを多数のスケジューラのうちから選択する段階と、を含む。

本発明の一実施形態による仮想マシンモニターを示す図である。 本発明の一実施形態によるスケジューラリストを示す図である。 本発明の一実施形態による加重値テーブルを示す図である。 本発明の一実施形態によるタイムテーブルを示す図である。 本発明の一実施形態による仮想マシンモニターの動作を示す図である。 本発明の他の実施形態による仮想マシンモニターの動作を示す図である。 本発明の他の実施形態による仮想マシンモニターを示す図である。 本発明のまた他の実施形態による仮想マシンモニターを示す図である。 本発明の一実施形態による仮想マシンモニターのスケジューリング方法を示す図である。 本発明の一実施形態による実行キューを示す図である。 本発明の他の実施形態による仮想マシンモニターを示す図である。 本発明の一実施形態による仮想マシンモニトウル制御するためのフローチャートを示す図である。

以下、添付した図面を参照して、本発明の実施のための具体的な例を詳しく説明する。

図１は、本発明の一実施形態による仮想マシンモニター（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｍｏｎｉｔｏｒ、ＶＭＭ）を示す図である。図１を参照すると、仮想マシンモニター１００は、多数のドメイン１０１、１０２とハードウェアプラットホーム１０３との間に存在する。それぞれのドメイン１０１、１０２は、運用体制（ｏｐｅｒａｔｉｏｎ ｓｙｓｔｅｍ）または応用プログラム（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ）になりうる。ハードウェアプラットホーム１０３は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、メモリ（ｍｅｍｏｒｙ）、入出力ポート（Ｉ／Ｏ ｐｏｒｔ）のような物理的装置になりうる。

仮想マシンモニター１００は、ハードウェアプラットホーム１０３を仮想化（ｖｉｒｔｕａｌｉｚａｔｉｏｎ）させて多数のドメイン１０１、１０２を同時に動作可能にする。すなわち、それぞれのドメイン１０１、１０２は、仮想マシンモニター１００の仮想化を通じて一つの物理的システムリソースを複数個の仮想化システムリソースとして使用しうる。

ドメイン１０１、１０２は、ハードウェアプラットホーム１０３に直接アクセスすることができるホストドメイン１０１とホストドメイン１０１の助けを受けて間接的にハードウェアプラットホーム１０３を用いるゲストドメイン１０２とに区分することができる。それぞれのドメイン１０１、１０２は、多種のタスク１０４、１０５を含みうる。

仮想マシンモニター１００は、少なくとも一つの実行キュー１１０、多数のスケジューラ１２１、１２２、１２３、制御部１３０、及びテーブル保存部１４０を含む。

実行キュー１１０は、ドメイン１０１、１０２から受信されたタスク１０４、１０５またはタスク１０４、１０５についての情報を保存する。本発明の一実施形態によって、タスク１０４、１０５は、スケジュール対象となる単位であるスケジュールエンティティ形態で実行キュー１１０に保存することができる。実行キュー１１０に保存されたタスクＴ１〜Ｔ３は、スケジューラ１２１、１２２、１２３のスケジュール対象となる。

本発明の一実施形態によって、実行キュー１１０は、一つのみ形成されることもでき、複数個が形成されうる。複数個の実行キュー１１０が形成される場合、それぞれの実行キュー１１０は、図６Ａまたは図６Ｂのようにハードウェアプラットホームの各ＣＰＵコアまたは各スケジューラ１２１、１２２、１２３とバインディング（ｂｉｎｄｉｎｇ）されうる。また、それぞれの実行キュー１１０は、図８のように、２次元マトリックス形態でも管理されうる。

図８は、本発明の一実施形態による実行キューを示す図である。図８を参照すると、本実施形態による実行キュー８００は、２次元マトリックス形態を有しうる。２次元マトリックス形態で管理される実行キュー８００の場合、マトリックスの行または列の別に相異なる属性を有するタスクを保存することが可能である。例えば、属性Ａを有するタスク１（Ｔ１）及びタスク２（Ｔ２）は、第１列８０１に保存され、属性Ｂを有するタスク３（Ｔ３）ないしタスク５（Ｔ５）は、第２列８０２に保存することができる。

本実施形態によって属性とは、タスクをトリガー（ｔｒｉｇｇｅｒ）するための条件を意味する。例えば、タスク１（Ｔ１）及びタスク２（Ｔ２）は、或るイベントによってトリガーされるタスクになり、タスク３（Ｔ３）ないしタスク５（Ｔ５）は、或るインタラプトによってトリガーされるタスクになりうる。このようなタスクの属性には、イベント、デッドライン、及び／またはインタラプトなどがあり得る。

再び図１で、スケジューラ１２１、１２２、１２３は、実行キュー１１０にあるタスクＴ１〜Ｔ３の実行順序を決定する。スケジューラ１２１、１２２、１２３は、相異なるスケジュールの特性を有する。例えば、第１スケジューラ１２１は、デッドラインファーストスケジューラ（ｄｅａｄｌｉｎｅ ｆｉｒｓｔ ｓｃｈｅｄｕｌｅｒ）であり、第２スケジューラ１２２は、ラウンドロビンスケジューラ（ｒｏｕｎｄ−ｒｏｂｉｎ ｓｃｈｅｄｕｌｅｒ）であり、第３スケジューラ１２３は、イベントファーストスケジューラ（ｅｖｅｎｔ ｆｉｒｓｔ ｓｃｈｅｄｕｌｅｒ）になりうる。しかし、スケジューラの種類が、これに限定されるものではない。

実行キュー１１０にあるタスクＴ１〜Ｔ３は、任意の時点に多数のスケジューラ１２１、１２２、１２３のうちからリアルタイムの特性を達成するのに最も適したスケジューラ（例えば、１２１）によってスケジューリングされうる。

制御部１３０は、それぞれのドメイン１０１、１０２からタスク１０４、１０５を受信し、該受信されたタスクを実行キュー１１０に挿入する。本発明の一実施形態によって、タスク１０４、１０５は、スケジュール対象となる単位であるスケジュールエンティティ形態で実行キュー１１０に挿入されうる。

制御部１３０は、タスク１０４、１０５を実行キュー１１０に挿入する時、タスクの属性別に区別されるように実行キュー１１０に挿入することができる。例えば、図８のように、実行キュー１１０を配列（ｍａｔｒｉｘ）形態で管理しながら特定の行または列によって、それぞれの属性別にタスク１０４、１０５を挿入することができる。ここで、タスクの属性は、タスクをトリガーするための条件を言うことで、電話の送／受信のようなイベントソース（ｅｖｅｎｔ ｓｏｕｒｃｅ）、デッドライン及び／またはインタラプトなどを含みうるということは前述した通りである。このようなタスク属性に関する情報は、ドメイン１０１、１０２に対応する運用体制（ＯＳ）を通じて収集されうる。

また制御部１３０は、タスク１０４、１０５を実行キュー１１０に挿入する時、タスクの優先順位によって実行キュー１１０を調整することができる。この際、タスク属性がイベントである場合には、加重値テーブル１４１に基づいて優先順位を決定することができる。またタスク属性がイベントである場合には、加重値テーブル１４１によらずに、そのタスクの緊急処理の必要性またはリアルタイム処理の必要性によって優先順位を決定することもできる。緊急処理の必要性またはリアルタイム処理の必要性は、タスクのデッドラインに基づいて判断されうる。

一例として、制御部１３０は、運用体制から収集された情報に基づいて、或るタスクが或るイベント類型によってトリガーされるか否かを把握することが可能であるが、加重値テーブル１４１には、このようなイベント類型による優先順位の加重値がスケジューラ１２１、１２２、１２３別に保存されている。例えば、タスク１（Ｔ１）及びタスク２（Ｔ２）いずれもタスク属性がイベントであるが、タスク１（Ｔ１）は、イベント類型Ａによってトリガーされ、タスク２（Ｔ２）は、イベント類型Ｂによってトリガーされる場合、制御部１３０は、加重値テーブル１４１のトリガー条件と関連したタスク属性を参照して、タスク１（Ｔ１）とタスク２（Ｔ２）との優先順位を決定することができる。

また、他の例として、タスク１（Ｔ１）及びタスク２（Ｔ２）いずれもタスク属性がイベントであり、タスク１（Ｔ１）及びタスク２（Ｔ２）いずれもイベント類型Ａによってトリガーされる場合、制御部１３０は、タスクの緊急またはリアルタイム処理の必要性に基づいて、タスク１（Ｔ１）とタスク２（Ｔ２）との優先順位を決定することができる。例えば、タスク１（Ｔ１）が５秒のデッドラインを有し、タスク２（Ｔ２）が１０秒のデッドラインを有する場合、タスク１（Ｔ１）がタスク２（Ｔ２）より緊急な処理が必要であるので、タスク１がさらに高い優先順位を有するようになる。

また制御部１３０は、タスク１０４、１０５を実行キュー１１０に挿入し、テーブル保存部１４０のタイムテーブル１４２を生成または更新することができる。タイムテーブル１４２には、時間と関連したタスクの制約事項、例えば、実行制限時間がタスク別に保存することができる。例えば、制御部１３０が、時間制約をタスクの属性として有するタスク３（Ｔ３）を受信した場合、制御部１３０は、タスク３（Ｔ３）を実行キュー１１０に入れてタイムテーブル１４２にタスク３（Ｔ３）の実行制限時間を記録することが可能である。

また制御部１３０は、発生したイベント情報に基づいて実行キュー１１０に挿入されたタスクＴ１〜Ｔ３をスケジューリングするスケジューラを多数のスケジューラ１２１、１２２、１２３のうちから選択する。本実施形態によって、イベントとは、仮想マシンモニターが搭載された機器の動作によって発生する各種のシステム関連のイベントになりうる。例えば、仮想マシンモニター１００基盤のデータ処理装置が携帯電話に搭載された場合、イベントの類型は、携帯電話の電話送信、電話受信、カメラＯＮ／ＯＦＦ、設定されたタイマー動作、設定された時間の到来などになりうる。イベント類型によって選択されるスケジューラは、テーブル保存部１４０のスケジューラリスト１４３に基づいて選択されうる。例えば、定められたデッドライン前まで実行されてリアルタイム性が保証されて初めて有意なイベントが発生する場合、制御部１３０は、多数のスケジューラ１２１、１２２、１２３のうちからデッドラインファーストスケジューラ（例えば、１２１）を選択することが可能である。

また制御部１３０は、選択されたスケジューラ１２１を呼び出す。該呼び出されたスケジューラ１２１は、自身のスケジュールの政策によって実行キュー１１０にあるタスクＴ１〜Ｔ３をスケジューリングする。

このように、仮想マシンモニター１００は、スケジュールの特性が異なる多数のスケジューラ１２１、１２２、１２３を用いて特定の状況またはタスク属性に適したスケジューラによって実行キュー１１０のタスクＴ１〜Ｔ３をスケジューリングさせうる。

図２は、本発明の一実施形態によるスケジューラリスト１４３を示す図である。

図１及び図２を参照すると、スケジューラリスト１４３は、イベント２０１及び各イベント２０１によって呼び出されるスケジューラ２０２を含む。制御部１３０は、スケジューラリスト１４３を参照して、発生したイベントに適したスケジューラを呼び出させうる。例えば、イベントＥ１とイベントＥ２とが発生した場合、スケジューラＳ１が呼び出され、イベントＥ３が発生した場合、スケジューラＳ２が呼び出されうる。ここで、それぞれのイベント２０１は、仮想マシンモニター１００基盤システムの各種のシステムイベントになりうる。また、スケジューラＳ１とスケジューラＳ２は、相異なるスケジュールの特性または相異なるスケジュールの政策を有するスケジューラを表わす。

図３は、本発明の一実施形態による加重値テーブル１４１を示す図である。

図１及び図３を参照すると、加重値テーブル１４１は、それぞれのタスク属性３０１による加重値３０２をスケジューラＳ１、Ｓ２別に有しうる。タスクの属性は、タスクをトリガーするための条件として電話の送／受信のようなイベントソース、デッドライン及び／またはインタラプトなどを含み、このようなタスク属性に関する情報は、制御部１３０がドメイン１０１、１０２に対応する運用体制（ＯＳ）を通じて収集することが可能である。

タスク属性がイベントであるタスクＴ１〜Ｔ３が実行キュー１１０に挿入される時、制御部１３０は、加重値テーブル１４１を参照して、実行キュー１１０に挿入されるタスクＴ１〜Ｔ３の優先順位を決定することができる。例えば、イベントＥ１Ｅ１によってトリガーされるタスク１とイベントＥ２Ｅ２によってトリガーされるタスク２とが受信された場合、制御部１３０は、加重値テーブル１４１を参照して、タスク１の優先順位をタスク２より高く設定することが可能である。この際、それぞれの加重値は、スケジューラＳ１、Ｓ２別に異ならせて与えられうる。例えば、イベントＥ１Ｅ１及びイベントＥ２Ｅ２が、スケジューラＳ２のスケジュールの特性に何らの影響を及ぼさない場合、スケジューラＳ２では、加重値が同様に与えられうる。

一方、例えば、タスク１及びタスク２いずれもタスク属性がイベントであり、またいずれもイベント類型Ｅ１によってトリガーされる場合、加重値テーブル１４１を参照すれば、タスク１とタスク２との優先順位が同じくなることもできるが、このような場合、制御部１３０は、タスクの緊急処理の必要性またはリアルタイム処理の必要性に基づいて、タスク１（Ｔ１）とタスク２（Ｔ２）との優先順位を決定することも可能である。

図４は、本発明の一実施形態によるタイムテーブル１４２を示す図である。

図１及び図４を参照すると、タイムテーブル１４２は、タスク別に時間制約事項、例えば、実行制限時間が保存することができる。例えば、制御部１３０は、タスクを実行キュー１１０に挿入し、タイムテーブル１４２を周期的に更新することが可能である。

図５Ａ及び図５Ｂは、本発明の一実施形態による仮想マシンモニターの選択的スケジューリング動作を示す図である。

図１、図５Ａ及び図５Ｂで、３つのタスクＴ１、Ｔ２、Ｔ３が受信され、タスクＴ１は、イベントＥ１によってトリガーされ、タスクＴ２は、イベントＥ２によってトリガーされ、タスクＴ３は、イベントＥ３によってトリガーされると仮定する。そして、イベントＥ３は、タイムインタラプトであり、スケジューラは、スケジューラＳ１とスケジューラＳ２の二つが存在すると仮定する。

まず制御部１３０は、タスク属性を考慮してタスクＴ１、Ｔ２、Ｔ３の優先順位を決定して実行キュー１１０に挿入する。例えば、制御部１３０は、‘イベント’というタスクの属性を考慮した加重値テーブル１４１を用いてタスクＴ１〜Ｔ３の優先順位を調節し、既存に挿入されていたタスクの順序も再配置されうる。

本実施形態において、加重値テーブル１４１は、各スケジューラによって異ならせて指定されているので、制御部１３０がタスクの優先順位を決定する時、或るスケジューラを基準にするのかによって実行キュー１１０に挿入されるタスクの優先順位が調節される。例えば、スケジューラＳ１を基準に優先順位を決定すれば、イベントＥ１によってトリガーされるタスクＴ１の優先順位が最も高く決定されうる。このような場合、図５Ａに示されたように、実行キュー１１０には、Ｔ１、Ｔ２、Ｔ３の順にタスクが挿入されうる。またスケジューラＳ２を基準に優先順位を決定すれば、イベントＥ３によってトリガーされるタスクＴ３の優先順位が最も高く決定されうる。このような場合、図５Ｂに示されたように、実行キュー１１０には、Ｔ３、Ｔ１、Ｔ２の順にタスクが挿入されうる。

一旦、タスクＴ１、Ｔ２、Ｔ３が実行キュー１１０に挿入されてから特定イベントが発生すれば、制御部１３０は、発生したイベント類型によって適切なスケジューラＳ１、Ｓ２を選択する。

例えば、図２及び図５Ａで、イベントＥ１が発生した場合、制御部１３０は、スケジューラリスト１４３を参照して、スケジューラＳ１を呼び出すことができる。また、図２及び図５Ｂで、イベントＥ３が発生した場合、制御部１３０は、スケジューラリスト１４３を参照して、スケジューラＳ２を呼び出すことができる。

イベントＥ３がタイムインタラプトであり、スケジューラＳ２がデッドラインスケジューラである場合を説明すれば、制御部１３０は、時間制約を有するタスクを実行キュー１１０に挿入しながら、タイムテーブル１４２を更新し、タイムインタラプトが発生すれば、デッドラインスケジューラを活性化させて時間制約を有するタスクを先にスケジューリングさせうる。また、タイムインタラプトのない間には、他の適切なスケジューラを活性化させてタスクをその優先順位によってスケジューリングすることができる。

図６Ａは、本発明の他の実施形態による仮想マシンモニターを示す図である。図６Ａを参照すると、仮想マシンモニター１００は、ハードウェアプラットホームの各ＣＰＵコアに対応して多数の実行キュー１１０−１、１１０−２、１１０−３を含む。図６Ａで、それぞれの実行キュー１１０−１、１１０−２、１１０−３は、ハードウェアプラットホーム１０３の３つのＣＰＵコア（ＣＰＵ＃０〜ＣＰＵ＃２）にそれぞれマッピングされうる。制御部１３０は、タスク１０４、１０５が受信されれば、運用体制から伝達されたタスク属性を用いて受信されたタスク１０４、１０５が挿入されるに適した実行キューを決定することが可能である。

図６Ｂは、本発明のまた他の実施形態による仮想マシンモニターを示す図である。図６Ｂを参照すると、仮想マシンモニター１００は、それぞれのタスク属性に対応して多数の実行キュー１１０−１、１１０−２、１１０−３を含む。図６Ｂで、それぞれのタスク属性に対応する最適の実行キュー１１０−１、１１０−２、１１０−３は、それぞれのスケジューラ１２１、１２２、１２３にマッピングされうる。制御部１３０は、タスク１０４、１０５が受信されれば、運用体制から伝達されたタスク属性を用いて受信されたタスク１０４、１０５が挿入されるに適した実行キューを決定することが可能である。

図７は、本発明の一実施形態による仮想マシンモニターのスケジューリング方法を示す図である。これは、図１で示されたシステムに適用可能である。

図１及び図７を参照すると、仮想マシンモニター１００は、ドメイン１０１、１０２から受信されたタスクを少なくとも一つの実行キュー１１０に挿入する（７０１）。本実施形態で、受信されたタスクは、加重値テーブル１４１またはタスクの緊急処理の必要性に基づいて判断された優先順位によって実行キュー１１０に挿入されうる。また、タスクが実行キュー１１０に挿入されながらタスクの実行制限時間が記録されたタイムテーブル１４２が生成または更新されうる。

そして、仮想マシンモニター１００は、イベントの類型によって実行キュー１１０に挿入されたタスクＴ１〜Ｔ３をスケジューリング、すなわち、ハードウェアプラットホームで実行される順序を決定するスケジューラを多数のスケジューラ１２１、１２２、１２３のうちから選択する（７０２）。例えば、制御部１３０が、テーブル保存部１４０に保存されたスケジューラリスト１４３を参照して、現在状況またはタスク属性に最も適したスケジューラを選択することが可能である。

そして、仮想マシンモニター１００は、選択されたスケジューラを呼び出す（７０３）。例えば、制御部１３０が選択されたスケジューラを呼び出し、該呼び出されたスケジューラによって実行キュー１１０にあるタスクＴ１〜Ｔ３が呼び出されたスケジューラのスケジュールの特性またはスケジュールの政策によってスケジューリングさせることが可能である。

また、本発明の一実施形態によって、実行キュー１１０が複数個形成される場合、仮想マシンモニター１００は、運用体制から伝達されたタスクの属性を用いてタスク属性に合う実行キューを選択し、該選択された実行キューにタスクを挿入することも可能である。

図９は、仮想マシンモニター（ＶＭＭ）の他の例を示す図である。

リアルタイムドメイン（ＲＴ−ＤＯＭＡＩＮ）のタスク創造、例えば、承認制御（ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ）、タスク特性によるグルーピング、及びスケジューラ間の関係が提供されうる。これにより、多数のリアルタイムドメインが仮想マシンモニター（ＶＭＭ）で実行される時、各リアルタイムドメインのタスク及びリアルタイムドメインのタスクに対してリアルタイムの特性が保証されうる。

本実施形態は、ＶＭＭで多数の仮想マシン（ＲＴ＿ＤＯＭＡＩＮ）が実行される時、タスクに関してリアルタイムの特性を提供することを含む。例えば、本実施形態は、ＶＭＭのスケジューリング単位でリアルタイムドメインのリアルタイムタスクを管理すること、多数のリアルタイムドメインのタスクの優先順位を管理すること、スケジュールエンティティをグルーピングすること、及びスケジューリングすること、などを含みうる。

ＲＴ−ＤＯＭＡＩＮのタスクが生成されれば、タスクは、ＶＭＭのスケジュールフレームワーク／承認制御部（Ｓｃｈｅｄｕｌｅ Ｆｒａｍｅｗｏｒｋ／Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ ｕｎｉｔ）を通じてＶＭＭのスケジュールエンティティに縛られ、図１の実行キュー１１０または図９のマルチレベル実行キューに挿入されうる。タスクが生成されれば、ＲＴ−ＤＯＭＡＩＮのリアルタイム運用体制（ＲＴＯＳ）は、デッドライン、周期、イベントソースなどのような情報をＶＭＭによって提供されるインターフェースを通じて承認制御部（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ ｕｎｉｔ）に伝達する。ＶＭＭの承認制御部は、このような情報に基づいてリアルタイムタスクをＶＭＭのスケジュールエンティティに結合させてスケジュールエンティティを実行キューに挿入することができる。

スケジュールエンティティの特性を考慮すれば、承認制御部は、多数の実行キューを維持し、スケジュールエンティティが挿入される時、対象実行キュー（ｔａｒｇｅｔ ｒｕｎ ｑｕｅｕｅ）を決定することができる。実行キューは、タスクのデッドラインが高く評価される実行キュー及びタスクの相互作用（ｉｎｔｅｒａｃｔｉｖｉｔｙ）が高く評価される実行キューを含みうる。

スケジュールエンティティが実行キューに挿入されれば、承認制御部は、ＲＴＯＳから伝達されたタスクの属性に基づいてスケジュールエンティティの優先順位を調節することができる。例えば、イベントソースによってトリガーされるタスクに対して、スケジュールエンティティの優先順位が、図１の加重値テーブル１４１のようなイベント加重値テーブルの優先順位に対する調節値によって調整されうる。また他の例として、時間に対する制限を有しているタスクに対して、タイムチャートが承認制御部に維持されることもある。その結果、時間に対する制限を有しているタスクは、与えられた時間制限内で実行を再開することができる。

イベント加重値テーブルは、システムから提供されるそれぞれの物理的イベントソースまたは論理的ソースに割り当てされる優先順位を有するテーブルになりうる。イベント加重値テーブルは、静的に提供され、システム実行によって動的にも更新されうる。タイムチャート、例えば、図１のタイムテーブル１４２は、生成されたスケジュールエンティティのタイムスロット（ｓｌｏｔ）を維持するために提供されうる。

実行キューに挿入されたスケジュールエンティティは、所定時間に最も適切なスケジューラを通じてスケジュールされうる。例えば、タイマーインタラプトが発生する度に、またはタイマーの設定が必要な度に、ＶＭＭはタイムチャートを更新し、時間制約を有するリアルタイムタスクをスケジュールするためにデッドラインスケジューラを実行することができる。またタイマーインタラプトが発生するものの以外に他の類型のイベントが発生する場合、ＶＭＭは、そのイベントに適切なスケジューラを通じてスケジュールエンティティをスケジュールすることができる。例えば、一般的な目的のドメイン（Ｇｅｎｅｒａｌ−ｐｕｒｐｏｓｅ ｄｏｍａｉｎ、ＧＰ−ＤＯＭＡＩＮ）は、リアルタイムドメインより低い優先順位を有しうる。

図１０は、仮想マシンモニターの制御ロジックのための方法を示す図である。段階１０１０で、タスクを処理するための要請が受信される。段階１０２０で、受信されたタスクの種類が決定される。もし、周期的なタスク（ｐｅｒｉｏｄｉｃ ｔａｓｋ）、例えば、任意の時間に実行されるタスクが受信された場合、段階１０３０で、空き時間スロットが利用可能か否か判断する。もし、空き時間スロットが存在すれば、段階１０５０で、空き時間スロットが得られる。段階１０５５で、周期的なタイマーがセッティングされうる。タスクは、段階１０６０で処理のために承認されうる。もし、空き時間スロットが段階１０３０で存在しない場合、タスクは、段階１０７０で拒絶されうる。

もし、段階１０２０で、デッドラインタスク、すなわち、実行完了についての時間またはデッドラインが設定されているタスクが受信された場合、段階１０４０で、空き時間スロットが利用可能か否か判断する。もし、空き時間スロットが存在すれば、空き時間スロットが段階１０９０で得られる。段階１０９５で、スナップショットタイマーがセッティングされうる。もし、空き時間スロットが段階１０４０で存在しない場合、段階１０８０で受信されたタスクがタスクと関連したデッドラインに相応する時間スロットに既存在するタスクより優先順位が高いか否かが判断される。もし、そうでなければ、タスクは、段階１０７０で拒絶されうる。もし、受信されたタスクが高い優先順位を有する場合、所望の時間スロットが段階１０８５で分割されうる。そして、段階１０９５でスナップショットタイマーがセッティングされうる。タスクは、段階１０６０で実行のために承認されうる。

開示された実施形態は、仮想環境でリアルタイムの特性を提供することができるシステム及び方法を含みうる。

スケジューラの種類及び個数は、多様に適用可能である。ＶＭＭは、論理構成になることもできる。或るスケジューラは、他のスケジューラによって活性化されることもできる。例えば、インタラプト基盤のスケジューラと関連した特定キューのタスク実行が完了されれば、ＶＭＭは、キューを元々インタラプト基盤のスケジューラに戻すか、または他のスケジューラのキューで持続させることができる。また多数の実行時間キューが存在することもできる。タスクまたはイベントの緊急性（ｕｒｇｅｎｃｙ）は、キューのタスク順序を変化させることができる。

特定のスケジューラは、イベントがスケジューラの変化をトリガーしない場合、他のスケジューラの実行時間キュー（ｒｕｎ ｔｉｍｅ ｑｕｅｕｅ）を実行することができる。特定のスケジューラは、自身のキューの一部を処理し、他のスケジューラのキューに移動することもできる。例えば、デッドラインスケジューラ、例えば、スケジューラ１２１は、緊急処理するタスクのない場合、他のスケジューラのためのキューを処理することもできる。

前述したように、仮想マシンモニター１００は、スケジュールの特性が他の多数のスケジューラ１２１、１２２、１２３を運用しながらイベント状況に合うまたはタスク属性に合うスケジューラでタスクをスケジューリングすることが分かる。したがって、リアルタイムタスクのようにユーザ要求に敏感に反応するタスクを適切にスケジューリングすることが可能である。

一方、本発明の実施形態は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取れるデータが保存されるあらゆる種類の記録装置を含む。

コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ保存装置などがあり、また、キャリアウェーブ（例えば、インターネットを通じる伝送）の形態で具現するものを含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散されて、分散方式でコンピュータで読み取り可能なコードとして保存されて実行可能である。そして、本発明を具現するための機能的な（ｆｕｎｃｔｉｏｎａｌ）プログラム、コード及びコードセグメントは、本発明が属する技術分野のプログラマーによって容易に推論されうる。

以上、本発明の実施のための具体的な例を説明した。前述した実施形態は、本発明を例示的に説明するためのものであって、これによって本発明の権利範囲が特定の実施形態に限定されるものではない。

本発明は、多数の運用体制を同時に駆動するための仮想化技術及びリアルタイム保証のためのスケジューリング技術分野に適用されうる。

１００ 仮想マシンモニター
１０１ ホストドメイン
１０２ ゲストドメイン
１０３ ハードウェアプラットホーム
１０４、１０５ タスク
１１０、１１０−１、１１０−２、１１０−３、８００ 実行キー
１２１、１２２、１２３ 第１〜第３スケジューラ
１３０ 制御部
１４０ テーブル保存部
１４１ 加重値テーブル
１４２ タイムテーブル
１４３ スケジューラリスト
２０１ イベント
２０２ スケジューラ
３０１ タスク属性
３０２ 加重値

Claims (17)

1. リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムであって，
   前記仮想マシンモニターは，
   実行キューと、
   前記ハードウェア上のタスクの実行順を決定するように構成された、相異なるスケジュールの特性を有する複数のスケジューラと、
   スケジューラリストと加重値テーブルとタイムテーブルとを格納するテーブル格納部と、
   制御部と、
   を含み、
   前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
   前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
   前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
   前記制御部は，プロセッサを含み、
   前記リアルタイムドメインから受信されたタスクを前記実行キューに挿入し、
   前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
   前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
   前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
   前記複数のタスクは、その決定された実行順に基づいて実行されるためにスケジューリングされる、
   ことを特徴とするシステム。
2. 前記タスクの属性は、
   前記タスクをトリガー（ｔｒｉｇｇｅｒ）するためのイベントソースを含むことを特徴とする請求項１に記載のシステム。
3. 前記優先度の順位の加重値は、
   前記スケジューラの種類別に独立した値を有することを特徴とする請求項１に記載のシステム。
4. 前記制御部は、
   受信されたタスクの緊急処理の必要性またはリアルタイム処理の必要性によって、前記タスクの優先度の順位を決定することを特徴とする請求項１に記載のシステム。
5. 前記制御部は、
   前記タイムテーブルを生成または更新することを特徴とする請求項１に記載のシステム。
6. 前記制御部は、選択されたスケジューラを呼び出し、
   前記実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされることを特徴とする請求項１に記載のシステム。
7. 前記実行キューは、
   多数個が形成されることを特徴とする請求項１に記載のシステム。
8. それぞれの実行キューは、
   前記仮想マシンモニターによって管理される多数の物理資源にそれぞれマッピングされることを特徴とする請求項７に記載のシステム。
9. それぞれの実行キューは、
   前記多数のスケジューラにそれぞれマッピングされることを特徴とする請求項８に記載のシステム。
10. 前記制御部は、
    前記受信されたタスクの属性によって、前記タスクが挿入される実行キューを決定することを特徴とする請求項７に記載のシステム。
11. 前記実行キューは、行と列とを有するマトリックス形態を有し、
    前記制御部は、前記受信されたタスクの属性によって、前記タスクが挿入される実行キューの行または列を決定することを特徴とする請求項１に記載のシステム。
12. 前記スケジューラは、デッドラインスケジューラを含み、
    前記制御部は、前記イベントの類型でタイムインタラプトが発生した場合、前記デッドラインスケジューラを呼び出すことを特徴とする請求項１に記載のシステム。
13. リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムにおける、前記仮想マシンモニターのスケジューリング方法であって、
    相異なるスケジュールの特性を有する複数のスケジューラを前記ハードウェア上のタスクの実行順を決定するように構成する段階と、
    スケジューラリストと加重値テーブルとタイムテーブルとを格納する段階と、を含み、
    前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
    前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
    前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
    さらに、
    前記リアルタイムドメインから受信されたタスクを実行キューに挿入し、
    前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
    前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
    前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
    前記複数のタスクを、その決定された実行順に基づいて実行するようにスケジューリングする、
    段階を含む、
    ことを特徴とするスケジューリング方法。
14. 前記タスクを挿入する段階は、
    前記タスクの実行制限時間が記録されたタイムテーブルを生成または更新する過程を含むことを特徴とする請求項１３に記載のスケジューリング方法。
15. 前記タスクを挿入する段階は、
    前記受信されたタスクの属性によって、前記タスクが挿入される実行キューを決定する過程を含むことを特徴とする請求項１３に記載のスケジューリング方法。
16. 前記選択されたスケジューラを呼び出す段階をさらに含み、
    前記実行キューに挿入されたタスクは、呼び出されたスケジューラのスケジュールの特性によってスケジューリングされることを特徴とする請求項１３に記載のスケジューリング方法。
17. リアルタイムタスクのためのリアルタイムドメインおよび一般目的のタスクのための一般ドメインを含む複数のドメインのためのハードウェアを仮想化する、仮想マシンモニターを含むシステムにおける、前記仮想マシンモニターのスケジュール方法が記録されたコンピュータで読取り可能な記録媒体であって、
    前記仮想マシンモニターにより、相異なるスケジュールの特性を有する複数のスケジューラを前記ハードウェア上のタスクの実行順を決定するように構成する段階と、
    前記仮想マシンモニターにより、スケジューラリストと加重値テーブルとタイムテーブルとを格納する段階と、を含み、
    前記スケジューラリストは、タスクを起動するイベント毎に、呼び出されるスケジューラが対応付けられて記録されており、
    前記加重値テーブルは、スケジューラ毎に独立して、タスクの属性に応じたそれぞれ異なる加重値が記録されており、
    前記タイムテーブルは、実行タイムリミットを有するそれぞれのタスクのための対応する実行タイムリミットが記録されており、
    さらに、前記仮想マシンモニターにより、
    前記リアルタイムドメインから受信されたタスクを実行キューに挿入し、
    前記タスクをトリガーするイベントのイベント類型に基づいて、前記複数のスケジューラの中から、前記タスクをスケジューリングするのに適したスケジューラを選択し、
    前記実行キューの中のタスクの実行順を、タスクの属性と前記タスクをトリガーするイベント類型に基づいて調整し、
    前記実行キュー内のタスクの実行順を当該タスクの優先度の順位と前記加重値テーブルとに基づいて決定し、
    前記複数のタスクを、その決定された実行順に基づいて実行さるようにスケジューリングする、
    段階を含む、
    ことを特徴とするコンピュータで読取り可能な記録媒体。

Images