JP2004342109A - 入出力ファブリックにおけるハードウェア・エラーからの自動回復 - Google Patents

Abstract

【課題】入出力ファブリックにおけるエラーからの自律的回復を可能にする
【解決手段】装置、プログラム製品、および方法が、複数のエンドポイントＩＯ資源をコンピュータ内の処理要素に結合するために使用されるＩＯファブリック内のＩＯファブリック要素において検出されたエラーを伝搬させる。具体的には、そのようなエラーを、ＩＯファブリック要素におけるエラーからの回復に関連して、ＩＯファブリック要素の影響を受けたエンドポイントＩＯ資源まで伝搬させる。これによって、影響を受けた各ＩＯ資源にアクセスするために使用されるデバイス・ドライバまたはその他のプログラム・コードを、それに付随するＩＯ資源において伝搬されたエラーから非同期で回復可能にすることができ、その際、ＩＯファブリック要素におけるエラーからの回復は、影響を受けた各ＩＯ資源について回復が完了するのを待つ必要がないことが多い。さらに、ＩＯファブリックは、回復不能なエンドポイントＩＯ資源と回復可能なエンドポイント資源の両方に対応するように動的に構成することができる。具体的には、ＩＯファブリック内のＩＯファブリック要素は、エンドポイントＩＯ資源が本質的に回復不能であることを検出するとそれに応答して、ＩＯファブリック要素におけるマシン・チェック通知を有効にするように動的に構成することができる。したがって、動的に構成されるＩＯファブリック要素は、回復不能資源と、その回復不能資源にアクセスするプロセッサとの間に規定されたハードウェア経路内に配置される。
【選択図】図１

Description

本発明は、コンピュータおよびコンピュータ・ソフトウェアに関し、より詳細には、コンピュータに接続されたハードウェア資源における障害の管理に関する。

現代社会ではコンピュータへの依存が絶え間なく増大していることを考えると、コンピュータ技術は、パフォーマンスに関する要求の増大だけでなく、コンピュータに対する高まる一方の信頼に対応するため、多くの面で進歩しなければならない。特に、コンピュータは、かなりの処理を一定して行わなければならず、不稼働期間が絶対に容認できない、高パフォーマンスかつミッション・クリティカルな用途で使用されることがますます多くなっている。

パフォーマンスを向上させるには、ますます高速化し、複雑化するハードウェア構成要素の使用が必要な場合が多い。さらに、多くの用途では、プロセッサだけでなく、記憶装置、ネットワーク接続といった周辺構成要素など、複数のハードウェア構成要素を並列動作させて、全体的なシステム・パフォーマンスを向上させる。

このような複雑化した構成要素の使用と共に、この種の構成要素の使用を有効に管理するには、この種の構成要素を動作させるために使用されるソフトウェアもより高度にし、より複雑にしなければならない。たとえば、コンピュータ・プログラムが複数の「スレッド」を並列実行することができるようにし、それによって基本的に同時に複数のタスクを行うことができるようにする、マルチスレッド・オペレーティング・システムおよびカーネルが開発されている。たとえば、電子商取引コンピュータ・アプリケーションの場合、顧客ごとに異なるスレッドを割り当てて、各顧客の特定の電子商取引トランザクションが別個のスレッドで処理されるようにする場合がある。

マルチスレッド・オペレーティング・システムの１つの論理的拡張は、論理区画化という概念であり、これは単一の物理コンピュータを基本的に複数の独立した「仮想」コンピュータ（論理区画と呼ぶ）のように動作させ、物理コンピュータ内の様々な資源（たとえばプロセッサ、メモリ、入出力装置）を様々な論理区画に割り振るものである。各論理区画は、別個のオペレーティング・システムを実行し、ユーザや、論理区画上で実行されているソフトウェア・アプリケーションから見ると、完全に独立したコンピュータのように動作する。

論理区画化では、しばしば「ハイパーバイザ」または区画マネージャと呼ばれる共用プログラムが論理区画を管理し、異なる論理区画への資源の割振りを容易にする。たとえば、区画マネージャは、プロセッサ、ワークステーション・アダプタ、記憶装置、記憶空間、ネットワーク・アダプタなどの資源を、様々な区画に割り振り、別個の物理コンピュータとほとんど同じ方式で各論理区画の相対的に独立した動作をサポートする。

しかし、上記のコンピュータ環境で可能なパフォーマンスの向上に伴い、障害の可能性も高くなる。タスクを並列実行することにより、１つのタスクが実行中の他のタスクと衝突し、データ破壊やシステム障害が発生する可能性が高くなる。同様に、ハードウェア・ベースの構成要素は常に、少なくともある程度の障害のリスクにさらされ、このリスクは、ハードウェア構成要素の複雑さと共に高くなることが多いため、複雑化したハードウェア構成要素を多数使用することにより、実行時にハードウェア構成要素エラーまたは障害が発生する可能性も高まる。

その結果、マルチスレッド・オペレーティング・システムと論理区画化の両方の開発と共に、最新のコンピュータ設計に耐障害性機能、高可用性機能、および自己回復機能を組み込むことに、かなりの開発努力が向けられてきた。

開発努力の対象となってきた１つの領域は、たとえば、記憶装置、ネットワーク接続、ワークステーションや、この種の構成要素をコンピュータの中央演算処理装置に接続するために使用されるアダプタ、コントローラ、およびその他の相互接続ハードウェア装置など、コンピュータが使用する周辺ハードウェア構成要素に付随する障害の管理である。以下で入出力（ＩＯ）資源と呼ぶ周辺構成要素は、一般には、中央演算処理装置とＩＯ資源との間の通信が経由する「ファブリック」を形成する１つまたは複数の中間相互接続ハードウェア装置構成要素を介してコンピュータに結合される。

よりパフォーマンスの低いコンピュータ、たとえば、デスクトップ・コンピュータ、ラップトップ・コンピュータなどのシングル・ユーザ・コンピュータでは、そのような設計で使用されるＩＯファブリックは、たとえば、インテグレーテッド・ドライブ・エレクトロニクス（Integrated Drive Electronics：ＩＤＥ）、ペリフェラル・コンポーネント・インターコネクト（PeripheralComponent Interconnect：ＰＣＩ）、ユニバーサル・シリアル・バス（Universal Serial Bus：ＵＳＢ）などの２、３の相互接続技法をサポートするＩＯチップセットを使用する、比較的単純な設計しか必要しない場合がある。一方、よりパフォーマンスの高いコンピュータ設計では、ＩＯ要件として、そのような設計に必要なすべての通信ニーズに対応するために相互接続ハードウェア装置の複雑な構成を必要とする場合がある。場合によっては、このような通信ニーズは、コンピュータの中央演算処理装置が収容されているエンクロージャとは別個に、そのエンクロージャに結合された１つまたは複数の追加のエンクロージャを使用しなければならないほど大きいこともある。

より複雑な設計では、ＩＯアダプタなどの周辺構成要素は、コンピュータの主エンクロージャまたは付属エンクロージャのいずれか一方あるいは両方内に配列された「スロット」を使用して、ＩＯファブリックに装着し、結合されることが多い。他の方式、たとえばケーブルおよびその他のタイプのコネクタを介して、ＩＯファブリックに装着または結合される構成要素もあるが、このような他のタイプの接続も、便宜上「スロット」と呼ぶことが多い。したがって、使用する接続のタイプにかかわりなく、ＩＯスロットは、ＩＯ資源がＩＯファブリックを介してコンピュータと通信するための接続点を表す。場合によっては、「ＩＯスロット」という用語を使用して、ＩＯファブリック内の特定の接続点に装着された実際の周辺ハードウェア構成要素を指すこともあり、その際、以下では、ＩＯスロット、またはそれに結合されたＩＯ資源をエンドポイントＩＯ資源とも呼ぶ。

ＩＯファブリックを介してコンピュータに結合されたエンドポイントＩＯ資源の管理は、複数のエンドポイントＩＯ資源と共に複数のタスクの並列実行をサポートする、ＩＯファブリックの典型的な機能と、ＩＯ資源にアクセスする、コンピュータ内のソフトウェアの様々なレベル間の相対的な独立性とのために、問題となることが多い。エンドポイントＩＯ資源で発生する障害と、ＩＯファブリック自体内の構成要素で発生する障害も、システム内の他のエンドポイントＩＯ資源にアクセスすることができる能力に重大な影響を与えることがある。さらに、個々の構成要素における障害の悪影響を最小限にしてシステム全体の可用性を維持したいため、障害を分離し、それらの障害を克服するようにシステムを動的に再構成することに多大な努力が注がれてきた。

たとえば論理区画化されたシステムでは、ＩＯスロットを個々の論理区画に割り当てることができ、各論理区画内のデバイス・ドライバが、その区画に割り当てられた各ＩＯスロット内のＩＯアダプタを制御することができる。これらのＩＯスロットは、そのファブリックの共通の相互接続要素を介して接続されたスロットを有するすべての区画によって実質的に共用される、共通のＩＯファブリックを介して、コンピュータ全体およびプロセッサ／メモリ複合体に共通に接続される。

論理区画化されたシステムの中には、ＩＯファブリックが、プロセッサ／メモリ・バスを配線バスを介して外部ＩＯエンクロージャに接続するブリッジ・ファブリック要素と、配線バスを複数のＩＯスロットを有するＩＯバスに接続する１つまたは複数の追加のブリッジ要素とから成るものもある。１つのそのような配線バスは、リモート入出力（Remote Input/Output：ＲＩＯ）バスであり、ＲＩＯバスをプロセス／メモリ複合体とインタフェースさせるためのＲＩＯハブと呼ばれるプロセッサ・ブリッジと、各外部ＩＯエンクロージャ内に配置され、配線バスを複数のＰＣＩホスト・ブリッジ（ＰＨＢ）とを備え、各ＰＨＢには、ＰＣＩ ＩＯアダプタ・カードを差し込む個別のＩＯスロット接続を形成する複数のＰＣＩ−ＰＣＩブリッジが接続されている。

このようなシステムでは、ＩＯファブリック・ハードウェアがエラーを検出すると、そのハードウェア要素は一般に、プロセッサ／メモリ複合体と、他のＩＯファブリック要素およびＩＯスロット要素との間のいずれの方向の連続データ伝送も阻止されるエラー状態になる。このエラー状態におけるデータ伝送の阻止は正確には、エラー状態の要素がプロセッサ・ストアのアダプタＤＭＡをすべて廃棄し、すべてのプロセッサ・ロードに対してオール１ビット・データを返すことと定義される。

多くのシステム、特にＰＣＩ対応ＩＯバスおよびアダプタを使用するシステムでは、デバイス・ドライバがメモリ・マップＩＯ（ＭＭＩＯ）を使用してＩＯアダプタと通信するのが一般的である。これによって、区画オペレーティング・システムにインストールされたデバイス・ドライバは、アダプタを、あたかもプロセッサ／メモリ・バスに論理的に直接接続されており、特定のメモリ・アドレス・レンジを占有するシステム・メモリの拡張部に過ぎないかのように扱うことができる。デバイス・ドライバは、内部アダプタ機構と直接関係する「メモリ」アドレスに対するプロセッサ・ロード命令またはストア命令を使用して、アダプタと通信する。このようなモデルでは、デバイス・ドライバは、一般にＩＯファブリック要素の構成や配置を認識しておらず、ＩＯファブリックとＩＯアダプタとに依存して、あたかもメモリ・マップ・ロードまたはストアに応答して単に記憶域にアクセスしているかのように動作する。

