さまざまな実施形態において、SMM入場/退場に際して個々のスレッドの保存状態を記憶するために外部の物理的メモリを使うことに対する代替として、ダイ上記憶を使用することができる。対照的に、現行のシステムはSMMに入場および退場するために、外部の物理的メモリに依存する。このSMMのシステムRAMへの依存の結果、ミッションクリティカルな応用におけるスケーリング、パフォーマンスおよび信頼性に関係した制限が生じるが、そのような依存は、本発明のある実施形態を使って回避できる。本稿での用法では、「スレッド」という用語は、プロセスに関連付けられたアーキテクチャ状態についてのプロセッサ中の記憶(たとえば、レジスタ・ファイルおよび関連する構成設定および状態レジスタ)を含むハードウェア・スレッドを指しうることを注意しておく。本稿での用法では、「ハードウェア・スレッド」という用語は、「論理プロセッサ」という用語と同義に使われる。各プロセッサ・コアは複数の論理プロセッサを含んでいてもよく、各論理プロセッサは、専用のアーキテクチャ状態記憶を有するが、フロントエンド・ユニット、実行ユニットなどといった他のコア資源を共有する。
種々の実装において、SMMの間、アクティブ・スレッドがあればその保存状態を記憶しておくために設けられるダイ上記憶は、保存状態記憶のための小さな専用のメモリとしてはたらく、ダイ上静的RAM(SRAM: static RAM)またはプロセッサ自身の中のレジスタ・ファイルであることができる。いくつかのプロセッサは、電力管理のような特定のタスクのためのダイ上SRAMを含むことがある。該電力管理とは、たとえば、先進構成設定および電力インターフェース(ACPI: Advanced Configuration and Power Interface)状態に基づくようなOSに管理される低電力状態(たとえば、C6状態または他の電力管理動作)である。そのようなプロセッサでは、スレッド毎に分割した、このSRAMの一部を、各スレッドのSRAM保存状態のためにリザーブすることができる。一例として、各論理プロセッサは、SMM保存状態のために1キロバイト(KB)のSRAM記憶を使ってもよい。所与のプロセッサがこの量のSRAMをSMM保存状態のために割くことができない場合、ある実施形態は、C6フローのためにリザーブされているSRAMを利用できるよう実装されることができる。この場合、SMM内部のC6/C7遷移はより低い低電力状態(たとえばC3)に降格されることができる。SMM状態保存のために共有されるSRAM空間の互いに排他的な使用を保証するためである。いくつかのプロセッサはC6状態保存のための専用のSRAMを実装せず、代わりに最終レベル・キャッシュ(LLC: last level cache)の一部を、C6状態保存の間、プロセッサ状態を保存するために利用する。これらのプロセッサにおいて、SMM保存状態はLLC内に記憶されることができる。
いったん保存されると、この内部SMM保存状態は種々の仕方でアクセスされうる。例として、内部状態は、スレッド毎のモデル固有レジスタ(MSR: model-specific register)アドレッシングまたは上位互換な機構を使ってアクセスされることができる。従来では、プロセッサは、ある種のシステム・メモリ・アドレスにおいてSMM保存状態にアクセスできる。上位互換な機構は、これらのレガシー・メモリ・アドレスへの論理プロセッサのアクセスを捕捉して、それらを適切なSRAM位置にリダイレクトするプロセッサ中の論理を含む。そのようなリダイレクトは、既存の基本入出力システム(BIOS: basic input/output system)ソフトウェアとの絶対的な上位互換性が要求される場合に実装されることができる。これらのMSRは、SMMモードでのみ読まれたり書かれたりすることができ、SMM保存状態に関連する制約に従う。ある論理プロセッサが別のプロセッサの保存状態へのアクセスを必要とする場合、これはソフトウェア・プロトコルを介して達成できる。
いくつかの実施形態では、専用のプロセッサ識別子リーフ(leaf)(たとえばCPUIDリーフ)またはそのフィールドまたは機能イネーブルMSR(Model-specific Register)ビットが、内部SRAMの使用を有効にするために使うことができる。ここで図1を参照するに、本発明のある実施形態に基づくプロセッサのブロック図が示されている。図1に示されるように、プロセッサ100は多段(multi-stage)パイプライン式(pipelined)順序外(out-of-order)プロセッサであってもよい。プロセッサ100は、本稿で記載されるSMM技法に関連して使われるさまざまな機能を例解するために比較的単純化した図として示している。見て取れるように、プロセッサ100は、複数のプロセッサ・コア105を含み、単一の半導体ダイ上に形成されうるマルチコア・プロセッサであってもよい。図1の実施形態では四つのそのようなコアをもって示されているが、本発明の範囲がこの点に関して限定されないことを理解されたい。図1においてさらに見て取れるように、追加的なコンポーネントがプロセッサ100内に存在していてもよい。たとえば、統合メモリ・コントローラ(IMC: integrated memory controller)108が、静的ランダム・アクセス・メモリ(SRAM)106とともに存在していてもよい。上で論じたように、いくつかの実装では、このメモリは、普通ならSMRAMに記憶されるところのコンテキスト状態を本発明の実施形態に基づいて記憶するために使用されてもよい。さらに、プロセッサ100は、すべてのプロセッサ・コアの間で共有されている共有キャッシュであってもよい最終レベル・キャッシュ(LLC)109を含んでいてもよい。
図1に示されるように、プロセッサ100は、実行されるべきマクロ命令をフェッチしてそれらをコアにおけるのちの使用のために用意するために使用されうるフロントエンド・ユニット110を含む。たとえば、フロントエンド・ユニット110は命令プリフェッチャー、命令デコーダおよびトレース・キャッシュを、マイクロコード記憶およびマイクロ命令(μop)記憶とともに含んでいてもよい。命令プリフェッチャーは、メモリからマクロ命令をフェッチし、それらを命令デコーダに供給してもよい。命令デコーダはそれらのマクロ命令をプリミティブ、すなわちプロセッサによる実行のためのマイクロ命令にデコードする。トレース・キャッシュはデコードされたマイクロ命令を受け、それらをプログラム順序付けシーケンス(program ordered sequence)にまとめてもよい。もちろん、追加的なコンポーネントおよび機能がフロントエンド・ユニット110において実装されていてもよい。
フロントエンド・ユニット110および実行ユニット120の間には、マイクロ命令を受け取ってそれらを実行のために用意するために使用されうる順序外(OOO: out-of-order)エンジン115が結合される。より具体的には、OOOエンジン115は、マイクロ命令フローを並べ替え、実行のために必要とされるさまざまな資源を割り当てるとともに、レジスタ・ファイル130aのようなさまざまなレジスタ・ファイル内の記憶位置への論理レジスタのリネーミング(renaming)を提供するためのさまざまなバッファを含んでいてもよい。レジスタ・ファイル130は、整数演算および浮動小数点演算のための別個のレジスタ・ファイルを含んでいてもよい。それぞれ異なる論理プロセッサ用の複数のレジスタ・ファイル130a〜nが存在していてもよいことを注意しておく。さらなるレジスタ、すなわち状態および構成設定レジスタ135も存在していてもよい。見て取れるように、レジスタ135a〜nの各セットは異なる論理プロセッサ用であってもよい。これらさまざまなレジスタは、異なる動作モードのためにコアを構成設定するために、また実行されるスレッドおよび異なる命令に関して状態情報を提供するために、使用されてもよい。
図1に示した例では、そのようなレジスタはSMM保存状態レジスタ136を含んでいてもよい。さまざまな実装では、それぞれコア上で動作する所与のスレッドに関連付けられている複数のそのようなレジスタが存在していてもよい。上で論じたように、そのようなレジスタは、SMMにはいるときにコア自身の内部などにスレッドの状態が記憶されることができるようにするインジケータ、たとえばイネーブル・ビットを記憶してもよい。このインジケータが有効にされていない場合は、その代わりに、SMMにはいった時点でスレッドのコンテキストがSMRAMに記憶される。いくつかの実施形態では、このMSRは、他のプロセッサ機能を制御できる他のビットを含んでいてもよい。いくつかの実施形態では、インジケータを含むこのレジスタ・ファイル135は、SMMにおいてのみ変更可能であるようにされることができる。こうして、SMMの外部のマルウェア・コンポーネントによって悪意をもって変更されることから保護され、システムのセキュリティおよび堅牢性の両方が向上する。
さらに見て取れるように、レジスタ・ファイル135は一つまたは複数のSMM状態インジケータ・レジスタ138をも含んでいてもよい。そのようなインジケータ・レジスタは、ビットマップまたはビット・ベクトルの形であってもよく、ここで、各論理プロセッサが、該論理プロセッサがいつSMMにはいることを禁止されるか、あるいは該論理プロセッサが長いフロー実行の中にあるかどうかを指示するための位置をもつ。ある実施形態では、別個のレジスタがそのような各指示について存在していてもよい。あるいはまた、単一のレジスタが存在していてもよく、論理的に組み合わされたインジケータが、各論理プロセッサについてこれらの状態の一つの存在を指示するために使用されてもよい。これらのレジスタの使用に関するさらなる詳細は以下で述べる。
引き続き図1を参照するに、さまざまな資源が実行ユニット120中に存在していてもよい。それにはたとえば、数ある特化されたハードウェアの中でも、整数、浮動小数点および単一命令複数データ(SIMD: single instruction multiple data)論理ユニットが含まれる。結果は、リアイアメント(retirement)ユニット140に与えられてもよい。リアイアメント・ユニット140は、実行された命令が有効にリタイアされ、結果データがプロセッサのアーキテクチャ状態にコミットされることができるかどうか、あるいは命令の適正なリアイアメントを妨げる一つまたは複数の例外が発生したかどうかを決定するよう動作しうる。
図1に示されるように、リアイアメント・ユニット140はキャッシュ・メモリ150に結合されている。キャッシュ・メモリ150は一実施例では低レベル・キャッシュ(たとえばL1キャッシュ)であってもよいが、本発明の範囲はこの点に関して限定されるものではない。また、実行ユニット120はキャッシュ150に直接結合されることができる(図1には示さず)。キャッシュ・メモリ150から、より高いレベルのキャッシュ、システム・メモリなどとデータ通信が行われてもよい。図1の実施形態ではこの高レベルで示されているが、本発明の範囲がこの点に関して限定されるものではないことを理解されたい。たとえば、他の実施形態は、順序内(in-order)プロセッサにおいて実装されてもよい。
SMM保存状態を内部的にプロセッサに保存することによって、システムの信頼性および堅牢性が改善されうる。すなわち、典型的にはSMRAMが存在する外部の動的ランダム・アクセス・メモリ(DRAM)デバイスの組である物理的メモリはメモリ・エラーを起こしやすい。本発明の実施形態なしでは、SMM動作はその外部メモリを使い果たして、よってエラー状態において頼られることができない。その代わり、本発明の実施形態を使うと、エラーを処理する際に不揮発性空間からSMIハンドラを実行することによって、SMRAMメモリ信頼性が改善できる。たとえば、SMMハンドラは、メモリ・エラーを処理する間、BIOSフラッシュまたは外部SRAMのようなより堅牢な記憶から走らせることができる。また、SMM保存状態がプロセッサ内部であるとき、この記憶のアーキテクチャ状態は、ソフトウェア外部には、MSRを通じてのみ暴露されることができる。SMMコードが「再開(RSM: resume)」命令を実行した後に機械実行状態を復元するために必要とされるプロセッサのマイクロアーキテクチャ状態は、外部のソフトウェアに暴露される必要がない。外部のソフトウェアはこの内部機械状態にとって何の正当な用途もないからである。これは、悪意のあるソフトウェア・コードが機微なマイクロアーキテクチャ状態へのアクセスをもたないことをも意味する(保存されたデータ記憶がSMRAM内にあればそのようなアクセスをもつはずである)。それにより当該機械がより安全で、堅牢になる。
諸実施形態は、パフォーマンスおよびレイテンシも改善しうる。多くのサーバー・アプリケーション/オペレーティング・システムは非一様メモリ・アーキテクチャ(NUMA: non-uniform memory architecture)最適化をされており、BIOSは典型的には、連続するメモリ範囲であるSMRAM全体が単一のソケットにマッピングされるようメモリを構成設定する。したがって、すべてのSMM保存状態/復元状態動作は、SMRAMにとってローカルな一つのソケットに含まれるものを除いて、すべての論理CPUについてリモート書き込み/リモート読み出しのように見えるであろう。それぞれ12個のコアをもつ四つのソケットをもつサーバー構成についてのパフォーマンス解析によると、SMM保存状態書き込み動作は相互接続およびメモリ帯域幅によって制限されることができ、高々5マイクロ秒かかることができることが示される。アプリケーションがよりNUMA最適化されるにつれ、プロセッサはリモート・トラフィックのためにさらに少数のバッファを割り当てることがありうる。そうなると、SMRAM保存状態書き込みおよび読み出し動作は、さらに長い時間がかかる。オペレーティング・システムは典型的には、受け容れ可能なリアルタイム・パフォーマンスを維持し、高速ネットワーク・リンク上でのタイムアウトを回避するために、CPUがどれくらい長くSMM内にあることができるかについて制限をもつ。この制限を超えることは、OSの反応性、アプリケーション・レイテンシに影響し、さらにはオペレーティング・システムの誤動作につながることもありうる。したがって、本発明のある実施形態に基づくダイ上SMM保存状態を使うことは、レイテンシを短縮し、よってSMMイベントにサービスする(SMMの有用な作業)ためのSMMハンドラのために割り当てられるさらなる時間を可能にする。
さらに、諸実施形態はスケーラビリティを改善しうる。マルチプロセッサ・システムにおいて、SMIが発生するとき、システム中の全スレッドがその保存状態を、システム・ブートの際にシステムBIOSによって画定され、リザーブされる、外部システム・メモリ中のそれ自身の専用の保存状態領域に記憶しなければならない。システム中のすべてのスレッドの保存状態すべてを取り込むために必要とされるSMRAM空間としてリザーブされるべき物理的メモリの総量は、システム中のスレッド数に対して線形に増大する。対称的なマルチスレッディング・サポートをもつマルチコア、マルチソケット・システムについて、空間の量はかなり大きいことがある(ある実施形態では約256KBのオーダーになりうる)。SMM保存状態のためのダイ上記憶を設けることによって、すべてのコアおよびそのスレッドを収容するための拡大し続けるSMRAM領域の必要性が回避でき、それによりスケーリングが容易にされる。また、BIOSがスレッド毎にSMRAM中の一意的な重複しない領域を見出し、割り当てる必要性もなくなる。さらにまた、これはメモリ保護領域がシリコンにおいて実装されることを免除する。ホット・プラグ・シナリオでは、SMRAMにおけるアーキテクチャ的に画定されるSMM保存状態領域は1MB未満である。本発明の実施形態なしでは、BIOSはメモリ保護範囲を設定し、新しいプロセッサを追加するときは、OS攻撃および/または干渉を避けるために、データを退避する。諸実施形態では、保存される状態はもはやOS可視メモリ内に記憶されないので、これを行う必要がなくなる。
ここで図2を参照すると、本発明のある実施形態に基づくマルチプロセッサ・システムのブロック図が示される。図2に示されるように、マルチプロセッサ・システム200は複数のプロセッサ2101〜210n(概括してプロセッサ210)を含む。図2の実施形態ではそのようなプロセッサ四つが示されているが、本発明の範囲がこの点に関して限定されるものではないことを理解されたい。図2に示される実施形態では、非一様メモリ・アーキテクチャ(NUMA)システムが存在しており、システム・メモリ2201および2203が相互接続2171および2173を介してプロセッサ2101および2103にローカルに取り付けられる。こうして、プロセッサ2102および210nによるメモリへのアクセスは、プロセッサ2101および2103の一方との複数のポイントツーポイント(PTP: point-to-point)相互接続215のうちの一つを通じた通信を必要とする。図2の実装において見て取れるように、DRAMであってもよいメモリ2201はSMRAM 225を含む。このNUMA最適化アーキテクチャでは、SMRAM 225はシステム全体のためのシステム管理ストアである。よって、本発明の実施形態なしでは、各プロセッサは、SMM入場または退場の際、このSMRAM 225にコンテキストを保存/復元する必要がある。これはPTP相互接続215および相互接続2171での帯域幅の大幅な使用を引き起こすとともに、SMMへの入場およびSMMからの退場のためのレイテンシを増加させる。したがって、さまざまな実施形態において、各プロセッサ210は、一つまたは複数のコア212および統合メモリ・コントローラ214に加えて、SRAM 216を含んでいてもよい。さまざまな実施形態では、SRAM 216はSMM保存状態の記憶のために専用とされてもよい。すなわち、システム管理割り込みが起こるとき、各プロセッサ210のさまざまな論理プロセッサについてのコンテキスト状態がそのSRAM 216にローカルに記憶されてもよい。それによりSMRAM 225との状態情報の通信の必要性が回避される。他の実施形態では、専用のダイ上記憶の代わりに、このコンテキスト状態は、たとえばレジスタ・ファイルまたはキャッシュ・メモリのような他の位置の、チップ上レジスタに記憶されることができる。図2の実施形態ではこの特定の実装で示しているが、本発明の範囲はこの点について限定されるものではない。たとえば、諸実施形態はさらに、一様メモリ・アーキテクチャ・システムとともに使用されてもよい。
ここで図3を参照するに、本発明のある実施形態に基づく方法の流れ図が示されている。図3に示されるように、方法300は、状態情報を保存するためにSMRAMにアクセスする必要なしにSMMへの入場を扱うよう実行されうる。議論の簡単のため、単一のハードウェア・スレッドしか存在していないと想定されるが、多くの実装では複数のスレッドが一緒にSMMにはいってもよいことを注意しておく。図3で見て取れるように、方法300は、システム管理割り込みを受け取ることによって開始されうる(ブロック310)。この割り込みを受領すると、(たとえば所与のハードウェア・スレッドの)現在のアクティブ状態がダイ上記憶に保存されてもよい(ブロック320)。上で論じたように、このダイ上記憶は、専用のSRAM、別の目的(たとえば電力管理状態)のために使われるSRAM、レジスタ記憶、ダイ上キャッシュ記憶などであってもよい。
引き続き図3を参照するに、プロセッサ状態は、たとえばプロセッサ仕様によって定義されるところのSMM入場状態にマッチするよう修正される(ブロック330)。この状態は、さまざまな制御および構成設定レジスタについての値およびレジスタ・ファイルについての初期値を含む。よって、このセットアップは、SMM入場状態に関連付けられた所定の値を状態記憶にロードすることによって、SMMハンドラのために適切なSMM実行環境を用意する。SMM状態がセットアップされたら、制御はブロック340に進む。ブロック340では、SMMがSMRAMからのコードおよびデータを使って実行されてもよい。したがって、所望されるSMM動作が実行されてもよい。本発明の範囲はこの点に関して限定されるものではないが、SMM動作の例は電力管理動作、エラー処理動作などを含む。
次いで、SMM動作が完了したかどうかが判定されてもよい(菱形350)。まだであれば、SMMにおける実行は継続してもよい。完了していれば、プロセッサは再開命令を実行する(ブロック360)。この命令の結果として、前の状態が、ダイ上記憶からプロセッサのレジスタにロードし戻されてもよい(ブロック370)。次いで、プロセッサは、アクティブ状態に復元し戻されたこの、前の状態に対応するスレッドの実行を再開してもよい(ブロック380)。図3の実施形態ではこの特定の実装をもって示しているが、本発明の範囲がこの点に関して限定されるものではないことを理解されたい。たとえば、いくつかの実装では、特にSMMがDRAMエラーのようなエラーを処理するためであるとき、SMM動作をSMRAMから実行するのではなく、諸実施形態はSMM状態情報、SMMコードおよびデータをフラッシュメモリのような不揮発性記憶から取得してもよい。
上記のように、アクティブ状態のシリコン記憶はSMMレイテンシを減らすことができる。諸実施形態はさらに、ある種の状況においてより高速にSMMにはいることを可能にすることによって、さらにレイテンシを減らしてもよい。それについてこれから論じる。
SMMレイテンシは、単一SMI当たりプロセッサがSMM環境内にある期間の長さとして定義される。全SMMレイテンシに対する主として二つの寄与因子がある。プロセッサ・オーバーヘッドおよびOEM BIOSコードである。このレイテンシは、タイムアウトおよびクロック・ドリフトのようなOS環境に対する副作用を回避するために制御下に保たれる必要がある。将来の需要はこのレイテンシが減らされることを要求するであろうが、それは実現するのが難しくなる。現在のところ、SMIレイテンシは、約190マイクロ秒未満であるよう指定されている。インターネット・ポータル・データ・センターおよびユーティリティー・コンピューティングのような新しい使用モデルは、アプリケーションから、より予測可能なレイテンシを期待する。結果として、OSベンダーはSMMレイテンシのさらなる削減を求めている。他方、他の技術は時間とともにSMIレイテンシを増大させる可能性がある。たとえば、マルチコア・プロセッサに向けた業界の圧力は、SMIハンドラが増大し続ける数のプロセッサ・コアを集結させなければならないことを意味する。新しいSMMベースの機能も、SMMレイテンシに対して追加的な圧力をかける。たとえば、ハイエンドRAS機能はSMMに依拠する。さらに、一部のOEMは、自分たちの製品を差別化するために独特な電力管理機能を与えるため、SMMを利用する。多くのOEMは、1秒当たり8回もSMIを生成することが知られている。
ある種の命令セット・アーキテクチャ(ISA: instruction set architecture)は、すべてのキャッシュ・ラインを無効にしてメモリに書き戻すライトバック(write back)および無効化(invalidate)命令(たとえばwbinvd)のような命令を含む。これらの動作は完了までに、特に大きなキャッシュ・サイズをサポートするプロセッサでは、たとえば103ないし107プロセッサ・サイクルのオーダーの長い時間がかかることがある。さらに、SMI応答が遅延されることのできるある種のプロセッサ状態がある(たとえばC3およびC6低プロセッサ状態)。まとめて、これらの命令およびプロセッサ状態は「長いフロー(long flow)」状態と称される。これは、完了するのに異例なほど長いサイクル数(たとえば103クロックのオーダー)がかかることがあり、SMMにはいるのを遅らせることができる命令またはプロセスを意味するものと定義される。ある実施形態では、SMM入場を5ミリ秒より長く遅らせるいかなるフローも長いフローと称されることができる。SMMに関しては、一つまたは複数の論理プロセッサが長いフロー中にある場合、それはSMMにはいるのを遅らせる。
上に説明したように、SMMモナークは、すべての期待される論理プロセッサがSMMにはいってしまうまで待つ。SMMにはいると、各プロセッサはSMRAM中の自らのビットをセットして、SMMにはいったことを示す。モナークは、すべての期待されるプロセッサがそのビットをセットしてしまうまで待つ。一つまたは複数の論理プロセッサが長いフロー中にあってSMMに遅れてはいるときは、SMMモナークは引き留められ、よってSMMレイテンシが増す。さらに、スタートアップ・プロセッサ間割り込み待ち(WFS: wait for startup interprocessor interrupt)およびTXTスリープ状態のような、SMIイベントが禁止されるある種のアーキテクチャ状態がある。OS/BIOSが一つまたは複数の論理プロセッサをSMI禁止状態に入れる場合、その論理プロセッサは、OS/BIOSが明示的にこの状態から出すまで、SMMにはいらない。SMIイベントは他のすべてのプロセッサをSMMに入れるので、OSはSMIをマスク解除することができない。このシナリオのもとでは、SMMモナークは、SMI禁止されたプロセッサの存在を判別するためには、長いタイムアウトに頼らなければならない。これらのタイムアウトはSMM集結を遅らせ、全体的なSMMレイテンシを増大させるか、SMMイベント処理のために利用可能な時間を減らすかする。
さまざまな実施形態において、たとえいくつかの論理プロセッサが長いフロー中にある場合でも、SMM内部のタイムアウトの必要性が回避できる。そのようなタイムアウトをなくすことは、平均SMMレイテンシを10〜20%改善でき、最悪ケースのSMMレイテンシを少なくとも数ミリ秒改善できる。
諸実施形態は、長いフロー中にあるまたはSMI禁止状態にあるプロセッサは共有資源にアクセスする可能性は低いという事実に依拠している。さらに、そのようなプロセッサはSMIを引き起こした可能性は低く、よってその参加はSMI処理のために必要ではない。したがって、SMMモナークは、そのようなプロセッサがSMMにはいる前にSMM処理を進めることができる。
しかしながら、先に進む前に、SMMモナークは、どのプロセッサが長いフロー中にあるおよび/またはSMI禁止状態にあるかを信頼できる仕方で検出できなければならない。長いフロー中またはSMI禁止状態にあってビジーであるプロセッサを検出するために、諸実施形態は、それらの状態についてのインジケータを、たとえばビットマップによって、設けてもよい。ある実施形態では、そのような指標はグローバルに可視である、LONG_FLOW_INDICATION〔長いフロー指標〕およびSMI_INHIBITED_INDICATION〔SMI禁止指標〕と呼ばれる構成設定レジスタを介して提供されることができる。この実施形態では、ソケット内の各論理プロセッサに1ビットが割り当てられることができる。一例として、レジスタは図1のレジスタ138によって表現されてもよい。プロセッサ・マイクロコードが長いフローおよびSMI禁止状態への出入りに関わる実装では、マイクロコード/ハードウェアがそれらのレジスタ・ビットの中身を入れることができる。長いフローのいくつかは、5マイクロ秒より長い時間をかけることがあり、したがって、これらの状態にあるプロセッサを待たない能力は、SMMレイテンシの有意な節減を提供できる。将来のプロセッサはSMMマイクロコード入場フローについて5ミリ秒を超える時間がかかることがありえ、それ自身が長いフローと考えられることができる。SMMモナークはすべてのプロセッサの説明が付く、すなわちSMMに加わるか長いフローまたはSMI禁止状態にあると報告されるまで待つことができる。そのような判定において支援するために、下記で述べるように、SMRAMに記憶されるビットマップのような一つまたは複数のテーブルが、使用されることができる。
ある実装では、モナーク・プロセッサはその状態を保存し、インジケータ・レジスタのチェックを実行する前にSMMプリアンブル・コードを走らせる。これらのステップは、容易に0.5マイクロ秒より長くかかることがある。この継続時間は、いかなるインフライト割り込み(in-flight interrupt)のための伝搬時間よりずっと長く、コアへのSMI送達とそのインジケータ・レジスタの読み出しの間に競合条件がないことが保証される。遅延がある種の構成のもとでより小さい場合、モナーク・プロセッサは、埋め合わせるために小さな遅延ループを挿入することができる。
ここで図4を参照するに、本発明のもう一つの実施形態に基づく方法の流れ図が示されている。特に、図4は、すべての論理プロセッサがSMM状態において集結する必要がないときの、SMMへの出入りを扱うための流れ図を示している。このようにして、すべての論理プロセッサを待ってからSMM動作を実行することに関わるレイテンシが回避できる。図4で見て取れるように、方法400は、SMIイベントの生成によって開始されうる(ブロック410)。このSMIイベントはすべてのスレッドに伝搬されてもよい。議論の簡単のため、図4のスレッドは単一プロセッサ・ソケットに関してであると想定されていることを注意しておく。ただし、実装は、複数のソケットにまたがってSMMを集結させるために使われることができる。
次に、SMM集結状態にはいる各スレッドについて、SMMインジケータ・マップにおいてインジケータが設定されてもよい(ブロック420)。たとえば図3に関して上述した状態保存のような、SMMにはいるためのさまざまな準備動作が先にスレッドによって実行されることができることは理解しておくものとする。SMM集結状態にはいる各スレッドは、SMRAM内に記憶されていてもよいSMMインジケータ・マップにおいて、インジケータをセットしてもよい。ある実施形態では、このマップは、各論理プロセッサがマップのあるビットと関連付けられており、各ソケットの論理プロセッサがマップの異なるセグメントに分離されることのできるビットマップであってもよい。このように、所与のスレッドがSMMにはいるとき、ビットマップにおけるその対応するビットがセットされてもよい。次いで、SMM内部のスレッドの一つが、モナークまたは実行スレッドとして選択されてもよい(ブロック430)。さまざまな実施形態において、どのスレッドが実行スレッドとなるかの決定は多様でありうる。たとえば、モナークはあらかじめ選択されていてもよいし(たとえば、ソケット0上の論理プロセッサ0)、あるいは選出機構を介して動的に選択されることもできる。
引き続き図4を参照するに、各スレッドは次いで、該スレッドがモナークとして選択されたかどうかを判定する(菱形435)。そうでなければ、そのスレッドはスリープ状態にはいって、モナーク・スレッドが完了を合図するのを待ってもよい(ブロック470)。
こうして、制御はモナーク・スレッドのためのブロック440に移る。このブロックでは、すべてのスレッドについてACCOUNTED〔説明が付けられた〕状態が決定される。ある実施形態では、この状態は、SMRAM内にあってもよいスレッド存在マップに加えて、さまざまな構成設定レジスタ、SMMインジケータ・マップに基づいていてもよい。この存在マップは、SMMインジケータ・マップと同様のビットマップであってもよく、システム中に存在するスレッドを示すためにSMM初期化の際に設定されてもよい。ある実施形態では、ブロック440における決定は次のようなビットごとのOR演算であってもよい:
OR(LONG_FLOW_INDICATION,SMI_INHIBITED_INDICATION,IN_SMM_INDICATION)
ここで、LONG_FLOW_INDICATIONは、各ビットが対応するスレッドが長いフロー動作中にあるかどうかを示すビット・ベクトルを記憶する状態レジスタから得られる。SMI_INHIBITED_INDICATIONは、各ビットが対応するスレッドがSMI禁止状態にあるかどうかを示すビット・ベクトルを記憶する状態レジスタから得られる。IN_SMM_INDICATIONはSMMインジケータ・マップである。このビットごとのORの結果であるACCOUNTEDは、たとえばSMRAM中のビットマップに記憶されてもよい。この解析後、制御は菱形450に移り、ACCOUNTED状態〔説明が付けられたかどうかの状態〕がすべての存在するスレッドについてアクティブであるかどうかが判定されてもよい(菱形450)。これは、ACCOUNTED演算の結果と存在マップとの間の比較に基づいて決定できる。もしそうでない場合には、制御はもとのブロック440に移る。それ以外の場合には、制御はブロック455に移り、SMIイベントが処理されうる。こうして、モナーク・スレッドは所望されるSMMコードを実行しうる。モナーク・スレッドによって実行されるSMMの終結時に、制御はブロック460に移る。ブロック460では、ACCOUNTED状態およびSMMインジケータ・マップがリセットされてもよい(ブロック460)。すなわち、モナーク・スレッドはこれら両方のビットマップにおける値をリセットしてもよい。次いで、モナーク・スレッドは他の論理プロセッサに、SMIから復帰してもよいことを合図してもよい(ブロック465)。このようにして、他のスレッドは待ちループから解放される。こうして、ブロック475において、すべてのスレッドがSMMから復帰してもよい。図4の実施形態ではこの特定の実装をもって示されているが、本発明の範囲はこの点に関して限定されるものではない。
このように、諸実施形態は、メモリ依存性なしにSMMハンドラ実行を可能にし、信頼性を改善する。この機構は、SMMに付随するパフォーマンスおよびスケーラビリティの問題にも対処する。そのため、SMI処理は、マルチコア/マルチソケット・システムにおけるボトルネックになることを回避できる。このように、諸実施形態は、DRAM依存性をもつSMMコードの実行を回避し、高い可用性使用モデルを可能にする。ここで、SMMコードはメモリ・エラーを診断および訂正する。
諸実施形態はさらに、長いフローまたはSMI禁止状態にある論理プロセッサがあるときに低減したレイテンシをもってSMMにはいることを可能にする。対照的に、現在のところ、SMMコードが一つまたは複数のプロセッサがSMMに遅れて加わるまたはSMM禁止状態にあるかどうかを判定できる信頼できる機構はなく、よって、最大の長いフロー状態よりも大きいタイムアウトが設定される。この解決策は、信頼できず、実装が難しいことに加えて、SMMレイテンシを増大させ、OSリアルタイム応答を低下させるが、本発明の実施形態を使って克服できる。
諸実施形態は、コードにおいて実装されてもよく、システムが命令を実行するようプログラムするために使用できる命令が記憶されている記憶媒体上に記憶されてもよい。記憶媒体は、これに限られないが、フロッピー(登録商標)ディスク、光ディスク、光学式ディスク、固体ドライブ(SSD: solid state drive)、コンパクトディスク読み出し専用メモリ(CD-ROM)、書き換え可能型コンパクトディスク(CD-RW)および光磁気ディスクを含む任意の型のディスク、読み出し専用メモリ(ROM)、動的ランダム・アクセス・メモリ(DRAM)、静的ランダム・アクセス・メモリ(SRAM)のようなランダム・アクセス・メモリ(RAM)、消去可能型プログラム可能読み出し専用メモリ(EPROM)、フラッシュメモリ、電気的に消去可能なプログラム可能読み出し専用メモリ(EEPROM)のような半導体デバイス、磁気もしくは光学式カードまたは電子的な命令を記憶するのに好適な他の任意の型の媒体を含んでいてもよい。
本発明は限られた数の実施形態に関して記述されてきたが、当業者は、それから数多くの修正および変形を理解するであろう。付属の請求項は、本発明の真の精神および範囲内にはいるそのようなすべての修正および変形をカバーすることが意図されている。