JP4769308B2 - 仮想計算機管理機構、同管理機構を有する仮想計算機システム及び同システムにおけるページング処理方法 - Google Patents

Description

本発明は、仮想的に計算機実行環境を提供する仮想計算機システムにおけるページフォルト処理に好適な、仮想計算機管理機構、同管理機構を有する仮想計算機システム及び同システムにおけるページング処理方法に関する。

古くから、メインフレームにおいてハードウェア（ＨＷ）による仮想計算機（Virtual Machine: VM）支援機構を使った仮想計算機システムが知られている。また、近年は、パーソナルコンピュータ（ＰＣ）に搭載されているプロセッサが同様のＶＭ支援機構をＨＷでサポートしてきたこともあり、ＰＣの世界でも計算機の仮想化技術が活用されるようになってきている。今後は個人用のＰＣや、ＰＣを用いて実現されるサーバ（いわゆるＰＣサーバ）等においても、仮想計算機の技術が広く利用されることが予測される。

典型的な仮想計算機システムでは、計算機（実計算機）のハードウェア上に仮想計算機管理機構（virtual machine manager/monitor: VMM）が存在する。実計算機のハードウェアは、ＣＰＵ（実ＣＰＵ）、メモリ（実メモリ）、各種入出力装置（実入出力装置）等で構成されている。ＶＭＭは一般にソフトウェアモジュールを用いて構成される。ＶＭＭは、ハードウェアを直接管理し、それを仮想化して仮想計算機（仮想マシン）を構築する。仮想計算機は、仮想ＣＰＵ、仮想入出力（Ｉ／Ｏ）装置等から構成される。つまりＶＭＭは、仮想ＣＰＵ、仮想Ｉ／Ｏ装置のイメージを作り、実ＣＰＵや実Ｉ／Ｏ装置、実メモリ等のＨＷリソースを時間的、領域的に仮想ＣＰＵ、仮想Ｉ／Ｏ装置、仮想計算機のメモリとして割り当てる。このようにしてＶＭＭは仮想計算機を構築する。仮想計算機にはゲストＯＳと呼ばれるオペレーティングシステム（ＯＳ）がロードされる。このゲストＯＳは、仮想ＣＰＵにより実行される。

このような仮想計算機システムでは、目的に合わせて複数のゲストＯＳを稼動させることができる。これは、通常の計算機システム（非仮想計算機システム）にはない、仮想計算機システムの利点である。

ところで、一般にＯＳは十分な大きさ（記憶容量）の主メモリを必要とする。主メモリの記憶容量が少ないとページング処理が多発し処理効率（処理性能）が落ちる。仮想計算機システムにおいては、実計算機に搭載される主メモリを各ゲストＯＳで分け合って使う必要がある。このため、ゲストＯＳの数が多くなるほど各ゲストＯＳに割り当てられる記憶容量（の平均値）は少なくなる。そこで、例えば非特許文献１では、ＶＭＭによるオンデマンドページングと、共通のデータを有するページをゲストＯＳ間で共有する技術とが提案されている。

ここで例に取り上げる仮想計算機システムにおけるＶＭＭも、ゲストＯＳに割り当てられたメモリ（メモリ領域、メモリ空間）に対してデマンドページング処理を行うものとする。ＶＭＭのメモリマネージャは、ページアウトしてもペナルティが少ないページを、適切なアルゴリズムによってページアウト対象として選択し、ページアウト処理を行う。適切なアルゴリズムには、通常はＬＲＵ（Least Recently Used）アルゴリズムが用いられることが多い。このアルゴリズムによれば、最近の使用頻度が少ないページがページアウト対象として選択される。ページアウト対象のページ（メモリページ）は、ＣＰＵに内蔵されているメモリ管理ユニット（ＭＭＵ）の管理テーブル上でＶＭＭによって「無効」として登録され、当該ページ（内のデータ）が外部記憶装置に書き出される。このページの書き出し（つまりページアウト）が終わり次第、そのページは他の目的で使用される。

その後、ゲストＯＳがページアウトされているページにアクセスすると、当該ページはＭＭＵの管理テーブル上で「無効」として登録されているので、当該ＭＭＵによってページフォルトトラップが発生される。するとＶＭＭに制御が渡り、ＶＭＭは、ページフォルトトラップが発生したページを対象とするページインの処理を行う。このページにアクセスしようとしたゲストＯＳは通常「ブロック状態」となり動作することができず、ＶＭＭによるページイン処理が終わるまで当該ＶＭＭによって実行を待たされる。

このように、ＶＭＭによってゲストＯＳのメモリ領域にデマンドページングを実施することにより、実メモリよりも見かけ上多くのメモリを各ゲストＯＳが使用できるようになる。しかしながら、ＶＭＭによるデマンドページングでは、以下に述べるような不具合が発生する可能性がある。

まず、ＶＭＭによるデマンドページングを説明する前に、通常の計算機システムにおける典型的なＯＳのページング処理について説明する。典型的なＯＳは、当該ＯＳのカーネル内のメモリ領域（カーネル領域、カーネル空間）を対象とするデマンドページング処理を行わないことが多い。一方、ＯＳ上で実行されるユーザプロセスに割り当てられるメモリの管理には仮想記憶方式が採用されおり、当該メモリはカーネルによるデマンドページング処理の対象されることが多い。

このようなＯＳにおいては、ユーザプロセスのメモリ空間（仮想アドレス空間）の全てに実メモリ内のページ（実ページ）が割り当てられているとは限らない。このため、アクセス頻度が低い仮想アドレス空間内のページ（仮想ページ）はページアウトの対象となり、カーネルにより外部記憶装置にページ（内のデータ）が書き出された（データの退避）後、そのページは開放されて他の用途に使用される。ユーザプロセスが再びそのページ（を指定する仮想アドレス）にアクセスすると、そのページには実ページが割り当てられていない（つまりＭＭＵに無効なページとして登録されている）のでページフォルトトラップが発生する。

カーネル（ＯＳのカーネル）は、ページフォルトトラップ発生を機にユーザプロセスからＣＰＵを奪う。そしてカーネルは、当該カーネルによるページイン処理として、ページフォルトトラップが発生したページ（仮想アドレス空間内のページ）への新たな実ページの割り当てと、そのページに対する外部記憶装置からの退避データの読み込みとを行う。この処理にはＩ／Ｏ処理が伴い、比較的長い時間がかかる。このため、ページフォルトを起こしたユーザプロセスは、その処理の間ブロックされる（つまりページイン待ち状態として待機状態になる）。そこでカーネルは、他の実行可能なユーザプロセスを選択し、この選択されたユーザプロセスにＣＰＵを割り当てる。その後、ページインのためのＩ／Ｏ処理が完了すると、Ｉ／Ｏ完了割り込みが発生する。

Ｉ／Ｏ完了割り込みが発生すると、カーネルは、その割り込みを受けて処理を開始する。するとカーネルは、ページイン待ちでブロックされていたユーザプロセスを実行可能状態にして再スケジューリングする。その後、実行可能状態にされたユーザプロセスに、しかるべきタイミングでＣＰＵが割り当てられる。これにより、ＣＰＵが割り当てられたユーザプロセスでは、ページフォルトを起こした状態から処理が再開される。

上述の典型的なＯＳの説明では、カーネル内のページフォルトは起こらないものとしている。しかし、例えばマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）など、カーネル内でのページングを実現しているＯＳもある。このようなＯＳにおいても、ユーザプロセスの場合と同様に、ページフォルトを起こしたカーネル内のスレッド（処理の流れ）は一時的にページイン処理待ちとなってブロックされる。そして、ユーザプロセスの場合と同様に、カーネルにより、他の実行可能なカーネル内のスレッド（カーネルスレッド）にＣＰＵが渡される。これにより、システム全体としてはＣＰＵを使い続けることができる。

なお、ページングを行うカーネルを「ページャブルなカーネル」と呼ぶことがある。ページャブルなカーネルにおいても、全ての領域がページング可能であることは少ない。つまり、特定領域はページング管理の対象外であり、常にページを貼り付けておかなければいけない領域が存在していることが多い。このような特定領域として、例えばページフォルト処理をするためのメモリ領域等が知られている。

ＯＳ（のカーネル）は、ＶＭＭと同様にメモリマネージャを有している。ＯＳのメモリマネージャは、当該ＯＳ上で実行されるユーザプロセス（のメモリ空間）に割り当てられているページを必要に応じてページアウトする。このページアウトされているページにユーザプロセスがアクセスしようとすると、メモリフォールトトラップが発生する。すると、ＯＳのメモリマネージャによりページインの処理が行われる。

トラップを起こしたユーザプロセス（より詳細には、トラップ発生の要因となった、ページアウトされているページにアクセスしたユーザプロセス）は、ＯＳ（のカーネル）によって「ページイン待ち状態（ブロック状態）」に設定される。そしてＯＳによって、他の実行可能なユーザプロセスが選択されて、その選択されたプロセスにＣＰＵがディスパッチされる。ここでＯＳが、カーネル内のメモリ領域（カーネル空間）でのページングもサポートしているものとする。つまり、カーネル内でページング可能なメモリ領域があり、そのメモリ領域はページング対象になるものとする。このページング可能なメモリ領域内のページがページアウトされると、カーネル内で、このページアウトされたページにアクセスしようとしたカーネルスレッドは、やはりページフォルトラップを起こす。すると、ページフォルトラップを起こしたカーネルスレッドは、ページイン処理が完了するまでブロックされる。この場合、他の実行可能なカーネルスレッドが選択されて制御が切り替わることで、システム全体としては処理が進む。

このように、通常のＯＳにおいて、ユーザプロセスあるいはカーネルスレッドのいずれも、ページアウトに起因するページフォルトにより、そのプロセスあるいはカーネルスレッドはページインの処理に伴って一時的に実行がブロックされる。その一方、ＯＳ内の他の実行可能なユーザプロセスあるいはカーネルスレッドが実行されるためにＣＰＵは継続して利用され続け、システム全体とすれば有効にＣＰＵが使用される。つまり、ページフォルトの度に、ＯＳ内に実行できる処理が存在しなくなるということはない。