このようなシステムでは、デバイス・ドライバは一般に、２つの方法のうちの一方に依存して、ＩＯファブリックに関するエラーを検出する。第１の方法では、ＭＭＩＯロードがエラー状態のファブリック要素に遭遇した場合、ＩＯファブリックは要求側プロセッサにマシン・チェック状態を通知する必要がある。マシン・チェックは、一般には、アクセス要求と共に状況信号を返すか、または割り込みをトリガすることによって示され、その結果として、一般には、プロセッサがマシン・チェック割込みハンドラに実行を振り向け、それによって、前に発行されたストアが正常に完了したことを検証することができないことからデータ整合性の問題が生じるため、大抵は、オペレーティング・システムと、オペレーティング・システム上で実行されているアプリケーションが終了する。このような場合、デバイス・ドライバとオペレーティング・システムは、一般に、データ整合性を失わずにエラーから回復することができないようになっている。その結果、エラーに対する一般的な応答は、論理区画全体（または非区画化システムではシステム全体）の実行を終了することである。

第２の方法では、従来、ＩＯファブリックとＩＯアダプタは、エラー状態では、デバイス・ドライバが、エラーを示す可能性のあるものとして認識することができる特定のデータ・セットを返すことによって、メモリ・マップ・ロードに応答するように構成されている。たとえば、１つの一般的なデータ・セットはオール１・ビット・データと呼ばれるものであり、メモリ・マップ・ロードに対する応答で返されるデータの各ビットが１に設定される。この場合、デバイス・ドライバは、メモリ・マップ・ロード応答データにオール１パターンがないか検査し、ある場合は、オペレーティング・システム・サービスを呼び出して、プラットフォーム・ハードウェアの中に、エラー状態になってそのような結果を生じさせた要素があるか否かを判断する。多くの場合、非マシン・チェック方法では論理区画またはオペレーティング・システムの実行を終了させずに、エラー状態を回復することができる。

マシン・チェックによる技法は、ハードウェア・エラーからの動的回復に多くの進歩が見られる以前からあったものであり、したがって、マシン・チェックを通知する必要があるデバイス・ドライバおよびＩＯ資源は、本質的に回復不能であることが多い。しかし、前述の後者の技法は、マシン・チェックの生成を回避することが多く、適切な回復プロトコルと共に使用した場合、回復の可能性がより高く、そのためこの技法に依存するデバイス・ドライバおよびＩＯ資源は、本質的により一般的に回復可能である。

いずれの手法を使用した場合も、通常は、ＩＯファブリック・エラーからの回復、たとえば、エラー分離データの獲得、影響を受けたハードウェアのリセット、通常のＩＯ動作の再開を同期させなければならず、それによって、影響を受けた各デバイス・ドライバおよびＩＯアダプタがエラー状態を確実に検出するようにし、そのエラー状態を検出するまで、デバイス・ドライバとそのアダプタとの間のＩＯをファブリック・エラー状態が持続しているかのように継続させる必要がある。しかし、プラットフォーム・ハードウェアと区画マネージャによってエラーが検出された時点から、影響を受けたすべてのデバイス・ドライバもエラーを検出するまでの時間は予測不能であり、過度に長い場合もあり、それによってＩＯファブリックの回復がきわめて複雑化し、遅れる可能性がある。極端な場合、デバイス・ドライバ自体はアクティブであるにも関わらずそれに付随するＩＯアダプタを使用しない期間の長さによっては、デバイス・ドライバ（エラーの時点でアクティブになっていない可能性があるＣＤ−ＲＯＭドライブの場合など）がそのアダプタからのＭＭＩＯロードを、数日、数週間、数カ月にも及ぶきわめて長期の期間、行うことができないことがある。

一方、ＩＯファブリック・エラーからの回復を完了する前に、すべてのデバイス・ドライバが別々にエラー状態を検出するのを待つ場合、過度の遅れや、予測不能な結果になることが多く、１つの論理区画のデバイス・ドライバが他の論理区画の回復を妨げる可能性がある。また一方、ＩＯファブリックの回復を完了することができるようにＩＯファブリック内のエラーのデバイス・ドライバに特別に変更を加えることは、特に論理区画化システムの場合、古いデバイス・ドライバとの互換性がないことと、デバイス・ドライバおよびカーネル・インタフェースに複雑な方法で変更を加えるか、設計し直すか、または改善を加える必要があるために、問題となる可能性がある。

したがって、当技術分野では、特に論理区画化コンピュータなどでは、影響を受けるＩＯ資源のデバイス・ドライバが、ＩＯファブリック内のエラーの検出と回復を確実に行うことができるようにする方法、特に既存のデバイス・ドライバの使用を容易にする、より迅速、自立的、かつ効率的な方法がきわめて必要である。

特に論理区画化システムにおいて、マシン・チェックを行う必要がある回復不能デバイス・ドライバに付随する他の問題は、ＩＯファブリックの初期設定によって、一般には、一組のファブリック要素を共通して有するすべての区画がマシン・チェックを受けることになることである。これは、１つの区画によって使用されているＩＯアダプタの障害によるエラーの結果、そのファブリックの共通要素を共用する複数の他の区画が、マシン・チェックにより終了する可能性があるため、区画化システムではきわめて望ましくない。

多くのコンピュータ環境では、システムの可用性に与える影響が大幅に削減されるために、回復不能なデバイス・ドライバおよびＩＯ資源は回復可能デバイス・ドライバおよびＩＯ資源と交換されているか、将来、交換されることになる。したがって、可能な限り、回復可能デバイス・ドライバおよびＩＯ資源のみを使用することが望ましいことが多い。しかし、環境によっては、古いレガシＩＯ資源およびデバイス・ドライバが依然として使用されている場合もあり、より高機能の回復プロトコルをサポートしないことがある。さらに、ＩＯ資源の中には、回復不能デバイス・ドライバと回復可能デバイス・ドライバの両方を利用可能なものもある。

その結果、実際には、どの導入済みのＩＯ資源が回復可能デバイス・ドライバを持っているか、あるいは特定の資源について、そのデバイス・ドライバのどのバージョンがマシン・チェックを必要としているのかを特定するのがきわめて困難になっている。さらに、顧客が論理区画ＩＯ割当ての再構成、デバイス・ドライバの更新、または新しいＩＯアダプタの追加を行うに伴い、一律に一方のタイプのみであった区画が、再構成によって、当該区画に両方のタイプのデバイス・ドライバが混在するようになったり、あるいは一律に他方のタイプのみになったりすることがある。

したがって、当技術分野では、混在環境（すなわち回復不能と回復可能な資源およびデバイス・ドライバの混在が可能な環境）において、ＩＯ資源とそのデバイス・ドライバが回復可能であることを検出すると共に、ＩＯエラーを確実に管理し、しかも、可能な限りマシン・チェックの使用を最小限に抑えるようにＩＯファブリックを動的に構成する方法の必要性がきわめて高い。

本発明は、一態様では、複数のエンドポイントＩＯ資源をコンピュータ内の処理要素に結合するために使用されるＩＯファブリックにおいて、複数のエンドポイントＩＯ資源のエラーからの回復を同期させる方法を提供することによって、従来の技術に付随する上記およびその他の問題に対処する。具体的には、本発明による実施形態は、ＩＯファブリック要素におけるエラーから回復すると共に、ＩＯファブリック内の特定のＩＯファブリック要素で検出されたエラーを、当該ＩＯファブリック要素の影響を受けるエンドポイントＩＯ資源まで実質的に伝搬させることができる。これによって、影響を受ける各ＩＯ資源へのアクセスに使用されるデバイス・ドライバまたはその他のプログラム・コードを、それに関連づけられたＩＯ資源において伝搬されたエラーから非同期で回復させることができ、その際、ＩＯファブリックにおけるエラーからの回復は、多くの場合、影響を受ける各ＩＯ資源についてのエラー回復が完了するまで待つ必要がない。

したがって、本発明の位置態様によると、ＩＯファブリック要素において検出されたエラーに応答して複数のエンドポイントＩＯ資源のそれぞれについてエラー状態を設定し、ＩＯファブリック要素におけるエラーから回復することによって、複数のエンドポイントＩＯ資源へのアクセスを可能にするＩＯファブリック要素におけるエラーを処理する。

他の態様では、本発明は、回復可能なエンドポイントＩＯ資源と回復不能なエンドポイントＩＯ資源の両方に対応するように、ＩＯファブリックを動的に構成する方法を提供することによって他の問題に対処する。具体的には、エンドポイントＩＯ資源が本質的に回復不能であることを検出すると、それに応答して、ＩＯファブリック要素においてマシン・チェック通知を有効にするように、ＩＯファブリック内のＩＯファブリック要素を動的に構成することができる。したがって、動的に構成されるＩＯファブリック要素は、回復可能資源とその回復不能資源にアクセスするプロセッサとの間に規定されたハードウェア経路内に配置される。

したがって、本発明の他の態様によると、少なくとも１つのプロセッサが複数のエンドポイントＩＯ資源にアクセスすることができるようにする複数のＩＯファブリック要素を含むＩＯファブリックを、複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源が回復不能な資源であることを検出し、その検出に応答してプロセッサと第１のエンドポイントＩＯ資源との間のハードウェア経路内に規定された各ＩＯファブリック要素においてマシン・チェック通知を動的に有効にすることによって、動的に構成することができる。

本発明を特徴づける上記およびその他の利点および特徴は、本明細書の特許請求の範囲に記載されており、本発明の一部を構成する。しかし、本発明と、本発明の使用により実現される利点および目的とをよりよく理解することができるように、本発明の実施例を記載した図面およびそれに付随する説明を参照されたい。

以下に記載の実施形態では、たとえば、ネットワーク接続、記憶装置、プリンタ、ワークステーションや、これらのためのアダプタやコントローラなど、周辺ハードウェア構成要素などのコンピュータにおけるＩＯ資源の管理に関連して、自動回復技法を使用する。

一面では、以下に記載の実施形態は、ＩＯファブリック内のＩＯファブリック要素で検出されたエラーを、エラーの影響を受ける個々のＩＯにまで伝搬させる機能をサポートする。これによって、影響を受けるＩＯ資源を利用する区画またはオペレーティング・システムでエラーに別々に対処するまで、影響を受ける各ＩＯ資源でエラー状態が持続している間に、ＩＯファブリックにおけるエラーを動的に修正することができる。これにより、特に、特定のＩＯファブリック・ドメインを複数の論理区画が共用する論理区画化環境の場合、資源とファブリックのエラー回復の同期が格段に簡略化される。

他の面では、以下に記載の実施形態は、同じＩＯファブリック内の回復可能ＩＯ資源と回復不能ＩＯ資源の両方に対処可能な機能をサポートする。回復可能ＩＯ資源と回復不能資源の両方に対する対処は、例示の実施形態では、コンピュータ・プロセッサとＩＯ資源との間の経路に配置された１つまたは複数のＩＯファブリック要素を選択的に切り換えて、ＩＯ資源が回復不能であると判断されるか否かを問わず、マシン・チェックを可能にすることによって行う。

ここで、回復可能ＩＯ資源とは、コンピュータの動作中に実行される回復プロトコルに応答して、動的に、すなわちシステムの通常の動作中に回復するように構成された資源である。一般には、ＩＯ資源は、論理区画のオペレーティング・システムまたは非論理区画化コンピュータのオペレーティング・システムに常駐する、当該ＩＯ資源用のデバイス・ドライバが、その資源の回復プロトコルをサポートする場合に、回復可能である。また、ＩＯ資源の回復可能性は、他のオペレーティング・システムまたはカーネル・サーボスに備えられたサポート、およびＩＯファブリック内の他のソフトウェア機能またはハードウェア機能あるいはその両方を基にすることもできる。また、ＩＯ資源の回復可能性は、一般には、当該資源を管理するために使用するデバイス・ドライバ内の回復プロトコルのサポートに少なくともある程度依存するため、適合するデバイス・ドライバと共に使用した場合に回復可能なＩＯ資源であっても、回付プロトコルをサポートしない古いデバイス・ドライバを使用して資源を管理している状況では回復不能なことがある。

