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