拡張可能なホストコントローラインターフェース

OHCIおよびUHCIコントローラはUSB 1速度のデバイス（1.5  Mbit/sおよび12  Mbit/s）のみをサポートし、EHCIはUSB 2デバイス（480  Mbit/s）のみをサポートします。

xHCIアーキテクチャは、 単一のドライバスタックで、SuperSpeed（5Gbps）を含むすべてのUSB速度と将来の速度をサポートするように設計されています。

USBが最初に開発された1995年当時は、PCに現れつつあったPS/2、シリアルポート、パラレルポート、ゲームポートなどのコネクタの増加を抑えるためにデスクトッププラットフォームを対象としており、ホストの消費電力は当時重要な考慮事項ではありませんでした。それ以来、モバイルプラットフォームが主流となり、バッテリーによって消費電力が重要な考慮事項となりました。従来のUSBホストコントローラ（OHCI、UHCI、EHCI）のアーキテクチャは、USB上で実行されるトランザクションの「スケジュール」がホストメモリ内のソフトウェアによって構築され、ホストコントローラのハードウェアがスケジュールを継続的に読み取り、データが移動されない場合でも、USB上でどのトランザクションをいつ実行する必要があるかを判断するという点で非常に似ていました。さらに、デバイスからの読み取りの場合、読み取るデータがなくても、スケジュール間隔ごとにデバイスがポーリングされました。

• xHCIはホストメモリに基づくUSBトランザクションスケジュールを排除し、USBデータ転送がない場合にはホストメモリのアクティビティをゼロにすることを可能にします。
• xHCI は、USB 3.0 以降のデバイスが読み取り可能なデータがあるときにホストコントローラに通知できるようにすることで、定期的なデバイス ポーリングの必要性を減らし、割り込みトランザクションを使用する USB 2.0 および 1.1 デバイスのポーリング管理を CPU 駆動の USB ドライバから USB ホストコントローラに移行します。EHCI、OHCI、および UHCI ホストコントローラは、変更する必要がなく、送信する割り込みがないデバイスがない場合は、CPU のポーリングを自動的に処理しますが、いずれもコントローラのスケジュールを設定するために CPU に依存しています。^{[ 3 ] [ 4 ] [ 5 ]}割り込みトランザクションを使用する USB デバイスが送信するデータを持っている場合、xHCI ホストコントローラは割り込みを送信して、処理する必要のある USB 割り込みトランザクションがあることを CPU に通知します。CPU は USB バスのポーリングを管理する必要がなくなったため、低電力状態により多くの時間を費やすことができます。
• xHCIは、実装においてUSB 2 LPM、USB 3 U1およびU2状態、HERD、LTM、ファンクションウェイクなど、すべての高度なUSB 2および3電源管理機能のサポートを義務付けてはいませんが、これらの機能はxHCIのすべての利点を実現するために必要です。

従来のUSBホストコントローラアーキテクチャは、仮想化環境に適用すると深刻な欠点があります。従来のUSBホストコントローラインターフェースは、比較的単純なハードウェアデータポンプを定義しており、バス全体の管理（帯域幅割り当て、アドレス割り当てなど）に関連する重要な状態は、ホストコントローラドライバ（HCD）のソフトウェアにあります。I/Oインターフェースレジスタを複製する標準的なハードウェアI/O仮想化技術を従来のUSBホストコントローラインターフェースに適用しようとすると、仮想マシン（VM）間で管理する必要のある重要な状態がハードウェアで利用できないため、問題が発生します。xHCIアーキテクチャは、この重要な状態の制御をハードウェアに移行し、VM間でのUSBリソース管理を可能にします。xHCI仮想化機能には、次の機能も含まれています。

• 個々のUSBデバイスを（バストポロジー上の位置に関係なく）任意のVMに直接割り当てる
• 実行時のVM間通信を最小限に抑える
• ネイティブUSBデバイス共有のサポート
• PCIe SR-IOV（シングルルートI/O仮想化）のサポート

EHCIはOHCIまたはUHCIコントローラを「コンパニオンコントローラ」として利用します。USB 2デバイスはEHCIスタックを介して管理され、EHCIのポートロジックにより、低速またはフルスピードのUSBデバイスを「コンパニオン」のUHCIまたはOHCIコントローラのポートにルーティングできます。この場合、低速またはフルスピードのUSBデバイスはそれぞれのUHCIまたはOHCIスタックを介して管理されます。たとえば、4つのUSB「標準A」コネクタを備えたUSB 2 PCIeホストコントローラカードは、通常、システムソフトウェアに対して1つの4ポートEHCIコントローラと2つの2ポートOHCIコントローラを提供します。高速USBデバイスが4つのコネクタのいずれかに接続されると、そのデバイスはEHCIコントローラの4つのルートハブポートのいずれかを介して管理されます。コネクタ1または2に低速または高速USBデバイスが接続された場合、それらのデバイスは管理のためにいずれかのOHCIコントローラのルートハブポートにルーティングされます。また、コネクタ3または4に接続された低速および高速USBデバイスは、もう一方のOHCIコントローラのルートハブポートにルーティングされます。高速USBデバイスと低速および高速USBデバイスのグループに対して、EHCIがそれぞれ別のホストコントローラに依存しているため、EHCIドライバとOHCI/UHCIドライバの間で複雑な相互作用と依存関係が生じます。

