JP2022509722A - 例外原因イベントをハンドリングするための装置及び方法 - Google Patents

Abstract

例外原因イベントをハンドリングするための装置及び方法が提供される。第１の処理ユニットは、プログラム・コードを実行するために提供され、第２の処理ユニットも提供される。第１の処理ユニットは、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された制御インターフェースを備える。第１の処理ユニットは、少なくとも１つの例外原因イベントに応答して、プログラム・コードの実行を停止して、トリガ・イベントを発行する停止モードに入る。第２の処理ユニットは、トリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて第１の処理ユニットの状態情報を修正するために、制御インターフェースを介して状態情報にアクセスするように配置構成された例外ハンドリング・ルーチンを実行する。第２の処理ユニットは、例外ハンドリング・ルーチンの完了時に、第１の処理ユニットが停止モードを終了してプログラム・コードの実行を再開するように配置構成される。このようなアプローチは、第１の処理ユニットによって実行されているプログラム・コードと、例外ハンドリング・ルーチンを実行するために使用されるソフトウェアとの間の物理的分離を可能にし、これにより、システム内のセキュリティが著しく改善される。

Description

本技法は、例外原因イベントをハンドリングするための装置及び方法に関する。

処理ユニット上でソフトウェアを実行するとき、イベントが生じ、例外が発生する可能性がある。このとき、例外原因イベントをハンドリングするために、割込サービス・ルーチンの実行が行われる可能性がある。しばしば、割込サービス・ルーチンは、ソフトウェア実行特権のより高いレベルで実行され、実行により例外原因イベントが発生するコードより信頼できるコードの一部であることが可能である。いくつかの実例の実装形態において、ソフトウェア実行特権のレベルは、例外レベルと呼ばれることがあり、したがって、ソフトウェアの特定の部分の実行中に例外原因イベントが発生するとき、より高い例外レベルで割込サービス・ルーチンを実行するために、このより高い例外レベルに遷移するケースがある可能性がある。

このようなシステムにおいて、より信頼できるコードと関連付けられたデータに、あまり信頼できないコードがアクセスするリスクを緩和するために、システム内のセキュリティのレベルを上げることが望ましい。

１つの実例の構成において、プログラム・コードを実行するための第１の処理ユニットと、第２の処理ユニットとを備え、第１の処理ユニットが、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された制御インターフェースを備え、第１の処理ユニットが、少なくとも１つの例外原因イベントに応答して、第１の処理ユニットがプログラム・コードの実行を停止しトリガ・イベントを発行する停止モードに入り、第２の処理ユニットが、トリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて第１の処理ユニットの状態情報を修正するために、制御インターフェースを介して状態情報にアクセスするように第２の処理ユニットが配置構成された例外ハンドリング・ルーチンを実行し、第２の処理ユニットが、例外ハンドリング・ルーチンの完了時に、第１の処理ユニットが停止モードを終了してプログラム・コードの実行を再開するように配置構成される、システムが提供される。

別の実例の構成において、プログラム・コードを実行するための実行回路と、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された制御インターフェースと、を備え、第１の処理ユニットが、少なくとも１つの例外原因イベントに応答して、実行回路がプログラム・コードの実行を停止し、トリガ・イベントが発行される停止モードに入り、制御インターフェースが、第２の処理ユニットが例外ハンドリング・ルーチンによる要求に応じて第１の処理ユニットの状態情報にアクセスして修正できるように、トリガ・イベントに応答して第２の処理ユニットが例外ハンドリング・ルーチンを実行している間に第２の処理ユニットがアクセスできるように配置構成され、第１の処理ユニットが、第２の処理ユニットが例外ハンドリング・ルーチンを完了したとき、停止モードを終了してプログラム・コードの実行を再開するように配置構成される、第１の処理ユニットが提供される。

さらなる実例の構成において、第１の処理ユニットによって発行されたトリガ・イベントに応答して例外ハンドリング・ルーチンを実行するための実行回路であって、トリガ・イベントが、第１の処理ユニットによるプログラム・コードの実行が停止される停止モードに第１の処理ユニットが入ったことを示す、実行回路と、例外ハンドリング・ルーチンを実行している間に、第２の処理回路が第１の処理ユニットの制御インターフェースにアクセスするように配置構成される通信インターフェースであって、制御インターフェースが、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成される、通信インターフェースと、を備え、第２の処理ユニットが、例外ハンドリング・ルーチンによる要求に応じて第１の処理ユニットの状態情報を修正するために、制御インターフェースを介して状態情報にアクセスするように配置構成され、第２の処理ユニットが、例外ハンドリング・ルーチンの完了時に、第１の処理ユニットが停止モードを終了してプログラム・コードの実行を再開するように配置構成される、第２の処理ユニットが提供される。

さらなる実例の構成において、プログラム・コードを実行するための第１の処理ユニット、及び第２の処理ユニット、を備えるシステムにおいて例外原因イベントをハンドリングする方法が提供され、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された制御インターフェースを第１の処理ユニットに提供することと、第１の処理ユニット内の少なくとも１つの例外原因イベントに応答して、第１の処理ユニットがプログラム・コードの実行を停止しトリガ・イベントを発行する停止モードに第１の処理ユニットを入れることと、第２の処理ユニットがトリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて第１の処理ユニットの状態情報を修正するために、制御インターフェースを介して状態情報にアクセスする例外ハンドリング・ルーチンを実行することと、第２の処理ユニットによる例外ハンドリング・ルーチンの完了時に、第１の処理ユニットが停止モードを終了して、プログラム・コードの実行を再開することと、を含む。

別の実例の構成において、プログラム・コードを実行するための第１の処理手段と、第２の処理手段と、を有し、第１の処理手段が、第１の処理手段の状態情報への直接マップ式アクセスを第２の処理手段に提供するために、第２の処理手段のメモリ・アドレス空間にマッピングされた制御インターフェース手段を有し、第１の処理手段が、プログラム・コードの実行を停止する停止モードに入ることによって、及びトリガ・イベントを発行することによって、少なくとも１つの例外原因イベントに応答するためのものであり、第２の処理手段が、トリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて状態情報を修正するために、制御インターフェース手段を介して第１の処理手段の状態情報にアクセスするように配置構成された例外ハンドリング・ルーチンを実行するためのものであり、第２の処理手段が、例外ハンドリング・ルーチンの完了時に、第１の処理手段が停止モードを終了してプログラム・コードの実行を再開するためのものである、システムが提供される。

本技法は、添付の図面に示されるような実例を参照しながら、例証のみを目的としてさらに説明される。

１つの実例の実装形態によるシステム内で提供される構成要素を示すブロック図である。 １つの実例の実装形態による図１のメモリ・マップ式制御インターフェース内に提供されることが可能な記憶素子をより詳細に示す図である。 １つの実例の実装形態による例外のハンドリングを示す流れ図である。 本技法を使用しない例外のハンドリングを示す図である。 本技法を使用するときの例外のハンドリングを示す図である。 本明細書において説明される技法が利用されることが可能な処理ユニットの実例の実装形態を示す図である。 本明細書において説明される技法が利用されることが可能な処理ユニットの実例の実装形態を示す図である。 １つの実例の配置構成による例外ハンドリングをネストできるように、本明細書において説明される技法をどのように実行できるかを示す図である。 いくつかの異なる制御コアのうちの１つに割込みを分配するために割込分配器が使用される代替の実例の構成を示す図である。 キャッシュの少なくとも１つのレベルが、アプリケーション・コアと制御コアとの間で共有されることが可能な実例の配置構成を示す図である。

１つの実例の構成において、システムは、プログラム・コードを実行するための第１の処理ユニット、及び第２の処理ユニットを提供することができる。第２の処理ユニットは、プログラム・コードを実行することも可能であるが、本明細書において説明される技法は、第１の処理ユニットによるプログラム・コードの実行中に例外原因イベントが発生する状況において、第２の処理ユニットがどのように使用されるかということに関心がある。

第１の処理ユニットは、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された制御インターフェースが提供される。したがって、制御インターフェースを介して、第２の処理ユニットは、第１の処理ユニットの状態のうちの少なくともいくつかへの直接マップ式アクセスを提供される。

第１の処理ユニットは、少なくとも１つの例外原因イベントに応答して、プログラム・コードの実行を停止して、トリガ・イベントを発行する停止モードに入るように配置構成される。第２の処理ユニットは、次に、このようなトリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて状態情報を修正するために、制御インターフェースを介して第１の処理ユニットの状態情報にアクセスできる例外ハンドリング・ルーチンを実行するように配置構成される。したがって、第１の処理ユニット自体が必要に応じてソフトウェア実行特権のより高いレベルに最初に遷移して、必要な例外ハンドリング・ルーチンを実行することになる通常のアプローチとは対照的に、本明細書において説明される技法によれば、第１の処理ユニットは例外ハンドリング・ルーチンを実行せず、代わりに例外ハンドリング・ルーチンは、別個の処理ユニットによって実行される。したがってこれは、自分のプログラム・コードを実行する第１の処理ユニットと、第１の処理ユニットの代わりに例外ハンドリング・ルーチンを実行するために使用される別個の処理ユニットとの間の物理的分離を達成できるようにする。これにより、システム内のセキュリティを著しく向上させることができる。

例外ハンドリング・ルーチンの完了時、第２の処理ユニットは、次に、第１の処理ユニットが停止モードを終了してプログラム・コードの実行を再開するように配置構成されることが可能である。第２の処理ユニットは、第１の処理ユニットの制御インターフェースを介して必要な状態情報にアクセスできるので、第１の処理ユニットの代わりに例外ハンドリング・ルーチンを実行している間、必要に応じて第１の処理ユニットの状態を効率的に操作することができ、やがて第１の処理ユニットが停止モードを終了するとき、例外原因イベントをハンドリングするために、必要に応じて更新された状態でプログラム・コードの実行を適切に再開できるようにする。

