Linux の仮想化と PCI パススルー

デバイス・エミュレーション、そしてハードウェアによる I/O 仮想化

プロセッサーが進化し、仮想化環境のパフォーマンスが向上していますが、I/O のパフォーマンスはどうなのでしょう。この記事では、I/O パフォーマンスを向上させるための、デバイス (または PCI) パススルーと呼ばれる技術を調べてみましょう。この革新的な技術のおかげで、Intel (VT-d) または AMD (IOMMU) によるハードウェア・サポートを利用して PCI デバイスのパフォーマンスを向上させることができます。

専門知識をお持ちの方へ:  皆さんの仮想化環境の中に PCI パススルーによってパフォーマンスを改善できるデバイスがある場合には、原文記事の終わりにあるコメント欄にコメント (英語) をお寄せください。

M. Tim Jones (mtj@mtjones.com), Independent author

M. Tim JonesM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。また、コロラド州ロングモン所在のEmulex Corp. の顧問エンジニアでもあります。


developerWorks 貢献著者レベル

2009年 10月 13日

My developerWorks の GReen グループに参加してください

エネルギー、効率、そして環境に関するトピックについて議論し、リソースを共有するために、My developerWorks の Green computing group に参加してください。

プラットフォームの仮想化というのは、2 つ以上のオペレーティング・システムの間でプラットフォームを共有し、より効率的にリソースを使えるようにすることです。ここで言うプラットフォームとは単にプロセッサーのみを意味するわけではなく、ストレージやネットワーキング、その他のハードウェア・リソースなど、プラットフォームを構成する他の重要な要素も含んでいます。一部のハードウェア・リソース (例えばプロセッサーやストレージなど) は容易に仮想化することができますが、ビデオ・アダプターやシリアル・ポートといった他のハードウェア・リソースは簡単に仮想化することはできません。PCI (Peripheral Component Interconnect) パススルーを利用すると、共有が不可能な場合や共有を手軽に使えない場合でも、仮想化が困難なリソースを効率的に使用することができます。この記事では、パススルーの概念、ハイパーバイザーでパススルーを実装する方法、そしてこの革新技術をサポートするハイパーバイザーの詳細について説明します。

プラットフォームでのデバイス・エミュレーション

パススルーについて説明する前に、現在のデバイス・エミュレーションがどのように動作するのか、2 種類のハイパーバイザー・アーキテクチャーにおける動作を説明します。最初のアーキテクチャーでは、ハイパーバイザーの中でデバイス・エミュレーションを行います。一方 2 番目のアーキテクチャーでは、ハイパーバイザーの外にあるアプリケーションでデバイス・エミュレーションを行います。

ハイパーバイザーの中でデバイス・エミュレーションを行う方法は、VMware ワークステーション製品 (オペレーティング・システムをベースとするハイパーバイザー) で実装されている一般的な方法です。このモデルでは、さまざまなゲスト・オペレーティング・システムによる共有が可能な、一般的なデバイスのエミュレーションがハイパーバイザーの中で行われます (仮想ディスク、仮想ネットワーク・アダプター、その他プラットフォームに必要な要素など)。この特定のモデルを示したものが図 1 です。

図 1. ハイパーバイザー・ベースのデバイス・エミュレーション
ハイパーバイザー・ベースのデバイス・エミュレーション

2 番目のアーキテクチャーは、ユーザー空間デバイス・エミュレーションと呼ばれます (図 2)。名前からわかるように、このデバイス・エミュレーションはハイパーバイザーの中に組み込まれるのではなく、ユーザー空間に実装されます。QEMU (デバイス・エミュレーションのみではなくハイパーバイザーも提供します) はデバイス・エミュレーションを提供し、また数多くの独立したハイパーバイザー (KVM (Kernel-based Virtual Machine) や VirtualBox は、ほんの一例にすぎません) から利用されます。このモデルのメリットは、デバイス・エミュレーションがハイパーバイザーとは独立しており、そのためデバイス・エミュレーションを複数のハイパーバイザーの間で共有できることです。またこのモデルでは、ハイパーバイザーにデバイス・エミュレーションによる負荷をかけることなく、随時デバイス・エミュレーションを行うことができます (ハイパーバイザーは特権モードで動作します)。