• xHCIアーキテクチャは、コンパニオンコントローラとその個別のドライバスタックを不要にします。
• これまでドライバが行っていたスケジュール、帯域幅管理、USBデバイスアドレス割り当て機能をxHCIハードウェアに組み込むことで、xHCIのソフトウェアスタックをよりシンプルで軽量、かつ低遅延にすることが可能になります。

ストリームのサポートは、主に USB を介した高性能ストレージ操作を可能にするために、USB 3.0 SuperSpeed 仕様に追加されました。従来、USB エンドポイントとシステム メモリ内のバッファの間には 1:1 の関係があり、ホスト コントローラがすべてのデータ転送の指示のみを担当していました。ストリームはこのパラダイムを変更し、1 対多の「エンドポイントからバッファへ」の関連付けを提供し、デバイスがホスト コントローラにどのバッファを移動するかを指示できるようにしました。USB ストリーム エンドポイントに関連付けられた USB データ転送は、他のバルク エンドポイントと同様に xHCI によってスケジュールされますが、転送に関連付けられたデータ バッファはデバイスによって決定されます。

• xHCI USBストリームのサポートにより、1つのエンドポイントに最大64Kのバッファを関連付けることができます。
• xHCI Streamsプロトコルのサポートにより、USBデバイスはエンドポイントがスケジュールされた際に、xHCIが転送するバッファを選択できます。

xHCIアーキテクチャは、1～255個のUSBデバイスと1～255個のルートハブポートをサポートできる、高い拡張性を持つように設計されています。各USBデバイスは最大31個のエンドポイントを定義できるため、255個のデバイスをサポートするxHCIは、合計7,906個の個別のエンドポイントをサポートする必要があります。従来、エンドポイントに関連付けられた各メモリバッファは、物理メモリブロックのキューで記述され、キューの状態を定義するために、ヘッドポインタ、テールポインタ、長さ、およびその他のレジスタが必要です。キューの状態を定義する方法は多数ありますが、各キューに32バイトのレジスタ空間があると仮定すると、 7,906個のキューをサポートするには、約256KBのレジスタ空間が必要になります。通常、システムに接続されるUSBデバイスは少数であり、平均してUSBデバイスは3～4個のエンドポイントをサポートし、そのうちのサブセットのみが同時にアクティブになります。xHCIは、エンドポイントコンテキストデータ構造として、システムメモリにキューの状態を保持します。コンテキストは、xHCI によってキャッシュされ、エンドポイントのアクティビティに応じて「ページイン」および「ページアウト」されるように設計されています。そのため、ベンダーは、自社製品で想定される実際の使用モデルに合わせて、サポートするアーキテクチャ上の制限ではなく、内部の xHCI エンドポイント コンテキスト キャッシュ スペースとリソースを拡張できます。理想的には、通常の使用条件下では xHCI によるコンテキスト ページングが発生しないように内部キャッシュ スペースが選択されます。また、USB エンドポイントのアクティビティはバースト的になる傾向があります。つまり、任意の時点で多数のエンドポイントがデータ転送の準備ができているかもしれませんが、実際にデータを転送しているのはその一部だけです。たとえば、ユーザーがデスクから離れている場合、マウスの割り込み IN エンドポイントは数時間データを転送しない可能性があります。xHCI ベンダー固有のアルゴリズムは、この状態を検出し、他のエンドポイントがビジー状態になった場合に、そのエンドポイントをページアウト候補にすることができます。

• xHCIアーキテクチャでは、サポートするUSB​​デバイス、ポート、割り込みベクタなどの最大数を大きく設定できますが、実装においては、マーケティング要件を満たすために必要な数だけを定義すれば十分です。例えば、ベンダーはタブレット向けxHCI実装において、サポートするUSB​​デバイスの数を16個に制限することも可能です。
• ベンダーは、xHCIのアーキテクチャ機能を活用して、ターゲットとする利用モデルに合わせて内部リソースを拡張できます。たとえば、ユーザビリティテストの結果、タブレットユーザーの95%が4台を超えるUSBデバイスを接続することはなく、各USBデバイスが通常4つ（またはそれ以下）のエンドポイントを定義することが判明した場合、16個のエンドポイントコンテキストの内部キャッシュにより、通常の状態ではエンドポイントコンテキストのページングによるシステムメモリのアクティビティが発生しないことが保証されます。

xHCI仕様では、「正誤表」ファイルを使用して、特定のリリースに対する更新と明確化を定義します。正誤表ファイル内の変更は、各リリースに蓄積されます。具体的な変更の詳細については、関連する正誤表ファイルを参照してください。xHCI正誤表ファイルで定義されている変更のほとんどは、明確化、文法やスペルの修正、追加の相互参照などであり、ドライバの実装には影響しません。アーキテクチャ上の変更と判断された変更では、特定の機能がxHCI実装でサポートされているかどうかを判断するためにCapabilityフラグを使用し、その機能を有効にするためにEnableフラグを使用します。