JP2008047112A - エラーハンドリング及びファームウェア更新を調停するための方法及びシステム - Google Patents

Abstract

【課題】エラーハンドリング及びファームウェア更新を調停するための方法及びシステムを提供する。
【解決手段】コンピュータ１０２は、ネットワークインターフェース１０６に連結されたプロセッサ１０４を備える。プロセッサ１０４は、ファームウェア１２０と通信する。ファームウェア１２０は、更新可能ファームウェアコンポーネント１２４、固定ファームウェアコンポーネント１３０、及びアービトレータ１２２を含む。アービトレータ１２２は、すでに進行中の要求を完了し、衝突している要求を延期することによって、ファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。
【選択図】図１

Description

本発明は、エラーハンドリング及びファームウェア更新を調停するための方法及びシステムに関する。

コンピュータプラットフォームのファームウェアは、従来、シングルイメージとしてパッケージされた単一のエンティティとして見られてきた。最近になって、いくつかのコンピュータプラットフォームは、個々のファームウェアコンポーネントを確立した。たとえば、Ｉｔａｎｉｕｍプロセッサファミリー（ＩＰＦ）標準規格は、個々のファームウェアコンポーネントとして、プロセッサ抽象化レイヤ（ＰＡＬ）、システム抽象化レイヤ（ＳＡＬ）、及び拡張可能ファームウェアインターフェース（ＥＦＩ）を確立している。

少なくともいくつかのファームウェアアーキテクチャ（たとえば「Ｂａｎｙａｎ（バンヤン）」）は、ＳＡＬ等のファームウェアコンポーネントを数個の異なるサブコンポーネントに分割することができる。これらの異なるサブコンポーネントの少なくとも一部は、関連付けられているコンピュータプラットフォームのランタイム中に更新することができる。また、新しい異なるサブコンポーネントを追加することもできる。
米国特許第６９６３９７０号 米国特許第７０３９８３６号 米国特許出願公開第２００６／０１０４５０号 INTEL CORPORATION, 「Intel Itanium Processor Family Error Handling Guide」2004年4月

本発明は、エラーハンドリング及びファームウェア更新を調停するための方法及びシステムを提供することを目的とする。

上記目的を達成するために、本発明にかかるコンピュータシステムは、プロセッサ（１０４）と、前記プロセッサ（１０４）と通信するファームウェア（１２０）であって、少なくとも１つの更新可能コンポーネント（１２４）及びアービトレータ（１２２）を有する、ファームウェア（１２０）とを備え、前記アービトレータ（１２２）は、前記ファームウェア（１２０）内で実行されるエラーハンドリングとファームウェア更新との間の衝突を管理する。

次に、本発明の例示の実施形態を詳細に説明するために、添付図面を参照することにする。

［表記及び用語体系］
以下の説明及び特許請求の範囲の全体にわたって、特定のシステムコンポーネントを参照するために、一定の用語が使用される。当業者には十分理解されるように、コンピュータ会社は、１つのコンポーネントを異なる名前で参照する場合がある。この文書は、名前は異なるが、機能は異ならないコンポーネントを区別することを意図していない。以下の解説及び特許請求の範囲において、「含む」及び「備える」という用語は、オープンエンド形式で使用され、したがって、「〜を含むが、これらに限定されるものではない」ことを意味するように解釈されるべきである。また、「連結する」という用語は、間接的な電気接続、直接的な電気接続、光電気接続、又は無線電気接続のいずれかを意味するように意図されている。したがって、第１のデバイスが第２のデバイスに連結する場合、その接続は、直接的な電気接続を通じたもの、他のデバイス及び接続を介した間接的な電気接続を通じたもの、光電気接続を通じたもの、又は無線電気接続を通じたものとすることができる。

［詳細な説明］
以下の解説は、本発明のさまざまな実施形態を対象にしている。これらの実施形態の１つ又は２つ以上は好ましいものとなり得るが、開示した実施形態は、特許請求の範囲を含めた開示の範囲を限定するものとして解釈されるべきでもなければ、それ以外に使用されるべきでもない。加えて、当業者ならば、以下の説明が広い用途を有し、どの実施形態の解説も、その実施形態の例示としてのみ意図されており、特許請求の範囲を含めた開示の範囲がその実施形態に限定されることを暗示するように意図されていないことを理解するであろう。

本発明の実施形態は、コンピュータプラットフォームの異なるファームウェアコンポーネントの更新、交換、又は追加を可能にする。また、本発明の実施形態は、ファームウェアコンポーネントがコンピュータプラットフォームでエラーを処理することも可能にし、いくつかの場合では、ファームウェアコンポーネントがエラーを訂正することも可能にする。少なくともいくつかの実施形態では、ファームウェアコンポーネントの更新、交換、又は追加の要求、及び、エラーをハンドリングする要求は、ファームウェアによって調停される。たとえば、衝突するエラーハンドリング要求（handle error request）が受信される時に、ファームウェア更新が進行中である場合、ファームウェアは、ファームウェア更新の完了後までエラーのハンドリングを延期することができる。或いは、衝突するファームウェア更新要求が受信される時に、ファームウェアがエラーをハンドリングしている場合、ファームウェアは、エラーハンドリングの完了後までファームウェアの更新（又は追加）を延期することができる。他の調停技法も可能である。

