Xen 3.3 Feature: Shadow 3の和訳

Xen 3.3 Feature: Shadow 3 - Xen Projectを和訳してみました。

あまりよく理解できてない部分もあるので、より正しい情報を知りたい場合は原文を参照してください。間違いや誤植のご指摘を歓迎いたします。

ちなみに、なぜこれを訳したかというと、これと同じ仕組みがKVMにも実装されようとしているからです。さすが最新技術を素早く取り込むのが得意なKVMですね;-)

Xen 3.3 Feature: Shadow 3

Shadow 3はシャドゥページテーブルの進化における次へのステップである。シャドゥページテーブルの振る舞いをよりTLBに近づけることで、ゲストOSのTLBの振る舞いをうまく利用し、ハイパーバイザがシャドゥページテーブルに変換しなければならないゲストページテーブルの変更の回数を減らしたり、それらを一まとめたりする。これによりHVMゲストの仮想化オーバヘッドを劇的に削減することができる。

シャドゥページングのオーバヘッドはHVMゲストのCPU仮想化における最も大きな要因の一つである。HVMゲストのOSは、自身に割り当てられたページの物理(マシン)フレーム番号を知らないため、彼らはゲストフレーム番号を代わりに用いる。このためハイパーバイザは、シャドゥページテーブルを用いて、(当該ページが)ゲストに使われる前に個々のゲストフレーム番号をマシンフレームへ変換する必要がある。

Shadow-1のコードに詳しい人たちならば覚えているかもしれない。ゲストページテーブルの変更がシャドゥページテーブルへ伝搬する手順は以下のようになっている。

  • すべてのゲストページテーブルへの書き込み権限を落とす。
  • ゲストがゲストのページテーブルに書き込みをしようとしたとき、それに対しout-of-sync (同期が取れていない)と印を付けて、out-of-syncリストへそのページを追加して、書き込み許可を与える。
  • 次回のページフォルトかCR3への書き込みで、out-of-syncリストから個々のページを取り出し：
    • ページを再同期する：ゲストページテーブルへの変更を探し出し、それらをシャドゥページテーブルへ反映させる。
    • 書き込み権限を落とし、out-of-syncビットをクリアする。

このやり方はLinux関してはそれなりにうまくいく一方で、Windowsにおいては悲惨であった。Windowsはデマンドページングと呼ばれる技術をかなり使っている。ゲストのページを再同期することは高価な操作であり、Shadows-1では、ページフォルトが起きる度にout-of-sync、書き込み、再同期を引き起こしていた。

次のステップ、Shadow-2ではout-of-syncメカニズムを廃止し、代わりにゲストのページテーブルへの書き込みをすべてエミュレートしていた。このエミュレーションにより、デマンドページングのための高価なunsyc-resyncサイクルを回避できる。しかしながら、これはあらゆる"バッチ"効果を打ち消してしまう。ゲストOSはそのアドレスの変更が後になるまで利用可能になると想定していないかもしれないにもかかわらず(すぐに使わないかもしれないにもかかわらず)、すべての書き込みはシャドゥページテーブルに即座に反映される。

さらに悪いことに、ページがマップされたりアンマップされるときに、Windowsはページテーブルエントリに頻繁に"transition values"を書き込む。32-bit Windowsにおけるゼロページ(ページ数が0だった場合？)のデマンドフォルトのサイクルは以下のようになる。

  • ゲストプロセスのページフォールト
  • Transition PTEへの書き込み
  • 実PTEへの書き込み
  • ゲストプロセスがページへアクセス

ベアマシンでは、これは"ページフォルト/メモリ書き込み/メモリ書き込み"に見える。メモリ書き込みは比較的高価ではない。しかしShadow-2ではこのように見える。

個々のエミュレートされた書き込みは、ハイパーバイザ内の8000サイクルのエミュレーションだけでなくVMEXIT/VMENTERも伴うため、単なるメモリ書き込みに比べてかなり高価な処理になる。

Shadow-3は、いくつかの鍵となる変更を加えたout-of-syncメカニズムを復活させる。一つ目は、L1ページテーブルのみout-of-sync状態になることを許され、すべてのL2+ページテーブルはエミュレートされることである。二つ目は、続いて起こるページフォールトは必ずしも再同期する必要がない。これによりできるようになることの一つは、"lazy pull-through"である。もしシャドゥは存在しないがゲストは存在するページでページフォルトが起きても、そのエントリをシャドゥへ伝搬させ、残りのページはout-of-sync状態のままゲストに戻るだけで良い。これは、一度ページがout-of-syncになればデマンドフォールトは以下のように見えることを意味する。

単一のゲストの値を用いることは(？)、実際のところエミュレーションより高価ではない。そのためWindowsにおけるデマンドページングでは、ハイパーバイザへの遷移を1/3に減らせる。さらに、プロセス破棄や大きなアドレス空間のマッピングのようなバッチ更新は、個々の書き込みでハイパーバイザへ/から遷移することなく次回のCR3スイッチでシャドゥへ伝搬される。

この結果、コンパイル、圧縮、データベースなどHVMゲスト内でメモリ管理を多く必要とする処理ではかなりの性能向上が期待できる。