Feb 28, 2007

VMware Virtualization Fair 2007に参加してきたよ

赤坂プリンスで開催されていたVMware Virtualization Fair 2007に参加してきた。記事も出ているね。

ヴイエムウェア、仮想化技術のロードマップを国内で披露 : ソフトウェア&サービス - Computerworld.jp

午前中の基調講演やパネルを観て、何だよVMwareの太鼓持ちイベントかよと思い、ついつい四川飯店で坦々麺だけ食べてそのまま帰りそうになったのだが、思いとどまって午後のVMwareのテクニカルなセッションに参加してよかった。なかなか面白かった。

特にOle AgesenのTalk。ASPLOS XIIの発表内容の平易な説明+αという感じ。ASPLOSのProceedingsはACMから買わないと読めないが、VMTNでも公開されているので誰でも読める。

A Comparison of Software and Hardware Techniques for x86 Virtualization - VMTN Technical Papers Directory

かいつまんで説明するとこんな話である。

PopekとGoldbergの74年の論文に出てくる古典的なVMMの作り方というのがある。古典的VMMでは特権命令が非特権コンテキスト中で実行されたときにトラップしてエミュレート実行することで、ゲストOSの実行中に現れる特権命令を正しくハンドリングするというもの。

ただし、この方法はトラップコストやMMUのエミュレーションコストが問題となる。前者のトラップコストはx86で1000サイクル以上(CPUのパイプライン長に相関する)にもなり、トラップ頻度はワークロードにも依存するが一秒に5万回以上発生する場合もある。また、後者は、ゲストのメモリーアクセスには基本的にゲスト仮想アドレス→ゲスト物理アドレス→ホスト物理アドレスという二段の間接参照をすることになるが、ハードウェアMMUはこれをサポートしていないために何らかのソフトウェアによるエミュレーションが欠かせないということである。歴史的にはIBM System 370などはinterpretive executionと呼ばれるゲストOS実行用の動作モードを備えて古典的VMMの性能問題をハードウェアで解決してきたという経緯がある。

また、x86にはpopfというユーザモードと特権モードの両方で動作するが振る舞いの異なる命令がある。カーネルコード中のpopfが何の割り込みも発生させることなくユーザコードとして実行できてしまう場合にはトラップできないことになる。トラップできなければエミュレート実行もできないので、x86では古典的方法は利用できない。

そういうわけでVMwareではBT(Binary Translation)と呼ばれる、実行中にゲストのカーネルモードをユーザモードで実行可能なエミュレーションコードに動的に変換する手法でソフトウェア仮想化を実現している。ユーザモードではネイティブ実行(Direct Execution)し、カーネルモードへのコンテキストスイッチをVMMが検出してBTに制御を渡す。BTでは、cliなど簡単な特権命令は直接コードに変換し、コンテキストスイッチなど複雑な命令はランタイムライブラリ呼び出しに書き換える。その結果としてジャンプ命令などではジャンプ先アドレスが変わり得るので、ベーシックブロック単位でコード変換を行った後、相対アドレス、レジスタ+オフセットアドレスなどはバックパッチする。変換結果はキャッシュされるので実行のたびに変換が必要なわけではない。このあたりのテクノロジーは変換速度を優先してバイナリーコードの局所最適化などを行わないだけで、JITコンパイラとそれほど違わない。

一方でIntel VT-xやAMD SVMのようなVT、ハードウェア仮想化が注目されている。VMMが動作するroot modeとゲストOS・アプリケーションが動作するnon-root modeの間を新たに追加されたVMEnter/VMExit命令を使って遷移することができる。ただし、VTを使って実現できるのは古典的なTrap & Emulate型のVMMなので、トラップオーバーヘッドはトラップ回数に比例するという制約が依然としてある。

ベンチマークを行ってみるとBTの方が軒並み速い。これは今のところVMEnter/VMExitのコストが大きいためにBTのメリットが勝る場合が多いためだ。マイクロベンチマークで特定の命令ごとに見てみるとsyscall/sysretのようにVTでネイティブと同等の性能が出るものや、call/retのようにBTではキャッシュ上にコードをリロケートするためにジャンプ先アドレスの決定に余計なコストがかかるものではVTの方が勝る。また、特権レジスタ%cr8への書き込みのようにソフトウェアでのエミュレーションの方が圧倒的に速いものもある。