図１は、本発明の実施形態によるシステム１００を示している。図１に示すように、システム１００は、ネットワーク１４０を介して更新コンピュータ１５０に連結されたコンピュータ１０２を備える。図示するように、コンピュータ１０２は、ネットワークインターフェース１０６に連結されたプロセッサ１０４を備える。ネットワークインターフェース１０６は、コンピュータ１０２がネットワーク１４０上のデバイスにデータを送信し、そのデバイスからデータを受信することを可能にする。たとえば、コンピュータ１０２は、更新コンピュータ１５０からファームウェア更新イメージを受信して、後に説明するような１つ又は２つ以上の更新可能ファームウェアコンポーネント１２４の更新、交換、又は追加を行うことができる。また、プロセッサ１０４は、メモリ１０８にも連結されている。メモリ１０８は、プロセッサ１０４によって実行されるオペレーティングシステム（ＯＳ）１１０及び他のアプリケーション１１２を記憶する。

図１に示すように、プロセッサ１０４は、ファームウェア１２０と通信する。ファームウェア１２０は、更新可能ファームウェアコンポーネント１２４、固定ファームウェアコンポーネント１３０、及びアービトレータ１２２を含む。本明細書で使用されるように、「更新可能ファームウェアコンポーネント」は、コンピュータ１０２のランタイム中に更新できるファームウェアコンポーネントであり、「固定ファームウェアコンポーネント」は、コンピュータ１０２のランタイム中に更新できないファームウェアコンポーネントである。いくつかの実施形態では、固定ファームウェアコンポーネント１３０の少なくとも１つは、更新可能ファームウェアコンポーネント１２４を更新又は増加させる時に使用される。また、アービトレータ１２２は、いくつかの実施形態では固定コンポーネント１３０のうちの１つとしてもよい。

コンピュータ１０２のユーザ又はアドミニストレータが、更新可能ファームウェアコンポーネント１２４の更新、交換、又は増加を望む場合、ファームウェア更新要求がファームウェア１２０にアサートされる。図１に示すように、ファームウェア更新要求は、プロセッサ１０４がアサートすることができる。たとえば、ファームウェア更新要求は、ローカル又はリモートで実行されるファームウェア更新アプリケーションによって提供される命令、ローカルストレージデバイス（たとえば、ＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク、フラッシュメモリデバイス、又はスマートカード）及び関連入力デバイス（図示せず）によって提供される命令、並びに（又は）、プロセッサ１０４によって実行されているＯＳ１１０もしくは別のアプリケーション１１２により提供される命令に応答してアサートすることができる。図１は、ファームウェア更新要求がプロセッサ１０４によってアサートされることを示しているが、ファームウェア更新要求は、代替的に、プロセッサ１０４以外のプラットフォームエンティティ（たとえば、ＯＳ１１０）がアサートすることもできる。

更新可能ファームウェアコンポーネント１２４の更新、交換、又は増加を行うために、ファームウェア更新イメージが、ファームウェア更新要求と共にファームウェア１２０へ送信されるか、又は、ファームウェア更新要求が受け付けられた後にファームウェア１２０へ送信される。少なくともいくつかの実施形態では、ファームウェア更新イメージをファームウェア１２０へ送信する前に、安全な（暗号鍵で保護された）セッションを確立することができる。ファームウェア更新イメージは、更新コンピュータ１５０によってリモートに実行されているか、又は、コンピュータ１０２によってローカルに実行されているファームウェア更新アプリケーション１５２によって提供することができる。或いは、ファームウェア更新イメージは、ローカルストレージデバイス（たとえば、ＣＤ−ＲＯＭ、フロッピーディスク、フラッシュメモリデバイス、又はスマートカード）によるか、ＯＳ１１０によるか、又は、プロセッサ１０４によって実行されている別のアプリケーション１１２により、提供することもできる。要約すると、ファームウェア更新要求及び対応するファームウェア更新イメージの発信元は、コンピュータ１０２に対してローカルとすることもできるし、リモートとすることもできる。いずれにしても、ファームウェア更新イメージを提供するエンティティとファームウェア１２０との間に安全なセッションを確立することができる。

コンピュータ１０２のランタイム中、エラーが発生する場合がある。たとえば、エラーは、プロセッサ１０４の内部又は外部のハードウェアに関与する場合がある。これに加えて又はこれに代えて、エラーは、実行されているソフトウェアに関与する場合もある（たとえば、ＯＳ１１０又はアプリケーション１１２の１つが発生したエラー）。エラーは、データの１ビット又は２ビット以上に関与する場合がある。エラー源にかかわらず、一定のエラーは、プロセッサ１０４、ファームウェア１２０、ＯＳ１１０、又は他のプラットフォームエンティティによって検出可能である。これらの検出可能なエラーは、必ずしも、ファームウェア１２０に関係していないが、プロセッサ１０４やＯＳ１１０等のプラットフォームエンティティは、ファームウェア１２０がエラーをハンドリングすることを要求することができる。たとえば、図１では、プロセッサ１０４がエラーハンドリング要求をファームウェア１２０にアサートしていることが示されている。いくつかの場合では、ファームウェア１２０は、エラーハンドリング要求を処理して、エラーを訂正することができる。ファームウェア１２０が、エラーハンドリング要求を処理するが、エラーを訂正できない場合、ファームウェア１２０は、プロセッサ１０４、ＯＳ１１０、又は別のプラットフォームエンティティがエラーをハンドリングすることを要求することができる。エラーを訂正できない場合、コンピュータ１０２を強制的にシャットダウン又は再起動させることができる。

