JP2009015848A - 階層化された仮想アーキテクチャに仮想イベントを導入するための装置、方法及びシステム - Google Patents

Abstract

【課題】階層化された仮想アーキテクチャに仮想イベントを導入するための装置、方法及びシステムを提供すること。
【解決手段】一実施例による装置は、仮想マシンエントリロジックと、認識ロジックと、評価ロジックとを有する。仮想マシンエントリロジックは、仮想マシンで動作するゲストへ、当該装置の制御をホストから移すことを開始する。認識ロジックは、仮想イベントを仮想マシンに導入するためのホストからのリクエストを認識する。評価ロジックは、仮想イベントを処理する介在モニタを特定する。
【選択図】図１

Description

本発明は一般に情報処理の技術分野に関連し、特にプラットフォームの仮想化の技術分野に関連する。

概して、データ処理装置におけるリソースの仮想化の概念は、１つ以上のオペレーティングシステム(それぞれ「OS」と言及する)の複数のインスタンスが１つのデータ処理システムで動作するのを可能にすることであり、たとえ装置及び装置のリソースに対して各OSが完全な直接的な制御機能を有するように設計されていた場合でさえ、それを可能にする。一般に仮想化は、ソフトウエア(例えば、仮想マシンモニタ(VMM: Virtual Machine Monitor)を使って、仮想リソースを有する「仮想マシン」(VM: Virtual Monitor)を各OSに与えることで実現され、その仮想リソースをOSは完全に直接的に制御してよい。VMMは、VM内の物理的リソースを共用すること及び／又は割り当てることのような仮想化の指針(virtualization policy)を実現するシステム環境(仮想環境)を維持する。VMで動作する各OS及び他の何らかのソフトウエアは、「ゲスト」又は「ゲストソフトウエア」と言及され、「ホスト」又は「ホストソフトウエア」はVMMのようなソフトウエアであり、仮想環境の外で動作する。

データ処理装置のプロセッサは、例えば２つのモード(ルートモード及び非ルートモード)で動作することで仮想化をサポートする。ルートモード(root mode)ではソフトウエアは、ハードウエア上で、どの仮想環境に対しても外部で、直接的に動作する。非ルートモード(non-root mode)では、ソフトウエアは意図される特権レベルで動作するが、ルートモードで動作しているVMMによるホストの仮想環境内で動作する。仮想環境の場合、あるイベント、処理及び状況（特権のあるレジスタやリソースにアクセスする試みや外部割り込み等）は遮られ、即ちプロセッサがその仮想環境を出るようにし、VMMが例えば仮想ポリシを実現する動作を行うようにする。仮想環境を設定する、そこに入る、そこから出る及び維持する命令をプロセッサはサポートし、プロセッサの仮想化機能を指示又は制御するレジスタビット又は他の構造をプロセッサは含んでもよい。

本発明の課題は、階層化された仮想アーキテクチャに仮想イベントを導入するための装置、方法及びシステムを提供することである。

本発明の一形態によれば、仮想マシンエントリロジックと、認識ロジックと、評価ロジックとを有する装置が使用される。前記仮想マシンエントリロジックは、仮想マシンで実行されるゲストへ、当該装置の制御をホストから移すことを開始する。前記認識ロジックは、仮想イベントを前記仮想マシンに導入するための前記ホストからのリクエストを認識する。前記評価ロジックは、前記仮想イベントを処理する介在モニタを特定する。

本発明は添付図面と共に非限定的な実施例により説明される。

階層化された仮想アーキテクチャに仮想イベントを導入する装置及び方法の実施例が説明される。以下の説明では、構成要素やシステム構成のような多くの具体的詳細が、本発明の更なる理解を促すために説明される。しかしながら、本発明はそのような具体的詳細によらず実施されてもよいことを当業者は理解するであろう。更に、ある周知の構造や回路等は、本発明を不必要に曖昧にすることを避ける観点から詳細には示されていない。

図１は、本発明の実施例が使用される階層化された仮想アーキテクチャ100を示す。図１では、プラットフォームハードウエア110は、何らかのOS又はVMMソフトウエアを実行できる如何なるデータ処理装置でもよい。例えば、プラットフォームハードウエアは、パーソナルコンピュータ、メインフレームコンピュータ、サーバ、携帯用コンピュータ、携帯装置、セットトップボックスその他の如何なるコンピュータシステム等でもよい。ベア(bare)プラットフォームハードウエア110は、プロセッサ120、メモリ130、入力／出力(I/O)装置111及びチップセット121を含む。

プロセッサ120は汎用マイクロプロセッサ、ディジタル信号プロセッサ又はマイクロコントローラ等を含む如何なるタイプのプロセッサでもよく、例えば、インテル(登録商標)ペンティアム(登録商標)プロセッサファミリ、Itanium(登録商標)プロセッサファミリ、若しくはインテル(登録商標)コーポレーションから入手可能な他のファミリに属するプロセッサ、他者からの他のプロセッサ等でもよい。図１はそのようなプロセッサ120を１つしか示していないが、ベアプラットフォームハードウエア110はプラットフォームをいくつでも含んでよい。プロセッサ120は複数のスレッド又は複数のコアを如何なる組み合わせで含んでもよい。

メモリ130は、スタティック又はダイナミックランダムアクセスメモリ、半導体ベースのリードオンリ又はフラッシュメモリ、磁気又は光ディスクメモリでもよいし、プロセッサ120により読取可能な他の如何なるタイプの媒体でもよいし、そのような媒体の如何なる組み合わせでもよい。プロセッサ120及びメモリ130は何らかの既知の方法で互いに結合される又は通信を行い、既知の方法は、１つ以上のバスを介した直接的な又は間接的なものでもよいし、１対１形式でもよいし、他の有線又は無線接続でもよい。ベアプラットフォームハードウエア110は、追加的な装置又は接続をいくつでも含んでよい。

ベアプラットフォームハードウエア110に加えて、図１はVMM140、VM150，160，170，180及び多数のゲストを示している。

VMM140は何らかのソフトウエア、ファームウエア又はハードウエアであり、ベアプラットフォーム110上で動作する又はそこにアクセス可能であるようにインストールされ、VM（即ち、抽象化したベアプラットフォームハードウエア110）をゲストに提示し、或いはそうでなければVMを作成し、VMを管理し、仮想アーキテクチャ100でサポートされている仮想環境内で仮想ポリシを実現する。本実施例では、VMM140は「ルートモードホスト」であり、その理由はプロセッサ120上でルートモードで動作するからである。他の実施例では、ルートモードホストは、モニタ、ハイパーバイザ、OS又は他のソフトウエア、ファームウエア若しくはハードウエア（ベアプラットフォームハードウエアを制御可能なもの）等の如何なるものでもよい。

ゲストは如何なるOSでもよいし、如何なるVMMでもよく（VMM140の他のインスタンスも含む）、如何なるハイパーバイザでもよいし、如何なるアプリケーションその他のソフトウエアでもよい。VMに与えられたプラットフォーム及びプロセッサのアーキテクチャに従って、各ゲストは物理的リソースにアクセスすることを想定し、例えば、ベアプラットフォームハードウエア110の、プロセッサ、プラットフォームレジスタ、メモリ、I/O装置等にアクセスする。VM150で動作するようインストールされたゲストOS152及びゲストアプリケーション154,155と、VM160で動作するようにインストールされたゲストVMM162と、VM170で動作するようインストールされたゲストOS172と、VM180で動作するようインストールされたVMM182と共にVM150，160，170及び180が図１に示されている。本実施例では、総てのゲストが非ルートモードで動作する。図１は４つのVM、３つのゲストOS及び２つのゲストアプリケーションを示しているが、VMはいくつ作成されてもよいし、ゲストOS及びアプリケーションのいくつでもが各VMで動作するようにインストールされてもよい（これらは総て本発明の範囲内である。）。

仮想アーキテクチャ100は「階層的(layered)」又は「再帰的(recursive)」である。なぜなら、VMM140のような或るVMMは、例えばVMM162のような他のVMMをゲストとするようにホストを務めるからである。階層的な仮想アーキテクチャ100では、VMM140はVM150,160を含む仮想環境のホストになるが、どの仮想環境の中でもゲストにならない。なぜなら、VMM及びベアプラットフォームハードウエア110間でモニタを一切「介在」せずにベアプラットフォームハードウエア110上で動作するようにVMMはインストールされているからである。「介在する」モニタ(“intervening” monitor)は、ゲストOS172のようなゲストに対してホストを務めるVMM162のようなモニタであるが、それ自身ゲストである。VMM162は、VM170,180を含む仮想環境のホストであるが、VMM140によるホストの仮想環境内のゲストでもある。介在するモニタ(例えば、VMM162)は、ここではペアレントゲスト(親ゲスト)と言及される。なぜなら、それは他のVM（又はVMの階層）に対するペアレント及び前提のVMMのゲストの双方として機能するからである（例えば、VMM140はVMM162のペアレントであり、VMM162はゲスト172,182二対するペアレントである。）。

VMM140とゲストとの間に介在するモニタが一切無ければ、VMM140のようなモニタは、OS152、ゲストアプリケーション154、ゲストアプリケーション155及びゲストVMM162のようなゲストの「ペアレント」として言及される。ゲストはそのモニタの「チャイルド」（子）として言及される。ゲストはチャイルド及びペアレント双方であってもよい。例えば、ゲストVMM162は、VMM140のチャイルドであり、且つゲストOS172及びゲストOS182のペアレントである。

ゲストによりアクセス可能なリソースは、「特権(privileged)」又は「非特権(non-privileged)」リソースの何れかに分類されてよい。特権リソースの場合、ホストはゲストの望む機能を促す一方、そのリソースに対する最終的な制御を留保する。非特権リソースはホストにより制御される必要が無く、ゲストにより直接的にアクセスされてよい。

更に、各ゲストOSは様々なイベントを処理することを想定しており、例えばそのイベントは、例外（例えば、ページ誤り、プロテクション障害）、割り込み（例えば、ハードウエア割り込み及びソフトウエア割り込み）及びプラットフォームイベント（例えば、初期化やシステム管理割り込み）等である。これらの例外、割り込み及びプラットフォームイベントは、本願では「イベント」として包括的に及び個別的に言及される。これらのイベントのいくつかは「特権」のあるものである。なぜなら、それらはホストにより処理され、VMの適切な処理、ホストをゲストから保護すること及びゲスト同士を互いに保護すること等を保証しなければならないからである。

何らかの所与の時点において、プロセッサ120はVMM140又は何らかのゲストからの命令を実行中であり、そして、VMM又はゲストがアクティブであり且つプロセッサ120上で動作している又は制御を受けているかもしれない。特権のイベントが発生した場合又はゲストが特権リソースにアクセスを試みた場合、コントロール(control)がゲストからVMM140に移されてもよい。ゲストからホストへのコントロールの移行は、本願では「VMエグジット(VM exit)」と言及される。イベントを処理し又はリソースへのアクセスを適切に促した後、VMM140はコントロールをゲストに戻してもよい。ホストからゲストへのコントロールの移行は、本願では「VMエントリ(VM entry)」と言及される。

上述したように、ゲストからルートモードホストへコントロールを移すVMエグジットに加えて、本発明の実施例は、ゲストから非ルートモードホストへ(例えば、介在するモニタへ)コントロールを移すVMエグジットを用意してもよい。本発明の実施例では、仮想イベント（即ち、VMエグジットを引き起こすかもしれないもの）は、「トップダウン」又は「ボトムアップ」仮想イベントとして分類されてよい。

「トップダウン」仮想イベントでは、どのホストがVMエグジットでコントロールを受けたかを判定することは、アクティブゲストのペアレントから出発してルートモードホストに向けて進むことで実行される。トップダウン仮想イベントは、アクティブゲストの処理(アクション)を通じて生じる仮想イベントでもよく、そのアクションは、ペンティアム(登録商標)プロセッサファミリに属するプロセッサの命令セットアーキテクチャにおけるCPUID命令のような仮想命令の実行を含む。一実施例では、１つ以上の仮想イベントについてトップダウン仮想イベント処理を迂回する機能が、ホストに備わっていてもよい。

「ボトムアップ」仮想イベントでは、どのホストがVMエグジットでコントロールを受けたかを判定することは、反対向きに実行され、例えばルートモードホストからアクティブゲストのペアレントに向けて実行される。ボトムアップ仮想イベントは、前提とするプラットフォームのアクションにより生じる仮想イベントでもよく、そのアクションは例えばハードウエア割り込み及びシステム管理割り込みであり、或いは、例えば導入される仮想割り込みのように前提とするプラットフォームのイベントをモデル化する。一実施例では、プロセッサ例外は、ボトムアップ仮想イベントとして処理される。例えば、アクティブゲストの実行中にページ誤り例外処理の生じることは、ボトムアップ形式で処理（評価）されてもよい。このボトムアップ処理は、総てのプロセッサ例外に又はその一部分に適用してもよい。

図１の例では、仮想マシン制御構造(VMCS)132に格納されているデータに従って、プロセッサ120はVMの動作を制御する。VMCS132は或る構造であり、１つ又は複数のゲストの状態、VMM140の状態、VMM140が１つ以上のゲストの動作をどのように制御するかを示す実行制御情報、VMエグジット及びVMエントリに関する情報その他の情報を有する。プロセッサ120はVMCS132からの情報を読み取り、VMの実行環境及びその動作に対する制約を確認する。本実施例では、VMCS132はメモリ130に格納されている。VMCS132は複数の構造に分割され、その複数の構造の各々は１つのホスト又は１つのゲストに対応し、各々は独立のVMCSと考えられてよい。

VMMの「ゲスト階層」は、VMMでサポートされている環境又は仮想環境内で動作するようインストールされたソフトウエア群である。本発明は或る仮想アーキテクチャで実現され、その仮想アーキテクチャではゲスト階層がVMCS（複数）の間で一連のポインタを含んでいる。これらのポインタは、チャイルドのVMCSからペアレントのVMCSを指す場合は「ペアレントポインタ」と言及され、ペアレントのVMCSからチャイルドのVMCSを指す場合は「チャイルドポインタ」と言及される。VMMのゲスト階層の場合、VMM及びアクティブゲストの間に１つ以上の介在モニタがあるかもしれない。ゲスト階層が考察されているVMMに近い介在モニタは、アクティブゲストに相対的に近い介在モニタよりも「下位(lower)」であると言及される。

図２は、VMM220のゲスト階層を示し、それはベアプラットフォームハードウエア210におけるルートモードとしてインストールされている。VMCS221はVMM220の制御構造である（但し、ルートモードホストは制御構造なしに動作してもよい。）。ゲスト230はVMM220のチャイルドであり、VMCS231により制御される。従って、ペアレントポインタ(PP)232はVMCS221を指す。ゲスト240はVMM220のチャイルドであり、VMCS241によって制御される。従ってペアレントポインタ242もVMCS221を指す。

ゲスト240はそれ自身がVMMであり、２つのチャイルド、ゲスト250,260を伴い、それぞれVMCS251,261を伴う。ペアレントポインタ252及びペアレントポインタ262双方がVMCS241を指す。

アクティブである又は動作中であるゲストのVMCSは、ペアレントのVMCSのチャイルドポインタによって示される。従って図２はVMCS251を指すチャイルドポインタ243を示し、ゲスト250がアクティブであることを表す。同様に、ヌルチャイルドポインタとは逆に、アクティブチャイルドポインタを伴うゲストのVMCSは、ペアレントのVMCSのチャイルドポインタによって示される。従って図２はVMCS241を指すチャイルドポインタ233を示す。従って、一連のペアレントポインタは、何らかの介在モニタVMCSを介してアクティブゲストのVMCSをルートモードホストのVMCSに連結し(リンクし)、一連のチャイルドポインタは、何らかの介在モニタのVMCSを介してルートモードホストのVMCSをアクティブゲストのVMCSに連結する。

VMCS221はここでは「ルートVMCS」と言及される。上述したように、一実施例では、VMCSは一切無い。ルートVMCSを含む実施例の場合、処理ハードウエアは、内部レジスタ又は他のデータ構造の中でルートVMCSを指すポインタを維持してよい。アクティブであるゲストのVMCSは、上述したように、現在の制御VMCSと言及される。例えば、ゲスト250がアクティブであった場合、VMCS251が現在の制御VMCSになる。一実施例では、処理ハードウエアは、内部レジスタ又は他のデータ構造における現在の制御VMCSを指すポインタを維持してもよい。

VMCSがペアレントVMCSでなかった場合、チャイルドポインタ233，253，263のようなチャイルドポインタはヌルポインタでもよい。VMCSがペアレントを持っていなかった場合、例えばそれがルートモードVMCSであった場合、ペアレントポインタ222のようなペアレントピン他はヌルポインタになってよい。代替的に、これらのポインタは省略されてもよい。場合によっては、ヌルVMCSポインタの「ヌル」用の値は、ゼロでもよい。他の実施例では、「ヌル」として別の値が使用されてもよい。例えば、32ビットアドレスを伴う実施例の場合、0xffffffffという値がヌルとして解釈されてもよい。

図２の各ゲストのVMCSは、仮想イベントを導入することに関する情報に備えて多数の格納場所を含む。これらの格納場所は、フィールドでもよいし、ビットでもよいし、如何なる他の情報格納空間フォーマットで用意されてもよい。

例えば、VMエグジットコントロールフィールド234，244，254，264が多数のイベントビットを含み、それぞれ可能性のある仮想イベントに対応するイベントビットを含んでもよい。各イベントビットは、関連する仮想イベントが生じた場合、ゲストのペアレントがコントロールを望むか否かを示す。

VMエントリコントロールフィールド235，245，255，265の各々は、仮想イベントの導入を制御するためのインジケータを含む。本実施例では、割り込みの導入を制御することにも使用される32ビットフィールドがある。ビット31は有効ビットであり、割り込み又は他のイベントが導入されることを示すように設定される。ビット10：8は導入される割り込み又は他のイベントのタイプを特定するのに使用され、値“001”はVMエグジットを導入することを意味する。このフィールドに関し、他の実施例は別のフォーマットを使用してもよいし、この情報を複数のフィールドにエンコードしてもよい。

VMエグジット情報フィールド236，246，256，266はエグジット理由フィールドを含み、VMエグジットの理由を説明するのに使用され、制御を受けるVMMがVMエグジットを如何に処理するかを判断することを支援する。この例では、上記のVMエグジットエントリコントロールがVMエグジットの導入に使用される場合、エグジット理由フィールドは、導入されるVMエグジットのタイプを説明することにも使用される。VMエグジットの理由に使用されたのと同じコードが、VMエグジットの導入に使用されてもよい。他の実施例では、VMエグジットの導入に使用されたエンコーディング(エンコード処理)は、VMエグジットの理由に使用されたエンコード処理と異なっていてもよい。他の実施例では、新たなフィールドがVMCSに加えられ、導入されるVMエグジットのタイプを表す。

上記の説明は、一実施例を説明するように特定のビット及びフィールドに関連していた。他の実施例では、各VMCSはそのようなビットや他の格納スペースを所望の制御インジケータに応じていくつでも含んでよい。

図１を参照するに、プロセッサ120は仮想化をサポートする制御ロジック(制御論理装置)121を含み、その仮想化は階層化された仮想アーキテクチャに仮想イベントを導入することを含む。制御ロジック121は、マイクロコード、プログラム可能なロジック、ハードコードロジック等で実現されてもよく、或いはプロセッサ120内の何らかの他の形式の制御ロジックで実現されてもよい。他の実施例では、制御ロジック121はハードウエアで、ソフトウエアで又はファームウエアで（例えば、プロセッサ抽象レイヤで）、プロセッサの中で又はプロセッサによりアクセス可能な何らかの装置内で又はプロセッサで読取可能な媒体（例えばメモリ）の中で実現されてもよい。

制御ロジック121は、VMエントリロジック122、認識ロジック123、評価ロジック124及びエグジットロジック125を含む。VMエントリロジック122は、VMエントリを準備し、VMエントリの原因になる。認識ロジック123は、仮想イベントを導入するリクエストを認識する。評価ロジック124は介在モニタを特定し、仮想イベントを処理する。VMエグジットロジック125は、VMエグジットを準備し、VMエグジットの原因になる。これらのロジックユニットの各々は追加的な機能（他のロジックユニットで実行されるように説明されたものを含む）を実行してもよく、これらのロジックユニットの全部又はどれでもが１つのロジックユニットに統合されてもよい。

制御ロジック121は、本発明の実施例による方法（例えば、図3に示される方法）をプロセッサ120が実行することを引き起こし、例えば、仮想化命令、ホスト若しくはゲストからの他の命令、又は仮想化イベントに応答して、1つ以上のマイクロオペレーションの実行を含めること(例えば、仮想化をサポートすること)をプロセッサ120が引き起こすようにする。

図３は、本発明の一実施例により仮想イベントを導入する方法300を示す。本方法はこの例に限定されないが、図３の方法例を説明する際、図１，２のプラットフォームの参照番号が使用される。

ボックス310では、アクティブなホストVMMが、インアクティブなゲスト(ゲストVMCS)のVMCSに、VMエントリ制御フィールドフィールドの値を格納し、そのゲストが動作することになる仮想マシンにVMエグジットが導入されることを表す。ボックス312では、ホストVMMがエグジット理由フィールドの値をゲストVMCSに格納し、導入されるVMエグジットのタイプを表す。ボックス314では、そのVMへのVMエントリが開始される。ボックス316では、認識ロジック123が、VMエグジットを導入するリクエストを認識し、例えば、ゲストVMCSからVMエントリ制御フィールドを読み取ることでそれを認識する。

ボックス320では、評価ロジック124が、挿入されるイベントはトップダウンイベントであるか或いはボトムアップイベントであるかを、例えばゲストVMCSからエグジット理由を読み取ることで確認する。イベントがトップダウンであった場合、本方法300はボックス330に続く。イベントがボトムアップであった場合、本方法300はボックス340に続く。

ボックス330では、評価ロジック124は、介在モニタがトップダウンイベントを処理するか否かを決定し、処理する場合、その介在モニタを識別する。

ボックス330では、ゲストVMCSがチャイルドVMCSとして特定される。ボックス332では、チャイルドのペアレントがイベントを導入したホストであるか否かの確認がなされる。そうであった場合、本実施例では、ボックス334にてエントリロジック122がVMエントリを完了し、ボックス335にて、エグジットロジック125は中間的なVMエグジットが生じることを引き起こし、コントロールがそのペアレントに移される。他の実施例では、ボックス314で開始されたVMエントリは不成功に終わり又は中断し、即ち、VMエントリは完了せず、コントロール（制御）はイベントを導入しようとしたホストと共にそのまま残る。

ボックス332に戻り、ペアレントはそのイベントを導入したホストでなかったことが確認された場合、ボックス336にて、そのペアレントがコントロール（制御）を望んでいるか否かを、例えば、チャイルドVMCSを検査して、導入されるイベントのイベントビットが設定されているか否かを確認することで確認する。望んでいた場合、ボックス334でエントリロジック122はVMエントリを完了し、ボックス335にてエグジットロジック125はVMエグジットが生じることを引き起こし、コントロール（制御）がそのペアレントに移される。例えば、ボックス336を介する唯1つのパスの後にVMエグジットがあった場合、意図されるゲストの中間的なペアレントはコントロール(制御)を受け取る。或る実施例では、仮想化イベントがVMエグジットを無条件に引き起こしてもよい。

ボックス336にて、ペアレントがコントロール(制御)を望んでいないことが確認された場合、ボックス338にて、チャイルドVMCSのペアレントポインタは、新たなチャイルドVMCSとしてペアレントVMCSを識別することに続き、最新のチャイルドVMCSに置き換わる。そして、ボックス332が反復される。

他の実施例では、ペアレントがコントロールを望むか否かの確認が、ホストによるイベント導入に備えて実行されるように、ボックス332から338は並び替えられてもよい。そうでなかった場合（例えば、VMCSのイベントビットがクリアであった場合）、VMエントリの不成功になる。

ボックス340乃至348の場合、介在モニタがボトムアップイベントを処理するか否かを評価ロジック124が決定し、処理する場合、介在モニタを識別する。ボックス340では、イベントを導入したホストのVMCSがペアレントVMCSとして確認される。ボックス341では、ペアレントVMCSのチャイルドポインタが続き、チャイルドVMCSを特定する。ボックス342では、ペアレントがコントロールを望んでいるか否かについての判定がなされ、例えばその判定は、チャイルドVMCSを検査し、導入されるイベントのイベントビットが設定されているか否かを確認することでなされる。そして、望んでいた場合、ボックス344にてエントリロジック122がVMエントリを完了し、ボックス345にてエグジットロジック125がVMエグジットを生じさせ、コントロールがペアレントに移される。或る実施例では、いくつかの仮想イベントが無条件にVMエグジットを引き起こしてもよい。

ペアレントがコントロールを望んでいないことがボックス342での判定で確認された場合、ボックス346にて、チャイルドは導入されたゲストであるか否かの確認がなされ、例えばその確認は、チャイルドVMCSのチャイルドポインタがヌルポインタであるか否かを判定することでなされる。ゲストであった場合、ボックス350にて、ボックス314で開始されたVMエントリは不成功に終わる又は中断され、即ちVMエントリは完了せず、イベントを導入しようとしたホストと共にコントロールは残る。他の実施例では、意図されるゲストに対するVMエントリが完了し、イベントを導入しようとしているホストに対して中間的なVMエグジットが続く。チャイルドは意図されたゲストでなかったことがボックス346で確認された場合、ボックス348でチャイルドVMCSが新たなペアレントVMCSとして確認され、最新のペアレントVMCSに置き換わる。そして、ボックス342が反復される。

本発明の範囲内においては、図３に示される方法を、異なる順序で実行してもよいし、図示の或るボックスを省略して実行してもよいし、別のボックスを追加して実行してもよいし、順序変更、省略又は追加されたボックスの組み合わせと共に実行してもよい。

上記の説明の一部は、コンピュータシステムのレジスタやメモリ内のデータビットに関する処理のアルゴリズム及び抽象的表現の観点からなされた。これらのアルゴリズム説明及び表現は、データ処理の技術分野の当業者が彼らの業務内容を他の当業者に効果的に伝えるために使用する手段である。アルゴリズムは、ここでは一般に、所望の結果をもたらす首尾一貫した処理シーケンスと考えられる。その処理は物理量の物理的取り扱いを必要とするものである。必須ではないが、通常的には、これらの量は、格納、転送、結合、比較その他の処理を行うことのできる電気的又は磁気的な信号の形式をとる。これらの信号をビット、値、エレメント、シンボル、キャラクタ、期間、数等々として言及することは、通常使用されるものであることに起因して、しばしば便利なことが分かるであろう。

しかしながら、これら及び類義語の総ては、適切な物理量に関連付けられ、それらの量に適用される便宜的なラベルに過ぎないことに留意を要する。特に断りのない限り、本発明を通じて、「処理」、「演算」、「計算」、「決定」等のような用語を使った議論は、コンピュータシステムや同様な電子コンピュータ装置の処理、アクション及びプロセス等に言及しており、そのコンピュータシステム等は、コンピュータシステムのレジスタ及びメモリ内で物理的な（電子的な）量で表現されているデータを操作し、そのデータを同様な他のデータに変換する。同様な他のデータは、コンピュータシステムのメモリ、レジスタ、他のそのような情報ストレージ、伝送媒体、ディスプレイ装置内で物理量として表現されるデータである。

更に、プロセッサ120だけでなく、本発明の一実施例により設計された構成要素又は構成要素の一部分の他の如何なるものも、創作、シミュレーションそして製造という様々な段階を考慮して設計されてよい。デザインを表現するデータは、様々な方法でそのデザインを表現してよい。先ず、シミュレーションに有用であるように、ハードウエアはハードウエア記述言語又は他の機能記述言語で表現されてもよい。追加的に又は代替的に、ロジック及び／又はトランジスタゲートを伴う回路レベルモデルが、デザインプロセスの或る段階で生成されてよい。更に、或る段階でほとんどのデザインが或るレベルに到達し、様々なデバイスの物理的配置を表すデータと共にモデル化される。通常の半導体製造技術が使用される場合、デバイスの配置モデルを表すデータは、様々な特徴の存否を様々なマスクレイヤ上で指定するデータでもよい（そのマスクは集積回路を製造するのに使用される。）。

デザインに関するどの表現の場合でも、データは何らかの形式のマシン読取可能な媒体に格納されてよい。そのような情報を伝送するように変調された又は生成された光学的又は電気的な信号波、メモリ、磁気的又は光学的なストレージ媒体（例えば、ディスク）は、マシン読取可能な媒体である。これらのどの媒体も、デザインの内容、本発明の実施例で使用された他の情報（例えば、エラーリカバリルーチンにおける命令等）を「伝送」又は「表現」する。情報を表現及び伝送する電気的搬送波が送信される場合、電気的な信号の複製、バッファリング又は再送が実行されるように、新たなコピーが作成される。従って通信プロバイダ又はネットワークプロバイダの処理は、例えば搬送波のように、事物のコピーを作成することを含み、本発明の技法を使用する。

以上、階層化された仮想アーキテクチャで仮想イベントを導入する装置及び方法が開示された。ある実施例が添付図面と共に説明及び図示されたが、そのような実施例は単なる例示に過ぎず、広範な発明を限定するものではないこと、本発明は図示及び説明された特定の構成及び配置に限定されないことが理解されるべきである。なぜなら、様々な他の修正例が本開示内容を理解した当業者に明らかだからである。そのような本発明の技術分野では、技術の成長は速く、更なる進展を容易には予測されない。添付の特許請求の範囲又は本開示内容の原理から逸脱せずに、技術革新を可能にすることで促されるように、開示された実施例は配置及び詳細について容易に修正可能になるかもしれない。

本発明の実施例が使用される階層化された仮想アーキテクチャを示す図である。 階層化された仮想アーキテクチャにおけるVMMのゲスト階層を示す図である。 本発明の一実施例により仮想イベントを導入する方法を示す図である。

符号の説明

100 仮想アーキテクチャ
110 プラットフォームハードウエア
120 プロセッサ
121 制御ロジック
122 VMエントリロジック
123 認識ロジック
124 評価ロジック
125 エグジットロジック
130 メモリ
132 VMCS(仮想マシン制御構造)
140 VMM(仮想マシンモニタ)
150,160,170,180 VM(仮想マシン)
152,172,182 ゲストオペレーティングシステム
154，155 ゲストアプリケーション
162 ゲストVMM

Claims (21)

1. 仮想マシンエントリロジックと、認識ロジックと、評価ロジックとを有する装置であって、
   前記仮想マシンエントリロジックは、仮想マシンで実行されるゲストへ、当該装置の制御をホストから移すことを開始し、
   前記認識ロジックは、仮想イベントを前記仮想マシンに導入するための前記ホストからのリクエストを認識し、
   前記評価ロジックは、前記仮想イベントを処理する介在モニタを特定する
   ようにした装置。
2. 当該装置の制御を前記介在モニタに移す仮想マシンエグジットロジックを更に有する請求項１記載の装置。
3. 前記仮想マシンエグジットロジックが当該装置の制御を前記介在モニタに移す前に、前記仮想マシンエントリロジックが当該装置の制御を、前記ホストから前記ゲストに移す請求項２記載の装置。
4. 前記評価ロジックが前記介在モニタを特定することに失敗した場合、前記仮想マシンエントリロジックは、前記ホストから前記ゲストへ制御を移すことを中断する請求項１記載の装置。
5. 前記認識ロジックは、前記仮想マシン制御構造に格納されたインジケータに基づいて前記リクエストを認識する請求項１記載の装置。
6. 前記評価ロジックは、前記仮想イベントのタイプも確認する請求項１記載の装置。
7. 前記評価ロジックは、前記仮想マシン制御構造内のインジケータに基づいて、前記仮想イベントのタイプを判定する請求項６記載の装置。
8. 前記仮想イベントの前記タイプに基づいて、トップダウン評価及びボトムダウン評価の何れを実行するかを、前記評価ロジックが判定する請求項６記載の装置。
9. 仮想マシンで実行されるゲストへ、プロセッサの制御をホストから移行することを開始するステップと、
   前記仮想マシンに仮想イベントを導入するための前記ホストからのリクエストを認識するステップと、
   前記仮想イベントを処理する介在モニタを特定するステップと、
   を有する方法。
10. 制御を前記介在モニタに移すステップを更に有する請求項９記載の方法。
11. 評価ロジックが前記介在モニタを特定することに失敗した場合、前記ホストから前記ゲストへ制御を移すことを中断するステップを更に有する請求項９記載の方法。
12. 前記リクエストを認識するステップが、仮想マシン制御構造に格納されたインジケータを読み取るステップを含む請求項９記載の方法。
13. 前記仮想イベントのタイプを確認するステップを更に有する請求項９記載の方法。
14. 前記仮想イベントのタイプを確認するステップは、前記仮想マシン制御構造に格納されたインジケータを読み取るステップを含む請求項１３記載の方法。
15. トップダウン及びボトムダウン評価の何れを実行するかを判定するステップを更に有する請求項９記載の方法。
16. 仮想マシン用の制御構造を格納するメモリと、プロセッサとを有するシステムであって、前記プロセッサは、仮想マシンエントリロジックと、認識ロジックと、評価ロジックとを有し、
    前記仮想マシンエントリロジックは、仮想マシンで実行されるゲストへ、前記プロセッサの制御をホストから移すことを開始し、
    前記認識ロジックは、仮想イベントを前記仮想マシンに導入するための前記ホストからのリクエストを認識し、
    前記評価ロジックは、前記仮想イベントを処理する介在モニタを特定する
    ようにしたシステム。
17. 前記プロセッサは、該プロセッサの制御を前記介在モニタに移す仮想マシンエグジットロジックを有する請求項１６記載のシステム。
18. 前記評価ロジックが前記介在モニタを特定することに失敗した場合、前記仮想マシンエントリロジックは、前記ホストから前記ゲストへ制御を移すことを中断する請求項１６記載のシステム。
19. 前記認識ロジックは、前記仮想マシン制御構造に格納されたインジケータに基づいて前記リクエストを認識する請求項１６記載のシステム。
20. 前記評価ロジックは、前記仮想マシン制御構造内のインジケータに基づいて、前記仮想イベントのタイプを判定する請求項１６記載のシステム。
21. 前記仮想イベントの前記タイプに基づいて、トップダウン及びボトムダウン評価の何れを実行するかを、前記評価ロジックが判定する請求項２０記載のシステム。

Images