それに対して、回復不能ＩＯ資源は動的資源をサポートしない。多くの環境では、資源が回復不能な資源である場合、エラーに応答してプロセッサ・マシン・チェックを生成する必要があり、その結果、一般に、オペレーティング・システム全体とその上で実行されるアプリケーションを、結局は終了させることになり、回復のためにシステムを再起動する必要がある。論理区画化コンピュータでは、マシン・チェックの結果として、システム全体ではなく論理区画のみの終了と再起動を行うことになる。

以下でさらに明らかになるように、本発明による実施形態は、たとえば、ブリッジ装置、ハブ装置、スイッチ、コネクタ、ホスト装置、スレーブ装置、コントローラ装置、ケーブル、モデム、並直列変換器／直並列変換器、オプトエレクトロニック・トランシーバなど、夥しい数および種類のＩＯファブリック要素を含むＩＯファブリックを使用することができる。

本明細書に記載の技法には、特に、論理区画化コンピュータにおけるスロットまたは資源レベルの区画化の実現が容易になり、個々のＩＯ資源またはスロットを、論理区画化コンピュータ内にある特定の論理区画に結びつけることができるという利点がある。しかし、本明細書に記載の技法は、論理区画化されていない環境や、たとえばバスやエンクロージャレベルなど他の資源区画化細分性でも使用可能であることがわかるであろう。

次に、図面を参照すると、いくつかの図面では同じ構成要素は同じ番号で示されており、図１には、本発明による論理区画化コンピュータ１０内の主要構成要素が図示されている。コンピュータ１０は、たとえば、ネットワーク・サーバ、中規模コンピュータ、たとえばＩＢＭ ｅＳｅｒｖｅｒなどのメインフレーム・コンピュータなど、複数のマルチユーザ・コンピュータのうちのいずれかを、一般的に示している。しかし、本発明は、たとえば、ワークステーション、デスクトップ・コンピュータ、携帯型コンピュータなどのシングル・ユーザ・コンピュータなど、他のコンピュータおよびデータ処理システム、または（たとえば組込みコントローラなどが組み込まれた）他のプログラム式電子装置や、非論理区画化コンピュータを含む他のマルチユーザ・コンピュータでも実施可能であることを理解されたい。

コンピュータ１０は、典型的には、バス１６を介してメモリ１４に結合された１または複数のプロセッサ１２を含む。各プロセッサ１２は、シングルスレッド・プロセッサ、または、複数のハードウェア・スレッド１８が組み込まれた、図のプロセッサ１２ａなどのマルチスレッド・プロセッサとして実施することができる。マルチスレッド・プロセッサ１２ａ内の各ハードウェア・スレッド１８は、概ね、コンピュータに常駐するソフトウェアによって独立したプロセッサのように扱われる。

さらに、図１に示すように、１つまたは複数のプロセッサ１２（たとえばプロセッサ１２ｂ）は、システムの初期プログラム・ロード（ＩＰＬ）を管理する専用ファームウェア・コードを実行し、システム・ハードウェアの監視、診断、および構成を行うために使用される、サービス・プロセッサとして実行することができる。一般に、コンピュータ１０は１つのサービス・プロセッサと、コンピュータに常駐するオペレーティング・システムおよびアプリケーションを実行するために使用される複数のシステム・プロセッサとを含むが、本発明はこの特定の実施態様のみには限定されない。実施態様によっては、サービス・プロセッサを、バス１６以外の方式でコンピュータ内の他の様々なハードウェア構成要素に結合することができる。

メモリ１４は、たとえばＤＲＡＭベースの主記憶装置などの１レベルまたは複数レベルのメモリ装置と、１レベルまたは複数レベルのデータ・キャッシュ、命令キャッシュ、または組合せキャッシュ、あるいはこれらの組合せを含むものとすることができ、当技術分野で周知のように、特定のキャッシュが個別プロセッサまたは複数プロセッサに使用される。さらに、メモリ１４は、ＩＯファブリック２０を介して、たとえば（コンピュータをネットワーク２４とインタフェースさせる）１つまたは複数のネットワーク・アダプタ２２、（コンピュータを１つまたは複数の記憶装置２８とインタフェースさせる）１つまたは複数の記憶制御装置２６、（複数のワークステーション・アダプタを介して１つまたは複数の端末またはワークステーション３２にインタフェースするための）１つまたは複数のワークステーション・コントローラ３０など複数の種類の外部装置に結合されている。

図１には、区画マネージャまたはハイパーバイザ３６によって管理される複数の論理区画３４を含む論理区画化環境をコンピュータ１０上で実現する際に使用される、基本ソフトウェア構成要素および資源も詳細に示されている。当技術分野で周知のように、任意の数の論理区画をサポートすることができ、コンピュータに任意の時点で存在する論理区画の数は、コンピュータの区画が追加または削除されるにつれて動的に変化可能である。

例示のＩＢＭ ｅＳｅｒｖｅｒベースの実施態様では、区画マネージャ３６は２層のプログラム・コードから成る。本明細書でディスパッチ不可部３８と呼ぶ第１の部分は、コンピュータのファームウェアまたはライセンス内部コード（ＬＩＣ）内で実現され、様々なハードウェア構成要素との低レベル・インタフェースをとるために使用されると同時に、たとえばオペレーティング・システムなど、より上位の層をハードウェア・アクセスの細部から分離する。このファームウェアは、サービス・プロセッサ１２ｂなどのサービス・プロセッサと通信することもできる。ディスパッチ不可部３８は、コンピュータ１０に、たとえばページ・テーブル管理など低レベル区画管理機能の多くを提供する。また、ディスパッチ不可部３８には、タスクという概念がなく、主として、上位層のソフトウェアからの関数呼出しによって、またはハードウェアからの割込みによってアクセス可能である。

区画マネージャ３６内のプログラム・コードの第２の層を、本明細書ではディスパッチ可能部４０と呼ぶ。タスクの概念がなく、メモリ再配置をオフにして実行され、より上位層のソフトウェアからスーパーバイザ関数呼出しによってアクセス可能なディスパッチ不可部３８とは異なり、ディスパッチ可能部４０は、（オペレーティング・システムと同様に）タスクの概念があり、メモリ再配置をオンにして実行される。ディスパッチ可能部は、典型的には、ユーザから隠蔽されている点を除けば、区画とほとんど同様にして実行される。ディスパッチ可能部は、一般に、区画の作成および削除、同時ハードウェア・メンテナンスや、プロセッサ、メモリ、およびその他のハードウェア資源の様々な区画３４への割振りなど、より上位の区画間理動作を管理する。

各論理区画３４には、一般に、コンピュータ１０内の利用可能な資源の一部が、静的または動的に割り振られる。たとえば、各論理区画には、１つまたは複数のプロセッサ１２、または１つまたは複数のハードウェア・スレッド１８、あるいはその両方、ならびに利用可能な記憶区間の一部を割り振ることができる。論理区画は、プロセッサなどの特定のハードウェア資源を共用することができ、それによって、所与のプロセッサを複数の論理区画が使用することになる。この代替ハードウェア資源は、一度に１つの論理区画にしか割り振ることができない。

一般には、たとえば大容量記憶装置、バックアップ記憶装置、ユーザ入力、ネットワーク接続、表示装置、およびそのためのＩ／Ｏアダプタなど、追加の資源が、当技術分野で周知の方式で、１つまたは複数の論理区画に割り振られる。資源は、たとえば、バスごと、または資源ごとなど、いくつかの方式で割り振ることができ、複数の論理区画が同一バス上の資源を共用する。資源の中には、一度に複数の論理区画に割り振ることができるものもある。さらに、たとえば仮想ローカル・エリア・ネットワークで使用される仮想ネットワーク・アダプタなど、本質的に「仮想」の資源もある。

各論理区画３４は、非区画化コンピュータのオペレーティング・システムと同じ方式で、論理区画の基本動作を制御するオペレーティング・システム４２を使用する。たとえば、各オペレーティング・システム４２は、インターナショナル・ビジネス・マシーンズ・コーポレーションが販売するＯＳ／４００オペレーティング・システムの他、ＡＩＸ、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘなど他のオペレーティングを使用して実施可能である。

各論理区画３４は、別個の、または独立した記憶空間で実行され、したがって、各論理区画は、各論理区画で実行される各ユーザ・アプリケーション４４から見ると、独立した非区画化コンピュータとほとんど同じように機能する。したがって、ユーザ・アプリケーションは、一般に、区画化環境で使用するための特別な構成を必要としない。

論理区画３４の別々の仮想コンピュータ的性質を考えると、論理区画が別々の物理マシン上にあるかのように互いに通信することができるように、区画間通信をサポートすることが望ましい。したがって、実施態様によっては、論理区画３４がイーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））プロトコルなどのネットワーク・プロトコルを介して互いに通信することができるように、ディスパッチ不可部３８において、仮想ローカル・エリア・ネットワーク（ＬＡＮ）４６をサポートすることが望ましい場合がある。区画間の通信をサポートする他の方式にも、本発明により対応可能である。

本発明により、他の論理区画化環境も使用可能であることを理解されたい。たとえば、図２に示すように、メモリ１４’内に、図１のディスパッチ不可部３８とほぼ同様に構成されたディスパッチ不可部３８’を備え、オペレーティング・システム４２および１つまたは複数のユーザ・アプリケーション４４も常駐する基本区画３３’内に組み込まれたディスパッチ可能部４０’を備えることもできる。

一般に、本発明の実施形態を実現するために実行されるルーチンは、オペレーティング・システムの一部、特定のアプリケーション、構成要素、プログラム、オブジェクト、モジュール、または命令シーケンス、あるいはこれらのサブセットのいずれとして実現されるかを問わず、本明細書では「コンピュータ・プログラム・コード」または単に「プログラム・コード」と呼ぶ。プログラム・コードは、一般に、様々な時点でコンピュータ内の様々なメモリおよび記憶装置内に存在し、コンピュータ内の１つまたは複数のプロセッサによって読み取られ、実行されると、本発明の様々な態様を実現するステップまたは要素を実行するために必要なステップをコンピュータに実行させる、１つまたは複数の命令を含む。さらに、上記および以下の説明では、本発明について、完全機能コンピュータおよびコンピュータ・システムの環境で説明するが、本発明の様々な実施形態は、様々な形態のプログラム製品として配布可能であり、本発明は、実際に配布を行うために使用される特定のタイプの信号伝達媒体に関わらず、等しく適用可能であることが、当業者ならわかるであろう。信号伝達媒体の例としては、揮発性および不揮発性の記憶装置、フロッピィ・ディスクおよびその他の取外し可能ディスク、ハード・ディスク・ドライブ、磁気テープ、光ディスク（たとえばＣＤ−ＲＯＭ、ＤＶＤなど）の記録可能型媒体と、デジタルおよびアナログ通信リンクなどの伝送型媒体とが含まれるが、これらには限定されない。

さらに、以下で述べる様々なプログラム・コードを、本発明の特定の実施形態において、プログラム・コードが実現されるアプリケーションまたはソフトウェア構成要素に基づいて識別する場合がある。しかし、以下の特定のプログラム名称は、便宜上使用するに過ぎず、したがって本発明は、そのような名称によって識別および／または暗黙的に示す特定のアプリケーションのみでの使用に限定すべきではないことを理解されたい。さらに、一般に、コンピュータ・プログラムをルーチン、プロシージャ、メソッド、モジュール、オブジェクトなどに編成する方法は多数あり、プログラムの機能を、典型的なコンピュータ内に常駐する様々なソフトウェア層（たとえば、オペレーティング・システム、ライブラリ、ＡＰＩ、アプリケーション、アプレットなど）に割り振る方法も様々あるため、本発明は、本明細書に記載するプログラム機能の特定の編成および割振りには限定されないことを理解されたい。

当業者なら、図１および図２に示す例示の実施形態は、本発明を限定するものではないことがわかるであろう。実際には、本発明の範囲から逸脱することなく、他の代替ハードウェアおよび／またはソフトウェア環境も使用可能であることが当業者ならわかるであろう。