ファームウェア１２０は、コンピュータ１０２のランタイム中に、ファームウェア更新要求及びエラーハンドリング要求の双方を受信する場合があるので、アービトレータ１２２は、これら異なる要求間を調停するように実施される。少なくともいくつかの実施形態では、ファームウェア更新要求及びエラーハンドリング要求の双方を処理するのに、固定ファームウェアコンポーネント１３０のうちの少なくとも１つが必要とされる。したがって、いくつかの場合では、エラーハンドリング要求の処理に関与している固定ファームウェアコンポーネント１３０は、エラーハンドリングプロセスを中断することなくファームウェア更新要求の処理に関与することができない。或いは、いくつかの場合では、ファームウェア更新要求の処理に関与している固定ファームウェアコンポーネント１３０は、ファームウェア更新プロセスを中断することなくエラーハンドリング要求の処理に関与することができない。したがって、アービトレータ１２２は、ファームウェア１２０が、ファームウェア更新要求とエラーハンドリング要求との間の衝突をどのように管理するかを決定する。

少なくともいくつかの実施形態では、アービトレータ１２２は、すでに進行中の要求を完了し、衝突している要求を延期することによって、ファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。たとえば、衝突するエラーハンドリング要求が受信される時に、ファームウェア更新が進行中である場合、アービトレータ１２２は、ファームウェア１２０に、エラーのハンドリングをファームウェア更新の完了後まで延期させる。或いは、衝突するファームウェア更新要求が受信される時に、ファームウェア１２０がエラーをハンドリングしている場合、アービトレータ１２２は、ファームウェア１２０に、ファームウェアの更新（追加）をエラーハンドリングの完了後まで延期させる。

代替的な実施形態では、アービトレータ１２２は、ファームウェア更新要求に優先権を選択的に与えることによって、ファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。たとえば、衝突するエラーハンドリング要求が受信される時に、ファームウェア更新が進行中である場合、アービトレータ１２２は、ファームウェア１２０に、エラーのハンドリングをファームウェア更新の完了後まで延期させる。或いは、衝突するファームウェア更新要求が受信される時に、ファームウェア１２０がエラーをハンドリングしている場合、アービトレータ１２２は、ファームウェア１２０に、エラーのハンドリングを停止又は延期させ、その代わり、ファームウェア更新要求を処理させる。ファームウェア更新が完了すると、エラーハンドリングプロセスを継続又は再起動することができる。少なくともいくつかの実施形態では、エラーハンドリング要求が中断され、且つエラーハンドリングを延期することができない場合、アービトレータ１２２は、プロセッサ１０４やＯＳ１１０等のプラットフォームエンティティに、エラーハンドリング要求を完了できなかったこと、又は、エラーを訂正できなかったことを通知する。たとえば、アービトレータ１２２は、エラーハンドリング要求をアサートしたプラットフォームエンティティ、又は、ファームウェア１２０がエラーのハンドリング又は訂正を行えない場合に、エラーをハンドリングするプラットフォームエンティティに通知を提供することができる。

代替的な実施形態では、アービトレータ１２２は、エラーハンドリング要求に優先権を選択的に与えることによって、ファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。たとえば、衝突するファームウェア更新要求が受信された時に、ファームウェア１２０がエラーをハンドリングしている場合、アービトレータ１２２は、ファームウェア１２０に、ファームウェアの更新（又は追加）をエラーハンドリングの完了後まで延期させる。或いは、衝突するエラーハンドリング要求が受信された時に、ファームウェア更新が進行中である場合、アービトレータ１２２は、ファームウェア１２０に、ファームウェアの更新を停止又は延期させ、その代わり、エラーハンドリング要求を処理させる。エラーハンドリングが完了すると、ファームウェア更新プロセスを継続又は再起動することができる。少なくともいくつかの実施形態では、ファームウェア更新要求が中断され、且つファームウェア更新要求を延期させることができない場合、アービトレータ１２２は、ファームウェア更新を要求したローカルエンティティ又はリモートエンティティに、ファームウェア更新を完了できなかったことを通知する。

いくつかの実施形態では、アービトレータ１２２は、タイミングの考慮に基づいてファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。たとえば、衝突するエラーハンドリング要求が受信される時に、ファームウェア更新が進行していた時間がしきい値時間量よりも少ない場合、アービトレータ１２２は、エラーを処理して、ファームウェア更新を延期することができる。或いは、衝突するファームウェア更新要求が受信される時に、エラーハンドリングが進行していた時間がしきい値時間量よりも少ない場合、アービトレータ１２２は、ファームウェアを更新して、エラー処理を延期することができる。

また、衝突するエラーハンドリング要求が受信される時（又は受信された後）に、ファームウェア更新が進行していた時間がしきい値時間量よりも多い場合に、アービトレータ１２２は、エラーハンドリング要求が通常はファームウェア更新よりも高い優先権を有していても、エラーの処理を中断又は延期することができる。或いは、衝突するエラーハンドリング要求が受信される時（又は受信された後）に、ファームウェア更新が進行していた時間がしきい値時間量よりも多い場合に、アービトレータ１２２は、ファームウェア更新が通常はエラー処理よりも高い優先権を有していても、ファームウェア更新を中断又は延期して、エラーを処理することができる。アービトレータ１２２によるタイミングの考慮を使用することは、たとえば、ファームウェア更新要求、ファームウェア更新オペレーション、エラーハンドリング要求及びエラーハンドリングオペレーションのステータスをチェックして更新するカウンタ及びオペレーションを伴うことができる。