次に、上述のようなＯＳがゲストＯＳとして仮想計算機上で実行される状態を想定する。ここではＶＭＭがゲストＯＳのメモリ領域に対してデマンドページングを行うことにより、実メモリが有するよりも多くのページ（メモリページ）を仮想的な「ページ」としてゲストＯＳに割り当てるものとする。このとき、上述のような、通常のＯＳ（カーネル）がその上で実行されるユーザプロセスに対して行うページング処理と同様の処理を、ＶＭＭがゲストＯＳに対して行うならば、効率が悪い。この点について、以下で説明する。

ＶＭＭは、各ゲストＯＳに割り当てられているページの中から、適切な戦略（メモリスケジューリングのポリシ）に基づいて使用頻度の低いページを選別してページアウトする。このページアウトされたページをゲストＯＳがアクセスすると、ＶＭＭのメモリ管理によってページフォルトが発生する。この場合、ページアウトされたページがＶＭＭによってページインされるまで、当該ページにアクセスしたゲストＯＳはブロックされる。

つまり、ゲストＯＳ自身によりページアウトされたページへのアクセスの場合には、上述の通り、当該ゲストＯＳが他の実行可能なユーザプロセスにＣＰＵを割り当てることにより、ゲストＯＳとして継続して動作可能である。これに対して、ＶＭＭがページアウトしたページへのアクセスに起因するページフォルトでは、ＶＭＭは当該ページにアクセスしたゲストＯＳ（つまりページフォルトを起こしたゲストＯＳ）をブロックせざるを得ない。この結果、ページフォルトを起こしたゲストＯＳは継続して動作することができなくなる。

各ゲストＯＳのカーネルはＶＭＭから割り当てられたたページを「（なくなることの無い）物理ページ」、つまり常に存在しＣＰＵから常にアクセスできるページとして扱うのが一般的である。しかしながら、ＶＭＭによりページアウトされているページが存在すると、そのページにゲストＯＳがアクセスした瞬間にページフォルトが発生し、ＶＭＭによるページインの処理が発生する。すると、ページアウトされているページにアクセスしたゲストＯＳ（第１のゲストＯＳ）は、ＶＭＭによるページインの処理が完了するまで制御を奪われる。つまり、他の実行可能なゲストＯＳ（第２のゲストＯＳ）にＣＰＵが割り当てられ、第１のゲストＯＳの実行は待たされる。

このような従来技術の不具合について以下に詳述する。
まず、仮想計算機システムが、計算機本体と外部記憶装置とから構成されるものとする。外部記憶装置は、ＶＭＭ及び複数のゲストＯＳそれぞれのページング領域、つまりＶＭＭページング領域及びゲストＯＳ毎のゲストＯＳページング領域を含んでいる。

ＶＭＭは、内部にメモリマネージャを有している。ＶＭＭは、仮想計算機を構築する。この仮想計算機上で複数のゲストＯＳが実行される。複数のゲストＯＳには、ＶＭＭにより実メモリが割り当てられている。ここでは、複数のゲストＯＳに割り当てられた実メモリ内のページ（メモリページ）のうち、使用頻度の少ないページがページアウト処理の対象としてＶＭＭによって選択される。

［ＶＭＭによるページアウト処理］
ここで、ＶＭＭによるページアウト処理について説明する。ＶＭＭのメモリマネージャは常にシステム内の実メモリの使用状態を監視している。ＶＭＭのメモリマネージャは、システム内の実メモリの空き領域（空きページ）が逼迫してきたなら、各ゲストＯＳが使用する仮想アドレス空間内のページに割り当てられている実メモリ内のページの中から使用頻度の低いページを選択し、選択されたページをゲストＯＳから回収する。ＶＭＭのメモリマネージャは、回収されたページ内のデータを、外部記憶装置内のＶＭＭページング領域に退避する。しかる後にＶＭＭのメモリマネージャは、データが退避されたページを、当該ページを必要とするシステム内の他の処理（ページを必要としているゲストＯＳ等）に割り当てる。

このように、ページアウトの対象となるページは、ゲストＯＳが使用する仮想アドレス空間内のページである。このページに元々格納されていたデータは、ページアウト処理の結果、ＶＭＭページング領域に保存される。ページアウト処理の際、ＶＭＭが有するＶＭＭページアウトメモリ管理テーブルに、ページアウトの対象となったページの情報が記録される。この情報は、一般に、ページアウトの対象となったページを使用していたゲストＯＳ（のＩＤ）、当該ページの仮想アドレス空間内のアドレス（仮想アドレス）、及び当該ページのデータが退避されたＶＭＭページング領域内のアドレスを含む。

［ＶＭＭによるページイン処理］
次に、ＶＭＭによるページイン処理について説明する。ＶＭＭによってページアウトされたページにゲストＯＳがアクセスすると、ＣＰＵに内蔵されているＭＭＵはページフォルトトラップを発生する。例えば、ゲストＯＳ上で動作するユーザプロセスが、当該ゲストＯＳの使用するメモリ（仮想アドレス空間）内のある仮想アドレスで指定されるページにアクセスしようとすると、ページフォルトトラップが生じてＶＭＭに制御が渡る。

ＶＭＭのメモリマネージャは、ＶＭＭページアウトメモリ管理テーブルを参照して、ページフォルトの要因となったページ（ＶＭＭによってページアウトされたページ）へのアクセスを試みた（ユーザプロセスが動作する）ゲストＯＳ（のＩＤ）と当該ページの仮想アドレス（ターゲットの仮想アドレス）とを含む情報を検索する。もし、この情報が検索できたならば、ＶＭＭのメモリマネージャは、ターゲットの仮想アドレスで指定されるページは、ＶＭＭによりページアウトされたと判断する。逆に、ページフォルト時にそのページの情報が検索できなかったならば、ＶＭＭのメモリマネージャは、そのページはＶＭＭによりページアウトされているページではないと判断する。

ＶＭＭのメモリマネージャは、ターゲットの仮想アドレスで指定されるページがＶＭＭによりページアウトされたと判断した場合には「ページイン処理」を実行する。この「ページイン処理」において、ページフォルトの要因となったアクセスが試みられたページに実ページを割り当てる処理と、そのページに（ページング領域から）データを復帰する処理とが行われる。「ページイン処理」はＩ／Ｏ処理を伴い、完了するまで比較的長い時間を要する。

そこで、ＶＭＭのメモリマネージャは、ページフォルトの要因となったページへのアクセスを試みたユーザプロセスが動作するゲストＯＳを「ページイン待ち状態（ブロック状態）」に設定する。するとＶＭＭが有するゲストＯＳ実行管理機構は、「ページイン待ち状態」に設定されたゲストＯＳからＣＰＵを奪い、他の実行可能なゲストＯＳに当該ＣＰＵを割り当てる。

その後、ＶＭＭのメモリマネージャによるページイン処理が完了すると、ＶＭＭが有するページイン完了時処理モジュールは、ページインされたページに関して、ＶＭＭページアウトメモリ管理テーブルから該当する登録情報を削除する。

するとＶＭＭのメモリマネージャは、ページインされたページを有するゲストＯＳを「ページイン待ち状態（ブロック状態）」から「実行可能状態」に変える。「実行可能状態」に変えられたゲストＯＳは、その後のＶＭＭのゲストＯＳ実行管理機構によるスケジューリングでＣＰＵディスパッチの対象になり、ディスパッチャによってＣＰＵが割り当てられた時点から動作を再開する。

以上、ゲストＯＳ上で動作するユーザプロセスが使用するメモリ領域に関するＶＭＭによるページング処理について説明した。しかし、ＶＭＭによるページングの対象はユーザプロセスが使用するメモリ領域だけに限らない。例えば、ゲストＯＳのカーネルが使用するメモリ領域がページングの対象になる場合もある。

ここで、注意しなければならないことは、次の点である。
まず、通常の計算機システムにおける典型的なＯＳのページング処理を想定する。この典型的なＯＳのページング処理では、前述したように、ＯＳによりページアウトされたページにユーザプロセスがアクセスしたためにページフォルトトラップが発生しても、他の実行可能なユーザプロセスに制御が切り替えられる。これにより、システムとしてはＣＰＵを有効に使い続けることができる。

しかしながら、仮想計算機システムでは、ＶＭＭによりページアウトされたページにゲストＯＳ上で動作するユーザプロセス（またはカーネルスレッド）がアクセスしたためにページフォルトトラップが発生した場合、通常の計算機システムと異なって、そのゲストＯＳ内の他の実行可能なユーザプロセス（またはカーネルスレッド）に制御を切り替えることができない。その理由は、次の通りである。

第１の理由は、ＶＭＭによりページングが管理されているため、ページフォルトトラップ発生をきっかけとする通常のゲストＯＳ内のメモリマネージャによるページングの処理を行うことができない点にある。第２の理由は、ページアウトされたページのデータが退避されるページング領域はＶＭＭ内のメモリマネージャが管理しているため、ゲストＯＳ内のメモリマネージャはＶＭＭのページングに関与できない点にある。

このため、仮想計算機システムでは、ゲストＯＳを切り替えることでＣＰＵを使い続けようとする。しかし、ページフォルトトラップを起こしたゲストＯＳ内に実行可能なプロセス（またはスレッド）が存在しているならば、システムの効率は低下する。

一方、ゲストＯＳ内でのページングによりページアウトされたページへのアクセスでページフォルトトラップが発生した場合には、通常の計算機システムにおけるのと同様のページング処理が行われる。この場合、ＣＰＵは、ページフォルトトラップを起こしたゲストＯＳ内で実行可能な処理に割り当て直されて継続して使われる。ところが、ＶＭＭによりページアウトされたページへのアクセスでページフォルトトラップが発生した状況でＣＰＵを使い続けるには、上述のように、ゲストＯＳ自体を切り替えるしかない。