次に図３を参照すると、システムの中央電子処理装置（CentralElectronics Complex：ＣＥＣ）５４を複数のエンドポイントＩＯ資源５６（ここではＩＯスロット）に接続するために使用されるＩＯファブリック５２を備えた例示のコンピュータ・システム５０が図示されている。ＣＥＣ５４は、プロセッサ／メモリ・バスまたはシステム・バス６２に結合された１つまたは複数のプロセッサ５８とメモリ６０とを含むものとして図示されている。例示の実施形態では、ＣＥＣ５４は、ＩＯスロット５６とは別個のエンクロージャ内に収容されており、したがって、ＩＯスロットは１つまたは複数のＩＯエンクロージャ６４内に、グループとして収容されている。実施形態によっては、図３に示す構成要素を同じエンクロージャ体内に組み込むこともできることを理解されたい。

ＩＯファブリック５２は、１つまたは複数のリモートＩＯ（ＲＩＯ）ネットワーク６６を含み、各ネットワーク６６は、ＣＥＣ５４内に収容されてプロセッサ／メモリ・バス６２に結合されたＲＩＯハブ６８を含み、エンクロージャ６４内に配置された１つまたは複数のＲＩＯブリッジ７０を備えた、ループ・トポロジ状に配置されている。各ＲＩＯブリッジ７０は、さらに１つまたは複数のＰＣＩホスト・ブリッジ（ＰＨＢ）７２に結合されて、たとえばＰＣＩ、ＰＣＩ−Ｘ、またはＰＣＩ ＥｘｐｒｅｓｓなどのＰＣＩ対応インタフェースをサポートする。各ＰＨＢ７２は、一次ＰＣＩバスを制御し、一次ＰＣＩバスには、複数のＰＣＩ−ＰＩＣブリッジ７４が接続されている。各ＰＣＩ−ＰＣＩブリッジ７４は、さらに、それに付随するＩＯスロット５６を二次ＰＣＩバスに接続する。ＩＯスロット５６は、たとえば、ＰＣＩ対応アダプタ・カードを受け入れるコネクタとして、または、ＰＣＩ−ＰＣＩブリッジおよび／またはＰＨＢを組み込んだ電子回路基板上に直接組み込まれた（はんだ付けされた）ＰＣＩアダプタ・チップとして実装可能である。

ＰＣＩベースのインタフェースは、メモリ・マップ入出力（ＭＭＩＯ）をサポートする。したがって、コンピュータ５０が論理区画化環境を実現する場合、論理区画オペレーティング・システムがプロセッサ・アドレスを特定のＰＣＩアダプタ・メモリに「バインド」することができるようにし、ＭＭＩＯについてはプロセッサ５８からアダプタに、また、メモリ６０からアダプタにアドレスをバインドすることができるようにして、アダプタがメモリ６０との間で直接メモリアクセスを行うことができるようにする。

例示の実施形態では、ＰＣＩ−ＰＣＩブリッジ７４介在ＰＨＢ７２とＩＯスロット５６とを使用して、個々のアダプタと、ＰＨＢ７２、ＲＩＯ要素６８、７０、プロセッサ５８、およびメモリ６０との間の追加の信号伝送およびアダプタ・バインド分離を可能にする。この追加の分離によって、個々のＩＯスロットを異なる論理区間に割り当てることが容易になり、それによって、論理区画がＰＣＩ−ＰＣＩブリッジ７４に共通して接続されたＩＯファブリック・ハードウェアを共用することができるようになるが、他の論理区画に割り当てられたＩＯスロット５６の動作が特定の論理区画に割り当てられたアダプタの動作を妨害せず、さらに、論理区画またはアダプタが他の区画−アダプタ・バインドを使用することができないようにアダプタ・アドレス・バインディンドが行われるようになる。他の実施形態では、所与のＰＣＩ−ＰＣＩブリッジに複数のＩＯスロットを結合することができるが、その場合、ＰＣＩ−ＰＣＩブリッジに結合されたすべてのＩＯスロットを、論理区画化コンピュータ内の同じ論理区画にバインドする必要がある。また、他の実施形態では、１つのＰＨＢに複数のスロットを接続して、各スロットに内部分離機能をもたせることもできる。

また、例示の実施形態では、各ＩＯスロットにホットプラグ・コントローラを関連づけ、ＰＨＢ７２またはＰＣＩ−ＰＣＩブリッジ７４に組み込んで、システム内の他のＩＯスロット５６への電力供給状態とは独立して、各ＩＯスロット５６に選択的に電力を供給することができるようにすることが望ましい。さらに、実施形態によっては、ＩＯファブリック要素のグループを、共通の集積回路またはカードに集積することができる。たとえば、１つの共通集積回路状に複数のＰＣＩ−ＰＣＩブリッジ７４を配置することができる。

さらに、例示の実施形態では、各ＰＣＩ−ＰＣＩブリッジ７４がそれに関連づけられたＩＯスロットのエラー状態を管理することができ、それによって、エラーをＩＯファブリックから該当するＩＯスロットに伝搬させることができる。代替実施形態では、ＰＨＢまたはその他のＩＯファブリック要素に、ＩＯファブリックに結合された複数のＩＯスロットのエラー状態を管理する機能が組み込まれる。

本発明によるＩＯファブリックのために、エンドポイントＩＯ資源とコンピュータ内のプロセッサとの間の通信をサポートする多くの代替構成を使用することができることを理解されたい。たとえば、ＵＳＢ、ＳＣＳＩ、ＩＤＥ、ＩＥＥＥ−１３９４、ＰＣＩ−Ｅｘｐｒｅｓｓ、ファイバ・チャネル、ＩｎＦｉｎｉＢａｎｄなど、複数のこと案留相互接続標準を、ＰＣＩに代えて、またはＰＣＩに加えて使用することができる。さらに、他の数および構成のブリッジ、スイッチ、ホスト、ハブ、エンクロージャ、アダプタ、コネクタ、通信プロトコル、コントローラ、およびその他のタイプのハードウェア装置も、本発明によるＩＯファブリックに組み込むことができる。したがって、図３の構成は本質的に例示的なものに過ぎず、本発明は、本明細書で開示する特定の構成には限定されないことがわかるであろう。

前述のように、本発明による実施形態は、ＩＯファブリック・エラーをＩＯ資源に伝搬させる機能をサポートし、デバイス・ドライバ・エラー検出とそのようなエラーの回復を容易にすると共に、ＩＯファブリックの一部を、マシン・チェック・モードと非マシン・チェック・モードとの間で再構成して回復可能ＩＯ資源と回復不能ＩＯ資源との混在環境に容易に対応することができるようにする。この点について、論理区画化環境を、図３に関連して説明した例示のＩＯファブリック・アーキテクチャと共に使用する実施例を以下に示す。しかし、本発明はこの特定の実施形態には限定されないことを理解されたい。

この例示の実施形態では、ＩＯファブリック要素がエラー状態を実現し、この状態では、ＩＯファブリック要素は、エラー状態を検出すると、（１）エンドポイントへのＭＭＩＯストアを廃棄し、（２）ＭＭＩＯロードに対してオール１データを返し、（３）ＤＭＡ書込みを廃棄し、ＤＭＡ読取り要求に対して拒否またはエラー状況を返す（たとえばＰＣＩバスでは、ＰＨＢはＤＭＡ読取り要求に対してターゲット打ち切り（Target Abort）または再試行（Retry）状況で応答する）。

さらに、この例示の実施形態では、ＩＯファブリック要素をマシン・チェック・モードと非マシン・チェック・モードとの間で動的に再構成することができる。したがって、マシン・チェック・モードでは、ＭＭＩＯロードに対してオール１データを返すと共に、ファブリック要素は、プロセッサにおいてマシン・チェック割込みを発生させるエラー状況を返す。

この例示の実施形態で使用する回復可能デバイス・ドライバは、オール１ロード応答を検出し、ファブリック・エラー状態があるか否かを調べるマシン／チェックを必要としない。区画マネージャは、ファブリック・エラー状態でマシン・チェックが通知されないようにＩＯファブリックを初期設定する。区画をアクティブにする前に、区画マネージャはすべてのファブリック要素を初期設定し、それによって、ファブリック要素がエラー状態になった場合にマシン・チェックを通知しないようにする。回復不能デバイス・ドライバが検出され、スロット構成が区画化システムのエラー分離ポリシーを満たす場合、区画マネージャはファブリック要素を動的に変更して、プロセッサ／メモリ・バスとＩＯアダプタ／スロットとの間のハードウェア経路を形成するように相互接続するファブリック要素について、マシン・チェック通知をアクティブにする。同様に、ＩＯアダプタ／スロットが回復不能デバイス・ドライバの制御下になくなった場合、区画マネージャはファブリック要素を動的に変更して、ファブリック要素を非マシン・チェック・モードに復帰させる。

ファブリック内の任意の箇所に、２つのスロット間の経路の接点を設けることができる。マシン・チェック通知を有効または無効にするようにファブリック要素に変更を加えるとき、区画マネージャは、この接点と、この接点からプロセッサ／メモリ・バスまでの経路とにおいて、ファブリック要素が適切に初期設定されるように保証し、それによって、いずれか一方のスロットがマシン・チェック・エラー・モードを必要とする場合、スロットとプロセッサ／メモリ・バスとの間の共通経路を形成する要素が、マシン・チェックを通知するように設定される。

図４の１００に、回復可能デバイス・ドライバを使用したＩＯファブリック・エラーの検出と回復のための流れの一例を示す。区画マネージャのディスパッチ可能部は、ファブリック・ハードウェア・マネージャ１０２を含む。このファブリック・ハードウェア・マネージャ１０２は、タスクを使用してファブリック・ハードウェア初期設定および回復シーケンシングの大部分を実行する。区画マネージャのディスパッチ不可部は、権限検査を実行して、区画デバイス・ドライバが区画に割り当てられたスロット内のＩＯアダプタに対して操作を行うことができるようにする。さらに、区画マネージャのディスパッチ不可部は、ファブリックＩＯハードウェア割込みを受け取り、（図４で区画マネージャ呼出しインタフェースとして識別されている破線によって示すように）ファブリック・ハードウェア・マネージャ１０２と区画オペレーティング・システム１０４の両方から呼出し可能である。ディスパッチ不可区画マネージャは、ファブリック・ハードウェア・マネージャ１０２および区画オペレーティング・システム１０４に付随するイベント待ち行列に格納されたイベント・メッセージを使用して、ファブリック・ハードウェア・マネージャ１０２または区画オペレーティング・システム１０４に対して非同期状態を通知する。これには、ファブリック・エラー割込みに関連するイベントも含まれる。

図４で、区画マネージャのディスパッチ不可文は、ファブリック・マネージャ構成要素１０６とスロット・マネージャ構成要素１０８とを含むものとして図示されている。ファブリック・マネージャ１０６は、ファブリック・ハードウェアの状態を監視し、エラーまたはその他の非同期状態が発生するとそのファブリック・ハードウェアから割込みを受け取る。区画マネージャのディスパッチ不可部は、各ＩＯアダプタ・スロットごとに、区画オペレーティング・システムから呼び出されるとＩＯスロットの状態を監視して権限検査とスロット操作を行うスロット・マネージャ１０８も含む。スロット・マネージャ１０８は、ファブリック・エラーが発生した場合、ファブリック・マネージャ１０６と区画オペレーティング・システム１０４との対話の同期化も行い、区画デバイス・ドライバがエラーを検出してエラー状況を要求するまでファブリック・エラー状況を記憶する機構を提供する。

ステップ１１０．１からステップ１２０．３までのシーケンスは、ファブリック・エラー、すなわちＩＯファブリック内のＩＯファブリック要素の１つにおけるエラーを認識した後の区画マネージャの動作を示す。１２２から１３０までのシーケンスは、オール１ロード応答を検出したときの回復可能デバイス・ドライバの動作を示す。両方のシーケンスは、ほぼ同時に発生可能であり、ステップ１２８および１３０は、この２つのシーケンス間の同期ステップである。デバイス・ドライバが詳細なファブリック・エラー状況を処理も記録もしない場合、デバイス・ドライバはステップ１２８を省いてステップ１３０のみを行うこともできることに留意されたい。