図 2. ユーザー空間デバイス・エミュレーション
ユーザー空間デバイス・エミュレーション

デバイス・エミュレーションをハイパーバイザー外のユーザー空間に移すことで、明らかなメリットがいくつかもたらされます。最も大きなメリットは、いわゆる TCB (Trusted Computing Base) に関係しています。システムの TCB というのは、そのシステムのセキュリティーにとって重要なすべてのコンポーネントのセットです。これはつまり、システムが最小になるとバグが存在する可能性が低くなり、従ってシステムは、よりセキュアになるということです。ハイパーバイザーの場合にも同じ考え方が成り立ちます。ハイパーバイザーは複数の独立したゲスト・オペレーティング・システムを切り分けて扱う必要があるため、ハイパーバイザーのセキュリティーは極めて重要です。ハイパーバイザーほどの特権が与えられないユーザー空間にデバイス・エミュレーションを移し、ハイパーバイザーのコードを少なくすることで、信頼できないユーザーに特権を悪用される可能性を低くすることができます。

ハイパーバイザー・ベースのデバイス・エミュレーションの別のバリエーションとして、準仮想化ドライバーがあります。このモデルでは、ハイパーバイザーは物理的なドライバーを含んでいます。また各ゲスト・オペレーティング・システムはハイパーバイザーを認識するドライバーを含み、このドライバーがハイパーバイザーのドライバー (準仮想化 (PV) ドライバーと呼ばれます) と連携して動作します。

デバイス・エミュレーションがハイパーバイザーの中で行われるか、あるいはゲスト VM (Virtual Machine: 仮想マシン) 上で行われるかによらず、エミュレーションの方法は似ています。デバイス・エミュレーションは、特定のデバイス (例えば Novell の NE1000 ネットワーク・アダプター) や特定のタイプのディスク (例えば IDE (Integrated Device Electronics) ドライブ) の動作を模倣することができます。物理的なハードウェアは大幅に異なっても構いません。例えば、ゲスト・オペレーティング・システムに対して IDE ドライブがエミュレーションされている状態で、物理的なハードウェア・プラットフォームでは SATA (シリアル ATA) ドライブを使用することができます。これは便利です。IDE は多くのオペレーティング・システムで一般的にサポートされており、高度なドライブ・タイプをすべてのゲスト・オペレーティング・システムでサポートする代わりに IDE を共通機能として使用できるからです。


デバイス・パススルー

上で説明した 2 つのデバイス・エミュレーションのモデルからわかるように、デバイスを共有するためには代償が伴います。デバイス・エミュレーションがハイパーバイザーで実行されるにせよ、あるいは独立した VM の中のユーザー空間で実行されるにせよ、オーバーヘッドが生じます。複数のオペレーティング・システムでデバイスを共有する必要がある場合には、このオーバーヘッドが生ずることはやむを得ません。しかしデバイスを共有する必要がない場合には、もっと効率的な方法でデバイスを共有することができます。

つまり一言で言えば、デバイス・パススルーというのは、指定されたゲスト・オペレーティング・システムに対してデバイスの分離を実現し、そのデバイスを、そのゲストのみが使用できるようにすることです (図 3)。なぜこれが便利なのでしょう。当然のことですが、いくつかの理由からデバイス・パススルーには価値があります。最も大きな理由は 2 つあり、1 つはパフォーマンス、もう 1 つは、元々共有できないデバイスを専用で使用できることです。

図 3. ハイパーバイザーの中でのパススルー
ハイパーバイザーの中でのパススルー

パフォーマンスに関して言えば、デバイス・パススルーを使用することで、ネイティブのパフォーマンスに近いパフォーマンスを得ることができます。これは、ハイパーバイザーによって競合やパフォーマンスの低下が起こるために仮想化を採用していないネットワーク・アプリケーション (またはディスク I/O 負荷が高いアプリケーション) にとって理想的です (競合やパフォーマンスの低下は、ハイパーバイザーがハイパーバイザー内にドライバーを提供することによるものであったり、あるいはハイパーバイザーからユーザー空間に対してエミュレーションを提供することによるものであったりします)。しかし特定のゲストにデバイスを割り当てられる機能は、そうしたデバイスを共有できない場合にも便利です。例えば、あるシステムに複数のビデオ・アダプターがインストールされている場合、これらのアダプターをある固有のゲスト・ドメインにパススルーすることができます。