これまでの説明から理解されるように、ゲストＯＳは、自身が管理するページに関して、自身が行うメモリ管理の一環としてデマンドページングを行っている。このため、たとえゲストＯＳ上で実行されるプロセスからのページアウトされているページへのアクセスに起因してページフォルトが発生しても、当該ゲストＯＳ内の他の実行可能なプロセスにスイッチすることができる。これにより、仮想計算機システム全体としてＣＰＵを効率よく利用することができる。

しかし、ゲストＯＳが使用するメモリページのＶＭＭによる管理に関しては、ＶＭＭがページアウトしたページに対してゲストＯＳがアクセスすることによってページフォルトが発生すると、他のゲストＯＳにスイッチするしかない。このため、せっかく、ゲストＯＳ内で効率よくページング処理を行っていたとしても、ＶＭＭによるページング処理によりゲストＯＳがブロックされてしまう状況が発生し、効率が悪かった。

そこで、上記非特許文献１は、バルーンと呼ばれる方法を提案している。この方法では、ゲストＯＳ内で特別なアプリケーションプログラムが実行される。この特別なアプリケーションプログラムの実行により、ゲストＯＳ内のメモリ使用状況を含むシステムの状態が監視されて、当該システムに悪影響を及ぼさない範囲内で、ゲストＯＳで使用可能ななるべく多くのページ（メモリ領域）が、当該ゲストＯＳによるページングの対象にされない状態で確保される。確保されたページのページアウトは、そのページをゲストＯＳからＶＭＭにこっそり通知することにより、ＶＭＭによって行われる。