いくつかの実施形態では、アービトレータ１２２は、特定の要求を識別することに基づいて、ファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する（すなわち、異なるタイプのファームウェア更新要求及びエラーハンドリング要求を識別でき、それに応じてハンドリングすることができる）。たとえば、特定のタイプのファームウェア更新要求は、特定のタイプのエラーハンドリング要求よりも高い優先権を有することもできるし、その逆とすることもできる。このような実施形態では、アービトレータ１２２は、各要求を備えた識別情報を検索し、その識別情報を使用して、衝突する要求に優先権を付ける。いくつかの実施形態では、アービトレータ１２２は、タイミングの考慮、優先権、及び他のポリシーを組み合わせて、ファームウェア更新要求とエラーハンドリング要求との間の衝突をハンドリングする。

いくつかの実施形態では、少なくとも１つの固定コンポーネント１３０が、エラーハンドリングの基本レベルを担当する一方、少なくとも１つの更新可能コンポーネント１２４が、エラーハンドリングの拡張レベルを担当する。いくつかの場合では、ファームウェア更新が進行中である場合、拡張エラーハンドリングを提供する更新可能コンポーネント１２４が利用可能でない場合であっても、基本エラーハンドリングを提供する固定コンポーネント１３０は利用可能である。したがって、アービトレータ１２２は、ファームウェア更新が進行中である間、エラー処理を延期するのか、それとも、基本エラーハンドリングを行うのかを決定することができる。いくつかの実施形態では、アービトレータ１２２は、いくつかのエラーハンドリング要求を延期することによって、ファームウェア１２０によるエラーハンドリング能力が劣化する可能性があることを考慮する。

図２は、本発明の実施形態による方法２００を示している。図２に示すように、方法２００は、開始ブロック２０２で始まる。ファームウェア更新要求が受信されていない場合（判断ブロック２０４）、方法２００は判断ブロック２０４に戻る。ファームウェア更新要求が受信されている場合（判断ブロック２０４）、方法２００は、エラーハンドリングが進行中であるか否かを判断する（判断ブロック２０６）。エラーハンドリングが進行中である場合（判断ブロック２０６）、方法は、エラーハンドリングを完了する（ブロック２０８）。エラーハンドリングが進行中でない場合（判断ブロック２０６）、又は、エラーハンドリングが完了している場合（ブロック２０８）、ファームウェアは更新される（ブロック２１０）。

方法２００は、エラーハンドリング要求が受信されているか否かを判断することをさらに含む（ブロック２１２）。エラーハンドリング要求が受信されなかった場合（判断ブロック２１２）、方法２００は判断ブロック２１２に戻る。エラーハンドリング要求が受信されている場合（判断ブロック２１２）、方法２００は、ファームウェア更新が進行中であるか否かを判断する（判断ブロック２１４）。ファームウェア更新が進行中である場合（判断ブロック２１４）、方法はファームウェア更新を完了する（ブロック２１６）。ファームウェア更新が進行中でない場合（判断ブロック２１４）、又は、ファームウェア更新が完了している場合（ブロック２１６）、エラーはハンドリングされる（ブロック２１８）。ブロック２１０及び２１８の後、方法２００は終了ブロック２２０で終了する。

図３は、本発明の実施形態による別のシステム３００を示している。図３に示すように、システム３００は、プロセッサ３０４に連結されたプラットフォーム（ハードウェアエンティティ）３０２を備える。プロセッサ３０４は、プロセッサ抽象化レイヤ（ＰＡＬ）３０６及びオペレーティングシステム（ＯＳ）３３２とも通信する。図示するように、システム３００は、プラットフォーム３０２と通信するシステム抽象化レイヤ（ＳＡＬ）３０８、ＰＡＬ３０６、及びＯＳ３３２も備える。たとえば、ＳＡＬ３０８は、一定のタスクを完了する際に、プラットフォーム３０２のチップセットレジスタにアクセスすることができる。ＰＡＬ３０６及びＳＡＬ３０８は、後述するように、システム３００によって検出される一定のエラーをハンドリングできるファームウェアコンポーネントである。また、システム３００は、システム３００によって検出されるエラーのハンドリングに必ずしも関与しない拡張可能ファームウェアインターフェース（ＥＦＩ）３３０も備える。

図３に示すように、ＳＡＬ３０８は、更新可能コンポーネント３１２及び固定コンポーネント３１４を備える。更新可能コンポーネント３１２は、コンピュータシステム３００のランタイム中に更新することができる一方、固定コンポーネント３１４は、システム３００のランタイム中に更新することができない。少なくともいくつかの実施形態では、更新可能コンポーネント３１２は、「Ｂａｎｙａｎ」アーキテクチャと呼ばれるファームウェアアーキテクチャの一部である。