最後に、1 つのゲスト・ドメインのみが使用する特別な PCI デバイスや、ハイパーバイザーがサポートしないためゲストへのパススルーが必要なデバイスがあるかもしれません。個々の USB ポートを切り離して指定のドメインに割り当てることができ、あるいは 1 つのシリアル・ポート (シリアル・ポート自体は共有することができません) を切り離して特定のゲストに割り当てることができます。


デバイス・エミュレーションの内部の動作

デバイス・エミュレーションが行われるようになった当初は、見えない形でデバイス・インターフェースをハイパーバイザーの内部に実装し、ハードウェアに対する仮想インターフェースをゲスト・オペレーティング・システムに提供していました。この仮想インターフェースは、必要とされるインターフェースで構成されます (デバイスを表す仮想アドレス空間 (シャドー PCI など) や仮想割り込みなど)。しかし、デバイス・ドライバーが仮想インターフェースと通信し、この通信をハイパーバイザーが実際のハードウェアに対応するように変換するため、(ネットワーク・アダプターなど、帯域幅の広いデバイスでは特に) かなりのオーバーヘッドが発生します。

Xen によって (これより前のセクションで説明した) 準仮想化手法が一般的になりました。この手法では、ゲスト・オペレーティング・システムのドライバーは、ドライバー自身が仮想化されていることを認識するため、パフォーマンスの低下を抑えることができます。この場合、ゲスト・オペレーティング・システムから見えるのはデバイス (ネットワーク・アダプターなど) の PCI 空間ではなく、ネットワーク・アダプターの API (Application Programming Interface) であり、この API によって上位レベルでの抽象化 (パケット・インターフェースなど) が行われます。この手法の欠点は、ゲスト・オペレーティング・システムを準仮想化に対応するように変更する必要がある点です。一方、長所としては、ネイティブに近いパフォーマンスを実現できる場合があります。

デバイス・パススルーを実現するための初期の試みでは、シン・エミュレーション・モデルが使われていました。このモデルでは、ハイパーバイザーがソフトウェア・ベースのメモリー管理を行います (ゲスト・オペレーティング・システムのアドレス空間をトラステッド・ホストのアドレス空間に変換します)。こうした初期の試みによって、あるデバイスを分離して特定のゲスト・オペレーティング・システムに割り当てることはできましたが、この手法には大規模な仮想化環境に必要なパフォーマンスやスケーラビリティーが欠けていました。幸いなことに、プロセッサー・ベンダーのおかげで、次世代のプロセッサーにはハイパーバイザーをサポートする命令やデバイス・パススルー用のロジックが用意され、割り込みの仮想化や DMA (Direct Memory Access) などもサポートされるようになりました。そのため、ハイパーバイザーの下で物理的なデバイスへのアクセス要求を受けてデバイスをエミュレートする代わりに、新しいプロセッサーには DMA アドレス変換やアクセス権チェックといった機能が用意されており、デバイス・パススルーを効率的に行うことができます。

ハードウェアがサポートするデバイス・パススルー

Intel と AMD は共に、新しいプロセッサー・アーキテクチャーで (ハイパーバイザーを補助する新しい命令に加えて) デバイス・パススルーをサポートしています。このオプションを Intel は VT-d (Virtualization Technology for Directed I/O) と呼び、AMD は IOMMU (I/O Memory Management Unit) と呼んでいます。どちらの場合も、新しい CPU には物理的な PCI アドレスをゲストの仮想アドレスにマッピングする手段が用意されています。このマッピングが行われる場合には、ハードウェアがアクセス (そして保護) の処理を行い、ゲスト・オペレーティング・システムは、あたかも仮想化システムでないかのようにそのデバイスを使用することができます。また、ゲストを物理的なメモリーにマッピングすることに加え、他のゲスト (またはハイパーバイザー) によるアクセスを防止するための分離機能が提供されています。Intel と AMD の CPU には、さらに多くの仮想化機能が用意されています。詳しくは「参考文献」セクションを参照してください。