VMwareのプロダクションコードではどうしているかというと、VMware Infrastructure 3 (ESX Server 3)では、VT-x付きEM64T上でx86_64 OSをゲストとして動作させる場合のみVT-xを用い、それ以外の場合(i386ゲストの場合やAMD64)はBTを用いている。EM64T+x86_64 OSでVT-xを使っているのは、現状BTでの実行に問題があるからであってVT-xが速度的に優れているためではない。

しかし悲観することはなくて、VT付きPentium 4でのVMEnterが2409サイクルであるのに対してIntel Coreでは937サイクルまで縮小している(VMExitはそれほど改善していない)。つまり、プロセッサの世代ごとに改善されてはいる。

(続きは温泉に浸かってから書く)

(温泉から帰ってきたので続き)

ところで、BTでもVTでもMMUのエミュレーションコストの問題は解決していない。一般にゲスト仮想アドレスに対応するホスト物理アドレスを決定するには、ゲストのページテーブルをルックアップしてゲスト仮想アドレスからゲスト物理アドレス(ホスト仮想アドレス)を得、さらにホストのページテーブルをルックアップしてホスト物理アドレスを得る、という二段階のルックアップが必要になる。

これに対して、VMware Workstationの実装では、ゲストの仮想アドレスからホストの物理アドレスに対応させるシャドーページテーブルをVMMで管理する。このシャドーページテーブルは(対応アドレスがホスト物理アドレスになっている点を除いて)ゲストのページテーブルのキャッシュとなっており、ホストのハードウェアページ保護機能を用いてアクセス権限を管理する。ユーザモードのメモリーアクセスは(ページテーブルポインタを制御することで)シャドーページテーブルを経由して物理メモリアドレスにマップされるが、保護違反やキャッシュミスがあればトラップされてVMMに制御が渡される。VMMはキャッシュミスなら上述の二段階のページテーブルルックアップを行ってシャドーページテーブルにPTEを加えてから制御をゲストに戻すし(メモリアクセスをリトライして必ずシャドーページテーブルルックアップに成功する)、そうでなければトラップ情報をゲストにフォワードする。

何が問題かと言えば、キャッシュミス時のテーブルルックアップコストが大きいし、ゲストでページテーブルが更新されるたびにそれを検出してシャドーページテーブルに反映する手間がかかる。また、コンテキストスイッチが起きるとTLB同様シャドーページテーブルも無効化される必要がある(その結果キャッシュミスが増加するかプリフェッチのコストを払うかどちらかを選択することになる)。このため、メモリトランザクションやコンテキストスイッチの多いワークロードでは現状のVMware(を含む仮想化ソフトウェア)の、ネイティブ実行に対する性能はかなり劣る。

しかし、この点に関しても楽観視してよい。なぜなら、次世代のプロセッサの仮想MMUサポート(NPT/EPT)は、こうしたコストを0にするか、ハードウェアで支援するのでソフトウェアオーバーヘッドは激減する。結果的に計算集中型でないワークロードでも仮想化ソフトウェアの性能が遜色ないものになるだろう。

Talkの後にOleにEPT/NPTがある環境下でのベンチマーク結果はあるのか聞いてみた。ベンチマーク結果はない。AMD Barcelonaのpreliminaryなバージョンでの動作試験をしている。エミュレータでの実験は山ほどやっていて良い結果が得られているとのこと。

ちなみにOleがSun MicrosystemsのBurlingtonでJITコンパイラの仕事をしていた(結局西海岸で作っていたHotSpotに負けてそのグループのVM+JITコンパイラ実装はご破算になってしまったが)ときにオフィスを訪問したことがあるし、98年に東工大・富士通に滞在していた時も東工大で机を並べて仕事していた。私がすごいハッカーだと思う人の一人である。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com