図示するように、固定コンポーネント３１４は、フレームワーク３１６、レジストリ３１８、及びシーケンサ３２０を備える。少なくともいくつかの実施形態では、フレームワーク３１６及びレジストリ３１８は、ランタイム時に追加、交換、又は更新が可能なファームウェアコンポーネント間の通信を可能にする。具体的には、レジストリ３１８は、現在インストールされているファームウェアコンポーネントのリストを保持し、フレームワーク３１６は、レジストリ３１８に列挙されたコンポーネント間の通信を調整する。シーケンサ３２０は、システム３００のブート及びエラーハンドリング要求の処理のための制御エンティティである。いくつかの実施形態では、アービトレータ３１０は、固定コンポーネント３１４のうちの１つである。

更新可能コンポーネントの更新、交換、又は増加の時に、固定コンポーネント３１４のうちの少なくとも１つが関与することができる。たとえば、フレームワーク３１６によって提供される通信メカニズム及びレジストリ３１８によって提供されるリストにより、ファームウェア更新が進行中の間、更新可能コンポーネント３１２間の通信を可能にすることができる。固定コンポーネント３１４は、ハードウェア初期化、管理、及びエラーハンドリング機能を可能にする他のＳＡＬコンポーネント及びＥＦＩコンポーネントも備えることができる。

システム３００のユーザ又はアドミニストレータが、更新可能コンポーネント３１２の更新、交換、又は増加を望む場合、ファームウェア更新要求がＳＡＬ３０８にアサートされる。図３では、ファームウェア更新要求は、たとえば、プラットフォーム３０２、プロセッサ３０４、又はＯＳ３３２がアサートすることができる。少なくともいくつかの実施形態では、ファームウェア更新要求は、ローカル若しくはリモートで実行されるファームウェア更新アプリケーションによって提供される命令、ローカルストレージデバイス（たとえば、ＣＤ−ＲＯＭ、フロッピーディスク、フラッシュメモリデバイス、又はスマートカード）及び関連入力デバイス（図示せず）によって提供される命令、又はプロセッサ３０４によって実行されている別のアプリケーションにより提供される命令に応答して、プラットフォーム３０２、プロセッサ３０４、又はＯＳ３３２によりアサートされる。

更新可能コンポーネント３１２の更新、交換、又は増加を行うために、ファームウェア更新イメージが、ファームウェア更新要求と共にＳＡＬ３０８へ送信されるか、又は、ファームウェア更新要求が受け付けられた後にファームウェア３０８へ送信される。少なくともいくつかの実施形態では、ファームウェア更新イメージをＳＡＬ３０８へ送信する前に、安全な（暗号鍵で保護された）セッションを確立することができる。ファームウェア更新イメージは、ローカル又はリモートで実行されるファームウェア更新アプリケーションによるか、ローカルストレージデバイス（たとえば、ＣＤ−ＲＯＭ、フロッピーディスク、フラッシュメモリデバイス、又はスマートカード）によるか、ＯＳ３３２によるか、又は、プロセッサ３０４によって実行されている別のアプリケーションにより、提供することができる。換言すれば、ファームウェア更新要求及び対応するファームウェア更新イメージの発信元は、システム３００に対してローカルとすることもできるし、リモートとすることもできる。いずれにしても、ファームウェア更新イメージを提供するエンティティとＳＡＬ３０８との間に安全なセッションを確立することができる。

システム３００のランタイム中、エラーが発生する場合がある。たとえば、エラーは、プロセッサ３０４の内部又は外部のハードウェアに関与する場合がある。これに加えて又はこれに代えて、エラーは、ＯＳ３３２や別のアプリケーション等のソフトウェアに関与する場合もある。エラーは、データの１ビット又は２ビット以上に関与する場合がある。エラー源にかかわらず、一定のエラーは、プラットフォーム３０２、プロセッサ３０４、ＰＡＬ３０６、ＳＡＬ３０８、又はＯＳ３３２によって検出可能である。これらの検出可能なエラーは、必ずしも、ＳＡＬ３０８に関係していないが、他のシステムエンティティ（たとえば、プラットフォーム３０２、プロセッサ３０４、ＰＡＬ３０６、又はＯＳ３３２）は、ＳＡＬ３０８がエラーをハンドリングすることを要求することができる。

一例として、図３は、プラットフォーム３０２が通常フローのデータを送受信することを示している。時々、エラーを表す割り込みが、プラットフォーム３０２によって受信される。プラットフォーム３０２がエラーを訂正できる場合、プラットフォーム３０２は、エラーが訂正されたことを示す訂正プラットフォームエラー割り込み（Corrected Platform Error Interrupt）（ＣＰＥＩ）信号をＯＳ３３２にアサートし、システム３００は通常オペレーションを継続する。プラットフォーム３０２がエラーを訂正できない場合、プラットフォーム３０２は、バスエラー信号（「ＢＥＲＲ＃」）、バス初期化信号（「ＢＩＮＩＴ」）、ハード故障信号（「ＨＦ（Hard Failure）」）等のエラー信号をプロセッサ３０４にアサートし、プロセッサ３０４がエラーをハンドリングする。プロセッサ３０４がエラーを訂正できる場合、プロセッサ３０４は、エラーが訂正されたことを示す訂正マシンチェック割り込み（Corrected Machine Check Interrupt）（ＣＭＣＩ）信号をＯＳ３３２にアサートし、システム３００は通常オペレーションを継続する。プロセッサ３０４がエラーを訂正できない場合、プロセッサ３０４は、マシンチェックアボート（Machine Check Abort）（ＭＣＡ）信号をＰＡＬ３０６にアサートし、ＰＡＬ３０６がエラーをハンドリングする。ＰＡＬ３０６がエラーを訂正できる場合、ＰＡＬ３０６は、エラーが訂正されたことを示すＣＭＣＩ信号をＯＳ３３２にアサートし、システム３００は通常オペレーションを継続する。ＰＡＬ３０６がエラーを訂正できない場合、ＰＡＬ３０６は、ＭＣＡ信号をＳＡＬ３０８にアサートし、ＳＡＬ３０８がエラーをハンドリングする。ＳＡＬ３０８がエラーを訂正できる場合、ＳＡＬ３０８は、エラーが訂正されたことを示すＣＰＥＩ信号をＯＳ３３２にアサートし、システム３００は通常オペレーションを継続する。ＳＡＬ３０８がエラーを訂正できない場合、ＳＡＬ３０８は、ＭＣＡ信号をＯＳ３３２にアサートし、ＯＳ３３２がエラーをハンドリングする。ＯＳ３３２がエラーを訂正できる場合、システム３００は通常オペレーションを継続する。ＯＳ３３２がエラーを訂正できない場合、システム３００は、訂正されないエラーに応じて、シャットダウン、再起動、又は他の或る動作により応答する。