ステップ１１０．１および１１０．２は、可能性のあるファブリック・エラーを区画マネージャに通知する独立した機構を示す。ステップ１１０．１は、区画マネージャ割込みハンドラにエラー割込みを通知するファブリック・ハードウェア要素を示し、ステップ１１０．２は、ステップ１２４を実行するデバイス・ドライバを示す。このデバイス・ドライバは、区画マネージャがステップ１１２．１を実行し、スロットのためにスロット・マネージャ１０８においてファブリック・エラー状態を記憶する前にステップ１２４が行われた場合、ステップ１１０．２を開始する。ステップ１１０．１および１１０．２は、順に行うことも同時に行うこともできる。区画マネージャとオペレーティング・システム・デバイス・ドライバの両方が、単一のＣＰＵを共用し、したがって、シーケンス１１０．１〜１２０．３および１２２−１３０の個々のステップは、物理的には互いに任意の順序で行うことができるが、区画マネージャとデバイス・ドライバから見ると論理的には順次的に見える。

シーケンス１１０．１ないし１２０．３を考察すると、ステップ１１０．１で、エラーを検出したファブリック・ハードウェア要素は、区画マネージャに対してエラー割込みを通知する。この割込みは、ステップ１１０．２が先に行われた場合でも常に行われ、区画マネージャ・エラー検出を開始させる。すなわち、ステップ１１０．２は、区画マネージャがステップ１１０．１の割込みを受け取る前に行うことができ、ステップ１１０．２は、ファブリック・ハードウェアの検査を開始し、その結果、ステップ１１２．２において、影響を受けるすべてのスロット・マネージャにエラー状況が通知されるようにすることができる。しかし、ファブリック・マネージャ１０６は、ステップ１１０．１で割込みが発生するまで、ステップ１１４のファブリック・エラー状態の回復を開始しない。その割込みが発生すると、デバイス・ドライバがステップ１２４においてすでにファブリック・マネージャ１０６にファブリック・エラー状況を個々のスロット・マネージャ１０８に記憶させていない場合（ステップ１１２．１）、ファブリック・マネージャ１０６割込みハンドラが、この状況を収集し、ステップ１１２．１を実行する。

さらに、区画マネージャは通常、ファブリック要素またはスロットに対して何らかのＩＯ動作（区画マネージャに対する区画呼出しを介して要求されたスロットへの構成ＩＯなど）を行い、それ自体でオール１ロード応答を検出することができる。これが発生した場合、区画マネージャ自体がステップ１１０．２を呼び出して、その経路にエラーがないかファブリックを分析する。

ステップ１１２．１の後で、ファブリック・マネージャ１０６は、ステップ１１４でファブリック・ハードウェア・マネージャ１０２にエラー・イベントを通知する。ファブリック・ハードウェア・マネージャ１０２は、ステップ１１６ないし１２０．１の必要な一連のハードウェア動作を行う。区画マネージャのディスパッチ可能部がすべての直接ハードウェア・アクセスを行うとき、ファブリック・ハードウェア・マネージャ１０２は、ディスパッチ不可区画マネージャに対する区画マネージャ呼出しを使用して、ファブリック・ハードウェア自体に変更を加える。これらの区画マネージャ状態は、ファブリック・ハードウェア・マネージャ１０２が、ファブリック・エラー状態の回復のために必要な一連のハードウェア動作を行うときに、ファブリック・マネージャ１０６が監視する必要があるファブリック要素状態またはハードウェア・モードの変化もファブリック・マネージャ１０６に伝達する。

ステップ１１２．２で、スロット・マネージャ１０８は、区画オペレーティング・システム１０４にエラー・イベントを通知する。区画オペレーティング・システム１０４は、デバイス・ドライバによるＭＭＩＯロードの発行に依存せずに、またはＭＭＩＯロードの発行を待たずにファブリック・エラーまたはスロット・エラーを非同期で検出するために、そのようなイベントの受領を任意選択により有効にする。場合によっては、デバイス・ドライバとＩＯアダプタとの間の通信プロトコルは、デバイス・ドライバがＭＭＩＯストアのみ、またはほぼ常にＭＭＩＯストアのみを実行し、ＭＭＩＯロードは、行うとしてもまれにしか行わないようなものとすることができる。そのような場合、ステップ１１２．２でのイベント・メッセージの受領は、デバイス・ドライバ・シーケンス１２４ないし１３０を開始させるように作用することができる。

ステップ１１６で、ファブリック・ハードウェア・マネージャ１０２は、ファブリック失敗イベントからのエラー状態情報を使用して、エラー状態のファブリック要素を判断し、ハードウェアの回復を開始する。エラー状態にある間、ファブリック要素は、ＭＭＩＯストアおよびＤＭＡを廃棄し、オール１ロード応答を返すことを続け、それによって、区画内で同時に実行されているデバイス・ドライバは、ファブリック・ハードウェア・マネージャ１０２がこのファブリック要素を介して到達した各スロットにおいてこのエラー状態（すなわちフリーズ）を再現することができるまで、この動作を観察することになる。したがって、ステップ１１６で、ファブリック・ハードウェア・マネージャ１０２は、ファブリック・ハードウェア・マネージャ１０２がＩＯアダプタ・スロットでハードウェアにアクセスしてフリーズ状態を引き起こすことができる状態にファブリックを復元させる。

例示の実施形態では、区画デバイス・ドライバが、スロット・マネージャ１０８と直接通信する区画マネージャ呼出しを使用してすべてのＰＣＩ構成ＩＯを行い、それによって、スロット・マネージャ１０８は、（ステップ１１２．１および１１２．２の実施後）構成ＩＯ区画マネージャ呼出しの実行の際に区画に対してファブリック・エラー状況を直接返すことができる。デバイス・ドライバは、アダプタ（スロット）ＰＣＩメモリにマップされた区画仮想アドレスを使用してメモリ・マップＩＯを行い、これらのデバイス・ドライバは、ファブリック要素の回復中に、ロードに対してオール１を返し続け、ストアを廃棄し続けなければならない。したがって、例示の実施形態では、プラットフォーム・スロット・ハードウェアは、ステップ１１６で区画マネージャが、スロットを接続してブリッジにフリーズ状態を設定するＰＣＩ−ＰＣＩブリッジ要素に対する構成ＩＯ動作を使用することができるようにする機構を備える。

次に、ステップ１１６で、ファブリック・ハードウェア・マネージャ１０２は、ファブリック要素を、ファブリック要素をエラー状態にしたまま、構成ＩＯの実行が可能な状態に復元させ、それによって、ファブリック・ハードウェア・マネージャ１０２が、当該ファブリック要素を介して到達する各スロットでこれと同じフリーズまたはエラー状態を設定するまで、メモリ・マップ動作はストアを廃棄し続け、ロードに対してオール１を返し続ける。例示の実施形態ではスロットＰＣＩ−ＰＣＩブリッジに対して構成ＩＯを使用するが、ファブリック・ハードウェアとは別にＰＣＩメモリをマップする別個の個別に有効にされる読取りアドレス・レンジを設け、ステップ１１６の回復中にそのファブリック・アドレス・レンジのみを再び有効にするなど、他の機構をファブリック・ハードウェア内に設けて、同等の機能を提供することもできることが明らかであろう。

ステップ１１８で、ファブリック・ハードウェア・マネージャ１０２は、区画マネージャ呼出しを使用して、ファブリックのＰＣＩ−ＰＣＩブリッジ要素にフリーズ状態を設定する構成ＩＯを実行し、それによって、そのファブリック要素を介して到達した各スロットをエラー状態にする。その後、ステップ１２０．１で、ファブリック・ハードウェア・マネージャ１０２は、ファブリック要素をその通常の動作状態に完全に復帰させ、各スロットにおけるＰＣＩ−ＰＣＩブリッジは、元のファブリック・エラー状態を再現し、ストアとＤＭＡを廃棄し、オール１ロード応答を返し、これによって、影響を受けるＩＯスロットにファブリック・エラーを実質的に伝搬させる。

例示の実施形態では、ＰＣＩ−ＰＣＩブリッジがこの機能を実行するが、たとえば、個々のスロットに割り当てられた、メモリ・マップ・アダプタ・アドレスおよびＤＭＡソース・アドレス・レンジに基づいて、ファブリックの他の要素が同等の機能を実現することも可能であることは明らかであろう。

ステップ１２０．１で、影響を受けた各スロットでフリーズ状態を再現したファブリック・ハードウェア・マネージャ１０２は、ファブリック要素の回復を完了し、ファブリック・マネージャ１０６にファブリックの回復が完了したことを通知する。ファブリック・マネージャ１０６は、ステップ１０２．２で、個々のスロット・マネージャ１０８に対して、ファブリックの回復が完了したことを通知し、スロット・マネージャ１０８はそれぞれの内部スロット状態情報にそれを反映させる。さらに、ステップ１２０．３で、各スロット・マネージャ１０８は、任意選択により、区画オペレーティング・システム１０４に対して、回復が完了したというイベントを通知する。ステップ１１２．２に関連して、区画は任意選択により、シーケンス１２２ないし１３０を開始する手段として、または当該シーケンスのサブセットを開始する手段として、そのようなイベントの受領を有効にすることができる。他の方法として、実施形態によっては区画オペレーティング・システムに対してイベントを渡さず、シーケンス１２４ないし１３０などにおいて、後で区画オペレーティング・システムによるポーリングを使用して、ＩＯファブリック・エラーの回復を検出することもできる。

次に、区画オペレーティング・システム１０４によって実行されるシーケンス１２２ないし１３０を参照すると、ステップ１２２で、区画デバイス・ドライバが、ＭＭＩＯロードからオール１データを受け取った結果として、ファブリック・エラーまたはスロット・エラー状態の発生した可能性があることを認識する。前述のように、区画オペレーティング・システム１０４は、任意選択により、ファブリック・エラー・イベント・メッセージの受領を有効にし、ステップ１２２の代わりとして、または場合によってはステップ１２２の前に、この機構によってファブリック・エラー状態を検出する。

ステップ１２４で、デバイス・ドライバ、またはデバイス・ドライバから呼び出された区画カーネル・ユーティリティが区画マネージャを呼び出して、ファブリック・エラーまたはスロット・エラーが存在する可能性があるか否かを判断する。ステップ１１０．１または１１０．２によって検出されたファブリック・エラーがまだスロット・マネージャ１０８に通知されていない場合、スロット・マネージャ１０８は、ステップ１１０．２を実行し、ファブリック経路にエラー状態がないか分析する。エラー状態が検出された場合、ステップ１１０．２は、そのファブリック状態をスロット・マネージャ１０８に返し、スロット・マネージャ１０８はステップ１２４でこの状況を区画オペレーティング・システムに返す。

この例示の実施形態では、ＰＣＩ−ＰＣＩブリッジは、ＰＣＩ−ＰＣＩブリッジをＩＯアダプタ・スロットに接続するＰＣＩ二次バス上でエラー状態を検出するとファブリック・エラー状態になる。例示の実施形態では、スロット・マネージャ１０８は、ＰＣＩ−ＰＣＩブリッジにもこのエラー状態がないか検査し、この状態が存在する場合、区画オペレーティング・システム１０４に対して、他のファブリック要素とは無関係のスロット・フリーズがあることを示す状況を返す。

