最初の質問への回答: はい、そうです。これが基本的に仮想メモリの仕組みです。
では、ハイパーバイザーが MMU とゲスト OS の間で実行されている場合に何が起こるか見てみましょう。パフォーマンスのために、ハイパーバイザー (タイプ 1またはタイプ 2のいずれか) は、各ゲスト OS メモリ アクセスでのトラップを回避しようとします。アイデアは、ゲスト OS が MMU を管理できるようにすることです。1 つは x86 用、もう 1 つは PowerPC 用の可能な実装について詳しく説明します。
x86 では、Intel のマニュアル 3Bから:
27.3.2 ゲストおよびホストの物理アドレス空間
メモリ仮想化は、ゲスト ソフトウェアに、ゼロから始まり、ゲスト仮想プロセッサの物理アドレス幅によってサポートされる最大アドレスまで拡張される、連続したゲスト物理アドレス空間を提供します。VMM は、ゲストの物理アドレスからホストの物理アドレスへのマッピングを利用して、ホスト メモリ内のゲスト物理アドレス空間のすべてまたは一部を特定します。VMM は、ホスト システムの物理メモリ マップと、VMM によってゲストに公開される仮想化された物理メモリ マップを考慮に入れることができる、このマッピングのポリシーとアルゴリズムを担当します。
VMMPDBRは VM の現在のベース アドレスを認識しています (これはレジスタPDBRに保持されています)。CR3CR3VM_EXIT が発生します。VMM は、ゲスト OS に代わってリアル ページ ディレクトリを維持できます。つまり、ゲスト OS がそのページ ディレクトリを変更して論理アドレス A を物理アドレス B にマップすると、VMM はこれをトラップし、A を B にマップする代わりに、A を C にマップします。 #PF の場合、MMU を介して C に問題なくルーティングされます。このアプローチの悲しい部分は、ゲストが A を B にマップしたと信じているが、実際には A が C にマップされているため、ゲストが以前に A をマップした場所を読み取る場合に備えて、VMM は仮想ページ ディレクトリを維持する必要があることです。 VMM はこの読み取りアクセスをトラップし、A が B にマップされていると言う代わりに、A が C にマップされていることをゲストに返します。
27.3.3 ブルートフォースによる仮想メモリの仮想化
これを行うための単純な方法は、すべてのゲストがアドレス変換ハードウェア トラップにアクセスしようとするときに、そのような操作を適切にエミュレートできる VMM にアクセスするようにすることです。ページ ディレクトリとページ テーブルへのアクセスも確実にトラップされるようにする必要があります。これは、これらのメモリ内構造を従来のページベースの保護で保護することによって行うことができます。VMM は、そのベース アドレスが CR3 にあり、VMM が CR3 への変更の制御を受け取るため、ページ ディレクトリを見つけることができるため、これを行うことができます。ベースアドレスがページディレクトリにあるため、ページテーブルを見つけることができます。
PowerPC では、Intel のようなページ ディレクトリのハードウェア テーブル ウォークはありません。TLB の各変更は、通常はカーネル メモリ マネージャーからの命令によって行われます。ここでも、簡単なアイデアは、ゲストが TLB にアクセスするたびにトラップすることです (たとえば、ゲストがtlbwe命令を実行したときに VM を終了させるように設定します。注: tlbweTLB にエントリを書き込みます)。VMM 内に入ると、ハイパーバイザーはトラップ命令をデコードし、その動作をエミュレートしますが、A を B にマッピングする代わりに、A を C にマッピングし、TLB に直接マッピングします。ここでも、ゲスト OS が TLB の内容を確認したい場合に備えて、VMM は仮想 TLBを維持する必要があり、以前に TLB に入れたと思われるものを返します。
結論として、一部のハードウェア機能はゲストの物理メモリの仮想化に役立ちますが、一般に、ゲストの物理メモリからホストの物理メモリへの効果的なマッピングを管理するのは VMM 次第です。