上記例では、エラーは、プラットフォーム３０２によって検出され、プロセッサ３０４、次にＰＡＬ３０６、次にＳＡＬ３０８，次にＯＳ３３２によって選択的にハンドリングされた。或いは、エラーは、ＯＳ３３２が最初に検出することもでき、ＯＳ３３２は、ＭＣＡ信号をＳＡＬ３０８又はＰＡＬ３０６にそれぞれアサートすることによってＳＡＬ３０８又はＰＡＬ３０６がエラーをハンドリングすることを要求することができる。或いは、エラーは、ＰＡＬ３０６又はＳＡＬ３０８が最初に検出して、同じように処理することもできる。要約すると、システム３００のコンポーネントは、互いに相互作用してエラーを検出し、可能ならば、システム３００においてエラーを訂正する。エラーを訂正できない場合、システム３００は、訂正されないエラーに応じて、シャットダウン、再起動、又は他の或る動作により応答する。

ＳＡＬ３０８は、システム３００のランタイム中に、ファームウェア更新要求及びエラーハンドリング要求（ＭＣＡ）の双方を受信する場合があるので、アービトレータ３１０は、これら異なる要求間を調停するように実施される。少なくともいくつかの実施形態では、ファームウェア更新要求及びＭＣＡの双方を処理するために、固定ファームウェアコンポーネント３１４のうちの少なくとも１つが必要とされる。したがって、いくつかの場合では、ＭＣＡの処理に関与している固定ファームウェアコンポーネント３１４は、ＳＡＬのＭＣＡハンドリングプロセスを中断することなくファームウェア更新要求の処理に関与することができない。或いは、いくつかの場合では、ファームウェア更新要求の処理に関与している固定ファームウェアコンポーネント３１４は、ＳＡＬのファームウェア更新プロセスを中断することなくＭＣＡの処理に関与することができない。したがって、アービトレータ３１０は、ＳＡＬ３０８が、ファームウェア更新要求とＭＣＡ処理との間の衝突をどのように管理するかを決定する。

少なくともいくつかの実施形態では、アービトレータ３１０は、すでに進行中の要求を完了すること及び衝突している要求を延期することによって、ファームウェア更新要求とＭＣＡ処理との間の衝突を管理する。たとえば、ＭＣＡが受信される時に、ファームウェア更新が進行中である場合、アービトレータ３１０は、ＳＡＬ３０８に、ＭＣＡの処理をファームウェア更新の完了後まで延期させる。或いは、ファームウェア更新要求が受信される時に、ＳＡＬ３０８がＭＣＡを処理している場合、アービトレータ３１０は、ＳＡＬ３０８に、ファームウェアの更新（追加）をＭＣＡ処理の完了後まで延期させる。

代替的な実施形態では、アービトレータ３１０は、ファームウェア更新要求に優先権を選択的に与えることによって、ファームウェア更新要求とＭＣＡ処理との間の衝突を管理する。たとえば、ＭＣＡが受信される時に、ファームウェア更新が進行中である場合、アービトレータ３１０は、ＳＡＬ３０８に、ＭＣＡの処理をファームウェア更新の完了後まで延期させる。或いは、ファームウェア更新要求が受信される時に、ＳＡＬ３０８がＭＣＡをハンドリングしている場合、アービトレータ３１０は、ＳＡＬ３０８に、ＭＣＡの処理を停止又は延期させ、その代わり、ファームウェア更新要求を処理させる。ファームウェア更新が完了すると、ＭＣＡ処理を継続又は再起動することができる。少なくともいくつかの実施形態では、ＭＣＡ処理が中断され、且つＭＣＡ処理を延期することができない場合、アービトレータ３１０は、ＰＡＬ３０６やＯＳ３３２等のプラットフォームエンティティに、ＭＣＡを処理できなかったこと、又は、エラーを訂正できなかったことを通知する。たとえば、アービトレータ３１０は、ＭＣＡをアサートしたプラットフォームエンティティ、又は、ＳＡＬ３０８がエラー訂正できない場合にエラーをハンドリングするプラットフォームエンティティに通知を提供することができる。いくつかの場合では、この通知は、単に、別のＭＣＡ信号とすることができる。