大量の VM にも対応するスケーラブルな割り込みを実現する、もう 1 つの革新技術が、MSI (Message Signaled Interrupt) と呼ばれるものです。MSI では、ゲストに割り当てられた物理的な割り込み端子に依存するのではなく、より仮想化が容易なメッセージに割り込みを変換します (そのため何千もの個別の割り込みにもスケーラブルに対応することができます)。MSI は PCI のバージョン 2.2 から利用できるようになっていますが、PCIe (PCI Express) でも MSI を利用することができます (PCIe ではデバイスの数が増えてもファブリックをスケーラブルに対応させることができます)。MSI を利用すると、割り込みソースを切り分けることができるため、MSI は I/O の仮想化にとって理想的です (物理的な端子では、多重化やソフトウェアによる処理が必要です)。


ハイパーバイザーがサポートするデバイス・パススルー

仮想化機能を強化した最新のプロセッサー・アーキテクチャーを使用することによって、いくつかのハイパーバイザーや仮想化ソリューションでデバイス・パススルーがサポートされています。Xen や KVM、あるいはその他のハイパーバイザーでは、(VT-d や IOMMU を利用して) デバイス・パススルーがサポートされています。ほとんどの場合、パススルーをサポートするようにゲスト・オペレーティング・システム (ドメイン 0) をコンパイルする必要がありますが、これはカーネルをビルドする際のオプションとして指定することが可能です。ホスト VM からデバイスが見えないようにする必要もあります (これは Xen で pciback を使って行われています)。PCI には少し制約があります (例えば、PCIe から PCI へのブリッジの背後にある PCI デバイスは同じドメインに割り当てる必要があります) が、PCIe にはそうした制約はありません。

また、デバイス・パススルーをサポートする構成を libvirt (virsh も同様) を使って実現することができます (libvirt は基礎となるハイパーバイザーで使用される構成の仕組みを抽象化します)。


デバイス・パススルーでの問題

デバイス・パススルーによって発生する問題の 1 つは、ライブ・マイグレーションが必要な場合です。ライブ・マイグレーションでは、VM を停止してから新しい物理的なホストに移行すると、その途端に VM が再起動されます。これは、物理的なホストによるネットワークで多数の VM のロード・バランシングを行うための優れた機能ですが、パススルー・デバイスが使用されている場合には問題が発生します。対応が必要な 1 つの側面が PCI ホットプラグです (PCI ホットプラグに関してはいくつかの仕様があります)。PCI ホットプラグを利用すると、PCI デバイスを指定のカーネルに自由に追加したり、除去したりすることができます。これは、新しいホスト・マシン上のハイパーバイザーに VM をマイグレーションすることを検討する場合には特に、理想的です (VM をマイグレーションする際には、デバイスを除去してからそのデバイスを新しいハイパーバイザーに追加する必要があります)。デバイスがエミュレーションされている場合 (例えば仮想ネットワーク・アダプターなど) には、物理的なハードウェアを抽象化するレイヤーがエミュレーションによって追加されます。こうすることで、仮想ネットワーク・アダプターを VM の中で容易にマイグレーションすることができます (これは Linux® のボンディング・ドライバーでもサポートされています。ボンディング・ドライバーを利用すると、複数の論理的なネットワーク・アダプターを同じインターフェースに束ねることができます)。


I/O 仮想化の次のステップ