ステップ１２６で、区画オペレーティング・システム１０４またはデバイス・ドライバは、任意選択によりスロット・マネージャ１０８を呼び出して、ロギングなどのため、またはファブリック・エラーが回復可能か否かを判断するために、ファブリック・エラーに関する追加の詳細を入手する。ステップ１２８で、デバイス・ドライバまたはオペレーティング・システムは、スロット・マネージャ１０８を呼び出して、スロット・フリーズ状態を解除することによってスロットの回復を開始する。この時点で、スロット・マネージャ１０８は、デバイス・ドライバ・スロットの回復をファブリック・マネージャ１０６ファブリック回復と同期させる。スロット・マネージャ１０８がファブリックの回復をまだ完了していない場合、スロット・マネージャ１０８はステップ１２８でビジー状況を返す。その後、デバイス・ドライバまたはオペレーティング・システムは、ステップ１２０．２でファブリック・マネージャ１０６が完了するまで、ステップ１２８で呼出しを定期的に再試行することができる。

また、ステップ１２８で、ファブリック・エラー状態が、手動介入（ハードウェア・サービス処置やプラットフォーム・リブート、パワー・サイクルなど）を行わないと区画マネージャが通常のファブリック動作を回復することができないようなものである場合、スロット・マネージャ１０８は、スロットが永続的に利用不能であること、すなわち、サービス処置が行われるまでは利用不能であることを示す状況を返す。その場合、デバイス・ドライバは再試行間隔を分単位または時間単位など、大幅に長い間隔にまで延ばすか、あるいは、区画オペレーティング・システム１０４が回復イベントの受領を有効にした場合は、区画マネージャがステップ１２０．３で回復イベントを通知するまでさらに再試行を延ばすことができる。

復帰成功状況の後、ステップ１３０で、デバイス・ドライバは、区画マネージャ呼出しシーケンスを実行し、ＩＯアダプタを動作状態に復帰させ、それによってＩＯアダプタのエラー状態をリセットする。このような処置としては、ＳＣＲＩＲＳＴなどのリセットをアダプタに対して発行し、次に、アダプタを完全に初期設定し直すか、またはＩＯアダプタとデバイス・ドライバの状態を同期させ、ファブリックがエラー状態であった間に廃棄された可能性のある動作を繰り返すことなどが含まれる。ステップ１３０が完了すると、ＩＯアダプタは動作状態に復帰し、ＩＯファブリック・エラーが回復し、ＩＯアダプタとプロセッサ／メモリ・バスｔの間の通信が復旧する。

前述のように、本発明による実施形態は、所与のＩＯファブリック内の回復不能エンドポイントＩＯ資源と回復可能エンドポイントＩＯ資源とを使用することが可能な能力と、システム内の異なるタイプのＩＯ資源の導入に動的に適応可能な能力もサポートすることができる。なお、デバイス・ドライバまたはそのための他の管理プログラム・コードが実際にマシン・チェック・モードを使用して動作を試みるまでは、資源が回復可能か回復不能かを特定することは実際には不可能なことが多いことは理解されよう。したがって、例示の実施形態では、そのような場合を検出し、ＩＯファブリックの１セグメントが他の区画を妨害せずにマシン・チェック・モードで動作することができるようなＩＯ構成である場合を判断し、ＩＯファブリックの適切な要素を適切な時点でマシン・チェック・モードにしたり、マシン・チェック・モードから復帰させたりするように切り換えるオペレーティング・システム機能または区画マネージャ機能を組み込むことが望ましい。また、システム自体がそのような状態を検出し、ＩＯファブリックの動作モードを動的に変更して、異なる区画のその時々の要件に対応することも、例示の実施形態の望ましい機能である。

論理区画化されたシステムでは、望ましくは、１つの区画によるＩＯエラーの検出が、影響を受けたＩＯファブリック要素を共有する他の区画によるＩＯ動作の区画マネージャ回復および再開を妨害してはならない。この例示の実施形態は、ＩＯファブリック・エラーの発生直後にそのＩＯファブリック・エラーを回復すると共に、その一方で、影響を受けたデバイス・ドライバがＩＯラー状態が発生したことを最終的に確実に検出するという前述の要件と、デバイス・ドライバがそのエラーを検出してアダプタ回復を開始するまでアダプタとの間のデータ伝送が行われないという前述の要件を保持するという問題にも対処する。

同様に、論理区画化システムでは、望ましくは、１つの区画がマシン・チェック・モードで動作するという要件によって、回復可能デバイス・ドライバを使用している他の区画がマシン・チェックをその必要もないのに受けるということがあってはならない。したがって、例示の実施形態では、マシン・チェックが必要なデバイス・ドライバおよび区画についてマシン・チェックを検出し、有効にし、他の区画がマシン・チェックを必要としない場合には、他の区画がマシン・チェック・モードの作用を受けないようにするという問題にも対処する。

したがって、この例示の実施形態では、オペレーティング・システムのデバイス・ドライバの集合内に回復可能なタイプと回復不能なタイプの両方のデバイス・ドライバが存在する可能性があると仮定し、その区画オペレーティング・システムに割り当てられた様々なスロットを各デバイス・ドライバが制御するものと仮定する。回復不能デバイス・ドライバは、古い「レガシ」技術を示しており、通常は、オペレーティング・システム内の回復不能デバイス・ドライバ・プロトコルより以前のものである。したがって、ＩＯファブリック内の回復可能デバイス・ドライバ機能を有効にすることは、一般には、より新しいオペレーティング・システム・カーネル・サービスおよびデバイス・ドライバの機能であり、このモデルをサポートするＩＯファブリック・ハードウェア自体内の新しい機能に加えて備えるものである。たとえば、ＡＩＸオペレーティング・システムを使用するコンピュータの中には、拡張エラー処理（ＥＥＨ）と呼ばれる回復可能プロトコルを使用するものもある。

マシン・チェックを起こさないＩＯファブリック・エラー状態を有効にするのは、新しいデバイス・ドライバおよびカーネル・サービスであることが多いにも関わらず、特に論理区画化システムでは、これらの新しい回復可能デバイス・ドライバは主要なタイプのデバイス・ドライバを構成し、区画オペレーティング・システムにおいて設定されているデバイス・ドライバの大多数を占めると見込まれる。したがって、例示の実施形態では、区画マネージャは、デフォルトで、マシン・チェック通知を禁止または抑止するファブリック初期状態をとり、オペレーティング・システム・カーネル・ユーティリティに依存して、より古い回復不能デバイス・ドライバを検出し、区画マネージャに対して、ＩＯファブリック内でマシン・チェック通知モードをアクティブにするように要求することが望ましい。

本発明によるＩＯファブリックの混在動作モードを例示するために、図５に、他のコンピュータ・アーキテクチャ５０’を示す。このアーキテクチャ５０’では、ＩＯスロット５６’に回復不能エンドポイントＩＯ資源が実装されている。このＩＯ資源と、コンピュータ内のアクセス側プロセッサ、たとえばプロセッサ／メモリ・バス６２に結合されたプロセッサ５８のうちの１つのプロセッサとの間の経路は、ＲＩＯハブ６８’と、ＲＯＩブリッジ７０’と、ＰＨＢ７２’と、ＰＣＩ−ＰＣＩブリッジ７４’とを含む。本発明によると、ＩＯスロット５６’内のＩＯ資源の管理に関連して回復不能デバイス・ドライバを使用する場合は常に、ＩＯスロット５６’とプロセッサ／メモリ・バス６２との間の経路内の各ＩＯファブリック要素６８’ないし７４’は、マシン・チェックを有効にするように設定される。

次に、図６を参照すると、マシン・チェック通知を必要とする回復不能デバイス・ドライバ１５２を検出し、マシン・チェック通知を行うためにＩＯファブリック・ハードウェア動作モードをファブリック・エラー状態またはスロット・エラー状態から変更する流れ１５０の一例が図示されている。区画マネージャのファブリック・マネージャ１５４とスロット・マネージャ１５６とが、デバイス・ドライバ１５２が常駐する区画内に設けられたサポートＯＳカーネル・サービス１５８と共に図示されている。さらに、ＰＣＩ−ＰＣＩブリッジ１６２、ＰＨＢ１６４、ＲＩＯブリッジ要素１６６、およびＲＩＯハブ要素１６８などの複数の例示のファブリック要素と共に、論理区画（ＬＰＡＲ）構成データベース１６０がファブリック・マネージャ１５４に結合されている様子が図示されている。

回復不能デバイス・ドライバの検出に応答したＩＯファブリックの動的再構成は、図６のステップ１７０．１ないし１８６のシーケンスに示されている。具体的には、この例では、回復可能デバイス・ドライバ１５２がステップ１７０．１を実行してカーネル・ユーティリティ１５８に、当該デバイス・ドライバ１２４が回復可能なタイプであり、マシン・チェック通知を必要としないことを通知し、さらにカーネル・ユーティリティ１５８がこれを区画マネージャに通知する（ステップ１７０．２）ものと仮定する。例示の実施形態では、典型的には、区画マネージャはすでにＩＯファブリックを初期設定してマシン・チェック通知を禁止していることになり、したがって、この動作は、カーネル・サービスおよび区画マネージャに関しては状態報告動作のようなものである。

ステップ１７２で、デバイス・ドライバ１５２は、そのデバイス・ドライバに関連づけられたＩＯアダプタを、メモリ・マップ・ロードおよびストアと、ＤＭＡおよび割込みのために有効にすることによって、そのＩＯアダプタを使用する準備を行うことができる。ＰＣＩアダプタを使用するこの例示の実施形態では、ステップ１７２は、デバイス・ドライバ１５２が区画マネージャを呼び出して、メモリ、ＩＯ、またはマスタ動作（ＤＭＡ）有効化ビットを「１」に設定してアダプタ・コマンド・レジスタへの構成ＩＯストアを行うものとすることができる。

ステップ１７２の前に、デバイス・ドライバ１５２がステップ１７０．１を実行していない場合、オール１エラー検出を実施しないデバイス・ドライバ１５２は、古い（レガシ）タイプのデバイス・ドライバであるものとみなされ、ＭＭＩＯロードが失敗するとマシン・チェックを必要とする（すなわち、デバイス・回復不能である）ものと解釈される。マシン・チェック無効化呼出し（ステップ１７０．１および１７０．２）およびＭＭＩＯ有効化呼出し（ステップ１７２）を実施するカーネル・サービス１５８または区画マネージャのいずれかが、この検出を行うことができる。ただし、例示の実施形態では、この検出はカーネル・サービス１５８に委ねられ、ステップ１７２のＭＭＩＯロード有効化サービスの実行の一部として、カーネル・サービス１５８が区画マネージャ内の適切なスロット・マネージャ１５６を呼び出して（ステップ１７４）、マシン・チェック・モードを有効にする。

したがって、この実施形態では、デバイス・ドライバが、たとえば資源の初期設定を試みるときなど、資源のバインド、資源の構成、またはその他の方法でデバイス・ドライバと資源との間の通信を確立するために資源へのアクセスを試みることに関連して、単にマシン・チェック通知無効化要求が存在しないことを検出するだけで回復不能資源が検出される。代替態様では、たとえば、デバイス・ドライバの起動時またはオペレーティング・システムへのバインド時に、オペレーティング・システムによって指定された他のカーネル呼出しが行われないことなど、他の回復不能資源検出方式も使用可能であることがわかるであろう。

論理区画化システムでは、例示の実施形態の区画マネージャの重要な機能は、区画間分離を確実にすることであり、これには、１つの区画の動作が他の区画の可用性に影響を及ぼさないようにすることが含まれる。この場合、区画化システムの目的は、所与のＩＯスロットについての１つの区画によるマシン・チェック・モードの有効化の作用が、できる限り当該区画のみに限られるようにする必要がある。例示の実施形態では、区画マネージャは、デバイス・ドライバがマシン・チェック通知を有効にすることができる構成を制限し、それによって、特定の区画が、その区画に割り当てられているＩＯスロットであって他の区画には割り当てられていないＩＯスロットのみを接続するＩＯファブリックの範囲内に限って、マシン・チェックを有効にすることができるようにする。