このようにして、第２の処理ユニットのメモリ・アドレス空間にマッピングされた制御インターフェースを第１の処理ユニットに装備し、第１の処理ユニットの関連状態情報への直接マップ式アクセスを第２の処理ユニットが行えるようにすることによって、例外原因イベントによって引き起こされる例外に対処するのに必要な例外ハンドリング・ルーチンの実行は、第１の処理ユニットから、物理的に別個の処理ユニットに退避させることができ、これにより、信頼できないコードから信頼できるデータへのアクセス権を得ようとする可能性のある一定のタイプの攻撃の可能性を著しく緩和する。

第１の処理ユニットの制御インターフェースを介して第２の処理ユニットが直接マップ式アクセスを行えるようにする状態情報は、様々な形式であることが可能である。１つの実例の実装形態において、このような状態情報は、プログラム・コードを実行するときに第１の処理ユニットによって処理されるデータを格納するために使用される第１の処理ユニットのレジスタのセットの内容を含む。したがって、第２の処理ユニットでの例外ハンドリング・ルーチンの実行中、第２の処理ユニットは、第１の処理ユニットの制御インターフェースを使用して効率的にこれらのレジスタの内容を読み、必要に応じてこれらのレジスタの内容を更新することができる。

第１の処理ユニットのレジスタの上述のセットへの直接マップ式アクセスを第２の処理ユニットに提供するように制御インターフェースが配置構成されることが可能ないくつかの方式がある。１つの実例の配置構成において、制御インターフェースは、第２の処理ユニットによるレジスタのセットへの直接マップ式アクセスを提供するために、第２の処理ユニットのメモリ・アドレス空間にマッピングされた記憶素子のセットを提供する。したがって、セット内の各記憶素子は、第２の処理ユニットによってアドレス指定され、第１の処理ユニットのレジスタのセット内の対応するレジスタに直接マッピングされることが可能である。結果として、これらの記憶素子のうちの１つに第２の処理ユニットがリード・アクセス又はライト・アクセスを行うときはいつでも、これは、第１の処理ユニットのレジスタのセット内の関連付けられたレジスタへの対応するリード・アクセス又はライト・アクセスをトリガするために使用される。

第１の処理ユニットのレジスタのセットへのアクセスに加えて、又はその代わりに、第２の処理ユニットは、第１の処理ユニットのメモリ・アドレス空間の少なくとも一部への直接マップ式アクセスを行える可能性があり、したがって、制御インターフェースを介して第２の処理ユニットが利用できるようになる第１の処理ユニットの状態情報の少なくとも一部は、第１の処理ユニットのメモリ・アドレス空間の一部であることが可能である。

１つの実例の配置構成において、第１の処理ユニットのメモリ・アドレス空間のこのような部分は、第２の処理ユニットの１次アドレス空間とは別個の第２の処理ユニットの２次アドレス空間を形成するように配置構成されることが可能である。第２の処理ユニットが２次アドレス空間にアクセスできるように提供されることが可能ないくつかのメカニズムがある。例えば、このために別個のロード命令／格納命令が使用されることが可能であり、又は、１次アドレス空間内でメモリ・アクセスを発生させるか、２次アドレス空間内でメモリ・アクセスを発生させるかに影響を与えるように、メモリ・アドレスを発生させるときに第２の処理ユニットによって使用されるアドレス・レジスタの非アドレス部にタグ・ビットが追加されることが可能である。

しかし、上記で示されるような２次アドレス空間を提供するには、一定の構造上の変更をシステムに対して行う必要がある可能性が高い。代替実装形態において、このような構造上の変更は、第１の処理ユニットのメモリ・アドレス空間の関連部分を第２の処理ユニットの１次アドレス空間にマッピングすることによって回避することができる。例えば、制御インターフェースは、第２の処理ユニットのメモリ・アドレス空間にマッピングされた記憶素子のブロックを提供することができ、ブロック内の各記憶素子は、第１の処理ユニットのメモリ・アドレス空間の少なくとも一部の中の対応するメモリ・ロケーションに直接マッピングされる。したがって、このような事例において、第１の処理ユニットの関連メモリ・アドレス空間は、第１の処理ユニットのレジスタの以前に言及されたセットがアクセスされることが可能な方式とほぼ同じ方式で、第２の処理ユニットによってアクセスされることが可能である。

制御インターフェース内の記憶素子のブロックが、第１の処理ユニットのメモリ・アドレス空間の一部の様々なメモリ・ロケーションとどのように関連付けられるかについて構成できることを可能にするために、制御インターフェースは、記憶素子のブロック内の記憶素子と、第１の処理ユニットのメモリ・アドレス空間の少なくとも一部の中の対応するメモリ・ロケーションとの間の直接マッピングを識別するように構成可能なマッピング・ストレージを備えることができる。

１つの実例の実装形態において、第１の処理ユニットがプログラム・コードを実行している間に発生するいずれかの例外原因イベントは、上述の手法で、すなわち、第１の処理ユニットが停止モードに入り、トリガ・イベントを発行することでハンドリングされることが可能である。しかし、他の実装形態において、これは、一定の例外原因イベントのために発生することだけに制限される可能性がある一方で、他の例外原因イベントは、従来の手法で、すなわち、第１の処理ユニット自体の中で、場合によっては、例外ハンドリング・ルーチンを実行する前に第１の処理ユニットの例外レベルの遷移と共に、ハンドリングされることが可能である。

１つの実装形態において、制御インターフェースは、第１の処理ユニットによるプログラム・コードの実行中に遭遇したときどの例外原因イベントが第１の処理ユニットを停止モードに入れトリガ・イベントを発行させることになるかを識別するように構成可能な例外イベント識別ストレージをさらに備えることができる。したがって、第１の処理ユニットは、例外原因イベントを検出すると、停止モードに入り、トリガ・イベントを発行することが妥当であるかどうかを判定できるように構成可能な例外イベント識別ストレージの内容によって制御されることが可能である。

このようなアプローチは、上述の技法の使用時に大きな柔軟性をもたらす。具体例のユース・ケースとして、例外イベント識別ストレージは、第１の処理ユニットによって例外原因イベントがハンドリングされる場合、第１の処理ユニットが指定の例外レベルに遷移することが必要になるはずの例外原因イベントが発生したときはいつでも、第１の処理ユニットが停止モードに入り、トリガ・イベントを発行することになるということを識別するように構成されることが可能である。したがって、第１の処理ユニット内の例外原因イベントのハンドリングによって、第１の処理ユニットが指定の例外レベルに遷移しないはずの状況において、必要な例外ハンドリング・ルーチンを第１の処理ユニット自体が実行できることにしてもよいが、第１の処理ユニットが指定の例外レベル（又は代替として、指定の例外レベル又はより高い例外レベル）に遷移する必要があるはずの状況において、このステップを行う代わりに第１の処理ユニットが停止モードに入り、トリガ・イベントを発行するように配置構成してもよく、したがって、物理的に別個の第２の処理ユニットが必要な例外ハンドリング・ルーチンを実行する。

１つの実例の実装形態において、第１の処理ユニットは、停止モードに入るとき、第１の処理ユニットの現在の例外レベルのままであるように配置構成され、第２の処理ユニットは、選ばれた例外レベルで例外ハンドリング・ルーチンを実行するように配置構成される。したがって、上述の技法を使用して例外原因イベントが処理され、第１の処理ユニットは、第１の処理ユニットの現在の例外レベルを変更する必要はない。代わりに第１の処理ユニットは、第１の処理ユニットの現在の例外レベルのまま、停止モードに入るだけであり、やがて停止モードを終了するように命令されるとき、この現在の例外レベルでプログラム・コードの実行を再開することができる。これは、例外ハンドリング・ルーチンを処理するために第１の処理ユニットが異なる例外レベルに遷移する場合に別途必要とされる可能性のあるステップを、第１の処理ユニットが行う必要をなくす。このようなステップは、例えば、現在の実行状態及び復帰アドレスを保存すること、必要なモード／例外レベルに入ること、場合によっては、ローカル・キャッシュ等の一時ストレージから一定のデータをフラッシュすること、等を含むことが可能である。したがって、本明細書において説明される技法を採用することによって実現されることが可能なセキュリティの恩恵に加えて、一定の効率性の恩恵も、いくつかの実装形態において実現されることが可能である。

第２の処理ユニットが例外ハンドリング・ルーチンを実行する選ばれた例外レベルは、様々な形式であることが可能である。例えば、いくつかの事例において、第２の処理ユニットの選ばれた例外レベルが、第１の処理ユニットの現在の例外レベルと同じであるというものであることが可能である。しかし、１つの特定の実装形態において、選ばれた例外レベルは、第１の処理ユニットの現在の例外レベルより高い例外レベルである。

１つの実装形態において、トリガ・イベントは、第１の処理ユニットが停止モードに入った理由を第２の処理ユニットが識別するのを支援するために一定の情報を組み込むことができる。しかし、トリガ・イベント自体を補う代わりに、１つの実装形態において、制御インターフェースは、第２の処理ユニットによって使用される情報を提供して、第１の処理ユニットが停止モードに入った理由を識別するのを支援するために、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第１の処理ユニットによって書き込まれるシンドローム・ストレージを備えることができる。したがって、第２の処理ユニットがトリガ・イベントをハンドリングするとき、第２の処理ユニットは、シンドローム・ストレージにリード・アクセスを行い、第１の処理ユニットが停止モードに入った理由を識別するのを支援するための情報を取得することができ、このことにより、例外原因イベントをハンドリングするのに必要な処理の効率を改善する。

第１の処理ユニットと第２の処理ユニットとの間に１対１のマッピングがある必要はない。例えば、第２の処理ユニットは、プログラム・コードを実行している様々な異なる処理ユニットの代わりに、上述の機能を実行することができる。例えば、１つの実例の配置構成において、システムは、第２の処理ユニットのメモリ・アドレス空間にマッピングされ、第３の処理ユニットの状態情報への直接マップ式アクセスを第２の処理ユニットに提供するように構成された、さらなる制御インターフェースを備える第３の処理ユニットをさらに備えることができる。第３の処理ユニットは、少なくとも１つの例外原因イベントに応答して、実行を停止して、トリガ・イベントを発行する停止モードに入ることが可能である。トリガ・イベントは、トリガ・イベントが第１の処理ユニットによって発行されたか、それとも第３の処理ユニットによって発行されたか、第２の処理ユニットが判定し、例外ハンドリング・ルーチンを実行するとき、第１と第３の処理ユニットのどちらにアクセスするべきかを判定できる情報を保持することができる。したがって、この事例において、第２の処理ユニットは、第１の処理ユニットと第３の処理ユニット両方の代わりに例外ハンドリング・ルーチンを実行することができ、第２の処理ユニットのメモリ・アドレス空間にマッピングされた関連付けられた制御インターフェースを介して必要に応じてどちらかの処理ユニットの必要な状態情報にアクセスすることができる。

