(57)【要約】      （修正有）【課題】コンピュータシステムをソフトパーティショニングするシステムおよび方法を提供する。【解決手段】それぞれがオペレーティングシステム（２０６、２０９、２１２、２１５）を実行する複数のソフトパーティションにコンピュータシステムをパーティショニングすること、および前記複数のソフトパーティションのそれぞれにつき、個別のファームウェアインスタンス（２０５、２０８、２１１、２１４）をインスタンス化すること、を含み、前記ファームウェアインスタンスのそれぞれは、該ファームウェアインスタンスの各ソフトパーティションの前記オペレーティングシステム用の事前に定義されたファームウェアインターフェースを提供する。【選択図】図２
2006024214.tif 000002
【特許請求の範囲】
【請求項１】
それぞれがオペレーティングシステム（２０６、２０９、２１２、２１５）を実行する複数のソフトパーティションにコンピュータシステムをパーティショニングする（３０１）こと、および
前記複数のソフトパーティションのそれぞれにつき、個別のファームウェアインスタンス（２０５、２０８、２１１、２１４）をインスタンス化する（３０２）こと、
を含み、
前記ファームウェアインスタンスのそれぞれは、該ファームウェアインスタンスの各ソフトパーティションの前記オペレーティングシステム用の事前に定義されたファームウェアインターフェースを提供する、
方法。
【請求項２】
前記事前に定義されたファームウェアインターフェースは、標準ＩＰＦファームウェアインターフェースを備える、請求項１に記載の方法。
【請求項３】
前記複数のソフトパーティションの第１のソフトパーティションから前記複数のソフトパーティションの第２のソフトパーティションへ少なくとも１つの資源を移動させること、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記移動させることは、
構成データベースを更新し、前記少なくとも１つの資源が前記第２のパーティションに割り当てられることを指定すること、前記第１のパーティションの前記ファームウェアインターフェースを使用し、前記第１のパーティションから前記少なくとも１つの資源を除去すること、および前記第２のパーティションの前記ファームウェアインターフェースを使用し、前記第２のパーティションに前記少なくとも１つの資源を追加すること、
を含む、請求項３に記載の方法。
【請求項５】
前記第１のパーティションの前記ファームウェアインターフェースを使用し、前記第１のパーティションから前記少なくとも１つの資源を除去することは、前記ファームウェアインターフェースによってサポートされたホットプラグ命令を使用し、前記少なくとも１つの資源を除去することを含む、請求項４に記載の方法。
【請求項６】
前記第２のパーティションの前記ファームウェアインターフェースを使用し、前記第２のパーティションに前記少なくとも１つの資源を追加することは、前記ファームウェアインターフェースによってサポートされたホットプラグ命令を使用し、前記少なくとも１つの資源を追加することを含む、請求項４に記載の方法。
【請求項７】
それぞれがオペレーティングシステム（２０６、２０９、２１２、２１５）を実行する複数のソフトパーティションと、
該複数のソフトパーティションのそれぞれについてのファームウェアインスタンス（２０５、２０８、２１１、２１４）であって、該ファームウェアインスタンスのそれぞれが、該ファームウェアインスタンスの各ソフトパーティションの前記オペレーティングシステム用の標準ファームウェアインターフェースを提供する、ファームウェアインスタンスと、
を備えるシステム。
【請求項８】
各ソフトパーティションについて、少なくとも１つのＩＰＦプロセッサ、
をさらに備え、
前記標準ファームウェアインターフェースはＩＰＦファームウェアインターフェースである、
請求項７に記載のシステム。
【請求項９】
ＩＰＦベースのコンピュータシステムを複数のソフトパーティションにパーティショニングする（１１０１）こと、
前記複数のソフトパーティションの第１のソフトパーティション上で第１のタイプのオペレーティングシステムのインスタンスを実行する（１１０２）こと、および
前記複数のソフトパーティションの第２のソフトパーティション上で第２のタイプのオペレーティングシステムのインスタンスを実行する（１１０３）こと、
を含み、
前記第２のタイプのオペレーティングシステムは、前記第１のタイプのオペレーティングシステムと異なる、
方法。
【請求項１０】
前記第１のタイプのオペレーティングシステムおよび前記第２のタイプのオペレーティングシステムは、それぞれ、ＩＰＦ  ＬＩＮＵＸ、ＷＩＮＤＯＷＳ、Ｏｐｅｎ  ＶＭＳ、およびＩＰＦ  ＨＰ−ＵＸから成る群から選択される、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムをソフトパーティショニングするシステムおよび方法に関する。
【０００２】
［関連出願］
本出願は、２００４年７月８日に出願された「System and Method for Soft Partitioning a Computer System」という発明の名称の米国仮特許出願第６０／５８６，２０１号の優先権を主張する。この米国仮特許出願の開示は、参照により本明細書に援用される。
【背景技術】
【０００３】
従来のコンピュータプラットフォームは、複数の中央処理装置（ＣＰＵ）がオペレーティングシステム（ＯＳ）の単一のコピーを実行する対称型マルチプロセッサ（ＳＭＰ）機構であった。ＯＳは、複数のアプリケーションの実行を可能にする時分割サービスを提供する。しかしながら、この機構は、アプリケーションが互いに干渉するのを許可する。例えば、システムが会計アプリケーションを実行している場合に、この会計アプリケーションは、システムのすべてのメモリを割り当てることができるだけでなく、ＯＳが割り当てることができるすべてのプロセッサを使用することもできる。この場合、例えば製造アプリケーションといった他の或るアプリケーションがプロセッサまたはメモリを必要とする時、このアプリケーションは、自身が必要とするメモリもプロセッサも割り当てることができず、したがって、フリーズすることになる。このように、製造アプリケーションは、会計アプリケーションによってフリーズされることもあるし、影響を受けることもある。また、この機構は、システムを故障しやすい脆弱な状態のままにする。或るアプリケーションに関して何か問題があると、その問題は、すべてのアプリケーションの資源を破損させる可能性がある。
【０００４】
この問題に対する既知のソリューションは、コンピュータシステムを、パーティションまたは保護ドメインに分離することである。実施されたパーティショニングのタイプに応じて、コンピュータシステムの資源は、或るブロックの資源が別のブロックの資源に直接的にアクセスしない個別の機能ブロックに有効に配置することができる。以下でさらに説明するように、一定のタイプのパーティショニングは、或るパーティションで動作するアプリケーションが別のパーティションの資源にアクセスしないように、各パーティションの資源を完全に隔離することができる。他のタイプのパーティショニングは、一定の資源を複数の異なるパーティション間で共有できるように制限を少なくすることができる。一般に、コンピュータ資源をパーティショニングすることによって、１つのアプリケーションがシステム資源全体を使用することが有効に防止できるだけでなく、或るパーティション内で発生し得る障害およびエラーを抑制することもできる。このように、パーティションによって、複数のＯＳおよびアプリケーションは、単一のボックス（または１組のコンピュータ資源）上で共存することが可能になり、複数のＯＳおよびアプリケーションを互いの故障および大抵の場合はシステム資源の使用から確実に保護することが可能になる。
【０００５】
パーティショニング技法は、システムの物理ハードウェアに深く根付いたものから、それ以外の完全にソフトウェアベースのものまで多岐にわたっている。或るタイプのパーティショニングは、「ハードパーティショニング」（または「物理パーティショニング」）として知られている。これは、コンピュータを数群のセルボードに分割するコンピュータの物理パーティションであり、各群は他の群から独立して動作する。互いに物理的にパーティショニングされたセルを提供するさまざまな異なるセルラーシステムが利用可能である。このセルラーシステムには、一例として、９０００Ｓｕｐｅｒｄｏｍｅとして商用で知られているHewlett-Packard社から入手可能なサーバが含まれる。一般に、物理（またはハード）パーティションは、プロセッサモジュールやメモリモジュール等の、基礎を成すシステムハードウェアおよびコンポーネントの構造に依拠し、パーティションの境界は、クロスバースイッチ等のシステム電子機器によって実施される。
【０００６】
異なるパーティション間の完全な電気的ハードウェア隔離を提供するさまざまなハードパーティショニングのソリューションが既存の技術分野で利用可能である。このソリューションには、「ｎＰａｒｔｉｔｉｏｎ」として商用で知られているソリューションが含まれる。この「ｎＰａｒｔｉｔｉｏｎ」は、Hewlett-Packard社から入手可能である。ｎＰａｒｔｉｔｉｏｎのソリューションによって、Hewlett-Packard社の９０００Ｓｕｐｅｒｄｏｍｅサーバ等の単一のサーバ複合体を、１つの大規模システムとして構成することもできるし、複数の小規模システムとして構成することもできる。これらのハードパーティションは、完全な電気的ソフトウェア隔離を提供するように設計される。高可用性が重要となる編成では、ハードパーティショニングによって、或るパーティション内のどの障害も、他のどのパーティションにも影響を与えることができないことを確実にすることができる。ハードパーティション内で実行されるアプリケーションは、他のパーティションのハードウェアイベントまたはソフトウェアイベントの影響を受けない。
【０００７】
各ｎＰａｒｔｉｔｉｏｎは、自身が排他的に使用するパーティションに割り当てられた１つまたは複数のセル（プロセッサおよびメモリを含む）を有する。また、パーティションに属するセルに付属したあらゆる入出力（「Ｉ／Ｏ」）筐体（chassis）も、そのパーティションに割り当てられる。一般に、各筐体は、あらゆるＩ／Ｏカードおよび付属デバイスに加えて周辺機器相互接続（「ＰＣＩ」）カードスロットを有し、また、コアＩ／Ｏも有することがある。各ｎＰａｒｔｉｔｉｏｎは、そのｎＰａｒｔｉｔｉｏｎに割り当てられたセルの資源から成るそれ自身の中央処理装置（「ＣＰＵ」）資源、メモリ資源、およびＩ／Ｏ資源を有するので、（例えば、各ｎＰａｒｔｉｔｉｏｎに割り当てられた資源（セル）を再定義することによって）ハードウェアの物理的な除去および追加を行なう必要なく、資源を或るｎＰａｒｔｉｔｉｏｎから除去して、別のｎＰａｒｔｉｔｉｏｎに追加することができる。これに加えて、ｎＰａｒｔｉｔｉｏｎの動的な作成および変更もサポートされる。各ｎＰａｒｔｉｔｉｏｎは、自身を他のハードパーティションから完全に隔離できるように動作する。各ｎＰａｒｔｉｔｉｏｎは、単一のＯＳイメージ（またはインスタンス）を実行し、したがって、ソフトウェア隔離を提供する。したがって、他のｎＰａｒｔｉｔｉｏｎは、ＯＳの異なるバージョンを実行中であってもよい。さらに、ＨＰ−ＵＸ（登録商標）、ＬＩＮＵＸ、Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）等の異なるタイプのＯＳが異なるｎＰａｒｔｉｔｉｏｎで実行中であってもよい。
【０００８】
上記を考慮して、ハードパーティショニングを通じて、アプリケーションおよび動作環境は、ハードウェア分離によって互いに電気的に隔離され、かつ、保護されたシステムパーティションで実行される。したがって、ハードウェアの故障は、それら故障が発生したパーティションに限られる。さらに、ハードウェアのアップグレードの大部分は、影響を受けるパーティションしか停止させる必要がなく、システム全体を停止させる必要はない。個々のハードパーティションの再構成または再ブートに、システム全体の再ブートは必要ない。このように、ハードパーティショニング手法は、ソフトウェアの問題に加えて多くのハードウェアの故障を隔離できるという利点を有する。しかしながら、ハードパーティショニング手法の粒度は、当該手法が基づいているモジュールと同程度の粒度にすぎない。多くのハードパーティションのソリューションは、４つよりも少ないプロセッサおよび１ギガバイト以上のメモリを有するモジュールでパーティションを形成することを許容していない。したがって、ハードパーティションを構成する柔軟性は制限されることが多い。よりきめの細かな粒度を得るために、ハードパーティションは、さらに、「ソフトパーティション」または「仮想パーティション」に分割することができる。これについては、以下でさらに説明する。
【０００９】
別のタイプのパーティショニングは、「ソフトパーティショニング」（時に、「論理パーティショニング」と呼ばれることもある）として知られている。この「ソフトパーティショニング」によって、コンピュータをソフトパーティションに分割することにより、ＯＳの複数のインスタンスを１つのコンピュータ上で同時に実行することができる。ソフトパーティショニングでは、ソフトウェアを使用して、さまざまなパーティションが構成され、かつ、スーパーバイズされる。このように、（例えば、ハードウェアがパーティションを実施する）物理パーティショニングを通じて資源をパーティショニングするのではなく、ソフトウェアスーパーバイズレイヤを実施して、パーティションを定義することができ、各パーティション用に予約されるシステムの資源およびパーティション間で共有されるあらゆる資源を割り当てることができる。ソフトウェア構成を通じて、各ソフトパーティションには、それ自身のハードウェアのサブセットを割り当てることができ、各ソフトパーティションは、ＯＳの個別のインスタンスを実行し、それ自身の１組のアプリケーションをホストする。しかしながら、ソフトパーティショニングは、完全な物理的かつ電気的な隔離を提供しない。逆に、ソフトパーティションの構成に応じて、メモリ等の一定のシステム資源は、さまざまな異なるソフトパーティション間で共有されることがある。
【００１０】
このように、ソフトパーティショニングは、パーティションの構成に関しては、ハードパーティションよりもはるかに大きな柔軟性を提供する。例えば、各ソフトパーティションに達成可能な粒度は、従来のハードパーティショニング技法のように、システムのハードウェアモジュールに基づいていない。したがって、ソフトパーティショニングを通じて、よりきめの細かなパーティションの粒度を達成することができる。しかしながら、ソフトパーティショニング手法は、ハードパーティションが隔離されるように十分に隔離されず、多くのハードウェアの故障は、複数のソフトパーティションに影響し得るようになる。ソフトパーティショニング技法の一例は、「METHOD AND APPARATUS FOR DYNAMICALLY SHARING MEMORY IN A MULTIPROCESSOR SYSTEM」という発明の名称の米国特許第６，３８１，６８２号（特許文献１）、および、「SOFTWARE-PARTITIONED MULTI-PROCESSOR SYSTEM WITH FLEXIBLE RESOURCE SHARING LEVELS」という発明の名称の米国特許第６，５４２，９２６号（特許文献２）にさらに説明されている。
【００１１】
別のタイプのパーティショニングは、「仮想パーティショニング」として知られている。仮想パーティション（「仮想マシン」としても知られている）を使用すると、基礎を成すハードウェアのどの境界ともどの物理的関係とも無関係に、システムのハードウェアを、ＣＰＵ、ネットワークカード、またはストレージアダプタといったパーツを含む任意の可能な組み合わせに概ね分割することができる。真の仮想マシン技術は、ＯＳ不可知型（OS-agnostic）メカニズムに基づいた低レベルプロセッサの仮想化を提供する。
【００１２】
ハードパーティショニングおよびソフトパーティショニングの双方を組み合わせるパーティショニング技法の一例は、ＨＰ−ＵＸ  ＯＳ用にHewlett-Packard社から入手可能な「ｖＰａｒｓ」として知られている。ｖＰａｒｓによって、コンピュータをいわゆる仮想パーティション（実際には、仮想マシン技術で形成された十分に仮想的なパーティションではなく、本明細書で使用されるような「ソフトパーティション」である）にパーティショニングすることができる。この仮想パーティションは、それぞれ、ＨＰ−ＵＸの、個別の隔離されたインスタンスを実行する。ＨＰ−ＵＸ用のｖＰａｒｓは、２００１年１１月の「Installing and Managing HP-UX Virtual Partitions (vPars)」初版、T1335-90001（ＨＰ−ＵＸのｖＰａｒｓバージョンＢ．０１．００）（非特許文献１）にさらに説明されている。
【００１３】
このように、ＨＰ−ＵＸのｖＰａｒｓによって、ＨＰ−ＵＸ  １１ｉ動作環境（ＯＥ）の複数のインスタンス（バージョン）を１つのサーバ上で同時に実行することができ、各ＯＥインスタンスは、それ自身の１組のアプリケーションを十分に隔離された環境でホストする。これらのソフトパーティションは、ソフトウェアを通じて作成されると、シングルサーバのノード上またはシングルシステムのハードパーティション内でアプリケーションとＯＳとの間の隔離を提供する。各ｖＰａｒパーティションは、それ自身のＯＳイメージ（またはインスタンス）を実行し、それ自身のアプリケーションを十分にホストすることができ、したがって、完全なソフトウェア隔離を提供する。ＣＰＵを移動できることによって、ユーザは、或るｖＰａｒパーティションから別のｖＰａｒパーティションへＣＰＵを（再ブートすることなく）動的に追加および削除することが可能になる。これによって、アプリケーションは、同じサーバで共存できると同時に、完全なプライバシーを確保できる。これに加えて、無関係なパーティションを妨害することなく、実行サーバ上で隔離された動作環境を動的に作成する機能、変更する機能、さらには削除する機能も提供される。
【００１４】
ｎＰａｒｔｉｔｉｏｎはより高い障害隔離を提供するのに対して、ｖＰａｒｓは、ｎＰａｒｔｉｔｉｏｎと比較して、より大きな柔軟性およびより高い粒度を提供する。ｖＰａｒｓの大きな柔軟性は、簡単なソフトウェアコマンドの使用を通じて、或るｖＰａｒから別のｖＰａｒへＣＰＵを（再ブートすることなく）動的に追加および削除できることによって達成される。これに加えて、複数のｖＰａｒパーティションが、ｎＰａｒｔｉｔｉｏｎ内で機能することができ、したがって、より高い粒度（例えば、１つのｖＰａｒパーティションにつき１つのＣＰＵ）を提供することができる。
【００１５】
【特許文献１】米国特許第６３８１６８２号
【特許文献２】米国特許第６５４２９２６号
【特許文献３】米国特許出願公開第２００４／０２６８２９５号
【特許文献４】米国特許出願公開第２００４／０２４３５３４号
【非特許文献１】「Installing and Managing HP-UX Virtual Partitions (vPars)」初版、T1335-90001（ＨＰ−ＵＸのｖＰａｒｓバージョンＢ．０１．００）、２００１年１１月
【非特許文献２】「Intel IA-64 Architecture Software Developer’s Manual」, Volume 2: IA-64 System Architectureの第１１．１節のFirmware Model
【発明の開示】
【課題を解決するための手段】
【００１６】
少なくとも１つの実施の形態によると、方法は、それぞれがオペレーティングシステムを実行する複数のソフトパーティションにコンピュータシステムをパーティショニングすることを含む。この方法は、さらに、複数のソフトパーティションのそれぞれにつき、個別のファームウェアインスタンスをインスタンス化することを含み、ファームウェアインスタンスのそれぞれは、その各ソフトパーティションのオペレーティングシステム用の事前に定義されたファームウェアインターフェースを提供する。
【００１７】
少なくとも１つの実施の形態によると、システムは、それぞれがオペレーティングシステムを実行する複数のソフトパーティションを備える。このシステムは、さらに、複数のソフトパーティションのそれぞれについてのファームウェアインスタンスを備え、ファームウェアインスタンスのそれぞれが、その各ソフトパーティションのオペレーティングシステム用の標準ファームウェアインターフェースを提供する。
【００１８】
少なくとも１つの実施の形態によると、システムは、それぞれがオペレーティングシステムを実行する複数のソフトパーティションを定義する手段を備える。このシステムは、さらに、複数のソフトパーティションのそれぞれについてのファームウェアインスタンスを提供する手段を備える。このファームウェアインスタンスは、各ソフトパーティションのＯＳ用の事前に定義されたファームウェアインターフェースを提供する。
【００１９】
少なくとも１つの実施の形態によると、方法は、ＩＰＦベースのコンピュータシステムを複数のソフトパーティションにパーティショニングすることを含む。この方法は、さらに、複数のソフトパーティションの第１のソフトパーティション上で第１のタイプのオペレーティングシステムのインスタンスを実行すること、および複数のソフトパーティションの第２のソフトパーティション上で第２のタイプのオペレーティングシステムのインスタンスを実行することを含み、第２のタイプのオペレーティングシステムは、第１のタイプのオペレーティングシステムと異なる。
【発明を実施するための最良の形態】
【００２０】
次に、新規なソフトパーティショニングシステムおよびソフトパーティショニング方法の実施の形態を添付した図を参照して説明する。上述したように、コンピュータシステムの資源を複数のハードパーティション、ソフトパーティション、および／または仮想パーティションにパーティショニングすることが、多くの場合、望ましい。本明細書で説明するソフトパーティショニングの実施の形態は、本明細書で「ｆＰａｒｓ」と呼ぶ技法を提供する。この「ｆＰａｒｓ」は、Ｉｎｔｅｌプロセッサファミリー（「ＩＰＦ」）のプロセッサ用の業界標準ファームウェアインターフェース等の業界標準ファームウェアインターフェースと互換性を有する。一実施の形態によると、システムは、それぞれがＯＳのインスタンスを実行する複数のソフトパーティションを備える。これら複数のソフトパーティションのそれぞれにつき、ファームウェアインスタンスが存在する。各ファームウェアインスタンスは、そのそれぞれのソフトパーティションのＯＳ用の標準ＩＰＦファームウェアインターフェースを提供する。このような標準ＩＰＦファームウェアインターフェースには、以下でさらに説明するように、例として、ＡＣＰＩインターフェース、ＥＦＩインターフェース、ＳＡＬインターフェース、およびＰＡＬインターフェースが含まれ得る。さらに、このような標準ＩＰＦファームウェアインターフェースは、上述したインターフェースに対する拡張メカニズムを備えることができる。例えば、ＥＦＩのそれらの標準仕様においてＩｎｔｅｌにより定義されたように、ＥＦＩインターフェースに対するＯＥＭランタイムＥＦＩプロトコル拡張を含めることができ、ＤＩＧ６４（ＩＰＦシステムを取り扱う業界標準の本体）によって定義されたように、ＯＥＭ拡張可能ＳＡＬインターフェーステーブルを含めることができる。また、システムは、複数のソフトパーティションのそれぞれに割り当てられる資源を指定する構成データベースも含む。
【００２１】
ハードウェアプラットフォームが提供することになるＩＰＦ標準規格は非常に広範囲にわたり、したがって、すべてのシステム設計をかなり厳密に制約する。ＩＰＦ標準規格は、ＩＰＦコンピュータのソフトパーティショニングが存在しないと仮定する（すなわち、この仮定は、コンピュータが１つのＯＳインスタンスを実行する１つのハードウェアシステムであるということである）。本明細書で説明するソフトパーティショニングの一定の実施の形態によって、ＩＰＦインターフェース制約条件を変更することもなく、また、この制約条件に違反することもなく、ソフトパーティショニング機能をＩＰＦベースのシステムに導入することが可能になる。従来のソフトパーティショニング技法は、ＯＳおよび／またはハードウェアの変更を通じて実施されていた（例えば、Hewlett-Packard社はＰＡ−ＲＩＳＣを利用し、ＣｏｍｐａｑはＡｌｐｈａおよびＶＭＳを利用したように）。すなわち、ソフトパーティショニング技法は、従来、ＯＳおよび／またはハードウェアの制御を有する技法によって実施されており、それにより、このようなＯＳおよび／またはハードウェアは、ソフトパーティショニングを可能にするように変更される（例えば、ＯＳとハードウェアとの間のインターフェースが変更されることがある）。本明細書で説明したソフトパーティショニングの実施の形態は、既存のＯＳ（または既存のＯＳをわずかに変更したバージョン）および既存のファームウェアアーキテクチャを使用してシステムのソフトパーティショニングを達成する技法を提供する。より具体的には、標準ファームウェアインターフェースとの互換性が維持されると同時に、システムのソフトパーティショニングが達成される。本明細書では、ＩＰＦベースのシステムについての具体例の実施態様を説明する。この実施態様では、標準ＩＰＦファームウェアインターフェースがソフトパーティショニングのソリューション内で維持されて、ＯＳ（単数または複数）および基礎を成すハードウェア（例えば、ＩＰＦプロセッサ）を変更する必要がない（または、わずかにのみ変更する必要がある）ようにされる。したがって、システムのソフトパーティショニングを可能にするためにＯＳによって利用される新たなファームウェアインターフェースを開発するのではなく、業界標準ＩＰＦファームウェアインターフェース等の事前に定義された（例えば、業界標準の）ファームウェアインターフェースがソフトパーティショニングで維持される。したがって、このような事前に定義されたファームウェアインターフェースと互換性を有するＯＳは、当該ファームウェアインターフェースとの互換性を依然として有すると同時に、ソフトパーティショニングも可能となる。したがって、例えば、以下でさらに説明するように、ソフトパーティション上で実行されるＩＰＦ互換ＯＳのインスタンスは、事前に定義された業界標準ＩＰＦファームウェアインターフェースとの互換性を依然として有する。以下でさらに説明するように、一定の実施の形態では、システムの各ソフトパーティションにつき、個別のファームウェアインスタンスが存在する。ここで、各ファームウェアインスタンスは、そのそれぞれのソフトパーティションのＯＳ用の標準ＩＰＦファームウェアインターフェースを提供する。
【００２２】
本明細書で説明するソフトパーティショニングの実施の形態は、本明細書でさらに説明する具体例におけるようなＩＰＦベースのシステムだけに適用できるのではなく、他のタイプのシステムのソフトパーティショニングを可能にするものにも同様に適用することができることが理解されよう。この他のタイプのシステムのソフトパーティショニングは、ＯＳとシステムファームウェアとの間の事前に定義されたインターフェースを維持できるようにして、このようなソフトパーティショニングを達成するのに、ＯＳおよび／または基礎を成すハードウェアを変更する必要がない（または、ＯＳおよび／または基礎を成すハードウェアへの変更を最小にすることができる）ようにされたものである。
【００２３】
したがって、本明細書で説明する一定の実施の形態によって、各ソフトパーティションが業界標準ファームウェアインターフェースと互換性を有するようにソフトパーティショニングを達成することができる。このソフトパーティショニングは、いくつかの利点および利益を提供する。業界標準ファームウェアインターフェースと互換性を有するようにソフトパーティショニングを達成できることによって、このような業界標準ファームウェアインターフェースと互換性を有する任意のＯＳおよびハードウェアを各ソフトパーティションで実施することができる。すなわち、ソフトパーティショニングを可能にするためにＯＳおよびハードウェアを変更する必要はない。例えば、ソフトパーティショニングのサポートを達成するために、メーカ独自のインターフェースをＯＳおよび／またはハードウェアに実施する必要はない。逆に、以下でさらに説明するように、ＯＳ（単数または複数）およびハードウェアの業界標準インターフェースを変更する必要なく、ファームウェアを使用して、ソフトパーティショニングを可能にすることができる。さらに、業界標準ファームウェアインターフェースと互換性を有する任意のＯＳを各ソフトパーティションで実行することができる。例えば、それぞれがＩＰＦ標準ファームウェアインターフェースをサポートするソフトパーティションを達成する一例の実施の形態が実施される。この場合、各ソフトパーティションで任意のＩＰＦ  ＯＳを実行することができる。ＩＰＦベースのシステムのソフトパーティショニングのソリューションは、従来技術では利用可能ではない。さらに、それぞれがＩＰＦ標準ファームウェアインターフェースと互換性を有するソフトパーティションの作成を可能にするソフトパーティショニングのソリューションも、従来技術では利用可能ではない。したがって、一定の実施の形態は、ＩＰＦベースのシステムのソフトパーティショニングを可能にするという点で有利である。この場合も、ＩＰＦインターフェースに関して具体例を本明細書で説明するが、本明細書で説明する技法は、事前に定義された任意のハードウェアインターフェースと互換性を有するソフトパーティショニングのソリューションの提供に適用するように容易に適合することができ、したがって、本明細書で説明する実施の形態は、ＩＰＦベースのシステムに限定することを目的とするものではない。
【００２４】
さらに、一定の実施の形態によると、コンピュータシステムの異なるソフトパーティション上で異なるＯＳを実行することもできる。例えば、一実施の形態によると、コンピュータシステムを複数のソフトパーティションにパーティショニングすることができ、第１のタイプのＯＳのインスタンスを、これら複数のソフトパーティションの第１のソフトパーティション上で実行することができ、異なるタイプのＯＳのインスタンスを、これら複数のソフトパーティションの第２のソフトパーティション上で実行することができる。一定の実施の形態では、各ソフトパーティションは、そこで実行される任意の標準ＩＰＦ  ＯＳのインスタンスを有することができるように、ＩＰＦ標準ファームウェアインターフェースと互換性を有することができる。この任意の標準ＩＰＦ  ＯＳには、例として、ＩＰＦ  ＬＩＮＵＸ、ＷＩＮＤＯＷＳ、Ｏｐｅｎ  ＶＭＳ、およびＩＰＦ  ＨＰ−ＵＸが含まれる。
【００２５】
以下でさらに説明するように、一定の実施の形態によって、「ホットプラグ」（ハードウェアのオンライン追加またはオンライン除去）用に存在する標準ＩＰＦファームウェアインターフェース（例えば、ＡＣＰＩインターフェースおよびＳＡＬインターフェース）の使用が可能になり、同種（sibling）のソフトパーティション間での「デバイス移動」が提供される。したがって、一定の実施の形態のソフトパーティショニング技法によって、標準ＩＰＦファームウェアインターフェースを使用するＩＰＦベースのシステム内において、同種のソフトパーティション（例えば、共通のハードパーティション上で構成されたソフトパーティション）間で（負荷バランシング等のために）資源を動的に移動させることができる。
【００２６】
これに加えて、このような「ホットプラグ」ファームウェアインターフェースを利用して、或るハードパーティションのソフトパーティションから異なるハードパーティションのソフトパーティションへ資源を移動させることもできる。例えば、一定の実施の形態では、ｆＰａｒｓの「スパニング名前空間（spanning namespace）」は、所与のソフトパーティションのＯＳに属しない資源（例えば、ハードウェアデバイス）を含むことができ、このＯＳは、当該ＯＳに属しないそれらの資源を使用するように試みることを回避する（例えば、ＯＳの＿ＳＴＡメソッドは、それらのデバイスが無効であることを宣言するので）。一定の実施の形態では、或るハードパーティションの資源のすべてをこのスパニング名前空間に含めることができるだけでなく、複数の異なるハードパーティションの資源のすべてもこのスパニング名前空間に含めることができる。次に、ホットプラグを実行する標準ファームウェアインターフェースを使用して、第１のハードパーティションのソフトパーティションから資源（例えば、ハードウェアデバイス）を除去して、第２のハードパーティションのソフトパーティションにこのような資源を追加することができる。例えば、構成データベース（本明細書では「ｆｐｃｆｇ」と呼ぶ）を変更して、その資源が第１のハードパーティションのソフトパーティションにもはや割り当てられず、次に、第２のハードパーティションのソフトパーティションに割り当てられることを反映することができる。
【００２７】
上述したように、既存の技術のハイブリッドパーティショニング技法の一例には、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社から入手できるＨＰ−ＵＸ用のｖＰａｒｓが含まれる。一般に、ｖＰａｒｓによって、ＰＡ−ＲＩＳＣのハードウェアおよびファームウェアをｎ個のｖＰａｒパーティションに分割することが可能になる。例えば、各パーティションは、それ自身のブートディスク、それ自身のＣＰＵ（単数または複数）、それ自身のネットワーク接続（例えば、ＬＡＮ接続および／またはＷＡＮ接続）、ならびに、ＨＰ−ＵＸおよびそのｖＰａｒパーティション上でホストされる予定のアプリケーションを実行するのに十分なメモリのサブセットを含むことができる。ｖＰａｒｓモニタは、オペレータの制御下でシステム管理アプリケーションと共同して、パーティションへのハードウェア資源の割り当てを管理し、パーティションおよびそれらのカーネルをブートし、一定のファームウェアコールをエミュレーションする。これらの特定のコールをエミュレーションすることによって、ｖＰａｒｓは、各ＨＰ−ＵＸインスタンスが自身に割り当てられたハードウェアを有するスタンドアロンコンピュータ上で実行されているというイリュージョンを当該各ＨＰ−ＵＸインスタンスに対して作成する。ｖＰａｒｓモニタの中心部には、「パーティションデータベース」がある。このパーティションデータベースは、パーティション構成情報を含む。ｖＰａｒｓモニタは、パーティションデータベースを使用して、どのパーティションが存在し、どのハードウェア資源およびパーティション属性が各パーティションに関連付けられているかを追跡する。
【００２８】
ＨＰ−ＵＸ  ＰＡ−ＲＩＳＣのｖＰａｒｓの実施態様は、「ハイブリッド」ソリューションである。このハイブリッドソリューションによって、ｖＰａｒｓモニタは、ＰＡファームウェアインターフェースをエミュレーションすることにより、「ソフトパーティショニングされた」フレームワークを提供する。このフレームワークでは、それ自体およびＨＰ−ＵＸ  ＯＳ自体の内部の他のｖＰａｒｓアウェア（vPars-aware）モジュールが「仮想パーティショニング」ユーザエクスペリエンスを提供するように共同する。より具体的には、ｖＰａｒｓは、仮想メモリメカニズムを使用して、ソフトパーティション間の保護を増強する。ＯＳ内の特定の仮想メモリ設計は、通例（好ましくは）、非常にＯＳ特有のものであるので、ソフトパーティション内で異なるＯＳ（例えば、ＨＰ−ＵＸ、ＬＩＮＵＸ、ＷＩＮＤＯＷＳ、およびＯｐｅｎ  ＶＭＳ）を使用するｖＰａｒパーティションの実施態様は、このような実施態様では、実践的に不可能である。したがって、仮想メモリメカニズムを使用してソフトパーティション間の保護を増強する際のｖＰａｒｓの有益な効果は、一般のソフトパーティショニングのソリューションと比較して、ソフトパーティション間により良い隔離が存在するということである。しかし、このソリューションの欠点は、システムのパーティション内で異なるタイプのＯＳを混在させることが事実上不可能であるということである。
【００２９】
ｖＰａｒｓ設計は、例えば、ＰＡ−ＲＩＳＣベースのソリューションに対してはうまく機能する。すなわち、ｖＰａｒｓは、Hewlett-Packard社のＰＡ−ＲＩＳＣプロセッサファミリー（ＰＡ−８０００プロセッサ、ＰＡ−８２００プロセッサ、ＰＡ−８５００プロセッサ等）からのプロセッサを有するコンピュータシステムをパーティショニングして、複数の隔離されたＨＰ−ＵＸのインスタンスをコンピュータシステム上で実行可能にすることに対してはうまく機能する。しかしながら、ｖＰａｒｓ設計の不利な点は、標準ＩＰＦファームウェアインターフェースを使用するＩＮＴＥＬ（登録商標）プロセッサファミリー（「ＩＰＦ」）サーバに対しては機能しないということである。他のさまざまなソフトパーティショニングのソリューションがこの技術で利用可能な場合があるが、このようなソフトパーティショニングのソリューションは、業界標準ファームウェアインターフェース（ＩＰＦの既知のＡＣＰＩインターフェース、ＳＡＬインターフェース、ＥＦＩインターフェース、ＰＡＬインターフェース等）と互換性を有しておらず、それによって、このようなパーティショニングは、標準ＩＰＦ  ＯＳを変更することなく、あらゆる標準ＩＰＦ  ＯＳと共に機能することができない。
【００３０】
上述したように、ＩＰＦベースのサーバがシステム資源のソフトパーティショニングを提供し、それによって、複数のＯＳインスタンスが単一のＳＭＰサーバの個別のパーツを共有できるソフトパーティショニング技法は、従来技術には存在しない。すなわち、業界標準ＩＰＦファームウェアインターフェースと互換性を有するソフトパーティショニング技法は、従来技術では利用可能ではない。例えば、上述したように、ｖＰａｒｓ設計は、標準ＩＰＦファームウェアインターフェースを使用するＩＰＦサーバに対して機能しない。この結果は、主として、仮想アドレスマッピングを使用する仮想モードでＩＰＦファームウェアを呼び出すことができるということによるものである。この仮想アドレスマッピングは、ファームウェアがＯＳの仮想アドレス空間内に存在するように、ＯＳイメージによって作成および定義される。複数の異なる仮想アドレス空間が、標準ＩＰＦファームウェアの（少なくとも）一部の複数の異なる物理コピーを必要とする。以下で図４と共にさらに説明するように、標準ＩＰＦファームウェアのこのような一部は、ＥＦＩブートサービスおよびＰＡＬ（プロセッサ）ファームウェアを含み、その結果、オペレーティングシステム内で実行されて、異なる仮想アドレスマッピングを使用するプロセッサは、仮想パーティションの個別のプロセッサ上で実行できる他のＯＳインスタンスと干渉することはない。この問題は、ＰＡ−ＲＩＳＣベースのソリューションには存在しない。その理由は、それらのソリューションでは、ファームウェアが、アーキテクチャ上、物理モードで実行されるように定義されるからである。すなわち、ＰＡ−ＲＩＳＣプロセッサのファームウェアは、アーキテクチャ上、物理モードで実行されるように定義される。これにより、実際のプラットフォームのハードウェアおよびファームウェアと、サーバの異なる（個別の）物理ＲＡＭに存在する１つまたは２つ以上のＯＳインスタンスとの間にソフトウェアのｖＰａｒモニタレイヤを介在させて、異なる（共有されない）Ｉ／Ｏハードウェアおよびプロセッサを利用することによって、ＰＡ−ＲＩＳＣファームウェアの直接的な「エミュレーション」を実施することが可能になる。
【００３１】
これに加えて、従来のソフトパーティショニング技法は、各ソフトパーティション用のファームウェアインターフェースを提供する個別のファームウェアインスタンスを提供しない。上述したように、ＩＰＦベースのシステムでは、仮想アドレスマッピングを使用する仮想モードでＩＰＦファームウェアを呼び出すことができる。この仮想アドレスマッピングは、ファームウェアがＯＳの仮想アドレス空間内に存在するようにＯＳイメージによって作成および定義される。複数の異なる仮想アドレス空間は、標準ＩＰＦファームウェアの（少なくとも）一部の複数の異なる物理コピーを必要とする。以下でさらに説明するように、ソフトパーティショニング技法の一実施の形態によると、ＩＰＦベースのシステム上で作成された各ソフトパーティションにつき、ファームウェアのインスタンスが存在し、各ファームウェアインスタンスは、その各ソフトパーティション用のＩＰＦ標準ファームウェアインターフェースを提供する。
【００３２】
このように、以下で説明する一定の実施の形態は、業界標準ＩＰＦファームウェアインターフェースと互換性を有するソフトパーティショニング技法を提供する。したがって、システムの各ソフトパーティションは、当該ソフトパーティション上で実行される任意のＩＰＦ  ＯＳのインスタンスを有することができる。このように、本明細書で説明する実施の形態は、構成の柔軟性をユーザに提供し、それによって、ユーザには、単一のコンピュータまたはハードパーティショニングされたセルラーコンピュータ内で、ＩＰＦ  ＯＳまたは異なるタイプのＩＰＦ  ＯＳ（例えば、ＬＩＮＵＸ、ＷＩＮＤＯＷＳ、ＶＭＳ、ＨＰ−ＵＸ等）の２つ以上のインスタンスを実行するオプションが与えられる。例えば、図１１を参照して、一実施の形態によると、ＩＰＦベースのコンピュータシステムは、オペレーションブロック１１０１で複数のソフトパーティションにパーティショニングされる。第１のタイプのＯＳのインスタンスは、これら複数のソフトパーティションの第１のソフトパーティション上で実行され（ブロック１１０２）、第２のタイプのＯＳのインスタンスは、これら複数のソフトパーティションの第２のソフトパーティション上で実行される。ここで、第２のタイプのＯＳは、第１のタイプのＯＳとは異なるものである（ブロック１１０３）。
【００３３】
このｆＰａｒｓ技法の一実施の形態によって可能にされたソフトパーティショニングの一例を図１に示す。図示するように、ハードパーティション１０１は、複数のファームウェアパーティション、すなわち、図１のｆＰａｒ０、ｆＰａｒ１、ｆＰａｒ２、およびｆＰａｒ３等の複数の「ｆＰａｒ」にパーティショニングすることができる。各ｆＰａｒはソフトパーティショニング技法を提供する。このソフトパーティショニング技法は、業界標準ファームウェアインターフェース（例えば、ＩＰＦ用のＡＣＰＩ、ＳＡＬ、ＥＦＩ、およびＰＡＬ）と互換性を有するものであり、したがって、正常に動作する（well-behaved）標準ＩＰＦ  ＯＳを変更する必要なく（または、ＯＳで行われるどの変更も最小にされて）、このようなｆＰａｒ上で当該ＯＳのインスタンスを実施することを可能にするものである。すなわち、各ｆＰａｒは、そのｆＰａｒが十分なハードウェアを含む場合に、正常に動作するどの標準ＩＰＦ  ＯＳもブートすることができる。
【００３４】
この意味で、ＯＳが、ハードウェアの物理構成について仮説を立てないが、その代わり、業界標準ファームウェアインターフェース（例えば、ＥＦＩ、ＳＡＬ、およびＡＣＰＩ）を通じてＯＳに提供されるハードウェアの記述にのみ依拠する場合に、当該ＯＳは、正常に動作するとみなされる。一定のシステムのＯＳに必要とされ得るさらに別の特性については、以下でさらに説明する。ＯＳのインスタンスは、任意の物理アドレスで開始できることが必要な場合があり、任意の特定の物理アドレスで実行される他のＯＳとの衝突を回避するために、その特定のアドレスを予約できない場合がある。インスタンスは、パーティション間でメモリを共有するシステム構成の一部である場合に、そのアドレス空間で複数の任意の物理ホール（physical hole）をサポートできることが必要な場合がある。これに加えて、インスタンスは、メモリの「ホットインスワップ（hot inswap）」をサポートするために、そのアドレス空間で物理ホールを取り扱うことが必要な場合もある。インスタンスは、インスタンスがメモリを共有しないシステムで使用される場合に、その「プライベートメモリ」内で完全に実行できることが必要な場合がある。あるいは、インスタンスは、メモリが共有されるシステムの一部である場合に、コンピュータ内で実行される他のインスタンスとデータを通信または共有する物理「共有メモリ」を使用できることが必要な場合もある。各インスタンスは、コンピュータシステムの別のＣＰＵと通信するために、当該別のＣＰＵと連絡する或るメカニズムを必要とする場合がある。また、インスタンスは、たとえ、自身のオペレーションと互換性を有する他のＣＰＵが、現在、そのインスタンスのパーティションに割り当てられていなくても、当該他のＣＰＵを認識できることが必要な場合もある。例えば、インスタンスは、クロック速度等のＣＰＵパラメータを確認して、そのＣＰＵが、当該インスタンスを実行するパーティションに再割り当てされた場合に、当該インスタンスがそのＣＰＵと共に実行できるかどうかを判断できることが必要な場合がある。
【００３５】
ＩＰＦベースのシステム用のｆＰａｒｓ内で利用されるＯＳの「正常動作性（well-behavedness）」の特性は、ＩＰＦ標準規格自体のアーキテクチャ上の要件を越えた拡張でないことが理解されるべきである。したがって、ＩＰＦ標準規格と十分な互換性を有するＯＳは「正常に動作する」。
【００３６】
一定の実施の形態によると、各ｆＰａｒは、例としてＩＰＦ  ＨＰ−ＵＸ、ＩＰＦ  ＬＩＮＵＸ、ＷＩＮＤＯＷＳ(登録商標)、Ｏｐｅｎ  ＶＭＳ等の正常に動作する任意の標準ＩＰＦ  ＯＳのインスタンスを備えることができる。現在既知であるか、または、今後開発されるこのような他のさまざまな正常に動作するＩＰＦ  ＯＳは、本発明の実施の形態に従って利用することができる。一般に、ＩＰＦ標準規格はＩｎｔｅｌ社によって定義され、このようなＩＰＦ標準規格をサポートするかどうかの決定は、個々のＯＳベンダに委ねられている。さらに、図１の例に示すように、ｆＰａｒｓは、異なるタイプのＯＳも備えることができる。例えば、図１の例では、ｆＰａｒ０はＯｐｅｎ  ＶＭＳのインスタンスを備え、ｆＰａｒ１はＩＰＦ  ＬＩＮＵＸのインスタンスを備え、ｆＰａｒ２はＷＩＮＤＯＷＳのインスタンスを備え、ｆＰａｒ３はそこで実行されるＩＰＦ  ＨＰ−ＵＸのインスタンスを備える。
【００３７】
上述したように、本明細書の一定の実施の形態によって利用されるソフトパーティショニング技法は、各ソフトパーティションに対して、その各ソフトパーティション用のＩＰＦ標準ファームウェアインターフェースを提供するファームウェアインスタンスを提供する。したがって、このようなＩＰＦ標準ファームウェアインターフェースと互換性を有するＯＳは、変更されずに利用することもできるし、当該ＯＳへの変更を最小にして利用することもできる。標準ＩＰＦファームウェアインターフェースは各ソフトパーティションについて保持されるので、ソフトパーティショニングを可能にするために、ＯＳを、異なるファームウェアインターフェース用に完全に修正する必要はない。一方、一定のＯＳに対しては、一定の軽微な変更が依然として行われることがある。例えば、ＩＰＦ命令セットアーキテクチャの技術的側面は、完全に「標準的な」（すなわち、パッケージの）ＩＰＦ  ＯＳが、一定の場合に実際に確実に機能することを禁止する。より具体的には、ＩＰＦ命令セットは、ほとんどのＩＰＦ  ＯＳがサーバのすべてのＣＰＵのグローバル変換キャッシュパージ（global translation cache purge）を実行するのに使用する命令（ｐｔｃ．ｇ）を含む。この命令は、シングルスレッド化されていなければならない。そこで、すべてのＯＳインスタンス間の同期が必要とされる。したがって、このようなＩＰＦ  ＯＳは、このようなｐｔｃ．ｇ命令のその使用を考慮するために、「ｆＰａｒｓアウェア（fPars-aware）」である少なくとも１つのソフトウェア変更でわずかに変更されることがある。あるいは、これは、ファームウェアにおいて考慮されることがあり、それによって、ファームウェアインターフェースインスタンスは、ｐｔｃ．ｇ命令をインターセプトし、当該命令のオペレーションを変更する。
【００３８】
本明細書で説明するソフトパーティショニング技法の一実施の形態によると、各ｆＰａｒ内の２種類の機能制約条件が存在し得る。これら２種類の機能制約条件は、１）ハードウェア制限に起因する機能制約条件、および、２）ファームウェアが課した制限に起因する機能制約条件（メインメモリ構成の並べ替えの制限等）である。一実施の形態では、ｆＰａｒｓの構成は、その構成を定義する永続性ストア（または、「ｆＰａｒｓ構成データベース」）に対する変更を通じて達成される。この実施の形態では、ｆＰａｒｓ構成データベースは、ＯＥＭ特有のグローバル一意識別子（「ＧＵＩＤ」）および名前を使用して、ＥＦＩ変数として記憶される。「ｆｐｃｆｇ」（ｆＰａｒｓ構成の場合）という名前を有するＥＦＩ変数のｆＰａｒｓ不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）定義が、システムファームウェアによって使用され、ブート時に各ｆＰａｒセグメントが構築される。これは、メモリチャンク、プロセッサ、Ｉ／Ｏカード等の割り当て可能な資源の低レベルハードウェア識別情報を保持する集約データベースの永続的なストレージコピーを提供する。また、このデータベースはポリシー変数も含む。ｆｐｃｆｇ変数のコピーが、各ブートデバイスのＥＦＩファームウェアパーティションのファイルに保持される。この保持は、ｆＰａｒアウェアツールによって、または、各ＥＦＩブートマネージャがｆＰａｒ内部でブートを行っている時は、当該各ＥＦＩブートマネージャ自体によって行われる。ＩＰＦ標準インターフェースは、すでに、入出力（Ｉ／Ｏ）、メモリ、およびプロセッサの動的な再構成をサポートしているので、これらのインターフェースは、各ｆＰａｒ内の要素を再構成するのに使用することができ、その結果、ｆＰａｒの要素のオンライン再構成を実行するのに新たなファームウェアアーキテクチャは必要とされない。
【００３９】
例えば、一実施の形態は、集約された（Ｃ言語構造の）ｆｐｃｆｇ変数を使用する。代替的な実施の形態では、このような集約体を使用するのではなく、各構成ポリシーおよび各資源について単一のＧＵＩＤの下で個別のＥＦＩ変数が使用される。
【００４０】
２つの主要なｆＰａｒｓ構成の使用ケースが、本明細書で説明するソフトパーティショニングの実施の形態によってサポートされる。この２つの主要なｆＰａｒｓ構成の使用ケースは、１）ＯＳが不在のケース、および、２）ＯＳが存在するケースである。「ＯＳが存在する」は、ＯＳがブートして、ソフトパーティショニングを実行中（オンライン）であることを意味する。「ＯＳが不在」は、ＯＳがブートする前に、ファームウェアがソフトパーティションを管理していることを意味する。双方の使用ケースにおいてシステムと相互作用することによりパーティションを構成／再構成する能力を有することが望ましく、それらの相互作用の内部の仕組みは各使用ケースで異なることがあるが、この内部の仕組みは、共に、一貫した構成データになるべきである。
【００４１】
一定の実施の形態では、ＩＰＦ標準デバイスホットプラグをサポートしないＯＳは、ソフトパーティションの再構成を達成するために再ブートを受ける。１つまたは２つ以上のデバイスタイプ（メモリ、ＣＰＵ、またはＩ／Ｏ）のＡＣＰＩ介在ホットプラグをサポートするＯＳは、構成を変更するのに再ブートする必要はない。これらの動作モードを、本明細書では、それぞれ「静的ｆＰａｒｓ」および「動的ｆＰａｒｓ」と呼ぶことがある。ソフトパーティション用のメモリデバイス（または「セグメント」）の追加および放出は、このようなソフトパーティションのＩＰＦ  ＯＳが、＿ＨＩＤ値がＰＮＰ０Ｃ８０（ＡＣＰＩ  ２．０仕様テーブル５−４２を参照）であるＡＣＰＩ  ２．０のメモリデバイスをサポートするという条件で、ＰＣＩデバイスの挿入および除去と同様に、ＡＣＰＩ相互作用を通じて達成することができる。さらに、プロセッサがファームウェアの制御に戻された後に、当該プロセッサのＡＣＰＩ＿ＥＪ０メソッドを利用することによって、ＣＰＵを除去する（割り当てられていないプールに戻す）こともできるし、同種のパーティションへ移動させることもできる。放出に先立ち、このプロセッサが、ｆＰａｒｓ拡張メソッドＳＦＰＮ（Set fPar Number（ｆＰａｒ番号の設定））の使用を通じて、同種のｆＰａｒに追加されるように指示されていると、受信側ＯＳはＡＣＰＩ通知イベントを受信し、そのＣＰＵを請求するよう注意を喚起される。プロセッサは、実際にはすでに存在し、ｆＰａｒを放出することにより使用されているが、このイベントは、あたかもプロセッサがハードウェアに「ホットプラグされた」ように見える。
【００４２】
図２に移って、図１の例のようにハードパーティション内で４つのｆＰａｒｓを実施するソフトパーティショニングの一実施の形態の一例の高レベルブロック図が示されている。本明細書のこの例の実施態様の多くでは、４つのｆＰａｒｓを説明するが、本明細書で説明する実施の形態は、（十分なハードウェア資源がシステムに存在するという条件で）任意の個数のｆＰａｒｓを実施するのに利用できることが理解されるべきであり、したがって、代替的な実施態様では、４つよりも多いｆＰａｒｓをハードパーティション上に含めることもできるし、４つよりも少ないｆＰａｒｓをハードパーティション上に含めることもできることが理解されるべきである。上述したように、各ｆＰａｒは、そのｆＰａｒが十分なハードウェアを含む（すなわち、十分なハードウェア資源がそのｆＰａｒに割り当てられている）という条件で、正常に動作する任意の標準ＩＰＦ  ＯＳを備えることができる。図１の例と同様に、図２の例でも、第１のｆＰａｒ（図１のｆＰａｒ３に対応する）は、ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６のインスタンスおよびＨＰ−ＵＸアプリケーション（単数または複数）２０７を備える；第２のｆＰａｒ（図１のｆＰａｒ１に対応する）は、ＩＰＦ  ＬＩＮＵＸ  ＯＳ２０９のインスタンスおよびＬＩＮＵＸアプリケーション（単数または複数）２１０を備える；第３のｆＰａｒ（図１のｆＰａｒ２に対応する）は、ＷＩＮＤＯＷＳ  ＯＳ２１２のインスタンスおよびＷＩＮＤＯＷＳアプリケーション（単数または複数）２１３を備える；第４のｆＰａｒ（図１のｆＰａｒ０に対応する）は、ＶＭＳ  ＯＳ２１５のインスタンスおよびＶＭＳアプリケーション（単数または複数）２１６を備える。
【００４３】
このように、図２の例は、４つのｆＰａｒソフトパーティションを備える。各ｆＰａｒパーティションには、ハードパーティション内の資源の交わらない（non-intersecting）記述が割り当てられる。例えば、各ｆＰａｒインスタンスは、１つまたは２つ以上のＩＰＦ  ＣＰＵ２０３、１つまたは２つ以上のＰＣＩカード２０２、および物理メモリ（ＲＡＭ）２０４の１つまたは２つ以上の「セグメント」を制御または「所有」する。図２の例では、第１のｆＰａｒインスタンス（ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６のインスタンスがそこで実行される）には、ＰＣＩカード２０２Ａおよび２０２Ｂ、ＣＰＵ２０３Ａ、ならびにメモリ２０４のセグメント２０４Ａおよび２０４Ｂが割り当てられる；第２のｆＰａｒインスタンス（ＩＰＦ  ＬＩＮＵＸ  ＯＳ２０９のインスタンスがそこで実行される）には、ＰＣＩカード２０２Ｄ、ＣＰＵ２０３Ｃ、およびメモリ２０４のセグメント２０４Ｃが割り当てられる；第３のｆＰａｒインスタンス（ＷＩＮＤＯＷＳ  ＯＳ２１２のインスタンスがそこで実行される）には、ＰＣＩカード２０２Ｃ、ＣＰＵ２０３Ｂ、ならびにメモリ２０４のセグメント２０４Ｄおよび２０４Ｅが割り当てられる；第４のｆＰａｒインスタンス（Ｏｐｅｎ  ＶＭＳ  ＯＳ２１５のインスタンスがそこで実行される）には、ＰＣＩカード２０２Ｅおよび２０２Ｆ、ＣＰＵ２０３Ｄおよび２０３Ｅ、ならびにメモリ２０４のセグメント２０４Ｆが割り当てられる。
【００４４】
ｆＰａｒｓロジック２０１は、ｆＰａｒパーティション（「ソフト」パーティション）のインスタンスへのハードウェア資源の割り当てを管理し、ｆＰａｒパーティションおよびそれらのカーネルをブートし、各ｆＰａｒパーティションの一定のファームウェアコールをエミュレーションする。これらの特定のコールをエミュレーションすることによって、ｆＰａｒｓは、ＩＰＦ標準ＯＳ（例えば、ＩＰＦ  ＨＰ−ＵＸ２０６、ＩＰＦ  ＬＩＮＵＸ２０９、ＷＩＮＤＯＷＳ２１２、およびＯｐｅｎ  ＶＭＳ２１５）の各インスタンスが自身に割り当てられたハードウェアのすべてを有するスタンドアロンコンピュータ上で実行されているというイリュージョンを当該各インスタンスに対して作成する。ｆＰａｒｓロジック２０１は「ｆＰａｒｓ構成データベース」を含む。この構成データベースは、（例えば、不揮発性メモリに記憶された）永続的なパーティション構成情報を含む。すなわち、構成データベースは、各ｆＰａｒインスタンスに割り当てられるハードウェア資源を指定する。例えば、構成データベースは、第１のｆＰａｒインスタンス（ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６のインスタンスがそこで実行される）にＰＣＩカード２０２Ａおよび２０２Ｂ、ＣＰＵ２０３Ａ、ならびにメモリ２０４のセグメント２０４Ａおよび２０４Ｂが割り当てられることを指定する。ｆＰａｒｓロジック２０１は、構成データベースを使用して、どのｆＰａｒインスタンスが存在し、どのハードウェア資源およびパーティション属性が各ｆＰａｒインスタンスに関連付けられているかを追跡することができる。
【００４５】
さらに、上述した構成データベースの実施に加えて、一定の実施の形態では、ｆＰａｒｓロジック２０１は、１つまたは２つ以上の他の機能を実行するように動作可能でもある。この機能は、以下のものである。
Ａ）システム（例えば、ハードパーティション内）に存在するハードウェアを発見すること。
Ｂ）ハードウェアを構成すること。
Ｃ）ＮＶＲＡＭ構成および既存のハードウェアを使用して、ハードウェアを１つまたは２つ以上のソフトパーティションに「セグメント化」し、「スパニング名前空間」を生成し、使用するオフライン構成ツールの各ＯＳインスタンスによるＥＦＩおよびＡＣＰＩアクセス用のＮＶＲＡＭインターフェースのすべてをセットアップする（図１０Ａ〜図１０Ｂを参照）こと。
Ｄ）各ＩＰＦファームウェアインスタンスおよびそのファームウェアインスタンスの上の各ＯＳインスタンスの起動を順序付けること。
Ｅ）サーバの動的なエラー応答（ＭＣＡ、リセット、およびＩＮＩＴ挙動、ならびにＳＡＬエラーログ記録）をセグメント化すること。
【００４６】
一定の実施の形態によると、業界標準ファームウェアインターフェースを使用して、ｆＰａｒｓのソフトパーティショニングが達成される。例えば、図２の例では、ファームウェアインスタンス２０５、２０８、２１１、および２１４を実施して、それらの各ｆＰａｒインスタンス用の標準ＩＰＦファームウェアインターフェースが提供される。図示するように、ファームウェアインスタンス２０５は、ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６用の標準ＩＰＦファームウェアインターフェースを提供する；ファームウェアインスタンス２０８は、ＩＰＦ  ＬＩＮＵＸ  ＯＳ２０９用の標準ＩＰＦファームウェアインターフェースを提供する；ファームウェアインスタンス２１１は、ＷＩＮＤＯＷＳ  ＯＳ２１２用の標準ＩＰＦファームウェアインターフェースを提供する；ファームウェアインスタンス２１４は、Ｏｐｅｎ  ＶＭＳ  ＯＳ２１５用の標準ＩＰＦファームウェアインターフェースを提供する。図４と共に以下でさらに説明するように、このような標準ＩＰＦファームウェアインターフェースには、例として、ＡＣＰＩインターフェース、ＳＡＬインターフェース、ＥＦＩインターフェース、およびＰＡＬインターフェースが含まれ得る。
【００４７】
ファームウェアインスタンス２０５、２０８、２１１、および２１４は、それらの各ｆＰａｒインスタンス用の標準ＩＰＦファームウェアインターフェースを提供するように実施されるので、各ｆＰａｒは、このようなＯＳの変更を必要とすることなく（または、例えば、上述したようなｐｔｃ．ｇ命令を考慮するために、このようなＯＳの変更を最小限にすることができる）、任意の標準ＩＰＦ  ＯＳを含むことができる。このように、この例の実施の形態では、各ｆＰａｒインスタンスは、ＩＰＦ標準ファームウェアサービスのそれ自身のプライベートインスタンスを含み、これらのサービスが提供する記述は、そのｆＰａｒインスタンスに属する資源のみを記述している。例えば、ＩＰＦ標準ファームウェアインスタンス２０５は、第１のｆＰａｒインスタンス（ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６のインスタンスがそこで実行されている）に割り当てられた資源のみを記述している。すなわち、ファームウェアインスタンス２０５は、図２の例のＰＣＩカード２０２Ａおよび２０２Ｂ、ＣＰＵ２０３Ａ、ならびにメモリ２０４のセグメント２０４Ａおよび２０４Ｂのみを記述している。ＩＰＦ標準ファームウェアインスタンス２０５、２０８、２１１、および２１４は、ＩＰＦ標準インターフェースによって全体が抽象化されたｆＰａｒｓロジック２０１へのアクセスを共有する。
【００４８】
米国特許第６，５４２，９２６号では、あらゆるソフトパーティションが、ハードウェアからアプリケーションに至るまで、ソフトウェアの「スタック」全体を実行する（例えば、各ソフトパーティションは「コンソール」の個別のコピーを有する）が、この米国特許に記載されたソフトパーティショニング技法と異なり、ｆＰａｒｓのこの例の実施の形態では、「コア」ロジック２０１の１つのコピーが、ソフトパーティションのすべてについて実施され、ＩＰＦ標準ファームウェアサービス（２０５、２０８、２１１、および２１４）の個別のコピーが、ソフトパーティションについて実施される（例えば、個別のＩＰＦファームウェアインスタンスが、図２の例に示すように、各ソフトパーティションについて実行される）。したがって、ｆＰａｒｓのこの実施の形態は、「階層化された」ソフトウェアアーキテクチャモデルを使用する、その上にある「シェアドナッシング」の１組のファームウェアインスタンスを備えた共有コアを有する。一定の実施の形態では、コア２０１は、すべてのソフトパーティションにわたって資源を特定する情報を含み、個々のファームウェアインスタンスは、それらの各ソフトパーティションに利用可能な（割り当てられた）資源を特定する。
【００４９】
さらに、一定の実施の形態によって、静的なソフトパーティショニングおよび／または動的なソフトパーティショニングが可能になる。例えば、ｆＰａｒインスタンスの資源は、このようなｆＰａｒインスタンスの異なる資源（例えば、より多くの資源またはより少ない資源）を指定するようにｆＰａｒｓロジック２０１の構成データベースを変更することによって、（システムのランタイム中に）動的に変更することができる。動的構成をサポートするどのＯＳによっても、このようなＯＳを実行するソフトパーティションにおいて資源を動的に変更することが可能になる。例えば、システムが３つのｆＰａｒパーティションを有し、その２つが、動的な構成をサポートするＯＳを実行していると仮定する。この場合、動的な構成をサポートするＯＳを実行している２つのパーティション間で（シャットダウンすることなく）資源を動的に移動させることができる一方、動的な構成をサポートしないＯＳを実行しているソフトパーティション上では、（このＯＳをシャットダウンして、その各ソフトパーティションの構成を変更することにより）静的な構成を実行することができる。一実施態様によると、ＯＳは、以下のものを提供することによって動的な構成をサポートすることができる。
１）資源（例えば、ＰＣＩデバイス、ＣＰＵデバイス、およびメモリデバイス）の基本的なＡＣＰＩホットプラグ機能。
２）アドミニストレータがｆＰａｒｓを構成することを可能にする或るＯＳ特有のオンラインソフトパーティショニング構成ツール。このツールは、ｆＰａｒｓアウェアであり、ＥＦＩのｆｐｃｆｇ変数、および、（資源の動的な移動をサポートする）ｆＰａｒｓの一定の実施の形態について実施されたＡＣＰＩ拡張について知っている。
３）オプションとして、アプリケーションレベルツールが負荷バランスを行う必要なく（または追加することなく）、ＯＳカーネルスケジューラを変更して、同種のｆＰａｒｓ間でＣＰＵの負荷バランスを動的に行うことができる。
【００５０】
上記を考慮して、本明細書で説明する一定の実施の形態は、ＩＰＦベースのシステムのソフトパーティショニングを可能にする。ここで、このようなソフトパーティショニング技法は、標準ＩＰＦファームウェアインターフェースと互換性を有し、ＯＳを変更することなく（または最小の変更で）、任意の標準ＩＰＦ  ＯＳを各ソフトパーティションで実施できる（すなわち、ＩＰＦ  ＯＳは、その通常のＩＰＦファームウェアコールを行って、自身に割り当てられたハードウェア資源にアクセスすることができる）ようにする。これによって、単一のコンピュータまたは単一のハードパーティションの資源を複数のソフトパーティション間で隔離することが可能になる。このように、ＯＳの変更を必要とすることのない（または、ＯＳの変更を最小にする）、ＩＰＦベースのシステム（および、使用したい任意の１つまたは２つ以上の正常に動作するＩＰＦ  ＯＳ）のソフトパーティショニングの利点を認識することができる。ｆＰａｒｓパーティショニング技法の一定の実施の形態の実施態様例を以下でさらに説明する。
【００５１】
図３は、本明細書でさらに説明するように、図２のソフトパーティショニング技法等のソフトパーティショニング技法の一定の実施の形態のオペレーションフロー図を示している。オペレーションブロック３０１において、複数のソフトパーティションがシステム上で定義され、ＯＳが各ソフトパーティション上で実行される。ソフトパーティションの定義は、本明細書でさらに説明するｆｐｃｆｇ構成データベースと同様に、このようなソフトパーティションに一定のシステム資源を割り当てることによって行うことができる。もちろん、一定の実施態様では、ユーザインターフェースを提供して、ユーザが（例えば、ｆｐｃｆｇ構成データベースと対話することにより）所望のｆパーティションを定義することもできる。オペレーションブロック３０２において、個別のファームウェアインスタンスが各ソフトパーティションについてインスタンス化される。ここで、各ファームウェアインスタンスは、その各ソフトパーティションのＯＳ用の事前に定義された（標準の）ファームウェアインターフェース（例えば、標準ＩＰＦファームウェアインターフェース）を提供する。例えば、ファームウェアインスタンス２０５、２０８、２１１、および２１４は、図２の上記例における４つの個別のソフトパーティション用にインスタンス化される。一定の実施態様では、本明細書でさらに説明するように、要望に応じて、ファームウェアインスタンスによって提供される事前に定義されたファームウェアインターフェースを利用して、或るソフトパーティションから別のソフトパーティションへ資源を動的に移動させることができる。
【００５２】
好ましい実施の形態の一例の実施態様を図４〜図５と共に以下でさらに説明する。図４は、一般的なＩＰＦベースのシステム４００の抽象モデルを示している。このシステム４００は、ハードウェアプラットフォーム４０１、プロセッサ（単数または複数）４０２、ＯＳ４０３、およびシステムファームウェア４０７を備える。この例の実施態様では、システムファームウェア４０７は、プロセッサ抽象レイヤ（ＰＡＬ）４０４、システム抽象レイヤ（ＳＡＬ）４０５、および拡張ファームウェアインターフェース（ＥＦＩ）４０６を備える。
【００５３】
さまざまなプロセッサアーキテクチャがこの技術分野で知られており、Hewlett-Packard社（「ＨＰ」）によって開発されたＰＡ−ＲＩＳＣプロセッサファミリー、Ｉｎｔｅｌ社（「Ｉｎｔｅｌ」）のアーキテクチャ（「ＩＡ」）のプロセッサ（例えば、既知のＩＡ−３２プロセッサおよびＩＡ−６４プロセッサ）等が知られている。既知のように、ＩＡ−６４は、ＨＰおよびＩｎｔｅｌによって共同開発された６４ビットプロセッサアーキテクチャであり、このプロセッサは、明示的並列命令コンピューティング技術（ＥＰＩＣ）に基づいている。
【００５４】
図４に示す例のシステム４００は、既知のＩＴＡＮＩＵＭプロセッサファミリー用に実施されたような既知のＩＡ−６４アーキテクチャに従う。実施の形態は、他の任意のＩＰＦアーキテクチャ内で実施することもできる（したがって、図４に示すＩＡ−６４アーキテクチャにのみ限定されるものではない）が、以下では、好ましい実施の形態を、図４のＩＡ−６４システムアーキテクチャ内で使用するために実施したものとして説明する。ＩＡ−６４プロセッサアーキテクチャの定義は、ＩＡ−６４プロセッサを利用するシステムのファームウェアアーキテクチャ要素についての要件を指定する。このアーキテクチャの典型的なモデルは、「Intel IA-64 Architecture Software Developer’s Manual」, Volume 2: IA-64 System Architectureの第１１．１節のFirmware Model（非特許文献２）にあげられている。この文献には、ＩＡ−６４ファームウェアが、ＰＡＬ４０４、ＳＡＬ４０５、およびＥＦＩ４０６の３つの主要なコンポーネントを備え、これらのコンポーネントが、共に、ＯＳブート用のプロセッサおよびシステムの初期化を提供することが記載されている。３つのコンポーネント４０４、４０５、および４０６は、一定のＩＡ−６４コンピュータシステムに必要なシステムファームウェア機能のすべてを表しているとは限らないことがあり、さらに別のファームウェアも含めることができる。
【００５５】
ハードウェアプラットフォーム４０１は、システムのプロセッサ４０２以外に、システム４００のハードウェアコンポーネント（例えば、ハードパーティション）のすべての集合を表す。図４の抽象モデルに示す、これらのさまざまなコンポーネント間の矢印は、システム４００の挙動について可能な相互作用のタイプを示している。システム４００に最初に電源が投入されると、いくつかの健全性チェック（例えば、パワーオンセルフテスト）が、プラットフォーム４０１に含まれるマイクロプロセッサによって実行される。このマイクロプロセッサは、アプリケーションを実行するメインシステムプロセッサ４０２ではない。それらのチェックが合格した後、電源およびクロックがプロセッサ４０２に提供される。プロセッサ４０２は、システムのＲＯＭ（図４には具体的に図示せず）からコードの実行を開始する。実行されるコードはＰＡＬ４０４である。ＰＡＬ４０４は、システム４００の制御を取得する。ＰＡＬ４０４は、プロセッサ４０２のすべてを獲得するように実行されて、プロセッサが同じファームウェアを通じて同時に実行を開始するようにする。
【００５６】
ＰＡＬ４０４は、自身の役目であるプロセッサ（単数または複数）４０２の初期化を実行した後、システム４００の制御をＳＡＬ４０５に渡す。ＳＡＬ４０５の任務は、どのハードウェアがプラットフォーム４０１上に存在するかを発見すること、および、そのハードウェアを初期化してＯＳ４０３に利用可能にすることである。このハードウェアは主としてメインメモリである。メインメモリが初期化されて機能すると、ファームウェア４０７（すなわち、ＰＡＬ４０４、ＳＡＬ４０５、およびＥＦＩ４０６。これらはまだ実行されていない）は、メインメモリにコピーされる。次に、制御がＥＦＩ４０６に渡される。ＥＦＩ４０６は、ブートデバイスをアクティブにする任務を有する。ブートデバイスには、通常、ディスクが含まれる。ＥＦＩ４０６は、ディスクを読み出して、プログラムをメモリにロードする。このプログラムは、通常、オペレーティングシステムローダと呼ばれる。ＥＦＩ４０６は、ＯＳローダをメモリにロードし、次いで、プロセッサ４０２の１つ（通常、ブートスタートアッププロセッサと呼ばれる）を、このようなＯＳローダプログラムのエントリポイントに分岐させることによって、ＯＳローダにシステム４００の制御を渡す。
【００５７】
次に、ＯＳローダプログラムは、標準ファームウェアインターフェース４０７を使用して、システム４００を発見して初期化し、さらに制御する。ＯＳローダが、通常、マルチプロセッサシステムで行うものの１つは、他のプロセッサの制御を取ってくることである。例えば、この時点において、マルチプロセッサシステムでは、他のプロセッサは、何もしないループを実行中の場合がある。アドバンストコンフィギュレーションアンドパワーマネージメントインターフェース（「ＡＣＰＩ」）互換システムでは、ＯＳ４０３は、ＡＣＰＩ静的テーブルを構文解析して、マルチプロセッサシステム４００の他のプロセッサを発見し、そのテーブルのＡＣＰＩ  ＤＤＢをコンパイルして、ＡＭＬオブジェクトおよびＡＭＬメソッドを有するＡＣＰＩ「名前空間」にする。次いで、ＯＳ４０３は、ファームウェアインターフェース４０７を使用して、それら発見されたプロセッサをオペレーティングシステムコードへ分岐させる。その時点で、ＯＳ４０３はプロセッサのすべてを制御し、ファームウェア４０７はもはやシステム４０３を制御していない。ランタイムにおいて、ＯＳは、ＡＣＰＩ名前空間をインタープリットし、そのオブジェクトと相互作用して、さまざまな機能ステップを実行する。
【００５８】
ＯＳ４０３は、初期化されるにつれて、どのハードウェアがブート時に存在するかをファームウェア４０７から発見する。そして、ＡＣＰＩ標準規格では、ＯＳ４０３は、ランタイムにおいて、どのハードウェアが存在するか、または、どのハードウェアが追加もしくは除去されるかも発見する。ＡＣＰＩ互換システムに存在し得るハードウェアを発見する際に、ＯＳ４０３は、システムのＡＣＰＩテーブル（単数または複数）にアクセスする。ＯＳは、システムの初期化中にファンクションコールを使用して、ＡＣＰＩテーブルのアドレスを見つけ出す。それらＡＣＰＩテーブルへのポインタは、ＥＦＩシステムテーブルポインタに渡される。ＥＦＩシステムテーブルポインタは、図４の標準ＥＦＩプロシージャコール４０８の１つを行うことによって取得される。したがって、ＥＦＩプロシージャコール４０８は、システム４００のハードウェアを記述するＡＣＰＩテーブルのアドレスを渡すのに使用される。ＯＳ４０３がブート時にアクセスするこのようなＡＣＰＩテーブルは、システム４００に利用可能な資源を記述する。
【００５９】
ｆＰａｒｓパーティショニング技法の一実施の形態に従って図４の上記ＩＡ−６４アーキテクチャ用に実施できる一例のファームウェアアーキテクチャを図５に示す。このような例のファームウェアアーキテクチャは、本明細書では、Ｂａｎｙａｎアーキテクチャと呼ぶことにする。上記図２は、Ｂａｎｙａｎアーキテクチャの一例のブロック図を示している。
【００６０】
図５の特定の例のＢａｎｙａｎアーキテクチャ５００は、フレームワークにコンポーネントを加えたモデルのアプリケーションである。一般に、フレームワークは、システム機能の本体を備えるドメイン特有の１組のソフトウェア機能である。コンポーネントは、フレームワークと協力して、明確に定義されたインターフェースを介して互いに相互作用し、全体的なシステム機能を達成する。２００３年１０月１４日に出願され、同時係属中で、かつ、本発明の譲受人に譲渡された「SYSTEM AND METHOD FOR DEVELOPMENT OF FIRMWARE」という発明の名称の米国特許出願第１０／６８４，９８５号は、さらに、ファームウェアを効率的に開発するこの例のＢａｎｙａｎアーキテクチャの使用を記載している。この米国特許出願は、現在、米国特許出願公開第２００４／０２６８２９５号（特許文献３）で公開されている。このように、図５の例の実施の形態を利用して、ｆＰａｒｓを実施する（例えば、図２に関して上述したファームウェアインターフェース２０５、２０８、２１１、および２１４、ならびにｆＰａｒｓロジック２０１を実施する）ファームウェアの効率的な開発を可能にすることができる。
【００６１】
管理プロセッサ（ＭＰ）およびユーティリティマイクロコントローラとは対照的に、Ｂａｎｙａｎファームウェア５００は、ＩＰＦ計算プロセッサ上で実行される、ＣＰＵに特有でない（例えば、ＰＡＬ）システムファームウェアのすべてを表す。Ｂａｎｙａｎファームウェア５００は、通常のシステム動作中に、リセットイベントおよび電源投入イベント、ハードウェアの発見および初期化、ハードウェア記述、システムソフトウェアのロードおよび起動、ならびにハードウェアに依存した機能をハンドリングする任務を有する。この通常のシステム動作には、ハードウェアの再構成およびエラーハンドリングが含まれる。ＰＡＬの観点からすると、Ｂａｎｙａｎファームウェア５００はＳＡＬのように見える。
【００６２】
この例のＢａｎｙａｎアーキテクチャ５００の各要素は以下のように記述される。
（１）ＡＣＰＩテーブル５０８：ＡＣＰＩテーブル５０８は、ＡＣＰＩ互換システムのＯＳに対するＡＣＰＩ互換システムの資源を記述した既知のテーブルである。資源の記述データおよび記述コードをＡＣＰＩテーブルに含めることができる。これらの記述は、静的テーブル、および、ＡＣＰＩマシン言語（ＡＭＬ）を含む名前空間オブジェクトを含む。ＡＭＬは、インタープリタ型言語であり、制御機能を実施するオプションをサポートする。これによって、ＯＳは、十分に制御されたランタイムの状況で、ファームウェアに類似したオペレーションを実行することが可能になる。この手法の価値は、自身を異常なファームウェアから保護する一方、ＯＳが実行される各プラットフォームについて、すべてが類似しているが相違した無数のハードウェアに依存した機能を含める必要がないことである。
【００６３】
Ｂａｎｙａｎシステムは、システムに存在する実際のハードウェアに基づいて、ブート時にＡＭＬプログラムセグメントを動的に生成する機能を含むように実施することができる。これは、２００３年５月２８日に出願され、同時係属中で、かつ、本発明の譲受人に譲渡された「SYSTEM AND METHOD FOR GENERATING ACPI MACHINE LANGUAGE TABLES」という発明の名称の米国特許出願公開第２００４／０２４３５３４号（特許文献４）に十分に記載されているのと同様のものである。
（２）ＡＣＰＩエージェント５０９：ＡＣＰＩエージェント５０９は、ＡＣＰＩ（標準）ファームウェア機能をエクスポートする任務を有する。このモデルでは、ＡＣＰＩエージェント５０９は、コア５０１が初期化された後、ブートストラップ中に制御を与えられるコードである。このブートストラップ中に、ＡＣＰＩエージェント５０９は、システムの内部表現を、外部標準規格によって必要とされる表現に変換する。ＡＣＰＩエージェント５０９は、ＡＣＰＩインターフェースの発展したものを、システムの記述およびいくつかのハードウェア機能の制御を行うのに内部で使用されるものから分離する点で、プロキシ設計パターンと類似している。
（３）ＥＦＩ  ＡＢＩ５１０：ＥＦＩ  ＡＢＩ５１０は、ＯＳローダおよび初期のＯＳ初期化コードにブートサービスを提供する外部インターフェース（プロシージャコールベース）のＩＡ−６４標準セットである。また、ＥＦＩ  ＡＢＩ５１０は、ＯＳに全制御が与えられた後であっても、ブート時のサービスが利用可能でなくなった時であっても、利用可能な、まさに最小限の１組のランタイムサービスも含む。ＥＦＩパッケージは、標準ＥＦＩブートドライバをサポートするＥＦＩブートドライバランタイム基盤も含む。
（４）ＳＡＬ  ＡＢＩ５１１：この表面（veneer）;（別のアダプタパターン）は、ＩＡ−６４アーキテクチャが必要とする標準ＩＡ−６４ファームウェアプロシージャインターフェースを実施する。また、ＳＡＬ  ＡＢＩ５１１は、製品差別化機能用のＯＥＭ特有のプロシージャも実施する。内部では、ＯＥＭ特有の機能が、サブパッケージまたは個別のコンポーネント（単数または複数）に分離されていることがある。
（５）ＳＡＬ  ＰＭＩ５１２：プラットフォーム管理割り込み（ＰＭＩ）は、オペレーティングシステムのサポートも新たなファームウェアインターフェースも必要としない機能的拡張を可能にするためにプロセッサが提供するメカニズムである。通常、このような機能は、ファームウェアの援助を有する専用ハードウェアの組み合わせで実施されることになる。したがって、通常、プロセッサ内に構築されて、ＰＡＬによりサポートされたファームウェアの援助をトリガするメカニズムが存在する。ＳＡＬ  ＰＭＩアダプタは、そのプログラムイメージが、シーケンサによって個別のプログラムエンティティとしてメインメモリ内にインスタンス化される点で、ＡＣＰＩエージェント５０９、ＥＦＩ  ＡＢＩ５１０、ＳＡＬ  ＡＢＩ５１１と類似している。しかしながら、ＳＡＬ  ＰＭＩアダプタは、オペレーティングシステムソフトウェアとファームウェアとの間のインターフェースを提供するこれら他のものとは異なる。その代わり、ＳＡＬ  ＰＭＩは、ＰＡＬとＳＡＬとの間のインターフェースを提供する。ＰＭＩ割り込みは、アーキテクチャ上、（ＰＡＬの観点からすると）ＳＡＬによってハンドリングされるハードウェアイベントであるが、このモジュール型のＢａｎｙａｎシステムでは、他のメモリ常駐アダプタと同様に、Ｂａｎｙａｎコアの「上に」階層化された、ＳＡＬから分離したプログラムとして最も良く実施される。
（６）移植可能コア（または「データベース」、例えば「構成データベース」）５０１：これは、いくつかの機能を実施するマルチパッケージのパッケージである。システムハードウェア構成の完全で動的な記述は、「デバイスツリー」アーキテクチャパターン５０５を実施するサブシステムに保持される。フレームワークをブートストラップするコンソール等のコアＩ／Ｏドライバは、リモートコンソールプロトコル、デバッガサポート５０７、システム初期化調整、エラーハンドリング調整、および、移植可能にすることができるファームウェアシステム機能の基本的にほとんどのように、このパッケージの一部である。
【００６４】
図５のこの例の実施の形態によると、コア５０１は、図２のｆＰａｒｓロジック２０１を実施する。コア５０１の要素を、以下のように、より十分に説明する。
（ａ）デバイスツリー５０５：システムプラットフォームのハードウェアコンポーネントおよびソフトウェアコンポーネントを表すバインドされたコンポーネント（bound-component）の動的システムであるＢａｎｙａｎコンポーネントツリーパッケージである。デバイスツリー５０５は、ハードパーティションのすべてのハードウェアを記述する（したがって、これは、各ソフトパーティションのハードウェアを結合したものである）。また、デバイスツリー５０５はソフトウェアオブジェクトも含む。これらのソフトウェアオブジェクトの１つがｆＰａｒｓコンポーネントである。このソフトウェアオブジェクトは、どのハードウェアが各ｆＰａｒに属するかの「データベース」を実際に含むｆｐｃｆｇ  ＮＶＲＡＭ変数を有する相互作用をサポートするコードおよびデータを含む。この変数は、ｆＰａｒｓコンポーネントが、インストールされたメモリデバイスを多くの「擬似」メモリデバイスに再分割するのに必要なデータも含む。「擬似」メモリデバイスは、物理メモリの交わらない領域であり、この交わらない領域は、ＯＳには、ＯＳ名前空間の個々のメモリデバイスとして見える。したがって、デバイスツリー５０５は、「スパニング名前空間」を表す（スパニング名前空間は、各ｆＰａｒインスタンスのすべての名前空間を結合したものである）。この例の実施の形態では、（例えば、ソフトパーティション内の）ハードパーティション上で実施されるあらゆるＯＳインスタンスは、ハードパーティションのハードウェアのすべての記述を有するが、名前空間における各デバイスのデバイス範囲のＡＣＰＩ＿ＳＴＡ（ステータス）オブジェクトは、そのＯＳインスタンスがそのデバイスを「所有する」かどうかを示す。
（ｂ）コンポーネント５０６：これは、デバイスツリー５０５にインスタンス化するのに利用可能なコンポーネントの緩やかに結合されたバイナリイメージの集約体を表す。いくつかは、ネットワークプロトコル、バッファキャッシュ等の共有可能なサービスを表す「ソフトウェアパッケージ」であり、それ以外は、実際のシステムハードウェアコンポーネントに対応する、ツリーの「デバイスノード」を実施する「ハードウェアパッケージ」である。インスタンス化されたコンポーネントは、ブート時に構築されたコンポーネントツリーに存在する。したがって、ツリーコンポーネント５０６は、図６〜図８に示す「ｆｐｃｆｇ」変数６１によって指定されるようなｆＰａｒインスタンスに割り当て可能なハードパーティションのハードウェア資源を含む。これについては、以下でさらに説明する。
（ｃ）デバッガ５０７：このパッケージは、デバッグのローカルモデルおよびリモートモデルの双方をサポートする対話型デバッガ機能を表す。リモートモデルは、サポートされた任意のデバイス（通常、シリアル接続またはＬＡＮ接続）を通じて接続することができる。ローカルデバッガは、直接リンク接続を通じて使用されることが予想される。ローカルデバッグは、必要なシンボルテーブルが利用可能でない場合があるので、ソースレベルのデバッグをサポートしないことがある。
（ｄ）コアフレームワーク５０２：メモリ管理、プリミティブコンソール等を含み、デバイスツリーパッケージ５０５をサポートするが、モジュール性のためにそのパッケージの外側でより良く収集されたサポートサービスである。主要な「コンポーネントバインド」および「コンポーネントフレームワーク」の基盤、エラーハンドリング基盤、ならびに、「ＯＳ類似の」基盤（ロックプリミティブ、ロックトレース、イベントログ記録等をここで実施することができる）。
（ｅ）イベントシーケンサ５０３：順序付けを必要とする主要な２種類のイベントには、初期化イベントおよびエラーハンドリングイベントが含まれる。このパッケージは、集中化ハンドリングメカニズムを表すものではない。逆に、本発明者らは、これを異なる音楽家の「オーケストラ」の「指揮者」と考える。各音楽家は、自身の楽器（初期化、エラーのハンドリング）を演奏する方法を知っているが、交響曲全体の楽譜は知らない。指揮者はこの楽譜を知っているが、各楽器を演奏する方法を知らない。シーケンサ５０３は、指揮者のように、「調整器」として機能する。これは、分散エラーハンドリングシステムおよび集中化エラーハンドリングシステムの双方の利点を損失なく提供する。
（ｆ）ＳＡＬ基板５０４：このパッケージは、ＰＡＬ要件と一致するＳＡＬ＿ＥＮＴＲＹ機能を表す。また、このパッケージは、プラットフォームに依存したいくつかのファブリック初期化プリミティブおよびエラーハンドリングフレームワークも含む。プロセッサ命令セットに依存するか、または、依存することがある１組のプラットフォームから独立した機能もある。プロセッサモデルに依存したコードは、この基板パッケージで実施することもできるし、プロセッサに対応するコンポーネント（または両者の組み合わせ）で実施することもできる。また、ＳＡＬ＿基板は、他のパッケージおよびコンポーネントツリーのコンポーネントにサービスをエクスポートすることも行う。
【００６５】
ｆＰａｒｓの一実施の形態に従ってｆＰａｒｓのファームウェアを実施する一例の技法を図５のアーキテクチャと共に説明するが、他のさまざまな技法を利用して、このようなファームウェアを開発／実施することができる。したがって、本明細書に提示する実施の形態は、図５の例のＢａｎｙａｎアーキテクチャから開発された実施態様にのみ限定されることを意図したものではなく、ＩＰＦベースのシステム（または、事前に定義された（例えば、業界標準）ファームウェアインターフェースを有する他のシステム）のソフトパーティショニングを実施する他のさまざまなアーキテクチャを包含することを意図している。一方、図５のＢａｎｙａｎアーキテクチャを使用することによって、同時係属中で、かつ、本発明の譲受人に譲渡された「SYSTEM AND METHOD FOR DEVELOPMENT OF FIRMWARE」という発明の名称の米国特許出願第１０／６８４，９８５号である米国特許出願公開第２００４／０２６８２９５号のように、ＩＰＦベースのシステムのソフトパーティショニングを実施するファームウェアを効率的に開発できると考えられる。
【００６６】
図６は、好ましい実施の形態に従ってハードパーティション内で実施された一例のＢａｎｙａｎソフトウェアスタックの高レベルの図を示している。すなわち、図６は、ハードパーティション上で実施された１つのｆＰａｒインスタンスのソフトウェアスタックの一例を示している。上記の図２〜図３と共に説明したように、このようなｆＰａｒインスタンスの複数のものを単一のハードパーティション内で実施することができる。ここで、以下でさらに説明するファームウェアインターフェース６０３、６０４、６０５、および６０６は、各ソフトパーティション用に複製することができる。図６の例のｆＰａｒインスタンスは、ＩＰＦ  ＯＳ６０７および対応するアプリケーション（単数または複数）６０８を含む。例えば、図２の例では、第１のｆＰａｒインスタンスは、ＩＰＦ  ＨＰ−ＵＸ  ＯＳ２０６およびＨＰ−ＵＸアプリケーション（単数または複数）２０７を含む。ファームウェアインスタンスは、図６の例のｆＰａｒインスタンス用の標準ＩＰＦファームウェアインターフェース６０３、６０４、６０５、および６０６を提供する。例えば、図２の例では、第１のｆＰａｒインスタンスは、ファームウェアインスタンス２０５を含み、このファームウェアインスタンス２０５は、図６の例の実施態様では、ＡＣＰＩエージェント６０３、ＥＦＩアダプタ６０４、ＳＡＬアダプタ６０５、およびＰＡＬイメージ６０６を含むことになる。ＡＣＰＩエージェント６０３は、図５で上述したＡＣＰＩエージェント５０９に対応する。同様に、ＥＦＩアダプタ６０４およびＳＡＬアダプタ６０５は、それぞれ、図５のＥＦＩ  ＡＢＩ５１０およびＳＡＬ  ＡＢＩ５１１に対応する。そして、ＰＡＬイメージ６０６は、図５のＰＡＬ４０４に対応する。
【００６７】
さらに、ＰＭＩエージェント６０２は、図５のＳＡＬ  ＰＭＩ５１２に対応する。ＰＭＩエージェント６０２は、「プラットフォーム管理割り込み」エージェントであり、この「プラットフォーム管理割り込み」エージェントは、ＩＰＦ命令セットアーキテクチャによって必要とされる。このファームウェアは、ＲＡＭ常駐（ＲＯＭではない）であることが必要とされ、ＳＡＬは、そのアドレスを、そのパーティションのあらゆるＣＰＵのＰＡＬに登録しなければならない。さらに、ＣＰＵの実施態様には、ＰＭＩハンドラアドレスの再登録を禁止することが可能にされる。したがって、ＣＰＵの移動をサポートするために、ｆＰａｒｓシステムのＰＭＩハンドラのコピーは１つだけ存在しなければならず、このハンドラは、「セグメント化された」挙動をサポートしなければならない。この例の実施の形態は、ＰＭＩを使用して、ＣＰＵがＰＡＬのコールドリセットパスを実際に通過する必要なく、プロセッサのリセットをシミュレーションする。
【００６８】
これに加えて、Ｂａｎｙａｎフレームワーク／コンポーネントコア６０１は、図５のＢａｎｙａｎコア５０１に対応し、図２のｆＰａｒｓロジック２０１を実施する。したがって、Ｂａｎｙａｎフレームワーク／コンポーネントコア６０１は、図６のこのｆＰａｒインスタンスに割り当てられるハードウェア資源を指定する構成データベース（例えば、ＮＶＲＡＭ変数「ｆｐｃｆｇ」６１）を提供する。また、ＩＰＦ  ＯＳ６０７は、当該ＯＳがハードパーティション（ソフトパーティションを有しない）の単独のＩＰＦ  ＯＳとして実施された場合に当該ＯＳが行うように、標準ＩＰＦインターフェース６０３、６０４、６０５、および６０６を利用して、その資源にアクセスすることができる。この例の実施の形態では、コア６０１もＰＭＩエージェント６０２も複製されない（しかし、逆に、ソフトパーティションにわたってこれらのコンポーネントの１つのコピーは存在する）が、インターフェース６０３〜６０６のインスタンスごとの（すなわち、ソフトパーティションインスタンスごとの）コピーは存在する。
【００６９】
図７は、一実施の形態に従って、図６の要素６１によって表された永続的なｆＰａｒｓ構成データベース機能を有する４つの異なる使用ケース（相互作用のタイプ）を示す高レベルの使用ケース図を示している。中心の使用ケース７０３は、外側の使用ケース７０１、７０２、および７０４のそれぞれによって使用される相互作用を表す。使用ケース７０１は、オペレータ７０９が、オペレーティングシステム（７０７、７０８）が存在しない場合に、ファームウェアユーザインターフェース（７０５）を使用してファームウェアと相互作用（対話）する場合のｆＰａｒｓの構成を表す。ファームウェアユーザインターフェース（７０５）は、ファームウェア内に構築することもできるし、ＥＦＩアダプタ（６０４）のファームウェアアプリケーションバイナリインターフェース（７０６）を利用するファームウェア（ＥＦＩ）アプリケーションプログラムとして一時的にロードすることもできる。「オンラインを構成する」使用ケース（７０２）は、オペレータ（７０９）がユーザインターフェースプログラムを通じてオペレーティングシステム（７０７）と相互作用（対話）することを表す。このユーザインターフェースプログラムは、そのオペレーティングシステム（７０８）上で実行されて、ｆＰａｒｓ構成を変更する。７０１のシナリオおよび７０２のシナリオの双方で実行されるいくつかのオペレーションは、新たなｆＰａｒｓの作成、および、ハードウェア資源の所有権を新たなｆＰａｒｓに割り当てることを含む。別のオペレーションは、オペレータがブートしたいｆＰｒａｓに配分できる、サーバの利用可能なハードウェアの「在庫調べ」を実行することを含む。興味のある１組の使用ケースは、「自動移動」（７０４）によって表される。この自動移動では、同種のｆＰａｒインスタンス内においてそれぞれ現在実行中のオペレーティングシステムが、オペレータが介入して、または、オペレータが介入することなく、共同して或るｆＰａｒから別のｆＰａｒへハードウェアの所有権を移動させる。例えば、システムの負荷に応じて、共同したオペレーティングシステム内の発見的方法によって決定された判断およびその開始により、ハードウェア資源をｆＰａｒインスタンス間で移すことができる。
【００７０】
図８は、ｆＰａｒソフトパーティショニング技法の一実施の形態による一例のｆＰａｒドメインモデルを示している。この例によると、このｆＰａｒモデルは、基本的に、ｎＰａｒｔｉｔｉｏｎｓモデルの上位セットである。一方、ファームウェアサービスの単一のインスタンスを有するのではなく、「ｎ」個のソフトパーティションについて、ファームウェアサービスの「ｎ」個のインスタンスが存在する。各インスタンスは、それ自身のテキストおよびデータを有し、ｎＰａｒｔｉｔｉｏｎのメモリ内の個別の物理アドレス空間に存在する。各ｆＰａｒインスタンスによって利用されるハードウェア資源は、一般に、ｎＰａｒｔｉｔｉｏｎ内の個別のプロセッサ、個別のＩ／Ｏカード、および物理メモリの個別の領域といった非共有資源である。一定の実施の形態によると、ｎＰａｒｔｉｔｉｏｎ内で構成可能なｆＰａｒｓの個数は変化する（例えば、ＩＡ−６４アーキテクチャでは１から６４に変化する）。
【００７１】
図８の例のモデルは、ｎＰａｒｔｉｔｉｏｎ内の２つのアクティブなｆＰａｒインスタンスを示している。一方のｆＰａｒインスタンスは、そこで実行されるＩＰＦ  ＯＳインスタンスＸ（図８では８０１のラベルを有する）を備え、第２のｆＰａｒインスタンスは、そこで実行されるＩＰＦ  ＯＳインスタンスＹ（図８ではラベル８０２を有する）を備える。Ｂａｎｙａｎコア６０１は、ｆＰａｒｓ構成データベース（例えば、上述したようなＮＶＲＡＭ変数「ｆｐｃｆｇ」６１）を備える。このｆＰａｒｓ構成データベースは、２つのｆＰａｒｓのそれぞれに割り当てられたプラットフォームハードウェア８０５の資源を指定する。例えば、この例では、ハードウェア資源８０６はｆＰａｒ  Ｘに割り当てられ、ハードウェア資源８０７はｆＰａｒ  Ｙに割り当てられる。ハードウェア資源８０６は、ＣＰＵ（単数または複数）８０６Ａ、ＰＣＩカード（単数または複数）８０６Ｂ、およびメモリセグメント（単数または複数）８０６Ｃを含む。ハードウェア資源８０７は、メモリセグメント（単数または複数）８０７Ａ、ＰＣＩカード（単数または複数）８０７Ｂ、およびＣＰＵ（単数または複数）８０７Ｃを含む。
【００７２】
ｎＰａｒｔｉｔｉｏｎ内には、ｆＰａｒｓのすべて（この事例では、２つのｆＰａｒインスタンス）によって共有されるＢａｎｙａｎコア６０１の１つのインスタンスが存在することに留意すべきである。ファームウェアインターフェースインスタンス８０３および８０４は、各ＯＳが、通常の（ｆＰａｒに関係しない）オペレーションシナリオ中に、他のｆＰａｒインスタンスに基本的に全く気付かないように、共有資源を抽象化する。ｆＰａｒに関係したシナリオが発生すると、或る値がｎＰａｒｔｉｔｉｏｎ内の他のｆＰａｒｓに気付かせる。例えば、構成ツールは、ｆＰａｒ  Ｘで実行されて、ｎＰａｒｔｉｔｉｏｎ内の利用可能な資源（すなわち、構成データベースｆｐｃｆｇ６１によって定義された、新たなｆＰａｒ  Ｙに割り当てられる資源）を使用する新たなｆＰａｒ  Ｙを作成してブートすることができる。図８の上述した例の実施態様は、例えば、米国特許第６，５４２，９２６号（特許文献５）のソフトパーティショニング技法とは大きく異なることが認識されるべきである。この米国特許では、各ソフトパーティションは、「コンソール」プログラムの完全に個別のコピーを実行し、多数の逐次および並列のブートシナリオおよび再ブートシナリオを取り扱う複雑なプロトコルが存在する。
【００７３】
ｆＰａｒがｎＰａｒｔｉｔｉｏｎ内の他のｆＰａｒｓに気付くことが有益である、ｆＰａｒに関係したシナリオの別の例は、ｆＰａｒパーティション間でデバイスを移動させる場合である。このようなｆＰａｒに関係したシナリオの別の例は、ハードウェアのすべての健全性を監視したいが、プログラムが１つだけのｆＰａｒインスタンスで実行される診断の実行である。このような診断システムを構成することができ、この診断システムによって、各ｆＰａｒ  ＯＳインスタンスで実行されるデーモンプロセスは、データを収集し、そのデータを、単一のｆＰａｒ（または他の場所）で実行される高レベルのユーザインターフェースツールに転送する。この単一のｆＰａｒでは、非常に多くのデータが集約される（「ｎＰａｒｔｉｔｉｏｎ」レベルにおけるすべてのハードウェアのロールアップ）。
【００７４】
一定の実施の形態によると、ｆＰａｒｓパーティショニング技法は、或るｆＰａｒが別のｆＰａｒの存在に気付くことを可能にするいくつかのメカニズムを含むことができる。このメカニズムには、次のものが含まれる。
Ａ）デバイスのＦＰＮメソッド値は、ｆＰａｒに割り当てることができるあらゆるデバイスについて、所有しているｆＰａｒのｆＰａｒ数を特定するものである。このデータは、あらゆるｆＰａｒがすべてのハードウェアの在庫調べを行うのに使用され、所与のハードパーティション上のあらゆるソフトパーティションにスパニング名前空間を公開するための値の１つである。
Ｂ）ｆｐｃｆｇ変数は、それ自体、他のｆＰａｒｓの存在を暗示し、あらゆるｆＰａｒにより見られ得る。
Ｃ）メモリデバイスは、共有資源として割り当てることができ、ＯＳは、さまざまなアルゴリズムを使用して互いにメッセージを送受信するのに、これらの領域を使用することができる。
Ｄ）ｆＰａｒｓは、すべてのｆＰａｒｓがアクセスできる「共有ＥＦＩ可変ＧＵＩＤ」名前空間を提供する。これによって、或るＯＳインスタンスは、ＥＦＩ変数を設定することが可能になり、他のどのＯＳインスタンス（ｆＰａｒ同種）もその変数を読み出したり、設定したりすることが可能になる。このＧＵＩＤの値を知っているＯＳは、特定のメモリ領域にマッピングする必要も、プロトコルのロックについて心配する必要もなく、そのＧＵＩＤを使用して、互いにメッセージを送信することができる。
Ｅ）ＯＳは、（実行中の場合）、それらＯＳのＡＣＰＩ名前空間に（存在し、機能するが、無効にされているものとして）列挙された他のＣＰＵに送信された、指令されたプロセッサ間割り込み（ＩＰＩ）を使用することができる。このメカニズムは、共有ＥＦＩ可変ＧＵＩＤによって増強され、ＯＳ不可知（OS agnostic）型で「ハートビート」機能を実施するのに使用することができる。
【００７５】
図８の例では、各ｆＰａｒのＯＳは、標準ＩＰＦファームウェアコールを使用して、その各資源とインターフェースすることができる。これは、当該ＯＳがＩＰＦベースのシステム（ソフトパーティショニングを有しない）上で単独のＯＳとして実施された場合に行うのと同様である。
【００７６】
図９は、セルラーＩＰＦコンピュータシステムの電源投入からの初期ブートストラップの一例のオペレーションフロー図９００を示している。このファームウェアを使用して、非セルラーＩＰＦコンピュータシステムをブートおよび構成する場合には、類似するが、より簡単なシーケンスを使用することもできる。
【００７７】
オペレーションブロック９０１は、最も内部の仕組みがメーカ独自のものであるＩｎｔｅｌのプロセッサ抽象レイヤ（ＰＡＬ）ファームウェア（図４では４０４のラベルを有する）のパワーオンリセットおよび実行を表す。ＰＡＬを終了してオペレーションブロック９０２に入ると、リセットに続いて、最初に、システム抽象レイヤ（ＳＡＬ）ファームウェア（図４では４０５のラベルを有する）が実行される。ＳＡＬは、この図のオペレーションブロック９０２〜９３０において表される非プロセッサファームウェアのすべてのアーキテクチャ名である。
【００７８】
（マルチセル構成の）各セルは、同じファームウェアのコピーを含み、その初期化を開始する。この初期化は、「ハードパーティション」または「ｎＰａｒ」と呼ばれるものを形成する際に初期化に参加する他のセルを（現在のところは）知らないで、または、当該他のセルとの通信機能を有しないで行われる。オペレーションブロック９２６（「全ＣＰＵアクティビティ」）は、ＰＡＬを終了してＳＡＬに入ったあらゆるＣＰＵが実行するオペレーションシーケンスを表す。
【００７９】
オペレーションブロック９０２は、設計されたＳＡＬからＰＡＬへのハンドオフを表す。このハンドオフは、上記で引用したＩｎｔｅｌのＩＰＦアーキテクチャ仕様によって定義されたものである。オペレーションブロック９０３は、健全性チェック（ＰＡＬからのステータス）およびマルチＣＰＵランデブーを実行して、単一のプロセッサ（ここでは、セルマスタと呼ぶ）を選択するファームウェアを表す。このセルマスタは、ブロック９２８（「セルマスタアクティビティ」）に示すセル初期化を続行することになる。不健全なプロセッサ（ＰＡＬセルフテストで不合格であるプロセッサ）は、このブロックより先に実行を継続することが阻止される。不健全なプロセッサがその後のステップを通らない状態に維持しておく必要があるということは、当業者には容易に理解されよう。このような機能を効率的に達成するハードウェアおよび／またはファームウェアの多くの実施の形態がこの技術分野には存在する。したがって、これについては、本明細書ではこれ以上説明しない。
【００８０】
健全なプロセッサは、オペレーションブロック９０４に入ることによって、セルマスタの選択後の処理を継続する。オペレーションブロック９０４では、各プロセッサが、ＰＡＬサービスを呼び出して、それ自身の内部キャッシュメモリを初期化する。ブロック９０４のキャッシュの初期化に続いて、各ＣＰＵは、判断（９０５）を実行し、セルスレーブアクティビティ（９２７）またはセルマスタアクティビティ（９２８）のラベルを有するいずれかのオペレーションブロックに入る。
【００８１】
ＣＰＵは、スレーブである場合に、自身のマスタから命令を得るために監視（９０６）を開始する。この命令はブロック９０７で実行される、命令の例には、調整されたセルフテストオペレーション、および、オペレーションブロック９１７でアプリケーションプロセッサ（ＡＰ）になるために継続するコマンドが含まれる。セルマスタＣＰＵは、後のセルフテストオペレーション中に不合格になる可能性があるので、スレーブも、マスタの前進／進行および健全性を監視する。（処理ステップ９０８〜９１５を通る前進進行がないことを観察することにより）マスタの故障が検出されると、セルスレーブは、自身をマスタに昇進させ、マスタの構成解除を行い、エラーイベントをログ記録し、次いで、サーバをリセットする。再ブート時に、健全であると推定された異なるマスタが選択され、ブートがさらに進行する。
【００８２】
マルチセルサーバの各セルはセルマスタを含むので、オペレーションブロック９０８〜９１５は、それ自身の構成されたハードウェアに従って、各セルにより並列に実行することができる。この並列性は、大規模なＩ／Ｏハードウェア構成を有する大規模サーバでは非常に望ましい。その理由は、Ｉ／Ｏハードウェアコンポーネントの発見および初期化が、通例、非常に多くの時間を要するからである。また、大規模な物理メモリアレイの構成および初期化も、ブート中にこのようなセルごとの並列性から利益を得る。
【００８３】
この判断ポイント（９０５）を通過すると、ＣＰＵは、スタックなしで、レジスタおよびＲＯＭのみを使用して実行を続ける。セルラーメモリシステムは、構成するのにかなり複雑であるので、Ｃ等の高級言語でこの作業を実行するファームウェアを作成することが望ましい。Ｃは、大きなスタックおよびヒープを必要とする手続型言語である。これは、ファームウェアがメモリを使用して当該メモリを初期化できないことを意味する。したがって、初期化には問題にならない、少量の、おそらく１メガバイトの特別なメモリを含めることがこのようなシステムにはよく見られる。このようなメモリは、多くの場合、性能が低く、必ずしもコヒーレントとは限らない。この例の実施の形態では、このようなメモリはＳＲＡＭ（スタティックＲＡＭ）と呼ばれる。したがって、セルマスタにとって最初の重要なタスクは、ＳＲＡＭおよびＣランタイム（ＣＲＴ）環境を初期化することである。したがって、処理ステップの残り（スレーブを含む）は、スタックを必要とする高級言語で記述することができ、ヒープテーブルや割り込みテーブル等のソフトウェア資源を使用することができる。この作業を図９のオペレーションブロック９０８によって表す。スタックおよびそれらスタックのバッキングストア（ＩＰＦ要件）が、そのセルの各ＣＰＵのマスタによって作成された後、命令が、監視中（９０６）のスレーブに送信され、スレーブは、自身の内部レジスタを初期化して、新たなスタックおよび割り込みテーブルを使用するように指令を受ける（９０７）。その後、スレーブは、高級言語で記述された命令も実行するように指令を受けることができる。
【００８４】
次に、セルマスタは、ブロック９０９に示すように、セルブートストラップの残りの綿密な順序付けを調整するのに使用するデータ構造体を初期化する。ブロック９１０は、不揮発性ＲＡＭ（ＮＶＲＡＭ）構成のオプションが事前に真に設定されていた場合に、内部デバッグモジュールを有効にする判断ポイントを提供する。この変数が真である場合、オペレーションブロック９１１が実行される。このデバッガは、対話型デバッグまたはリモートデバッグ用の簡単なＵＡＲＴおよび／またはＬＡＮデバイスドライバを含む。この変数が偽である場合、セルマスタはブロック９１１をスキップし、ブロック９１２のそのセルごとの初期化を継続する。
【００８５】
オペレーションブロック９１２は、Ｂａｎｙａｎファームウェアアーキテクチャによって使用されるツリーベースの（階層的な）データベースのルートを作成し、最小限のコンポーネント／フレームワークのデータ構造体を初期化して、データベースのブランチおよびノードの成長を可能にする。オペレーションブロック９１３は、セル内のさまざまなハードウェア要素（例えば、メモリ、Ｉ／Ｏ）およびセルに接続されたさまざまなハードウェア要素（例えばＩ／Ｏ）の発見および初期化を表す。要素が発見され、初期化されると、ツリーデータベースは、新たなブランチおよびノードを「成長」させる。
【００８６】
対象のパーティションの各セルで並列に行われるブロック９１３に続いて、セルは、互いに通信して、どのセルが実際にブート中であり、健全であるかを判断する。この対象となる１組のセルは、ＮＶＲＡＭデータベースに記載される。ＮＶＲＡＭデータベースは、電源コントローラサブシステムによるリセットからの各セルの解放に先立って、各セル内に記憶される。ブロック９１４におけるこのセルのランデブーは、機能するメインメモリにまだ依存していない特別なハードウェアを使用して、複雑なセル対セルの相互作用を通じて行われる。このオペレーション（９１４）の目的は、パーティションモナーク（Partition Monarch）になる準備ができた１組のセルマスタを発見することである。
【００８７】
ブロック９１５において、ランデブーセル（９１４）オペレーションに参加したセルマスタは、当該セルマスタのうちの１つを選んで、パーティションモナークにする。このプロセスの結果に従って、各セルマスタにより判断が実行される（９１６）。パーティションモナークであるＣＰＵは、オペレーションブロック９２９でサーバの初期化を継続し、昇進していないセルマスタプロセッサは、パーティションスレーブになって、アプリケーションプロセッサ待機ループ９１７に入る。パーティションスレーブは、このループ９１７から、後に、オペレーティングシステムによって起動される。また、パーティションモナークは、ＯＳを起動するＩＰＦ「ブートスタートアッププロセッサ」（ＢＳＰ）にもなる。したがって、オペレーションブロック９２９は、「ＢＳＰアクティビティ」というラベルを有する。
【００８８】
パーティションモナークが実行する最初の重要なステップは、各セル内のハードウェアを初期化し、それらセルを「接続」して単一の大規模な対称型マルチプロセッシング（ＳＭＰ（Symmetric Multi-Processing））サーバにすることである。これをオペレーションブロック９１８によって表す。これを行うと、次に、各セル内のメモリコントローラを再初期化して、複数のセル間でメモリをインターリーブすることが可能である。また、次に、各セルのローカルデバイスツリーのルートを接木して、パーティションツリーと呼ばれる単一ルートのツリーにすることも可能である。また、ＥＦＩ変数用のＮＶＲＡＭマネージャ等のパーティションレベルのファームウェアデータベース構造体も、パーティションツリー成長（９１９）オペレーション中に初期化されて準備される。
【００８９】
最後に、メインメモリが、ＰＡＬ（４０４）およびＳＡＬ＿ＰＭＩ（５１２）、ならびに、図５のＯＳインターフェースアダプタであるＥＦＩ＿ＡＢＩ（５１０）、ＳＡＬ＿ＡＢＩ（５１１）、およびＡＣＰＩエージェント（５０９）をロードするために使用準備される。このステップを図９のオペレーションブロック９２０によって表す。
【００９０】
ＰＭＩ（プラットフォーム管理割り込み）アダプタは、オペレーションブロック９２１において最初に初期化され、４つのＳＡＬ  ＰＭＩレベル（０、１、２、および３）のハンドラがこのアダプタに登録される。
【００９１】
ＡＣＰＩテーブル用にメモリが選択され、ＡＣＰＩテーブルは、オペレーションブロック９２２でＡＣＰＩエージェントへ呼び出しを行うことによって構築される。ＡＣＰＩエージェント（５０９）は、共にオペレーティングシステムに手続きインターフェースを公開するＳＡＬおよびＥＦＩのようなＯＳインターフェースアダプタではない。その代わり、ＡＣＰＩエージェントは、ブート中に使用されるＡＣＰＩテーブル構築機構およびＡＭＬ生成機構、ならびに、システムのブート後にセルが追加される時のセルホットプラグ用のＡＣＰＩテーブル構築機構およびＡＭＬ生成機構を提供する。その時点で、追加されたセルハードウェアを記述する新たなＡＭＬが生成される。一定の実施の形態では、２００３年５月２８日に出願され、同時係属中で、かつ、本発明の譲受人に譲渡された「SYSTEM AND METHOD FOR GENERATING ACPI MACHINE LANGUAGE TABLES」という発明の名称の米国特許出願第１０／４４６，９５０号であって、米国特許出願公開第２００４／０２４３５３４号に記載されたように、このようなＡＭＬを動的に生成することができる。
【００９２】
ＳＡＬ＿ＡＢＩアダプタは、オペレーションブロック９２３において次に初期化される。このプログラムレイヤは、コアファームウェアへ呼び出しを行い、オペレーティングシステムに提供されることになるメモリ資源およびＩ／Ｏ資源の記述を取得する。さまざまなテーブルが構築される。このさまざまなテーブルには、ＥＦＩアダプタに与えられることになるメモリのマップ、存在するＰＣＩデバイスのマップ、およびＳＡＬ拡張インターフェーステーブル（ＥＳＩＴ）が含まれる。ＰＣＩデバイスのマップは、ＳＡＬのＰＣＩ＿ＣＯＮＦＩＧ＿ＲＥＡＤおよびＰＣＩ＿ＣＯＮＦＩＧ＿ＷＲＩＴＥへのその後の呼び出しのために、同期ロックをホールドするのに使用されるものである。ＳＡＬ拡張インターフェーステーブルは、ＳＡＬに対するＯＥＭ拡張のエントリポイントを保持するものである。
【００９３】
次に、ＥＦＩアダプタが、オペレーションブロック９２４でＳＡＬ＿ＡＢＩアダプタから呼び出され、（ＢＳＰは復帰せず）、ＥＦＩが初期化される。ＥＦＩアダプタは、ＳＡＬ＿ＡＢＩアダプタからハンドオフ記述子構造体を受け取り、このハンドオフ記述子構造体から、ＥＦＩアダプタは、設計されたシステムテーブルを構築する。このシステムテーブルはＯＳに提供される。ＥＦＩブートマネージャが呼び出され、これと相互作用する機会がシステムファームウェアコンソールのユーザに提供される。
【００９４】
最後に、オペレーションブロック９２５において、システムが自動ブートに設定されていない場合には、ＥＦＩシェルに入り、システムが自動ブートに設定されている場合には、ブートマネージャがブート変数を使用して、ブートデバイスを選択し、ブートデバイスが、通例、ＯＳローダであるＥＦＩプログラムをロードする。
【００９５】
オペレーションブロック９３１はＥＦＩプログラムの起動を表す。この起動時に、システムソフトウェアはマシンの制御を開始する。一方、アプリケーションプロセッサは、オペレーションブロック９１７のＯＳ＿ＲＥＮＤＥＺＶＯＵＳ（ＯＳランデブー）待機でアイドリング中である。このハンドオフは、ブートスタートアッププロセッサ（ＢＳＰ）のファームウェア制御の任務の終了を表す。ＢＳＰは、通例、ＥＦＩ、ＳＡＬ、およびＰＡＬへプロシージャコールを行い、ハードウェアに関する情報を収集し、システムの初期化を継続する。
【００９６】
ブロック９２６は、すべてのＣＰＵが実行するオペレーションを示す。ブロック９２７は、セルスレーブＣＰＵのみが実行するオペレーションを示す。オペレーションブロック９２８は、役割がセルマスタ（ハードパーティションのセルごとに１つ）であるＣＰＵのみが実行するステップを示す。ブロック９２９は、ハードパーティション全体におけるセルマスタのうちの１つのみが実行するシーケンスを示す。このセルマスタのうちの１つは、役割が「ハードパーティションモナーク」であるＣＰＵであり、また、ＯＳローダをロードして起動する設計されたＢＳＰ  ＣＰＵになるＣＰＵでもある。ブロック９３０は、アプリケーションプロセッサのみが実行するアクティビティを示す。これらのプロセッサは、セルスレーブ、および、パーティションモナークにならなかったセルマスタである。その主要なアクティビティは、ウェイクアップ割り込みを受け取った時にＯＳによって起動されるように待機することである。
【００９７】
図１０Ａおよび図１０Ｂは、一実施の形態に従ってソフトパーティショニングのｆＰａｒｓ拡張をサポートするセルラーＩＰＦコンピュータシステムの初期ブートストラップの一例のオペレーションフロー図を示している。この図は、３つの異なるブートシーケンスを表している。これら３つの異なるブートシーケンスは、ａ）単一のＯＳインスタンス（１つのｎＰａｒ）をブートするように構成されたシステムのパワーオンリセット（power on）からのコールドブート、ｂ）１つのハードパーティション内部で構成されたソフトパーティション内の１つまたは２つ以上のオペレーティングシステムインスタンス（Ｎ個のｆＰａｒｓ）をブートするように構成されたシステムのパワーオンリセットからのコールドブート、およびｃ）１つまたは２つ以上のソフトパーティションをリセットおよび／または再構成することができ、かつ、ハードパーティションをコールドリセットから再ブートすることなくブートすることができる後者のシステムのパワーオンリセットからのコールドブートである。したがって、このフロー図は、図９で説明した上記システムの完全な上位セットであるシステムを表している。図９の上記オペレーション図と同様に、図１０Ａおよび図１０Ｂも、非セルラーＩＰＦコンピュータシステムに適用される実施の形態を正確にモデル化するために（セルごとのサブシーケンスを除去することにより）簡単化することができる。以下では、当業者がこの発明の一実施の形態を再現できるように、図１０Ａおよび図１０Ｂのオペレーションブロックのそれぞれを詳述することにする。オペレーションブロックの多くは、図９のオペレーションと必然的に同一であり、それ以外は、図９におけるそれらの対応するものをわずかに変更した変形であり、いくつかのオペレーションは、図１０Ａおよび図１０Ｂに新たに導入されたものである。
【００９８】
オペレーションブロック１００１は、最も内部の仕組みがメーカ独自のものであるＩｎｔｅｌのプロセッサ抽象レイヤ（ＰＡＬ）ファームウェア（図４では４０４のラベルを有する）のパワーオンリセットおよび実行を表す。ＰＡＬを終了してオペレーションブロック１００２に入ると、リセットに続いて、最初に、システム抽象レイヤ（ＳＡＬ）ファームウェアが実行される。ＳＡＬは、図１０Ａおよび図１０Ｂのオペレーションブロック１００２〜１０４５において表される非プロセッサファームウェアのすべてのアーキテクチャ名である。
【００９９】
（マルチセル構成の）各セルは、同じファームウェアのコピーを含み、その初期化を開始する。この初期化は、「ハードパーティション」または「ｎＰａｒ」と呼ばれるものを形成する際に初期化に参加する他のセルを（現在のところは）知らないで、または、当該他のセルとの通信機能を有しないで行われる。オペレーションブロック１０２１（全ＣＰＵアクティビティのラベルを有する）は、ＰＡＬを終了してＳＡＬに入ったあらゆるＣＰＵが実行するオペレーションシーケンスを表す。
【０１００】
オペレーションブロック１００２は、設計されたＳＡＬからＰＡＬへのハンドオフを表す。このハンドオフは、上記で引用したＩｎｔｅｌのＩＰＦアーキテクチャ仕様によって定義されたものである。オペレーションブロック１００３は、健全性チェック（ＰＡＬからのステータス）およびマルチＣＰＵランデブーを実行して、単一のプロセッサ（ここでは、セルマスタと呼ぶ）を選択するファームウェアを表す。このセルマスタは、ブロック１０２２（「セルマスタアクティビティ」）に示すセル初期化を続行することになる。不健全なプロセッサ（ＰＡＬセルフテストで不合格であるプロセッサ）は、このブロックより先に実行を継続することが阻止される。不健全なプロセッサがその後のステップを通らない状態に維持しておく必要があるということは、当業者には容易に理解されよう。このような機能を効果的に達成するハードウェアおよび／またはファームウェアの多くの実施の形態が当該技術分野には存在する。したがって、これについては、本明細書ではこれ以上説明しない。
【０１０１】
健全なプロセッサは、オペレーションブロック１００４に入ることによって、セルマスタの選択後の処理を継続する。オペレーションブロック１００４では、各プロセッサが、ＰＡＬサービスを呼び出して、それ自身の内部キャッシュメモリを初期化する。
【０１０２】
ブロック１００４のキャッシュの初期化に続いて、各ＣＰＵは、判断（１００５）を実行し、セルスレーブアクティビティのラベルを有するオペレーションブロック（１０２４）またはセルマスタアクティビティのラベルを有するブロック（１０２２）のいずれかに入る。ＣＰＵは、スレーブである場合に、マスタから命令を得るために監視（１００６）を開始する。この命令はブロック１００７で実行される、命令の例には、調整されたセルフテストオペレーション、および、オペレーションブロック１０１５の役割選択プロセスに参加するために継続するコマンドが含まれる。セルマスタＣＰＵは、後のセルフテストオペレーション中に不合格になる可能性があるので、スレーブも、マスタの前進／進行および健全性を監視する。（処理ステップ１００８〜１０１４を通る前進進行がないことを観察することにより）マスタの故障が検出されると、セルスレーブは、自身をマスタに昇進させ、マスタの構成解除を行い、エラーイベントをログ記録し、次いで、サーバをリセットする。再ブート時に、健全であると推定された異なるマスタが選択され、ブートがさらに進行する。
【０１０３】
パーティション役割選択オペレーション（１０１５）は図９には存在しない。しかしながら、これを省略することは重大ではない。このシーケンスにこのオペレーションが存在することによって、単に、健全なＣＰＵの取り扱いの対称性がわずかに多く導入されるにすぎず、それによって、セルスレーブとして選ばれたものを含めて、任意のプロセッサを、パーティションマスタの役割を実行する単一のプロセッサとして選択することが可能になる。このステップは、図９の適切なポイント（ブロック９１５の後で、かつ、ブロック９１６の前）に含めることができる。より多くの対称性を導入することの利益は、そうすることによって、無数のコードパスおよび構成の組み換えの自動化テストがより簡単になることである。これは、当該分野で既知の技法であり、シーケンスのこのフェーズとは関係がない。
【０１０４】
マルチセルサーバの各セルはセルマスタを含むので、オペレーションブロック１００８〜１０１４は、それ自身の構成されたハードウェアに従って、各セルにより並列に実行することができる。この並列性は、大規模なＩ／Ｏハードウェア構成を有する大規模サーバでは非常に望ましい。その理由は、Ｉ／Ｏハードウェアコンポーネントの発見および初期化が、通例、非常に多くの時間を要するからである。また、大規模な物理メモリアレイの構成および初期化も、ブート中にこのようなセルごとの並列性から利益を得る。
【０１０５】
判断ポイント（１００５）を通過すると、ＣＰＵは、スタックなしで、レジスタおよびＲＯＭのみを使用して実行を続ける。セルラーメモリシステムは、構成するのにかなり複雑であるので、Ｃ等の高級言語でこの作業を実行するファームウェアを作成することが望ましい。Ｃは、大きなスタックおよびヒープを必要とする手続型言語である。これは、ファームウェアがメモリを使用して当該メモリを初期化できないことを意味する。したがって、初期化には問題にならない、少量の、おそらく１メガバイトの特別なメモリを含めることがこのようなシステムにはよく見られる。このようなメモリは、多くの場合、性能が低く、必ずしもコヒーレントとは限らない。この例の実施の形態では、このようなメモリはＳＲＡＭ（スタティックＲＡＭ）と呼ばれる。したがって、セルマスタにとって最初の重要なタスクは、ＳＲＡＭおよびＣランタイム（ＣＲＴ）環境を初期化することである。これにより、処理ステップの残り（スレーブを含む）は、スタックを必要とする高級言語で記述することができ、ヒープテーブルや割り込みテーブル等のソフトウェア資源を使用することができる。この作業をオペレーションブロック１００８によって表す。スタックおよびそれらスタックのバッキングストア（ＩＰＦ要件）が、そのセルの各ＣＰＵのマスタによって作成された後、命令が、監視中（１００６）のスレーブに送信され、スレーブは、自身の内部レジスタを初期化して、新たなスタックおよび割り込みテーブルを使用するように指令を受ける（１００７）。その後、スレーブは、高級言語で記述された命令も実行するように指令を受けることができる。
【０１０６】
次に、セルマスタは、ブロック１００９に示すように、セルブートストラップの残りの綿密な順序付けを調整するのに使用するデータ構造体を初期化する。ブロック１０１０において、判断ポイントによって、不揮発性ＲＡＭ（ＮＶＲＡＭ）構成のオプションが事前に真に設定されていた場合に、内部デバッグモジュールが有効にされる。この変数が真である場合、オペレーションブロック１０１１が実行される。このデバッガは、対話型デバッグまたはリモートデバッグ用の簡単なＵＡＲＴおよび／またはＬＡＮデバイスドライバを含む。この変数が偽である場合、セルマスタはブロック１０１１をスキップし、ブロック１０１２のそのセルごとの初期化を継続する。
【０１０７】
オペレーションブロック１０１２は、Ｂａｎｙａｎファームウェアアーキテクチャによって使用されるツリーベースの（階層的な）データベースのルートを作成し、最小限のコンポーネント／フレームワークのデータ構造体を初期化して、データベースのブランチおよびノードの成長を可能にする。オペレーションブロック１０１３は、セル内のさまざまなハードウェア要素（例えば、メモリ、Ｉ／Ｏ）およびセルに接続されたさまざまなハードウェア要素（例えばＩ／Ｏ）の発見および初期化を表す。要素が発見され、初期化されると、ツリーデータベースは、新たなブランチおよびノードを「成長」させる。
【０１０８】
対象のパーティションの各セルで並列に行われるブロック１０１３に続いて、セルは、互いに通信して、どのセルが実際にブート中であり、健全であるかを判断する。この対象となる１組のセルは、ＮＶＲＡＭデータベースに記載される。ＮＶＲＡＭデータベースは、電源コントローラサブシステムによるリセットからの各セルの解放に先立って、各セル内に記憶される。パーティション役割選択（１０１５）のオペレーションブロックが（図９に対して）導入されたことにより、ランデブーセル（１０１４）のステップが図９のオペレーション９１４とわずかに異なる。ブロック１０１４において、セルマスタは、（同じセル内の）自身のスレーブに命令を発行して、パーティション全体（パーティションのすべての健全なＣＰＵ）にわたるパーティションモナーク選択プロセスへの参加を開始させる。それによって、セルスレーブのすべてからの１つのみのＣＰＵ、および、（マルチセルパーティションの）それ以外のセルマスタが、モナーク選択に対称的に参加を行う。マスタのスレーブのすべてがこのような指令を受けるとすぐに、セルマスタは、ブロック１０１４を終了して、１０１５の選択プロセスに入る。選択は、不揮発性ポリシー変数またはハードウェア回路による事前選択を含む任意の個数のアルゴリズムを通じて行うことができる。
【０１０９】
判断ポイント１０１６は、１０１５で選ばれたもののオペレーションを表す。パーティションモナークとして選択されたＣＰＵは、パーティションモナークアクティビティ（１０２３）のラベルを有するオペレーションのブロックでハードパーティションの初期化を継続する。他のすべてのセルマスタプロセッサおよびセルスレーブプロセッサは、パーティションスレーブアクティビティ１０２５に入って、コールドブートバリア同期（１０１７）のラベルを有するバリア同期に入り、その後のシーケンスに参加するように解放されるまでアイドル状態にある。図示していないが、スレーブは、ブロック１０２４のメカニズムと類似したメカニズムを使用してパーティション全体にわたる初期化を援助する命令を実行するように（モナークにより）指令を受けることもできる。一方、パーティションモナークは、コールドブートアクティビティ（１０２３）のモナークの部分を継続する。これらのアクティビティは、コールドブート（パワーオンリセット）から１度だけ実行され、そのオペレーティングシステム（ｎＰａｒ）または複数のオペレーティングシステム（ｆＰａｒｓ）の動作環境をインスタンス化することを可能にするサーバハードウェアおよびファームウェア基盤を準備するのに使用される。
【０１１０】
パーティションモナークが実行する最初のステップは、各セル内のハードウェアを初期化し、それらセルを「接続」して単一の大規模な対称型マルチプロセッシング（ＳＭＰ（Symmetric Multi-Processing））サーバにすることである。これをオペレーションブロック１０１８によって表す。これを行うと、次に、各セル内のメモリコントローラを再初期化して、複数のセル間でメモリをインターリーブすることが可能である。また、次に、各セルのローカルデバイスツリーのルートを接木して、パーティションツリーと呼ばれる単一ルートのツリーにすることも可能である。また、ＥＦＩ不揮発性変数用のＮＶＲＡＭマネージャ等のパーティションレベルのファームウェアデータベース構造体も、パーティションツリー成長（１０１９）オペレーション中に初期化されて準備される。図９のブロック９１９と異なるオペレーションがここでは行われる。このオペレーションは、コアファームウェア内のソフトパーティションのデータベースマネージャコンポーネントの初期化である。図６の要素６１および図７の要素７０３によって表されるこのコンポーネントは、ブート中の各ＯＳインスタンスに対するハードウェア資源割り当て（ＣＰＵデバイス、Ｉ／Ｏデバイス、およびメモリデバイス）を表すデータを保持する任務を有する。
【０１１１】
この時点まで、図１０Ａのオペレーションは、図９のオペレーションと非常に類似している。一方、図１０Ａのオペレーションブロック１０２０では、パーティションモナークが、プラットフォーム管理割り込みエージェント（６０２、５１２）をロードして初期化する。このプラットフォーム管理割り込みエージェントは、システムが、その後、単一のインスタンスＯＳ（ｎＰａｒ  ＯＳ）をブートしようと、ソフトパーティションが有効化した複数のＯＳ（ｆＰａｒ）インスタンスをブートしようと、ハードパーティションの単一のインスタンスとして存在することになる。ＰＭＩの１つのコピーが初期化される主な理由は、ＩＰＦ命令セットの実施態様がＰＭＩハンドラの１つの登録しかサポートしないように要求されることが、ＩＰＦプロセッサのＰＡＬファームウェアのアーキテクチャ上の制限で表明されていることによる。これは、電源操作を繰り返すことによるリセットごとに、各ＩＰＦ  ＣＰＵに１つのアドレスのみを与えることができることを意味する。ソフトパーティションインスタンスで実行されるプロセッサは、ＯＳインスタンスを再ブートするのにおそらく多くのソフトパーティション（エミュレーションされた）リセットを受けることになるが、ＰＡＬＥ＿ＲＥＳＥＴ（ペールリセット）ベクトルに再び入るコールドリセットは受けない。したがって、ハードパーティションのあらゆるＣＰＵがそのＰＭＩハンドラを１度だけ登録するように保証することが必要である。上記の図９では、ｎＰａｒは、ソフトリセットを決して実行せず、この要件は、この登録を後に行うことができるように、ｎＰａｒについて１つのＢＳＰが存在することによって自動的に満たされる。一方、ソフトパーティション環境では、多くのＢＳＰが存在し、これらＢＳＰのそれぞれが、残りの初期化ステップを実行し、ハードパーティションが再び「コールドブート」される前で、かつ、プロセスが１００１で再び開始する前に、数回にわたって残りの初期化ステップを実行することができる。
【０１１２】
パーティションスレーブおよびパーティションモナークのオペレーションフローは、ラベル「Ａ」で図１０Ａを終了する。これによって、再ブートごとに１度だけ行われるＣＰＵのアクティビティが完了する。図１０Ｂは、ＣＰＵが、ハードパーティション（ｎＰａｒ）では１回実行するが、ソフトパーティション動作モードでは、もちろんコールドリセットからの一番最初を含めて、ソフトパーティションが作成され起動されるごとに何回も実行する、アクティビティを示している。図１０Ａの処理の終了時に、ハードパーティションのメインメモリおよびＩ／Ｏハードウェアは、ＣＰＵのすべてと共に、その時点で、ＩＰＦオペレーティングシステムソフトウェアの標準ＩＰＦ動作環境をインスタンス化するのに使用される準備ができている。一方、このステップは、同じ単一のＩＰＦサーバ内の複数の個別の動作環境をサポートする実施の形態のいくつかのステップが行われる場所である。一例の実施の形態のこれらのオペレーションの集合は、図１０Ｂに見られ、ＦＰＡＲＳシーケンサアクティビティ（１０４２）のラベルを有する。
【０１１３】
プロセッサがラベル「Ａ」で図１０Ａのステップを終了するオペレーションフローの説明を開始する。これらのフローは、開始ポイント１００１（サーバのコールドリセットまたはパワーオンリセット）でこのシーケンスに入るごとに１度だけ実行されるＣＰＵのコールドブートアクティビティのオペレーションを表す。ソフトパーティション動作モードのプロセッサのフローは、以下で説明するステップ１０３８で開始する。
【０１１４】
（図９に対して）新たなオペレーションブロック１０２７がブート役割選択プロセスを実行する。このブート役割選択プロセスによって、アプリケーションプロセッサ（０または複数）およびブートスタートアッププロセッサ（１つ）のアーキテクチャ上定義された役割が決定される。あらゆるＩＰＦサーバインスタンス（ｎＰａｒモードでは１つ、ｆＰａｒモードでは１つまたは２つ以上）は、ＥＦＩファームウェアコードの単一のプライベートコピーを有する。このＥＦＩファームウェアコードは、ブートスタートアッププロセッサ（ＢＳＰ）と呼ばれる単一のプロセッサ上で動作環境をロードして起動する、設計された初期化シーケンスを実行する。割り当て（ＣＰＵのｆＰａｒインスタンスへのマッピング）を指定するＮＶＲＡＭ  ＥＦＩ変数が、ｆＰａｒｓモードで動作している時はこのブロックで使用され、ｎＰａｒｓモードで動作している時は無視される。ｎＰａｒｓモードでは、１つのプロセッサがＢＳＰとして選択され、他のすべてのプロセッサ（もし存在すれば）が、アプリケーションプロセッサ（ＡＰ）となるように選択される。ｆＰａｒｓモードでは、割り当てられていないプロセッサの役割という第３の役割が可能である。このようなプロセッサは、ブートには割り当てられず、ドラフトプール（Draft Pool）状態（１０４１）に保持される。これらのプロセッサは、ソフトリセットプロセス（１０３８）に参加することによって、このドラフトプール状態から抜け出して、その後に作成されるか、または、アクティブにされるｆＰａｒ内でブートへの召集を受けることができる。
【０１１５】
各プロセッサは、ブロック１０２７を終了すると、それ自身の役割を知り、１０２８の判断を行って、コードブロックに入るかどうかを決定する。ＡＰは、ブートバリア同期ブロック（１０４０）に入り、そこで、自身のＢＳＰが、設計されたＯＳランデブー待機状態（１０４３）に入るように指令するのを待機する。ＢＳＰは、オペレーションブロック１０２９で、Ｉ／Ｏから開始して、ブートしているインスタンスにメモリおよびＩ／Ｏハードウェアを割り当てるステップの実行を継続する。そして、上述したように、具体的な割り当てが行われていないことから役割が割り当てられていないプロセッサは、状態が無効であるｆＰａｒに割り当てられる。これは、状態が無効であるｆＰａｒが、ソフトリセットプロセスを通じてブートするように指示されるまで、ブートしないことを意味する。これらのプロセッサは、機能的には割り当てを受けていない。
【０１１６】
オペレーションブロック１０２９は、機能的には２モードである。ｎＰａｒｓモードでは、Ｉ／Ｏハードウェアのすべてが、ブートしているインスタンスに割り当てられるが、このハードウェアは、セルマスタが自身のローカルデバイスツリーを成長させると（１０１２）、セルマスタによる処理中、先に初期化されたことが知られている。したがって、Ｉ／Ｏは割り当てられるものの、初期化されない。一方、ｆＰａｒｓモードでは、Ｉ／Ｏは、ソフトリセットポイント（１０３８）でシーケンスに入った場合に再初期化される。その理由は、Ｉ／ＯハードウェアがＯＳ内部のソフトウェア環境内で動作することに起因したステール状態（stale state）を有するからである。このハードウェアは、ＥＦＩブートドライバが正しく機能できるように、既知の良好な状態に置かれることになる。
【０１１７】
次に、ＢＳＰ（単数または複数）が、オペレーションブロック１０３０に入る。オペレーションブロック１０３０では、ｎＰａｒｓ動作モードで、先に見た図９で使用されるのと同一の方法で、すべてのメモリが単一のＯＳインスタンスに割り当てられる。ソフトパーティション（ｆＰａｒｓ）モードでは、ハードパーティション内の物理メモリの交わらない領域が、１つまたは２つ以上のｆＰａｒｓに割り当てられていることになるか、または、割り当てられない状態に保持されていることになる。このオペレーションでは、これらの記述は、（呼び出し側ＣＰＵのＩＤに応じて）前後の関係からＧｅｔＭｙＨｅａｐ（）、ＧｅｔＭｙＳｔａｃｋ（）、ＧｅｔＭｙＩｎｓｔａｎｃｅＲＡＭ（）等の内部インターフェースを通じてＢＳＰに利用可能にされる。ＢＳＰは、自身に属する資源のみが記述されることを完全に保証して、これらのインターフェースを使用して自身の動作環境を作成することができる。それによって、同種のソフトパーティションインスタンス内でブートまたは動作していることがある他のＢＳＰプロセッサとあらゆる通信を行う必要がなくなる。
【０１１８】
ＣＰＵ、Ｉ／Ｏ、およびメモリハードウェアが、ＢＳＰによるブート中のインスタンスに割り当てられた以上、ＢＳＰは、アーキテクチャ上、必要なＯＳファームウェアインターフェースのインスタンス化を自由に開始することができる。しかし、ＢＳＰは、この作業を開始する直前に、ｆＰａｒｓデータベース（７０１）によって提供されたＭｙＣｐｕｓ（）関数を使用して、自身の（場合によっては存在しない）アプリケーションプロセッサのそれぞれを、当該アプリケーションプロセッサのブートバリア同期オペレーション（１０４０）から解放する。その結果、これらのアプリケーションプロセッサは、ＯＳが自身をウェイクアップさせるのを待機すること（１０４３）を開始できる。好ましい実施の形態は、ｆＰａｒ自体に属するメモリ内に記憶されたランデブースピンループを提供する。このメモリは、ステップ１０３０における割り当てによりＢＳＰに利用可能である。代替的な実施の形態は、すべてのソフトパーティションのすべてのＡＰに対して同じメモリ（スピンループの１つのコピー）を使用する。ステップ１０４０を終了するようにＡＰに指令する一般的なメカニズムには、割り込み、共有メモリメッセージパッシング、センチネル値用のメモリロケーションのポーリング、および特別なハードウェアレジスタまたはメールボックスメカニズムが含まれる。解放用のメカニズムは、知的には重要ではなく、実施の形態は、当業者によく知られた任意の適切なメカニズムを使用することができる。
【０１１９】
シーケンス中のこの時点で、図１０Ｂは、図９のＢＳＰアクティビティ（９２９）と類似し始める。ＰＭＩエージェントは、ハードパーティション全体についてすでに初期化されているので（１０２０）、ＰＭＩエージェントに関係したステップのみが省略される。したがって、ｎＰａｒ（およびあらゆる有効にされ、かつ、有効に構成されたｆＰａｒ）のＢＳＰは、ＢＳＰアクティビティ（１０４４）の実行を開始する。
【０１２０】
オペレーションブロック１０３３において、あらゆるＩＰＦインスタンス（６０３、６０４、６０５）およびＰＡＬ（６０６）が必要とするＯＳインターフェースアダプタ用にメモリが選択される。これらのアダプタは、自身のメモリにロードされる。ＡＣＰＩテーブル用のメモリは、オペレーションブロック１０３４の期間中、ＡＣＰＩエージェント（５０９、６０３）へ呼び出しを行うことによって選択される。デバイス移動のｆＰａｒｓの機能をサポートするために、ｆＰａｒｓモードにおけるＡＣＰＩエージェントの挙動によって、ハードウェアのセグメント化ビューの代わりに、本明細書でスパニング名前空間と呼ばれるものが生成される。これは、ハードウェアのすべてが、ＡＣＰＩテーブルに記述されるが、どのハードウェアが使用可能であり、どのハードウェアが使用可能でないかが、ソフトパーティションが有効化したＯＳに分かるように記述されることを意味する。使用可能でないハードウェアは、他の或る同種のｆＰａｒに属するか、または、割り当てが行われていないものである。割り当てられていないが、物理的には存在するハードウェアの記述を、各ＯＳインスタンスに見えるＡＣＰＩ名前空間に配置することによって、標準ＡＣＰＩホットプラグインターフェース（具体的には、Ｎｏｔｉｆｙ（）演算子、＿ＥＪ０メソッドおよび＿ＳＴＡメソッド、ならびに拡張メソッドＦＰＮおよびＳＦＰＮ）の使用を、資源のオンライン（動的）再構成を実行する新規な方法に採用することができる。資源のオンライン再構成によって、動作環境のシャットダウンおよび再ブートを通過することが回避され、したがって、このオンライン再構成は静的な構成よりも優れている。双方のモデルは、一定の実施の形態では、単一の設計に含まれる。ソフトパーティショニングの特徴を、ＡＣＰＩエージェントが生成したＡＣＰＩテーブルに含めることによって、名前空間を動的に成長または縮小させる機能も維持される。例えば、コールドブート時に存在しないセルが、その後、ハードパーティションに追加されると、名前空間は成長して、追加されたハードウェアを記述しなければならない。あるいは、セルがハードパーティションから除去されると、ＡＣＰＩ名前空間内のその記述を取り除かなければ（除去しなければ）ならない。
【０１２１】
次に、ＳＡＬ＿ＡＢＩアダプタが、オペレーションブロック１０３５で初期化される。このプログラムレイヤは、コアファームウェアへ呼び出しを行って、オペレーティングシステムに提供されることになるメモリ資源およびＩ／Ｏ資源の記述を取得する。この例の実施の形態は、上述したｆＰａｒｓデータベースおよびＭｙＩｎｓｔａｎｃｅＲＡＭ（）のような関数を使用して、（ｎＰａｒｓモードまたはｆＰａｒｓモードの）呼び出し側ＣＰＵが資源のセグメント化（交わらない）ビューを取得するようにこれらの要求を満たす。さまざまなテーブルが構築される。このさまざまなテーブルには、ＥＦＩアダプタに与えられることになるメモリのマップ、存在するＰＣＩデバイスのマップ、およびＳＡＬ拡張インターフェーステーブル（ＥＳＩＴ）が含まれる。ＰＣＩデバイスのマップは、ＳＡＬのＰＣＩ＿ＣＯＮＦＩＧ＿ＲＥＡＤおよびＰＣＩ＿ＣＯＮＦＩＧ＿ＷＲＩＴＥへのその後の呼び出しのために、同期ロックをホールドするのに使用されるものである。ＳＡＬ拡張インターフェーステーブルは、ＳＡＬに対するＯＥＭ拡張のエントリポイントを保持するものである。
【０１２２】
次に、ＥＦＩアダプタが、オペレーションブロック１０３６でＳＡＬ＿ＡＢＩアダプタから呼び出され、（ＢＳＰは復帰せず）、ＥＦＩが初期化される。ＥＦＩアダプタは、ＳＡＬ＿ＡＢＩアダプタからハンドオフ記述子構造体を受け取り、このハンドオフ記述子構造体から、ＥＦＩアダプタは、設計されたシステムテーブルを構築する。このシステムテーブルはＯＳに提供される。ＢＳＰがｎＰａｒを起動する場合、図９と同様に、インスタンスには、すべての利用可能なメモリが与えられる。しかし、この場合も、ｆＰａｒｓモードでは、これら設計されたインターフェースを通じてＯＳに記述されたメモリは、メモリ（ソフトパーティション間の共有メモリをサポートする新たなメモリタイプを除く）のセグメント化ビューを提供する。ＥＦＩブートマネージャが呼び出され、これと相互作用する機会がシステムファームウェアコンソールのユーザに提供される。
【０１２３】
オペレーションブロック１０３７において、システムが自動ブートに設定されていない場合には、ＥＦＩシェルに入り、システムが自動ブートに設定されている場合には、ブートマネージャがブート変数を使用して、ブートデバイスを選択し、ブートデバイスが、通例はＯＳローダであるＥＦＩプログラムをロードする。
【０１２４】
オペレーションブロック１０４５はＥＦＩプログラムの起動を表す。この起動時に、システムソフトウェアはマシンの制御を開始する。一方、アプリケーションプロセッサは、オペレーションブロック１０４３のＯＳ＿ＲＥＮＤＥＺＶＯＵＳ待機でアイドリング中である。このハンドオフは、ブートスタートアッププロセッサ（ＢＳＰ）のファームウェア制御の任務の終了を表す。ＢＳＰは、通例、ＥＦＩ、ＳＡＬ、およびＰＡＬへプロシージャコールを行い、ハードウェアに関する情報を収集し、システムの初期化を継続する。
【０１２５】
最後に、ｆＰａｒｓ動作モードでは、設計されたＥＦＩのＲｅｓｅｔＳｙｓｔｅｍ（）サービスを使用してシャットダウンするどのブートされたＯＳも、実際には、自身のインスタンスのみをシャットダウンしていることになる。ＥＦＩアダプタ（５１０、６０４）は、この実施の形態では変更され、それによって、ＥＦＩアダプタが、ｆＰａｒｓモードで、オペレーションエントリ（１０３８）に入ることによりｆＰａｒｓシーケンサアクティビティでの実行をプロセッサに開始させるようにする。プロセス１０３８のアクティビティは、ＰＡＬのパワーオンコールド（スタートアップ）コードを通過することなく、ＣＰＵに「ブートの開始を準備」させることになる命令により呼び出された命令シーケンスおよびＰＡＬプロシージャである。本発明者らは、これをＣＰＵの「スクラビング（scrubbing）」と考える。スクラビング中のアクティビティの例としては、ＣＰＵの実行を物理モードに設定する（仮想アドレス変換を無効にする）こと、ＴＬＢを無効にすること、割り込みを無効にすること、すべての保留中の割り込みを空にすること、プロセッサキャッシュを無効にすること、およびＣＰＵ命令セットアーキテクチャに依存した他のステップがある。
【図面の簡単な説明】
【０１２６】
【図１】本明細書で説明するソフトパーティショニング技法の一実施の形態によって可能にされるソフトパーティショニングの一例である。
【図２】本明細書で「ｆＰａｒｓ」パーティショニングと呼ぶソフトパーティショニング技法の一実施の形態の一例の高レベルブロック図である。ここで、複数のソフトパーティションのそれぞれにつき、個別のファームウェアインスタンスがインスタンス化され、各ファームウェアインスタンスは、その各ソフトパーティションのオペレーティングシステム用の事前に定義されたファームウェアインスタンスを提供する。
【図３】図２のソフトパーティショニング技法等のソフトパーティショニング技法の一定の実施の形態のオペレーションフロー図である。
【図４】一般的なＩＰＦベースのコンピュータシステムの抽象モデルを示し、このようなＩＰＦベースのコンピュータシステムの標準ファームウェアインターフェースを示す図である。
【図５】本明細書でＢａｎｙａｎアーキテクチャと呼ぶｆＰａｒｓパーティショニング技法の一実施の形態に従って、図４のＩＡ−６４アーキテクチャ用に実施された一例のファームウェアアーキテクチャである。
【図６】好ましい実施の形態に従ってハードパーティション内で実施された一例のＢａｎｙａｎソフトウェアスタックの高レベル図である。
【図７】ソフトパーティションを構成／再構成する一実施の形態のｆＰａｒｓ構成データベースを含む４つの例の使用ケースである。
【図８】ｆＰａｒソフトパーティショニング技法の一実施の形態による一例のｆＰａｒドメインモデルである。
【図９】従来のｎＰａｒｔｉｔｉｏｎブートシーケンスの一例である。
【図１０Ａ】従来のｎＰａｒｔｉｔｉｏｎブートとこの例のｆＰａｒブートシーケンスとの差を示す、ｆＰａｒｓソフトパーティショニング技法の一実施の形態のオペレーションフロー図である。
【図１０Ｂ】従来のｎＰａｒｔｉｔｉｏｎブートとこの例のｆＰａｒブートシーケンスとの差を示す、ｆＰａｒｓソフトパーティショニング技法の一実施の形態のオペレーションフロー図である。
【図１１】一実施の形態によるＩＰＦベースのコンピュータシステムの異なるソフトパーティションの異なるタイプのＯＳのインスタンスを実行する一例のオペレーションフロー図である。
【符号の説明】
【０１２７】
１０１  ハードパーティション
２０１  ｆＰａｒｓロジック
２０２  ＰＣＩカード
２０３  ＩＰＦ  ＣＰＵ
２０４  物理メモリ（ＲＡＭ）
２０５、２０８、２１１、２１４  ファームウェアインスタンス
２０６  ＩＰＦ  ＨＰ−ＵＸ  ＯＳ
２０７  ＨＰ−ＵＸアプリケーション
２０９  ＩＰＦ  ＬＩＮＵＸ  ＯＳ
２１０  ＬＩＮＵＸアプリケーション
２１２  ＷＩＮＤＯＷＳ  ＯＳ
２１３  ＷＩＮＤＯＷＳアプリケーション
２１５  Ｏｐｅｎ  ＶＭＳ  ＯＳ
４０１  ハードウェアプラットフォーム
４０３  ＯＳ
４０４  プロセッサ抽象レイヤ（ＰＡＬ）
５００  Ｂａｎｙａｎファームウェア（Ｂａｎｙａｎアーキテクチャ）
５０１  移植可能コア
５０２  コアフレームワーク
５０３  イベントシーケンサ
５０４  ＳＡＬ基板
５０５  デバイスツリー
５０６  コンポーネント
５０７  デバッガ
５０８  ＡＣＰＩテーブル
５０９  ＡＣＰＩエージェント
５１０  ＥＦＩ  ＡＢＩ
５１１  ＳＡＬ  ＡＢＩ
５１２  ＳＡＬ  ＰＭＩ
６０１  Ｂａｎｙａｎフレームワーク／コンポーネントコア
６０２  ＰＭＩエージェント
６０３  ＡＣＰＩエージェント（１．０または２．０）
６０４  ＥＦＩアダプタ
６０５  ＳＡＬアダプタ
６０６  ＰＡＬイメージ
６０７  ＩＰＦ  ＯＳ
６０８  アプリケーション
８０１  ＩＰＦ  ＯＳインスタンスＸ
８０２  ＩＰＦ  ＯＳインスタンスＹ
８０３、８０４  ファームウェアインターフェースインスタンス
８０６、８０７  ハードウェア資源
８０６Ａ、８０７Ｃ  ＣＰＵ
８０６Ｂ、８０７Ｂ  ＰＣＩカード
８０６Ｃ、８０７Ａ  メモリセグメント
【図１】
2006024214.tif 000003
【図２】
2006024214.tif 000004
【図３】
2006024214.tif 000005
【図４】
2006024214.tif 000006
【図５】
2006024214.tif 000007
【図６】
2006024214.tif 000008
【図７】
2006024214.tif 000009
【図８】
2006024214.tif 000010
【図９】
2006024214.tif 000011
【図１０Ａ】
2006024214.tif 000012
【図１０Ｂ】
2006024214.tif 000013
【図１１】
2006024214.tif 000014