代替的な実施形態では、アービトレータ３１０は、ＭＣＡ処理に優先権を選択的に与えることによって、ファームウェア更新要求とＭＣＡ処理との間の衝突を管理する。たとえば、ファームウェア更新要求が受信される時に、ＳＡＬ３０８がＭＣＡを処理している場合、アービトレータ３１０は、ＳＡＬ３０８に、ファームウェアの更新（又は追加）をＭＣＡ処理の完了後まで延期させる。或いは、ＭＣＡが受信された時に、ファームウェア更新が進行中である場合、アービトレータ３１０は、ＳＡＬ３０８に、ファームウェアの更新を停止又は延期させ、その代わり、ＭＣＡを処理させる。ＭＣＡ処理が完了すると、ファームウェア更新プロセスを継続又は再起動することができる。少なくともいくつかの実施形態では、ファームウェア更新要求が中断され、且つファームウェア更新要求を延期させることができない場合、アービトレータ３１０は、ファームウェア更新を要求したローカルエンティティ又はリモートエンティティに、ファームウェア更新を完了できなかったことを通知する。

いくつかの実施形態では、アービトレータ３１０は、タイミングの考慮に基づいてファームウェア更新要求とエラーハンドリング要求との間の衝突を管理する。たとえば、衝突するＭＣＡが受信される時に、ファームウェア更新が進行していた時間がしきい値時間量よりも少ない場合、アービトレータ３１０は、ＭＣＡを処理して、ファームウェア更新を延期することができる。或いは、衝突するファームウェア更新要求が受信される時に、ＭＣＡ処理が進行していた時間がしきい値時間量よりも少ない場合、アービトレータ３１０は、ファームウェアを更新して、ＭＣＡ処理を延期することができる。

また、衝突するＭＣＡが受信される時（又は受信された後）に、ファームウェア更新が進行していた時間がしきい値時間量よりも多い場合、アービトレータ３１０は、エラーハンドリング要求が通常はファームウェア更新よりも高い優先権を有していても、エラーの処理を中断又は延期することができる。或いは、衝突するＭＣＡが受信される時（又は受信された後）に、ファームウェア更新が進行していた時間がしきい値時間量よりも多い場合、アービトレータ３１０は、ファームウェア更新が通常はＭＣＡ処理よりも高い優先権を有していても、ファームウェア更新を中断又は延期して、ＭＣＡを処理することができる。アービトレータ３１０によるタイミングの考慮を使用することは、たとえば、ファームウェア更新要求と、ファームウェア更新オペレーションと、ＭＣＡ信号と、ＭＣＡハンドリングオペレーションとのステータスをチェックして更新するカウンタ及びオペレーションを伴うことができる。

いくつかの実施形態では、アービトレータ３１０は、特定の要求を識別することに基づいて、ファームウェア更新要求とＭＣＡとの間の衝突を管理する（すなわち、異なるタイプのファームウェア更新要求及びＭＣＡを識別でき、それに応じてハンドリングすることができる）。たとえば、特定のタイプのファームウェア更新要求は、特定のタイプのＭＣＡよりも上の優先権を有することもできるし、その逆とすることもできる。このような実施形態では、アービトレータ３１０は、各要求を備えた識別情報を検索し、その識別情報を使用して、衝突する要求に優先権を付ける。いくつかの実施形態では、アービトレータ３１０は、タイミングの考慮、優先権、及び他のポリシーを組み合わせて、ファームウェア更新要求とＭＣＡとの間の衝突をハンドリングする。

いくつかの実施形態では、少なくとも１つの固定コンポーネント３１４が、ＭＣＡハンドリングの基本レベルを担当する一方、少なくとも１つの更新可能コンポーネント３１２が、拡張ＭＣＡハンドリングを担当する。いくつかの場合では、ファームウェア更新が進行中である場合、拡張ＭＣＡハンドリングを提供する更新可能コンポーネント３１２が利用可能でない場合であっても、基本ＭＣＡハンドリングを提供する固定コンポーネント３１４は利用可能である。したがって、アービトレータ３１０は、ファームウェア更新が進行中である間、ＭＣＡ処理を延期するのか、それとも、基本ＭＣＡハンドリングを行うのかを決定することができる。いくつかの実施形態では、アービトレータ３１０は、いくつかのＭＣＡの処理を延期することによって、ＳＡＬ３０８によるＭＣＡハンドリング能力が劣化する可能性があることを考慮する。

図４は、本発明の実施形態による別の方法４００を示している。図４に示すように、方法４００は開始ブロック４０２を含む。方法４００では、エラーはプラットフォームによって処理される（ブロック４０４）。プラットフォームがエラーを訂正する場合（判断ブロック４０６）、通常オペレーションが継続される（ブロック４１２）。プラットフォームがエラーを訂正しない場合（判断ブロック４０６）、ＰＡＬファームウェアモジュールがエラーをハンドリングする（ブロック４１４）。

方法４００では、エラーは、プロセッサが処理することもできる（ブロック４０８）。プロセッサがエラーを訂正する場合（判断ブロック４１０）、通常オペレーションが継続される（ブロック４１２）。プロセッサがエラーを訂正しない場合（判断ブロック４１０）、ＰＡＬがエラーをハンドリングする（ブロック４１４）。ＰＡＬがエラーを訂正する場合（判断ブロック４１６）、通常オペレーションが継続される（ブロック４１８）。ＰＡＬがエラーを訂正しない場合（判断ブロック４１６）、ＳＡＬファームウェアモジュールがエラーをハンドリングする（ブロック４２０）。