１つの実例の実装形態において、例外のハンドリングは、システム内で複数のレベルにネストされることが可能である。したがって、第２の処理ユニットが第１の処理ユニットの代わりに例外をハンドリングできる一方で、第１の処理ユニット自体は、コードを実行している間に発生する例外原因イベントが追加の処理ユニットによってハンドリングされるように配置構成されることが可能である。したがって、１つの実例の配置構成において、システムは、追加の処理ユニットをさらに備えることができ、第２の処理ユニットは、追加の処理ユニットのメモリ・アドレス空間にマッピングされ、第２の処理ユニットの状態情報への直接マップ式アクセスを追加の処理ユニットに提供するように構成された第２の制御インターフェースを備える。第２の処理ユニットは、次に、第２の処理ユニット上でのプログラム・コードの実行中に生じる少なくとも１つの例外原因イベントに応答して、第２の処理ユニット上で実行されているプログラム・コードの実行を停止して、さらなるトリガ・イベントを発行する停止モードに入ることが可能である。追加の処理ユニットは、次に、さらなるトリガ・イベントに応答して、さらなる例外ハンドリング・ルーチンによる要求に応じて第２の処理ユニットの状態情報を修正するために、第２の制御インターフェースを介して状態情報にアクセスするように配置構成された、さらなる例外ハンドリング・ルーチンを実行する。追加の処理ユニットは、次に、さらなる例外ハンドリング・ルーチンの完了時に、第２の処理ユニットが停止モードを終了して、第２の処理ユニット上で実行されているプログラム・コードの実行を再開するように配置構成される。

このようなアプローチによって、必要に応じてネストのいずれかの任意のレベルが達成されることが可能であるということが理解されよう。このような実装形態によれば、各個々の処理ユニットは、システム内の利用可能な例外レベルのサブセットで動作することだけができるように構成されることが可能である。実際は、一端において、全ての個々の処理ユニットは、より高い例外レベルに遷移させたはずのいずれかの例外原因イベントが現在の処理ユニットによって処理される代わりに、現在の処理ユニットが停止モードに入ってトリガ・イベントを発行し、このトリガ・イベントが次に、このより高い例外レベルで動作する別の処理ユニットによって処理されることによって処理される場合、これらのいずれかの例外原因イベントによって、単一の例外レベルで実行するようにのみ配置構成されることが可能である。

システム内の様々な処理ユニットは、様々な形式であることが可能である。１つの実例の配置構成において、第１の処理ユニットは、アプリケーション処理ユニットであり、プログラム・コードは、アプリケーション・プログラム・コードであり、第２の処理ユニットは、制御処理ユニットである。したがって、１つの実例の配置構成において、第１の処理ユニットは、アプリケーション・コードしか実行しないように配置構成されることが可能であり、例えば最低例外レベルといった、ソフトウェア実行特権の最低レベルでしか動作しないように構成されることが可能である。より高い例外レベルでコードを実行することが必要ないずれかの例外原因イベントは、第１の処理ユニットによって処理されず、代わりに、本明細書において説明される技法によって別の処理ユニットに退避される。

１つの実例の配置構成において、第１の処理ユニット及び第２の処理ユニットは、別個のプロセッサ・コアによって提供されることが可能である。１つのこのような配置構成において、第１の処理ユニット及び第２の処理ユニットは、システム内のキャッシュ・レベルの少なくともサブセットのための別個のキャッシュ構造を備えることが可能である。第１の処理ユニットと第２の処理ユニットの間のキャッシュ構造の適切な分離によって、これは、キャッシュ・タイミング分析が次に、命令の誤って推測された実行から情報を漏らすために悪用される恐れがあるシナリオを生み出そうとするためにいくつかの技法が使用される恐れがある、例えば、最近公表された推測ベースのキャッシュ・タイミング・サイド・チャネル攻撃（ｓｐｅｃｕｌａｔｉｏｎ－ｂａｓｅｄ ｃａｃｈｅ ｔｉｍｉｎｇ ｓｉｄｅ－ｃｈａｎｎｅｌ ａｔｔａｃｋ）に関して、セキュリティの恩恵をさらに向上させることができる。別個のキャッシュ構造が使用されることを保証することによって、少なくともレベル１キャッシュ及びレベル２キャッシュ等のキャッシュのより高いレベルで、このような攻撃を緩和することができる。

第１の処理ユニット及び第２の処理ユニットが別個のプロセッサ・コアである必要はない。例えば、別の実装形態において、第１の処理ユニット及び第２の処理ユニットは、マルチ・スレッド・プロセッサ・コアの別個のスレッドによって提供されることが可能である。各スレッドには独自の構造上の状態があるので、本明細書において説明される技法は、マルチ・スレッド・プロセッサ・コア内のこのような別個のスレッドに対して適用されることが可能である。

前述のように、本明細書において説明される技法は、システムが構成される方法に大きな柔軟性をもたらすことができる。例えば、第１の処理ユニットと第２の処理ユニットのうちの少なくとも１つは、単一の例外レベルで動作することだけに制限されることが可能である。実際は、前述のように、妥当なネスト技法によって、各個々の処理ユニットは単一の例外レベルで動作することだけに制限される可能性があることがある。

第１の処理ユニットによって発行されるトリガ・イベントは、様々な形式であることが可能である。例えば、トリガ・イベントは、このトリガ・イベントをハンドリングすることになる特定の処理ユニットを明示的に対象とすることができるので、このような事例において、第２の処理ユニットは、トリガ・イベントが発行される対象の処理ユニットである。しかし、代替アプローチにおいて、トリガ・イベントは、どの処理ユニットが次にこのトリガ・イベントをハンドリングすることになるかを判定するいくつかの分配メカニズムに発行されることが可能であり、この場合、第２の処理ユニットは、トリガ・イベントに応答することができるいくつかの処理ユニットの中の処理ユニットである。

図を参照しながら、特定の例がこれから説明される。

図１は、１つの実例の実装形態によるシステムのブロック図である。プログラム・コードを実行するための処理パイプライン２５を備える第１の処理ユニット１０が提供される。処理パイプラインによる命令の実行中、処理パイプラインは、命令のためのソース・オペランドを取得するため、及びこれらの命令の実行によって生み出される結果オペランドをレジスタ・セットに格納するために、一般的な手法でレジスタ・セット３０のレジスタにアクセスすることになる。データは、ロード動作によってメモリからレジスタにロードされることが可能であり、同様にデータは、格納命令の実行によってメモリに戻して格納することができる。メモリ・システムは、図１に示されたキャッシュ３５等の、キャッシュの１つ又は複数のレベルを含むことができる。

当業者によってよく知られているように、処理ユニット内でのプログラム・コードの実行中、例外の発生を生じる状況が生じることがあり、このような状況は、本明細書において、例外原因イベントと呼ばれる。このような例外原因イベントは、例えば、入出力（Ｉ／Ｏ）デバイス・リクエスト、（しばしばシステム・コールと呼ばれる）ユーザ・プログラムからオペレーティング・システム・サービスを起動するリクエスト、整数算術桁あふれ又は下位桁あふれ、ページ・フォールト、等の、多種多様な種々の形式であることが可能である。

本明細書において、異なる例外レベルと呼ばれる、ソフトウェア実行特権のいくつかの異なるレベルで処理ユニットが実行できるということも知られている。例外原因イベントによって例外が行われるとき、これは、典型的には、例外に対処するために、（本明細書において、例外ハンドリング・ルーチンとも呼ばれる）割込サービス・ルーチンの実行が必要となる。しばしば、全てのケースにおいてではないが、例外をハンドリングするために、割込サービス・ルーチンの実行前に、異なる、より高い特権の例外レベルに処理ユニットが遷移することが必要になることがある。

システム内のデータのセキュリティを保証するために、特定の例外レベルで実行するソフトウェアが、これより高い例外レベルで実行するソフトウェアと関連付けられた一定のデータにアクセスできないことを保証することが望ましい。より低い例外レベルで実行されているあまり信頼できないコードがアクセスできないように、システム内の信頼できるコードによって使用されるデータを隔離しようとするメカニズムが知られている。しかし、攻撃者は、彼らが信頼できないコードを実行するときに、信頼できるデータにアクセスしようとするために用いる技法に関して、これまで以上に洗練されつつある。特定の実例として、キャッシュ・タイミング分析が次に、命令の誤って推測した実行から情報を漏らそうとするために悪用されることが可能になるように、いくつかの技法が使用されることが可能な、（しばしば、Ｓｐｅｃｔｒｅと呼ばれる）推測ベースのキャッシュ・タイミング・サイド・チャネル攻撃が開発された。この背景に対して、より高い例外レベルで操作される信頼できるデータが、これより低い、あまり信頼できない例外レベルで実行するコードに無意識のうちに利用できるようにならないことを保証するために、例外をハンドリングするときのシステム内のセキュリティを向上させることが望ましいはずである。

本明細書においてより詳細に論じられることになるように、第１の処理ユニット１０は、生じる可能性のある例外原因イベントのタイプのうちの少なくともいくつかについて、第１の処理ユニットが、例えば、より高い例外レベルにスイッチして、処理パイプライン２５上で適切な割込サービス・ルーチンを実行することによって例外自体をハンドリングしないように配置構成されるが、代わりに図１において第２の処理ユニット２０と呼ばれる、物理的に別個の処理ユニットによってこの例外のサービスをハンドリングできるようにするメカニズムが提供される。

