~主にプログラミング関係この広告は、90日以上更新していないブログに表示しています。Cowperthwaiteによって発表され、XenGTやKVMGTとしてごく最近に実装された新しいたGPU仮想化方式、GVT-gについて見ていく。Pass-Throughhttps://www.usenix.org/conference/atc14/technical-sessions/presentation/tian昨今サーバー,クライアントサイド共にネィティブな速度のGPU仮想化が求められており、GPUに特化したインスタンスやGPUリソースをサービスとしたクラウド業者もいるがこういった背景からもGPU仮想化は非常に需要のある技術である。GVT-gはブランド名であり論文内ではgVirtと呼ばれているため以降後者で呼ぶ。pass-throughを用いてネイティブパフォーマンスの95%の速度で仮想化を行うことができる代物だ。Pass-ThroughGPUの仮想化方式には様々な物があるがどれも一長一短でさまざまな実装例がある。Forwadingはゲストサイドの、OpenGLやDirectXといったAPIをハイパーバイザ内のAPIに転送(フォワーディング)する技術でVMGL,Xen3Dなどで利用されている。優れたパフォーマンスを発揮するが変換の対応が多く互換性維持が難しいなどの問題がある。Pass-Throughは名前の通りゲストから直接物理GPUへパススルーする物だがこれは各VM間でGPUを共有することが難しくなる。Virtualizationはハイパーバイザ上に実装されたデバイスモデルを用いた完全仮想化方式である。全てのアクセスをエミュレートした場合、これは非常にオーバーヘッドが大きくなり使い物にならない。Pass-Throughはエミュレーションをごく一部(特権命令)のみにとどめ、パフォーマンスクリティカルなリソースへのアクセスは直接パススルーを行ってアクセスしている。GPUプログラミングモデルGPUの内部アーキテクチャは概ね以下のようになっている。memoryにマップされている。bufferからピクセルデータを取り出しディスプレイなどに送信する役目を持つ。bufferに送信し、GPUがそれをフェッチして実行というのがGPUの基本的なプログラミングモデルである。bufferで構成される。bufferのringを表す。bufferから構成される。bufferが占める結果となる。registerへのアクセスは相対的にかなり少ない。Pass-Throughを採用したXenベースのシステムである。現在はXenGT[1]としてXenのmainlineに統合されておりまたKVMにもKVMGTとしてごく最近に実装された。[2]アーキテクチャは以下のようになる。driverにフォワーディングされる。mediatorはハイパーコールを使って実際の物理GPUへアクセスする。上でも述べたがこの特権リソースへのアクセス回数は非常に少ないためパフォーマンスへの影響は小さい。schedulerもmediator内に実装されている。stubはXenのvMMUモジュールを拡張し特定のアドレスへのアクセスをトラップするかパススルーするか選択できるようにした物でトラップされたアクセスはmediatorへフォワーディングされる。MediatorはDom0内にカーネルモジュールとして実装。特権リソースへのアクセスを処理するためのvGPUおよびそれらvGPUのschedulerにより構成される。コンテキストスイッチがGPUはCPUの1000倍程度時間がかかり、またコア数も双方違うためCPU/GPUスケジューラは別々に実装している。BIOSはQEMUを用い、mediatorかVGA(QEMU)のどちらかにフォワーディングするような仕組みになっている。各VMは仮想GPUを持っていてこれらvGPUは物理GPUを共有する。engineスケジューラーにより決定される。bufferへコマンドが送り続けられGPUが実行する。GPUはnon-preemptiveであるためこれは非同期に行えない。bufferの処理が終わるまで待っておく必要がある。controlを使うことでタイムスライス内に終わるようなコマンド発行を行うよう最適化を行う。registerの退避、復帰を行う必要がある。現在のI/O状態を復帰となる。bufferを通して実行する。bufferに直接挿入するとゲストの別のコマンドで上書きされてしまうためである。bufferへのアクセスは直接パススルーする。この際複数のゲストがアクセスするため物理アドレス空間をパーティショニングする必要がある。memoryをパーティショニングする機能だ。これによるパフォーマンスへの影響は比較的少ないがゲスト-ホスト間のアドレス変換を行う必要がありオーバーヘッドとなる。ballooningも併用する。ballooningは、各ゲスト内のグラフィックドライバが他のVMのアドレス空間をBalooned領域として予約することで、ホストのメモリ空間と全く同じメモリレイアウトを維持し、アドレス変換の必要性をなくす。bufferが変換なしで使えるため、ゲストのコマンドを高速に実行できる。Table)を持っている。memoryアドレスはゲストの物理メモリに変換される。memoryへ変換を行うshadowingされたページテーブルである。pagingはPTEにwrite-protectをかけてフォルトを起こして書き換える典型的な方式を用いている。mediatorによりtrapされエミュレートされる。bufferへの直接アクセスもEPTを使用することでブロックする。commandの実行から保護する。bufferを使用し、直接コマンドを実行するためgVirt側で保護を行う必要がある。GPUのアクセスにも制御をかける。bufferにコマンドが送信されるとgVirtはコマンドを記録する。bufferを修正されてしまうと、次の記録が行われるまでに間にGPUに送信されてしまう。bufferへのポーリングの間に改竄されてしまう可能性がある。このためそれぞれのbufferに対して保護機構を実装する必要がある。bufferにはWrite-protectionを適用することでこれを実現する。bufferへコピーする。bufferと同期を行う。bufferはゲストからアクセス不能である。VMからの悪意のあるbuffer修正はできない。bufferはゲストからのcommandが発行されてから実際にGPUでの実行が完了するまで書き込み保護をかけることで変更不可能にする。bufferが書き換えられる恐れがない。おわりに本論文におけるgVirtは、パフォーマンスと可用性のバランスが非常にとれたGPUの完全仮想化方式でありXenGTやKVMGTとして実際に実装されている。table[4]を用いてさらに高速化を図っている。第5世代BroadwellよりGPU仮想化機構がさらに進化しており今後の発展に期待できるだろう。カーネルエクスプロイト入門記事part2です。)月別アーカイブはてなブログをはじめよう!RKX1209さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。