シャドウページテーブル（VMM用）は正確に何をしますか？
私の理解では、シャドウページテーブルは、VM内の物理メモリをエミュレートする必要をなくします。
すなわち。
の代わりに：
ゲストOS-> VMM +仮想物理メモリ->ホストOS->ホストハードウェア
それはただ：
ゲストOS-> VMM->ホストOS->ホストハードウェア
シャドウページテーブルは、プロセスがホストハードウェアのメモリに正しくアクセスできるようにするだけです。また、ページフォールトのしくみがわかりません（または、すべての物理メモリがホストによって処理されるため、ホストがページフォールトやスワップなどを処理します）。
シャドウページテーブルは、ゲストがページテーブルを「考える」必要がある状態を追跡するためにハイパーバイザーによって使用されます。ゲストはハードウェアページテーブルへのアクセスを許可されません。これは、ゲストが本質的にマシンを制御するためです。したがって、関連するゲストが実行しているとき、ハイパーバイザーはハードウェアで「実際の」マッピング（ゲスト仮想->ホスト物理）を維持し、ゲストが「シャドウ内」で使用していると考えるページテーブルの表現を維持します。少なくともそれは私がそれについて考えるのが好きな方法です。
これにより、GVA-> GPA変換ステップが回避されることに注意してください。
ページフォールトに関する限り、ハードウェアの観点からは何も変更されません（ハイパーバイザーがハードウェアによって使用されるページテーブルにGVA-> HPAマッピングが含まれるようにすることを忘れないでください）。ページ違反は単に例外を生成し、適切な例外ハンドラにリダイレクトします。ただし、VMの実行中にページ違反が発生した場合、この例外はハイパーバイザーに「転送」され、適切に処理されます。
ハイパーバイザーは、ゲストによって生成されたページフォールトを検出するため、これらのシャドウページテーブルを構築する必要があります。ゲストがそのページテーブルの1つにマッピングを書き込んでも、ハイパーバイザーはすぐには認識しないため、シャドウページテーブルはゲストの意図と瞬時に「同期」しません。したがって、ハイパーバイザーは、たとえば次の方法でシャドウページテーブルを構築します。
- ゲストはVA
0xdeadbeefのマッピングをページテーブル（メモリ内の場所）に書き込みますが、このマッピングはハードウェアによって使用されていないことに注意してください。 - ゲストが
0xdeadbeefにアクセスすると、実際のページテーブルがマッピングを追加するように更新されていないため、ページ違反が発生します - ページ違反はハイパーバイザーに転送されます
- ハイパーバイザーはゲストページテーブルを見て、シャドウページテーブルとは異なることに気付き、「ねえ、
0xdeadbeefの実際のマッピングはまだ作成していません」と言います。 - そのため、シャドウページテーブルを更新し、ハードウェアが使用する対応する
0xdeadbeef-> HPAマッピングを作成します。
前のケースはシャドウページフォールトと呼ばれます。これは、メモリ仮想化の導入によってのみ引き起こされるためです。そのため、ページ違反の処理はハイパーバイザーで停止し、ゲストOSはそれが発生したことさえわかりません。ゲストは、まだ作成しようとしていないマッピングのために、本物のページフォールトを生成する可能性もあります。ハイパーバイザーはこれらをゲストに転送して戻します。また、このプロセス全体は、ゲストの実行中に発生するeveryページフォールトがVMMを終了させ、シャドウページテーブルを最新の状態に保つ必要があることを意味します。これは高価であり、メモリ仮想化のためにハードウェアサポートが導入された理由の1つです。 （ ここ は、ネストされた、または拡張されたページテーブルの簡単な紹介です）
これの良い参考文献は この本 です。
ゲストがそのページテーブルの1つにマッピングを書き込んでも、ハイパーバイザーはすぐには認識しないため、シャドウページテーブルはゲストの意図と瞬時に「同期」しません。
正確ではありません。ゲストページテーブルは読み取り専用です。ゲストページテーブルに更新（たとえば、新しいマッピングが追加された）があると、ハイパーバイザーにトラップされ、ハイパーバイザーはそれに応じてシャドウページテーブルを更新し、ゲストと「同期」します。
参照：