特に、第１の処理ユニット１０は、第２の処理ユニット２０のメモリ・アドレス空間にマッピングされた、メモリ・マップ式制御インターフェース４０を有する。特に、第２の処理ユニットのメモリ・アドレス空間の一部にマッピングされた、メモリ・マップ式制御インターフェース４０内のいくつかの記憶素子４５が備えられ、第２の処理ユニットのメモリ・アドレス範囲内の対応アドレスを指定することによって、これらの記憶素子４５に対して読書きするために、処理パイプライン５０上でロード命令及び格納命令を実行できるようになる。

さらに、これらの記憶素子４５は、第１の処理ユニットの一定の状態情報への直接マップ式アクセスを提供するように構成される。特に、図２を参照しながら後でより詳細に論じられることになるように、これらの記憶素子のうちのいくつかは、レジスタ・セット３０内のレジスタへの直接マップ式アクセスを提供することができ、第１の処理ユニット１０によって生じた例外をハンドリングするために割込サービス・ルーチンを実行するときに、第２の処理ユニットがこれらのレジスタの内容を読み込んで更新することを可能にする。同様に、第１の処理ユニットのメモリ・アドレス空間の一定の部分は、第２の処理ユニット２０によってこれらの記憶素子に対して行われるロード動作又は格納動作によって、第１の処理ユニット１０のメモリ・アドレス空間内のメモリ・ロケーションからデータを読み込むこと、又はメモリ・ロケーションに書き込むように、記憶素子４５を介して第２の処理ユニットが利用できるようにすることができる。したがって、記憶素子４５を介して、第２の処理ユニットは、図１の双方向の線８０によって示されるように、レジスタ・セット３０への読書き動作を行える可能性があり、同様に、第１の処理ユニット１０のキャッシュ３５とインターフェースする双方向の線８５によって示されるように、第１の処理ユニットのメモリ・アドレス空間の少なくともサブセットに対して読書き動作を行える可能性がある。

第２の処理ユニットは、第１の処理ユニットと同様に配置構成されることが可能であるので、命令を実行するように配置構成された処理パイプライン５０を有することができ、命令の実行中、処理パイプラインは、レジスタ５５の関連付けられたセットにアクセスすることができ、第２の処理ユニットのローカル・キャッシュ６０を介してメモリからこれらのレジスタにデータをロードすること、又はローカル・キャッシュ６０を介してレジスタからメモリにデータを戻して格納することもできる。

本明細書において説明される技法によれば、例外原因イベントの少なくとも一定のタイプについて、処理パイプライン２５は、プログラム・コードの実行をやめてトリガ・イベントを発行する動作の停止モードに入るように配置構成される。特に、処理パイプライン２５は、経路６５上で停止モード信号をアサートし、第１の処理ユニット１０からトリガ・イベント７０を出力することができる。トリガ・イベントは、特定の処理ユニットに向けられることが可能であり、又は、どの処理ユニットにトリガ・イベントを向けるべきかを判定するための任意の適切な尺度を適用する割込分配エンティティに発行されることが可能である。現在の事例において、トリガ・イベントは、第２の処理ユニット２０に最終的に伝搬されるということが仮定される。

トリガ・イベントを受信すると、第２の処理ユニットは、第２の処理ユニットの処理パイプライン５０内で実行されている処理に割込み、トリガ・イベントにおいて提供された情報に基づいて、第１の処理ユニット１０によって生じた例外をハンドリングするのに適した割込サービス・ルーチンを実行することを決定する。

割込サービス・ルーチンを実行するとき、処理パイプライン５０は、メモリ・マップ式制御インターフェース４０内のメモリ・アドレス指定可能な記憶素子４５に向かう経路７５を介してロード動作及び／又は格納動作を行うことができる。前述のように、記憶素子へのリード・アクセス又はライト・アクセスは、例えば、経路８０を介したレジスタ・セット３０のレジスタ、又は、経路８５を介した第１の処理ユニットのメモリ・アドレス空間内のメモリ・ロケーションといった、第１の処理ユニット内の直接マップ式状態保持構造への対応するアクセスをトリガする。

結果として、割込サービス・ルーチンの処理中に、第２の処理ユニット２０は、第１の処理ユニット内の必要な状態にアクセスすることができ、割込サービス・ルーチンによる要求に応じてこの状態を修正することができる。

第２の処理ユニットの制御下でこの処理が行われている間、第１の処理ユニットは停止モードのままであり、したがって、処理パイプライン２５内でいずれの命令も実行しない。第２の処理ユニットによって例外ハンドリング・ルーチンが完了すると、例外ハンドリング処理が完了したこと、すなわち、例外からの復帰があることを示すために経路９０上で信号を発することができる。この時点で、第１の処理ユニットは、プログラム・コードの実行を自由に再開することができるので、プログラム実行を再開させるために、経路９５上で処理パイプライン２５に停止モード終了信号が伝送される。

このようなメカニズムによって、処理パイプライン２５は、処理パイプライン２５の現在の例外レベルから、すなわち、例外原因イベントが生じる前に処理パイプライン２５が動作していた例外レベルから、遷移する必要がないということに留意されたい。代わりに、処理パイプライン２５は、現在の例外レベルのままである間、実行を停止することしかできず、やがて、次に、やはり現在の例外レベルにとどまっている間、プログラム・コードの実行を再開することができる。

メモリ・マップ式制御インターフェース４０を使用することによって、物理的に別個の処理ユニット２０に例外ハンドリング・ルーチンの処理を退避させ、必要に応じて第１の処理ユニットの状態情報へのアクセス及び修正をこの物理的に別個の処理ユニットが行うためのメカニズムを提供することによって、この物理的に別個の処理ユニットが例外ハンドリング・ルーチンを効果的に実行できるようにすることが可能である。これは、システム内に著しく強化されたセキュリティをもたらす。例えば、例外原因イベントが、例外ハンドリング・ルーチンを実行する前に第１の処理ユニットがより高い例外レベルに入るのに通常必要であるはずのタイプのものである場合、もはや第１の処理ユニット内でこの遷移が行われる必要はない。代わりに、例外ハンドリング・ルーチンは、別個の処理ユニットによって実行されることが可能であり、別個の処理ユニットは、別個の処理ユニット自体がこの例外ハンドリング・ルーチンを実行するために、より高い例外レベルに遷移しても、しなくてもよく、この事例における、異なる例外レベルで動作するソフトウェアの間の物理的分離は、セキュリティを著しく強化する。

必要に応じて、第２の処理ユニットは、例えば、追加のメモリ・マップ式制御レジスタ１１０といった、第１の処理ユニット内の他のストレージへのメモリ・マップ式アクセスを行えるようにされることも可能である。例えば、処理パイプライン２５の処理活動を示す性質をもつトレース・ストリームを生成するために、第１の処理ユニット内にエンベデッド・トレース・マクロセル（ＥＴＭ）１００を備えることができ、このＥＴＭの動作は、制御レジスタ１１０に格納された一定の制御情報１２０によって制御される。同様に、第１の処理ユニットの動作性能を示す性質をもつ一定の性能測定基準を生み出すために性能管理ユニット（ＰＭＵ）１０５を備えることができ、この性能管理ユニットは、制御レジスタ１１０内の制御情報１１５に基づいて構成されることも可能である。必要に応じて、第２の処理ユニット２０は、ＥＴＭ１００及びＰＭＵ１０５によって行われることになる動作を第２の処理ユニットがプログラムできるようにするために、制御レジスタ１１０へのメモリ・マップ式アクセスを行えるようにされることが可能である。

メモリ・マップ式制御インターフェース４０は、１つの実装形態において、第１の処理ユニット１１０のデバッグ・インターフェース内に提供される機能を強化することによって提供されることが可能である。特に、第１の処理ユニット上でデバッグ動作を行うとき、デバッグ・インターフェースは、必要なときに処理パイプラインの実行を停止できるようにするためのメカニズムを備えることができる。このようなメカニズムは、標準外部デバッグ・インターフェースを単に提供するのではなく、また、第１の処理ユニットの一定の状態情報への直接マップ式アクセスを提供すること、したがって、例外のハンドリング中にこの状態情報にアクセスして更新するために、割込サービス・ルーチンが別個の処理ユニット２０上で実行するための効率的なメカニズムを提供することによって、第２の処理ユニット等の外部デバイスからのより高い性能アクセスを可能にするために補われることが可能である。

図２は、１つの実例の実装形態における、メモリ・マップ式制御インターフェース４０内に備えることができる記憶素子４５をより詳細に示す図である。

図示のように、記憶素子のセット１５０は、第１の処理ユニットのレジスタ３０への直接マップ式アクセスを第２の処理ユニットが行えるようにするために提供されることが可能である。例えば、セット内の各個々の記憶素子は、レジスタ・セット３０内のレジスタのうちの１つに直接マッピングされることが可能である。第２の処理ユニット２０内の処理パイプライン５０が次に、セット１５０内の特定の記憶素子にマッピングするメモリ・アドレスを指定してロード動作又は格納動作を実行するとき、これは、レジスタ・セット内のレジスタに直接アクセスするために使用されることが可能である。例えば、ロード動作を実行するとき、関連レジスタ３０からの内容は、処理パイプライン５０に提供して戻すためにセット１５０内の記憶素子の中に回収されることが可能であり、同様に、格納動作を実行するとき、データは、レジスタ・セット３０の対応するレジスタに直接更新されるように、セット１５０内のアドレス指定された記憶素子に書き込まれることが可能である。

図２にも示されるように、第１の処理ユニットのメモリ・アドレス空間の一部への直接マップ式アクセスを行うために、必要に応じて、記憶素子のブロック１５５が提供されることが可能である。例えば、記憶素子のブロック１５５は、記憶素子のこれらのブロックに対して第２の処理ユニットによってロード動作及び格納動作を行えるように、第２の処理ユニットのメモリ・アドレス空間内のアドレスの特定の範囲と関連付けられることが可能である。さらに、各記憶素子は、第１の処理ユニットのメモリ・アドレス空間内の関連付けられたメモリ・ロケーションに直接マッピングされることが可能であり、これにより、次に、このような記憶素子に対して行われるいずれかのアクセスが、関連付けられたメモリ・ロケーションに対して直接行われる。