I/O 仮想化の次のステップが実際に今、起こりつつあります。例えば、PCIe では仮想化がサポートされています。サーバーの仮想化にとって理想的な仮想化概念の 1 つが、SR-IOV (Single-Root I/O Virtualization) と呼ばれるものです。この、(PCI-SIG (PCI-Special Interest Group) によって作成された) 仮想化技術を利用すると、単一ルートの複合インスタンス (この場合、1 台のサーバーで複数の VM が 1 つのデバイスを共有します) でデバイス仮想化を実現することができます。もう 1 つのバリエーションで MR-IOV (Multi-Root IOV) と呼ばれる技術は、大規模なトポロジーをサポートしています (例えば複数のサーバーが 1 つ以上の PCIe デバイスにアクセスするブレード・サーバーなど)。実際にこれらの技術を利用すれば、サーバー、エンド・デバイス、スイッチなど (デバイスの検出やパケット・ルーティングなども備えた) 任意の大規模なデバイス・ネットワークが可能になります。

PCIe デバイスは SR-IOV を利用することによって、いくつかの物理的な PCI 機能をエクスポートできるだけではなく、I/O デバイス上でリソースを共有する一連の仮想機能もエクスポートすることができます。サーバーの仮想化を単純化したアーキテクチャーを示したものが図 4 です。このモデルではパススルーは必要ありません。仮想化はエンド・デバイスで行われ、ハイパーバイザーは単に仮想機能を VM にマッピングすることでネイティブのデバイス・パフォーマンスを実現することができ、しかもセキュリティーは分離されているからです。

図 4. SR-IOV を使ったパススルー
SR-IOV を使ったパススルー

まとめ

仮想化は約 50 年間にわたって開発が続けられていますが、ようやく今、I/O の仮想化に対して大きな関心が寄せられるようになっています。商用プロセッサーが仮想化をサポートするようになったのは、ほんの 5 年ほど前からです。つまり私達は今、プラットフォームと I/O の仮想化に関する転換点にあります。また、クラウド・コンピューティングなどの今後さらに発展していくアーキテクチャーの重要な要素として、仮想化は明らかに、その進化を注視する価値のある興味深い技術です。いつものことですが、これらの新しいアーキテクチャーのサポートに関して Linux は最前線にあり、最新のカーネル (2.6.27 およびそれ以降) では、これらの新しい仮想化技術をサポートするようになっています。

参考文献

学ぶために

  • VTdHowTo のウィキでは、VT-d によるデバイス・パススルーを Xen で使用する方法の詳細が説明されています。Xen のサイトには豊富な情報が用意されています。
  • Waikato Linux User's Group のサイトには、Xen ハイパーバイザーで PCI パススルーを実現するための詳細が説明されています。
  • Libvirt にはハイパーバイザーを管理するアプリケーションを作成するための管理 API が用意されています。libvirt の Web サイトのウィキでは、ハイパーバイザー間で VM を移行するために何が必要かについて説明しています。
  • Fedora プロジェクトに関する Intel の資料には、Linux VM のライブ・マイグレーションの話題がデバイス・パススルーの観点から解説されています。
  • PCI-SIG の Web サイトから SR-IOV 技術とMR-IOV 技術の仕様をダウンロードしてください。これらの技術によって、単一ルート (単一ホスト) またはマルチルート (ブレード・サーバーなどの複数ホスト) のトポロジーで I/O の仮想化を実現することができます。これらの技術は PCI-SIG による成果です。
  • 仮想 Linux」(developerWorks、2006年12月) を読み、他の仮想化ソリューションについて学んでください。また、KVM と QEMU の詳細を学ぶために、「Linux カーネル仮想マシンを探る」(developerWorks、2007 年 4 月) と「QEMU によるシステムのエミュレーション」(developerWorks、2007年9月) を読んでください。
  • developerWorks の Linux ゾーンには、Linux 開発者のための資料が他にも豊富に用意されています。また最も人気の高かった記事とチュートリアルの一覧もご覧ください。
  • developerWorks に掲載されているすべての「Linux のヒント」シリーズの記事と Linux チュートリアルを参照してください。
  • developerWorks の Technical events and webcasts で最新情報を入手してください。

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を利用して、皆さんの次期 Linux 開発プロジェクトを構築してください。

議論するために

  • My developerWorks community に参加してください。個人プロファイルとカスタムのホームページを利用することで、皆さんの関心事項に合わせて developerWorks を調整することができ、また他の developerWorks ユーザーとやり取りすることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=445397
ArticleTitle=Linux の仮想化と PCI パススルー
publish-date=10132009