ユニプロセッサ PC での APIC ベースの割り込みサブシステムの実装の重要性について

トピック

	将来に向けての APIC の重要性
	はじめに
	技術的な相違点
	割り込みを共有するべきではない理由
	歴史的要因
	業界の開発に関する問題
	パートナーの皆様へ
	その他のリソース

将来に向けての APIC の重要性

PC 業界では、マルチプロセッサ システムに対しては、8259 Programmable Interrupt Controllers (PIC) では不十分であり、Advanced Programmable Interrupt Controllers (APIC) が必要であると広く認識されています。しかし、ユニプロセッサ PC プラットフォーム (特にモバイル システム) に対する APIC の重要性は、それほど認識されていません。

この記事では、ユニプロセッサ システムにとってなぜ APIC が重要なのかについて説明します。Microsoft Windows ロゴ プログラムでは現在、モバイル システムを除くすべてのシステムに対して APIC が必須とされています。今後、Windows ロゴ プログラムでは、モバイル システムを含むすべてのシステムにおいて APIC が必須となる予定です。

ページのトップへ

はじめに

APIC が有用であるのは、下記の理由によります。

これらの点については、下記のセクションでさらに詳しく説明します。

ページのトップへ

技術的な相違点

従来の 8259 割り込みコントローラは、重大なレガシ問題になる可能性があります。IRQ 0、1、2、6、8、12、13、14、および 15 は、レガシ デバイスによって使用されます。さらに、レガシ デバイスが存在しなくても、これらの IRQ では、レガシ ソフトウェアまたはファームウェアによる要求が頻繁に発生します。IRQ 3 および 4 でも、この種の問題が発生する場合があります。

これらのレガシ問題の結果、IRQ 5、7、9、10、および 11 のみが、一般的なコンピュータでの通常どおりの使用が可能であることになります。オーディオ ハードウェアは、ほとんどの場合 IRQ 5 を使用するようにプログラムされています。これにより、残り 4 つの IRQ のみをその他のデバイスが使用できることになります。今日のほとんどのコンピュータでは、割り込みをプログラムされたデバイスが、4 つをはるかに超えて、多数使用されています。たとえば、この記事を書くために使用したシステムでは、下記のデバイスが使用されています。

レガシでは、下記のような非共有カテゴリがあります。

これは、システム内のすべてのデバイスが IRQ を共有できると仮定した場合、このシステムでは、使用可能な IRQ ごとに、最高で平均約 3 つのデバイスが割り当てられるということです。このコンピュータには CardBus スロットが 4 つあるという点に留意してください。それは、ユーザーがいつでも、それらのスロットのうちの 1 つに対して、2 つの非共有 IRQ を必要とする PCMCIA デバイスをプラグインする可能性があるということです。4 つの使用可能なスロットのうち 2 つにカードをプラグインするだけで、コンピュータは、すべてのデバイスを同時に処理不可能な状態になります。

また、このコンピュータの PCI デバイスが割り込みコントローラに直接接続されていないことにも注意してください。サウス ブリッジには、4 つの IRQ ステアリング デバイスがあり、それぞれが PCI 割り込みを複数の IRQ に割り当てることができます。これにより、コンピュータの設計者は、前の例の 11 個の PCI デバイスを使用し、それらのデバイスのいくつかを割り込みコントローラに到達する前にワイヤ OR 接続することを余儀なくされます。その結果、それらのデバイスに割り当てられる IRQ の数は 4 つに減少します。

APIC 割り込みサブシステムでは、特定のコンピュータで必要な数だけ IRQ を持つことができます。一般に、チップセットのベンダは、I/O APIC がそれぞれ 24 の IRQ を持てるように設計します。また、ほとんどの場合、クライアント コンピュータには I/O APIC が 1 つだけ搭載されています。これにより、各 PCI デバイス専用の IRQ が割り当てられることが十分に保証され、ユーザーが複数の PCMCIA デバイスをインストールした場合のみ共有が必要になります。

APIC ベースのシステムでは、各 PCI デバイスを I/O APIC の割り込みコントローラ入力へ直接ルーティングできます。一方、I/O APIC へ直接ルーティングできる場合や、IRQ ステアリング デバイスを通じてルーティングできる場合もあります。理想は、チップセットがより多くのステアリング デバイスを内蔵できるようにすることです。これまでに OEM では、少なくとも単一プロセッサ システムに関しては、余分なコストをかけてまで、チップセットの外部にステアリング デバイスを搭載したことはありませんでした。