この確保されたページをゲストＯＳ内で取り扱うプロセスはなく、且つカーネルもページングの対象にしないので、安全にＶＭＭによるページング処理の対象にできる。つまり、ゲストＯＳ内で何らかの処理（プロセスまたはスレッド）がページアウトされたページにアクセスしても、当該処理（プロセスまたはスレッド）を含むゲストＯＳがブロックされる事態は生じない。
"Memory Resource Management in VMware ESX Server", Carl A. Waldspurger, VMware, Inc., In Proc. Fifth Symposium on Operating Systems Design and Implementation (OSDI '02), Dec. 2002、［２００７年９月３０日検索］、インターネット＜URL: http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf＞

上述した通り、仮想計算機上で動作するゲストＯＳが使用可能なメモリページに対するＶＭＭによるページングでは、一般のＯＳ、或いはゲストＯＳ自身で行っているデマンドページングに比べると、ページアウトされているページへのアクセスに起因してページフォルトが発生した場合に、ページフォルトを起こしたゲストＯＳは継続して動作することができなくなるという問題があった。特に、ＶＭＭからはゲストＯＳ内のプロセス管理やスレッド管理ができないため、ゲストＯＳ単位でＣＰＵの割り当てを変えるしかなく、ゲストＯＳにとって効率の悪い状況となっていた。

一方、非特許文献１に記載された方法では、アプリケーションプログラムから指定されたページに関しては、そのページがＶＭＭによってページアウトされて、そのページアウトされたページに、ゲストＯＳ内のプロセスまたはスレッドがアクセスしても、当該プロセスまたはスレッド（を含むゲストＯＳ）がブロックされるのを防止できる。

しかし、非特許文献１に記載された方法では、アプリケーションプログラムから指定されたページのみしか効率よくＶＭＭがページアウトすることができない。また、アプリケーションプログラムによってゲストＯＳ内のメモリ使用状況を正確に把握することには限界があり、精度の良いページングは難しい。要するに、非特許文献１に記載された方法は、柔軟性に乏しい。

本発明は上記事情を考慮してなされたものでその目的は、仮想計算機管理機構によるページングを実現しながら、当該仮想計算機管理機構によってページアウトされたページへのゲストＯＳからのアクセスに起因してページフォルトが発生しても、当該ゲストＯＳがブロックされるのを防止できる、仮想計算機管理機構、同管理機構を有する仮想計算機システム及び同システムにおけるページング処理方法を提供することにある。

本発明の１つの観点によれば、ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機管理機構が提供される。前記仮想計算機管理機構は、前記複数のゲストＯＳに割り当てられたメモリ領域に対してページを単位にページアウト処理を含むデマンドページング処理を行うページング手段と、前記ページング手段によってページアウトされたページに関するページアウト管理情報を保持するページアウト管理情報保持手段とを具備する。前記ページング手段は、ページアウトされたページに対してゲストＯＳがアクセスしたことによりページフォルトが発生した際に、当該ページフォルトが発生したページに関するページアウト管理情報が前記ページアウト管理情報保持手段に保持されていることをもって、当該ページフォルトの要因が前記ページング手段によってページアウトされたページへのアクセスにあると判定して、その旨を当該ページフォルトが発生したページにアクセスした前記ゲストＯＳに通知すると共に当該ゲストＯＳにページフォルトトラップを配信し、且つ当該ページアウトされたページにデータを復帰するためのページイン処理を実行する。

本発明によれば、ゲストＯＳが起こしたページフォルトの要因が、ＶＭＭのページング手段）によってページアウトされたページへのアクセスにあることが、当該ＶＭＭのページング手段から当該ゲストＯＳに通知される構成とすることにより、従来技術では当該ゲストＯＳの実行をブロックするしかなかったページフォルト（つまりＶＭＭによってページアウトされたページへのアクセスに起因して当該ゲストＯＳが起こしたページフォルト）に関して、ＶＭＭのページング手段からの上記通知を受けたゲストＯＳが、ページフォルトを起こした処理をＶＭＭのページング手段によるページイン処理の完了待ちの状態に設定することが可能となり、当該ゲストＯＳ自体がブロックされるのを防止することができる。これにより、ページフォルトを起こした処理を実行していたゲストＯＳにおいて、他の処理（つまり他のユーザプロセスまたはカーネル内スレッド）の実行に切り替えて当該ゲストＯＳ自体は動作を継続することができ、ＶＭＭによるページングを実現しながら、効率のよいゲストＯＳ内スケジューリングを可能とする。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システムの構成を示すブロック図である。図１に示される仮想計算機システムは、計算機本体１０と外部記憶装置２０とから構成される。

計算機本体１０は、例えば、ＰＣ（パーソナルコンピュータ）やＰＣサーバのような実計算機を用いて実現される。実計算機は、ＣＰＵ（実ＣＰＵ）、メモリ（実メモリ）、各種Ｉ／Ｏ装置（実Ｉ／Ｏ装置）等で構成されるハードウェア（ＨＷ）を有している。図１では、このＨＷは省略されている。

計算機本体１０は、仮想計算機管理機構（virtual machine manager/monitor：ＶＭＭ）１１を含む。ＶＭＭ１１は、周知のように、計算機本体１０が有するＨＷを構成するＨＷリソース（ＣＰＵを含むＨＷリソース）を管理する。ＶＭＭ１１は、このＨＷリソースの管理によって、当該ＨＷリソースを、時間的、領域的に割り当てる（配分する）ことにより、例えばｎ台の仮想計算機（仮想マシン）１２-1〜１２-nを構築する。仮想計算機１２-1〜１２-nは、ＶＭＭ１１上で動作する。図１では、仮想計算機１２-1〜１２-nを構成する、仮想ＣＰＵ等は省略されている。

仮想計算機１２-1〜１２-n上では、それぞれゲストＯＳ１３-1（＃１）〜１３-n（＃ｎ）が動作する。本実施形態においてゲストＯＳ１３-1〜１３-nは、いわゆる「パラ・バーチャライゼーション」と呼ばれるゲストＯＳ実装（実行）方式を適用することを前提としている。すなわち、ゲストＯＳ１３-1〜１３-nは初めからＶＭＭ１１上で動作することを前提とした実装がなされている。

なお、「パラ・バーチャライゼーション」に対して「フル・バーチャライゼーション」と呼ばれるゲストＯＳの実装方式も知られている。「フル・バーチャライゼーション」では、通常の実計算機（物理計算機）で実行されるＯＳと同じ構造のＯＳを仮想計算機上でゲストＯＳとして動作させることを前提としている。つまり、フル・バーチャライゼーション」は、カーネルを特別にゲストＯＳ向けに修正（ＶＭＭ上でゲストＯＳが動くことを前提にゲストＯＳそのものを修正）しないという方針の実装方式である。

フル・バーチャライゼーションでは、通常の実計算機で動いているＯＳが、何の修正もなくそのままゲストＯＳとして仮想計算機上で動くことが可能である。このためフル・バーチャライゼーションの適用によって実装されるゲストＯＳは、移植性が高く使いやすい反面、ＶＭＭと密に連携できずに効率が悪い部分が多々ある。また、フル・バーチャライゼーションを実現するＶＭＭを実装するためには、ＶＭＭが生成する仮想計算機は実計算機と全く同じ見せ方をする必要があるので、実装コストは一般的に大きい。

これに対し、パラ・バーチャライゼーションはゲストＯＳを修正する必要がある。しかし、パラ・バーチャライゼーションの適用によって実装されるゲストＯＳは、ＶＭＭと協調して動作し、互いに効率よく動作できる可能性がある。このため、最近パラ・バーチャライゼーションが注目されている。

ゲストＯＳ１３-1〜１３-n上では、それぞれ１つ以上のユーザプロセス１４が動作可能であるものとする。ゲストＯＳ１３-1〜１３-nは、それぞれ当該ゲストＯＳ１３-1〜１３-nの中枢をなすカーネル（ゲストＯＳカーネル）１５-1〜１５-nを含む。

ゲストＯＳカーネル１５-1〜１５-nは、それぞれ当該ゲストＯＳカーネル１５-1〜１５-n（内で動作するカーネルスレッド）によってアクセス可能なメモリ領域（カーネル内メモリ領域）１６-1〜１６-nを含む。

カーネル内メモリ領域１６-1は、ゲストＯＳカーネル１５-1内の後述するメモリマネージャ１７によるページングの対象となる１つ以上の仮想アドレス領域を含むものとする。ゲストＯＳ１３-1上で動作するユーザプロセス１４が使用するページもゲストＯＳカーネル１５-1内のメモリマネージャ１７によるページングの対象となる。一方、カーネル内メモリ領域１６-1〜１６-nのうち、カーネル内メモリ領域１６-1以外のカーネル内メモリ領域も、メモリマネージャ１７と同様のメモリマネージャによるページングの対象となる１つ以上の仮想アドレス領域を含むものとする。また、ゲストＯＳ１３-1〜１３-nのうち、ゲストＯＳ１３-1以外のゲストＯＳ上で動作するユーザプロセス１４が使用するページも、そのゲストＯＳのゲストＯＳカーネル内のメモリマネージャによるページングの対象となる。

図１には、ゲストＯＳ１３-1〜１３-n上で動作するユーザプロセス１４によって使用（アクセス）されたページ及びゲストＯＳカーネル１５-1〜１５-nによって使用（アクセス）されたカーネル内メモリ領域１６-1〜１６-nのページのうち、ＶＭＭ１１によってページアウトされたページＰ_VMM１〜Ｐ_VMM８が示されている。また、図１には、上述のページのうち、ゲストＯＳ１３-1，１３-nによってページアウトされたページＰ_OS１〜Ｐ_OS６も示されている。

ゲストＯＳカーネル１５-1は、カーネル内メモリ領域１６-1を管理するメモリマネージャ１７を含む。メモリマネージャ１７は、ページングモジュール１７１、ページイン完了時処理モジュール１７２及び図示せぬページアウトメモリ管理テーブルから構成される。これらページングモジュール１７１、ページイン完了時処理モジュール１７２及びページアウトメモリ管理テーブルは従来からよく知られているため、説明を省略する。

ＶＭＭ１１は、ゲストＯＳインターフェイス機構１１１、ゲストＯＳ実行管理機構１１２及びメモリマネージャ１１３を含む。

ゲストＯＳインターフェイス機構１１１は、ＶＭＭ１１が提供する種々のサービスを利用するためのゲストＯＳ１３-1〜１３-nからの要求を当該ＶＭＭ１１に通知するのに用いられる、いわゆるシステムコール機構である。ゲストＯＳ１３-1〜１３-nは、ゲストＯＳインターフェイス機構１１１を使うことにより、ＶＭＭ１１に種々のサービスを要求することができる。これらの要求は、例えば、（１）メモリ割り当ての要求、（２）ＣＰＵ割り当て量の増減の要求、（３）ＭＭＵ操作の要求、（４）割り込みマスク操作の要求、（５）割り込みステータス取得の要求等が一般的である。

本実施形態では、ゲストＯＳ１３-1〜１３-nはパラ・バーチャライゼーションを前提としている。このため、ゲストＯＳインターフェイス機構１１１を使用することでＶＭＭ１１が提供する種々のサービスを要求するための機能を、ゲストＯＳ１３-1〜１３-nに持たせることができる。つまりゲストＯＳ１３-1〜１３-nのカーネル（ゲストＯＳカーネル）１５-1〜１５-nは、ＶＭＭ１１によって管理されるＨＷリソースの操作を、ゲストＯＳインターフェイス機構１１１を用いてＶＭＭ１１に要求するように構成されている。これに対し、実計算機（物理計算機）上で動作するＯＳは、直接ＨＷリソースにアクセスして操作するのが一般的である。

ゲストＯＳ実行管理機構１１２は、ＶＭＭ１１が管理するゲストＯＳ１３-1〜１３-nの各々にどの程度の時間の割合でＣＰＵを割り当てるかを計算し決定するスケジューラとしての機能を有するモジュールである。つまりゲストＯＳ実行管理機構１１２は、ゲストＯＳ１３-1〜１３-nの実行スケジュールを計算し決定するためのスケジューリング処理を行う。

ゲストＯＳ実行管理機構１１２はまた、ディスパッチャとしての機能をも有する。つまりゲストＯＳ実行管理機構１１２は、当該ゲストＯＳ実行管理機構１１２のスケジューリング処理によって決定されたスケジュールに従って、ゲストＯＳ１３-1〜１３-nにＣＰＵを割り当てるディスパッチ処理も行う。

メモリマネージャ１１３は、ゲストＯＳ１３-1上で実行されるユーザプロセス１４が使用するページ及びカーネル内メモリ領域１６-1内のページのＶＭＭ１１によるページング処理を管理する。メモリマネージャ１１３は、ＶＭＭページングモジュール１１４、ＶＭＭページイン完了時処理モジュール１１５、ＶＭＭページアウトメモリ管理テーブル１１６及びＶＭＭメモリ管理テーブル１１７から構成される。

ＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1〜１３-n上でそれぞれ実行されるユーザプロセス１４が使用するページ及びカーネル内メモリ領域１６-1〜１６-n内のページを必要に応じて外部記憶装置２０にページアウトするためのページアウト処理を行う。ＶＭＭページングモジュール１１４は、ページアウトされたページにゲストＯＳ１３-1〜１３-nがアクセスしたためにページフォルトが発生した場合に、必要に応じて当該ゲストＯＳ１３-1〜１３-nにページフォルトトラップを配信するトラップ配信モジュールを含む。ＶＭＭページングモジュール１１４はまた、ページフォルトの要因となったアクセス（ページアクセス）が試みられたページに実ページを割り当て、そのページに外部記憶装置２０からデータを復帰するページイン処理を行う。

ＶＭＭページイン完了時処理モジュール１１５は、ＶＭＭページングモジュール１１４によるページイン処理（ＶＭＭページイン処理）が完了した際に動作して、当該ＶＭＭページイン処理の完了時の処理を行う。この処理においてＶＭＭページイン完了時処理モジュール１１５は、ＶＭＭページイン処理の完了を、ページフォルトの要因（当該ページイン処理の要因）となったアクセス（ページアクセス）を試みたゲストＯＳに通知するための割り込み（ＶＭＭページイン完了通知割り込み）を発行する。

ＶＭＭページアウトメモリ管理テーブル１１６は、ＶＭＭ１１に割り当てられているメモリ（図示せず）に格納される。ＶＭＭページアウトメモリ管理テーブル１１６は、ＶＭＭページングモジュール１１４によるページアウトの対象となったページの情報（ページアウト管理情報）を保持する保持手段（ページアウト管理情報保持手段）として用いられる。このＶＭＭページアウトメモリ管理テーブル１１６に保持（登録）されるページアウト管理情報は、ページアウトの対象となったページを使用していたゲストＯＳのＩＤ（ゲストＯＳ ＩＤ）、当該ページの仮想アドレス空間内のアドレス（仮想アドレス）、及び当該ページのデータが退避された後述するＶＭＭページング領域２１内のアドレス（ＶＭＭページング領域アドレス）を含む。

図２は、ＶＭＭページアウトメモリ管理テーブル１１６のデータ構造例を示す。図２の例では、ページアウトの対象となったページのページアウト管理情報として、ゲストＯＳ ＩＤ＝２、仮想アドレス＝０x８０００３０００、ＶＭＭページング領域アドレス＝０x４００３８０２からなる情報が、ＶＭＭページアウトメモリ管理テーブル１１６に登録されていることが示されている。

ＶＭＭメモリ管理テーブル１１７は、ＶＭＭページアウトメモリ管理テーブル１１６と同様にＶＭＭ１１に割り当てられているメモリに格納される。ＶＭＭメモリ管理テーブル１１７は、ゲストＯＳ１３-i（ｉ＝１〜ｎ）のＩＤ（ゲストＯＳ ＩＤ）と、当該ゲストＯＳ１３-iのゲストＯＳカーネル１５-iがページャブル（ページャブルカーネル）であるか否かを示すフラグとを含む情報（サービス要求情報）を保持する保持手段（サービス要求情報保持手段）として用いられる。このサービス要求情報は、当該サービス要求情報中のフラグによってゲストＯＳカーネル１５-iがページャブルことが示されている場合に、当該ゲストＯＳカーネル１５-iのページング対象メモリ領域を示すメモリ領域情報を含む。

ゲストＯＳ１３-iのゲストＯＳカーネル１５-iがページャブルであるとは、当該ゲストＯＳカーネル１５-i（を含むゲストＯＳ１３-i）が本来、カーネルモードにおいてページングをサポートしていることを意味する。つまりゲストＯＳ１３-iのゲストＯＳカーネル１５-iは、ページャブルなメモリ領域でのページフォルトトラップ発生時に、カーネルスレッドをスイッチして（切り替えて）処理を継続できるカーネルである。

図３は、ＶＭＭメモリ管理テーブル１１７のデータ構造例を示す。図３の例では、ページング対象メモリ領域を示すメモリ領域情報として、当該メモリ領域（仮想アドレス領域）の開始位置及び終了位置を示す情報、つまり開始仮想アドレス及び終了仮想アドレスの対が用いられる。

外部記憶装置２０は、ＶＭＭページング領域２１と、ゲストＯＳページング領域２２-1〜２２-nを有する。ＶＭＭページング領域２１は、ＶＭＭ１１内のＶＭＭページングモジュール１１４によるページアウトの対象となったページのデータを退避するのに用いられる。図１の例では、ＶＭＭページング領域２１に、ページＰ_VMM１〜Ｐ_VMM８のデータが退避されている。

ゲストＯＳページング領域２２-1〜２２-nは、それぞれ、ゲストＯＳカーネル１５-1〜１５-n内のページングモジュールによるページアウトの対象となったページのデータを退避するのに用いられる。図１の例では、ゲストＯＳページング領域２２-1にページＰ_OS１〜Ｐ_OS４のデータが退避され、ゲストＯＳページング領域２２-nにページＰ_OS５,Ｐ_OS６のデータが退避されている。

次に、本実施形態の動作について説明する。
まず、ゲストＯＳ１３-i（ｉ＝１〜ｎ）内のゲストＯＳカーネル１５-iは、
（１）ページャブルカーネルであるか否か
（２）ページャブルカーネルであるならば、ページャブルなメモリ領域
をＶＭＭ１１に予め通知する。この通知によってゲストＯＳカーネル１５-iは、ＶＭＭ１１に対して特定のサービスを要求する。この特定のサービスとは、ＶＭＭ１１内のＶＭＭページングモジュール１１４がページアウトしたページに対してゲストＯＳ１３-iがアクセスしたことを要因としてページフォルトが発生した場合に、ＶＭＭ１１が、その旨を当該ゲストＯＳ１３-iに通知し、且つページフォルトトラップを当該ゲストＯＳ１３-iに配信するサービスを意味する。

そのためＶＭＭ１１内のゲストＯＳインターフェイス機構１１１は、ゲストＯＳカーネル１５-iがページャブルカーネルであるか否かを当該ゲストＯＳカーネル１５-iからＶＭＭ１１に通知するのに用いられる第１のゲストＯＳインターフェイスを含む。この第１のゲストＯＳインターフェイスは、例えば
VMM_Interface_If_This_GuestOS_is_Pagable_Kernel(True or False);
のような、関数（インターフェイス関数）を用いて実現される。括弧内には引数が設定される。この引数に「True」または「False」を指定することで、該当するゲストＯＳ１３-i内のゲストＯＳカーネル１５-iがページャブルカーネルであるか否かがＶＭＭ１１に通知される。

またゲストＯＳインターフェイス機構１１１は、ゲストＯＳ１３-iのゲストＯＳカーネル１５-iがページャブルカーネルである場合に、ページャブルなメモリ領域（仮想アドレス領域）を当該ゲストＯＳカーネル１５-iからＶＭＭ１１に通知するのに用いられる第２のゲストＯＳインターフェイスを含む。

第２のゲストＯＳインターフェイスは、例えば
VMM_Interface_Regstration_Pagable_Kernel_Area(StartAddress, EndAddress);
のような、関数（インターフェイス関数）を用いて実現される。括弧内には引数が設定される。この引数によりページャブルなメモリ領域の開始仮想アドレス（StartAddress）及び終了仮想アドレス（EndAddress）の対が指定される。もし、複数のページャブルな領域をＶＭＭ１１に通知する必要があるときには、ゲストＯＳ１３-iのゲストＯＳカーネル１５-iは、それぞれの領域毎に第２のゲストＯＳインターフェイスを用いる。

ここで、ゲストＯＳ１３-iがゲストＯＳ１３-1（ｉ＝１）であり、当該ゲストＯＳ１３-1のゲストＯＳカーネル１５-1が、ページャブルカーネルであるものとする。この場合、ゲストＯＳ１３-1のゲストＯＳカーネル１５-1は、上述の第１のゲストＯＳインターフェイスを使って、当該ゲストＯＳカーネル１５-1がページャブルカーネルであることを予めＶＭＭ１１に通知しておく。本実施形態では、この第１のゲストＯＳインターフェイスを用いたゲストＯＳ１３-1からＶＭＭ１１への通知により、ＶＭＭ１１のＶＭＭページングモジュール１１４によってページアウトされたページに対してゲストＯＳ１３-1がアクセスしたことを要因としてページフォルトが発生した場合に、ＶＭＭ１１が、その旨を当該ゲストＯＳ１３-1に通知し、且つページフォルトトラップを当該ゲストＯＳ１３-1に配信する特定のサービスが、当該ＶＭＭ１１に要求される。

またゲストＯＳカーネル１５-1は、上述の第２のゲストＯＳインターフェイスを使って、ページャブルなメモリ領域（仮想アドレス領域）を、当該領域の開始位置及び終了位置を示す情報（つまり開始仮想アドレス及び終了仮想アドレスの対）により予めＶＭＭ１１に通知しておく。

ゲストＯＳ１３-1のゲストＯＳカーネル１５-1からの第１のインターフェイス、更には第２のゲストＯＳインターフェイスを用いた通知は、ＶＭＭ１１のゲストＯＳインターフェイス機構１１１で受け付けられる。

ＶＭＭ１１のメモリマネージャ１１３は、ゲストＯＳ１３-1のゲストＯＳカーネル１５-1からの第１のインターフェイスを用いた通知に応じて、ＶＭＭメモリ管理テーブル１１７に、当該ゲストＯＳ１３-1のＩＤとページャブルカーネルであるか否かを示すフラグ（ここでは、ページャブルカーネルであることを示すフラグ）とを含むエントリ情報（サービス要求情報）を追加する。メモリマネージャ１１３はまた、ゲストＯＳ１３-1のゲストＯＳカーネル１５-1からの第２のインターフェイスを用いた通知に応じて、ＶＭＭメモリ管理テーブル１１７内の当該ゲストＯＳ１３-1のＩＤを含むエントリ情報（サービス要求情報）に、通知されたページャブルなメモリ領域を示す情報（開始仮想アドレス及び終了仮想アドレスの対）を追加する。

次に、ゲストＯＳ１３-1〜１３-nのうちの例えばゲストＯＳ１３-1によるページアクセスでページフォルトが発生した場合にＶＭＭ１１によって実行される処理について、図４のフローチャートを参照して説明する。なお、ゲストＯＳ１３-1以外のゲストＯＳによるページアクセスでページフォルトが発生した場合も同様の処理が行われる。

今、ゲストＯＳ１３-1（更に詳細には、ゲストＯＳ１３-1上で動作するユーザプロセスまたはカーネルスレッド）が、ページアウトされているページにアクセスした結果、ページフォルトが発生したものとする。つまりゲストＯＳ１３-1に割り当てられたＣＰＵ（実ＣＰＵ）に内蔵のＭＭＵによってページフォルトが発生されたものとする。このページフォルトの発生（ページフォルトトラップ）により、ＶＭＭ１１内のメモリマネージャ１１３に含まれているＶＭＭページングモジュール１１４に制御が渡る。すると、ＶＭＭページングモジュール１１４を始めとする、ＶＭＭ１１内の各モジュールにより、次のような処理（ページフォルト発生時の処理）が行われる。

まずＶＭＭページングモジュール１１４は、ＶＭＭページアウトメモリ管理テーブル１１６を参照する（ステップ４０１）。そしてＶＭＭページングモジュール１１４は、ページフォルトを起こしたゲストＯＳ１３-1のＩＤ及びページフォルトとなったページの仮想アドレスの対を含むページアウト管理情報がＶＭＭページアウトメモリ管理テーブル１１６に登録されているかにより、当該ページフォルトの要因が、ＶＭＭ１１内のＶＭＭページングモジュール１１４によってページアウトされたページへのアクセスにあるかを判定する（ステップ４０２）。

もし、ゲストＯＳ１３-1のＩＤ及びページフォルトとなったページの仮想アドレスの対を含むページアウト管理情報がＶＭＭページアウトメモリ管理テーブル１１６に登録されていないならば、ＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1におけるページフォルトの要因がＶＭＭ１１内の当該ＶＭＭページングモジュール１１４自身によってページアウトされたページへのアクセス以外にあると判定する（ステップ４０２がＮｏ）。つまりＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1におけるページフォルトの要因が、ゲストＯＳ１３-1内のメモリマネージャ１７によって管理されているページングによるページフォルト（またはエラーによる不正アドレスへのアクセス）にあると判定する。この場合、ＶＭＭページングモジュール１１４（のトラップ配信モジュール）はゲストＯＳ１３-1にページフォルトトラップを配信する（ステップ４０３）。これにより、ページフォルト発生時のＶＭＭ１１による処理は終了する。

ゲストＯＳ１３-1は、ＶＭＭページングモジュール１１４からのページフォルトトラップを受けて、当該ゲストＯＳ１３-1が起こしたページフォルトを、後述するように通常のページフォルトとして処理する（ステップ５０５）。

これに対し、ゲストＯＳ１３-1のＩＤ及びページフォルトとなったページの仮想アドレスの対を含むページアウト管理情報がＶＭＭページアウトメモリ管理テーブル１１６に登録されているならば、ＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1におけるページフォルトの要因が当該ＶＭＭページングモジュール１１４自身によってページアウトされたページへのアクセスにあると判定する（ステップ４０２がＹｅｓ）。このとき、外部記憶装置２０のＶＭＭページング領域２１には、ページフォルトとなったページのデータが退避されている。

ステップ４０２の判定がＹｅｓの場合、ＶＭＭページングモジュール１１４はは、ページフォルトとなったページのデータをページインするためのＩ／Ｏ処理（ページイン処理）を開始する（ステップ４０４）。つまりＶＭＭページングモジュール１１４は、ページフォルトの要因となったアクセスが試みられたページに実ページを割り当て、外部記憶装置２０のＶＭＭページング領域２１に退避（ページアウト）されていたデータを読み込んで、当該読み込まれたデータを、そのページに復帰するページイン処理を開始する。

次にＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1がページフォルトを起こした際に、当該ゲストＯＳ１３-1がカーネルモードであったか否か（ユーザモードであったか）を判定する（ステップ４０５）。つまり、ＶＭＭページングモジュール１１４はステップ４０５において、ゲストＯＳ１３-1がカーネルモードのときに発生したページフォルトであるかを判定する。このステップ４０５の判定は、ページフォルト発生時（ページフォルトトラップ時）のプロセッサの特権モードの情報（ここではゲストＯＳ１３-1がカーネルモードであるかユーザモードであるかを示す情報）を参照することで簡単に実現される。

もし、カーネルモードでないならば（ステップ４０５がＮｏ）、ＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1がユーザモードのときに発生したページフォルトであると判定する。この場合、ＶＭＭページングモジュール１１４（のトラップ配信モジュール）は、ゲストＯＳ１３-1にページフォルトトラップを配信する（ステップ４０６）。このステップ４０６において、ＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1でのページフォルトの要因がＶＭＭ１１がページアウトしたページへのアクセスにあることと、そのページのアドレス（ページフォルト発生アドレス）とを、当該ゲストＯＳ１３-1に通知する。ステップ４０６が実行されると、ページフォルト発生時のＶＭＭ１１による処理は終了する。

ステップ４０６での上述の要因の通知は、高々１ビットで実現可能である。例えば、元々用意されているべき、ＶＭＭ１１からゲストＯＳに情報を渡すためのＣＰＵのレジスタ中の空きビット（１ビット）を用いればよい。もし、空きビットがなければ、トラップ時に利用可能なレジスタの中にＶＭＭページングモジュール１１４が特定の値を設定することにより、当該レジスタを介して上述の要因を通知してもよい。

一方、ゲストＯＳ１３-1がカーネルモードのときに発生したページフォルトであるならば（ステップ４０５がＹｅｓ）、ＶＭＭページングモジュール１１４は、当該ゲストＯＳ１３-1のＩＤに基づいてＶＭＭメモリ管理テーブル１１７を参照する（ステップ４０７）。そしてＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1のＩＤを含むサービス要求情報がＶＭＭメモリ管理テーブル１１７に格納され、当該サービス要求情報に含まれているフラグによって当該ゲストＯＳ１３-1のゲストＯＳカーネル１３-1がページャブルであることが示され、且つ当該サービス要求情報に当該ゲストＯＳカーネル１５-iのページング対象メモリ領域を示すメモリ領域情報（開始仮想アドレス及び終了仮想アドレスの対）が含まれているかを判定する。つまりＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1のゲストＯＳカーネル１５-1がページャブルカーネルであり、且つ当該ゲストＯＳカーネル１５-1がページング対象としているメモリ領域が予め通知されているかを判定する（ステップ４０８）。

ステップ４０８の判定がＹｅｓの場合、ＶＭＭページングモジュール１１４はＶＭＭメモリ管理テーブル１１７を参照した結果に基づき、ページフォルトとなったページは、予めゲストＯＳカーネル１５-1から通知されている、当該ゲストＯＳカーネル１５-1（を含むゲストＯＳ１３-1）がページング対象としているメモリ領域内にあるかを判定する（ステップ４０９）。このステップ４０９の判定は、ページフォルトとなったページの仮想アドレスが、参照されたサービス要求情報に含まれているメモリ領域情報によって示される、ゲストＯＳ１３-1（のゲストＯＳカーネル１５-1）がページング対象としているメモリ領域の開始仮想アドレスと終了仮想アドレスとの間に入っているかを調べることにより実現される。

もし、ページフォルトとなったページが、ゲストＯＳ１３-1（のゲストＯＳカーネル１５-1）がページング対象としているメモリ領域内にある場合には（ステップ４０９がＹｅｓ）、ＶＭＭページングモジュール１１４はステップ４０６に進む。つまり、ゲストＯＳ１３-1（のゲストＯＳカーネル１５-1）がページャブルカーネルであり、且つゲストＯＳ１３-1（のゲストＯＳカーネル１５-1）がページング対象としているメモリ領域内のページへのアクセスでページフォルトが発生した場合、ＶＭＭページングモジュール１１４はステップ４０６に進む。

さて、ステップ４０９の判定がＹｅｓの場合、ゲストＯＳ１３-1が起こしたページフォルトを、当該ゲストＯＳ１３-1で処理できる。つまりステップ４０９の判定がＹｅｓであることは、ゲストＯＳ１３-1内でページフォルトを起こしたカーネルスレッドをブロックして他のスレッドにスイッチすることができることを示す。そのためステップ４０９の判定がＹｅｓの場合、ＶＭＭページングモジュール１１４（のトラップ配信モジュール）はステップ４０６に進み、ゲストＯＳ１３-1にページフォルトトラップを配信する。

一方、ステップ４０８の判定がＮｏであるか、ステップ４０８の判定がＹｅｓであってもステップ４０９の判定がＮｏの場合には、ゲストＯＳ１３-1が処理できないカーネルモードでのページフォルトである。この場合、ＶＭＭページングモジュール１１４は、ページフォルトを起こしたゲストＯＳ１３-1の状態を、ＶＭＭ１１（内のＶＭＭページングモジュール１１４）によるページイン処理の完了を待つページイン待ち状態（ＶＭＭページイン処理完了待ち）に設定する（ステップ４１０）。つまりＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1をブロックする。

するとゲストＯＳ実行管理機構１１２は、ページフォルトを起こしたゲストＯＳ１３-1から当該ゲストＯＳ１３-1に割り当てられていたＣＰＵを横取りし、当該ゲストＯＳ１３-1のコンテクスト（つまり実行状態）を例えば外部記憶装置２０に保存する（ステップ４１１）。

次にゲストＯＳ実行管理機構１１２は、ゲストＯＳ１３-1〜１３-nの中から、ゲストＯＳ１３-1以外の実行可能な１つのゲストＯＳを選択して、当該選択されたゲストＯＳにＣＰＵを割り当てる再スケジューリングを行う（ステップ４１２）。これにより、ページフォルト発生時のＶＭＭ１１による処理は終了する。

次に、ページフォルトを起こしたゲストＯＳ１３-1にＶＭＭ１１（内のＶＭＭページングモジュール１１４）からページフォルトトラップが配信されたときに、当該ゲストＯＳ１３-1によって実行される処理について、図５のフローチャートを参照して説明する。

なお、ＶＭＭ１１がゲストＯＳ１３-1にページフォルトトラップを配信した際には、通常の実計算機で発生する各種トラップ、割り込みと同様、それを当該ゲストＯＳ１３-1で処理するために必要な情報が、ＶＭＭ１１から当該ゲストＯＳ１３-1に何らかの形で（例えばレジスタを用いて）渡されることを前提とする。この情報は、ページフォルトトラップの例では、
（１）そもそも例外がページフォルトトラップであることを示す情報
（２）ページフォルトとなったページのアドレス（ページフォルト発生アドレス）、及び例外発生時の特権モード情報を含むトラップ情報
を含む。

ページフォルトトラップの場合、このような情報に加えて、前述のステップ４０６の処理で説明したように、ページフォルトの要因がＶＭＭ１１がページアウトしたページへのアクセスにあることを示す情報も、当該ＶＭＭ１１（内のＶＭＭページングモジュール１１４）からゲストＯＳ１３-1に渡される。

さて、ＶＭＭ１１からゲストＯＳ１３-1にページフォルトトラップが配信されると、ゲストＯＳ１３-1に含まれているメモリマネージャ１７内のページングモジュール１７１は、ページフォルトの要因が、ＶＭＭ１１がページアウトしたページへのアクセスにあるかを判定する（ステップ５０１）。

もし、ページフォルトの要因が、ＶＭＭ１１がページアウトしたページへのアクセス以外にある場合には（ステップ５０１がＮｏ）、メモリマネージャ１７内のページングモジュール１７１は、実計算機で動作する通常のゲストＯＳがページフォルトに対するのと同様のページイン処理を行う（ステップ５０２）。即ちページングモジュール１７１は、ページフォルトの要因となったアクセスが試みられたページに実ページを割り当て、外部記憶装置２０のゲストＯＳページング領域２２-1に退避（ページアウト）されていたデータを読み込んで、当該読み込まれたデータを、そのページに復帰するページイン処理を行う（ステップ５０２）。また、ステップ５０２においてページングモジュール１７１は、ページフォルトを起こしたゲストＯＳ１３-1において実行中のユーザプロセス１４またはカーネルスレッドの状態（つまりページフォルトを起こした処理）を、通常のゲストＯＳによるページイン処理の場合と同様に、ゲストＯＳ１３-1によるページイン処理の完了を待つページイン待ち状態（ゲストＯＳページイン処理完了待ち）に設定する。

なお、不正アドレスへのアクセスに伴うページフォルトトラップの場合にも、ステップ５０１の判定がＮｏとなる。この場合、ステップ５０２では、ユーザプロセス１４が起こしたページフォルトであるならば、当該ユーザプロセス１４を停止したり、カーネルが起こしたページフォルトならば、ゲストＯＳ１３-1を周知のパニックモードに移行するなどの、エラー処理が行われる。ここでは、便宜的に、不正アドレスへのアクセスに伴うページフォルトトラップは発生していないものとする。

一方、ページフォルトの要因が、ＶＭＭ１１がページアウトしたページへのアクセスにある場合には（ステップ５０１がＹｅｓ）、ページングモジュール１７１は、ページフォルトを起こしたユーザプロセス１４またはカーネルスレッドの状態（処理）を、ＶＭＭ１１（内のＶＭＭページングモジュール１１４）によるページイン処理の完了を待つページイン待ち状態（ＶＭＭページイン処理完了待ち）に設定する（ステップ５０３）。このステップ５０３では、先のステップ５０２と異なり、ページングモジュール１７１によるページイン処理（ページインのためのＩ／Ｏ処理）は行われないことに注意する。

ゲストＯＳ１３-1は、ステップ５０２及び５０３のうちのいずれが実行された場合にも、ページフォルトを起こしたユーザプロセス１４またはカーネルスレッド（処理）から当該ユーザプロセス１４またはカーネルスレッドに割り当てられていたＣＰＵを横取りし、当該ユーザプロセス１４またはカーネルスレッドのコンテクスト（つまり実行状態）を例えば外部記憶装置２０に保存する（ステップ５０４）。

続いてゲストＯＳ１３-1は、他の実行可能なユーザプロセス１４またはカーネルスレッド（つまり他の実行可能な処理）をゲストＯＳ１３-1内から選択して、当該選択されたユーザプロセス１４またはカーネルスレッドにＣＰＵを割り当てる再スケジューリングを行う（ステップ５０５）。

さて、本実施形態では、上記ステップ４０４の処理、即ちＶＭＭ１１のＶＭＭページングモジュール１１４によるページイン処理が完了した際に、ページフォルトを起こしたゲストＯＳ（ここではゲストＯＳ１３-1）に対し、その旨が、ＶＭＭ１１のＶＭＭページイン完了時処理モジュール１１５によって通知される。このＶＭＭ１１のＶＭＭページングモジュール１１４によるページイン処理の完了時の処理について、図６のフローチャートを参照して説明する。

今、ＶＭＭページングモジュール１１４によるページイン処理が完了したものとする。この場合、ＶＭＭページイン完了時処理モジュール１１５に制御が渡る。ＶＭＭページイン完了時処理モジュール１１５は、ＶＭＭページアウトメモリ管理テーブル１１６から、ページイン処理が完了したページのページアウト管理情報を削除する（ステップ６０１）。

次にＶＭＭページイン完了時処理モジュール１１５は、ページイン処理が完了したページを所有するゲストＯＳ１３-1の状態が、ＶＭＭ１１（内のＶＭＭページングモジュール１１４）によるページイン処理の完了を待つページイン待ち状態（ＶＭＭページイン処理完了待ち）にあるかを判定する（ステップ６０２）。明らかなように、前述のステップ４１０が実行された場合には、ゲストＯＳ１３-1はページイン待ち状態（ＶＭＭページイン処理完了待ち）にあることから、ステップ６０２の判定はＹｅｓとなる。

この状態のときには、ゲストＯＳ１３-1のゲストＯＳカーネル１５-1のページャブルでないメモリ領域内のページをＶＭＭ１１（内のＶＭＭページングモジュール１１４）がページアウトしているために、当該ゲストＯＳ１３-1全体が動けない状態になっている。そこでステップ６０２の判定がＹｅｓの場合、ＶＭＭ１１のＶＭＭページングモジュール１１４は、ゲストＯＳ１３-1（つまりＶＭＭページイン処理が完了したページを所有するゲストＯＳ１３-1）の状態を実行可能状態に設定する（ステップ６０３）。

するとＶＭＭ１１のゲストＯＳ実行管理機構１１２は、ステップ６０３で実行可能状態に設定されたゲストＯＳ１３-1を含むゲストＯＳ１３-1〜１３-nの中から、実行可能な１つのゲストＯＳを選択して、当該選択されたゲストＯＳにＣＰＵを割り当てる再スケジューリングを行う（ステップ６０４）。

一方、ページイン処理が完了したページを所有するゲストＯＳ１３-1がページイン待ち状態（ＶＭＭページイン処理完了待ち）にないものとする（ステップ６０２がＮｏ）。明らかなように、前述のステップ４０６が実行された場合には、ゲストＯＳ１３-1内のページフォルトを起こしたユーザプロセス１４またはカーネルスレッド（処理）はページイン待ち状態（ＶＭＭページイン処理完了待ち）にあるものの、ゲストＯＳ１３-1自体はページイン待ち状態（ＶＭＭページイン処理完了待ち）にないことから、ステップ６０２の判定はＮｏとなる。この場合、ゲストＯＳ１３-1内にページフォルトを起こしたユーザプロセス１４またはカーネルスレッド（処理）が存在し、当該ページフォルトを起こしたユーザプロセス１４またはカーネルスレッド（処理）がページイン処理の完了を待っている。

そこで、ステップ６０２の判定がＮｏの場合、ＶＭＭページイン完了時処理モジュール１１５は、ゲストＯＳ１３-1に、ＶＭＭ１１によるページイン処理（ＶＭＭページイン処理）の完了、及びページフォルト発生アドレスを通知すると共に、ＶＭＭページイン処理の完了を通知する割り込み（ＶＭＭページイン完了通知割り込み）を当該ゲストＯＳ１３-1に配信する（ステップ６０５）。

次に、上述のステップ６０５でＶＭＭ１１のＶＭＭページイン完了時処理モジュール１１５が配信したＶＭＭページイン完了通知割り込みをゲストＯＳ１３-1が受信した場合に当該ゲストＯＳ１３-1によって実行される処理について、図７のフローチャートを参照して説明する。

まずゲストＯＳ１３-1は、ＶＭＭ１１のＶＭＭページイン完了時処理モジュール１１５からのＶＭＭページイン完了通知割り込みを受け取ると、ＶＭＭ１１によるページイン処理（ＶＭＭページイン処理）の完了を待っていたユーザプロセス１４またはカーネルスレッド（処理）の状態を実行可能状態に設定する（ステップ７０１）。

次にゲストＯＳ１３-1は、（ステップ７０１で実行可能状態に設定されたユーザプロセス１４またはカーネルスレッドを含めて）実行可能な１つのユーザプロセス１４またはカーネルスレッド（処理）をゲストＯＳ１３-1内から選択して、当該選択されたユーザプロセス１４またはカーネルスレッドにＣＰＵを割り当てる再スケジューリングを行う（ステップ７０２）。

従来の仮想計算機システムにおいて実行されるＶＭＭによるデマンドページングは、ゲストＯＳがその中で行うデマンドページングとは独立して行われていた。ここでは、ゲストＯＳ内のユーザプロセスのメモリ空間を対象とするページングであっても、ゲストＯＳがページアウトしたページへのアクセスでのページフォルトでは、当該ゲストＯＳ内の他のユーザプロセスに切り替わってゲストＯＳとしては処理が継続できる。

ところが、上記のページを、ＶＭＭ１１がページアウトしていた場合には、ゲストＯＳ内で他のユーザプロセスにスイッチすることはできず、つまり当該ゲストＯＳはブロックされる。このため従来の仮想計算機システムでは、効率のよいゲストＯＳ内スケジューリング（ユーザプロセス及び／またはカーネルスレッドのディスパッチ）が行えないという問題があった。

これに対して本実施形態では、ゲストＯＳがページフォルトの要因が、ＶＭＭ１１によってページアウトされたページへのアクセスにあることが、ＶＭＭ１１のメモリマネージャ１１３（内のＶＭＭページングモジュール１１４）から当該ゲストＯＳに通知される。この通知により、当該通知を受けたゲストＯＳは、ＶＭＭ１１のメモリマネージャ１１３と連携することで、当該ゲストＯＳをブロックすることなく、ＶＭＭ１１によるページイン処理の完了を待つことができる。その結果、通知を受けたゲストＯＳ（つまりページフォルトを起こした処理を実行していたゲストＯＳ）において、他の処理（他のユーザプロセスまたはカーネル内スレッド）の実行に切り替えて動作を継続することができ、ＶＭＭ１１によるページングを実現しながら、効率のよいゲストＯＳ内スケジューリングを図ることができる。

なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係る仮想計算機システムの構成を示すブロック図。 図１に示されるＶＭＭページアウトメモリ管理テーブルのデータ構造例を示す図。 図２に示されるＶＭＭメモリ管理テーブルのデータ構造例を示す図。 ゲストＯＳによるページアクセスでページフォルトが発生した場合にＶＭＭ（仮想計算機管理機構）によって実行される処理の手順を示すフローチャート。 ページフォルトを起こしたゲストＯＳにＶＭＭからページフォルトトラップが配信されたときに実行される処理の手順を示すフローチャート。 ＶＭＭによるページイン処理の完了時に当該ＶＭＭによって実行される処理の手順を示すフローチャート。 ＶＭＭが配信したＶＭＭページイン完了通知割り込みをゲストＯＳが受信した場合に実行される処理の手順を示すフローチャート。

１０…計算機本体、１１…ＶＭＭ（仮想計算機管理機構）、１２-1〜１２-n…仮想計算機、１３-1〜１３-n…ゲストＯＳ、１４…ユーザプロセス、１５-1〜１５-n…ゲストＯＳカーネル、１６-1〜１６-n…カーネル内メモリ領域、１７…メモリマネージャ、２０…外部記憶装置、２１…ＶＭＭページング領域、２２-1〜２２-n…ゲストＯＳページング領域、１１１…ゲストＯＳインターフェイス機構、１１２…ゲストＯＳ実行管理機構、１１３…メモリマネージャ、１１４…ＶＭＭページングモジュール、１１５…ＶＭＭページイン完了時処理モジュール、１１６…ＶＭＭページアウトメモリ管理テーブル、１１７…ＶＭＭメモリ管理テーブル、１７１…ページングモジュール、１７２…ページイン完了時処理モジュール。

Claims (10)

1. ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機管理機構において、
   前記複数のゲストＯＳに割り当てられたメモリ領域に対してページを単位にページアウト処理を含むデマンドページング処理を行うページング手段と、
   前記ページング手段によってページアウトされたページに関するページアウト管理情報を保持するページアウト管理情報保持手段とを具備し、
   前記ページング手段は、
   ページアウトされたページに対してゲストＯＳがアクセスしたことによりページフォルトが発生した際に、当該ページフォルトが発生したページに関するページアウト管理情報が前記ページアウト管理情報保持手段に保持されているかに基づき、当該ページフォルトの要因が、前記ページング手段自身によってページアウトされたページへのアクセスにある第１の要因であるか、或いは前記ゲストＯＳ内のページングによってページアウトされたページへのアクセスにある第２の要因であるかを判定し、
   前記第１の要因の場合には、前記第１の要因を前記ページフォルトが発生したページにアクセスした前記ゲストＯＳに通知すると共に当該ゲストＯＳにページフォルトトラップを配信することによって、当該ゲストＯＳに、当該ゲストＯＳにおいて前記ページフォルトを起こした処理を前記ページング手段によるページイン処理の完了待ちの状態に設定させ、且つ前記ページング手段自身によってページアウトされたページにデータを復帰するためのページイン処理を実行し、
   前記第２の要因の場合には、前記ページフォルトが発生したページにアクセスした前記ゲストＯＳにページフォルトトラップを配信することによって、当該ゲストＯＳに、当該ゲストＯＳ内のページングによってページアウトされたページにデータを復帰するためのページイン処理を実行させると共に、当該ゲストＯＳにおいて前記ページフォルトを起こした処理を当該ゲストＯＳによるページイン処理の完了待ちの状態に設定させる
   ことを特徴とする仮想計算機管理機構。
2. 前記ページング手段によるページイン処理の完了に応じて、その旨を通知するための特定の完了割り込みを、前記ページフォルトが発生したページにアクセスした前記ゲストＯＳに発行することにより、当該ゲストＯＳにおいて前記ページング手段によるページイン処理の完了待ちの状態に設定されている処理を実行可能状態に切り替えさせるページイン完了時処理手段を更に具備することを特徴とする請求項１記載の仮想計算機管理機構。
3. 前記複数のゲストＯＳの各々が前記仮想計算機管理機構に特定のサービスを予め要求するのに用いられるゲストＯＳインターフェイス機構であって、前記特定のサービスは、当該特定のサービスを要求するゲストＯＳが前記仮想計算機管理機構の前記ページング手段によってページアウトされたページに対してアクセスしたことを要因としてページフォルトが発生した場合に、その旨を当該ゲストＯＳに通知すると共にページフォルトトラップを当該ゲストＯＳに配信するサービスであるゲストＯＳインターフェイス機構と、
   前記ゲストＯＳから前記仮想計算機管理機構に前記特定のサービスが要求されたことを示すサービス要求情報を保持するサービス要求情報保持手段とを更に具備し、
   前記ページング手段は、前記ページフォルトの要因が当該ページング手段によってページアウトされたページへのアクセスにあると判定した場合、当該ページにアクセスしたゲストＯＳから前記特定のサービスが要求されていることを示す前記サービス要求情報が前記サービス要求情報保持手段に保持されていることをもって、前記第１の要因の通知と前記ページフォルトトラップの配信とを行うことを特徴とする請求項１または２に記載の仮想計算機管理機構。
4. 前記ゲストＯＳインターフェイス機構は、前記複数のゲストＯＳの各々が前記特定のサービスを要求するのに加えて、当該ゲストＯＳのカーネルがカーネルモードでページングを実施するページャブルカーネルであることと、当該ページングの対象となるメモリ領域とを当該ゲストＯＳが前記仮想計算機管理機構に予め通知するのに用いられ、
   前記サービス要求情報保持手段に保持されている前記サービス要求情報は、当該サービス要求情報によって示される前記特定のサービスを要求したゲストＯＳのカーネルが前記ページャブルカーネルであるかを示す情報及び前記ページャブルカーネルである場合に前記ページングの対象となるメモリ領域を示すメモリ領域情報を含み、
   前記ページング手段は、当該ページング手段によってページアウトされたページに前記カーネルモードでアクセスした前記ゲストＯＳのカーネルが前記ページャブルカーネルであることが前記サービス要求情報に含まれている前記ページャブルカーネルであるかを示す情報によって示され、且つ当該ページアウトされたページが前記サービス要求情報に含まれている前記メモリ領域情報の示すメモリ領域内にある場合に、前記ゲストＯＳへの前記第１の要因の通知と前記ページフォルトトラップの配信とを行う
   ことを特徴とする請求項３記載の仮想計算機管理機構。
5. 前記複数のゲストＯＳの実行を管理するゲストＯＳ実行管理手段を更に具備し、
   前記ページング手段は、当該ページング手段によってページアウトされたページに前記カーネルモードでアクセスした前記ゲストＯＳのカーネルが前記ページャブルカーネルでないことが前記サービス要求情報に含まれている前記ページャブルカーネルであるかを示す情報によって示されている場合、前記第１の要因の通知と前記ページフォルトトラップの配信とを抑止し、
   前記ゲストＯＳ実行管理手段は、前記第１の要因の通知と前記ページフォルトトラップの配信とが抑止された前記ゲストＯＳから前記複数のゲストＯＳのうちの他のゲストＯＳの実行に切り替える
   ことを特徴とする請求項４記載の仮想計算機管理機構。
6. 前記ページング手段は、当該ページング手段によってページアウトされたページにアクセスした前記ゲストＯＳから前記特定のサービスが要求されていることを示す前記サービス要求情報が前記サービス要求情報保持手段に保持されていない場合、前記第１の要因の通知と前記ページフォルトトラップの配信とを抑止し、
   前記ゲストＯＳ実行管理手段は、前記要因の通知と前記ページフォルトトラップの配信とが抑止された前記ゲストＯＳから前記複数のゲストＯＳのうちの他のゲストＯＳの実行に切り替える
   ことを特徴とする請求項５記載の仮想計算機管理機構。
7. ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機管理機構を有する仮想計算機システムにおいて、
   前記仮想計算機管理機構は、
   前記複数のゲストＯＳに割り当てられたメモリ領域に対してページを単位にページアウト処理を含むデマンドページング処理を行うページング手段と、
   前記ページング手段によってページアウトされたページに関するページアウト管理情報を保持するページアウト管理情報保持手段とを具備し、
   前記ページング手段は、
   ページアウトされたページに対してゲストＯＳがアクセスしたことによりページフォルトが発生した際に、当該ページフォルトが発生したページに関するページアウト管理情報が前記ページアウト管理情報保持手段に保持されているかに基づき、当該ページフォルトの要因が、前記ページング手段によってページアウトされたページへのアクセスにある第１の要因であるか、或いは前記ゲストＯＳ内のページングによってページアウトされたページへのアクセスにある第２の要因であるかを判定し、
   前記第１の要因の場合には、前記第１の要因を前記ページフォルトが発生したページにアクセスした前記ゲストＯＳに通知すると共に当該ゲストＯＳにページフォルトトラップを配信し、且つ前記ページング手段自身によってページアウトされたページにデータを復帰するためのページイン処理を実行し、
   前記第２の要因の場合には、前記ページフォルトが発生したページにアクセスした前記ゲストＯＳにページフォルトトラップを配信し、
   前記複数のゲストＯＳの各々は、
   前記第１の要因の判定に応じて前記仮想計算機管理機構の前記ページング手段からページフォルトトラップが配信されると共に前記第１の要因が通知された場合に、当該ゲストＯＳにおいて前記ページフォルトを起こした処理を前記ページング手段によるページイン処理の完了待ちの状態に設定し、
   前記第２の要因の判定に応じて前記仮想計算機管理機構の前記ページング手段からページフォルトトラップが配信された場合に、当該ゲストＯＳ内のページングによってページアウトされたページにデータを復帰するためのページイン処理を実行すると共に、当該ゲストＯＳにおいて前記ページフォルトを起こした処理を当該ゲストＯＳによるページイン処理の完了待ちの状態に設定する
   ことを特徴とする仮想計算機システム。
8. 前記複数のゲストＯＳの各々は、前記ページフォルトを起こした処理を前記仮想計算機管理機構の前記ページング手段によるページイン処理の完了待ちの状態に設定した場合、前記ページフォルトを起こした処理以外の実行可能な処理の実行に切り替えることを特徴とする請求項７記載の仮想計算機システム。
9. 前記仮想計算機管理機構は、前記仮想計算機管理機構の前記ページング手段によるページイン処理の完了に応じて、その旨を通知するための特定の完了割り込みを、前記ページフォルトが発生したページにアクセスした前記ゲストＯＳに発行するページイン完了時処理手段を更に具備し、
   前記複数のゲストＯＳの各々は、自身宛に前記特定の完了割り込みが発行された場合、前記仮想計算機管理機構の前記ページング手段によるページイン処理の完了待ちの状態に設定されている処理を実行可能状態に切り替える
   ことを特徴とする請求項７または８に記載の仮想計算機システム。
10. ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを実行させるための管理を行う仮想計算機管理機構と、前記仮想計算機管理機構によってページアウトされたページに関するページアウト管理情報を保持するページアウト管理情報保持手段とを有する仮想計算機システムにおけるページング処理方法であって、
    ページアウトされたページに対してゲストＯＳがアクセスしたことによりページフォルトが発生した際に、前記仮想計算機管理機構が、前記ページアウト管理情報保持手段を参照するステップと、
    前記ページフォルトが発生したページに関するページアウト管理情報が前記ページアウト管理情報保持手段に保持されているかによって、当該ページフォルトの要因が、前記仮想計算機管理機構によってページアウトされたページへのアクセスにある第１の要因であるか、或いは前記ゲストＯＳ内のページングによってページアウトされたページへのアクセスにある第２の要因であるかを、前記仮想計算機管理機構が判定するステップと、
    前記第１の要因の場合、前記仮想計算機管理機構によってページアウトされたページにデータを復帰するためのページイン処理を、前記仮想計算機管理機構が実行するステップと、
    前記第１の要因の場合、前記仮想計算機管理機構が、前記第１の要因を前記ページフォルトが発生したページにアクセスした前記ゲストＯＳに通知すると共に当該ゲストＯＳにページフォルトトラップを配信するステップと、
    前記第２の要因の場合、前記仮想計算機管理機構が、前記ページフォルトが発生したページにアクセスした前記ゲストＯＳにページフォルトトラップを配信するステップと、
    前記第１の要因の判定に応じて前記仮想計算機管理機構から前記ページフォルトトラップが配信されると共に前記第１の要因が通知されたゲストＯＳが、前記ページフォルトを起こした処理を前記前記仮想計算機管理機構によるページイン処理の完了待ちの状態に設定するステップと、
    前記第２の要因の判定に応じて前記仮想計算機管理機構から前記ページフォルトトラップが配信されたゲストＯＳが、当該ゲストＯＳ内のページングによってページアウトされたページにデータを復帰するためのページイン処理を実行すると共に、当該ゲストＯＳにおいて前記ページフォルトを起こした処理を当該ゲストＯＳによるページイン処理の完了待ちの状態に設定するステップと
    を具備することを特徴とする仮想計算機システムにおけるページング処理方法。

Images