図４に示すように、ブロック４２０は、ファームウェア更新が進行中であるか否かを判断すること（判断ブロック４２２）を伴う。ファームウェア更新が進行中である場合（判断ブロック４２２）、方法４００は、ファームウェア更新の完了後までエラーハンドリングを延期する（ブロック４２４）。ファームウェア更新が進行中でない場合（判断ブロック４２２）、又は、ファームウェア更新が完了している場合（ブロック４２４）、エラーハンドリングが実行され、どのファームウェア更新要求も、エラーハンドリングの完了後まで延期される（ブロック４２６）。

ＳＡＬがエラーを訂正する場合（判断ブロック４２８）、通常オペレーションが継続される（ブロック４３０）。ＳＡＬがエラーを訂正しない場合（判断ブロック４２８）、ＯＳがエラーをハンドリングする（ブロック４３２）。図示しないが、ＯＳがエラーを訂正する場合、又は、ＯＳがエラーを訂正しないときにＯＳがシステムをシャットダウン（再起動）する場合、方法４００は、通常オペレーションを継続する等のステップも含むことができる。

上記解説は、本発明の原理及びさまざまな実施形態の例示であることが意図されている。当業者には、上記開示が十分に理解されると、多数の変形及び変更が明らかになるであろう。添付の特許請求の範囲は、このようなすべての変形及び変更を包含するように解釈されることが意図されている。

本発明の実施形態によるシステムを示す図である。 本発明の実施形態による方法を示す図である。 本発明の実施形態による別のシステムを示す図である。 本発明の実施形態による別の方法を示す図である。

符号の説明

１００・・・システム
１０２・・・コンピュータ
１０４・・・プロセッサ
１０６・・・ネットワークインターフェース
１０８・・・メモリ
１１２・・・アプリケーション
１２０・・・ファームウェア
１２２・・・アービトレータ
１２４・・・更新可能ファームウェアコンポーネント
１３０・・・固定ファームウェアコンポーネント
１４０・・・ネットワーク
１５０・・・更新コンピュータ
１５２・・・ファームウェア更新アプリケーション
３００・・・システム
３０２・・・プラットフォーム
３０４・・・プロセッサ
３０６・・・プロセッサ抽象化レイヤ（ＰＡＬ）
３０８・・・システム抽象化レイヤ（ＳＡＬ）
３１０・・・アービトレータ
３１２・・・更新可能コンポーネント
３１４・・・固定コンポーネント
３１６・・・フレームワーク
３１８・・・レジストリ
３２０・・・シーケンサ
３３０・・・拡張可能ファームウェアインターフェース（ＥＦＩ）
３３２・・・オペレーティングシステム

Claims (10)

1. コンピュータシステム（１０２）であって、
   プロセッサ（１０４）と、
   前記プロセッサ（１０４）と通信するファームウェア（１２０）であって、少なくとも１つの更新可能コンポーネント（１２４）及びアービトレータ（１２２）を有する、ファームウェア（１２０）と
   を備え、
   前記アービトレータ（１２２）は、前記ファームウェア（１２０）内で実行されるエラーハンドリングとファームウェア更新との間の衝突を管理する
   コンピュータシステム。
2. 前記アービトレータ（１２２）は、進行中のファームウェア更新の完了後までエラーハンドリングを延期することによって、エラーハンドリングとファームウェア更新との間の衝突を管理する
   請求項１に記載のコンピュータシステム。
3. 前記アービトレータ（１２２）は、進行中のエラーハンドリングの完了後までファームウェア更新を延期することによって、エラーハンドリングとファームウェア更新との間の衝突を管理する
   請求項１に記載のコンピュータシステム。
4. 前記ファームウェア（１２０）は、
   少なくとも１つの固定コンポーネント（１３０）
   をさらに備える
   請求項１に記載のコンピュータシステム。
5. 前記少なくとも１つの固定コンポーネント（１３０）は、
   現在インストールされているファームウェアコンポーネントのリストを保持するレジストリ（３１８）と、
   ファームウェア更新が進行中に更新可能コンポーネント（３１２）が通信することを可能にするフレームワーク（３１６）と
   を備える
   請求項４に記載のコンピュータシステム。
6. 前記更新可能コンポーネント（３１２）及び前記アービトレータ（３１０）は、システム抽象化レイヤ（ＳＡＬ）（３０８）の一部である
   請求項１に記載のコンピュータシステム。
7. ファームウェア更新要求を受信することと、
   エラーハンドリング要求を受信することと、
   前記ファームウェア更新要求の処理と前記エラーハンドリング要求の処理との間を調停することと
   を含む方法。
8. 前記調停することは、
   基本エラーハンドリングを有効にすることと、
   ファームウェア更新が行われている間、拡張エラーハンドリングを延期することと
   を含む
   請求項７に記載の方法。
9. 更新可能ファームウェアコンポーネント（３１２）のリスト（３１８）を保持することと、
   前記ファームウェア更新要求に応答して前記リストを更新することと
   をさらに含む請求項７に記載の方法。
10. エラーハンドリング要求に関連するエラー処理が中断されるか、又は、延期される場合、該エラーハンドリング要求を別のエンティティにアサートすること
    をさらに含む請求項７に記載の方法。

Images