第１の処理ユニットのメモリ・アドレス空間内の特定のメモリ・ロケーションにブロック１５５内の記憶素子がマッピングされる方式は構成可能であることが可能であり、したがって、例えば、１つ又は複数のマッピング・レジスタ１６０は、ブロック１５５内の記憶素子と、第１の処理ユニットのメモリ・アドレス空間１０内の対応するメモリ・ロケーションとの間のマッピングを識別するために提供されることが可能である。マッピング・レジスタは、例えば、第２の処理ユニット２０上で実行される信頼できるコードによって、第１の処理ユニット１０上で実行される適切な信頼できるコードによって、又は、第１と第２の処理ユニットの間の関係をセットアップするために使用される、さらなる処理ユニット上で実行される信頼できるコードによって、等、様々な方式で書き込まれることが可能である。このようなアプローチによって、第１の処理ユニット１０のメモリ内に保持される状態情報は、メモリ・マップ式制御インターフェース４０によって提供された直接マップ式アクセスによって効率的に、第２の処理ユニット２０の処理パイプライン５０上での割込サービス・ルーチンの実行中に、アクセスされ、更新されることが可能である。

マッピング・レジスタ１６０によって構成された記憶素子のブロック１５５は、第１の処理ユニットのメモリ・アドレス空間の一部への直接マップ式アクセスを、第２の処理ユニット２０が行えるようにされることが可能な１つのメカニズムを提供するが、必要に応じて他のメカニズムが使用されてもよいということが理解されよう。例えば、第１の処理ユニット１０のメモリ・アドレス空間は、第２の処理ユニットの１次アドレス空間とは別個の第２の処理ユニットの２次アドレス空間として扱われることが可能である。第２の処理ユニットは、次に、第１の処理ユニットの代わりに割込サービス・ルーチンを実行している間に、第１の処理ユニット１０のアドレス空間内の状態情報にアクセスするように、第２の処理ユニットが第２の処理ユニットの２次アドレス空間をアドレス指定することを可能にするためのメカニズムを提供されることが可能である。このために使用されることが可能ないくつかのメカニズムがある。例えば、１次アドレス空間ではなく２次アドレス空間にアクセスするために使用されるロード命令及び格納命令の別個のセットが、インストラクション・セット・アーキテクチャによって提供されることが可能である。代替として、これが１次アドレス空間内のメモリ・アクセスを生成するか、２次アドレス空間内のメモリ・アクセスを生成するかに影響を与えるために、メモリ・アドレスを生成するときに第２の処理ユニットによって使用されるアドレス・レジスタの非アドレス部にタグ・ビットが追加されることが可能である。しかし、このようなメカニズムは、第２の処理ユニットの２次アドレス空間として第１の処理ユニットのアドレス空間全体が複製されることを潜在的に可能にすることができるが、一定の構造上の変更を実行することが必要になる可能性があるということが理解されよう。したがって、いくつかの実装形態において、図２を参照しながら上述されたメカニズムが好ましい可能性がある。任意の時点で（すなわち、マッピング・レジスタ１６５内のマッピングを変更することなく）第２の処理ユニットによってアクセスされることが可能な第１の処理ユニット内のアドレス空間の大きさは、記憶素子のブロック１５５のサイズによって指示されるが、これにより、システムへの任意の構造上の変更を必要としなくても実行されることが可能なメカニズムが提供される。

図２にも示されたように、１つ又は複数の例外イベント識別レジスタ１６５が提供されることが可能であり、これは、（例えば、例外レベルの変更、及び処理パイプライン２５内の割込サービス・ルーチンの実行をトリガすることによって）例外自体に対処しようとするのではなく、どのタイプの例外原因イベントによって、第１の処理ユニットが停止モードに入り、トリガ・イベントを発行することになるかを識別するようにプログラムされることが可能である。これにより、停止モードがいつ使用されるかについて、大きく構成できるようにすることが可能になる。例えば、スケールの１つのエンドにおいて、任意の例外原因イベントによって処理パイプラインは停止モードに入ることができ、これにより、全ての例外が、第２の処理ユニットによってリモートにハンドリングされる。しかし、必要に応じて、停止モードのトリガ、及び第２の処理ユニットへの例外ハンドリングの退避を行わなくても、例外原因イベントの１つ又は複数の異なる形式を、第１の処理ユニットによって処理できるようにすることができる。

１つの実例の配置構成において、例外イベント識別レジスタ１６５は、第１の処理ユニットによって例外原因イベントが処理される場合に第１の処理ユニットが指定の例外レベルに遷移する必要があるはずの第１の処理ユニット内の例外原因イベントが発生したときはいつでも、この例外原因イベントの発生によって、停止モードに入り、トリガ・イベント７０を発行して、第２の処理ユニット２０等の物理的に別個の処理ユニットが例外をハンドリングすることになるということを識別するようにプログラムされることが可能である。具体的な実例として、第１の処理ユニットは、例外レベル１以上のレベルへの遷移が必要になるはずのいずれかの例外原因イベントは別にして、例外レベル０にとどまりながら処理されることが可能な例外原因イベントをハンドリングできるようにされることが可能であり、これによって、処理パイプライン２５は停止モードに入り、物理的に別個の処理ユニットに例外のハンドリングを退避することができる。別の例として、第１の処理ユニットは、例外レベル０又は例外レベル１で処理されることが可能な例外を処理できるようにされることが可能であるが、例外レベル２以上のレベルへの遷移が必要になるはずの他のいずれかの例外原因イベントについては停止モードに入ることになる。

例外イベント識別レジスタ１６５は、例えば、第２の処理ユニット２０上で実行する信頼できるコードによって、第１の処理ユニット１０上で実行する信頼できるコードによって、又は、第１と第２の処理ユニットの間の関係をセットアップするために使用される、さらなる処理ユニット上で実行される信頼できるコードによって、等、様々な方式でプログラムされることが可能である。

１つの実装形態において、トリガ・イベント７０は、それ自体が、第１の処理ユニットが停止モードに入った理由を第２の処理ユニットが判定できるようになるいくつかの情報を提供することができる。しかし、代替実装形態において、このために、１つ又は複数のシンドローム・レジスタ１７０が、記憶素子４５内に提供されることが可能である。特に、第１の処理ユニットは、次に、停止モードに入る前にこれらのシンドローム・レジスタに書き込むことができ、これにより、第２の処理ユニットがトリガ・イベントに応答するとき、及びしたがって、割込サービス・ルーチンを実行するとき、第２の処理ユニットは、この情報を取得するためにシンドローム・レジスタにアクセスすることができる。

図３は、第１の処理ユニット１０内で検出された例外原因イベントをハンドリングするときの図１のシステムの動作を示す流れ図である。ステップ２００において、例外が行われる必要があることを第１の処理ユニットが検出したかどうかが判定される。これが検出されると、ステップ２０５において、第１の処理ユニットが停止モードに入ることを例外原因イベントが要求するかどうかが判定される。前述のように、これは、例外イベント識別レジスタ１６５の構成によって決まることが可能である。第１の処理ユニットが停止モードに入ることを例外原因イベントが要求しない場合、処理はステップ２１０に進み、ここで、第１の処理ユニットは、一般的な手法で例外をハンドリングする。前述のように、これは、第１の処理ユニットがより高い例外レベルに変わることを伴うことができる。

第１の処理ユニットが停止モードに入ることを例外原因イベントが要求することが判定された場合、ステップ２１５において、第１の処理ユニットは、第１の処理ユニットの現在の例外レベルにとどまり、停止モードに入り、トリガ・イベントをアサートする。

トリガ・イベントは、例外をハンドリングすることになる特定の処理ユニットを対象にすることができ、又は、代わりに、どの処理ユニットにトリガ・イベントを向けるべきかを決定する割込再分配メカニズムによってルーティングされることが可能である。どのメカニズムが使用されても、トリガ・イベントは、適切な第２の処理ユニットによって最終的に受信され、ステップ２２０において、第２の処理ユニットはトリガ・イベントに応答して、この第２の処理ユニットによって現在行われている処理を停止するために割込みを行い、次に、例外を処理するために、適切な例外ハンドリング・ルーチンを実行する。例外ハンドリング・ルーチンの決定は、例えば、生じた例外のタイプを参照することによって、一般的な方式で行うことができる。さらに、トリガ・イベントの一部として発行された割込番号等の情報は、トリガ・イベントを発行した第１の処理ユニットを第２の処理ユニットが判定し、したがって、例外ハンドリング・ルーチンを実行するときにどのメモリ・マップ式制御インターフェース４０と通信することになるかを第２の処理ユニットが判定することができるようになる。

ステップ２２０において示されるように、例外ハンドリング・ルーチンの実行の処理中、第２の処理ユニット２０は、第１の処理ユニット１０のメモリ・マップ式制御インターフェース４０の記憶素子４５を介して第１の処理ユニットの状態情報１０にアクセスして更新することになる。これは、例えば、レジスタ・セット３０内の１つ又は複数のレジスタの内容にアクセスして更新すること、及び、第１の処理ユニットのメモリ・アドレス空間内の１つ又は複数のメモリ・ロケーションにアクセスして更新することを含むことができる。

第２の処理ユニットは、その後、ステップ２２５において、経路９０上で例外からの復帰を第１の処理ユニットに信号で伝えることになり、第１の処理ユニットは停止モードを終了して、プログラム・コードの実行を再開する。

図４Ａ及び図４Ｂは、上記のアプローチを採用するときにデータに与えられる強化された保護を示す。特に、図４Ａは、本技法を伴わずに採用されるはずのアプローチ、すなわち、例えば、第１の処理ユニットがより高い例外レベルに遷移し、次に、この高い例外レベルで、必要な例外ハンドリング・ルーチンを実行することによって、独自の例外をハンドリングするアプローチを示す。最初に、（図４ＡにおいてＣＰＵ０と呼ばれる）第１の処理ユニット上で、アプリケーション例外レベルでアプリケーション・コードが実行されており、次に、ポイント２５０において、トラップが例外ハンドリング・ルーチンに対して行われることを仮定する。この実例では、ポイント２５０に達すると、処理ユニットは、例えば、オペレーティング・システム・ソフトウェアと関連付けられた例外レベルといった、より高い例外レベルに遷移し、次に、オペレーティング・システムの制御下で例外ハンドリング・ルーチンが実行されることを仮定する。