多く場合、ラップトップ コンピュータにおいて使用可能な IRQ の数は、非常に限られています。そのため、出荷時の状態で COM ポートまたはその他の内部デバイスを無効にしておくことによって、PCMCIA デバイスが使用する IRQ を確保できるようにしています。これは、ドッキング ステーションを使用するコンピュータにおいて、好ましい状況とは言えません。一般的にラップトップ コンピュータは、エンド ユーザーがモデムを無効にして COM ポートなどを有効にできる、複雑なユーティリティを備えています。このような方法で IRQ の不足を補うと、ソフトウェアがする必要のあることやソフトウェアができることを、可能な限りユーザーがハードウェアに対してしなければならなくなるので、システムの使いやすさが損なわれます。

最後に、8259 割り込みコントローラにより、スプリアス割り込みの処理方法に従って、割り込みが実際に破棄されることがあります。APIC では、この問題が発生する可能性は、より低くなります。

ページのトップへ

割り込みを共有するべきではない理由

PIC ベース システムにおいて、割り込みの共有は、システム内のすべてのデバイスまたはほとんどのデバイスが機能できるようにする唯一の方法です。Microsoft は、割り込みを正常に共有できるハードウェアおよびドライバをベンダが設計するために役に立つように、詳細情報をホワイト ペーパーや DDK などの情報源で提供しています。ただし、割り込みの共有は、現在の PIC ベース PC での割り込みの問題に対する十分な解決策とは言えません。割り込みの共有は、多くの PC プラットフォームで必要とされてきましたが、やむを得ず必要とするものであると考えなければなりません。割り込みの問題に対する本来の解決策は、APIC ベースのシステムに移行することです。

IRQ の不足による問題は、Windows が、特定のシステムですべての PCI デバイスを 1 つまたはほんの少数の IRQ に割り当てて、残りの IRQ を他のデバイスに割り当てることができるとしても解決されません。たとえば、ドライバ開発に関するニュースグループをざっと見てみると、多くのハードウェア設計では、割り込みの待機時間について、非常に微妙な問題として扱われていることがよくわかります。この微妙な問題に対処するために、多くのハードウェア ベンダは、自社のデバイスで割り込みの共有が絶対に起こらないようにする方法を見つけたいと考えます。これらのデバイスに関しては、APIC システムでの実行が、唯一の選択肢です。

下記の例は、割り込みの共有に関連する特定の技術的な問題を明確にするのに役立ちます。デバイスが割り込みを共有しなければならない場合、IRQ のトリガによって下記の一連のイベントが発生します。

レベルトリガ (PCI) の場合 :

エッジトリガの場合 :

エッジトリガ デバイスでは、その IRQ が割り当てられたいずれかのデバイスによる割り込みが発生するたびに、ISR のチェーン全体を繰り返す必要があることに注意してください。それは、未処理の割り込みが割り込みコントローラで認識された後、デバイスがそれを再びアサートする保証がないからです。

このペーパーの執筆に使用しているコンピュータでは、11 個のデバイスが IRQ 11 を共有しています。そのうちの 1 つが割り込むと、オペレーティング システムは、ISR チェーンの先頭から開始し、割り込んだデバイスを発見するまで各デバイスを調べます。各ハードウェアへのアクセスには数マイクロ秒が費やされる可能性があり、各 ISR はそのデバイスに数回 (またはそれ以上) アクセスする場合があります。その結果、ハードウェアへのアクセスによって、コンピュータ上のその他すべてのタスクの処理に遅延が生じます。割り込みが発生するときにはいつも、1 ミリ秒ほどの遅延を伴う可能性があり、その間は他の処理を実行できなくなります。そのため、オーディオ デバイスなどの、多くの処理時間を要するデバイスが正常に機能することが保証されることは、非常に難しくなります。実際、このコンピュータでは、大量の処理を同時に行っているときは常に、オーディオにエラーが発生します。

もちろん、これらの割り込みの待機時間の問題については、今日のコンピュータでリアルタイム動作を完全に実現できるようにするために解決しておく必要がありますが、それだけでよいわけではありません。これらの問題については、緊急に解決する必要があるのです。