したがって、ステップ１７６で、ファブリック・マネージャ１５４は、論理区画構成データベース１６０を調べて、マシン・チェック有効化が要求されているスロットが、この制限を満たすファブリック領域内にあるか否かを判断する。すなわち、区画マネージャは、ファブリック内の一カ所でマシン・チェック・モードを設定することができる場合に、区画がマシン・チェック・モードを設定することができるようにし、それによって、その一カ所を対象とするすべてのＭＭＩＯロードは、その区画のみに割り当てられたスロットに関するものとなるようにする。たとえば、例示の実施形態では、ＰＨＢは、そのＰＨＢより下位のスロットについてマシン・チェック通知を有効にすることができる箇所であり、他のＰＨＢ上のスロットを使用する他の区画がマシン・チェックを受けないようになっている。したがって、例示の実施形態では、区画マネージャは、そのＰＨＢを介して接続されているすべてのスロットが同じ区画に割り当てられている場合にのみ、ステップ１７４で、区画がマシン・チェック・モードを設定することができるようにする。その結果、区画マネージャは、ＰＨＢおよびＩＯファブリック内のＰＨＢより上位の要素がマシン・チェック・モードに設定されるときに、これらのスロットの１つが他の論理区画に再割当てされないようにする。

上記以外の場合、区画マネージャはステップ１７４で、区画マネージャ呼出しに対して障害状況を返し、さらにステップ１７２でカーネル・サービス１５８がデバイス・ドライバ１５２に対して障害状況を返す。これによって、デバイス・ドライバ１５２は、マシン・チェック・モードを設定すると区画間ポリシーおよびシステム全体の機構と矛盾することになる場合には、付随するＩＯアダプタを動作させることができなくなる。

ＩＯスロット割当ておよび物理構成によって、マシン・チェック・モードを有効にすることができるものと仮定すると、区画マネージャはステップ１７８ないし１８６で、ファブリック内の各要素の動作モードの変更に進む。これによって、各要素は、まず、ファブリックの最も外側の要素（たとえば当該スロットのＰＣＩ−ＰＣＩブリッジ１６２）から開始して（ステップ１８０）、当該スロットをプロセッサ／メモリ・バスに接続するＩＯファブリックの残りの要素、たとえばＰＨＢ１６４（ステップ１８２）、ＲＩＯブリッジ要素１６６（ステップ１８４）、およびＲＩＯハブ要素１６８（ステップ１８６）を順に遡って、エラー状態にある場合にマシン・チェックを通知する。他の実施形態では他の順序も用いることができる。

図５に戻り、区画マネージャが、ＩＯスロット５６’に装着されているＩＯ資源のデバイス・ドライバが、回復不能な性質のものであることを検出したものと仮定すると、当該ＩＯ資源とプロセッサ／メモリ・バスとの間の経路に配置された各ファブリック要素は、ＰＣＩ−ＰＣＩブリッジ７４’、ＰＨＢ７２’、ＲＩＯブリッジ７０’、およびＲＩＯハブ６８’を含めて、前述の流れにより、マシン・チェック・モードが有効にされる。

図６を参照すると、例示の論理区画化システムの実施形態では、区画は互いに独立して（論理的に）電源オン、電源オフ、またはリブートすることができることがわかるであろう。したがって、１つまたは複数のスロットについてマシン・チェック・モードを設定していた区画が電源オフまたはリブートすると、区画マネージャのディスパッチ可能部は、その区画に割り当てられた各スロットについてスロット・マネージャ１５６に通知する。区画マネージャは、スロットの何らかの最初期設定を行って、そのスロットを、他の区画に再割当てされる場合に備えて、または当該区画が次にブートするときに同じ区画内で当該スロットが再起動される場合に備えて準備する。特に、区画リブートには、デバイス・ドライバの更新または交換が伴うことが多い。たとえば、区画リブートまたは電源オフおよびオンの一環として、スロットの回復不能デバイス・ドライバがそのスロットのＩＯアダプタの回復可能デバイス・ドライバに置き換えられることなどがある。

そのような状況では、区画の電源オフまたはリブートと共に、ファブリック・マネージャ１５４は、区画がそのデバイス・ドライバを終了させたことも認識することが望ましく、当該ファブリック領域内でアクティブのままになっている他のスロットについてマシン・チェック・モードが不要になった場合、ファブリック・エラー・モードをマシン・チェックの抑止に戻すことが望ましい。この場合、ファブリック・ハードウェア・マネーは、終了した区画に付随するスロットについてスロット・マネージャ１５６に通知し、さらにスロット・マネージャ１５６がファブリック・マネージャ１５４に通知する。次に、ファブリック・マネージャ１５４は、ステップ１８０ないし１８６のシーケンスを逆転させ、その結果、マシン・チェック通知モードになっていたファブリック要素がマシン・チェックを通知しなくなるように設定される。

マシン・チェック・モードへの切り換えとマシン・チェック・モードからの復帰を可能にするか否かを制御する様々なポリシーを実施することができる。たとえば、論理区画化システムでは、スロットのマシン・チェック・モードへの切り換えは、当該スロットを持つ区画が同じＰＨＢ上の他のすべてのスロット（任意選択として、空のスロットも含む）も持つことを条件とすることが望ましい場合がある。また、そのような切り換えは、さらに、区画間動作が分離されるような方式でファブリックを共用するクラスタ・システムなどのファブリックのトポロジ、または他のエラー状態を条件とすることが望ましい場合もある。

また、ＩＯファブリック要素は、典型的には、所与のＰＨＢ内のすべてのスロットがマシン・チェック・モードから復帰することを条件として、マシン・チェック通知無効状態に復帰する。また、区画マネージャは、マシン・チェック有効ＰＨＢ上のスロットが、区画マネージャまたは他の区画に移行しないようにすることが望ましい場合がある。

ＩＯファブリック要素を、マシン・チェック通知が有効なモードと抑止されるモードとの間で動的に切り換える機能の実現は、本開示の恩恵を受ける当業者の能力の範囲内にあることがわかるであろう。さらに、本明細書に記載の機能のソフトウェアによる実現も、同様に、本開示の恩恵を受ける当業者の能力の範囲内にある。

本開示の恩恵を受ける当業者には、本明細書に記載の実施形態に加えられる様々な変更が明らかであろう。したがって、本発明は、特許請求の範囲に存在する。

本発明による論理区画化されたコンピュータのハードウェア構成要素の一部を示すブロック図である。 図１に示す論理区画化アーキテクチャの代替態様を示すブロック図である。 本発明による自動回復機能と共に使用可能なＩＯファブリックの一例を示すブロック図である。 図３のＩＯファブリックにおけるＩＯファブリック・エラーの検出と回復を示すフローチャートである。 回復不能なエンドポイントＩＯ資源の導入後の、図３のＩＯファブリックを示すブロック図である。 回復不能なエンドポイントＩＯ資源の導入に応答する、図４のＩＯファブリックの非マシン・チェックとマシン・チェック・モードとの動的切り換えを示すフローチャートである。

符号の説明

１０ コンピュータ
１２ システム・プロセッサ
１４ メモリ
１６ バス
１８ ハードウェア／スレッド
２０ ＩＯファブリック
２２ ネットワーク・アダプタ
２４ ネットワーク
２６ 記憶制御装置
２８ ワークステーション・コントローラ
３２ ワークステーション
３４ 区画
３６ 区画マネージャ
３８ 区画マネージャ（ディスパッチ不可部）
４０ 区画マネージャ（ディスパッチ可能部）
４２ オペレーティング・システム
４４ ユーザ・アプリケーション
４６ 仮想ＬＡＮ
５２ ＩＯファブリック
５４ メモリ
５６ スロット
５８ プロセッサ
６０ メモリ
６８ ＲＩＯハブ
７０ ＲＩＯブリッジ
７２ ＰＣＩホスト・ブリッジ
７４ ＰＣＩ−ＰＣＩブリッジ

Claims (41)

1. 論理区画化されたコンピュータであって、
   複数のプロセッサと、
   複数のＩＯアダプタ・スロットと、
   前記複数のプロセッサに結合され、前記複数のＩＯアダプタ・スロットへのプロセッサ・アクセスを可能にするように構成された入出力（ＩＯ）ファブリックであって、各前記ＩＯアダプタ・スロットと前記複数との間の複数のハードウェア経路を規定する複数のＩＯファブリック要素を有し、前記複数のＩＯファブリック要素が前記複数のＩＯアダプタ・スロットのサブセットへのアクセスを可能にする第１のＩＯファブリック要素を含む、入出力（ＩＯ）ファブリックと、
   前記複数のプロセッサのうちの少なくとも１つのプロセッサ上で実行される複数の論理区画と、
   前記複数の論理区画のうちの１つの論理区画内に存在し、前記複数のＩＯアダプタ・スロットのうちの第１のＩＯアダプタ・スロットにアクセスするように構成されたデバイス・ドライバと、
   前記複数のプロセッサのうちの少なくとも１つのプロセッサ上で実行され、前記複数の論理区画を管理するように構成された区画マネージャと、
   前記区画マネージャ内に存在し、前記第１のＩＯファブリック要素内で検出されたエラーに応答してＩＯアダプタの各サブセットについてエラー状態を設定し、前記複数のＩＯアダプタ・スロットのそれぞれについて前記エラー状態が設定された後で、前記第１のＩＯファブリック要素における前記エラーから回復するように構成された第１のプログラム・コードと、
   前記区画マネージャ内に存在し、前記デバイス・ドライバが回復不能なデバイス・ドライバであることを検出し、その検出に応答して、前記第１のＩＯアダプタ・スロットと前記複数のプロセッサとの間のハードウェア経路内に規定された各ＩＯファブリック要素においてマシン・チェック通知を動的に有効にするように構成された第２のプログラム・コードと、
   を有する論理区画化コンピュータ。
2. 複数のエンドポイントＩＯ資源へのアクセスを可能にする少なくとも１つのＩＯファブリック要素を含む入出力（ＩＯ）ファブリックにおけるエラーを処理する方法であって、前記ＩＯファブリック要素において検出されたエラーに応答して、
   前記複数のエンドポイントＩＯ資源のそれぞれについてエラー状態を設定するステップと、
   前記ＩＯファブリック要素における前記エラーから回復するステップとを有する方法。
3. 前記ＩＯファブリック要素における前記エラーからの回復後に、前記複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源にアクセスすることができるオペレーティング・システム内で、
   前記第１のエンドポイントＩＯ資源の前記エラー状態を検出し、前記第１のエンドポイントＩＯ資源上でエラー回復を実行するステップと、
   前記第１のエンドポイントＩＯ資源について前記エラー状態をリセットするステップと、
   をさらに有する、請求項２に記載の方法。
4. 前記ＩＯファブリック要素における前記エラーからの回復後に、前記複数のエンドポイントＩＯ資源のそれぞれについて前記エラー状態を非同期でリセットするステップをさらに有する、請求項２に記載の方法。
5. 前記複数のエンドポイントＩＯ資源のそれぞれについて前記エラー状態を非同期でリセットする前記ステップは、前記複数のエンドポイントＩＯ資源のそれぞれを対象とするアクセス要求に応答して実行される、請求項４に記載の方法。
6. 前記ＩＯファブリック要素における前記エラーからの回復後に、前記複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源において前記エラー状態の通知を生成するステップをさらに有し、前記第１のエンドポイントＩＯ資源について前記エラー状態を非同期でリセットする前記ステップは、前記通知に応答して実行される、請求項４に記載の方法。
7. 前記ＩＯファブリック要素は、ペリフェラル・コンポーネント・インターコネクト（PeripheralComponent Interconnect：ＰＣＩ）ホスト・ブリッジと、多機能ＰＣＩ−ＰＣＩブリッジ装置と、リモート入出力（ＲＩＯ）ブリッジと、ＲＩＯハブと、スイッチ装置とから成るグループから選択される、請求項２に記載の方法。
8. 前記複数のエンドポイントＩＯ資源はＩＯアダプタ・スロットを含む、請求項２に記載の方法。
9. 前記ＩＯファブリックはメモリ・マップ入出力（ＭＭＩＯ）ファブリックである、請求項２に記載の方法。
10. 前記ＩＯファブリックは、区画マネージャによって管理される複数の論理区画を含むタイプの論理区画化コンピュータに結合され、各エンドポイントＩＯ資源が前記複数の論理区画のうちの論理区画に割り振られ、各エンドポイントＩＯ資源について前記エラー状態を設定する前記ステップと前記ＩＯファブリック要素における前記エラーから回復する前記ステップとが、前記区画マネージャによって開始される方法であって、
    前記ＩＯファブリック要素における前記エラーからの回復後に、エンドポイントＩＯ資源の前記エラー状態を、該エンドポイントＩＯ資源が割り振られている論理区画内のデバイス・ドライバによって生成されたアクセス要求に応答して、該デバイス・ドライバに返すステップと、
    前記エラー状態からの復帰に応答して、前記デバイス・ドライバを使用して前記エンドポイントＩＯ資源における前記エラー状態から回復するステップと、
    をさらに有する、請求項２に記載の方法。