トラップ・ポイント２５０の前に実行していたアプリケーション・コードと、例外ハンドリング・ルーチンを実行するために使用されるオペレーティング・システム・コードとの両方が、ＣＰＵ０内のローカル・キャッシュ２３０にアクセスする。例外ハンドリング・ルーチンの実行中、次に、種々のタイプのデータが、オペレーティング・システム・ソフトウェアによって、キャッシュ２３０に読書きされることが可能である。これは、オペレーティング・システムに属するデータであるとみなされることが可能なオペレーティング・システム固有データ２５５、２６５を含むことができ、アプリケーション・コードと共有されることはないが、例えば、アプリケーション例外レベルのための更新された状態情報といった、ユーザ・データ２６０を含むこともでき、このデータは、例外ハンドリング・ルーチンが完了し、アプリケーション・コードの実行を再開するために処理パイプラインがアプリケーション例外レベルに復帰すると、アプリケーション・コードが利用できるようにするためのタイプのデータである。

ステップ２７０において、例外ハンドリング・ルーチンが完了し、それによりプロセッサが例外から復帰し、アプリケーション例外レベル（例えば、例外レベル（ＥＬ：ｅｘｃｅｐｔｉｏｎ ｌｅｖｅｌ）０）に遷移して戻り、その後、ＣＰＵ０がアプリケーション・コードの処理を再開し、キャッシュ２３０にアクセスすることを仮定する。例えば、オペレーティング・システム固有データ２５５、２６５をキャッシュからフラッシュすることによって、又は他のいくつかのメカニズムを使用してこのデータを保護することによって、例外ハンドリング・ルーチンからの復帰後に、このデータがアプリケーション・コードによってアクセスされることから保護しようとするために様々なメカニズムが用いられることが可能であるが、このようなデータのセキュリティに対する懸念、及びこのデータにアクセスするために使用されるサイド・チャネル攻撃の可能性が最近増してきた。

図４Ｂは、本明細書において説明される技法を使用して、このようなデータのセキュリティがいつ、どのように改善されることが可能であるかについて示す。特に、やはり、例えばＥＬ０といったアプリケーション例外レベルでアプリケーション・コードをＣＰＵ０が実行しており、次に、ポイント２７５において例外原因イベントが発生し、例外ハンドリング・ルーチンへのトラップを生じることを仮定する。前述の技法によれば、この時点でＣＰＵ０は停止モードに入り、命令の実行をやめる。トリガ・イベントの発行によって、ＣＰＵ１として図４Ｂにおいて言及された第２の処理ユニットによって割込みが行われる。ポイント２８０において、ＣＰＵ１は、次に、必要な例外ハンドリング・ルーチンの実行を開始し、やはり、これは、例えばＥＬ１といったオペレーティング・システム例外レベルでのコードの実行を伴うことができる。しかし、必要な例外ルーチンはＣＰＵ１によって実行されているので、オペレーティング・システムのプライベート・データ（「固有データ」）２８２、２８６は、ＣＰＵ１のローカル・キャッシュ２４０に対して読書きが行われることが可能である。逆に、アプリケーション・コードと共有されることになるユーザ・データ２８４は、前述のメカニズム、すなわち、メモリ・マップ式制御インターフェース２３５内の記憶素子を介して行われるＣＰＵ０のメモリ・アドレス空間への直接マップ式アクセスを使用して、ＣＰＵ０の制御インターフェース２３５を通じてＣＰＵ０のローカル・キャッシュ２３０に書き込まれる。

やがて例外ハンドリング・ルーチンが完了し、したがってステップ２９０において処理が例外から復帰すると、これにより、ＣＰＵ０は、アプリケーション・コードの実行を再開することになる。しかし、ＣＰＵ０とＣＰＵ１の間の物理的分離のために、オペレーティング・システムの要注意データのどれもＣＰＵ０のキャッシュ２３０に書き込まれなかったので、セキュリティが著しく強化される。

さらに、図４Ｂのメカニズムを用いると、ＣＰＵ０は、アプリケーション例外レベル（例えば例外レベル０）から決して遷移せず、したがって（例外をハンドリングするために、より高い例外レベルにＣＰＵ０自体が遷移したケースの状況とは逆に）より高い例外レベルと関連付けられた特権にアクセスできないので、セキュリティが全体的に強化される。

図４Ｂを参照しながら説明された技法を採用するときに、いくつかの性能の恩恵が実現されることもある。例えば、例外のハンドリング中、データは、例外レベル０に関係のないＣＰＵ０のキャッシュ２３０に格納されないので、ステップは、例外ハンドリング・ルーチンが完了した時に例外レベル１のデータのセキュリティを維持する必要がない。例えば、ポイント２９０において例外ハンドリング・ルーチンが完了したとき、ＣＰＵ０のキャッシュ２３０からいずれのデータもフラッシュする必要がない。

本明細書において説明される技法は、第１の処理ユニットの動作時に制御機能の多くを第２の処理ユニットが利用できるように拡張されることが可能であるということに留意されたい。例えば、第２の処理ユニット２０は、（例えば、アプリケーション・コアであるとみなされることが可能な）第１の処理ユニットを停止し、例えば、複数のユーザ・プロセス間でアプリケーション・コアを時間共有するために、いつでもコンテキストをスイッチすることができる制御コアの形式であると考えられることが可能である。したがって、１つ又は複数のタイプの例外原因イベントに対する例外をハンドリングすることによって、制御コアがシステム・サービスをアプリケーション・コアに提供することに加えて、このようなアプローチによって、アプリケーション・コアが計算サービスを制御コアに効果的に提供できるようにもなる。単一の制御コアは、このようなシナリオにおいて複数のアプリケーション・コアを管理することができる。

上述の技法を用いることができる処理ユニットは、様々な形式であることが可能である。例えば、図５Ａに示されるように、処理ユニットのそれぞれは、別個のプロセッサ・コアであることが可能である。したがって、複数の第１の処理ユニット３００、３１０が提供されることが可能であり、それぞれは、図５Ａにおいて制御コア３２０として言及された、第２の処理ユニットのメモリ・アドレス空間にメモリ・マッピングされた関連付けられた制御インターフェース３０５、３１５を備える。

コア３００、３１０のいずれかにおいて例外原因イベントが発生し、このコアが停止モードに入り、トリガ・イベントを発行するタイプのものであるとき、トリガ・イベントは、制御コア３２０にルーティングされることが可能である。例外番号に基づいて、制御コアは、どのコアがトリガ・イベントを発行したかを判定することができ、次に、例外をハンドリングするために、生じた例外のタイプを考慮して、適切な例外ハンドリング・ルーチンを実行することができる。前述の技法を使用して、制御コアは、関連付けられた制御インターフェース３０５、３１５を介してトリガ・イベントを発行したコア３００、３１０の必要な状態にアクセスして更新することができる。

しかし、図５Ａに示されるように処理ユニットが別個のプロセッサ・コアである必要はない。代わりに、別個の処理ユニットは、図５Ｂに示されるもの等のマルチ・スレッド・コア内の別個のスレッドであることが可能である。したがって、マルチ・スレッド・コア３３０は、それぞれが、関連付けられた制御インターフェース３４０、３５０を備えることができる複数のスレッド３３５、３４５を備えることができる。マルチ・スレッド・コア３３０のいくつかの処理リソースを異なるスレッドが共有することができるが、スレッドは、別個の処理要素を効果的に形成し、これらに固有のレジスタを備えること、空間をアドレス指定すること、これらに固有の特定の例外レベルで動作すること、等が可能である。したがって、個々のスレッドは、前述の第１の処理ユニットと同じように動作することができ、トリガ・イベントを第２の処理ユニットに発行して、第２の処理ユニットに、スレッドに代わって例外をハンドリングさせることができる。したがって、制御コア３６０は、図５Ａの実例を参照しながら前述されたものと正確に同じ方式で例外をハンドリングすることができ、例外番号情報は、トリガ・イベントを発行したマルチ・スレッド・コア内の特定のスレッドを識別するために使用される。

図５Ｂにおいて、制御コア３６０は別個のプロセッサ・コアとして示されているが、他の実装形態において、制御コア３６０はそれ自体が、マルチ・スレッド・コア３３０内のスレッドのうちの１つであることが可能であるということに留意されたい。

図６は、ネスト化された例外のハンドリングをサポートするために、本明細書において説明される技法がどのように使用されることが可能であるかを示す。したがって、この実例において、第１の処理ユニットは、この実例では制御コア１ ３８０である第２の処理ユニットのメモリ・アドレス空間にマッピングされた、関連付けられた制御インターフェース３７５を備えるアプリケーション・コア３７０の形式である。しかし、制御コア１ ３８０によって行われる処理中、例外が行われ、適切な例外ハンドリング・ルーチンが実行されることが必要な制御コア１内で、例外原因イベントが検出されることになる可能性もある。このような事例において、例外ハンドリング・ルーチンは、例えば、より高い例外レベルに遷移し、適切な例外ハンドリング・ルーチンを実行することによって、制御１ ３８０自体の中で実行されることが可能であるが、１つの代替実施例において、制御コア１ ３８０は、制御コア２ ３９０のメモリ・アドレス空間にメモリ・マッピングされた制御インターフェース３８５を備えることもできる。このようなアプローチによって、制御コア１は、一定の例外原因イベントに対して、停止モードに入り、トリガ・イベントを発行して、適切な例外ハンドリング・ルーチンを制御コア２ ３９０に実行させることができ、この処理中、制御コア２ ３９０は、制御インターフェース３８５を介して制御コア１ ３８０内の必要な状態にアクセスして更新することができる。

図６に示された方式は、必要に応じて、よりネストされたレベルをもたらすように任意に拡張されることが可能であるということが理解されよう。このようなメカニズムは、著しい柔軟性をもたらす。例えば、１つの事例において、各個々のコアは、単一の例外レベルで動作するようにだけ配置構成されることが可能であり、全ての例外原因イベントは、ハンドリングのために別個のコアにルーティングされるということが理解されよう。いくつかの事例において、これは、例外レベルの概念が完全に不要になる可能性があることを意味することができる。

