セキュアな埋め込みコンテナの実行のためのプロセッサの拡張
セキュアな埋込みコンテナを実行するためのプロセッサの拡張に関する方法及び装置。一実施例では、（例えば、マネージャビリティのために専用プロセッサ又はマイクロコントローラを利用することが不適切であるか、又は実用的でないＵＭＰＣ環境又はその他の環境のための）マネージャビリティ機能のためのスケーラブルな解決策を提供する。例えば、一実施例では、ＯＳ（オペレーティング・システム）又はＶＭＭ（仮想マシン・マネージャ）独立アーキテクチャ（本明細書及び特許請求の範囲では概括的に「ＯＩ」として表す）は、ホストＯＳ／ＶＭＭとＯＩコンテナとの間の（プロセッサ・サイクル、メモリ、デバイスなど）のリソースを動的に区画化することにより、プロセッサ上で１つ又は複数のコンテナを生成することが関係する。他の実施例も説明し、特許請求の範囲において請求している。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書及び特許請求の範囲は、一般に、エレクトロニクスの分野に関する。特に、本発明の実施例は、セキュアな埋込みコンテナの実行のためのプロセッサの拡張に関する。
【背景技術】
【０００２】
コンピュータ・システムは、例えば、ハードウェア・レイヤ、ファームウェア及びオペレーティング・システム・レイヤ、並びにアプリケーション・プログラム・レイヤを含むレイヤ化されたデバイスとして実現し得る。コンピュータ・システムのハードウェア・レイヤは、物理プラットフォームとして表し得る。物理プラットフォームは、プロセッサ、チップセット、通信チャネル、メモリ、基板、及びシステムを含み得る。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
コンピュータ・システムは、マネージャビリティ・エンジン（例えば、コンピュータ・システムが（例えば、通信ネットワーク上で、遠隔管理コンソールを介して遠隔に）管理されることを可能にするための専用のマイクロコントローラを含む）も含み得る。しかし、マネージャビリティ・サービスのための専用のマイクロコントローラの提供は、制限されたＭＩＰＳ（毎秒百万命令）、放熱、電力消費、サイズ、コストを含む理由のために、一部の実現形態において、適切でないか、実用的でないか、又は、さもなければ、スケーラブルでないことがあり得る。
【課題を解決するための手段】
【０００４】
本発明の詳細な説明を、添付図面を参照して記載する。図中、参照符号の最も左の桁は、参照符号が最初に存在する図を識別する。別々の図において同じ参照符号を使用していることは、同様又は同一の項目を示している。
【図面の簡単な説明】
【０００５】
【図１】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【図２】一実施例による、一状態から別の状態への遷移をもたらすトリガ及び４つの状態を示す状態遷移図である。
【図３】一実施例による、別々のメモリ区画の実行に関連付けられた種々の動作を示すブロック図である。
【図４】一部の実施例によるタイムチャートである。
【図５】一部の実施例によるタイムチャートである。
【図６】一部の実施例によるタイムチャートである。
【図７】一部の実施例によるタイムチャートである。
【図８】一部の実施例によるタイムチャートである。
【図９】本発明の一部の実施例によるフロー図である。
【図１０】一実施例による、ＯＩ区画に導入し、ＯＩに割り当てられた装置から生じる割り込みを処理するために使用される種々の構成部分を示すブロック図である。
【図１１】本発明の一部の実施例によるフロー図である。込みを処理するために使用される種々の構成部分を示すブロック図である。
【図１２】一実施例による、ＯＩＰＩＣモジュールと通信し合う種々の構成部分を示す図である。
【図１３】一部の実施例による、ロード鍵の利用に関連付けられた動作を示すブロック図である。
【図１４】一部の実施例による、ロード鍵の利用に関連付けられた動作を示すブロック図である。
【図１５】一部の実施例による、記憶鍵の利用に関連付けられた動作を示すブロック図である。
【図１６】一部の実施例による、記憶鍵の利用に関連付けられた動作を示すブロック図である。
【図１７】一実施例による、Ｓ０とＳ３との間のセキュアな遷移に関連付けられた動作を示すブロック図である。
【図１８】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【図１９】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【発明を実施するための形態】
【０００６】
以下の説明では、種々の実施例の徹底的な理解を得るために数多くの具体的な詳細を記載している。しかし、本発明の種々の実施例は、上記具体的な詳細なしで実施し得る。他の場合には、周知の方法、手順、構成部分、及び回路は、本発明の特定の実施例を分かりにくくすることがないように詳細に説明していない。更に、本発明の実施例の種々の局面は、半導体集積回路（「ハードウェア」）、１つ若しくは複数のプログラムに編成されたコンピュータ読み取り可能な命令（「ソフトウェア」）、又は、ハードウェア及びソフトウェアの特定の組み合わせなどの種々の手段を使用して行い得る。本明細書及び特許請求の範囲の目的では、「ロジック」への言及は、ハードウェア、ソフトウェア、又はそれらの特定の組み合わせを意味する。更に、本明細書及び特許請求の範囲の（「ｕｏｐ」としても表し得る）「マイクロオペレーション」又は「命令」の使用は、置き換え可能であり得る。更に、本明細書及び特許請求の範囲記載の実施例の一部は、論理０及び論理１として組、又は明確な値を表し得るが、前述の語は、例えば、実現形態に応じて、置き換え可能である。
【０００７】
一部のプロセッサは複数のプロセッサ・コアを含み得る。複数のコアに加えて、プロセッサ・ダイは、（コア以外の、プロセッサ・ダイ上の構成要素全てを併せて表し得る）非コアを含み得る。性能を向上させるために、一層多くの機能を、例えば、複数のチップセットを置き換えることにより、プロセッサの非コアに組み入れることができる。例えば、一部の実現形態は、メモリ・コントローラ機能、ＩＯ（入出力）コントローラ機能、及びグラフィクス機能を非コアに組み入れ得る。しかし、この傾向は、プラットフォーム上で供給される他の機能及びサービス（例えば、マネージャビリティ）に影響を及ぼす。現在、一部のマネージャビリティ機能は、マネージャビリティ・エンジン（ＭＥ）のコア部分を構成し得る専用プロセッサ上で提供し得る。ＭＥは一般に、チップセット上に配置される。更に、一部のサーバ・プラットフォームは、ベースボード管理コントローラ（ＢＭＣ）、サービス・プロセッサ（ＳＰ）と呼ばれるか、又は何れかの他の名称によって呼ばれる個別の専用マイクロコントローラを実現し得る。上述の通り、前述の解決策は、限定されたＭＩＰＳ、放熱、電力消費、サイズ、コスト等などの理由で、スケーラブルでない。このことは、超モバイル・パーソナル・コンピュータ（ＵＭＰＣ）環境において更に問題となり、別の解決策に対する必要性を強いる。
【０００８】
この目的で、本明細書及び特許請求の範囲記載の一部の実施例は、（例えば、マネージャビリティのために専用プロセッサ又はマイクロコントローラを利用することが不適切であるか、又は実用的でないＵＭＰＣ環境又はその他の環境のための）マネージャビリティ機能のためのスケーラブルな解決策を提供する。例えば、一実施例では、ＯＳ（オペレーティング・システム）又はＶＭＭ（仮想マシン・マネージャ）独立アーキテクチャ（併せて本明細書及び特許請求の範囲では「ＯＩ」として表す）は、ホストＯＳ／ＶＭＭとＯＩコンテナとの間の（プロセッサ・サイクル、メモリ、デバイスなど）のリソースを動的に区画化することにより、例えば、プロセッサ上に、１つ又は複数のコンテナを生成することが関係する。一実施例では、ＯＩリソース・マネージャ（ＯＩＲＭ）は、ホストＯＳ／ＶＭＭコンテナ（本明細書及び特許請求の範囲では区画とも表す）とＯＳ独立コンテナとの間のタイム・シェアリング動作を行い得る。その結果、一部の実施例は、ＯＳ／ＶＭＭ実行性能に影響を及ぼすことなく（又はＯＳ／ＶＭＭ実行性能に対する、低減された影響を伴って）、有用な目的（例えば、マネージャビリティ）のために、アイドル・プロセッサ・サイクルを使用することを可能にする。
【０００９】
一実施例では、ＯＩ区画の割り当てを導入し、ＯＩに割り当てられたデバイスから生じた割り込みを処理するための手法を開示している。一実施例では、タンパリング耐性メモリが、ＯＩにおけるセキュリティ感応性データを処理するために提供される。一実施例では、Ｓ３からＳ０への遷移及びＳ０からＳ３への遷移に費やすことが必要な期間の量が削減される。更に、本明細書及び特許請求の範囲記載の手法は、例えば、図１乃至図１９を参照して説明したものなどの種々の計算装置における性能、効率、及び／又はセキュリティの向上を可能にし得る。
【実施例】
【００１０】
より具体的には、図１は、本発明の実施例による計算システム１００のブロック図を示す。上記システム１００は、１つ又は複数のプロセッサ１０２−１乃至１０２−Ｎ（一般に、本明細書及び特許請求の範囲において「プロセッサ１０２」又は「プロセッサ１０２」として表す）を含み得る。プロセッサ１０２は、相互接続ネットワーク又はバス１０４を介して通信し得る。各プロセッサは、種々の構成部分を含み、その一部は、明確にするためにプロセッサ１０２−１のみを参照して表している。よって、残りのプロセッサ１０２−２乃至１０２−Ｎはそれぞれ、プロセッサ１０２−１を参照して表す同一又は同様の構成部分を含み得る。
【００１１】
一実施例では、プロセッサ１０２−１は、（本明細書及び特許請求の範囲において「コア１０６」として、又はより概括的に「コア１０６」として表される）１つ又は複数のプロセッサ・コア１０６−１乃至１０６−８、共有キャッシュ１０８、及び／又はルータ１１０を含み得る。プロセッサ・コア１０６は単一の集積回路（ＩＣ）チップ上で実現し得る。更に、チップは、１つ若しくは複数の共有キャッシュ及び／又は占有キャッシュ（キャッシュ１０８など）、（バス若しくは相互接続ネットワーク１１２などの）バス又は相互接続、（図１８乃至図１９を参照して説明したものなどの）メモリ・コントローラ、又は他の構成部分を含み得る。
【００１２】
一実施例では、ルータ１１０は、システム１００及び／又はプロセッサ１０２−１の種々の構成部分間で通信するために使用し得る。更に、プロセッサ１０２−１は２つ以上のルータ１１０を含み得る。更に、多くのルータ１１０が、プロセッサ１０２−１の内部又は外部の種々の構成部分間のデータ・ルーティングを可能にするために通信し得る。一実施例では、プロセッサ１０２−１は、暗号動作における使用のためにＯＩＲＭ１２４にのみアクセス可能な埋め込まれた鍵１１３を有し得る。一実施例では、この鍵は、プロセッサの最初の電源投入時に、強い乱数発生器を使用してＯＩＲＭにより、プロセッサ上で生成し、記憶し得る。別の実施例では、この鍵は、製造時にプロセッサに記憶し得る。
【００１３】
共有キャッシュ１０８は、コア１０６などの、プロセッサ１０２−１の１つ又は複数の構成部分によって利用されるデータ（例えば、命令を含む）を記憶し得る。図に示すように、プロセッサ１０２は、オンプロセッサ（本明細書及び特許請求の範囲では「オンパッケージ」としても表す）メモリ１１１（更に後述するように、セキュアなメモリとして使用し得る）も含み得る。例えば、共有キャッシュ１０８は、プロセッサ１０２の構成部分による高速アクセスのために、メモリ１１４に記憶されたデータを局所にキャッシュし得る。一実施例では、キャッシュ１０８は、ミッドレベル・キャッシュ（レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）、又は他のレベルのキャッシュなど）、ラスト・レベル・キャッシュ（ＬＬＣ）、及び／又はそれらの組み合わせを含み得る。更に、プロセッサ１０２−１の種々の構成部分は、共有キャッシュ１０８と直接、バス（例えば、バス１１２）を介して、かつ／又はメモリ・コントローラ若しくはハブを介して通信し得る。図１に示すように、一部の実施例では、コア１０６の１つ又は複数は、（本明細書及び特許請求の範囲において概括的に「Ｌ１キャッシュ１１６」として表す）レベル１（Ｌ１）キャッシュ（１１６−１）及び／又はＬ２キャッシュ（図示せず）を含み得る。
【００１４】
図１に示すように、システム１００は、１つ又は複数の区画１２０又は１２２（本明細書及び特許請求の範囲では同義で「コンテナ」としても表す）を利用し得る。ＯＩリソース・マネージャ（ＯＩＲＭ）１２４を、通信するよう、物理レイヤ（例えば、プロセッサ・コア、チップセット、メモリ、記憶装置、ネットワーク・インタフェース等）、ホストＯＳ／ＶＭＭ、ＯＩコンテナ（又は区画）１２０及び１２２間に結合し得る。更に、２つ以上のＯＩコンテナを使用し得る。一部の実施例では、ＯＩＲＭ１２４は、プロセッサ上のファームウェア又はマイクロコードとして実現し得る。例えば、ＯＩＲＭ１２４は、プロセッサ・サイクルをスケジューリングする役割を果たすプロセッサ・マイクロコードであり得る。これは更に、（例えば、システム上で実行される複数の処理に対するシステム応答性又は公平性を維持するために）ＯＩ区画１２４によって実行されるプロセッサ命令とインタリーブされたプロセッサ命令を主ＯＳ／ＶＭＭ区画１２０が実行することを可能にし得る。
【００１５】
ホストＯＳ／ＶＭＭ区画１２０は、通常の（ホスト）アプリケーション及び／又はホスト・デバイス・ドライバ（図示せず）を含み得る。更に、ＯＩ区画１２２は、（例えば、選択されたデバイスに対する）ＯＩドライバ（図示せず）及び／又は、コア機能に対応するデータ、アプリケーションを含み得る。更に、一部の実施例では、ＯＩＲＭは、ＯＩＥＥ（ＯＩ実行環境（ＯＩ区画内の動作環境））にプロセッサ時間を割り当てる場合に満たすべき、以下の制約のうちの１つ又は複数を有し得る。
【００１６】
ホストＯＳ／ＶＭＭは割り込みを取り逃さず、又は時間ドリフトを被らず、ホストＯＳ／ＶＭＭ ＩＯデバイス（例えば、ＣＤＲＯＭ、ＬＡＮ、ＷＡＮ等）は、バッファのアンダーフロー又はオーバフローを避けるために処理される。このことは、ホストＯＳ／ＶＭＭ宛のプロセッサ間割り込み及び外部割り込みが、最小のレーテンシを伴って配信されるということを示唆している。
【００１７】
プロセッサ・コア上のＯＩＥＥのスケジューリングは、他のプロセッサのブロッキングにつながるものでない。ＯＩをスケジューリングするために選択されたプロセッサ・コア上のロックをオペレーティング・システムが保持している場合に、前述の状態が生じ得る。ＯＩを実行させるために前述のプロセッサ・コアを取り去ることにより、前述のロックを待っている他のプロセッサ・コアがスピンし、サイクルを浪費してしまう。プロセッサ・コア上の実行のためにＯＩをスケジューリングするアルゴリズムは、できる限り、前述の状態を避けるべきである。
【００１８】
プロセッサ・コア、デバイス、バス等の電力管理は、ホストＯＳ／ＶＭＭ １２０に干渉するというよりも、ＯＳと協調する。ＯＩＲＭ１２４には、システムの電力状態、熱状態、及び性能状態についての決定のスケジューリングの副作用が分かり得る。例えば、ＯＩをスケジューリングするために、（プロセッサＣ状態に関連付けられた）Ｃ−ｘプロセッサ・コアをＣ−０に至らせることにより、自動周波数スロットリングにつながる、システムの電力エンベロープの、閾値との交差をもたらし得る。よって、Ｃ−０プロセッサ・コアに対する性能の影響を避けるために行われるが、スケジューリングのためにＣ−ｘプロセッサ・コアを選択する動作は、厳しい性能ペナルティをもたらし得る。ＯＩＲＭ１２４は、（例えば、賢明な選択を行うためにＰＣＵ（電力制御装置）からの）非コア及びコアにおいて利用可能な適切な電力ヒューリスティックを利用し得る。ＰＣＵは、プロセッサ・コア及び非コア構成部分の電力管理方針を管理するためにプロセッサ非コアに備え得る。
【００１９】
オペレーティング・システム及び性能監視ツールは、ＯＩを実行するために特定のプロセッサ・コアから消費されたサイクルの数を検出する機会を与えるよう構成し得る。前述の観測機能を与えることは、それがＯＩによってもたらされたかを確かめるために、何れかの不測の挙動が観測された場合に、システムをデバッグすることに助力し得る。
【００２０】
一部の実施例では、ＯＩ実現形態は、ホストＯＳ／ＶＭＭの状態によって影響を受けない実行環境を提供することである。よって、ＯＩＲＭは一部の実施例では、以下の要件のうちの１つ又は複数を満たし得る。
【００２１】
構成されたように最小保証持続時間の間、ＯＩ動作／命令が実行することを確実にすることにより、ＯＩの枯渇を避けるか、又は減らす。
【００２２】
システム内の何れかの１つのプロセッサ・コアにＯＩ動作／命令を束縛することを避けるか、又は減らす。ＯＳ独立動作は、ホストＯＳ／ＶＭＭからサイクルをとり得る。一部のオペレーティング・システム及びＶＭＭは、スループット目標を達成するためにワークロード（例えば、スレッド、ＶＭ（仮想マシン）等）を束縛する。特定のプロセッサ・コアにＯＩを束縛することは、ホストＯＳ／ＶＭＭにより、そのプロセッサ・コアに束縛された何れかのワークロードに対して不当にペナルティを課すことになる。
【００２３】
システム性能に対する影響が最小のプロセッサ・コア上で実行する。システム性能は、ホストＯＳ／ＶＭＭスループット、電力消費、及びＣ状態ウェイク・レーテンシの混合である。ＯＩＲＭは、前述のベクトルのうちの何れかに沿ったシステム性能に悪影響を及ぼさないためにＯＩＥＥを実行するためのプロセッサ・コア選択についての最適な決定に至るようＰＣＵからのヒューリスティックスに依存し得る。
【００２４】
図２は、一実施例による、一状態から別の状態への遷移をもたらすトリガ及び４つの状態を示す状態遷移図である。更に、上記要件に基づいて、プロセッサ・コアの例証された状態遷移を表し得る。プロセッサ・コアは、一部の実施例によれば、以下のモードのうちの１つにおいて存在し得る。一実施例では、前述のモード間のプロセッサ・コアの遷移はＯＩＲＭ１２４によって制御される。
【００２５】
ホストＯＳ／ＶＭＭ ホストＯＳ／ＶＭＭコンテナ１２０は、プロセッサ上で実行しており、アクティブである。
【００２６】
ＯＩ プロセッサ・コアはＯＩコンテナ１２２のうちの１つを実行している。
【００２７】
ＳＭＭ（システム管理モード） プロセッサ・コアはＳＭＭコンテナ１２３を実行している。ＳＭＭ状態には何れの状態からも入ることができる。
【００２８】
アイドル ホストＯＳ／ＶＭＭ、及びＯＩＥＥがＣ−ｘ状態に入っている。ＯＩＲＭは、ホストＯＳ／ＶＭＭによって要求されるＣ状態にプロセッサ・コアを遷移させる。
【００２９】
以下の表１は、原因及び図２に示す各遷移に関する更なる情報を提供する。
【００３０】
【表１】
更に、ＯＩＲＭ１２４は、プロセッサ・スレッド全ての上で実行するマイクロコード・モジュールとして実現し得る。ＯＩＲＭインスタンスのうちの１つは、何れかの特定の時点においてプロセッサ・コアのうちの１つの上で実行するためにＯＩＥＥをアクティブにスケジューリングし得る。プロセッサ・コア上で実行するためにＯＩＥＥをアクティブにスケジューリングするＯＩＲＭインスタンスは、「アクティブ」ＯＩＲＭインスタンスと呼ぶことができ、その他のインスタンスは、本明細書及び特許請求の範囲では「スタンバイ」ＯＩＲＭインスタンスと呼ぶことができる。一実施例では、システムにおけるＯＩＲＭのアクティブなインスタンスは１つだけ存在している。
【００３１】
一般に、マルチプロセッサ対応のオペレーティング・システムは、ロックを使用して、特定の動作のアトミック性を強化する。前述のロックを使用したクリティカル・セクション・コードは、ロックを保持しているプロセッサ・コア上でＯＩコンテナを実行するための強制排除によって拡張し得る。よって、他のロック・コンテンダは、ホストＯＳ／ＶＭＭの実行のためにプロセッサ・コアが戻されるまでスピンし得る。したがって、スピンロック獲得をかなり拡張し得る。プロセッサ・コア上のＯＩＥＥのスケジューリングは、スピンロック上の他のプロセッサ・コアの前述の望ましくないスピンにつながらないはずである。本明細書及び特許請求の範囲記載のアーキテクチャによって実現される以下の方法は、前述のロックアップを避ける（又は、前述のロックアップの可能性を少なくとも削減する）。
【００３２】
（１）ドライバ支援スケジューリング ＯＩ動作／命令を実行するためにオペレーティング・システムからプロセッサ・コアを取り去ることには、前述の障害はない時間間隔を宣言する機会をオペレーティング・システムに許す。例えば、（例えば、ホストＯＳ／ＶＭＭ１２０において備えられる）ドライバはこの判定を支援し得る。これは、ＯＩＲＭが、ＯＩ動作／命令をスケジューリングするための必要性を示すために（例えば、割り込みを使用して）ホストＯＳ／ＶＭＭにおけるＯＩドライバに通知する動作の通常モードであり得る。ドライバは（例えば、スケジューリングされたことに応じて）ＯＩＲＭに通知する。この通知は、そのプロセッサ・コア上でＯＩをスケジューリングするためにＯＩＲＭによる「歩留り」表示として使用することができる。ＯＩＲＭは、ＯＩがそのサイクル割り当てを消費するか、又は割り込み／ＩＰＩ（プロセッサ間割り込み）がホストＯＳ／ＶＭＭに配信される必要がある状態になるまでそのプロセッサ・コア上でＯＩが実行することを可能にする。この手法は、基本的に、ＯＩ実行時間がドライバ実行時間として説明されることにつながり、更に、この手法により、高優先度ロック同期化関連の問題が避けられる。
【００３３】
（２）自律スケジューリング しかし、一部の状態では、上記手法（１）は、ＯＩスケジューリングの場合、完全に依存可能な訳でない。それは、（ａ）ホストＯＳ／ＶＭＭが非動作状態にあり得、（ｂ）ＯＩドライバがディセーブルされているか、又はインストールされていないことがあり得、かつ／又は（ｃ）ホストＯＳ／ＶＭＭ上の現在のワークロードは、ＯＩドライバがスケジューリングされることを妨げ得る。ＯＩＲＭは枯渇からＯＩＥＥを保護する必要があり、特定の構成された最小実行時間を与えるので、ＯＩＲＭは、ホストＯＳ／ＶＭＭにおける前述の異常状態に対して保護するためにガード・タイマを使用し得る。ガード・タイマは、ＯＩドライバに対する割り込みの形式での通知がホストＯＳ／ＶＭＭに配信されると、起動し得る。ＯＩドライバが、このガード時間内にＯＩに、構成された最小実行時間を割り当てるのに十分長くスケジューリングされなかった場合、ＯＩＲＭは、ＯＩＥＥに対して行われた最小実行時間保証を満たすために動作のプリエンプティブ・モードにシフトし得る。ＯＩＲＭは、更に、ホスト ＯＳ／ＶＭＭが強制排除される持続時間が決定論的であり、閾値上限に制限されることを確実にし得る。
【００３４】
一部の実施例によれば、以下のパラメータは、ホストＯＳ／ＶＭＭとＯＩとの間の実行時間の時間共有を調節し得る。
【００３５】
１． ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌ ＯＩＥＥとホストＯＳ／ＶＭＭとの間の時間共有が実施されるアカウンティング・インターバル。例えば、ＯＩＥＥが、プロセッサ・コア上のサイクルの３％を使用するよう構成され、ＯＩアカウンティング・インターバルが１００ｍｓに設定された場合、ＯＩＥＥは、何れの特定の１００ｍｓ間隔においても、３ｍｓ超の間、実行しない。ＯＩドライバに対する割り込みは、各アカウンティング・インターバルの開始時に供給し得る。
【００３６】
２． ＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの割合としてＯＩに対して保証し得る最小プロセッサ実行時間。最小シェアは、何れの特定のアカウンティング・インターバルにおいてＯＩに利用可能になる。しかし、レーテンシの保証はなく、最小シェアは、１つ又は複数のランにおけるアカウンティング・インターバル全体にわたって分散させ得る。
【００３７】
３． ＯＩ−Ｎｏｒｍａｌ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−ＩｎｔｅｒｖａｌのパーセンテージとしてのＯＩに割り当てられたプロセッサ時間の通常のシェア。通常のシェアはＯＩに対して保証されないことがあり得る。
【００３８】
４． ＯＩ−Ｍａｘｉｍｕｍ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−ＩｎｔｅｒｖａｌのパーセンテージとしてのＯＩによって使用され得るプロセッサ時間の最大シェア。これは、ＯＩに利用可能なプロセッサ・シェアであり（例えば、ＯＳ独立ＯＩＲＭによって示される修復モードに入る場合）、実現形態に応じてＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの最高１００％になり得る。
【００３９】
５． ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍ ホストＯＳ／ＶＭＭを実行しているプロセッサ・コアが、ＯＩを実行するために強制排除される場合に、強制排除されない状態で実行し得る。
【００４０】
実行時間の現在のシェア（例えば、ＯＩ−Ｎｏｒｍａｌ−Ｓｈａｒｅ又はＯＩ−Ｍａｘｉｍｕｍ−Ｓｈａｒｅ）は、ＯＩ−Ｃｕｒｒｅｎｔ−Ｓｈａｒｅと呼ばれるパラメータを使用してＯＩＲＭによって追跡し得る。例えば、各アカウンティング・インターバルの開始時に、ＯＩＥＥは、プロセッサ・コア上の実行時間のそのＯＩ−Ｃｕｒｒｅｎｔ−Ｓｈａｒｅに等しい時間クレジットを受け取る。上記クレジットは、ＯＩＥＥがプロセッサ・コア上で実行した持続時間に等しい量で、ＯＩＥＥの各スケジュールに対して消費される。クレジットが枯渇すると、ＯＩＥＥは、クレジットが補充される次のアカウンティング・インターバルまで実行が妨げられる。
【００４１】
ドライバ支援スケジューリング手法（上記項目（１））は、ホストＯＳ／ＶＭＭにインストールされたＯＩドライバに依存し得る。ＯＩドライバは、ＯＩＲＭによるその初期化の一部としてＯＩＲＭに割り込みベクトルを登録し得る。ＯＩドライバは、ＯＩドライバからのイベントの通知を待つ無限ループに位置するＯＩワーカ・スレッドの生成ももたらし得る。ＯＩＲＭは、ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの開始をＯＩドライバに通知するために、このベクトルに対応するＩＳＲ（割り込みサービス・ルーチン）ハンドラを呼び出す旨の割り込みをホストＯＳ／ＶＭＭに導入し得る。
【００４２】
図３は、一実施例による、ＯＩＥＥ及びホストＯＳ／ＶＭＭの実行に関連付けられた種々の動作のブロック図を示す。図３に示すように、動作１では、ＯＩＲＭ１２４は割り込みをホストＯＳ／ＶＭＭ１２０に導入する。これは、（例えば、ＯＳ／ＶＭＭ区画１２０に記憶された）ＯＩドライバ３０２によって登録されたＩＳＲを呼び出し得る。動作２では、ＯＩドライバ３０２は（例えば、対応するＩＳＲを介して）ＯＩワーカ・スレッド３０３に通知する。一実施例では、スレッド３０３は、何れの特定のプロセッサ・コアにも結合していない。オペレーティング・システムは、適切な場合、スレッド３０３をスケジュールし得る。動作３では、スレッド３０３はＯＩＥＥ３０４をスケジューリングする旨をＯＩＲＭ１２４に要求するための命令を呼び出す。動作４では、ＯＩＲＭ１２４はホストＯＳ／ＶＭＭコンテナ１２０の現在の状態を保存し、ＯＩＥＥ３０４の保存された状態をロードする。動作５は、ホストＯＳ／ＶＭＭ１２０向けの割り込み／ＩＰＩの到着によってトリガされ得るか、又は、ＯＩＥＥ３０４のために構成された実行時間の現在のシェア（通常又は最大）の満了によってトリガされ得る。
【００４３】
ホストＯＳ／ＶＭＭ及びＯＩワーカ・スレッド３０３の観点から、ＩＯ命令は基本的には、上記動作５が実行されると戻るブロッキング命令であり得る。動作５を実行する理由に応じて、ＯＩＲＭ１２４は、ワーカ・スレッド３０３に以下の戻り値のうちの１つを戻し得る：
ＢＬＯＣＫ この戻された値は、ＯＩに対する時間割り当てが消費されたので、動作５が実行されたことを示す。これにより、基本的には、スレッド３０３を戻らせ、スレッド３０３に、ＯＩドライバからの次のイベント通知を待たせ得る。
【００４４】
ＣＯＮＴＩＮＵＥ この戻り値は、動作５が実行された（例えば、外部割り込み／ＩＰＩがホストＯＳ／ＶＭＭに到着することによってＯＩが強制排除された）旨を示す。このアカウンティング・インターバル内のＯＩに対する時間割り当ては未だ消費されていないことがあり得る。動作５を実行させた割り込みはＯＩを強制排除し得る。ホストＯＳ／ＶＭＭは、ＩＳＲ処理（及び、場合によっては他の保留中の高優先度タスクの実行）を完了すると、ＯＩワーカ・スレッド３０３を再スケジューリングする。あるいは、ホストＯＳ／ＶＭＭは、到着している割り込みを処理する間に、スレッド３０３を別のプロセッサ・コアに移動させ得る。再開すると、ワーカ・スレッド３０３は、戻り値を検査し得、戻り値がＣＯＮＴＩＮＵＥの場合、ＯＩ実行を再開するための動作３を実行する。
【００４５】
図４は、実施例によるタイムチャートを示す。２つのアカウンティング・インターバルを図４に示す。（図４の左側から始まる）第１のアカウンティング・インターバルでは、ＯＩは、４０２でＯＩドライバ・スレッド３０３がＯＩ−ＲＥＡＤを呼び出すことによってスケジューリングされる。しかし、ＯＩは、４０４におけるホストＯＳ／ＶＭＭによって割り込まれる。ＯＩは再度、後に、４０６で、アカウンティング・インターバル内でスケジューリングされ、４０８でその割り当てられた時間の実行を完了する。（４１０で始まる）第２のアカウンティング・インターバルでは、４１２でその割り当てられた時間の間の実行を完了するまでＯＩは割り込まれない状態で実行する。
【００４６】
一部の場合には、ＯＩワーカ・スレッド３０３の実行を阻止又はブロックすることにより、ＯＩに対して、偶然に、又は不当に、完全なサービス妨害を行う可能性が存在し得る。ガード・タイマ及び関連付けられたホストＯＳ／ＶＭＭ強制排除（後述する）は、ＯＩに対して行われる最小実行時間保証をＯＩＲＭが達成することを可能にする。
【００４７】
特に、ＯＩワーカ・スレッド３０３のスケジューリングを要求するための割り込みが導入されると、ＯＩＲＭはガード・タイマを起動させる。このタイマの持続時間は、一実施例におけるアカウンティング・インターバルの５０％に設定し得る。他の持続時間も設定し得る。ＯＩが、その最小の構成された時間のシェアの消費を実行する機会を十分得た場合、ＯＲＩＭはそのアカウンティング・インターバルのガード・タイマをオフにする。更なる実行の機会は、よって、保証されないことがあり得る。このガード・タイマが満了すると、ＯＩが、その構成された最小時間シェアを実行する機会を有していなかった場合、ＯＩに対して、その構成された最小の時間シェアを消費する機会を十分提供した状態になるまで、ＯＩＲＭはプリエンプティブ・スケジューリング・モードに入る。ＯＩを実行するためのプリエンプティブ・スケジューリングを行う場合、ホストＯＳ／ＶＭＭ割り込みはブロックされ得る。しかし、ＯＩＲＭは、ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍになるよう、割り込まれない状態でＯＩが実行する最大持続時間を制御し得る。
【００４８】
一実施例では、以下の動作は、ガード・タイマ満了時のＯＩＲＭ処理を説明しており、ここで、ＯＩＲＭは、周期性Ｐのタイマを起動させ、ここで、Ｐは、
Ｐ＝（ＯＩ＿Ａｃｃｏｕｎｔｉｎｇ＿Ｉｎｔｅｒｖａｌ／２）／（ＯＩ＿Ｍｉｎｉｍｕｍ＿Ｓｈａｒｅ／ＯＩ＿Ｓｃｈｅｄｕｌｉｎｇ＿Ｑｕａｎｔｕｍ）
で定められる。
【００４９】
各インターバルが満了すると、以下の動作が行われる：（ａ）ホストＯＳ／ＶＭＭを強制排除し、ホストＯＳ／ＶＭＭが強制排除されたプロセッサ・コア上の実行のためにＯＩをスケジューリングし、（ｂ）ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍ後にＯＩが満了する強制排除時間を構成し、（ｃ）ＯＩ強制排除タイマが満了すると、ホストＯＳ／ＶＭＭを再開する。
【００５０】
図５及び図８は、一部の実施例によるタイムチャートを示す。特に、図５は、ガード・タイマ満了前に消費されたＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅを示す。ここで、２つのアカウンティング・インターバルを示す。第１のアカウンティング・インターバルでは、ＯＩは、ガード時間の満了前にその最小シェアを既に消費している。しかし、ホストＯＳ／ＶＭＭは、更に実行するための機会をＯＩに対して与えることは決してない。第２のインターバルでは、同様な状態が起こる。しかし、ホストＯＳ／ＶＭＭは、ＯＩが、ＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅ超を実行することを可能にする。
【００５１】
図６では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、その最小の構成された時間シェアの間、実行する機会を有する状態になるまでＯＩにおけるＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。図７では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、ＯＩにおいてＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。しかし、前述の数カンタム後、ＯＳ内のドライバは、アクティブになり、ＯＩのスケジューリングを要求する旨のＯＩ−ＲＥＡＤを呼び出す、更に、ＯＩ−ＲＥＡＤは、構成された最小の時間の消費に十分長くＯＩが実行すること、及びＯＩ停止を実行するためのホストＯＳ／ＶＭＭの強制排除につながる。図８では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、ＯＩにおいてＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。しかし、前述の数カンタム後、ＯＳ内のドライバは、アクティブになり、ＯＩのスケジューリングを要求する旨のＯＩ−ＲＥＡＤを呼び出す（しかし、ＯＩは、構成された最小時間を消費するのに十分長く実行される訳でない）。これは、構成された最小時間がＯＩにおいて実行されるまでプリエンプティブ・スケジューリングをＯＩＲＭに続けさせる。
【００５２】
一実施例では、ホストＯＳ／ＶＭＭにおけるＯＩドライバの有無の処理に関し、ドライバ支援スケジューリング機構は、オペレーティング・システムにインストールされている前述のドライバが存在している場合に起動し得る。しかし、ＯＩスケジューリングは、存在しているドライバに依存しないことがあり得る。よって、ドライバがインストールされ、機能している場合、スケジューリングはＯＳフレンドリな態様で機能する。ドライバがインストールされていないか、若しくはアンロードされていないか、又は、オペレーティング・システム自体がインストールされていないか、又はオペレーティング・システムが作動状態にない場合、ＯＩＲＭは、上述のガード時間がゼロであったかのように実行し得る。スケジューリングのプリエンプティブ・モードは、構成された最小の実行時間をＯＩＥＥが受け取った状態になるまで、用い得る。ＯＩＥＥ時間スライスにおけるホストＯＳ／ＶＭＭの到着は、同様に、構成された最小時間の間、ＯＩＥＥが実行すると、ホストＯＳ／ＶＭＭを実行させるようＯＩＥＥを強制排除させ得る。
【００５３】
一部の実施例では、ＯＳの可視性を、ＯＩモードにおいて消費されたサイクルに与え得る。前述の機能は、ＯＩがイネーブルされたプラットフォーム上の何らかの異常な挙動を理解するためのデバッグ用ツールにも有用であり得る。ＯＩモードにおいて消費されたサイクルへの可視性は、コア毎ＭＳＲ（モデル特有レジスタ）の対、ＯＩ＿ＣＹＣＬＥ＿ＬＯＷ（サイクル・カウントの低位３２ビットを含む）及びＯＩ＿ＣＹＣＬＥ＿ＨＩＧＨ（カウンタの高位３２ビットを含む）（オペレーティング・システム及び／又は性能監視ツールによって読み出し得る）によって利用可能にされ得る。ＯＩＲＭは、その初期化手続の一部としてコア毎に前述のカウンタを０にリセットし得る。ＯＩの実行毎に、ＯＩ内部で費やされた時間（ＳＭＭ又はホストＯＳ／ＶＭＭ内で費やされる時間は考慮に入れない）は前述のカウンタによって更新し得る。
【００５４】
図９は、一実施例による、ホップする対象の次のコアを判定するためのフロー図を示す。例えば、スケジューリングのドライバ支援モードが設けられると、ＯＩＲＭは、ＯＩＥＥの実行のためにプロセッサ・コアを選択する旨をホストＯＳ／ＶＭＭに要求し得る。ＯＩドライバに対する割り込みが、ＯＩスケジューリングを要求するよう発信されると、オペレーティング・システムは、プロセッサ・コア上でＯＩワーカ・スレッド３０３をスケジューリングすると、この選択を行い得る。ワーカ・スレッド３０３がスケジューリングされるプロセッサ・コアは、ＯＩＥＥをスケジューリングするために使用し得る。ホストＯＳ／ＶＭＭが応答しない（例えば、ガード・タイマが満了したか、又は、ホストＯＳ／ＶＭＭがＯＩドライバをインストールさせなかった）モ―ドでは、ＯＩＲＭはプロセッサ・コア選択を自律的に行い得る。
【００５５】
一般に、プロセッサ・コア（又はハードウェア・スレッド）は、プロセッサ命令をアクティブに実行する場合、Ｃ０状態にあると言える。この状態では、システム構成部分（例えば、プロセッサ、バス、キャッシュ、メモリ等）は全て、電源オンにされ、使用されている。しかし、プロセッサ・コアは、命令を実行していない場合、次第に、システムの別々の部分の電源をオフにするか、又はシステムの別々の部分を低電力モードに入れ得るＣ１、Ｃ２、Ｃ３等の状態に移され得る。前述の電力節減状態は一般に、Ｃ−ｘ状態として表す。
【００５６】
一部の実施例によれば、ＯＩＲＭは、システム内のプロセッサ・コア全てにわたってロードを分散させ得る。これは、特定のプロセッサ・コア上で実行しているソフトウェアにペナルティを課すこと（例えば、ＶＭＭにより、物理プロセッサ・コアに束縛された仮想マシン）を減らすか、又は避け得る。プロセッサ・コア・ホッピング規則は、ＯＩＲＭの現在のアクティブなインスタンスによって行われ、プロセッサ・コア・ホッピング・アルゴリズムの結果に応じて、アクティブな役割をスタンバイ・インスタンスのうちの１つにハンドオフし得る。ＯＩは、パッケージ内のプロセッサ・コアのうちの１つの上で何れの特定の時点においても実行し得る。ＯＩＲＭは、ＯＩを実行するために使用する対象のプロセッサ・コアについての決定を行い得る。ホストＯＳ／ＶＭＭは、１つ又は複数のプロセッサ・コアをＣ−ｘ状態に入れ得る。実行するプロセッサ・コアを判定するためにＯＩＲＭによって使用されるロジックは、プロセッサ・コアにＣ−ｘ状態が常駐していること、及びプロセッサ・コアの現在のＣ−ｘ状態を考慮に入れ得る。
【００５７】
一実施例では、ＯＩＲＭは、ＯＩを実行するためにＣ−ｘプロセッサ・コアをウェイクするか、又はＣ０プロセッサ・コアからサイクルをとるかを決定し得る。ここでのトレードオフは、電力対性能である。ＯＩを実行するためにＣ−ｘプロセッサ・コアをウェイクしても、（大半の場合）ホストＯＳ／ＶＭＭの性能に影響を及ぼさないことがあり得る。アクティブな場合、プロセッサ・コアからサイクルはとられないからである。しかし、Ｃ−ｘプロセッサ・コアをウェイクすることにより、電力利用率が増加する。考慮に入れるべき別の要因は、電力／熱エンベロープにおける変動により、Ｃ−ｘプロセッサ・コアがウェイクされた場合に、Ｃ０プロセッサ・コアの性能を低下させ得るダイナミック・スロットリングである。ＯＩＲＭは、この判定を支援するためにヒューリスティックスを求めてＣＰＰＭ／ＰＣＵを照会し得る。第２の考慮点は、Ｃ−ｘ状態からのウェイクのレーテンシについてホストＯＳ／ＶＭＭに対して行われる「保証」である。各Ｃ状態は、Ｃ０状態にウェイクするためのレーテンシと関連付けられる。ホストＯＳ／ＶＭＭにより、Ｃ−ｘ状態に入れられたプロセッサ・コアが、ＯＩを実行するために選択されると、そのプロセッサ・コアの状態はＣ０に移る。ここで、（プロセッサ・コアがＯＩを実行していた際に）ウェーキング・イベント（例えば、割り込み）がホストＯＳ／ＶＭＭに対して生じた場合、ＯＩＲＭは、ホストＯＳ／ＶＭＭに制御を戻すようＯＩを強制排除し得る。ＯＩからホストＯＳ／ＶＭＭへの切り換えの実行において生じるレーテンシは、ホストＯＳ／ＶＭＭが要求したＣ状態からの保証されたウェイク・レーテンシを超えないことがあり得る。一部の実施例では、以下の規則は、前述の場合においてプロセッサ・コア選択を行うためにＯＩＲＭによって使用される。
【００５８】
図９を参照すれば、Ｃ状態（ここで指しているＣ状態は、ホストＯＳ／ＶＭＭによって認識され、要求された通りのＣ状態である）において、規則を適用し得る（９０２）。サイクルをこっそり取ることにより、ホストＯＳ／ＶＭＭの性能に影響を及ぼすことを避けるために、ＯＩＲＭは、アイドル状態（例えば、ホストＯＳ／ＶＭＭの観点からの、Ｃ−ｘ状態）にあり、ホストＯＳ／ＶＭＭによって使用されていないプロセッサ・コア上でＯＩＥＥを実行し得る。ＯＩＥＥを実行するためにＣ−ｘプロセッサ・コアをウェイクすることはしかし、電力／熱ベースの自律的なスロットリングをトリガさせるという悪い副作用を及ぼし、Ｃ０プロセッサ・コア上のホストＯＳ／ＶＭＭ性能が悪影響を受けることにつながり得る。（例えば、９０２における）ＯＩＲＭは、ＯＩを実行するようＣ０プロセッサ・コアを強制排除することと、Ｃ−ｘプロセッサ・コアを使用することとに関係するトレードオフを求めるようＰＣＵ９０４からのヒューリスティクスを利用し得る。同様に、プラットフォーム上の電力の影響は、Ｃ０状態にあるプロセッサ・コアを使用する場合よりも、スリーピング・プロセッサ・コアをウェイクする場合のほうが大きい。しかし、ＯＩを実行するためにプロセッサ・コアをウェイクすることによる電力消費のわずかな増加は、プラットフォームが、バッテリ電源９０６で動作している場合に対して、ＡＣ電力で動作している場合に許容可能であり得る。
【００５９】
図９に示すように、Ｃ状態の規則９０２の適用は、（Ｃ−ｘプロセッサ・コア及びＣ０プロセッサ・コアを含み得る）フィルタリングされたコア・リスト９１０を生成するために、現在のコアのリスト９０８、ＰＣＵヒューリスティクス９０４、及び／又はプラットフォーム電源９０６を考慮に入れ得る。動作９１２では、コアがＣ−ｘ状態にないと判定された場合、ＯＩＲＭは、ロードを分散させるためにＣ０プロセッサ・コア９１４のうちでコア・ホッピング規則９２０（例えば、ラウンド・ロビン選択）を行い得る。Ｃ−ｘプロセッサ・コアが存在している場合、ＯＩＲＭは、リスト９１６からＣ−ｘプロセッサ・コアを選択し、（９１８において最低Ｃ状態におけるコアを選択するなどの）更なるホッピングを行わないことがあり得る。一実施例では、ＯＩＲＭは、選択されたプロセッサ・コアが、なお、実行するのに最良のプロセッサ・コアであることを確実にするためにＣ状態の規則９０２を実行することにより、条件を周期的に再評価し得る。
【００６０】
よって、図９に示す実施例によるプロセッサ・コア選択は、以下の動作を含み得る。まず、ＯＩが実行し得るプロセッサ・コア・リスト９０８を使用し、Ｃ状態の規則９０２を適用して、フィルタリングされたプロセッサ・コア・リスト９１０を生成する、Ｃ状態の規則に対する入力としてプラットフォーム電源９０６及びＰＣＵヒューリスティクス９０４を使用する。フィルタリングされたプロセッサ・コア・リスト９１０にＣ−ｘ状態におけるプロセッサ・コアが存在している場合、最低Ｃ−ｘ状態９１８におけるプロセッサ・コアを、ホップする先の、次のプロセッサ・コアとして選ぶ。Ｃ−ｘ状態におけるプロセッサ・コアが存在しない場合、Ｃ−０プロセッサ・コア９１４のリストのうちから（例えば、ラウンド・ロビン・ホップを行うために）プロセッサ・コア・ホッピング規則９２０を呼び出す。このことは、一部の実施例には、前述のプロセッサ・コア上でＯＩＲＭのアクティブ／スタンバイの役割を切り換えることが関係し得る。
【００６１】
図１０は、一実施例による、ＯＩ区画に導入し、ＯＩに割り当てられたデバイスから生じる割り込みを処理するために使用される種々の構成部分のブロック図を示す。図示したように、ハードウェア装置は、ＬＡＰＩＣ（局所高度プログラマブル割り込みコントローラ）１００６及び１００８を、それぞれが有する複数のプロセッサ・コア１００２及び１００４を含み得る。ＬＡＰＩＣはそれぞれ、（外部割り込み１０１２を受け取る）割り込み再マッピング装置１０１０と通信し合う。
【００６２】
割り込み再マッピング装置１０１０は、（ａ）第２の割り込み再マップ・テーブル（ＩＲＴ）１０２０をＯＩ ＩＲＴエントリ（ＩＲＴＥ）で登録すること、（ｂ）ＯＩデバイス・フィルタ１０２２（例えば、ＰＣＩリクエスタＩＤ毎の１ビット（８ＫＢ）を有する）を登録すること、及び／又は、（ｃ）後述する（例えば、図１１に灰色の箱で示す。図１１は、一実施例による、ＯＩ関連の割り込みの処理に関連付けられた動作のフロー図を示す）割り込み再マップ・ロジックに対する修正に対するサポートを含み得る。例えば、割り込み１１０２を受け取った後、ポスティングされた割り込みが、割り込みＴＬＢ（変換ルックアサイド・バッファ）１１０４になかった場合、割り込みがポスティングされているかを判定し得（１１０６）、肯定の場合、ルックアップ１１０８を、ＰＣＩリクエスタＩＤを使用してデバイス・フィルタ１０２２において行い得る。否定の場合、割り込みが処理される（１１０９）。対応するビットがデバイス・フィルタ１０２２にセットされた場合、ＯＩ ＩＲＴ１１１０を、対応するラベルを探すために使用し得、さもなければ、ＯＳ／ＶＭＭ
ＩＲＴをルックアップ１１１２に使用し得る。動作１１１０及び１１１２の後、割り込み記述子に対するベクトルを１１１４でポスティングし得る。
【００６３】
更に、一実施例では、割り込み記述子は、割り込みをどこにポスティングするかを割り込み再マップ装置が判定することを助力する２つの項目（すなわち、割り込むためのＡＰＩＣ ＩＤ， 及び通知割り込みとして使用するためのベクトル）を有し得る。更に、一部の実施例では、ＯＩに対する要件の１つは、ＯＩに対する割り込みの配信が、主ＯＳからの何れの動作によっても影響を受けないということである。このことは、割り込み記述子内のベクトルを、コアに対する配信のために上記記述子にプログラムされた局所ＡＰＩＣに配信するポスティングされた割り込み方法が、割り込み再マップ装置が、新たなマイクロコード・イベント通知を使用してＯＩＲＭにＣＰＵマイクロコードを通知するように修正される。特に、割り込み再マップ装置からマイクロコード・イベント通知を受け取ると、ＯＩ区画は、何れのプロセッサ・コア上でもその時点で実行していないことがあり得るので、ＯＩＲＭは、ポスティングされた割り込みをＯＩ区画に直ちに導入する訳でないことがあり得る。よって、ＯＩＲＭは、後述するメモリ構造（例えば、ＯＩＰＩＣ（ＯＩプログラマブル割り込みコントローラ）に、受け取られた割り込みをキューイングし、ＯＩ ＩＤＴ（割り込み記述子テーブル）を使用した標準ｘ８６割り込み配信機構を使用してスケジューリングされる都度、ＯＩ区画に割り込みを導入する。
【００６４】
図１２は、一実施例による、ＯＩＰＩＣモジュールと通信し合う種々の構成部分を示す。図示した通り、ＯＩＰＩＣモジュール１２０２は、考えられる２つのソース（すなわち、（１）（例えば、割り込み再マッピング装置によって通知され、ＯＩ割り込みバッファにポスティングされる）ＯＩＥＥ１２０４に割り当てられたデバイスからの割り込み、又は（２）電力管理イベント、ＯＩ間通信通知、ＯＩＥＥタイマに対するＯＩＲＭ導入割り込み等（併せて１２０６として表す））からＯＩＥＥへの配信のためにベクトルを受け取る。
【００６５】
ＯＩＰＩＣモジュール１２０２は、ＯＩＥＥに配信するためのベクトルをキューイングするために３つのレジスタをモデリングし得る。（１）ＯＩ ＩＲＲ（割り込み要求レジスタ）１２０８（例えば、内部ソース又は外部ソースから到着するベクトルは全て、この２５６ビット・レジスタに入る） （２）ＯＩ ＩＳＲ（ＯＩインサービス・レジスタ）１２０８（例えば、ＯＩ ＩＲＲからの最高優先度ベクトルは、ＯＩ ＩＳＲに既にあるベクトルよりも優先度が高い場合、ＯＩ ＩＳＲに入れられる。これは、ＯＩＥＥによって現在処理されている割り込みベクトルを追跡する２５６ビット・レジスタであり得る。ＯＩ ＩＳＲに既にある現在の割り込みベクトルはそのままである。例えば、最高優先度割り込みが低優先度割り込みに割り込みをかけたことを示す）及び／又は（３）ＯＩ ＥＯＩ（割り込みの終了）１２１２（例えば、ここで、ＯＩＥＥ ＩＳＲは、ＯＩ ＩＳＲにおいて現在マーキングされている最高優先度ベクトルの処理の完了を通知する）。
【００６６】
一部の実施例では、プロセッサ・コア上で実行するためにＯＩ区画が（例えば、スケジューラ１２１４によって）スケジューリングされると、動作（すなわち、（１）ＯＩ ＩＲＲにおいて保留中のベクトルが存在していない場合、動作は必要でなく、（２）ＯＩ ＩＲＲから最高優先度ベクトルを取得し、ＯＩ ＩＳＲにおける最高ベクトルと比較し（ＯＩ ＩＲＲベクトルがＯＩ ＩＳＲベクトルよりも低い場合、動作は必要でなく）、（３）ＯＩＥＥが割り込み可能な場合、ＯＩ ＩＳＲにおいてＯＩ ＩＲＲから受け取られた最高ベクトルに対応するビットをセットし（一実施例においては、OI IRRからそのベクトルをクリアし）、かつ／又は、（４）ＯＩＥＥに導入する対象のベクトルとしてＯＩ ＩＳＲにおいて保留中の最高ベクトルを戻す）がＯＩＰＩＣモジュール１２０２によって行われる。割り込みに応じて、ＯＩＥＥにおける割り込みコントローラ・ドライバはＯＩＥＯＩレジスタ１２１２に対する書き込みを使用して完了を通知する。ＯＩＥＥからＯＩＥＯＩを受け取ると、ＯＩＰＩＣ１２０２は、ＯＩ ＩＳＲ１２１０において保留中の最高優先度ベクトルに対応するビットをクリアする。次いで、次の再開時にＯＩＥＥに導入することが可能な何れかの他のベクトルが存在しているかを判定する。
【００６７】
図１０乃至１２を参照して説明したように、ホストＯＳ／ＶＭＭによって使用し得る割り込みベクトルに対する制約を加えないホストＯＳ／ＶＭＭに対する非侵入的な手法が提供される。同様に、前述の実施例は、ホストＯＳ／ＶＭＭからＬＡＰＩＣ／ＩＯＡＰＩＣへの何れのアクセスも遮断せず、前述のデバイスの何れも仮想化しようとしない。このことにより、別々の区画に割り込みを誘導し、前述の機能を有しない他の実現形態と比較すると、前述の機能を更に相当好適かつスケーラブルにするという機構が可能になる。
【００６８】
一部の実施例では、ホストＯＳ／ＶＭＭ区画とＯＩ区画との間のメモリの分離をもたらすために、ＯＩＲＭは、ＯＩメモリ区画に対する、ホストＯＳ／ＶＭＭによって発生したアクセスをブロックするか否かを判定するためにハードウェア・レンジ・レジスタの１つ又は複数のビットを利用し得る。同様に、ホストＯＳ／ＶＭＭメモリ区画に対するＯＩ区画からのアクセスを制御するために、ＯＩＲＭは、ＯＩ区画下の拡張ページ・テーブル（ＥＰＴ）などのページ・テーブルを作成し得る。例えば、上記ＯＩ区画は、起動前認証、メディア・トランスコーディング、電子商取引等のような、セキュリティに気を配る必要がある特定の作業を行うために使用し得る。前述の動作が行われると、ＯＩ区画は、鍵及びパスワードのような秘密を有し得る。同様に、ホストＯＳ／ＶＭＭプロセッサ・ベースのアクセスを使用して、又は、ＤＭＡバスマスタ・デバイスを使用して前述の秘密を盗むための、ＯＩメモリに対するソフトウェア・ベースの攻撃は、レンジ・レジスタ及びＤＭＡデバイス・フィルタを使用してブロックされる。
【００６９】
一部の実施例では、２つのタイプの保護（すなわち、（１）保存データに対する保護、又は（２）使用中のデータに対する保護）を提供し得る。揮発性メモリ内又は不揮発性メモリ内にある場合の保存データの保護は、攻撃者に対して価値がないように上記データを暗号化することを必要とする。このために、ＯＩは、処理する必要がある場合にデータを復号し、同時に、処理している際に盗むことができないようにデータを保護するためのやり方を必要とする。
【００７０】
保存データを保護することは、ＣＢＣ（暗号ブロック連鎖）、ＣＴＲ（カウンタ・モード）等などの、何れかのモードにおける暗号を使用する高度暗号化標準（ＡＥＳ）（２５６ビット又は他のバージョン）のような暗号化アルゴリズムを使用してデータを暗号化し得るということを示唆している。暗号化するための鍵も保護する必要がある。一実施例では、その秘密を保護する必要がある各アプリケーションは、その秘密の暗号化のためのそれ自身の鍵を有する。ＯＩＲＭは、コア又は非コアにおけるプロセッサ・ヒューズを使用してこの鍵を保護するためのｂｌｏｂサービスを提供し得る。ｂｌｏｂ鍵動作の場合、ユーザは、そのデータを保護するために使用したい鍵を生成し、それに対してｂｌｏｂを行うようＯＩＲＭに要求する。更に、以下に更に説明するように、一部の実施例は、処理における、ユーザによって生成された鍵の保護に助力し得る。
【００７１】
一実施例によれば、以下の擬似コードは、鍵ｂｌｏｂを生成するためにユーザによって使用し得る。
【００７２】
１． ａｐｐｌｉｃａｔｉｏｎ＿ｋｅｙ＿ｇｅｎｅｒａｔｉｏｎ＿ｆｕｎｃｔｉｏｎ（）
２． ｛
３． ｃｈａｒ＊ｋｅｙ＿ｂｕｆｆｅｒ＝ｍａｌｌｏｃ（４０９６）
４． ｇｅｎｅｒａｔｅ＿ｋｅｙ（ｋｅｙ＿ｂｕｆｆｅｒ）
５． ｂｌｏｂ＿ｋｅｙ（ｋｅｙ ｂｕｆｆｅｒ）
６． ｝
上記擬似コードの行４では、アプリケーションはｋｅｙ＿ｂｕｆｆｅｒ内に鍵を生成し、行５では、アプリケーションは、鍵ｂｌｏｂを生成するために（例えば、ＯＩＲＭによって提供される）ｂｌｏｂサービスを呼び出す。ＯＩＲＭｂｌｏｂサービスは、このｂｌｏｂサービスに使用されるプロセッサ鍵１１３を使用して鍵バッファ内の鍵を暗号化し得る。よって、アプリケーションは、その秘密を保護するために使用し得るプラットフォームに結合されたセキュアな鍵を有する。アプリケーションは、上記行４において生成した元の鍵を保持しなくてよい。鍵ｂｌｏｂが、データに対して処理するために今後必要な全てである。
【００７３】
一部の実施例では、実行時にデータを保護するために、データは、システム・メモリ内で決して平文でないことがあり得る。これは、ＯＩ秘密を一時的に記憶するためにオンパッケージ・メモリ１１１の一ページの使用によって達成し得る。一実施例では、オンパッケージ・メモリ１１１は、このメモリの内容が、バス・アナライザ及び「フリーズ・キャン」攻撃を使用してアクセス可能でないことを可能にする。すなわち、メモリ１１１に記憶された、暗号化されていない情報は、プロセッサ１０２−１の外では利用可能でないことがあり得る。一実施例では、ＯＩＲＭは、セキュアなメモリ・アクセスを可能にするための命令（すなわち、（１）Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ メモリ・バッファからのデータをセキュアなメモリに移し、アプリケーションによる使用のために復号する。（２）Ｓｔｏｒｅ Ｋｅｙ Ｐａｇｅ セキュアなメモリからのデータをメモリ・バッファに移し、セキュアなメモリをクリアする。）をユーザに提供する。
【００７４】
一実施例では、鍵ページ・ロード動作は２つの入力（すなわち、（ａ）鍵ページの暗号化のために使用されるｂｌｏｂが行われた鍵、及び（ｂ）（鍵ページとして表される）暗号化データを保持するバッファの物理アドレス）を用いる。Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ動作が呼び出されると、ＯＩＲＭは、（１）物理アドレスによって指し示されたページの内容をオンパッケージ・メモリ１１１に複製し、（２）プロセッサ・ヒューズ鍵を使用して鍵ｂｌｏｂを復号し、（３）オンパッケージ・メモリ１１１内のデータを、復号された鍵を使用して復号し、（４）オンパッケージ・メモリ１１１に対する前述の動作に転送される物理アドレスに対するアクセスを再指示するようＯＩのＥＰＴを更新し、かつ／又は、（５）アプリケーションは次いで、秘密にアクセスするために標準ソフトウェア構成を使用し得るという動作を行う。
【００７５】
図１３及び図１４は、一部の実施例による、ロード鍵の利用に関連付けられた動作のブロック図を示す。図１３では、ロード鍵は、（例えば、暗号化された）物理メモリをセキュアなメモリに変え、出願人の鍵を使用してデータを復号する。図１４では、ＯＩ ＥＰＴは、物理メモリをセキュアなメモリに転換するよう再マッピングし得る。
【００７６】
一部の実施例では、単一の鍵ページのみを何れかの時点でロードし得る。先行してロードされたページに対してＳｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅを行うことなくＬｏａｄ＿Ｋｅｙ＿Ｐａｇｅを行おうとすると、障害が発生し得る。ＯＩＥＥカーネルからの鍵ページ管理は、アプリケーションに対してロード／記憶サービスを提供するＯＩカーネル・モジュールに依存し得る。カーネル・モジュールは、処理／タスク・スイッチが通知されるようＯＩカーネル・スケジューラに関わり、Ｌｏａｄ／Ｓｔｏｒｅ Ｋｅｙ Ｐａｇｅを使用して、ＯＩにおいて実行しているアプリケーションに基づいて鍵・ページを変え得る。
【００７７】
一実施例では、鍵ページ記憶動作は２つの入力（すなわち、（ａ）鍵ページの暗号化のために使用される、ｂｌｏｂが行われた鍵、及び（ｂ）（鍵ページとして表される）暗号化データを記憶するためのバッファの物理アドレス）を用いる。ＯＩＲＭは、（１）プロセッサ・ヒューズ鍵を使用して鍵ｂｌｏｂを復号し、（２）復号されたｂｌｏｂ鍵を使用してオンパッケージ・メモリ１１１の内容を暗号化し、かつ／又は（３）オンパッケージ・メモリ１１１の内容を、アプリケーションによって転送されたメモリ・ページに複製するという動作を行う。
【００７８】
図１５及び図１６は、一部の実施例による、記憶鍵の利用に関連付けられた動作のブロック図を示す。図１５では、記憶鍵は、セキュアなメモリ（例えば、平文）を物理メモリに変え、出願人の鍵を使用することにより、データを暗号化する。図１６では、ＯＩ ＥＰＴは、物理メモリの転換を元に戻すよう再マッピングし得る。
【００７９】
一実施例では、以下の擬似コードは、上述のＬｏａｄ＿Ｋｅｙ＿Ｐａｇｅ及びＳｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅに使用し得る。
【００８０】
Ｄｏ＿ｓｅｃｒｅｔ＿ｗｏｒｋ＿ｅｘａｍｐｌｅ＿ｆｕｎｃｔｉｏｎ（ｕｉｎｔ６４＿ｔ ｋｅｙ ｂｌｏｂ ＰＡ， ｕｉｎｔ６４＿ｔ ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）
｛
Ｃｈａｒ ＊ｓｅｃｒｅｔ＿ｐａｇｅ＿ｌａ＝ｍａｐ＿ｓｅｃｒｅｔ＿ｐａｇｅ（ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ（ｋｅｙ＿ｂｌｏｂ＿ＰＡ，ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
Ｄｏ＿ｓｅｃｒｅｔ＿ｗｏｒｋ（ｓｅｃｒｅｔ＿ｐａｇｅ＿ｌａ）；
Ｓｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅ（ｋｅｙ＿ｂｌｏｂ＿ＰＡ，ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
｝
上記コードでは、「ｌａ」が線形を表し、「ＰＡ」は物理アドレスを表す。よって、一実施例は、（例えば、ソフトウェア・ベースの攻撃又はコールド・ブートのようなハードウェアベースの攻撃からＯＩメモリ内の秘密を保護することにより、）ＯＩにおける、セキュリティ感応性データを処理するためのタンパリング耐性メモリを提供する。これは、この機能なしの実現形態と比較して、上記機能をかなり好適に、かつ／又はスケーラブルにする。
【００８１】
一部の実施例では、ホストＯＳ／ＶＭＭとＯＩＥＥとの間のメモリの分離をもたらすために、ＯＩＲＭは、ＯＩメモリに対する、ホストＯＳ／ＶＭＭによって発生したアクセスをブロックするハードウェア・レンジ・レジスタを利用する。同様に、ＯＩ区画からホストＯＳ／ＶＭＭメモリへのアクセスを制御するために、ＯＩＲＭは、ＯＩ区画下の拡張ページ・テーブル（ＥＰＴ）などのページ・テ―ブルを作成する。
【００８２】
システムが停止する（Ｓ３）と、システム・メモリは自己リフレッシュ状態に入る。しかし、ＣＰＵが電源オフにされ、よって、メモリ上でアクティブな保護は存在していない。よって、システムがＳ３状態に入っている場合、敵対者はメモリの内容を修正することができ得、メモリが、再開時に検証されない場合（Ｓ０）、これは、ＯＩに対するコード導入攻撃につながり得る。前述のコード導入攻撃を避けるための一手法は、Ｓ３に入る前にメモリをハッシングし、Ｓ３からＳ０に再開する際に内容を検証する。しかし、この手法は一部の場合には２つの欠点を有し得る。（１）メモリの内容をハッシングするために行うべき更なる作業が理由で、Ｓ０からＳ３への遷移に必要な時間の量を増やし、（２）上記内容を検証するためにメモリをハッシングするために行うべき更なる作業が理由でＳ３からＳ０への遷移に必要な時間の量を増やす。
【００８３】
上述の通り、Ｓ３へのシステムの遷移は、ＣＰＵの電源がオフになり、メモリが自己リフレッシュ・モードに入ることをもたらす。この時点では、レンジ・レジスタと同様にアクティブなメモリ上の保護は存在せず、デバイス・フィルタは動作状態にない。Ｓ３上で保持されるメモリ・イメージは、システムがＳ０状態に戻ると実行される。しかし、このメモリのインテグリティはこの場合、疑わしく、自己リフレッシュ・イメージに、不当なコードが導入されているか、あるいは、メモリが、不注意に、特定の形式で損なわれているか、あるいはタンパリングされていることがあり得る。この目的で、一実施例は、Ｓ３の再開時にメモリのインテグリティを検証する。ＯＩＲＭ１２４は例えば、実行することを可能にする前に、自己リフレッシュにおけるメモリ・イメージのインテグリティを測定し得る。上述の通り、このインテグリティ検証の一手法は、Ｓ０からＳ３への遷移の際のＯＩメモリの測定を記録し、Ｓ３からＳ０への遷移の際のイメージを検証することである。Ｓ３の再開に続く前にインテグリティ検証を行うのに大量の時間をＯＩＲＭが費やす必要があるので、この手法は再開のレーテンシを増加させ得る。（２ＬＭ（二レベルのメモリ）を有するシステム上でより顕著になる）前述の手法の不意の副作用は、測定するためにＮＶ（不揮発性）メモリからＤＲＡＭページ・キャッシュにメモリ・ページをフェッチするオーバヘッドである。Ｓ３再開パスは、「即時ＯＮ」モードのような使用の場合の遅延を最小にするために最適化しなければならず、Ｓ３からの再開は、システムをＳ３に戻す前に同期化活動を行うための短い期間の間に行い得る。
【００８４】
一実施例では、再開時間を最小にするために、インテグリティ検査値（ＩＣＶ）は、ページ単位でＯＩＥＥイメージについて計算し得るので、Ｓ３からの再開の際には、ＩＣＶを検証するための時間は最小にされ得る。この場合、検証はＯＩＥＥコードとしてページ単位で行い得、Ｓ３の再開後にデータにアクセスされるからである。図１７を参照すれば、一実施例による、Ｓ０とＳ３との間のセキュアな遷移に関連付けられた動作のブロック図を示す。ＯＩＥＥページ１７０２のページ単位のインテグリティ検査値は、（例えば、ＯＩＲＭ１２４により、）ＩＣＶアレイ１７０４に記録し得る。ＩＣＶアレイの各要素はＯＩメモリ内の一ページに対応し、（１）インテグリティ検査値（ＩＣＶ） 構成されたようなＳＨＡＳＨＡ２５６、ＳＨＡ５１２等のような一方向の暗号ハッシュ・アルゴリズムを使用して生成されたページの一方向暗号ハッシュ、（２）ＩＣＶ有効（図１７に「Ｖ」として示す）、正／誤、及び／又は（３）（図１７に「Ｄ」として示す）ＤＭＡ（直接メモリ・アクセス）ページ、正／誤。ＯＩＲＭは、ＩＣＶアレイのインテグリティを検証するためにＩＣＶアレイに関する（例えば、メモリ１１４にも）ＳＨＡハッシュを保持し得る、という情報を有する。Ｓ０からＳ３状態への遷移を行うと、ＯＩＲＭは、Ｓ３からの再開の際に検証し得るようにＩＣＶアレイのハッシュに署名し得る。
【００８５】
一部の実施例では、ＯＩＲＭは、ＯＩページ１７０２を（例えば、周期的に）ハッシングするためにバックグラウンド・タスク１７０６を使用し得る。ＯＩに対する各遷移の前に、メモリ内のページの固定の組をハッシングするためにバックグラウンド・タスク１７０６を呼び出し得る。例えば、ＯＩイメージのサイズが６４ＭＢである場合、インテグリティ保護するためのページが１６３８４存在している。バックグラウンド・タスクは、ラウンド・ロビンで１６Ｋページを実行し、各ランにおいて１６ページのハッシュを行い得る。よって、バックグラウンド・タスクは、ＯＩＥＥに割り当てられる１６Ｋページ全てのハッシュを行うために１Ｋ回、呼び出す必要がある。一実施例では、ページをハッシングするために要する時間は、ＯＩに帰され、実行クレジットから減算される。
【００８６】
ページのハッシュが記されると、ＯＩＲＭは、再ハッシュを必要としている修正を検知するために前述のページに対する書き込みを追跡し得る。ＯＩＲＭは、ＯＩ ＥＰＴを使用して書き込み追跡を行い得る。ページがハッシングされ、ハッシュがＩＣＶアレイ１７０４において記されると、これは、ＥＰＴにおいてリードオンリとしてマーキングされ、ＩＣＶは、ＩＣＶアレイにおいて有効であるとしてマーキングされる。ＯＩＥＥからのページへの書き込みは、ＯＩＲＭがページＩＣＶを無効であるとしてマーキングし、もう一度書き込み可能であるとしてページを作ることにつながるＥＰＴフォールトをもたらし得る。ページはこの場合、バックグラウンド・ハッシング・タスクがこのページまでもう一度至ると再ハッシングし得、ハッシュが記された後、リードオンリとして再マーキングされる。更に、ＤＭＡ動作を使用したページに対する書き込みは、ＥＰＴ障害を使用して追跡されないことがあり得る。ＤＭＡページに対する書き込みを追跡するために、ＯＩＲＭは、ＤＭＡに対するページをデバイスに送出する前にＯＩＲＭに通知するためにＯＩＥＥカーネルに依存し得る。ＯＩＲＭは、前述のページをＤＭＡページとしてＩＣＶアレイに記し、そのバックグラウンド・タスクの一部として前述のページに対するＩＣＶ検査を何ら行わないことがあり得る。
【００８７】
Ｓ０からＳ３への遷移の場合、上記遷移がＳ３遷移の場合に、ＯＩＲＭはＩＣＶページ・アレイを走査し得、無効のＩＣＶを記録させたページ、及びＤＭＡページのＩＣＶ値を記す。ＤＭＡページとしてマーキングされたページの場合、そのハッシュの記録に加えて、ＯＩＲＭは、ＤＭＡページとしてのそのステータスをクリアし得る。ＯＩＲＭは次いで、ＩＣＶアレイ自体にわたってハッシュを行う。ＩＣＶアレイのハッシュは、パッケージ内のプロセッサ鍵１１３から導き出されたＯＩＲＭ ＩＣＶ署名鍵を使用して署名し得る。ＩＣＶアレイの署名されたハッシュは、そのタンパリングをＯＩＲＭによって検出することが可能であるので、システム・メモリに残し得る。
【００８８】
Ｓ３再開の場合、ＢＩＯＳ（基本ＩＯシステム）は、ＯＩイメージを再開するようＯＩＲＭに通知し得る。ＯＩＲＭは、ＯＩのコンテナを作成し、次いで、ＯＩメモリ内に有効なＩＣＶアレイが存在しているかを判定する。一実施例では、ＩＣＶアレイの有効性は、ＩＣＶアレイのハッシュ上の署名を検証し、Ｓ０乃至Ｓ３の遷移上に記憶された値に対してＩＣＶアレイのハッシュを検査することによって判定される。
【００８９】
ＩＣＶアレイのインテグリティが損なわれていなかった場合、ＯＩＲＭはＯＩ初期化を通常のリセット・パスとして続け得る（例えば、メモリ内のイメージが廃棄され、フレッシュ・ロード・コードのロードが行われる）。ＩＣＶアレイのインテグリティが損なわれていなかった場合、ＯＩＲＭは、ＯＩ ＥＰＴに存在していないとしてＯＩＥＥのページを全てマーキングし、制御をＯＩＥＥに移し得る。ＯＩＥＥが実行を始めるにつれ、コード及びデータ・ページのアクセスは、ＯＩＲＭに誘導されたＥＰＴ障害を発生させる。ＩＣＶアレイ内のページに対して有効なＩＣＶが存在している場合、ＯＩＲＭは、障害ページ上のＩＣＶを計算し、ページのインテグリティを検証するためにＩＣＶアレイにおけるＩＣＶに対してこれをマッチングさせる。このページは次いで、（例えば、ページに対する変更を追跡するために）リードオンリ・ページとしてＯＩ ＥＰＴにマッピングし得る。よって、プロセッサによって生成されたＥＰＴ、及びＩＯＲＭを使用した増分ハッシングは、例えば、ハイパバイザにおいて現在行われていることと比較して、主要な相違点である。更に、一実施例は、自己リフレッシュを出ると、ＯＩメモリのインテグリティを効率的に検証する非常に重要な機構を加える。これは、この機能なしの実現形態と比較して、上記機能をかなり好適に、かつ／又はスケーラブルにする。
【００９０】
図１８は、本発明の実施例による計算システム１８００のブロック図を示す。計算システム１８００は、相互接続ネットワーク（又はバス）１８０４を介して通信する１つ若しくは複数の中央処理装置（ＣＰＵ）１８０２又はプロセッサを含み得る。プロセッサ１８０２は、汎用プロセッサ、（コンピュータ・ネットワーク１８０３を介して通信されるデータを処理する）ネットワーク・プロセッサ、（縮小命令セット・コンピュータ（ＲＩＳＣ）プロセッサ又は高度命令セット・コンピュータ（ＣＩＳＣ）プロセッサを含む）他のタイプのプロセッサを含み得る。更に、プロセッサ１８０２は、単一又は複数のコア・デザインを有し得る。複数のコア・デザインを有するプロセッサ１８０２は、同じ集積回路（ＩＣ）ダイ上に各種プロセッサ・コアを一体化し得る。更に、複数のコア・デザインを有するプロセッサ１８０２は、対称又は非対称のマルチプロセッサとして実現し得る。一実施例では、プロセッサ１８０２のうちの１つ又は複数は、図１のプロセッサ１０２と同一又は同様であり得る。例えば、プロセッサ１８０２のうちの１つ又は複数は、例えばＯＩＲＭ１２４を含む、図１乃至１７を参照して記載したキャッシュ、記憶デバイス、及び／又はロジックのうちの１つ又は複数を含み得る。更に、図１乃至図１７を参照して説明した動作は、システム１８００の１つ又は複数の構成部分によって行い得る。
【００９１】
チップセット１８０６は、相互接続ネットワーク１８０４とも通信し得る。チップセット１８０６はメモリ制御ハブ（ＭＣＨ）１８０８を含み得る。ＭＣＨ１８０８は、（図１のメモリ１１４と同一又は同様であり得る）メモリ１８１２と通信するメモリ・コントローラ１８１０を含み得る。メモリ１８１２は、計算システム１８００に含まれるＣＰＵ１８０２又は何れかの他のデバイスによって実行し得る命令のシーケンスを含むデータを記憶し得る。本発明の一実施例では、メモリ１８１２は、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、又は他のタイプの記憶デバイスなどの１つ又は複数の揮発性記憶（又はメモリ）デバイスを含み得る。ハード・ディスクなどの不揮発性メモリも利用し得る。複数のＣＰＵ及び／又は複数のシステム・メモリなどの更なるデバイスは、相互接続ネットワーク１８０４を介して通信し得る。
【００９２】
ＭＣＨ１８０８は、ディスプレイ・デバイス１８１６と通信するグラフィクス・インタフェース１８１４も含み得る。本発明の一実施例では、グラフィクス・インタフェース１８１４は、アクセラレーテッド・グラフィクス・ポート（ＡＧＰ）を介してディスプレイ・デバイス１８１６と通信し得る。本発明の一実施例では、（フラット・パネル・ディスプレイなどの）ディスプレイ１８１６は、例えば、ディスプレイ１８１６によって解釈され、表示されるディスプレイ信号にビデオ・メモリ又はシステム・メモリなどの記憶デバイスに記憶されたイメージのディジタル表現を変換する信号変換器を介してグラフィクス・インタフェース１８１４と通信し得る。ディスプレイ・デバイスによって生成されるディスプレイ信号は、ディスプレイ１８１６によって解釈され、その後、ディスプレイ１８１６上に表示される前に種々の制御デバイスを通り得る。
【００９３】
ハブ・インタフェース１８１８は、ＭＣＨ１８０８及び入出力制御ハブ（ＩＣＨ）１８２０が通信することを可能にし得る。ＩＣＨ１８２０は、計算システム１８００と通信するＩ／Ｏデバイスに対するインタフェースを提供し得る。ＩＣＨ１８２０は、周辺装置相互接続（ＰＣＩ）ブリッジ、ユニバーサル・シリアル・バス（ＵＳＢ）コントローラや他のタイプの周辺装置ブリッジ又はコントローラなどの周辺装置ブリッジ（又はコントローラ）１８２４を介してバス１８２２と通信し得る。ブリッジ１８２４は、ＣＰＵ１８０２と周辺装置との間のデータ・パスを提供し得る。他のタイプのトポロジも利用し得る。更に、複数のバスは、例えば、複数のブリッジ又はコントローラを介して、ＩＣＨ１８２０と通信し得る。更に、ＩＣＨ１８２０と通信し合う他の周辺装置は、本発明の種々の実施例において、集積ドライブ・エレクトロニクス（ＩＤＥ）又は小型コンピュータ・システム・インタフェース（ＳＣＳＩ）ハード・ドライブ、ＵＳＢポート、キーボード、マウス、パラレル・ポート、シリアル・ポ―ト、フロッピー（登録商標）ディスク・ドライブ、ディジタル出力サポート（例えば、ディジタル・ビデオ・インタフェース（ＤＶＩ））、又は他のデバイスを含み得る。
【００９４】
バス１８２２は、オーディオ・デバイス１８２６、１つ又は複数のディスク・ドライブ１８２８、及び（コンピュータ・ネットワーク１８０３と通信し合う）ネットワーク・インタフェース・デバイス１８３０と通信し得る。他のデバイスは、バス１８２２を介して通信し得る。更に（ネットワーク・インタフェース・デバイス１８３０などの）種々の構成部分が、本発明の一部の実施例においてＭＣＨ１８０８と通信し得る。更に、（限定列挙でないが、ＭＣＨ１８０８、ＭＣＨ１８０８の１つ又は複数の構成部分等を含む）図１８に示すプロセッサ１８０２及び他の構成部分は、単一のチップを形成するよう組み合わせることができる。更に、グラフィクス・アクセラレータは、本発明の他の実施例においてＭＣＨ１８０８内に含まれ得る。
【００９５】
更に、計算システム１８００は、揮発性及び／又は不揮発性のメモリ（又は記憶装置）を含み得る。例えば、不揮発性メモリは、リードオンリ・メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能なＰＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＰＲＯＭ（ＥＥＰＲＯＭ）、ディスク・ドライブ（例えば、１８２８）、フロッピー（登録商標）・ディスク、コンパクト・ディスクＲＯＭ（ＣＤ−ＲＯＭ）、ディジタル多用途ディスク（ＤＶＤ）、フラッシュ・メモリ、光磁気ディスク、又は、電子データ（例えば、命令を含む）を記憶することができる不揮発性のマシン読み出し可能な他のタイプの媒体のうちの１つ又は複数を含み得る。
【００９６】
図１９は、本発明の実施例による、ポイントツーポイント（ＰｔＰ）構成に配置された計算システム１９００を示す。特に、図１９は、いくつかのポイントツーポイント・インタフェースによってプロセッサ、メモリ及び入出力デバイスが相互接続されたシステムを示す。図１乃至１８を参照して説明した動作は、システム１９００の１つ又は複数の構成部分によって行い得る。
【００９７】
図１９に示すように、システム１９００はいくつかのプロセッサ（明瞭にするために、このうちの２つ、すなわち、プロセッサ１９０２及び１９０４のみを示す）を含み得る。プロセッサ１９０２及び１９０４はそれぞれ、メモリ１９１０及び１９１２との通信を可能にするための局所メモリ・コントローラ・ハブ（ＭＣＨ）１９０６及び１９０８を含み得る。メモリ１９１０及び／又は１９１２は、図１８のメモリ１８１２を参照して説明したものなどの種々のデータを記憶し得る。
【００９８】
一実施例では、プロセッサ１９０２及び１９０４は、（例えば、図１乃至図１８を参照して説明したキャッシュのうちの１つ又は複数を含む、）図１８を参照して説明したプロセッサ１８０２のうちの１つであり得る。プロセッサ１９０２及び１９０４は、ＰｔＰインタフェース回路１９１６及び１９１８それぞれを使用してポイントツーポイント（ＰｔＰ）インタフェース１９１４を介してデータを交換し得る。更に、プロセッサ１９０２及び１９０４はそれぞれ、ポイントツーポイント・インタフェース回路１９２６、１９２８、１９３０及び１９３２を使用して個々のＰｔＰインタフェース１９２２及び１９２４を介してチップセット１９２０とデータを交換し得る。チップセット１９２０は、例えば、ＰｔＰインタフェース回路１９３７を使用して、グラフィクス・インタフェース１９３６を介してグラフィクス回路１９３４とデータを交換し得る。
【００９９】
本発明の少なくとも１つの実施例は、プロセッサ１９０２及び１９０４内に提供し得る。例えば、図１のコア１０６のうちの１つ又は複数は、プロセッサ１９０２及び１９０４内に配置され得る。更に、プロセッサ１９０２及び１９０４は、図１乃至図１８を参照して説明したキャッシュ、記憶デバイス、及び／又はロジックの１つ又は複数を含み得る。例えば、ＯＩＲＭ１２４は、プロセッサ１９０２／１９０４内に提供し得る。しかし、ＯＩＲＭは、図１乃至図１８を参照して説明したような、（例えば、チップセット１９２０におけるプロセッサ１９０２／１９０４とＭＣＨ１９０６／１９０８との間の）他の場所で提供し得る。しかし、本発明の他の実施例は、図１９のシステム１９００内の他の回路、ロジック装置、又はデバイスに存在し得る。更に、本発明の他の実施例は、図１９に示すいくつかの回路、ロジック装置、又はデバイスにわたって分散させ得る。
【０１００】
チップセット１９２０はＰｔＰインタフェース回路１９４１を使用してバス１９４０と通信し得る。バス１９４０は、バス・ブリッジ１９４２やＩ／Ｏデバイス１９４３などの１つ又は複数のデバイスと通信し得る。バス１９４４を介して、バス・ブリッジ１９４２は、（コンピュータ・ネットワーク１８０３と通信し得るモデム、ネットワーク・インタフェース・デバイス、又は他の通信デバイスなどの）通信デバイス１９４６、キーボード／マウス１９４５、オーディオＩ／Ｏデバイス１９４７、及び／又はデータ記憶デバイス１９４８などの他のデバイスと通信し得る。データ記憶デバイス１９４８は、プロセッサ１９０２及び／又は１９０４によって実行し得るコード１９４９を記憶し得る。
【０１０１】
本発明の種々の実施例では、例えば、図１乃至図１９を参照して、本明細書及び特許請求の範囲に記載された動作は、ハードウェア（例えば、論理回路）、ソフトウェア、ファームウェア、又はそれらの組み合わせ（例えば、本明細書及び特許請求の範囲記載の処理を実行するようコンピュータをプログラムするために使用される命令（又はソフトウェア手続）を記憶させたマシン読み取り可能な媒体又はコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム・プロダクトとして提供し得る）であり得る。マシン読み取り可能な媒体は、本明細書及び特許請求の範囲記載のものなどの記憶デバイスを含み得る。更に、前述の有形のコンピュータ読み取り可能な媒体はコンピュータ・プログラム・プロダクトとしてダウンロード可能であり得、プログラムは、通信リンク（例えば、バス、モデム、又はネットワーク接続）を介した伝搬媒体におけるデータ信号により、要求側のコンピュータ（例えば、クライアント）に遠隔コンピュータ（例えば、サーバ）から転送し得る。
【０１０２】
「一実施例」、「実施例」、又は「一部の実施例」に、明細書中で言及していることは、実施例に関して説明する特定の構成、構造又は特性が少なくとも一実現形態に含まれ得るということを意味している。明細書中の種々の箇所において「一実施例における」という句が存在することは、全てが、同じ実施例を表していてもよく、表していなくてもよい。
【０１０３】
更に、本明細書及び特許請求の範囲では、「結合」、「接続」、及びその派生形を使用し得る。本発明の一部の実施例では、「接続」は、２つ以上の構成要素が、互いに直接、物理的に又は電気的に接触しているということを示すために使用し得る。「結合」は、２つ以上の構成要素が直接、物理的又は電気的に接触しているということを意味し得る。しかし、「結合」は、２つ以上の構成要素が互いに直接接触している訳でないが、互いになお協調又は相互作用し得るということも意味し得る。
【０１０４】
よって、本発明の実施例は、構造的な構成及び／又は方法論的な動作に特有の文言で説明してきたが、請求された主題は、上述の特定の構成又は動作に限定されないことがあり得る。むしろ、上記特定の構成及び動作は、請求された主題を実現するサンプル形式として開示している。
【技術分野】
【０００１】
本明細書及び特許請求の範囲は、一般に、エレクトロニクスの分野に関する。特に、本発明の実施例は、セキュアな埋込みコンテナの実行のためのプロセッサの拡張に関する。
【背景技術】
【０００２】
コンピュータ・システムは、例えば、ハードウェア・レイヤ、ファームウェア及びオペレーティング・システム・レイヤ、並びにアプリケーション・プログラム・レイヤを含むレイヤ化されたデバイスとして実現し得る。コンピュータ・システムのハードウェア・レイヤは、物理プラットフォームとして表し得る。物理プラットフォームは、プロセッサ、チップセット、通信チャネル、メモリ、基板、及びシステムを含み得る。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
コンピュータ・システムは、マネージャビリティ・エンジン（例えば、コンピュータ・システムが（例えば、通信ネットワーク上で、遠隔管理コンソールを介して遠隔に）管理されることを可能にするための専用のマイクロコントローラを含む）も含み得る。しかし、マネージャビリティ・サービスのための専用のマイクロコントローラの提供は、制限されたＭＩＰＳ（毎秒百万命令）、放熱、電力消費、サイズ、コストを含む理由のために、一部の実現形態において、適切でないか、実用的でないか、又は、さもなければ、スケーラブルでないことがあり得る。
【課題を解決するための手段】
【０００４】
本発明の詳細な説明を、添付図面を参照して記載する。図中、参照符号の最も左の桁は、参照符号が最初に存在する図を識別する。別々の図において同じ参照符号を使用していることは、同様又は同一の項目を示している。
【図面の簡単な説明】
【０００５】
【図１】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【図２】一実施例による、一状態から別の状態への遷移をもたらすトリガ及び４つの状態を示す状態遷移図である。
【図３】一実施例による、別々のメモリ区画の実行に関連付けられた種々の動作を示すブロック図である。
【図４】一部の実施例によるタイムチャートである。
【図５】一部の実施例によるタイムチャートである。
【図６】一部の実施例によるタイムチャートである。
【図７】一部の実施例によるタイムチャートである。
【図８】一部の実施例によるタイムチャートである。
【図９】本発明の一部の実施例によるフロー図である。
【図１０】一実施例による、ＯＩ区画に導入し、ＯＩに割り当てられた装置から生じる割り込みを処理するために使用される種々の構成部分を示すブロック図である。
【図１１】本発明の一部の実施例によるフロー図である。込みを処理するために使用される種々の構成部分を示すブロック図である。
【図１２】一実施例による、ＯＩＰＩＣモジュールと通信し合う種々の構成部分を示す図である。
【図１３】一部の実施例による、ロード鍵の利用に関連付けられた動作を示すブロック図である。
【図１４】一部の実施例による、ロード鍵の利用に関連付けられた動作を示すブロック図である。
【図１５】一部の実施例による、記憶鍵の利用に関連付けられた動作を示すブロック図である。
【図１６】一部の実施例による、記憶鍵の利用に関連付けられた動作を示すブロック図である。
【図１７】一実施例による、Ｓ０とＳ３との間のセキュアな遷移に関連付けられた動作を示すブロック図である。
【図１８】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【図１９】本明細書及び特許請求の範囲記載に種々の実施例を実現するために利用し得るコンピュータ・システムの実施例を示すブロック図である。
【発明を実施するための形態】
【０００６】
以下の説明では、種々の実施例の徹底的な理解を得るために数多くの具体的な詳細を記載している。しかし、本発明の種々の実施例は、上記具体的な詳細なしで実施し得る。他の場合には、周知の方法、手順、構成部分、及び回路は、本発明の特定の実施例を分かりにくくすることがないように詳細に説明していない。更に、本発明の実施例の種々の局面は、半導体集積回路（「ハードウェア」）、１つ若しくは複数のプログラムに編成されたコンピュータ読み取り可能な命令（「ソフトウェア」）、又は、ハードウェア及びソフトウェアの特定の組み合わせなどの種々の手段を使用して行い得る。本明細書及び特許請求の範囲の目的では、「ロジック」への言及は、ハードウェア、ソフトウェア、又はそれらの特定の組み合わせを意味する。更に、本明細書及び特許請求の範囲の（「ｕｏｐ」としても表し得る）「マイクロオペレーション」又は「命令」の使用は、置き換え可能であり得る。更に、本明細書及び特許請求の範囲記載の実施例の一部は、論理０及び論理１として組、又は明確な値を表し得るが、前述の語は、例えば、実現形態に応じて、置き換え可能である。
【０００７】
一部のプロセッサは複数のプロセッサ・コアを含み得る。複数のコアに加えて、プロセッサ・ダイは、（コア以外の、プロセッサ・ダイ上の構成要素全てを併せて表し得る）非コアを含み得る。性能を向上させるために、一層多くの機能を、例えば、複数のチップセットを置き換えることにより、プロセッサの非コアに組み入れることができる。例えば、一部の実現形態は、メモリ・コントローラ機能、ＩＯ（入出力）コントローラ機能、及びグラフィクス機能を非コアに組み入れ得る。しかし、この傾向は、プラットフォーム上で供給される他の機能及びサービス（例えば、マネージャビリティ）に影響を及ぼす。現在、一部のマネージャビリティ機能は、マネージャビリティ・エンジン（ＭＥ）のコア部分を構成し得る専用プロセッサ上で提供し得る。ＭＥは一般に、チップセット上に配置される。更に、一部のサーバ・プラットフォームは、ベースボード管理コントローラ（ＢＭＣ）、サービス・プロセッサ（ＳＰ）と呼ばれるか、又は何れかの他の名称によって呼ばれる個別の専用マイクロコントローラを実現し得る。上述の通り、前述の解決策は、限定されたＭＩＰＳ、放熱、電力消費、サイズ、コスト等などの理由で、スケーラブルでない。このことは、超モバイル・パーソナル・コンピュータ（ＵＭＰＣ）環境において更に問題となり、別の解決策に対する必要性を強いる。
【０００８】
この目的で、本明細書及び特許請求の範囲記載の一部の実施例は、（例えば、マネージャビリティのために専用プロセッサ又はマイクロコントローラを利用することが不適切であるか、又は実用的でないＵＭＰＣ環境又はその他の環境のための）マネージャビリティ機能のためのスケーラブルな解決策を提供する。例えば、一実施例では、ＯＳ（オペレーティング・システム）又はＶＭＭ（仮想マシン・マネージャ）独立アーキテクチャ（併せて本明細書及び特許請求の範囲では「ＯＩ」として表す）は、ホストＯＳ／ＶＭＭとＯＩコンテナとの間の（プロセッサ・サイクル、メモリ、デバイスなど）のリソースを動的に区画化することにより、例えば、プロセッサ上に、１つ又は複数のコンテナを生成することが関係する。一実施例では、ＯＩリソース・マネージャ（ＯＩＲＭ）は、ホストＯＳ／ＶＭＭコンテナ（本明細書及び特許請求の範囲では区画とも表す）とＯＳ独立コンテナとの間のタイム・シェアリング動作を行い得る。その結果、一部の実施例は、ＯＳ／ＶＭＭ実行性能に影響を及ぼすことなく（又はＯＳ／ＶＭＭ実行性能に対する、低減された影響を伴って）、有用な目的（例えば、マネージャビリティ）のために、アイドル・プロセッサ・サイクルを使用することを可能にする。
【０００９】
一実施例では、ＯＩ区画の割り当てを導入し、ＯＩに割り当てられたデバイスから生じた割り込みを処理するための手法を開示している。一実施例では、タンパリング耐性メモリが、ＯＩにおけるセキュリティ感応性データを処理するために提供される。一実施例では、Ｓ３からＳ０への遷移及びＳ０からＳ３への遷移に費やすことが必要な期間の量が削減される。更に、本明細書及び特許請求の範囲記載の手法は、例えば、図１乃至図１９を参照して説明したものなどの種々の計算装置における性能、効率、及び／又はセキュリティの向上を可能にし得る。
【実施例】
【００１０】
より具体的には、図１は、本発明の実施例による計算システム１００のブロック図を示す。上記システム１００は、１つ又は複数のプロセッサ１０２−１乃至１０２−Ｎ（一般に、本明細書及び特許請求の範囲において「プロセッサ１０２」又は「プロセッサ１０２」として表す）を含み得る。プロセッサ１０２は、相互接続ネットワーク又はバス１０４を介して通信し得る。各プロセッサは、種々の構成部分を含み、その一部は、明確にするためにプロセッサ１０２−１のみを参照して表している。よって、残りのプロセッサ１０２−２乃至１０２−Ｎはそれぞれ、プロセッサ１０２−１を参照して表す同一又は同様の構成部分を含み得る。
【００１１】
一実施例では、プロセッサ１０２−１は、（本明細書及び特許請求の範囲において「コア１０６」として、又はより概括的に「コア１０６」として表される）１つ又は複数のプロセッサ・コア１０６−１乃至１０６−８、共有キャッシュ１０８、及び／又はルータ１１０を含み得る。プロセッサ・コア１０６は単一の集積回路（ＩＣ）チップ上で実現し得る。更に、チップは、１つ若しくは複数の共有キャッシュ及び／又は占有キャッシュ（キャッシュ１０８など）、（バス若しくは相互接続ネットワーク１１２などの）バス又は相互接続、（図１８乃至図１９を参照して説明したものなどの）メモリ・コントローラ、又は他の構成部分を含み得る。
【００１２】
一実施例では、ルータ１１０は、システム１００及び／又はプロセッサ１０２−１の種々の構成部分間で通信するために使用し得る。更に、プロセッサ１０２−１は２つ以上のルータ１１０を含み得る。更に、多くのルータ１１０が、プロセッサ１０２−１の内部又は外部の種々の構成部分間のデータ・ルーティングを可能にするために通信し得る。一実施例では、プロセッサ１０２−１は、暗号動作における使用のためにＯＩＲＭ１２４にのみアクセス可能な埋め込まれた鍵１１３を有し得る。一実施例では、この鍵は、プロセッサの最初の電源投入時に、強い乱数発生器を使用してＯＩＲＭにより、プロセッサ上で生成し、記憶し得る。別の実施例では、この鍵は、製造時にプロセッサに記憶し得る。
【００１３】
共有キャッシュ１０８は、コア１０６などの、プロセッサ１０２−１の１つ又は複数の構成部分によって利用されるデータ（例えば、命令を含む）を記憶し得る。図に示すように、プロセッサ１０２は、オンプロセッサ（本明細書及び特許請求の範囲では「オンパッケージ」としても表す）メモリ１１１（更に後述するように、セキュアなメモリとして使用し得る）も含み得る。例えば、共有キャッシュ１０８は、プロセッサ１０２の構成部分による高速アクセスのために、メモリ１１４に記憶されたデータを局所にキャッシュし得る。一実施例では、キャッシュ１０８は、ミッドレベル・キャッシュ（レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）、又は他のレベルのキャッシュなど）、ラスト・レベル・キャッシュ（ＬＬＣ）、及び／又はそれらの組み合わせを含み得る。更に、プロセッサ１０２−１の種々の構成部分は、共有キャッシュ１０８と直接、バス（例えば、バス１１２）を介して、かつ／又はメモリ・コントローラ若しくはハブを介して通信し得る。図１に示すように、一部の実施例では、コア１０６の１つ又は複数は、（本明細書及び特許請求の範囲において概括的に「Ｌ１キャッシュ１１６」として表す）レベル１（Ｌ１）キャッシュ（１１６−１）及び／又はＬ２キャッシュ（図示せず）を含み得る。
【００１４】
図１に示すように、システム１００は、１つ又は複数の区画１２０又は１２２（本明細書及び特許請求の範囲では同義で「コンテナ」としても表す）を利用し得る。ＯＩリソース・マネージャ（ＯＩＲＭ）１２４を、通信するよう、物理レイヤ（例えば、プロセッサ・コア、チップセット、メモリ、記憶装置、ネットワーク・インタフェース等）、ホストＯＳ／ＶＭＭ、ＯＩコンテナ（又は区画）１２０及び１２２間に結合し得る。更に、２つ以上のＯＩコンテナを使用し得る。一部の実施例では、ＯＩＲＭ１２４は、プロセッサ上のファームウェア又はマイクロコードとして実現し得る。例えば、ＯＩＲＭ１２４は、プロセッサ・サイクルをスケジューリングする役割を果たすプロセッサ・マイクロコードであり得る。これは更に、（例えば、システム上で実行される複数の処理に対するシステム応答性又は公平性を維持するために）ＯＩ区画１２４によって実行されるプロセッサ命令とインタリーブされたプロセッサ命令を主ＯＳ／ＶＭＭ区画１２０が実行することを可能にし得る。
【００１５】
ホストＯＳ／ＶＭＭ区画１２０は、通常の（ホスト）アプリケーション及び／又はホスト・デバイス・ドライバ（図示せず）を含み得る。更に、ＯＩ区画１２２は、（例えば、選択されたデバイスに対する）ＯＩドライバ（図示せず）及び／又は、コア機能に対応するデータ、アプリケーションを含み得る。更に、一部の実施例では、ＯＩＲＭは、ＯＩＥＥ（ＯＩ実行環境（ＯＩ区画内の動作環境））にプロセッサ時間を割り当てる場合に満たすべき、以下の制約のうちの１つ又は複数を有し得る。
【００１６】
ホストＯＳ／ＶＭＭは割り込みを取り逃さず、又は時間ドリフトを被らず、ホストＯＳ／ＶＭＭ ＩＯデバイス（例えば、ＣＤＲＯＭ、ＬＡＮ、ＷＡＮ等）は、バッファのアンダーフロー又はオーバフローを避けるために処理される。このことは、ホストＯＳ／ＶＭＭ宛のプロセッサ間割り込み及び外部割り込みが、最小のレーテンシを伴って配信されるということを示唆している。
【００１７】
プロセッサ・コア上のＯＩＥＥのスケジューリングは、他のプロセッサのブロッキングにつながるものでない。ＯＩをスケジューリングするために選択されたプロセッサ・コア上のロックをオペレーティング・システムが保持している場合に、前述の状態が生じ得る。ＯＩを実行させるために前述のプロセッサ・コアを取り去ることにより、前述のロックを待っている他のプロセッサ・コアがスピンし、サイクルを浪費してしまう。プロセッサ・コア上の実行のためにＯＩをスケジューリングするアルゴリズムは、できる限り、前述の状態を避けるべきである。
【００１８】
プロセッサ・コア、デバイス、バス等の電力管理は、ホストＯＳ／ＶＭＭ １２０に干渉するというよりも、ＯＳと協調する。ＯＩＲＭ１２４には、システムの電力状態、熱状態、及び性能状態についての決定のスケジューリングの副作用が分かり得る。例えば、ＯＩをスケジューリングするために、（プロセッサＣ状態に関連付けられた）Ｃ−ｘプロセッサ・コアをＣ−０に至らせることにより、自動周波数スロットリングにつながる、システムの電力エンベロープの、閾値との交差をもたらし得る。よって、Ｃ−０プロセッサ・コアに対する性能の影響を避けるために行われるが、スケジューリングのためにＣ−ｘプロセッサ・コアを選択する動作は、厳しい性能ペナルティをもたらし得る。ＯＩＲＭ１２４は、（例えば、賢明な選択を行うためにＰＣＵ（電力制御装置）からの）非コア及びコアにおいて利用可能な適切な電力ヒューリスティックを利用し得る。ＰＣＵは、プロセッサ・コア及び非コア構成部分の電力管理方針を管理するためにプロセッサ非コアに備え得る。
【００１９】
オペレーティング・システム及び性能監視ツールは、ＯＩを実行するために特定のプロセッサ・コアから消費されたサイクルの数を検出する機会を与えるよう構成し得る。前述の観測機能を与えることは、それがＯＩによってもたらされたかを確かめるために、何れかの不測の挙動が観測された場合に、システムをデバッグすることに助力し得る。
【００２０】
一部の実施例では、ＯＩ実現形態は、ホストＯＳ／ＶＭＭの状態によって影響を受けない実行環境を提供することである。よって、ＯＩＲＭは一部の実施例では、以下の要件のうちの１つ又は複数を満たし得る。
【００２１】
構成されたように最小保証持続時間の間、ＯＩ動作／命令が実行することを確実にすることにより、ＯＩの枯渇を避けるか、又は減らす。
【００２２】
システム内の何れかの１つのプロセッサ・コアにＯＩ動作／命令を束縛することを避けるか、又は減らす。ＯＳ独立動作は、ホストＯＳ／ＶＭＭからサイクルをとり得る。一部のオペレーティング・システム及びＶＭＭは、スループット目標を達成するためにワークロード（例えば、スレッド、ＶＭ（仮想マシン）等）を束縛する。特定のプロセッサ・コアにＯＩを束縛することは、ホストＯＳ／ＶＭＭにより、そのプロセッサ・コアに束縛された何れかのワークロードに対して不当にペナルティを課すことになる。
【００２３】
システム性能に対する影響が最小のプロセッサ・コア上で実行する。システム性能は、ホストＯＳ／ＶＭＭスループット、電力消費、及びＣ状態ウェイク・レーテンシの混合である。ＯＩＲＭは、前述のベクトルのうちの何れかに沿ったシステム性能に悪影響を及ぼさないためにＯＩＥＥを実行するためのプロセッサ・コア選択についての最適な決定に至るようＰＣＵからのヒューリスティックスに依存し得る。
【００２４】
図２は、一実施例による、一状態から別の状態への遷移をもたらすトリガ及び４つの状態を示す状態遷移図である。更に、上記要件に基づいて、プロセッサ・コアの例証された状態遷移を表し得る。プロセッサ・コアは、一部の実施例によれば、以下のモードのうちの１つにおいて存在し得る。一実施例では、前述のモード間のプロセッサ・コアの遷移はＯＩＲＭ１２４によって制御される。
【００２５】
ホストＯＳ／ＶＭＭ ホストＯＳ／ＶＭＭコンテナ１２０は、プロセッサ上で実行しており、アクティブである。
【００２６】
ＯＩ プロセッサ・コアはＯＩコンテナ１２２のうちの１つを実行している。
【００２７】
ＳＭＭ（システム管理モード） プロセッサ・コアはＳＭＭコンテナ１２３を実行している。ＳＭＭ状態には何れの状態からも入ることができる。
【００２８】
アイドル ホストＯＳ／ＶＭＭ、及びＯＩＥＥがＣ−ｘ状態に入っている。ＯＩＲＭは、ホストＯＳ／ＶＭＭによって要求されるＣ状態にプロセッサ・コアを遷移させる。
【００２９】
以下の表１は、原因及び図２に示す各遷移に関する更なる情報を提供する。
【００３０】
【表１】
更に、ＯＩＲＭ１２４は、プロセッサ・スレッド全ての上で実行するマイクロコード・モジュールとして実現し得る。ＯＩＲＭインスタンスのうちの１つは、何れかの特定の時点においてプロセッサ・コアのうちの１つの上で実行するためにＯＩＥＥをアクティブにスケジューリングし得る。プロセッサ・コア上で実行するためにＯＩＥＥをアクティブにスケジューリングするＯＩＲＭインスタンスは、「アクティブ」ＯＩＲＭインスタンスと呼ぶことができ、その他のインスタンスは、本明細書及び特許請求の範囲では「スタンバイ」ＯＩＲＭインスタンスと呼ぶことができる。一実施例では、システムにおけるＯＩＲＭのアクティブなインスタンスは１つだけ存在している。
【００３１】
一般に、マルチプロセッサ対応のオペレーティング・システムは、ロックを使用して、特定の動作のアトミック性を強化する。前述のロックを使用したクリティカル・セクション・コードは、ロックを保持しているプロセッサ・コア上でＯＩコンテナを実行するための強制排除によって拡張し得る。よって、他のロック・コンテンダは、ホストＯＳ／ＶＭＭの実行のためにプロセッサ・コアが戻されるまでスピンし得る。したがって、スピンロック獲得をかなり拡張し得る。プロセッサ・コア上のＯＩＥＥのスケジューリングは、スピンロック上の他のプロセッサ・コアの前述の望ましくないスピンにつながらないはずである。本明細書及び特許請求の範囲記載のアーキテクチャによって実現される以下の方法は、前述のロックアップを避ける（又は、前述のロックアップの可能性を少なくとも削減する）。
【００３２】
（１）ドライバ支援スケジューリング ＯＩ動作／命令を実行するためにオペレーティング・システムからプロセッサ・コアを取り去ることには、前述の障害はない時間間隔を宣言する機会をオペレーティング・システムに許す。例えば、（例えば、ホストＯＳ／ＶＭＭ１２０において備えられる）ドライバはこの判定を支援し得る。これは、ＯＩＲＭが、ＯＩ動作／命令をスケジューリングするための必要性を示すために（例えば、割り込みを使用して）ホストＯＳ／ＶＭＭにおけるＯＩドライバに通知する動作の通常モードであり得る。ドライバは（例えば、スケジューリングされたことに応じて）ＯＩＲＭに通知する。この通知は、そのプロセッサ・コア上でＯＩをスケジューリングするためにＯＩＲＭによる「歩留り」表示として使用することができる。ＯＩＲＭは、ＯＩがそのサイクル割り当てを消費するか、又は割り込み／ＩＰＩ（プロセッサ間割り込み）がホストＯＳ／ＶＭＭに配信される必要がある状態になるまでそのプロセッサ・コア上でＯＩが実行することを可能にする。この手法は、基本的に、ＯＩ実行時間がドライバ実行時間として説明されることにつながり、更に、この手法により、高優先度ロック同期化関連の問題が避けられる。
【００３３】
（２）自律スケジューリング しかし、一部の状態では、上記手法（１）は、ＯＩスケジューリングの場合、完全に依存可能な訳でない。それは、（ａ）ホストＯＳ／ＶＭＭが非動作状態にあり得、（ｂ）ＯＩドライバがディセーブルされているか、又はインストールされていないことがあり得、かつ／又は（ｃ）ホストＯＳ／ＶＭＭ上の現在のワークロードは、ＯＩドライバがスケジューリングされることを妨げ得る。ＯＩＲＭは枯渇からＯＩＥＥを保護する必要があり、特定の構成された最小実行時間を与えるので、ＯＩＲＭは、ホストＯＳ／ＶＭＭにおける前述の異常状態に対して保護するためにガード・タイマを使用し得る。ガード・タイマは、ＯＩドライバに対する割り込みの形式での通知がホストＯＳ／ＶＭＭに配信されると、起動し得る。ＯＩドライバが、このガード時間内にＯＩに、構成された最小実行時間を割り当てるのに十分長くスケジューリングされなかった場合、ＯＩＲＭは、ＯＩＥＥに対して行われた最小実行時間保証を満たすために動作のプリエンプティブ・モードにシフトし得る。ＯＩＲＭは、更に、ホスト ＯＳ／ＶＭＭが強制排除される持続時間が決定論的であり、閾値上限に制限されることを確実にし得る。
【００３４】
一部の実施例によれば、以下のパラメータは、ホストＯＳ／ＶＭＭとＯＩとの間の実行時間の時間共有を調節し得る。
【００３５】
１． ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌ ＯＩＥＥとホストＯＳ／ＶＭＭとの間の時間共有が実施されるアカウンティング・インターバル。例えば、ＯＩＥＥが、プロセッサ・コア上のサイクルの３％を使用するよう構成され、ＯＩアカウンティング・インターバルが１００ｍｓに設定された場合、ＯＩＥＥは、何れの特定の１００ｍｓ間隔においても、３ｍｓ超の間、実行しない。ＯＩドライバに対する割り込みは、各アカウンティング・インターバルの開始時に供給し得る。
【００３６】
２． ＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの割合としてＯＩに対して保証し得る最小プロセッサ実行時間。最小シェアは、何れの特定のアカウンティング・インターバルにおいてＯＩに利用可能になる。しかし、レーテンシの保証はなく、最小シェアは、１つ又は複数のランにおけるアカウンティング・インターバル全体にわたって分散させ得る。
【００３７】
３． ＯＩ−Ｎｏｒｍａｌ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−ＩｎｔｅｒｖａｌのパーセンテージとしてのＯＩに割り当てられたプロセッサ時間の通常のシェア。通常のシェアはＯＩに対して保証されないことがあり得る。
【００３８】
４． ＯＩ−Ｍａｘｉｍｕｍ−Ｓｈａｒｅ ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−ＩｎｔｅｒｖａｌのパーセンテージとしてのＯＩによって使用され得るプロセッサ時間の最大シェア。これは、ＯＩに利用可能なプロセッサ・シェアであり（例えば、ＯＳ独立ＯＩＲＭによって示される修復モードに入る場合）、実現形態に応じてＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの最高１００％になり得る。
【００３９】
５． ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍ ホストＯＳ／ＶＭＭを実行しているプロセッサ・コアが、ＯＩを実行するために強制排除される場合に、強制排除されない状態で実行し得る。
【００４０】
実行時間の現在のシェア（例えば、ＯＩ−Ｎｏｒｍａｌ−Ｓｈａｒｅ又はＯＩ−Ｍａｘｉｍｕｍ−Ｓｈａｒｅ）は、ＯＩ−Ｃｕｒｒｅｎｔ−Ｓｈａｒｅと呼ばれるパラメータを使用してＯＩＲＭによって追跡し得る。例えば、各アカウンティング・インターバルの開始時に、ＯＩＥＥは、プロセッサ・コア上の実行時間のそのＯＩ−Ｃｕｒｒｅｎｔ−Ｓｈａｒｅに等しい時間クレジットを受け取る。上記クレジットは、ＯＩＥＥがプロセッサ・コア上で実行した持続時間に等しい量で、ＯＩＥＥの各スケジュールに対して消費される。クレジットが枯渇すると、ＯＩＥＥは、クレジットが補充される次のアカウンティング・インターバルまで実行が妨げられる。
【００４１】
ドライバ支援スケジューリング手法（上記項目（１））は、ホストＯＳ／ＶＭＭにインストールされたＯＩドライバに依存し得る。ＯＩドライバは、ＯＩＲＭによるその初期化の一部としてＯＩＲＭに割り込みベクトルを登録し得る。ＯＩドライバは、ＯＩドライバからのイベントの通知を待つ無限ループに位置するＯＩワーカ・スレッドの生成ももたらし得る。ＯＩＲＭは、ＯＩ−Ａｃｃｏｕｎｔｉｎｇ−Ｉｎｔｅｒｖａｌの開始をＯＩドライバに通知するために、このベクトルに対応するＩＳＲ（割り込みサービス・ルーチン）ハンドラを呼び出す旨の割り込みをホストＯＳ／ＶＭＭに導入し得る。
【００４２】
図３は、一実施例による、ＯＩＥＥ及びホストＯＳ／ＶＭＭの実行に関連付けられた種々の動作のブロック図を示す。図３に示すように、動作１では、ＯＩＲＭ１２４は割り込みをホストＯＳ／ＶＭＭ１２０に導入する。これは、（例えば、ＯＳ／ＶＭＭ区画１２０に記憶された）ＯＩドライバ３０２によって登録されたＩＳＲを呼び出し得る。動作２では、ＯＩドライバ３０２は（例えば、対応するＩＳＲを介して）ＯＩワーカ・スレッド３０３に通知する。一実施例では、スレッド３０３は、何れの特定のプロセッサ・コアにも結合していない。オペレーティング・システムは、適切な場合、スレッド３０３をスケジュールし得る。動作３では、スレッド３０３はＯＩＥＥ３０４をスケジューリングする旨をＯＩＲＭ１２４に要求するための命令を呼び出す。動作４では、ＯＩＲＭ１２４はホストＯＳ／ＶＭＭコンテナ１２０の現在の状態を保存し、ＯＩＥＥ３０４の保存された状態をロードする。動作５は、ホストＯＳ／ＶＭＭ１２０向けの割り込み／ＩＰＩの到着によってトリガされ得るか、又は、ＯＩＥＥ３０４のために構成された実行時間の現在のシェア（通常又は最大）の満了によってトリガされ得る。
【００４３】
ホストＯＳ／ＶＭＭ及びＯＩワーカ・スレッド３０３の観点から、ＩＯ命令は基本的には、上記動作５が実行されると戻るブロッキング命令であり得る。動作５を実行する理由に応じて、ＯＩＲＭ１２４は、ワーカ・スレッド３０３に以下の戻り値のうちの１つを戻し得る：
ＢＬＯＣＫ この戻された値は、ＯＩに対する時間割り当てが消費されたので、動作５が実行されたことを示す。これにより、基本的には、スレッド３０３を戻らせ、スレッド３０３に、ＯＩドライバからの次のイベント通知を待たせ得る。
【００４４】
ＣＯＮＴＩＮＵＥ この戻り値は、動作５が実行された（例えば、外部割り込み／ＩＰＩがホストＯＳ／ＶＭＭに到着することによってＯＩが強制排除された）旨を示す。このアカウンティング・インターバル内のＯＩに対する時間割り当ては未だ消費されていないことがあり得る。動作５を実行させた割り込みはＯＩを強制排除し得る。ホストＯＳ／ＶＭＭは、ＩＳＲ処理（及び、場合によっては他の保留中の高優先度タスクの実行）を完了すると、ＯＩワーカ・スレッド３０３を再スケジューリングする。あるいは、ホストＯＳ／ＶＭＭは、到着している割り込みを処理する間に、スレッド３０３を別のプロセッサ・コアに移動させ得る。再開すると、ワーカ・スレッド３０３は、戻り値を検査し得、戻り値がＣＯＮＴＩＮＵＥの場合、ＯＩ実行を再開するための動作３を実行する。
【００４５】
図４は、実施例によるタイムチャートを示す。２つのアカウンティング・インターバルを図４に示す。（図４の左側から始まる）第１のアカウンティング・インターバルでは、ＯＩは、４０２でＯＩドライバ・スレッド３０３がＯＩ−ＲＥＡＤを呼び出すことによってスケジューリングされる。しかし、ＯＩは、４０４におけるホストＯＳ／ＶＭＭによって割り込まれる。ＯＩは再度、後に、４０６で、アカウンティング・インターバル内でスケジューリングされ、４０８でその割り当てられた時間の実行を完了する。（４１０で始まる）第２のアカウンティング・インターバルでは、４１２でその割り当てられた時間の間の実行を完了するまでＯＩは割り込まれない状態で実行する。
【００４６】
一部の場合には、ＯＩワーカ・スレッド３０３の実行を阻止又はブロックすることにより、ＯＩに対して、偶然に、又は不当に、完全なサービス妨害を行う可能性が存在し得る。ガード・タイマ及び関連付けられたホストＯＳ／ＶＭＭ強制排除（後述する）は、ＯＩに対して行われる最小実行時間保証をＯＩＲＭが達成することを可能にする。
【００４７】
特に、ＯＩワーカ・スレッド３０３のスケジューリングを要求するための割り込みが導入されると、ＯＩＲＭはガード・タイマを起動させる。このタイマの持続時間は、一実施例におけるアカウンティング・インターバルの５０％に設定し得る。他の持続時間も設定し得る。ＯＩが、その最小の構成された時間のシェアの消費を実行する機会を十分得た場合、ＯＲＩＭはそのアカウンティング・インターバルのガード・タイマをオフにする。更なる実行の機会は、よって、保証されないことがあり得る。このガード・タイマが満了すると、ＯＩが、その構成された最小時間シェアを実行する機会を有していなかった場合、ＯＩに対して、その構成された最小の時間シェアを消費する機会を十分提供した状態になるまで、ＯＩＲＭはプリエンプティブ・スケジューリング・モードに入る。ＯＩを実行するためのプリエンプティブ・スケジューリングを行う場合、ホストＯＳ／ＶＭＭ割り込みはブロックされ得る。しかし、ＯＩＲＭは、ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍになるよう、割り込まれない状態でＯＩが実行する最大持続時間を制御し得る。
【００４８】
一実施例では、以下の動作は、ガード・タイマ満了時のＯＩＲＭ処理を説明しており、ここで、ＯＩＲＭは、周期性Ｐのタイマを起動させ、ここで、Ｐは、
Ｐ＝（ＯＩ＿Ａｃｃｏｕｎｔｉｎｇ＿Ｉｎｔｅｒｖａｌ／２）／（ＯＩ＿Ｍｉｎｉｍｕｍ＿Ｓｈａｒｅ／ＯＩ＿Ｓｃｈｅｄｕｌｉｎｇ＿Ｑｕａｎｔｕｍ）
で定められる。
【００４９】
各インターバルが満了すると、以下の動作が行われる：（ａ）ホストＯＳ／ＶＭＭを強制排除し、ホストＯＳ／ＶＭＭが強制排除されたプロセッサ・コア上の実行のためにＯＩをスケジューリングし、（ｂ）ＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍ後にＯＩが満了する強制排除時間を構成し、（ｃ）ＯＩ強制排除タイマが満了すると、ホストＯＳ／ＶＭＭを再開する。
【００５０】
図５及び図８は、一部の実施例によるタイムチャートを示す。特に、図５は、ガード・タイマ満了前に消費されたＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅを示す。ここで、２つのアカウンティング・インターバルを示す。第１のアカウンティング・インターバルでは、ＯＩは、ガード時間の満了前にその最小シェアを既に消費している。しかし、ホストＯＳ／ＶＭＭは、更に実行するための機会をＯＩに対して与えることは決してない。第２のインターバルでは、同様な状態が起こる。しかし、ホストＯＳ／ＶＭＭは、ＯＩが、ＯＩ−Ｍｉｎｉｍｕｍ−Ｓｈａｒｅ超を実行することを可能にする。
【００５１】
図６では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、その最小の構成された時間シェアの間、実行する機会を有する状態になるまでＯＩにおけるＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。図７では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、ＯＩにおいてＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。しかし、前述の数カンタム後、ＯＳ内のドライバは、アクティブになり、ＯＩのスケジューリングを要求する旨のＯＩ−ＲＥＡＤを呼び出す、更に、ＯＩ−ＲＥＡＤは、構成された最小の時間の消費に十分長くＯＩが実行すること、及びＯＩ停止を実行するためのホストＯＳ／ＶＭＭの強制排除につながる。図８では、ＯＩは、プリエンプティブ・スケジューリング・モードに入り、ＯＩにおいてＯＩ−Ｓｃｈｅｄｕｌｉｎｇ−Ｑｕａｎｔｕｍの長バーストを実行するようホストＯＳ／ＶＭＭの強制排除を開始する。しかし、前述の数カンタム後、ＯＳ内のドライバは、アクティブになり、ＯＩのスケジューリングを要求する旨のＯＩ−ＲＥＡＤを呼び出す（しかし、ＯＩは、構成された最小時間を消費するのに十分長く実行される訳でない）。これは、構成された最小時間がＯＩにおいて実行されるまでプリエンプティブ・スケジューリングをＯＩＲＭに続けさせる。
【００５２】
一実施例では、ホストＯＳ／ＶＭＭにおけるＯＩドライバの有無の処理に関し、ドライバ支援スケジューリング機構は、オペレーティング・システムにインストールされている前述のドライバが存在している場合に起動し得る。しかし、ＯＩスケジューリングは、存在しているドライバに依存しないことがあり得る。よって、ドライバがインストールされ、機能している場合、スケジューリングはＯＳフレンドリな態様で機能する。ドライバがインストールされていないか、若しくはアンロードされていないか、又は、オペレーティング・システム自体がインストールされていないか、又はオペレーティング・システムが作動状態にない場合、ＯＩＲＭは、上述のガード時間がゼロであったかのように実行し得る。スケジューリングのプリエンプティブ・モードは、構成された最小の実行時間をＯＩＥＥが受け取った状態になるまで、用い得る。ＯＩＥＥ時間スライスにおけるホストＯＳ／ＶＭＭの到着は、同様に、構成された最小時間の間、ＯＩＥＥが実行すると、ホストＯＳ／ＶＭＭを実行させるようＯＩＥＥを強制排除させ得る。
【００５３】
一部の実施例では、ＯＳの可視性を、ＯＩモードにおいて消費されたサイクルに与え得る。前述の機能は、ＯＩがイネーブルされたプラットフォーム上の何らかの異常な挙動を理解するためのデバッグ用ツールにも有用であり得る。ＯＩモードにおいて消費されたサイクルへの可視性は、コア毎ＭＳＲ（モデル特有レジスタ）の対、ＯＩ＿ＣＹＣＬＥ＿ＬＯＷ（サイクル・カウントの低位３２ビットを含む）及びＯＩ＿ＣＹＣＬＥ＿ＨＩＧＨ（カウンタの高位３２ビットを含む）（オペレーティング・システム及び／又は性能監視ツールによって読み出し得る）によって利用可能にされ得る。ＯＩＲＭは、その初期化手続の一部としてコア毎に前述のカウンタを０にリセットし得る。ＯＩの実行毎に、ＯＩ内部で費やされた時間（ＳＭＭ又はホストＯＳ／ＶＭＭ内で費やされる時間は考慮に入れない）は前述のカウンタによって更新し得る。
【００５４】
図９は、一実施例による、ホップする対象の次のコアを判定するためのフロー図を示す。例えば、スケジューリングのドライバ支援モードが設けられると、ＯＩＲＭは、ＯＩＥＥの実行のためにプロセッサ・コアを選択する旨をホストＯＳ／ＶＭＭに要求し得る。ＯＩドライバに対する割り込みが、ＯＩスケジューリングを要求するよう発信されると、オペレーティング・システムは、プロセッサ・コア上でＯＩワーカ・スレッド３０３をスケジューリングすると、この選択を行い得る。ワーカ・スレッド３０３がスケジューリングされるプロセッサ・コアは、ＯＩＥＥをスケジューリングするために使用し得る。ホストＯＳ／ＶＭＭが応答しない（例えば、ガード・タイマが満了したか、又は、ホストＯＳ／ＶＭＭがＯＩドライバをインストールさせなかった）モ―ドでは、ＯＩＲＭはプロセッサ・コア選択を自律的に行い得る。
【００５５】
一般に、プロセッサ・コア（又はハードウェア・スレッド）は、プロセッサ命令をアクティブに実行する場合、Ｃ０状態にあると言える。この状態では、システム構成部分（例えば、プロセッサ、バス、キャッシュ、メモリ等）は全て、電源オンにされ、使用されている。しかし、プロセッサ・コアは、命令を実行していない場合、次第に、システムの別々の部分の電源をオフにするか、又はシステムの別々の部分を低電力モードに入れ得るＣ１、Ｃ２、Ｃ３等の状態に移され得る。前述の電力節減状態は一般に、Ｃ−ｘ状態として表す。
【００５６】
一部の実施例によれば、ＯＩＲＭは、システム内のプロセッサ・コア全てにわたってロードを分散させ得る。これは、特定のプロセッサ・コア上で実行しているソフトウェアにペナルティを課すこと（例えば、ＶＭＭにより、物理プロセッサ・コアに束縛された仮想マシン）を減らすか、又は避け得る。プロセッサ・コア・ホッピング規則は、ＯＩＲＭの現在のアクティブなインスタンスによって行われ、プロセッサ・コア・ホッピング・アルゴリズムの結果に応じて、アクティブな役割をスタンバイ・インスタンスのうちの１つにハンドオフし得る。ＯＩは、パッケージ内のプロセッサ・コアのうちの１つの上で何れの特定の時点においても実行し得る。ＯＩＲＭは、ＯＩを実行するために使用する対象のプロセッサ・コアについての決定を行い得る。ホストＯＳ／ＶＭＭは、１つ又は複数のプロセッサ・コアをＣ−ｘ状態に入れ得る。実行するプロセッサ・コアを判定するためにＯＩＲＭによって使用されるロジックは、プロセッサ・コアにＣ−ｘ状態が常駐していること、及びプロセッサ・コアの現在のＣ−ｘ状態を考慮に入れ得る。
【００５７】
一実施例では、ＯＩＲＭは、ＯＩを実行するためにＣ−ｘプロセッサ・コアをウェイクするか、又はＣ０プロセッサ・コアからサイクルをとるかを決定し得る。ここでのトレードオフは、電力対性能である。ＯＩを実行するためにＣ−ｘプロセッサ・コアをウェイクしても、（大半の場合）ホストＯＳ／ＶＭＭの性能に影響を及ぼさないことがあり得る。アクティブな場合、プロセッサ・コアからサイクルはとられないからである。しかし、Ｃ−ｘプロセッサ・コアをウェイクすることにより、電力利用率が増加する。考慮に入れるべき別の要因は、電力／熱エンベロープにおける変動により、Ｃ−ｘプロセッサ・コアがウェイクされた場合に、Ｃ０プロセッサ・コアの性能を低下させ得るダイナミック・スロットリングである。ＯＩＲＭは、この判定を支援するためにヒューリスティックスを求めてＣＰＰＭ／ＰＣＵを照会し得る。第２の考慮点は、Ｃ−ｘ状態からのウェイクのレーテンシについてホストＯＳ／ＶＭＭに対して行われる「保証」である。各Ｃ状態は、Ｃ０状態にウェイクするためのレーテンシと関連付けられる。ホストＯＳ／ＶＭＭにより、Ｃ−ｘ状態に入れられたプロセッサ・コアが、ＯＩを実行するために選択されると、そのプロセッサ・コアの状態はＣ０に移る。ここで、（プロセッサ・コアがＯＩを実行していた際に）ウェーキング・イベント（例えば、割り込み）がホストＯＳ／ＶＭＭに対して生じた場合、ＯＩＲＭは、ホストＯＳ／ＶＭＭに制御を戻すようＯＩを強制排除し得る。ＯＩからホストＯＳ／ＶＭＭへの切り換えの実行において生じるレーテンシは、ホストＯＳ／ＶＭＭが要求したＣ状態からの保証されたウェイク・レーテンシを超えないことがあり得る。一部の実施例では、以下の規則は、前述の場合においてプロセッサ・コア選択を行うためにＯＩＲＭによって使用される。
【００５８】
図９を参照すれば、Ｃ状態（ここで指しているＣ状態は、ホストＯＳ／ＶＭＭによって認識され、要求された通りのＣ状態である）において、規則を適用し得る（９０２）。サイクルをこっそり取ることにより、ホストＯＳ／ＶＭＭの性能に影響を及ぼすことを避けるために、ＯＩＲＭは、アイドル状態（例えば、ホストＯＳ／ＶＭＭの観点からの、Ｃ−ｘ状態）にあり、ホストＯＳ／ＶＭＭによって使用されていないプロセッサ・コア上でＯＩＥＥを実行し得る。ＯＩＥＥを実行するためにＣ−ｘプロセッサ・コアをウェイクすることはしかし、電力／熱ベースの自律的なスロットリングをトリガさせるという悪い副作用を及ぼし、Ｃ０プロセッサ・コア上のホストＯＳ／ＶＭＭ性能が悪影響を受けることにつながり得る。（例えば、９０２における）ＯＩＲＭは、ＯＩを実行するようＣ０プロセッサ・コアを強制排除することと、Ｃ−ｘプロセッサ・コアを使用することとに関係するトレードオフを求めるようＰＣＵ９０４からのヒューリスティクスを利用し得る。同様に、プラットフォーム上の電力の影響は、Ｃ０状態にあるプロセッサ・コアを使用する場合よりも、スリーピング・プロセッサ・コアをウェイクする場合のほうが大きい。しかし、ＯＩを実行するためにプロセッサ・コアをウェイクすることによる電力消費のわずかな増加は、プラットフォームが、バッテリ電源９０６で動作している場合に対して、ＡＣ電力で動作している場合に許容可能であり得る。
【００５９】
図９に示すように、Ｃ状態の規則９０２の適用は、（Ｃ−ｘプロセッサ・コア及びＣ０プロセッサ・コアを含み得る）フィルタリングされたコア・リスト９１０を生成するために、現在のコアのリスト９０８、ＰＣＵヒューリスティクス９０４、及び／又はプラットフォーム電源９０６を考慮に入れ得る。動作９１２では、コアがＣ−ｘ状態にないと判定された場合、ＯＩＲＭは、ロードを分散させるためにＣ０プロセッサ・コア９１４のうちでコア・ホッピング規則９２０（例えば、ラウンド・ロビン選択）を行い得る。Ｃ−ｘプロセッサ・コアが存在している場合、ＯＩＲＭは、リスト９１６からＣ−ｘプロセッサ・コアを選択し、（９１８において最低Ｃ状態におけるコアを選択するなどの）更なるホッピングを行わないことがあり得る。一実施例では、ＯＩＲＭは、選択されたプロセッサ・コアが、なお、実行するのに最良のプロセッサ・コアであることを確実にするためにＣ状態の規則９０２を実行することにより、条件を周期的に再評価し得る。
【００６０】
よって、図９に示す実施例によるプロセッサ・コア選択は、以下の動作を含み得る。まず、ＯＩが実行し得るプロセッサ・コア・リスト９０８を使用し、Ｃ状態の規則９０２を適用して、フィルタリングされたプロセッサ・コア・リスト９１０を生成する、Ｃ状態の規則に対する入力としてプラットフォーム電源９０６及びＰＣＵヒューリスティクス９０４を使用する。フィルタリングされたプロセッサ・コア・リスト９１０にＣ−ｘ状態におけるプロセッサ・コアが存在している場合、最低Ｃ−ｘ状態９１８におけるプロセッサ・コアを、ホップする先の、次のプロセッサ・コアとして選ぶ。Ｃ−ｘ状態におけるプロセッサ・コアが存在しない場合、Ｃ−０プロセッサ・コア９１４のリストのうちから（例えば、ラウンド・ロビン・ホップを行うために）プロセッサ・コア・ホッピング規則９２０を呼び出す。このことは、一部の実施例には、前述のプロセッサ・コア上でＯＩＲＭのアクティブ／スタンバイの役割を切り換えることが関係し得る。
【００６１】
図１０は、一実施例による、ＯＩ区画に導入し、ＯＩに割り当てられたデバイスから生じる割り込みを処理するために使用される種々の構成部分のブロック図を示す。図示したように、ハードウェア装置は、ＬＡＰＩＣ（局所高度プログラマブル割り込みコントローラ）１００６及び１００８を、それぞれが有する複数のプロセッサ・コア１００２及び１００４を含み得る。ＬＡＰＩＣはそれぞれ、（外部割り込み１０１２を受け取る）割り込み再マッピング装置１０１０と通信し合う。
【００６２】
割り込み再マッピング装置１０１０は、（ａ）第２の割り込み再マップ・テーブル（ＩＲＴ）１０２０をＯＩ ＩＲＴエントリ（ＩＲＴＥ）で登録すること、（ｂ）ＯＩデバイス・フィルタ１０２２（例えば、ＰＣＩリクエスタＩＤ毎の１ビット（８ＫＢ）を有する）を登録すること、及び／又は、（ｃ）後述する（例えば、図１１に灰色の箱で示す。図１１は、一実施例による、ＯＩ関連の割り込みの処理に関連付けられた動作のフロー図を示す）割り込み再マップ・ロジックに対する修正に対するサポートを含み得る。例えば、割り込み１１０２を受け取った後、ポスティングされた割り込みが、割り込みＴＬＢ（変換ルックアサイド・バッファ）１１０４になかった場合、割り込みがポスティングされているかを判定し得（１１０６）、肯定の場合、ルックアップ１１０８を、ＰＣＩリクエスタＩＤを使用してデバイス・フィルタ１０２２において行い得る。否定の場合、割り込みが処理される（１１０９）。対応するビットがデバイス・フィルタ１０２２にセットされた場合、ＯＩ ＩＲＴ１１１０を、対応するラベルを探すために使用し得、さもなければ、ＯＳ／ＶＭＭ
ＩＲＴをルックアップ１１１２に使用し得る。動作１１１０及び１１１２の後、割り込み記述子に対するベクトルを１１１４でポスティングし得る。
【００６３】
更に、一実施例では、割り込み記述子は、割り込みをどこにポスティングするかを割り込み再マップ装置が判定することを助力する２つの項目（すなわち、割り込むためのＡＰＩＣ ＩＤ， 及び通知割り込みとして使用するためのベクトル）を有し得る。更に、一部の実施例では、ＯＩに対する要件の１つは、ＯＩに対する割り込みの配信が、主ＯＳからの何れの動作によっても影響を受けないということである。このことは、割り込み記述子内のベクトルを、コアに対する配信のために上記記述子にプログラムされた局所ＡＰＩＣに配信するポスティングされた割り込み方法が、割り込み再マップ装置が、新たなマイクロコード・イベント通知を使用してＯＩＲＭにＣＰＵマイクロコードを通知するように修正される。特に、割り込み再マップ装置からマイクロコード・イベント通知を受け取ると、ＯＩ区画は、何れのプロセッサ・コア上でもその時点で実行していないことがあり得るので、ＯＩＲＭは、ポスティングされた割り込みをＯＩ区画に直ちに導入する訳でないことがあり得る。よって、ＯＩＲＭは、後述するメモリ構造（例えば、ＯＩＰＩＣ（ＯＩプログラマブル割り込みコントローラ）に、受け取られた割り込みをキューイングし、ＯＩ ＩＤＴ（割り込み記述子テーブル）を使用した標準ｘ８６割り込み配信機構を使用してスケジューリングされる都度、ＯＩ区画に割り込みを導入する。
【００６４】
図１２は、一実施例による、ＯＩＰＩＣモジュールと通信し合う種々の構成部分を示す。図示した通り、ＯＩＰＩＣモジュール１２０２は、考えられる２つのソース（すなわち、（１）（例えば、割り込み再マッピング装置によって通知され、ＯＩ割り込みバッファにポスティングされる）ＯＩＥＥ１２０４に割り当てられたデバイスからの割り込み、又は（２）電力管理イベント、ＯＩ間通信通知、ＯＩＥＥタイマに対するＯＩＲＭ導入割り込み等（併せて１２０６として表す））からＯＩＥＥへの配信のためにベクトルを受け取る。
【００６５】
ＯＩＰＩＣモジュール１２０２は、ＯＩＥＥに配信するためのベクトルをキューイングするために３つのレジスタをモデリングし得る。（１）ＯＩ ＩＲＲ（割り込み要求レジスタ）１２０８（例えば、内部ソース又は外部ソースから到着するベクトルは全て、この２５６ビット・レジスタに入る） （２）ＯＩ ＩＳＲ（ＯＩインサービス・レジスタ）１２０８（例えば、ＯＩ ＩＲＲからの最高優先度ベクトルは、ＯＩ ＩＳＲに既にあるベクトルよりも優先度が高い場合、ＯＩ ＩＳＲに入れられる。これは、ＯＩＥＥによって現在処理されている割り込みベクトルを追跡する２５６ビット・レジスタであり得る。ＯＩ ＩＳＲに既にある現在の割り込みベクトルはそのままである。例えば、最高優先度割り込みが低優先度割り込みに割り込みをかけたことを示す）及び／又は（３）ＯＩ ＥＯＩ（割り込みの終了）１２１２（例えば、ここで、ＯＩＥＥ ＩＳＲは、ＯＩ ＩＳＲにおいて現在マーキングされている最高優先度ベクトルの処理の完了を通知する）。
【００６６】
一部の実施例では、プロセッサ・コア上で実行するためにＯＩ区画が（例えば、スケジューラ１２１４によって）スケジューリングされると、動作（すなわち、（１）ＯＩ ＩＲＲにおいて保留中のベクトルが存在していない場合、動作は必要でなく、（２）ＯＩ ＩＲＲから最高優先度ベクトルを取得し、ＯＩ ＩＳＲにおける最高ベクトルと比較し（ＯＩ ＩＲＲベクトルがＯＩ ＩＳＲベクトルよりも低い場合、動作は必要でなく）、（３）ＯＩＥＥが割り込み可能な場合、ＯＩ ＩＳＲにおいてＯＩ ＩＲＲから受け取られた最高ベクトルに対応するビットをセットし（一実施例においては、OI IRRからそのベクトルをクリアし）、かつ／又は、（４）ＯＩＥＥに導入する対象のベクトルとしてＯＩ ＩＳＲにおいて保留中の最高ベクトルを戻す）がＯＩＰＩＣモジュール１２０２によって行われる。割り込みに応じて、ＯＩＥＥにおける割り込みコントローラ・ドライバはＯＩＥＯＩレジスタ１２１２に対する書き込みを使用して完了を通知する。ＯＩＥＥからＯＩＥＯＩを受け取ると、ＯＩＰＩＣ１２０２は、ＯＩ ＩＳＲ１２１０において保留中の最高優先度ベクトルに対応するビットをクリアする。次いで、次の再開時にＯＩＥＥに導入することが可能な何れかの他のベクトルが存在しているかを判定する。
【００６７】
図１０乃至１２を参照して説明したように、ホストＯＳ／ＶＭＭによって使用し得る割り込みベクトルに対する制約を加えないホストＯＳ／ＶＭＭに対する非侵入的な手法が提供される。同様に、前述の実施例は、ホストＯＳ／ＶＭＭからＬＡＰＩＣ／ＩＯＡＰＩＣへの何れのアクセスも遮断せず、前述のデバイスの何れも仮想化しようとしない。このことにより、別々の区画に割り込みを誘導し、前述の機能を有しない他の実現形態と比較すると、前述の機能を更に相当好適かつスケーラブルにするという機構が可能になる。
【００６８】
一部の実施例では、ホストＯＳ／ＶＭＭ区画とＯＩ区画との間のメモリの分離をもたらすために、ＯＩＲＭは、ＯＩメモリ区画に対する、ホストＯＳ／ＶＭＭによって発生したアクセスをブロックするか否かを判定するためにハードウェア・レンジ・レジスタの１つ又は複数のビットを利用し得る。同様に、ホストＯＳ／ＶＭＭメモリ区画に対するＯＩ区画からのアクセスを制御するために、ＯＩＲＭは、ＯＩ区画下の拡張ページ・テーブル（ＥＰＴ）などのページ・テーブルを作成し得る。例えば、上記ＯＩ区画は、起動前認証、メディア・トランスコーディング、電子商取引等のような、セキュリティに気を配る必要がある特定の作業を行うために使用し得る。前述の動作が行われると、ＯＩ区画は、鍵及びパスワードのような秘密を有し得る。同様に、ホストＯＳ／ＶＭＭプロセッサ・ベースのアクセスを使用して、又は、ＤＭＡバスマスタ・デバイスを使用して前述の秘密を盗むための、ＯＩメモリに対するソフトウェア・ベースの攻撃は、レンジ・レジスタ及びＤＭＡデバイス・フィルタを使用してブロックされる。
【００６９】
一部の実施例では、２つのタイプの保護（すなわち、（１）保存データに対する保護、又は（２）使用中のデータに対する保護）を提供し得る。揮発性メモリ内又は不揮発性メモリ内にある場合の保存データの保護は、攻撃者に対して価値がないように上記データを暗号化することを必要とする。このために、ＯＩは、処理する必要がある場合にデータを復号し、同時に、処理している際に盗むことができないようにデータを保護するためのやり方を必要とする。
【００７０】
保存データを保護することは、ＣＢＣ（暗号ブロック連鎖）、ＣＴＲ（カウンタ・モード）等などの、何れかのモードにおける暗号を使用する高度暗号化標準（ＡＥＳ）（２５６ビット又は他のバージョン）のような暗号化アルゴリズムを使用してデータを暗号化し得るということを示唆している。暗号化するための鍵も保護する必要がある。一実施例では、その秘密を保護する必要がある各アプリケーションは、その秘密の暗号化のためのそれ自身の鍵を有する。ＯＩＲＭは、コア又は非コアにおけるプロセッサ・ヒューズを使用してこの鍵を保護するためのｂｌｏｂサービスを提供し得る。ｂｌｏｂ鍵動作の場合、ユーザは、そのデータを保護するために使用したい鍵を生成し、それに対してｂｌｏｂを行うようＯＩＲＭに要求する。更に、以下に更に説明するように、一部の実施例は、処理における、ユーザによって生成された鍵の保護に助力し得る。
【００７１】
一実施例によれば、以下の擬似コードは、鍵ｂｌｏｂを生成するためにユーザによって使用し得る。
【００７２】
１． ａｐｐｌｉｃａｔｉｏｎ＿ｋｅｙ＿ｇｅｎｅｒａｔｉｏｎ＿ｆｕｎｃｔｉｏｎ（）
２． ｛
３． ｃｈａｒ＊ｋｅｙ＿ｂｕｆｆｅｒ＝ｍａｌｌｏｃ（４０９６）
４． ｇｅｎｅｒａｔｅ＿ｋｅｙ（ｋｅｙ＿ｂｕｆｆｅｒ）
５． ｂｌｏｂ＿ｋｅｙ（ｋｅｙ ｂｕｆｆｅｒ）
６． ｝
上記擬似コードの行４では、アプリケーションはｋｅｙ＿ｂｕｆｆｅｒ内に鍵を生成し、行５では、アプリケーションは、鍵ｂｌｏｂを生成するために（例えば、ＯＩＲＭによって提供される）ｂｌｏｂサービスを呼び出す。ＯＩＲＭｂｌｏｂサービスは、このｂｌｏｂサービスに使用されるプロセッサ鍵１１３を使用して鍵バッファ内の鍵を暗号化し得る。よって、アプリケーションは、その秘密を保護するために使用し得るプラットフォームに結合されたセキュアな鍵を有する。アプリケーションは、上記行４において生成した元の鍵を保持しなくてよい。鍵ｂｌｏｂが、データに対して処理するために今後必要な全てである。
【００７３】
一部の実施例では、実行時にデータを保護するために、データは、システム・メモリ内で決して平文でないことがあり得る。これは、ＯＩ秘密を一時的に記憶するためにオンパッケージ・メモリ１１１の一ページの使用によって達成し得る。一実施例では、オンパッケージ・メモリ１１１は、このメモリの内容が、バス・アナライザ及び「フリーズ・キャン」攻撃を使用してアクセス可能でないことを可能にする。すなわち、メモリ１１１に記憶された、暗号化されていない情報は、プロセッサ１０２−１の外では利用可能でないことがあり得る。一実施例では、ＯＩＲＭは、セキュアなメモリ・アクセスを可能にするための命令（すなわち、（１）Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ メモリ・バッファからのデータをセキュアなメモリに移し、アプリケーションによる使用のために復号する。（２）Ｓｔｏｒｅ Ｋｅｙ Ｐａｇｅ セキュアなメモリからのデータをメモリ・バッファに移し、セキュアなメモリをクリアする。）をユーザに提供する。
【００７４】
一実施例では、鍵ページ・ロード動作は２つの入力（すなわち、（ａ）鍵ページの暗号化のために使用されるｂｌｏｂが行われた鍵、及び（ｂ）（鍵ページとして表される）暗号化データを保持するバッファの物理アドレス）を用いる。Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ動作が呼び出されると、ＯＩＲＭは、（１）物理アドレスによって指し示されたページの内容をオンパッケージ・メモリ１１１に複製し、（２）プロセッサ・ヒューズ鍵を使用して鍵ｂｌｏｂを復号し、（３）オンパッケージ・メモリ１１１内のデータを、復号された鍵を使用して復号し、（４）オンパッケージ・メモリ１１１に対する前述の動作に転送される物理アドレスに対するアクセスを再指示するようＯＩのＥＰＴを更新し、かつ／又は、（５）アプリケーションは次いで、秘密にアクセスするために標準ソフトウェア構成を使用し得るという動作を行う。
【００７５】
図１３及び図１４は、一部の実施例による、ロード鍵の利用に関連付けられた動作のブロック図を示す。図１３では、ロード鍵は、（例えば、暗号化された）物理メモリをセキュアなメモリに変え、出願人の鍵を使用してデータを復号する。図１４では、ＯＩ ＥＰＴは、物理メモリをセキュアなメモリに転換するよう再マッピングし得る。
【００７６】
一部の実施例では、単一の鍵ページのみを何れかの時点でロードし得る。先行してロードされたページに対してＳｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅを行うことなくＬｏａｄ＿Ｋｅｙ＿Ｐａｇｅを行おうとすると、障害が発生し得る。ＯＩＥＥカーネルからの鍵ページ管理は、アプリケーションに対してロード／記憶サービスを提供するＯＩカーネル・モジュールに依存し得る。カーネル・モジュールは、処理／タスク・スイッチが通知されるようＯＩカーネル・スケジューラに関わり、Ｌｏａｄ／Ｓｔｏｒｅ Ｋｅｙ Ｐａｇｅを使用して、ＯＩにおいて実行しているアプリケーションに基づいて鍵・ページを変え得る。
【００７７】
一実施例では、鍵ページ記憶動作は２つの入力（すなわち、（ａ）鍵ページの暗号化のために使用される、ｂｌｏｂが行われた鍵、及び（ｂ）（鍵ページとして表される）暗号化データを記憶するためのバッファの物理アドレス）を用いる。ＯＩＲＭは、（１）プロセッサ・ヒューズ鍵を使用して鍵ｂｌｏｂを復号し、（２）復号されたｂｌｏｂ鍵を使用してオンパッケージ・メモリ１１１の内容を暗号化し、かつ／又は（３）オンパッケージ・メモリ１１１の内容を、アプリケーションによって転送されたメモリ・ページに複製するという動作を行う。
【００７８】
図１５及び図１６は、一部の実施例による、記憶鍵の利用に関連付けられた動作のブロック図を示す。図１５では、記憶鍵は、セキュアなメモリ（例えば、平文）を物理メモリに変え、出願人の鍵を使用することにより、データを暗号化する。図１６では、ＯＩ ＥＰＴは、物理メモリの転換を元に戻すよう再マッピングし得る。
【００７９】
一実施例では、以下の擬似コードは、上述のＬｏａｄ＿Ｋｅｙ＿Ｐａｇｅ及びＳｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅに使用し得る。
【００８０】
Ｄｏ＿ｓｅｃｒｅｔ＿ｗｏｒｋ＿ｅｘａｍｐｌｅ＿ｆｕｎｃｔｉｏｎ（ｕｉｎｔ６４＿ｔ ｋｅｙ ｂｌｏｂ ＰＡ， ｕｉｎｔ６４＿ｔ ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）
｛
Ｃｈａｒ ＊ｓｅｃｒｅｔ＿ｐａｇｅ＿ｌａ＝ｍａｐ＿ｓｅｃｒｅｔ＿ｐａｇｅ（ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
Ｌｏａｄ＿Ｋｅｙ＿Ｐａｇｅ（ｋｅｙ＿ｂｌｏｂ＿ＰＡ，ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
Ｄｏ＿ｓｅｃｒｅｔ＿ｗｏｒｋ（ｓｅｃｒｅｔ＿ｐａｇｅ＿ｌａ）；
Ｓｔｏｒｅ＿Ｋｅｙ＿Ｐａｇｅ（ｋｅｙ＿ｂｌｏｂ＿ＰＡ，ｓｅｃｒｅｔ＿ｐａｇｅ＿ＰＡ）；
｝
上記コードでは、「ｌａ」が線形を表し、「ＰＡ」は物理アドレスを表す。よって、一実施例は、（例えば、ソフトウェア・ベースの攻撃又はコールド・ブートのようなハードウェアベースの攻撃からＯＩメモリ内の秘密を保護することにより、）ＯＩにおける、セキュリティ感応性データを処理するためのタンパリング耐性メモリを提供する。これは、この機能なしの実現形態と比較して、上記機能をかなり好適に、かつ／又はスケーラブルにする。
【００８１】
一部の実施例では、ホストＯＳ／ＶＭＭとＯＩＥＥとの間のメモリの分離をもたらすために、ＯＩＲＭは、ＯＩメモリに対する、ホストＯＳ／ＶＭＭによって発生したアクセスをブロックするハードウェア・レンジ・レジスタを利用する。同様に、ＯＩ区画からホストＯＳ／ＶＭＭメモリへのアクセスを制御するために、ＯＩＲＭは、ＯＩ区画下の拡張ページ・テーブル（ＥＰＴ）などのページ・テ―ブルを作成する。
【００８２】
システムが停止する（Ｓ３）と、システム・メモリは自己リフレッシュ状態に入る。しかし、ＣＰＵが電源オフにされ、よって、メモリ上でアクティブな保護は存在していない。よって、システムがＳ３状態に入っている場合、敵対者はメモリの内容を修正することができ得、メモリが、再開時に検証されない場合（Ｓ０）、これは、ＯＩに対するコード導入攻撃につながり得る。前述のコード導入攻撃を避けるための一手法は、Ｓ３に入る前にメモリをハッシングし、Ｓ３からＳ０に再開する際に内容を検証する。しかし、この手法は一部の場合には２つの欠点を有し得る。（１）メモリの内容をハッシングするために行うべき更なる作業が理由で、Ｓ０からＳ３への遷移に必要な時間の量を増やし、（２）上記内容を検証するためにメモリをハッシングするために行うべき更なる作業が理由でＳ３からＳ０への遷移に必要な時間の量を増やす。
【００８３】
上述の通り、Ｓ３へのシステムの遷移は、ＣＰＵの電源がオフになり、メモリが自己リフレッシュ・モードに入ることをもたらす。この時点では、レンジ・レジスタと同様にアクティブなメモリ上の保護は存在せず、デバイス・フィルタは動作状態にない。Ｓ３上で保持されるメモリ・イメージは、システムがＳ０状態に戻ると実行される。しかし、このメモリのインテグリティはこの場合、疑わしく、自己リフレッシュ・イメージに、不当なコードが導入されているか、あるいは、メモリが、不注意に、特定の形式で損なわれているか、あるいはタンパリングされていることがあり得る。この目的で、一実施例は、Ｓ３の再開時にメモリのインテグリティを検証する。ＯＩＲＭ１２４は例えば、実行することを可能にする前に、自己リフレッシュにおけるメモリ・イメージのインテグリティを測定し得る。上述の通り、このインテグリティ検証の一手法は、Ｓ０からＳ３への遷移の際のＯＩメモリの測定を記録し、Ｓ３からＳ０への遷移の際のイメージを検証することである。Ｓ３の再開に続く前にインテグリティ検証を行うのに大量の時間をＯＩＲＭが費やす必要があるので、この手法は再開のレーテンシを増加させ得る。（２ＬＭ（二レベルのメモリ）を有するシステム上でより顕著になる）前述の手法の不意の副作用は、測定するためにＮＶ（不揮発性）メモリからＤＲＡＭページ・キャッシュにメモリ・ページをフェッチするオーバヘッドである。Ｓ３再開パスは、「即時ＯＮ」モードのような使用の場合の遅延を最小にするために最適化しなければならず、Ｓ３からの再開は、システムをＳ３に戻す前に同期化活動を行うための短い期間の間に行い得る。
【００８４】
一実施例では、再開時間を最小にするために、インテグリティ検査値（ＩＣＶ）は、ページ単位でＯＩＥＥイメージについて計算し得るので、Ｓ３からの再開の際には、ＩＣＶを検証するための時間は最小にされ得る。この場合、検証はＯＩＥＥコードとしてページ単位で行い得、Ｓ３の再開後にデータにアクセスされるからである。図１７を参照すれば、一実施例による、Ｓ０とＳ３との間のセキュアな遷移に関連付けられた動作のブロック図を示す。ＯＩＥＥページ１７０２のページ単位のインテグリティ検査値は、（例えば、ＯＩＲＭ１２４により、）ＩＣＶアレイ１７０４に記録し得る。ＩＣＶアレイの各要素はＯＩメモリ内の一ページに対応し、（１）インテグリティ検査値（ＩＣＶ） 構成されたようなＳＨＡＳＨＡ２５６、ＳＨＡ５１２等のような一方向の暗号ハッシュ・アルゴリズムを使用して生成されたページの一方向暗号ハッシュ、（２）ＩＣＶ有効（図１７に「Ｖ」として示す）、正／誤、及び／又は（３）（図１７に「Ｄ」として示す）ＤＭＡ（直接メモリ・アクセス）ページ、正／誤。ＯＩＲＭは、ＩＣＶアレイのインテグリティを検証するためにＩＣＶアレイに関する（例えば、メモリ１１４にも）ＳＨＡハッシュを保持し得る、という情報を有する。Ｓ０からＳ３状態への遷移を行うと、ＯＩＲＭは、Ｓ３からの再開の際に検証し得るようにＩＣＶアレイのハッシュに署名し得る。
【００８５】
一部の実施例では、ＯＩＲＭは、ＯＩページ１７０２を（例えば、周期的に）ハッシングするためにバックグラウンド・タスク１７０６を使用し得る。ＯＩに対する各遷移の前に、メモリ内のページの固定の組をハッシングするためにバックグラウンド・タスク１７０６を呼び出し得る。例えば、ＯＩイメージのサイズが６４ＭＢである場合、インテグリティ保護するためのページが１６３８４存在している。バックグラウンド・タスクは、ラウンド・ロビンで１６Ｋページを実行し、各ランにおいて１６ページのハッシュを行い得る。よって、バックグラウンド・タスクは、ＯＩＥＥに割り当てられる１６Ｋページ全てのハッシュを行うために１Ｋ回、呼び出す必要がある。一実施例では、ページをハッシングするために要する時間は、ＯＩに帰され、実行クレジットから減算される。
【００８６】
ページのハッシュが記されると、ＯＩＲＭは、再ハッシュを必要としている修正を検知するために前述のページに対する書き込みを追跡し得る。ＯＩＲＭは、ＯＩ ＥＰＴを使用して書き込み追跡を行い得る。ページがハッシングされ、ハッシュがＩＣＶアレイ１７０４において記されると、これは、ＥＰＴにおいてリードオンリとしてマーキングされ、ＩＣＶは、ＩＣＶアレイにおいて有効であるとしてマーキングされる。ＯＩＥＥからのページへの書き込みは、ＯＩＲＭがページＩＣＶを無効であるとしてマーキングし、もう一度書き込み可能であるとしてページを作ることにつながるＥＰＴフォールトをもたらし得る。ページはこの場合、バックグラウンド・ハッシング・タスクがこのページまでもう一度至ると再ハッシングし得、ハッシュが記された後、リードオンリとして再マーキングされる。更に、ＤＭＡ動作を使用したページに対する書き込みは、ＥＰＴ障害を使用して追跡されないことがあり得る。ＤＭＡページに対する書き込みを追跡するために、ＯＩＲＭは、ＤＭＡに対するページをデバイスに送出する前にＯＩＲＭに通知するためにＯＩＥＥカーネルに依存し得る。ＯＩＲＭは、前述のページをＤＭＡページとしてＩＣＶアレイに記し、そのバックグラウンド・タスクの一部として前述のページに対するＩＣＶ検査を何ら行わないことがあり得る。
【００８７】
Ｓ０からＳ３への遷移の場合、上記遷移がＳ３遷移の場合に、ＯＩＲＭはＩＣＶページ・アレイを走査し得、無効のＩＣＶを記録させたページ、及びＤＭＡページのＩＣＶ値を記す。ＤＭＡページとしてマーキングされたページの場合、そのハッシュの記録に加えて、ＯＩＲＭは、ＤＭＡページとしてのそのステータスをクリアし得る。ＯＩＲＭは次いで、ＩＣＶアレイ自体にわたってハッシュを行う。ＩＣＶアレイのハッシュは、パッケージ内のプロセッサ鍵１１３から導き出されたＯＩＲＭ ＩＣＶ署名鍵を使用して署名し得る。ＩＣＶアレイの署名されたハッシュは、そのタンパリングをＯＩＲＭによって検出することが可能であるので、システム・メモリに残し得る。
【００８８】
Ｓ３再開の場合、ＢＩＯＳ（基本ＩＯシステム）は、ＯＩイメージを再開するようＯＩＲＭに通知し得る。ＯＩＲＭは、ＯＩのコンテナを作成し、次いで、ＯＩメモリ内に有効なＩＣＶアレイが存在しているかを判定する。一実施例では、ＩＣＶアレイの有効性は、ＩＣＶアレイのハッシュ上の署名を検証し、Ｓ０乃至Ｓ３の遷移上に記憶された値に対してＩＣＶアレイのハッシュを検査することによって判定される。
【００８９】
ＩＣＶアレイのインテグリティが損なわれていなかった場合、ＯＩＲＭはＯＩ初期化を通常のリセット・パスとして続け得る（例えば、メモリ内のイメージが廃棄され、フレッシュ・ロード・コードのロードが行われる）。ＩＣＶアレイのインテグリティが損なわれていなかった場合、ＯＩＲＭは、ＯＩ ＥＰＴに存在していないとしてＯＩＥＥのページを全てマーキングし、制御をＯＩＥＥに移し得る。ＯＩＥＥが実行を始めるにつれ、コード及びデータ・ページのアクセスは、ＯＩＲＭに誘導されたＥＰＴ障害を発生させる。ＩＣＶアレイ内のページに対して有効なＩＣＶが存在している場合、ＯＩＲＭは、障害ページ上のＩＣＶを計算し、ページのインテグリティを検証するためにＩＣＶアレイにおけるＩＣＶに対してこれをマッチングさせる。このページは次いで、（例えば、ページに対する変更を追跡するために）リードオンリ・ページとしてＯＩ ＥＰＴにマッピングし得る。よって、プロセッサによって生成されたＥＰＴ、及びＩＯＲＭを使用した増分ハッシングは、例えば、ハイパバイザにおいて現在行われていることと比較して、主要な相違点である。更に、一実施例は、自己リフレッシュを出ると、ＯＩメモリのインテグリティを効率的に検証する非常に重要な機構を加える。これは、この機能なしの実現形態と比較して、上記機能をかなり好適に、かつ／又はスケーラブルにする。
【００９０】
図１８は、本発明の実施例による計算システム１８００のブロック図を示す。計算システム１８００は、相互接続ネットワーク（又はバス）１８０４を介して通信する１つ若しくは複数の中央処理装置（ＣＰＵ）１８０２又はプロセッサを含み得る。プロセッサ１８０２は、汎用プロセッサ、（コンピュータ・ネットワーク１８０３を介して通信されるデータを処理する）ネットワーク・プロセッサ、（縮小命令セット・コンピュータ（ＲＩＳＣ）プロセッサ又は高度命令セット・コンピュータ（ＣＩＳＣ）プロセッサを含む）他のタイプのプロセッサを含み得る。更に、プロセッサ１８０２は、単一又は複数のコア・デザインを有し得る。複数のコア・デザインを有するプロセッサ１８０２は、同じ集積回路（ＩＣ）ダイ上に各種プロセッサ・コアを一体化し得る。更に、複数のコア・デザインを有するプロセッサ１８０２は、対称又は非対称のマルチプロセッサとして実現し得る。一実施例では、プロセッサ１８０２のうちの１つ又は複数は、図１のプロセッサ１０２と同一又は同様であり得る。例えば、プロセッサ１８０２のうちの１つ又は複数は、例えばＯＩＲＭ１２４を含む、図１乃至１７を参照して記載したキャッシュ、記憶デバイス、及び／又はロジックのうちの１つ又は複数を含み得る。更に、図１乃至図１７を参照して説明した動作は、システム１８００の１つ又は複数の構成部分によって行い得る。
【００９１】
チップセット１８０６は、相互接続ネットワーク１８０４とも通信し得る。チップセット１８０６はメモリ制御ハブ（ＭＣＨ）１８０８を含み得る。ＭＣＨ１８０８は、（図１のメモリ１１４と同一又は同様であり得る）メモリ１８１２と通信するメモリ・コントローラ１８１０を含み得る。メモリ１８１２は、計算システム１８００に含まれるＣＰＵ１８０２又は何れかの他のデバイスによって実行し得る命令のシーケンスを含むデータを記憶し得る。本発明の一実施例では、メモリ１８１２は、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、又は他のタイプの記憶デバイスなどの１つ又は複数の揮発性記憶（又はメモリ）デバイスを含み得る。ハード・ディスクなどの不揮発性メモリも利用し得る。複数のＣＰＵ及び／又は複数のシステム・メモリなどの更なるデバイスは、相互接続ネットワーク１８０４を介して通信し得る。
【００９２】
ＭＣＨ１８０８は、ディスプレイ・デバイス１８１６と通信するグラフィクス・インタフェース１８１４も含み得る。本発明の一実施例では、グラフィクス・インタフェース１８１４は、アクセラレーテッド・グラフィクス・ポート（ＡＧＰ）を介してディスプレイ・デバイス１８１６と通信し得る。本発明の一実施例では、（フラット・パネル・ディスプレイなどの）ディスプレイ１８１６は、例えば、ディスプレイ１８１６によって解釈され、表示されるディスプレイ信号にビデオ・メモリ又はシステム・メモリなどの記憶デバイスに記憶されたイメージのディジタル表現を変換する信号変換器を介してグラフィクス・インタフェース１８１４と通信し得る。ディスプレイ・デバイスによって生成されるディスプレイ信号は、ディスプレイ１８１６によって解釈され、その後、ディスプレイ１８１６上に表示される前に種々の制御デバイスを通り得る。
【００９３】
ハブ・インタフェース１８１８は、ＭＣＨ１８０８及び入出力制御ハブ（ＩＣＨ）１８２０が通信することを可能にし得る。ＩＣＨ１８２０は、計算システム１８００と通信するＩ／Ｏデバイスに対するインタフェースを提供し得る。ＩＣＨ１８２０は、周辺装置相互接続（ＰＣＩ）ブリッジ、ユニバーサル・シリアル・バス（ＵＳＢ）コントローラや他のタイプの周辺装置ブリッジ又はコントローラなどの周辺装置ブリッジ（又はコントローラ）１８２４を介してバス１８２２と通信し得る。ブリッジ１８２４は、ＣＰＵ１８０２と周辺装置との間のデータ・パスを提供し得る。他のタイプのトポロジも利用し得る。更に、複数のバスは、例えば、複数のブリッジ又はコントローラを介して、ＩＣＨ１８２０と通信し得る。更に、ＩＣＨ１８２０と通信し合う他の周辺装置は、本発明の種々の実施例において、集積ドライブ・エレクトロニクス（ＩＤＥ）又は小型コンピュータ・システム・インタフェース（ＳＣＳＩ）ハード・ドライブ、ＵＳＢポート、キーボード、マウス、パラレル・ポート、シリアル・ポ―ト、フロッピー（登録商標）ディスク・ドライブ、ディジタル出力サポート（例えば、ディジタル・ビデオ・インタフェース（ＤＶＩ））、又は他のデバイスを含み得る。
【００９４】
バス１８２２は、オーディオ・デバイス１８２６、１つ又は複数のディスク・ドライブ１８２８、及び（コンピュータ・ネットワーク１８０３と通信し合う）ネットワーク・インタフェース・デバイス１８３０と通信し得る。他のデバイスは、バス１８２２を介して通信し得る。更に（ネットワーク・インタフェース・デバイス１８３０などの）種々の構成部分が、本発明の一部の実施例においてＭＣＨ１８０８と通信し得る。更に、（限定列挙でないが、ＭＣＨ１８０８、ＭＣＨ１８０８の１つ又は複数の構成部分等を含む）図１８に示すプロセッサ１８０２及び他の構成部分は、単一のチップを形成するよう組み合わせることができる。更に、グラフィクス・アクセラレータは、本発明の他の実施例においてＭＣＨ１８０８内に含まれ得る。
【００９５】
更に、計算システム１８００は、揮発性及び／又は不揮発性のメモリ（又は記憶装置）を含み得る。例えば、不揮発性メモリは、リードオンリ・メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能なＰＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＰＲＯＭ（ＥＥＰＲＯＭ）、ディスク・ドライブ（例えば、１８２８）、フロッピー（登録商標）・ディスク、コンパクト・ディスクＲＯＭ（ＣＤ−ＲＯＭ）、ディジタル多用途ディスク（ＤＶＤ）、フラッシュ・メモリ、光磁気ディスク、又は、電子データ（例えば、命令を含む）を記憶することができる不揮発性のマシン読み出し可能な他のタイプの媒体のうちの１つ又は複数を含み得る。
【００９６】
図１９は、本発明の実施例による、ポイントツーポイント（ＰｔＰ）構成に配置された計算システム１９００を示す。特に、図１９は、いくつかのポイントツーポイント・インタフェースによってプロセッサ、メモリ及び入出力デバイスが相互接続されたシステムを示す。図１乃至１８を参照して説明した動作は、システム１９００の１つ又は複数の構成部分によって行い得る。
【００９７】
図１９に示すように、システム１９００はいくつかのプロセッサ（明瞭にするために、このうちの２つ、すなわち、プロセッサ１９０２及び１９０４のみを示す）を含み得る。プロセッサ１９０２及び１９０４はそれぞれ、メモリ１９１０及び１９１２との通信を可能にするための局所メモリ・コントローラ・ハブ（ＭＣＨ）１９０６及び１９０８を含み得る。メモリ１９１０及び／又は１９１２は、図１８のメモリ１８１２を参照して説明したものなどの種々のデータを記憶し得る。
【００９８】
一実施例では、プロセッサ１９０２及び１９０４は、（例えば、図１乃至図１８を参照して説明したキャッシュのうちの１つ又は複数を含む、）図１８を参照して説明したプロセッサ１８０２のうちの１つであり得る。プロセッサ１９０２及び１９０４は、ＰｔＰインタフェース回路１９１６及び１９１８それぞれを使用してポイントツーポイント（ＰｔＰ）インタフェース１９１４を介してデータを交換し得る。更に、プロセッサ１９０２及び１９０４はそれぞれ、ポイントツーポイント・インタフェース回路１９２６、１９２８、１９３０及び１９３２を使用して個々のＰｔＰインタフェース１９２２及び１９２４を介してチップセット１９２０とデータを交換し得る。チップセット１９２０は、例えば、ＰｔＰインタフェース回路１９３７を使用して、グラフィクス・インタフェース１９３６を介してグラフィクス回路１９３４とデータを交換し得る。
【００９９】
本発明の少なくとも１つの実施例は、プロセッサ１９０２及び１９０４内に提供し得る。例えば、図１のコア１０６のうちの１つ又は複数は、プロセッサ１９０２及び１９０４内に配置され得る。更に、プロセッサ１９０２及び１９０４は、図１乃至図１８を参照して説明したキャッシュ、記憶デバイス、及び／又はロジックの１つ又は複数を含み得る。例えば、ＯＩＲＭ１２４は、プロセッサ１９０２／１９０４内に提供し得る。しかし、ＯＩＲＭは、図１乃至図１８を参照して説明したような、（例えば、チップセット１９２０におけるプロセッサ１９０２／１９０４とＭＣＨ１９０６／１９０８との間の）他の場所で提供し得る。しかし、本発明の他の実施例は、図１９のシステム１９００内の他の回路、ロジック装置、又はデバイスに存在し得る。更に、本発明の他の実施例は、図１９に示すいくつかの回路、ロジック装置、又はデバイスにわたって分散させ得る。
【０１００】
チップセット１９２０はＰｔＰインタフェース回路１９４１を使用してバス１９４０と通信し得る。バス１９４０は、バス・ブリッジ１９４２やＩ／Ｏデバイス１９４３などの１つ又は複数のデバイスと通信し得る。バス１９４４を介して、バス・ブリッジ１９４２は、（コンピュータ・ネットワーク１８０３と通信し得るモデム、ネットワーク・インタフェース・デバイス、又は他の通信デバイスなどの）通信デバイス１９４６、キーボード／マウス１９４５、オーディオＩ／Ｏデバイス１９４７、及び／又はデータ記憶デバイス１９４８などの他のデバイスと通信し得る。データ記憶デバイス１９４８は、プロセッサ１９０２及び／又は１９０４によって実行し得るコード１９４９を記憶し得る。
【０１０１】
本発明の種々の実施例では、例えば、図１乃至図１９を参照して、本明細書及び特許請求の範囲に記載された動作は、ハードウェア（例えば、論理回路）、ソフトウェア、ファームウェア、又はそれらの組み合わせ（例えば、本明細書及び特許請求の範囲記載の処理を実行するようコンピュータをプログラムするために使用される命令（又はソフトウェア手続）を記憶させたマシン読み取り可能な媒体又はコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム・プロダクトとして提供し得る）であり得る。マシン読み取り可能な媒体は、本明細書及び特許請求の範囲記載のものなどの記憶デバイスを含み得る。更に、前述の有形のコンピュータ読み取り可能な媒体はコンピュータ・プログラム・プロダクトとしてダウンロード可能であり得、プログラムは、通信リンク（例えば、バス、モデム、又はネットワーク接続）を介した伝搬媒体におけるデータ信号により、要求側のコンピュータ（例えば、クライアント）に遠隔コンピュータ（例えば、サーバ）から転送し得る。
【０１０２】
「一実施例」、「実施例」、又は「一部の実施例」に、明細書中で言及していることは、実施例に関して説明する特定の構成、構造又は特性が少なくとも一実現形態に含まれ得るということを意味している。明細書中の種々の箇所において「一実施例における」という句が存在することは、全てが、同じ実施例を表していてもよく、表していなくてもよい。
【０１０３】
更に、本明細書及び特許請求の範囲では、「結合」、「接続」、及びその派生形を使用し得る。本発明の一部の実施例では、「接続」は、２つ以上の構成要素が、互いに直接、物理的に又は電気的に接触しているということを示すために使用し得る。「結合」は、２つ以上の構成要素が直接、物理的又は電気的に接触しているということを意味し得る。しかし、「結合」は、２つ以上の構成要素が互いに直接接触している訳でないが、互いになお協調又は相互作用し得るということも意味し得る。
【０１０４】
よって、本発明の実施例は、構造的な構成及び／又は方法論的な動作に特有の文言で説明してきたが、請求された主題は、上述の特定の構成又は動作に限定されないことがあり得る。むしろ、上記特定の構成及び動作は、請求された主題を実現するサンプル形式として開示している。
【特許請求の範囲】
【請求項１】
装置であって、
複数の区画を有する記憶装置であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する記憶装置と、
前記複数の区画をプロセッサに結合するためのＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）と
を備え、前記ＯＩＲＭは前記第１の区画と前記第２の区画との間で前記プロセッサのサイクルを動的に区画化する記憶装置。
【請求項２】
請求項１記載の装置であって、前記記憶装置は前記第２の区画にＯＩドライバを記憶し、前記ＯＩドライバは、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを前記ＯＩＲＭに示す装置。
【請求項３】
請求項１記載の装置であって、前記ＯＩＲＭは、選択された時間内の実行のためにＯＩＲＭが前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てる装置。
【請求項４】
請求項１記載の装置であって、前記ＯＩＲＭは前記プロセッサのアイドル・サイクルを前記第１の区画に割り当てる装置。
【請求項５】
請求項１記載の装置であって、前記プロセッサは１つ又は複数のプロセッサ・コアを含み、前記ＯＩＲＭは、Ｃ０状態における前記１つ又は複数のプロセッサ・コアのうちの１つからサイクルを割り当てるか、Ｃ−Ｘ状態における前記１つ又は複数のプロセッサ・コアのうちの別の１つをウェイクするかを判定する装置。
【請求項６】
請求項１記載の装置であって、前記第１の区画は、前記第１の区画に記憶された第１の割り込み再マップ・テーブルに応じて割り込みが処理されるか、前記第２の区画に記憶された第２の割り込み再マップ・テーブルに応じて割り込みが処理されるかを示すためのデバイス・フィルタを含む装置。
【請求項７】
請求項６記載の装置であって、前記割り込みを受け取り、前記デバイス・フィルタをルックアップさせるための割り込み再マッピング装置を更に含む装置。
【請求項８】
請求項１記載の装置であって、前記ＯＩＲＭは、レンジ・レジスタの１つ又は複数のビットに基づいて前記第２の区画から前記第１の区画へのアクセスをブロックする装置。
【請求項９】
請求項１記載の装置であって、前記ＯＩＲＭは、前記第１の区画に記憶された、拡張ページ・テーブルに記憶されたデータに基づいて前記第１の区画から前記第２の区画へのアクセスをブロックする装置。
【請求項１０】
請求項１記載の装置であって、前記プロセッサは、暗号化されていない情報を記憶するためのメモリを備え、前記暗号化されていない情報は、前記プロセッサの外部では利用可能でない装置。
【請求項１１】
請求項１記載の装置であって、前記第１の区画の１つ又は複数のページに対応するデータを記憶するためのインテグリティ検査値アレイを更に含み、前記アレイにおける各エントリは、セキュアなハッシュ・アルゴリズム値、バリディティ、及び、前記第１の区画における対応するページの直接メモリ・アクセスを示す装置。
【請求項１２】
請求項１１記載の装置であって、前記ＯＩＲＭは、前記インテグリティ検査値アレイの対応するエントリに記憶された値に基づいて前記第１のパーティションの前記１つ又は複数のページのインテグリティを判定する装置。
【請求項１３】
請求項１１記載の装置であって、前記ＯＩＲＭは、前記第１の区画の対応するページに対する修正の検出に応じて前記インテグリティ検査値アレイに記憶された値に対して更新をもたらす装置。
【請求項１４】
方法であって、
メモリに複数の区画を記憶する工程であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する工程と、
前記複数の区画をプロセッサにＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）を介して結合する工程と、
前記ＯＩＲＭが、前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを割り当てる工程と
を含む方法。
【請求項１５】
請求項１４記載の方法であって、前記第２の区画にＯＩドライバを記憶する工程を更に含み、前記ＯＩドライバは、前記ＯＩＲＭに対して、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを示す方法。
【請求項１６】
請求項１４記載の方法であって、選択された時間内の実行のために１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を前記ＯＩＲＭが割り当てる工程を更に含む方法。
【請求項１７】
請求項１４記載の方法であって、前記ＯＩＲＭは前記プロセッサのアイドル・サイクルを前記第１の区画に割り当てる工程を更に含む方法。
【請求項１８】
請求項１４記載の方法であって、前記ＯＩＲＭが、Ｃ０状態における前記プロセッサの１つ又は複数のプロセッサ・コアからのサイクルを割り当てるか、Ｃ−Ｘ状態における前記１つ又は複数のプロセッサ・コアのうちの別の１つをウェイクするかを判定する工程を更に含む方法。
【請求項１９】
請求項１４記載の方法であって、前記第１の区画に記憶されたデバイス・フィルタが、前記第１の区画に記憶された第１の割り込み再マップ・テーブルに応じて割り込みを処理するか、前記第２の区画に記憶された第２の割り込み再マップ・テーブルに応じて割り込みを処理するかを示す工程を更に含む方法。
【請求項２０】
請求項１４記載の方法であって、前記ＯＩＲＭは、レンジ・レジスタの１つ又は複数のビットに基づいて前記第２の区画から前記第１の区画へのアクセスをブロックする工程を更に含む方法。
【請求項２１】
請求項１４記載の方法であって、インテグリティ検査値アレイに前記第１の区画の１つ又は複数のページに対応するデータを記憶する工程を更に含み、前記アレイにおける各エントリは、セキュアなハッシュ・アルゴリズム値、バリディティ、及び、前記第１の区画における対応するページの直接メモリ・アクセスを示す方法。
【請求項２２】
プロセッサ上で実行されると、
複数の区画をメモリに記憶する工程であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する工程と、
前記複数の区画を前記プロセッサにＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）を介して結合する工程であって、前記ＯＩＲＭは前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを割り当てる工程と
を行うよう前記プロセッサを構成する１つ又は複数の命令を含むコンピュータ読み取り可能な媒体。
【請求項２３】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記第２の区画にＯＩドライバを記憶するよう前記プロセッサを構成する１つ又は複数の命令を更に含み、前記ＯＩドライバは、前記第１の区画に記憶された１つ又は複数の命令が、実行するためにスケジューリングされるか否かを前記ＯＩＲＭに示すコンピュータ読み取り可能な媒体。
【請求項２４】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、選択された期間内に実行するために前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てるよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２５】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記インテグリティ検査値アレイの対応するエントリに記憶された値に基づいて前記第１の区画の前記１つ又は複数のページのインテグリティを判定するよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２６】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記第１の区画の対応するページに対する修正の検出に応じて前記インテグリティ検査値アレイに記憶された値に対する更新をもたらすよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２７】
計算システムであって、
命令を記憶するためのメモリであって、前記メモリは複数の区画を含み、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶するメモリと、
前記命令を実行するためのプロセッサと、
前記複数の区画を前記プロセッサに結合するためのＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）と
を備え、前記ＯＩＲＭは、前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを動的に区画化するシステム。
【請求項２８】
請求項２７記載のシステムであって、前記メモリは前記第２の区画にＯＩドライバを記憶し、前記ＯＩドライバは、前記ＯＩＲＭに対して、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを示すシステム。
【請求項２９】
請求項２７記載のシステムであって、ＯＩＲＭは、選択された時間内の実行のために前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てるシステム。
【請求項３０】
請求項２７記載のシステムであって、前記プロセッサ・コアに結合されたオーディオ・デバイスを更に含むシステム。
【請求項１】
装置であって、
複数の区画を有する記憶装置であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する記憶装置と、
前記複数の区画をプロセッサに結合するためのＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）と
を備え、前記ＯＩＲＭは前記第１の区画と前記第２の区画との間で前記プロセッサのサイクルを動的に区画化する記憶装置。
【請求項２】
請求項１記載の装置であって、前記記憶装置は前記第２の区画にＯＩドライバを記憶し、前記ＯＩドライバは、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを前記ＯＩＲＭに示す装置。
【請求項３】
請求項１記載の装置であって、前記ＯＩＲＭは、選択された時間内の実行のためにＯＩＲＭが前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てる装置。
【請求項４】
請求項１記載の装置であって、前記ＯＩＲＭは前記プロセッサのアイドル・サイクルを前記第１の区画に割り当てる装置。
【請求項５】
請求項１記載の装置であって、前記プロセッサは１つ又は複数のプロセッサ・コアを含み、前記ＯＩＲＭは、Ｃ０状態における前記１つ又は複数のプロセッサ・コアのうちの１つからサイクルを割り当てるか、Ｃ−Ｘ状態における前記１つ又は複数のプロセッサ・コアのうちの別の１つをウェイクするかを判定する装置。
【請求項６】
請求項１記載の装置であって、前記第１の区画は、前記第１の区画に記憶された第１の割り込み再マップ・テーブルに応じて割り込みが処理されるか、前記第２の区画に記憶された第２の割り込み再マップ・テーブルに応じて割り込みが処理されるかを示すためのデバイス・フィルタを含む装置。
【請求項７】
請求項６記載の装置であって、前記割り込みを受け取り、前記デバイス・フィルタをルックアップさせるための割り込み再マッピング装置を更に含む装置。
【請求項８】
請求項１記載の装置であって、前記ＯＩＲＭは、レンジ・レジスタの１つ又は複数のビットに基づいて前記第２の区画から前記第１の区画へのアクセスをブロックする装置。
【請求項９】
請求項１記載の装置であって、前記ＯＩＲＭは、前記第１の区画に記憶された、拡張ページ・テーブルに記憶されたデータに基づいて前記第１の区画から前記第２の区画へのアクセスをブロックする装置。
【請求項１０】
請求項１記載の装置であって、前記プロセッサは、暗号化されていない情報を記憶するためのメモリを備え、前記暗号化されていない情報は、前記プロセッサの外部では利用可能でない装置。
【請求項１１】
請求項１記載の装置であって、前記第１の区画の１つ又は複数のページに対応するデータを記憶するためのインテグリティ検査値アレイを更に含み、前記アレイにおける各エントリは、セキュアなハッシュ・アルゴリズム値、バリディティ、及び、前記第１の区画における対応するページの直接メモリ・アクセスを示す装置。
【請求項１２】
請求項１１記載の装置であって、前記ＯＩＲＭは、前記インテグリティ検査値アレイの対応するエントリに記憶された値に基づいて前記第１のパーティションの前記１つ又は複数のページのインテグリティを判定する装置。
【請求項１３】
請求項１１記載の装置であって、前記ＯＩＲＭは、前記第１の区画の対応するページに対する修正の検出に応じて前記インテグリティ検査値アレイに記憶された値に対して更新をもたらす装置。
【請求項１４】
方法であって、
メモリに複数の区画を記憶する工程であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する工程と、
前記複数の区画をプロセッサにＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）を介して結合する工程と、
前記ＯＩＲＭが、前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを割り当てる工程と
を含む方法。
【請求項１５】
請求項１４記載の方法であって、前記第２の区画にＯＩドライバを記憶する工程を更に含み、前記ＯＩドライバは、前記ＯＩＲＭに対して、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを示す方法。
【請求項１６】
請求項１４記載の方法であって、選択された時間内の実行のために１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を前記ＯＩＲＭが割り当てる工程を更に含む方法。
【請求項１７】
請求項１４記載の方法であって、前記ＯＩＲＭは前記プロセッサのアイドル・サイクルを前記第１の区画に割り当てる工程を更に含む方法。
【請求項１８】
請求項１４記載の方法であって、前記ＯＩＲＭが、Ｃ０状態における前記プロセッサの１つ又は複数のプロセッサ・コアからのサイクルを割り当てるか、Ｃ−Ｘ状態における前記１つ又は複数のプロセッサ・コアのうちの別の１つをウェイクするかを判定する工程を更に含む方法。
【請求項１９】
請求項１４記載の方法であって、前記第１の区画に記憶されたデバイス・フィルタが、前記第１の区画に記憶された第１の割り込み再マップ・テーブルに応じて割り込みを処理するか、前記第２の区画に記憶された第２の割り込み再マップ・テーブルに応じて割り込みを処理するかを示す工程を更に含む方法。
【請求項２０】
請求項１４記載の方法であって、前記ＯＩＲＭは、レンジ・レジスタの１つ又は複数のビットに基づいて前記第２の区画から前記第１の区画へのアクセスをブロックする工程を更に含む方法。
【請求項２１】
請求項１４記載の方法であって、インテグリティ検査値アレイに前記第１の区画の１つ又は複数のページに対応するデータを記憶する工程を更に含み、前記アレイにおける各エントリは、セキュアなハッシュ・アルゴリズム値、バリディティ、及び、前記第１の区画における対応するページの直接メモリ・アクセスを示す方法。
【請求項２２】
プロセッサ上で実行されると、
複数の区画をメモリに記憶する工程であって、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶する工程と、
前記複数の区画を前記プロセッサにＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）を介して結合する工程であって、前記ＯＩＲＭは前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを割り当てる工程と
を行うよう前記プロセッサを構成する１つ又は複数の命令を含むコンピュータ読み取り可能な媒体。
【請求項２３】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記第２の区画にＯＩドライバを記憶するよう前記プロセッサを構成する１つ又は複数の命令を更に含み、前記ＯＩドライバは、前記第１の区画に記憶された１つ又は複数の命令が、実行するためにスケジューリングされるか否かを前記ＯＩＲＭに示すコンピュータ読み取り可能な媒体。
【請求項２４】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、選択された期間内に実行するために前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てるよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２５】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記インテグリティ検査値アレイの対応するエントリに記憶された値に基づいて前記第１の区画の前記１つ又は複数のページのインテグリティを判定するよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２６】
請求項２２記載のコンピュータ読み取り可能な媒体であって、前記プロセッサ上で実行されると、前記第１の区画の対応するページに対する修正の検出に応じて前記インテグリティ検査値アレイに記憶された値に対する更新をもたらすよう前記プロセッサを構成する１つ又は複数の命令を更に含むコンピュータ読み取り可能な媒体。
【請求項２７】
計算システムであって、
命令を記憶するためのメモリであって、前記メモリは複数の区画を含み、前記複数の区画からの第１の区画はオペレーティング・システム（ＯＳ）独立区画を記憶し、前記複数の区画からの第２の区画はＯＳを記憶するメモリと、
前記命令を実行するためのプロセッサと、
前記複数の区画を前記プロセッサに結合するためのＯＳ独立（ＯＩ）リソース・マネージャ（ＯＩＲＭ）と
を備え、前記ＯＩＲＭは、前記第１の区画と前記第２の区画との間の前記プロセッサのサイクルを動的に区画化するシステム。
【請求項２８】
請求項２７記載のシステムであって、前記メモリは前記第２の区画にＯＩドライバを記憶し、前記ＯＩドライバは、前記ＯＩＲＭに対して、前記第１の区画に記憶された１つ又は複数の命令が、実行のためにスケジューリングされるか否かを示すシステム。
【請求項２９】
請求項２７記載のシステムであって、ＯＩＲＭは、選択された時間内の実行のために前記１つ又は複数の命令をＯＩＲＭがスケジューリングすることができなかった旨の判定に基づいて前記第１の区画に記憶された１つ又は複数の命令に対して最小保証実行持続時間を割り当てるシステム。
【請求項３０】
請求項２７記載のシステムであって、前記プロセッサ・コアに結合されたオーディオ・デバイスを更に含むシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公表番号】特表２０１２−５０８９４０（Ｐ２０１２−５０８９４０Ａ）
【公表日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願番号】特願２０１１−５３６６３２（Ｐ２０１１−５３６６３２）
【出願日】平成２１年１２月２２日（２００９．１２．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０６９１３６
【国際公開番号】ＷＯ２０１０／０７８１４３
【国際公開日】平成２２年７月８日（２０１０．７．８）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公表日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願日】平成２１年１２月２２日（２００９．１２．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０６９１３６
【国際公開番号】ＷＯ２０１０／０７８１４３
【国際公開日】平成２２年７月８日（２０１０．７．８）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]