【レポート】IDF Fall 2006 - PCI Express Update (9) I/O Virtualization - その3 | パソコン

【レポート】

IDF Fall 2006 - PCI Express Update

9 I/O Virtualization - その3

大原雄介　 [2006/10/18]

さて、Multi-Rootは、1つのマシンから見れば単なる1つのDevice Treeとして見えなければならない(Photo30)。このため、Multi-Rootのインプリメントはもっぱら、SwitchとEndpointに集約される形になる(Photo31)。まぁ当然インプリメントは難しい事になる(Photo32)。あくまでもアプリケーションには影響がないようにするためには、Root Complexそのものには手をつけられないから、様々な制御はPCI Express Switch(や場合によってはEndpoint)で行う事になる。この制御を、既に存在する管理ツールとどうマイグレーションするか、が大きなチャレンジという事になる。


Photo30:先のPhoto27の図とあわせてもらうと判りやすいが、左端のHostからみると、自分の下にこの図の様なDevice Treeが構成されているように見えることになる。	Photo31:厳密に言えば、各Root Complexは、それぞれ独自のVirtualization(つまりSingle-Root I/O Virtualization)をインプリメントしており、これがMulti-Root I/O Virtualizationに乗るという構造になる。

Photo32:これは設計目標であって、これがどこまで実現できるかはちょっと謎。

実際のインプリメントについて、まずEnd-Pointに関しては複数のVirtual Planeの実装が必要になる(Photo33)。もっと面倒なのはSwitchの方で、これがMulti-Root I/O Virtualizationの要になる部分だけに、インプリメントはかなり面倒になると見られる(Photo34)。具体的に言えば、例えばResetのハンドリング(Photo35)とかHot Plug(Photo36)などである。


Photo33:各End-pointは、複数のRoot Complexからのリクエストを個別にハンドリングできなければいけない。実はこの機能はSingle-Root I/O Virtualizationでも必要になるのだが、両者を同じ様に取り扱えるのかは現時点では不明である。概ね共通な処理は多いが、完全に一緒とは行かない気がする。	Photo34:もっとも、要するにネットワークで言うところのL3以上のスイッチと同じ、といえば同じかもしれないが。Virtual LANを構成するようなものだと考えてもいいだろう。

Photo35:リセットに関しては、前回のIDFレポートでもFLR(Function Level Reset)という形でちょっと触れている。例えばあるブレードサーバがリブートしてしまったとき、当然リセット信号が配下のデバイスに伝達される訳だが、そのデバイスが他のRoot Complexからのリクエストを受けてI/O実行中だと、いきなりリセットを実行するわけには行かないので、リセット要求を保留する仕組みが必要になる。もっとも、留保してフルリセットを掛けるべきか、それともそのRoot Complex向けのデータのみを初期化するか、とかはケースによって異なるわけで、このあたりをどう判断するかは難しいところ。

Photo36:Hot PlugなりUnPlugなりのイベントが発生した場合、その通知はスイッチに内蔵されたvHPC(Virtual Hot Plug Controller)がハンドリングして所定のRoot Complexに伝達するという形になる。ただこれが、単に各Root ComplexがどのEnd Pointを見ているかだけで判断してよいのか、EndPoint側の特徴に応じてどう伝播させるかを決めるメカニズムを用意するか、など議論は続く。