前述の図５Ｂと同様に、図６において、要素３７０、３８０、３９０は別個のプロセッサ・コアであることを仮定しているが、代替実装形態において、これらの要素は、マルチ・スレッド・コア内の別個のスレッドによって提供されることが可能である。

図７は、割込分配器４２０がシステム内に提供される実装形態を示す。この実例では、複数の制御コア４１０、４１５があり、これらのそれぞれは、１つ又は複数のアプリケーション・コア４００、４４０へのメモリ・マップ式アクセスを提供されることが可能である。アプリケーション・コアは、アプリケーション・コアの代わりに割込サービス・ルーチンを実行する制御コアによって、前述のように、これらのアプリケーション・コア内の一定の状態情報への直接マップ式アクセスを行うように配置構成された、関連付けられた制御インターフェース４０５、４４５を備える。

このような実装形態において、アプリケーション・コア４００がトリガ・イベントを発行するとき、これは、割込分配器４２０に渡される割込リクエストの形式であることが可能である。したがって、アプリケーション・コア４００はトリガ・イベントをアサートすると、経路４２５上で割込分配器４２０に割込リクエストを発行することができる。割込分配器は、次に、どの制御コアに割込リクエストをルーティングするべきかを判定するためのメカニズムを用いることになり、経路４３０上で制御コア１ ４１０に、又は経路４３５上で制御２ ４１５に、割込リクエストを送信することになる。図７において、簡略化のために２つの制御コアだけが示されたが、他の実装形態において、これより多くの制御コアが提供されることが可能であり、したがって、割込リクエストが伝搬される宛先制御コアについて、割込分配器４２０のためのより多くのオプションがある可能性があるということが理解されよう。

割込リクエストが向けられた制御コアによって割込リクエストが受け入れられると仮定すると、処理は、本質的に前述のように進み、この制御コアは、適切な例外ハンドリング・ルーチンを実行し、その処理の間、ロード動作及び／又は格納動作は、アプリケーション・コア４００内の状態情報にアクセスして更新するために、メモリ・マップ式制御インターフェース４０５内の記憶素子に対して行われることが可能である。例外ハンドリング・ルーチンが完了すると、アプリケーション・コア４００は例外からの復帰を通知され、次に、アプリケーション・コードの実行を再開するために停止モードを終了する。

図７において、アプリケーション・コア及び制御コアが参照されたが、割込リクエストを発行するコアはアプリケーション・コアである必要はなく、アプリケーション・コードより高い例外レベルでコア自体がソフトウェアを実行していることが可能であるということが前述の図６から正しく認識されよう。

図７に示された様々なコアは、物理的に別個のプロセッサ・コアである必要はなく、代わりに、マルチ・スレッド・コア上で実行している別個のスレッドであることが可能であるということも前述から正しく認識されよう。

１つの実装形態において、アプリケーション・コア及び制御コアによってアクセスされるキャッシュ構造は別個のものであることが可能であるが、いくつかの事例において、キャッシュのレベルの１つ又は複数は、図８に実例として示されるように共有されることが可能である。この実例において、アプリケーション・コア４７０は、ローカル・レベル１キャッシュ４７５を備え、制御コア４８０も、関連付けられたレベル１キャッシュ４８５を備える。しかし、必要に応じて、アプリケーション・コア４７０及び制御コア４８０は、レベル２キャッシュ４９０を共有することができる。一方で、いくつかの実装形態において、前述のＳｐｅｃｔｒｅベースの攻撃等のキャッシュ・タイミング・サイド・チャネル攻撃に対する堅牢性を強化するために、レベル２キャッシュ構造を共有するのはふさわしくないと考えられる可能性があり、このような事例において、アプリケーション・コア及び制御コアは、別個のレベル２キャッシュ構造、及び別個のレベル１キャッシュ構造を備えることができ、他の実装形態において、図８に示されたアプローチは、全面的に受入れ可能である可能性がある。特に、例えば例外レベルの物理的分離等、上述の停止モードを使用して別個のコアによって例外をハンドリングできること、及び、単一の例外レベルでしか動作できないいくつかの事例において、一定のコアが可能な例外レベルのサブセットしかサポートできないように配置構成できること、という恩恵の多くを得ることが、このようなアプローチで依然として可能であるはずである。少なくともいくつかのキャッシュ構造の共有を可能にすることによって、これは、現在説明されている技法を適用できる領域を増やし、例えば、マルチ・スレッド・コア内の個々のスレッドに対して、より容易に適用されるようにする。

本明細書において説明される技法を採用するとき、例外レベルの物理的分離によって全体的なセキュリティを改善しながら、いくつかの恩恵が実現されることが可能である。第１に、アプリケーション・コア上で実行されているアプリケーション・ソフトウェアは変更する必要がないということに留意されたい。さらに、制御コアは、より高い例外レベルで実行されている必要はなく、前述の手法でアプリケーション・コアへのメモリ・マップ式アクセスを行えるようにされている場合、例外レベル０で実行されていることさえ可能である。同様に前述されたように、制御コアの例外は、それ自体が、別のコアによってトラップされて処理されることが可能であり、例外ハンドリングを任意にネストすることができる。

さらに、この例外を制御コアに任せることをアプリケーション・コアが当てにできると仮定すると、このアプリケーション・コアは、例えばＥＬ０のみ等、例外レベルのサブセットしか実行しない可能性があり（したがって、純粋なデータ・プレーン・コアを実行する）、設計をかなり簡素化することができる。

１つの特定の実装形態において、全てのアプリケーション・コア及び制御コアは、これらが単一の例外レベルを実行する必要しかないように配置構成されることが可能であり、全面的に例外レベルを不要にすることを潜在的に可能にすることができる。

前述のように、１つの実例の実装形態において、第１の処理ユニット１０内で提供されるメモリ・マップ式制御インターフェース４０は、制御コアによる高速メモリ・マップ式アクセスを可能にし、関連レジスタ状態及び／又はメモリ・アドレス空間への直接マップ式アクセスを行うために、既存のデバッグ・インターフェースの能力を強化することによって形成されることが可能である。改善されたメモリ・マップ式インターフェースは、改善された効率で既存のデバッグ・ユース・ケースもサポートすることになり、外部デバッガがコアのレジスタに、より高速にアクセスすること、及び外部デバッガがメモリを見ることを可能にし、したがって、例外ハンドリングと関連付けられたものを超える追加の恩恵をもたらすことができるということに留意されたい。

前述のように、１つの実装形態において、物理的に別個のプロセッサ・コアが使用されることが可能であるが、代替実装形態において、個々の処理ユニットは、マルチ・スレッド・コア内の個々のスレッドの形式であることが可能である。したがって、第１のスレッド内で発生する例外原因イベントは、このスレッドが停止モードに入り、ハンドリングのために例外が別のスレッドに退避されることを引き起こす可能性があり、この他のスレッドは、第１のスレッドの状態へのメモリ・マップ式アクセスを行うことができる。上述のネストされるアプローチは、このような１つの実例の実装形態において採用されることが可能であり、各スレッドは特定の例外レベルに対応し、このようにして、特定の例外レベルで処理されることが必要な例外が、この例外レベルで動作することができる特定のスレッドに向けられることを可能にする。

前述のように、いくつかの実装形態において、メモリ・マップ式制御インターフェース４０内の記憶素子は、第１の処理ユニットが停止モードに入り、トリガ・イベントを発行して、異なる処理ユニットによって例外ハンドリング・ルーチンが実行されることになる例外原因イベントのタイプについて大いに構成できるように構成されることが可能である。いくつかの事例において、第１の処理ユニットは、例外原因イベントに関係なく、この手法で例外に常に応答するように配置構成されることが可能である。この事例において、前述の図３について、ステップ２０５が効果的に除去されるということがわかるので、第１の処理ユニットが例外をハンドリングするステップ２１０へ進む経路は全くなくなる。代わりに、処理は、ステップ２１５に直接進むことになり、ここで処理ユニットは、処理ユニットの現在の例外レベルにとどまり、停止モードに入り、トリガ・イベントをアサートすることになる。これにより、第１の処理ユニットの複雑性をかなり簡素化することができる。

本出願において、単語「～ように構成される（ｃｏｎｆｉｇｕｒｅｄ ｔｏ ．．．）」は、装置の要素が、定義された動作を行うことができる構成を備えることを意味するために使用される。この文脈において、「構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）」は、ハードウェア又はソフトウェアの相互接続の配置構成又は手法を意味する。例えば、装置は、定義された動作を行う専用ハードウェアを備えることができ、又は、プロセッサ若しくは他の処理デバイスは、機能を実行するようにプログラムされることが可能である。「ように構成される（ｃｏｎｆｉｇｕｒｅｄ ｔｏ）」は、装置要素が、定義された動作を行うために任意の方式で変更される必要があるということを意味しない。

本発明の例証的な実施例が、添付の図面を参照しながら本明細書において詳細に説明されてきたが、本発明はこれらの正確な実施例に限定されず、添付の特許請求の範囲によって定義されるような本発明の範囲及び精神から逸脱することなく、様々な変更、追加、及び修正が当業者によって行われることが可能であるということが理解されよう。例えば、従属請求項の特徴の様々な結合が、本発明の範囲から逸脱することなく、独立請求項の特徴とともに行われることが可能である。

Claims (23)

1. プログラム・コードを実行するための第１の処理ユニットと、
   第２の処理ユニットと
   を備え、
   前記第１の処理ユニットが、前記第２の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第１の処理ユニットの状態情報への直接マップ式アクセスを前記第２の処理ユニットに提供するように構成された制御インターフェースを備え、
   前記第１の処理ユニットが、少なくとも１つの例外原因イベントに応答して、前記第１の処理ユニットが前記プログラム・コードの実行を停止しトリガ・イベントを発行する停止モードに入り、
   前記第２の処理ユニットが、前記トリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて前記第１の処理ユニットの状態情報を修正するために、前記制御インターフェースを介して前記状態情報にアクセスするように前記第２の処理ユニットが配置構成された前記例外ハンドリング・ルーチンを実行し、
   前記第２の処理ユニットが、前記例外ハンドリング・ルーチンの完了時に、前記第１の処理ユニットが前記停止モードを終了して前記プログラム・コードの実行を再開するように配置構成される、
   システム。