PCI デバイスに割り込みを共有させる際には、それ以外にもアーキテクチャの問題が発生する可能性があります。たとえば、あるコンピュータでは、サウンド デバイスと USB コントローラが使用されており、その両方が同じ IRQ に接続されているとします。BIOS は、起動時に両方のデバイスの使用を試みる場合があります。BIOS は、起動時のサウンドを再生するために、このサウンド デバイスにアクセスする可能性があります。また、BIOS は、スタートアップ時に USB コントローラへのアクセスを試み、システムが USB キーボードやマウスを使用しているかどうか調べる場合もあります。

PCI 2.0 の仕様の時点では、デバイスの割り込みを停止させる一般的な方法については規定されていません。PCI 2.3 では、Interrupt Disable ビットによりこの問題に対応していますが、コンピュータのインストール環境がそれによる影響を受けることは、しばらくの間ありません。一方、PCI 2.0 では、デバイスによる入出力リソースおよびメモリ リソースのデコードと、バス マスタ トランザクションを、コマンド レジスタをクリアして停止する方法が規定されています。これは、BIOS が USB コントローラとサウンド デバイスの両方を割り込み状態にできることを意味します。これも、非常に一般的な方法です。

オペレーティング システムは、USB ドライバまたはサウンド ドライバのいずれかを最初に読み込む必要があります。これらは同時に読み込むことができると異論を唱える方もいるかもしれません。しかし、それは、システムで USB 2.0 が使用され、USB 接続のディスクから起動している場合には不可能なことです。また、既存の Microsoft オペレーティング システムのすべてを、ドライバの同時割り込みが可能になるように変更することも不可能です。サウンド ドライバの前に USB ドライバを読み込むと、サウンドの割り込みが保留の状態で IRQ が有効になります。これにより、ISR チェーン内にサウンド デバイスに対する ISR がない状態で、割り込みが送信されます。オペレーティング システムは USB ISR を呼び出し、USB ISR は、その割り込みが USB によるものでなかったことを示す値を返します。その後、オペレーティング システムは、割り込みを確認します。ただし、この割り込みは、レベルトリガ方式で発生するため、直ちに再アサートされます。そして、オペレーティング システムはすぐに割り込み処理コードへ戻ります。その結果、コンピュータがハングし、割り込みは永久的に失われます。つまり、割り込みストームでコンピュータがハングします。

同様のことは、コンピュータがサスペンド状態または休止状態から再開されるときにも起こる可能性があります。

ここでの説明では、すべてのハードウェアがまったく問題なく動作し、すべてのデバイス ドライバが正常に書き込まれ、すべてが正常に機能していることを想定しています。しかし、常にそうであるとは限りません。

特定のドライバ A において、書き込みが正常に実行されず、常に ISR が割り込み処理を終了したと示される場合を考えてください。ドライバ A は、レベルトリガ割り込みを使用するデバイスに対する処理を実行します。これは新しいデバイスすべてに当てはまることです。最近のデバイスはすべて、PCI 規格に準拠しているか、PCI デバイスと同様の機能を備えているからです。また、もう 1 つのドライバ B があり、そのドライバ用の ISR がチェーンのずっと下方にあると仮定してください。ドライバ B に関連するデバイスが割り込む場合、オペレーティング システムは、そのデバイスの ISR を呼び出すことができません。ドライバ A が常に割り込みを要求するからです。この場合も、割り込みストームによってコンピュータはハングします。しかし、それぞれの IRQ を取得できれば、ドライバ A は問題なく機能します。

別のケースとして、デバイス 2 つ、モデム 1 つ、および CardBus コントローラ 1 つが IRQ を共有しているとします。コンピュータはモバイル式のものであり、ユーザーが電話をかけていないときに、オペレーティング システムがモデムを D3 (電源オフ) 状態に設定します。モデム用のドライバは、その ISR の登録を解除し、ハードウェアの電源をオフにします。しかし、ハードウェアまたはソフトウェアのバグが原因で、モデムは、電話が鳴ると割り込みを送信します。モデムに固有の IRQ が割り当てられている場合、オペレーティング システムは、ドライバが ISR の登録を削除したときに、その IRQ をマスクします。ただし、これら 2 つのデバイスは IRQ を共有しているので、オペレーティング システムは、IRQ のマスクを解除して CardBus コントローラが機能するようにしておく必要があります。このときに電話が鳴ると、マスクが解除された IRQ に割り込みが送信されます。モデム ハードウェアに対しては ISR が登録されていないため、CardBus の ISR のみが呼び出され、その後にオペレーティング システムが割り込みを確認します。その結果、割り込みが依然として保留状態のため、別の割り込みストームが生じます。

