Nestrilabs公開virtio-nvgpuでKVMゲストのNVIDIA GPU性能がニアネイティブに
35秒でわかる内容解説
Nestrilabsが9月24日、KVMゲスト内でNVIDIA GPUのニアネイティブなパフォーマンスを実現するオープンソースプロジェクトvirtio-nvgpuを公開した。グラフィックスAPIレベルの翻訳を省略し、カーネルドライバのABIレベルでioctlsを転送する仕組みだ。RTX 3060でのベンチマークでは、単一ゲストのベアメタル性能に対し98〜100％の描画速度を維持する。同一カードで4つのゲストを並列動作させてもトータル性能が低下しないため、マルチテナント環境やヘッドレスストリーミングの実装コストを大幅に削減できる可能性を示している。
カーネルABI転送によるニアネイティブ性能の実現
virtio-nvgpuは、ゲストOSがNVIDIAの公式ユーザーモードドライバをそのまま動作させることを可能にする。従来のvirtio-gpuではVulkanやOpenGLの呼び出しを毎フレームシリアライズするため、ホストCPUに大きな負荷がかかった。
A guest renders within 2% of the machine it is running on, and costs the same CPU.
ゲストはホストマシンに対し2％以内の差で描画し、同じCPUコストで動作する。
一方、本プロジェクトはカーネルドライバのABIレベルでioctlsを転送するため、描画ループ中のVMエグジットを約20回に抑える。ベンチマークでは、フレーム時間が2ms以上のワークロードでホストのベアメタル性能に対し98〜100％を達成した。
CPU使用率もゲストとホストでほぼ同等の0.37秒から0.40秒に収まっている。同一のRTX 3060上に4つのゲストを配置した計測では、単一ゲストの102.9fpsに対して4ゲスト合計で103.7fpsを記録した。写真ではvirtio-nvgpuのゲストとホスト間のデータフローを示す構成図が描かれている。
下図はゲストとホスト間のデータフローを示す。プロジェクトはGPLのゲストカーネルモジュールとApache-2.0のホストRustクレートに分かれ、VMM非依存の設計となっている。IOMMUによるメモリ分離は行わないが、GPU内部のMMUとドライバの信頼計算基底で安全性を担保する構造だ。
gVisor nvproxyとChromeOSの設計思想を継承
本プロジェクトの設計は、gVisorのnvproxyとChromeOSのvirtio-mediaに着想を得ている。nvproxyはコンテナ環境でNVIDIA ioctlsをホストへ転送する実績がある。virtio-mediaはGPLゲストドライバとパーミッションライセンスのデバイスクレートを併置するレイアウトの参考となった。
| ABIプロファイル | 対応ドライバ範囲 |
|---|---|
| 535.129.03 | 535.129.03〜次プロファイル |
| 580.178.04 | 580.178.04〜次プロファイル |
| 595.71.05 | 595.71.05以降 |
WSL2の/dev/dxgやIntelやAMDのDRMネイティブコンテキストと同様に、ゲスト側でコマンドバッファを生成し、境界を跨ぐ通信を最小化するアプローチを採用した。これにより、Venus方式が抱えていたシリアライズ遅延とCPU消費を解消している。
共有メモリはguest driverがmmapし、device crateがホストのファイルディスクリプタへ変換する。イベント通知用のvirtqueueが別経路で動作し、ゲストのGPU待機を効率的に醒ます仕組みだ。
VFIOパsthroughはIOMMUでデバイスをゲストに専有させるため分離が強いが、1 VMしか使用できない。本方式はマルチテナント向けに設計され、ドライバABIの互換性プロファイルでバージョンを管理する。新しいドライバは変更がないと仮定して適用される。
Hacker Newsでの評価と実運用に関する懸念
Hacker NewsなどではAmazing projectと称賛の声が上がっている。VFIOやvGPUライセンスなしで高性能なゲーミングVMやヘッドレスストリーミング環境が実現できる点に期待が集まっている。
一方で、IOMMU境界がないことによるセキュリティ面の懸念も交錯している。Smells like KVM escape to hostと指摘されるように、ホストのNVIDIAドライバがTCBに含まれる構造だ。
技術的な質問では、gVisorのnvproxyとの違いやWindowsゲストでの動作可否、ProxmoxやOpenStackでの実装可否が焦点となっている。4ゲスト以上の負荷耐性や720p以上の重いワークロードでの実測値も待ち望まれている。
現在の攻撃表面積はABIプロファイルで記述されないioctlsを拒否する仕組みで狭められている。RM_ALLOCクラスやUVMやmodeset ioctlsのフィルタリングは未実装のため、完全なハードウェア分離ではないことが強調された。
isolateサンドボックス構築と次世代ドライバ対応
現在実行中のバックエンドはVMMプロセス内でデバイス記述子を持つが、今後はゲストプロセスごとにサンドボックス化されたisolateヘルパーを起動する設計だ。このヘルパーは実際にデバイスFDを保持し、特権なしでioctlを呼び出す予定となっている。
未実装の機能にはRM_ALLOCクラスやUVMやmodeset ioctlsのフィルタリングがある。CUDA転送性能の実測や、720pを超える重い負荷、複数カードでの動作検証も今後の課題だ。
ドライババージョンの互換性は595.71.05のプロファイルが最新だが、それより新しいバージョンは変更がないと仮定して適用される。2026年9月時点でRTX A2000の615.71.09でのレンダリング確認が完了しており、次回のベンチマークではより広いハードウェア対応が期待される。
プロジェクトはBSD-3-ClauseとGPLのデュアルライセンスでプロトコル定義を公開する。記述子チェーンやメモリマッピングのトレイトを実装するだけで他の仮想化環境に統合可能だ。
用語の注釈
- IOMMU
- ハードウェアデバイスによるシステムメモリアクセスを制御し、ゲストとホストのメモリ空間を分離する機能。（参考：IOMMUとは何でしょうか？ どうすれば有効にできますか？）
出典
- Virtio-nvgpu: Near-native Nvidia GPU access inside a KVM guest（Hacker News） · 議論