ページテーブルエントリを作成する際の挙動・メモリレイアウトについて

[keisuke713]

概要

自分の認識が合っているか確認させて頂きたいのですが、
こちらの処理は本書p71図6.4の1段目のページテーブル内のページテーブルエントリを作成する箇所に該当していて、こちらの処理では PTE_PADDR が1段目のページテーブルエントリから2段目のページテーブルのメモリを算出している。であっていますでしょうか？？
また各ページテーブルエントリがp.72の図6.5が示すように物理アドレスでなく物理ページ番号を保持している理由は各ページ(テーブル)内でのオフセットは仮想アドレスのそれぞれ先頭10ビット・真ん中10ビット・下位12ビットが持っているから。で解釈合っていますでしょうか？

開発環境

No response

ソースコードのURL

No response

[nuta]

ページテーブルを辿る処理についてはどちらも正しいです 💯 PTE_PADDRは物理ページ番号から物理メモリアドレスへの変換をするマクロです。

なぜエントリが物理ページの先頭アドレスではなく、物理ページ番号を持っているのかは（おそらく）エントリ中のビット数の節約です。先頭アドレスをページの固定長を割ったより小さな数値を持っておけば良いので、節約できたところに他の情報（有効ビット・書き込み可ビットなど）を埋め込めます。

「おそらく」とはぐらかしたのは、CPUの設計次第で「物理アドレスをもつページテーブルエントリ」というのも実現できるはずだからです。ただ、x86-64含め基本的には物理ページ番号を持っていることが一般的だと思います。

[keisuke713]

なぜエントリが物理ページの先頭アドレスではなく、物理ページ番号を持っているのかは（おそらく）エントリ中のビット数の節約です。先頭アドレスをページの固定長を割ったより小さな数値を持っておけば良いので、節約できたところに他の情報（有効ビット・書き込み可ビットなど）を埋め込めます。

なるほど、確かに節約できるならして他の情報を埋め込む方が効率が良いですね。

[keisuke713]

もう一点だけ確認させてください。
こちらの処理でuaddr でなく tmp_page の仮想アドレスを介して物理アドレス( paddr )にセグメントの内容を読み込んでいるのは uaddr の値はvmのページテーブルに登録されていない値でページフォルトが起きてしまうから。と解釈したのですが合っていますでしょうか？

[nuta]

なぜならuaddrの仮想アドレスは、そのコードを実行しているVMサーバのアドレス空間ではなく、ページフォルトが発生したプロセスのアドレス空間内を指しているためです。

そのため、uaddrにマップされている同じ物理ページにVMサーバからアクセスできるように、一旦VMサーバのアドレス空間の一部 (tmp_page) にその物理ページをマップしています。

[keisuke713]

認識合っていそうでよかったです！
ありがとうございます。