上記の例は、非常に一般的なものです。多くのハードウェア設計者は、"ウェイク シグナル" または PME の概念と "割り込み" の概念を混同しているからです。ハードウェア設計者は、デバイスの割り込みはデバイスをスリープ解除するためにトリガされる必要があるという誤った考えを持ってしまうことがよくあります。詳細については、Windows での GPE ルーティングを参照してください。

これらのシナリオはすべて、APIC をシステムに備えることで回避され、それによって、ほとんどまたはすべてのデバイスが固有の IRQ を取得できるようになります。

最後に、PCI Express のネイティブの割り込み機構は、MSI (メッセージ シグナル割り込み) です。これは、PCI-X にも当てはまります。APIC なしでは MSI を使用できません。

ページのトップへ

歴史的要因

1997 年には、デバイス用の IRQ を選択する Windows 2000 のサブシステム (IRQ アービタ) を Windows エンジニアが設計しており、多くの ISA スロットや PCMCIA スロットを持つ大量のコンピュータが依然として使用されていました。つまり、IRQ が今以上に制約されていたのです。Windows テスト ラボには、IRQ を 19 個も使用するほど多くのデバイスが搭載された、1 台のラップトップ コンピュータがありました。それとは別に、18 の割り込みを必要とする別のラップトップ コンピュータもありました。また、これは、コンピュータが ACPI モードに切り替わる前のことでした。ACPI モードでは、もう 1 つ別の IRQ が使用されます。

1996 年、Microsoft では、1998 年までにすべての Microsoft 製コンピュータに I/O APIC を搭載することを Intel から求められていました。そのため、すべての PCI デバイスが ACPI を使用して IRQ を共有するように IRQ アービタが設計され、デバイスも ACPI 対応になりました。これによって、割り込みの制約による問題の多くが解決されましたが、IRQ の共有が非常に多く発生しました。多くのユーザーは、この実装を好まず、ACPI をオフにしました。しかし、それ以外のユーザーのコンピュータは、前に説明したような割り込みの共有に関連する一般的な問題が発生する可能性があるにもかかわらず、既定どおりに動作し、機能していました。

I/O APIC を持つコンピュータでは、Windows 2000 は各デバイスに IRQ を分散して割り当てます。

IRQ アービタは、Windows XP で、割り込みをより分散して処理するように変更されました。しかし、オペレーティング システムのテストにより、興味深い問題が明らかになりました。Windows 98 では、IRQ ステアリング デバイスの構成に ACPI をあまり使用せず、Windows 2000 では、各デバイスを常に固有の IRQ に割り当てるため、オペレーティング システムがそれぞれ ACPI BIOS を使用し始めたときに、多くの BIOS にバグが存在することがわかりました。そのため、オペレーティング システムが割り込みを分散する必要があるかどうかを決定するためのヒューリスティック手法の開発が必要になりました。したがって、オペレーティング システムは、I/O APIC がない場合には、CardBus コントローラを使用するすべてのコンピュータ上で、強制的に割り込みを共有 (またはスタック、分散の逆) させます。

こうした BIOS に関する問題とは別に、デバイス ドライバに関する問題もあります。実行時にデバイスが使用する IRQ を変更するために、ドライバは、WDM の IRP_MN_STOP_DEVICE 要求をサポートする必要があります。しかし、多くのドライバはそれを正常に実装できません。コンピュータの起動時に、オペレーティング システムは、新たに検出されたそれぞれのデバイスが固有の IRQ を取得するかどうかを判断する必要があります。固有の IRQ を取得する場合、ドライバが IRP_MN_STOP_DEVICE をサポートしていないと、オペレーティング システムはその IRQ をほかのデバイスに割り当て直すことはできません。つまり、オペレーティング システムが、コンピュータに搭載されたすべてのデバイスを、これまでのスタック方法を使用して開始できるようにしなければならなくなることが、しばしば起こります。それには、コンピュータがしばらく実行された後で CardBus スロットにホット挿入される可能性のあるデバイスも含まれます。

ページのトップへ

業界の開発に関する問題

PC は、この記事で説明済みのアーキテクチャの問題が解決されているだけでなく、より安価で信頼性の高いものでなくてはなりません。そのために、Windows と既存のハードウェア プラットフォームでどのような変更を加えたらよいかを、下記で説明します。

ページのトップへ

パートナーの皆様へ

ページのトップへ

その他のリソース

MSI の詳細については、PCI Specification, Version 2.3 に対する最新の Engineering Change Notifications (ECN) を参照してください。

ページのトップへ