ここまで解説してきたような仕組みを使う事で、xHCIでは複数の転送速度のDeviceを混在させる形で、まとめて管理を行うことが出来る。Specificationではこれに続き、xHCI ControllerのInitializationから始めてDeviceのAttach/Detach、各Transfer RingへのOperationやSlotのEnable/Disable、Power Managementまで24種類に分けてOperationの詳細を定義しており、更にRegisterの構造やMemory上に展開するデータ構造、Virtualizationまでを細かく定義しているが、こうした構造を必要とする読者は、自分でxHCI Controllerを作成する人か、もしくはxHCIのBus Driverを書く人のみで、通常のUSB Deviceを作る人やアプリケーションを書く人にはまず縁が無いと思われるのでここでは割愛する。
大雑把に言っても、xHCIの構造は従来までと全く異なっている事が改めてご理解いただけたかと思う。ここまで違えば、既存の資産を生かすといった方向にはならない(というか、出来ない)のは明白で、なるほど殆ど新規に作り直しという事になったのも無理はない。
xHCIの設計目標は345回で触れたとおりだが、この目標の実現にこうした構造が選ばれた理由を考えてみると、なかなか興味深い。まずあるのは仮想化の対応である。例えばUSB HDDを複数のVMから同時にアクセスする(こういう使い方はどうか? という議論は勿論あるのだが)なんてケースでは、当然複数のリクエストがVM経由で特定のDeviceに集中することになる。USB Controllerにぶら下がるDevice数が少ないと問題ないが、Device数が多くなると全体で一つのキューでラウンドロビン、というUSB 2.0までのやり方は非常に遅くなる。またUSB 3.0ではAsynchronous Transferがサポートされるが、全体でまとめてラウンドロビンの方式ではこれを管理するのが難しい。というわけで、少なくともUSB 3.0ではDevice毎に異なるキューで管理するのが一番好ましいことになる。で、USB 3.0が個別管理するのであれば、USB 1.1/2.0のDeviceにしても、やはり個別にキューを設けたほうが好ましい。もっと言えば、あるDeviceが同時にUSB 2.0とUSB 3.0で接続されることは無く、ただしUSB 3.0で繋がっていたものが途中でUSB 2.0で繋ぎなおされたり、逆にUSB 2.0からUSB 3.0に繋ぎなおされたりというケースは想定される。であれば、個々のDeviceのキューは転送速度そのものとは切り離して管理するほうがむしろわかりやすい。Virtualizationの対象はUSB 3.0だけとは限らないから、この観点からもUSB 2.0以前もやはり個別キューにしたほうが好ましいと言える。
この時点でxHCIは「沢山のキューを持ち、そのキューをコントローラが自律的に判断しながら転送する」という構図が必然になってしまったと言える。もっと中央集権的に、全てを一つのキューで管理するといった方法も勿論物理的には可能だろうが、その場合はテーブルを舐めるだけで一苦労になるだろうし、テーブルサイズそのものも肥大化する。現行のxHCI自身はState Machine的なものは入っていてもMCUそのものは統合されていない(というか、MCUを統合しなくても実装できる)構造になっているが、巨大テーブルを扱うとMCUか何かを搭載するか、ECHIまでと同じようにHost側のCPUがそうしたデータ構造を扱う事が必要になってくる。が、Host側が扱うのはHost側の負荷を減らしたいという設計目標に反するし、MCUを入れるとなると相当高速のMCUを搭載しないと(絶対性能はともかく)処理のレスポンスが間に合わない。当然これはダイサイズの肥大化や消費電力の増加を招き、結局高価なソリューションになってしまう恐れがある。そんな辺りを考えると、実装そのものはかなり手間が掛かりそうだが、製品のコストや消費電力を抑えることが可能な現在のxHCIの方が賢明である、という判断を下したのであろう。
ただこれが難易度の高いソリューションである、というのは現時点でもHostとしてCertificationを受けたものが2製品しかない、ということでも伺える。ちなみにその2製品とはμD720200とμPD720200Aで、何の事はなくどちらもルネサスエレクトロニクス(というか、旧NECエレクトロニクス)の製品のみである。
(続く)