2. 前記第１の処理ユニットの前記状態情報が、前記プログラム・コードを実行するときに前記第１の処理ユニットによって処理されるデータを格納するために使用される前記第１の処理ユニットのレジスタのセットの内容を含む、請求項１に記載のシステム。
3. 前記制御インターフェースが、前記第２の処理ユニットによるレジスタの前記セットへの直接マップ式アクセスを提供するために、前記第２の処理ユニットの前記メモリ・アドレス空間にマッピングされた記憶素子のセットを提供する、請求項２に記載のシステム。
4. 前記第１の処理ユニットの前記状態情報が、前記第１の処理ユニットのメモリ・アドレス空間の少なくとも一部に格納されたデータを含む、請求項１から３までのいずれか一項に記載のシステム。
5. 前記第１の処理ユニットの前記メモリ・アドレス空間の前記少なくとも一部が、前記第２の処理ユニットの２次アドレス空間を形成する、請求項４に記載のシステム。
6. 前記制御インターフェースが、前記第２の処理ユニットの前記メモリ・アドレス空間にマッピングされた記憶素子のブロックを提供し、前記ブロック内の各記憶素子が、前記第１の処理ユニットの前記メモリ・アドレス空間の前記少なくとも一部の中の対応するメモリ・ロケーションに直接マッピングされる、請求項４に記載のシステム。
7. 前記制御インターフェースが、記憶素子の前記ブロック内の前記記憶素子と、前記第１の処理ユニットの前記メモリ・アドレス空間の前記少なくとも一部の中の前記対応するメモリ・ロケーションとの間の前記直接マッピングを識別するように構成可能なマッピング・ストレージを備える、請求項６に記載のシステム。
8. 前記制御インターフェースが、前記第１の処理ユニットによる前記プログラム・コードの実行中に遭遇したときどの例外原因イベントが前記第１の処理ユニットを前記停止モードに入れ前記トリガ・イベントを発行させることになるかを識別するように構成可能な例外イベント識別ストレージを備える、請求項１から７までのいずれか一項に記載のシステム。
9. 前記例外イベント識別ストレージが、前記第１の処理ユニットによって例外原因イベントがハンドリングされる場合、前記第１の処理ユニットが指定の例外レベルに遷移することが必要になるはずの前記例外原因イベントが発生したときはいつでも、前記第１の処理ユニットが前記停止モードに入り、前記トリガ・イベントを発行することになるということを識別するように構成される、請求項１から８までのいずれか一項に記載のシステム。
10. 前記第１の処理ユニットが、前記停止モードに入るとき、前記第１の処理ユニットの現在の例外レベルのままであるように配置構成され、前記第２の処理ユニットが、選ばれた例外レベルで前記例外ハンドリング・ルーチンを実行するように配置構成される、請求項１から９までのいずれか一項に記載のシステム。
11. 前記選ばれた例外レベルが、前記第１の処理ユニットの前記現在の例外レベルより高い例外レベルである、請求項１０に記載のシステム。
12. 前記制御インターフェースが、前記第２の処理ユニットによって使用される情報を提供して、前記第１の処理ユニットが前記停止モードに入った理由を識別するのを支援するために、前記第２の処理ユニットの前記メモリ・アドレス空間にマッピングされ、前記第１の処理ユニットによって書き込まれるシンドローム・ストレージを備える、請求項１から１１までのいずれか一項に記載のシステム。
13. 前記第２の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第３の処理ユニットの状態情報への直接マップ式アクセスを前記第２の処理ユニットに提供するように構成された、さらなる制御インターフェースを備える第３の処理ユニット
    をさらに備え、
    前記第３の処理ユニットが、少なくとも１つの例外原因イベントに応答して、前記第３の処理ユニットが実行を停止し前記トリガ・イベントを発行する前記停止モードに入り、
    前記トリガ・イベントは、前記トリガ・イベントが前記第１の処理ユニットによって発行されたか、それとも前記第３の処理ユニットによって発行されたか、前記第２の処理ユニットが判定し、前記例外ハンドリング・ルーチンを実行するとき前記第１と第３の処理ユニットのどちらにアクセスするべきかを判定できる情報を含む、
    請求項１から１２までのいずれか一項に記載のシステム。
14. 追加の処理ユニット
    をさらに備え、
    前記第２の処理ユニットが、前記追加の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第２の処理ユニットの状態情報への直接マップ式アクセスを前記追加の処理ユニットに提供するように構成された第２の制御インターフェースを備え、
    前記第２の処理ユニットが、少なくとも１つの例外原因イベントに応答して、前記第２の処理ユニット上で実行されているプログラム・コードの実行を停止して、さらなるトリガ・イベントを発行する前記停止モードに入り、
    前記追加の処理ユニットが、前記さらなるトリガ・イベントに応答して、さらなる例外ハンドリング・ルーチンによる要求に応じて前記第２の処理ユニットの状態情報を修正するために、前記第２の制御インターフェースを介して前記状態情報にアクセスするように配置構成された、前記さらなる例外ハンドリング・ルーチンを実行し、
    前記追加の処理ユニットが、前記さらなる例外ハンドリング・ルーチンの完了時に、前記第２の処理ユニットが前記停止モードを終了して、前記第２の処理ユニット上で実行されている前記プログラム・コードの実行を再開するように配置構成される、
    請求項１から１３までのいずれか一項に記載のシステム。
15. 前記第１の処理ユニットが、アプリケーション処理ユニットであり、前記プログラム・コードが、アプリケーション・プログラム・コードであり、前記第２の処理ユニットが、制御処理ユニットである、請求項１から１４までのいずれか一項に記載のシステム。
16. 前記第１の処理ユニット及び前記第２の処理ユニットが、別個のプロセッサ・コアによって提供される、請求項１から１５までのいずれか一項に記載のシステム。
17. 前記第１の処理ユニット及び前記第２の処理ユニットが、前記システム内の前記キャッシュ・レベルの少なくともサブセットのための別個のキャッシュ構造を備える、請求項１から１６までのいずれか一項に記載のシステム。
18. 前記第１の処理ユニット及び前記第２の処理ユニットが、マルチ・スレッド・プロセッサ・コアの別個のスレッドによって提供される、請求項１から１７までのいずれか一項に記載のシステム。
19. 前記第１の処理ユニットと前記第２の処理ユニットのうちの少なくとも１つが、単一の例外レベルで動作することだけに制限される、請求項１から１８までのいずれか一項に記載の装置。
20. 前記第２の処理ユニットが、
    前記トリガ・イベントが発行される対象の処理ユニット、
    前記トリガ・イベントに応答することができるいくつかの処理ユニットの中の処理ユニット
    のうちの１つである、請求項１から１９までのいずれか一項に記載の装置。
21. プログラム・コードを実行するための実行回路と、
    第２の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第１の処理ユニットの状態情報への直接マップ式アクセスを前記第２の処理ユニットに提供するように構成された制御インターフェースと
    を備え、
    前記第１の処理ユニットが、少なくとも１つの例外原因イベントに応答して、前記実行回路が前記プログラム・コードの実行を停止し、トリガ・イベントが発行される停止モードに入り、
    前記制御インターフェースが、前記第２の処理ユニットが例外ハンドリング・ルーチンによる要求に応じて前記第１の処理ユニットの前記状態情報にアクセスして修正できるように、前記トリガ・イベントに応答して前記第２の処理ユニットが前記例外ハンドリング・ルーチンを実行している間に前記第２の処理ユニットがアクセスできるように配置構成され、
    前記第１の処理ユニットが、前記第２の処理ユニットが前記例外ハンドリング・ルーチンを完了したとき、前記停止モードを終了して前記プログラム・コードの実行を再開するように配置構成される
    第１の処理ユニット。
22. 第１の処理ユニットによって発行されたトリガ・イベントに応答して例外ハンドリング・ルーチンを実行するための実行回路であって、前記トリガ・イベントが、前記第１の処理ユニットによるプログラム・コードの実行が停止される停止モードに前記第１の処理ユニットが入ったことを示す、実行回路と、
    前記例外ハンドリング・ルーチンを実行している間に、前記第２の処理回路が前記第１の処理ユニットの制御インターフェースにアクセスするように配置構成される通信インターフェースであって、前記制御インターフェースが、前記第２の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第１の処理ユニットの状態情報への直接マップ式アクセスを前記第２の処理ユニットに提供するように構成される、通信インターフェースと
    を備え、
    前記第２の処理ユニットが、前記例外ハンドリング・ルーチンによる要求に応じて前記第１の処理ユニットの前記状態情報を修正するために、前記制御インターフェースを介して前記状態情報にアクセスするように配置構成され、
    前記第２の処理ユニットが、前記例外ハンドリング・ルーチンの完了時に、前記第１の処理ユニットが前記停止モードを終了して前記プログラム・コードの実行を再開するように配置構成される、
    第２の処理ユニット。
23. プログラム・コードを実行するための第１の処理ユニット、及び第２の処理ユニット、を備えるシステムにおいて例外原因イベントをハンドリングする方法であって、
    前記第２の処理ユニットのメモリ・アドレス空間にマッピングされ、前記第１の処理ユニットの状態情報への直接マップ式アクセスを前記第２の処理ユニットに提供するように構成された前記制御インターフェースを前記第１の処理ユニットに提供するステップと、
    前記第１の処理ユニット内の少なくとも１つの例外原因イベントに応答して、前記第１の処理ユニットが前記プログラム・コードの実行を停止してトリガ・イベントを発行する停止モードに前記第１の処理ユニットを入れるステップと、
    前記第２の処理ユニットが前記トリガ・イベントに応答して、例外ハンドリング・ルーチンによる要求に応じて前記第１の処理ユニットの前記状態情報を修正するために、前記制御インターフェースを介して前記状態情報にアクセスする前記例外ハンドリング・ルーチンを実行するステップと、
    前記第２の処理ユニットによる前記例外ハンドリング・ルーチンの完了時に、前記第１の処理ユニットが前記停止モードを終了して、前記プログラム・コードの実行を再開するステップと
    を含む、方法。

Images