11. 前記複数のエンドポイントＩＯ資源のうちの１つのエンドポイント資源を対象とするロード動作の結果から、前記ＯＩファブリック要素における前記エラーを検出するステップをさらに有する、請求項２に記載の方法。
12. 前記ＩＯファブリック要素がエラー状態になることに応答して生成された割込みから、前記ＩＯファブリック要素における前記エラーを検出するステップをさらに有する、請求項２に記載の方法。
13. 少なくとも１つのプロセッサと、
    少なくとも１つの前記プロセッサに結合され、複数のエンドポイントＩＯ資源へのプロセッサ・アクセスを可能にする少なくとも１つのＩＯファブリック要素を有するＩＯファブリックと、
    前記複数のエンドポイントＩＯ資源のそれぞれについてエラー状態を設定し、前記ＩＯファブリック要素におけるエラーから回復することによって、前記ＩＯファブリック要素において検出されたエラーを処理するように構成されたプログラム・コードと、
    を有する装置。
14. 前記プログラム・コードの少なくとも一部は、前記複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源にアクセスすることができるオペレーティング・システム内に存在し、前記プログラム・コードの前記一部は、前記第１のエンドポイントＩＯ資源のエラー状態を検出し、前記第１のエンドポイントＩＯ資源上でエラー回復を実行し、前記ＩＯファブリック要素における前記エラーからの回復後に、前記第１のエンドポイントＩＯ資源について前記エラー状態をリセットするように構成された、請求項１３に記載の装置。
15. 前記プログラム・コードは、前記ＩＯファブリック要素における前記エラーからの回復後に、前記複数のエンドポイントＩＯ資源のそれぞれについて前記エラー状態を非同期でリセットするようにさらに構成された、請求項１３に記載の装置。
16. 前記プログラム・コードは、前記複数のエンドポイントＩＯ資源のそれぞれを対象とするアクセス要求に応答して、前記複数のエンドポイントＩＯ資源のそれぞれについて前記エラー状態を非同期でリセットするように構成された、請求項１５に記載の装置。
17. 前記プログラム・コードは、前記ＩＯファブリック要素における前記エラーからの回復後に、前記複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源において前記エラー状態の通知を生成するようにさらに構成され、前記プログラム・コードは、前記通知に応答して前記第１のエンドポイントＩＯ資源の前記エラー状態を非同期でリセットするように構成された、請求項１５に記載の装置。
18. 前記ＩＯファブリック要素は、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）ホスト・ブリッジと、多機能ＰＣＩ−ＰＣＩブリッジ装置と、リモート入出力（ＲＩＯ）ブリッジと、ＲＩＯハブと、スイッチ装置とから成るグループから選択される、請求項１３に記載の装置。
19. 区画マネージャによって管理される複数の論理区画をさらに有し、各エンドポイントＩＯ資源が前記複数の論理区画のうちの１つの論理区画に割り振られ、前記プログラム・コードの少なくとも一部は、前記区画マネージャ内に存在し、前記プログラム・コードは、前記ファブリック要素における前記エラーの回復後に、エンドポイントＩＯ資源が割り振られている論理区画内のデバイス・ドライバによって生成されたアクセス要求に応答して、該エンドポイントＩＯ資源のエラー状態を該デバイス・ドライバに返し、前記エラー状態に応答して、該デバイス・ドライバを使用して該エンドポイントＩＯ資源における前記エラー状態から回復するようにさらに構成された、請求項１３に記載の装置。
20. ＩＯファブリック内に配置され、複数のエンドポイントＩＯ資源へのアクセスを可能にするように構成されたＩＯファブリック要素において検出されたエラーに応答して、前記複数のエンドポイントＩＯ資源のそれぞれについてエラー状態を設定し、前記ＩＯファブリック要素における前記エラーから回復するように構成されたプログラム・コードと、
    前記プログラム・コードを担持する信号担持媒体と、
    を有するプログラム製品。
21. 前記信号担持媒体は、伝送媒体と記録可能媒体とのうちの少なくとも一方を含む、請求項２０に記載のプログラム製品。
22. 少なくとも１つのプロセッサが複数のエンドポイントＩＯ資源にアクセスすることができるようにする複数のＩＯファブリック要素を有するＩＯファブリックを動的に構成する方法であって、
    前記複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源が回復不能な資源であることを検出するステップと、
    前記検出に応答して、前記プロセッサと前記第１のエンドポイントＩＯ資源との間のハードウェア経路内に規定された各ＩＯファブリック要素においてマシン・チェック通知を動的に有効にするステップと、
    を有する方法。
23. 前記第１のエンドポイントＩＯ資源が回復不能資源であることを検出する前記ステップは、前記第１のエンドポイントＩＯ資源にアクセスを試みるデバイス・ドライバによるマシン・チェック通知を無効にする要求がないことを検出するステップを有する、請求項２２に記載の方法。
24. 前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されているか否かを判断するステップをさらに有し、前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されている場合にのみ、マシン・チェック通知を動的に有効にする、請求項２２に記載の方法。
25. 前記少なくとも１つのプロセッサは、複数の論理区画を含む論理区画化コンピュータ内に配置され、前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されているか否かを判断する前記ステップは、前記第１のエンドポイントＩＯ資源が同じ論理区画にバインドされたエンドポイントＩＯ資源のみに対するアクセスを可能にするファブリック領域に配置されているか否かを判断するステップを含む、請求項２４に記載の方法。
26. 前記ファブリック領域は、複数のＰＣＩ−ＰＣＩブリッジを介して前記複数のエンドポイントＩＯ資源のサブセットに結合されたＰＣＩホスト・ブリッジを有する、請求項２５に記載の方法。
27. ファブリック領域によってアクセスすることができるエンドポイントＩＯに回復不能なエンドポイントＩＯがないことを検出するとそれに応答して、前記ファブリック領域内の各ＩＯファブリック要素におけるマシン・チェック通知を動的に無効にするステップをさらに有する、請求項２５に記載の方法。
28. 前記ファブリック領域内に配置された第２のエンドポイントＩＯ資源を他の論理区画に割り振ることができないようにするステップをさらに有する、請求項２５に記載の方法。
29. 前記複数のＩＯファブリック要素は、少なくとも１つのリモート入出力（ＲＩＯ）ハブと、少なくとも１つのＲＩＯブリッジと、少なくとも１つのＰＣＩホスト・ブリッジと、少なくとも１つのＰＣＩ−ＰＣＩブリッジとを有し、前記プロセッサと前記第１のエンドポイントＩＯ資源との間のハードウェア経路は、前記ＲＩＯハブと、前記ＲＩＯブリッジと、前記ＰＣＩホスト・ブリッジと、前記ＰＣＩ−ＰＣＩブリッジとを有する、請求項２２に記載の方法。
30. マシン・チェック通知を無効にするように前記ＩＯファブリックを初期設定するステップをさらに有する、請求項２２に記載の方法。
31. 少なくとも１つのプロセッサと、
    複数のＩＯファブリック要素を有し、前記少なくとも１つのプロセッサを複数のエンドポイントＩＯ資源に結合するように構成されたＩＯファブリックと、
    前記ＩＯファブリックに結合された第１のエンドポイントＩＯ資源が回復不能な資源であることを検出し、その検出に応答して、前記プロセッサと前記第１のエンドポイントＩＯ資源との間のハードウェア経路内に規定された各ＩＯファブリック要素においてマシン・チェック通知を動的に有効にするように構成されたプログラム・コードと、
    を有する装置。
32. 前記プログラム・コードは、前記第１のエンドポイントＩＯ資源にアクセスを試みるデバイス・ドライバによるマシン・チェック信号の無効化要求がないことを検出することによって、前記第１のエンドポイントＩＯ資源が回復不能な資源であることを検出するように構成された、請求項３１に記載の装置。
33. 前記プログラム・コードは、前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されているか否かを判断するようにさらに構成され、前記プログラム・コードは、前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されている場合にのみマシン・チェック通知を動的に有効にするように構成された、請求項３１に記載の装置。
34. 前記少なくとも１つのプロセッサは、複数の論理区画を含む論理区画化コンピュータ内に配置され、前記プログラム・コードは、前記第１のエンドポイントＩＯ資源が、同じ論理区画にバインドされたエンドポイントＩＯ資源のみに対するアクセスを可能にするファブリック領域内に配置されているか否かを判断することによって、前記第１のエンドポイントＩＯ資源についてマシン・チェック通知が許可されているか否かを判断するように構成された、請求項３３に記載の装置。
35. 前記ファブリック領域は、複数のＰＣＩ−ＰＣＩブリッジを介して前記複数のエンドポイントＩＯ資源のサブセットに結合されたＰＣＩホスト・ブリッジを有する、請求項３４に記載の装置。
36. 前記プログラム・コードは、ファブリック領域によってアクセスすることができるエンドポイントＩＯ資源に回復不能なエンドポイントＩＯ資源がないと判断するとそれに応答して、前記ファブリック領域内の各ＩＯファブリック要素においてマシン・チェック通知を動的に無効にするように構成された、請求項３４に記載の装置。
37. 前記プログラム・コードは、前記ファブリック領域内に配置された第２のエンドポイントＩＯ資源を他の論理区画に割り振ることを禁止するように構成された、請求項３４に記載の装置。
38. 前記複数のＩＯファブリック要素は、少なくとも１つのリモート入出力（ＲＩＯ）ハブと、少なくとも１つのＲＩＯブリッジと、少なくとも１つのＰＣＩホスト・ブリッジと、少なくとも１つのＰＣＩ−ＰＣＩブリッジとを有し、前記プロセッサと前記第１のエンドポイントＩＯ資源との間のハードウェア経路は、前記ＲＩＯハブと、前記ＲＩＯブリッジと、前記ＰＣＩホスト・ブリッジと、前記ＰＣＩ−ＰＣＩブリッジとを有する、請求項３１に記載の装置。
39. 前記プログラム・コードは、前記ＩＯファブリックを初期設定してマシン・チェック通知を無効にするように構成された、請求項３１に記載の装置。
40. ＩＯファブリックを介して少なくとも１つのプロセッサに結合された複数のエンドポイントＩＯ資源のうちの第１のエンドポイントＩＯ資源が回復不能資源であることを検出し、その検出に応答して、前記プロセッサと前記第１のエンドポイントＩＯ資源との間のハードウェア経路内に規定された前記ＩＯファブリック内の複数のＩＯファブリック資源のそれぞれにおいてマシン・チェック通知を動的に有効にするように構成されたプログラム・コードと、
    前記プログラム・コードを担持する信号担持媒体と、
    を有するプログラム製品。
41. 前記信号担持媒体は、伝送媒体と記録可能媒体とのうちのいずれか一方を含む、請求項４０に記載のプログラム製品。

Images