JP7149298B2 - レルム階層における目標レルムの無効化 - Google Patents

レルム階層における目標レルムの無効化 Download PDF

Info

Publication number
JP7149298B2
JP7149298B2 JP2019570883A JP2019570883A JP7149298B2 JP 7149298 B2 JP7149298 B2 JP 7149298B2 JP 2019570883 A JP2019570883 A JP 2019570883A JP 2019570883 A JP2019570883 A JP 2019570883A JP 7149298 B2 JP7149298 B2 JP 7149298B2
Authority
JP
Japan
Prior art keywords
realm
given
realms
memory
child
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019570883A
Other languages
English (en)
Other versions
JP2020527777A (ja
Inventor
パーカー、ジェイソン
ルシアン エバンス、マシュー
リース ストックウェル、ガレス
コバチェビク、ジョルジェ
Original Assignee
アーム・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アーム・リミテッド filed Critical アーム・リミテッド
Publication of JP2020527777A publication Critical patent/JP2020527777A/ja
Application granted granted Critical
Publication of JP7149298B2 publication Critical patent/JP7149298B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466—Key-lock mechanism
    • G06F12/1475—Key-lock mechanism in a virtual system, e.g. with translation means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)
  • Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)
  • Memory System (AREA)

Description

本技法は、データ処理の分野に関する。
指定のメモリ領域についてのアクセス権を行使するためのメモリ・アクセス制御技法を提供することが知られている。通常は、権限のより少ないプロセスがメモリ領域にアクセスすることを、より高い特権レベルで実行するプロセスが排除することができるように、これらの技法は特権レベルに基づく。
「Ｓｏｍｅ Ｅｆｆｉｃｉｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｉｍｕｌａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ」、１９９０年冬、ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ、５３～６３頁
少なくともいくつかの実例は、以下を備える装置を提供する。
１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理回路と、
複数のメモリ領域の所有権を行使するためのメモリ・アクセス回路であり、所与のメモリ領域は、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムは、ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所有者レルムは、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス回路と、
ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って複数のレルムを管理するためのレルム管理ユニット、
ここで、目標レルムの無効化を要求するコマンドに応答して、レルム管理ユニットは、目標レルム及び目標レルムの任意の子孫レルムを処理回路にアクセス不可能にさせるように構成される。
少なくともいくつかの実例は、以下を備える装置を提供する。
１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための手段と、
複数のメモリ領域の所有権を行使するための手段であり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所有者レルムが、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、手段と、
ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って複数のレルムを管理するための手段、
ここで、目標レルムの無効化を要求するコマンドに応答して、管理するための手段は、目標レルム及び目標レルムの任意の子孫レルムを、処理するための手段にアクセス不可能にさせるように構成される。
少なくともいくつかの実例は、以下を含むデータ処理方法を提供する。
１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するステップと、
複数のメモリ領域の所有権を行使するステップであり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所有者レルムが、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を有し、ここで、複数のレルムは、ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムである、レルム階層を有する、ステップと、
目標レルムの無効化を要求するコマンドに応答して、目標レルム及び目標レルムの任意の子孫レルムを処理回路にアクセス不可能にさせるステップ。
少なくともいくつかの実例は、以下を備える命令実行環境を提供するようにホスト・データ処理装置を制御するためのコンピュータ・プログラムを提供する。
１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理プログラム論理と、
複数のメモリ領域の所有権を行使するためのメモリ・アクセス・プログラム論理であり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所有者レルムが、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を有する、メモリ・アクセス・プログラム論理と、
ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って複数のレルムを管理するためのレルム管理プログラム論理、
ここで、目標レルムの無効化を要求するコマンドに応答して、レルム管理プログラム論理は、目標レルム及び目標レルムの任意の子孫レルムを処理回路にアクセス不可能にさせるように構成される。
本技法のさらなる態様、特徴及び利点は、以下のような添付の図面と併せて読まれることになる、以下の実例の説明から明らかとなろう。
第１のメモリ及び第２のメモリ内に記憶されたメモリ領域を使用する複数の処理要素を含むデータ処理システムを概略的に示す図である。 実行される複数のプロセスの関係と、それらのプロセスに関連する特権レベルと、どのプロセスが所与のメモリ領域を所有するか及びそれに応じてその所与のメモリ領域へのアクセスを制御するための排他的権利を有するかを制御するためのそれらのプロセスに関連付けられたレルムとを概略的に示す図である。 レルム管理ユニット及びメモリ管理ユニットによる管理下のメモリ領域を概略的に示す図である。 所与のメモリ領域を第１のメモリから第２のメモリにエクスポートするために実行されるプログラム命令のシーケンスを概略的に示す図である。 ページ・エクスポートを概略的に示す流れ図である。 複数のレルムと、どのエクスポート・コマンドがどの他のエクスポート・コマンドを中断することができるかを制御するための制御階層内のそれらの関係とを概略的に示す図である。 ページ・インポートを概略的に示す流れ図である。 所与のメモリ領域の重複するエクスポート動作を実行する第１のエクスポート・コマンド・ソース及び第２のエクスポート・コマンド・ソースを概略的に示す図である。 処理要素と、メモリに記憶されたレルム管理制御データとのより詳細な実例を示す図である。 親レルムが様々な子レルムのプロパティを記述するレルム記述子を定義することができる、レルムの階層の実例を示す図である。 レルム階層の異なる実例を示す図である。 レルム階層の異なる実例を示す図である。 親レルムによって、その子レルムのレルム記述子を記録するために保持される、レルム記述子ツリーの実例を示す図である。 レルム記述子ツリーの対応するレベルにインデックスをそれぞれ提供するいくつかの可変長ビット部分から構築されたローカル・レルム識別子の実例を示す図である。 レルム階層内の各レルムのローカル及びグローバル・レルム識別子の実例を示す図である。 レルム記述子の内容の実例を示す図である。 異なるレルム・ライフサイクル状態を示すテーブルである。 レルムのライフサイクル状態の変化を示す状態機械の図である。 所与のメモリ領域の所有権テーブルにおけるエントリの内容を示すテーブルである。 所有者以外のどのレルムが領域にアクセスすることを許されるかを制御するために所与のメモリ領域について設定することができる可視性属性を示すテーブルである。 レルム管理ユニットによって排他的アクセス向けに確保されたＲＭＵプライベート・メモリ領域に対応する状態を含む、メモリ領域の異なるライフサイクル状態の実例を示す図である。 所与のメモリ領域のライフサイクル状態の遷移を示す状態機械を示す図である。 所与のメモリ領域の所有権が親レルムとその子レルムとの間をどのように通過することができるかを示す図である。 所有者レルムによって設定された許可に基づくメモリ・アクセスの制御の直交レベルを提供する特権レベル及びレルム管理ユニット・レベルに依存する、メモリ制御属性を定義するページ・テーブルに基づいて提供されるメモリ・アクセス制御を概略的に示す図である。 変換ルックアサイド・バッファの実例を示す図である。 ページ・テーブル及びＲＭＵテーブルに基づいてメモリへのアクセスを制御する方法を示す流れ図である。 異なる例外レベルにおいて実行するプロセスにアクセス可能な状態を示す図である。 レルムに入る又は例外から戻る方法を示す流れ図である。 レルムを出る又は例外を取る方法を示す流れ図である。 子レルムへのエントリ及び親レルムに戻る退出の実例を示す図である。 ネストされたレルム退出及びネストされたレルム・エントリの実例を示す図である。 レルムからの退出時のレルム実行コンテキストの遅延保存の使用の実例を示す図である。 異なる子レルムが入られる前に、前に退出された子レルムに関連する状態のサブセットがメモリに保存されることを確実にするためのフラッシュ・コマンドの使用の実例を示す図である。 サブレルムの親レルムに関連するプロセス内の指定のアドレス範囲に対応するサブレルムの使用を示す図である。 使用され得るシミュレータ実例を示す図である。
図１は、大容量記憶デバイスの役割を果たすオフチップ・フラッシュ・メモリなどの別個の不揮発性メモリ６に接続されたシステム・オン・チップ集積回路４を備えるデータ処理システム２を概略的に示す。システム・オン・チップ集積回路４は、（この例示的実施例では）２つの汎用プロセッサ（ＣＰＵ：Ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ））８、１０、及びグラフィックス・プロセッシング・ユニット（ＧＰＵ：Ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）１２の形で、複数の処理要素を備える。実際には、追加の汎用プロセッサ、グラフィックス・プロセッシング・ユニット、直接メモリ・アクセス（ＤＭＡ：Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）ユニット、コプロセッサ、並びに、メモリ・アドレス空間内のメモリ領域にアクセスするのに役立つ及びそれらのメモリ領域内に記憶されたデータにデータ処理動作を実行する他の処理要素など、多数の異なる形態の処理要素が提供され得ることが理解されよう。
汎用プロセッサ８、１０及びグラフィックス・プロセッシング・ユニット１２は、相互接続回路１４につながれ、相互接続回路１４を介してオンチップ・メモリ１６及び外部メモリ６（外部メモリ・インターフェース１８を介する）とのメモリ・トランザクションを実行する。メモリ１６は、図１においてオンチップであるが、他の実施例において、メモリ１６は、この代わりに、オフチップ・メモリとして実装され得る。オンチップ・メモリ１６は、全メモリ・アドレス空間内の複数のメモリ領域に対応するデータを記憶する。これらのメモリ領域は、メモリ・ページに対応し、どのメモリ領域（ページ）が所与の時間にオンチップ・メモリ１６内に存在するか、どのプロセスがそれらのメモリ領域内に記憶されたデータ及びそれらのメモリ領域に関連する他のパラメータにアクセスすることができるか、を制御する管理動作の対象となる。より具体的には、この例示的実施例において、処理要素８、１０、１２のそれぞれは、レルム管理ユニット２０、２２、２４及び汎用メモリ管理ユニット２６、２８、３０を含む。汎用メモリ管理ユニット２６、２８、３０は、アドレス・マッピング（たとえば、仮想アドレス及び中間物理アドレス、又は物理アドレスの間のマッピング）などのメモリ領域の動作、所与のメモリ領域にアクセスすることができるプロセスでの特権レベル制約、所与のメモリ領域内のデータの記憶特性（たとえば、キャッシュ可能性、デバイス・メモリ状況など）及びメモリの領域の他の特性の態様を制御するのに役立つ。
レルム管理ユニット２０、２２、２４は、複数のメモリ領域の所有権を行使するのに役立つデータを管理し、それにより、所与のメモリ領域は、複数のプロセスのうちから指定された所与の所有するプロセス（又は所有者「レルム」）を有する（プロセス又はレルムは、たとえば、モニタ・プログラム、ハイパーバイザ・プログラム、ゲスト・オペレーティング・システム・プログラム、アプリケーション・プログラム、又は同様の物のうちの１つ、或いはそのようなプログラムの指定の副部分である）。所与のメモリ領域の所与の所有するプロセス（所有者レルム）は、その所与のメモリ領域に記憶された所与の独自のデータへのアクセスを制御する排他的権利を有する。具体的には、所有者プロセスは、その所有者プロセスより高い特権レベルで実行されるプロセスによるその所有されるメモリ領域へのアクセスを防止する権利を有する。
したがって、複数のメモリ領域は、複数の所有者レルムの間で分けられる。各レルムは、少なくとも１つのソフトウェア・プロセスの少なくとも一部分に対応し、いくつかのメモリ領域の割り当てられた所有権である。所有するプロセス／レルムは、それらのレルムのメモリ領域内に記憶されたデータへのアクセスを制御する排他的権利を有する。どのメモリ領域が各レルムにマップされたメモリであるかの管理及び制御は、所有者レルム自体以外のプロセスによって実行される。この配置を使用して、どのメモリ領域（メモリのページ）が、そのハイパーバイザによって管理されるそれぞれのゲスト仮想マシン（ゲスト・オペレーティング・システム）によって所有されるレルム内に含まれるかをハイパーバイザなどのプロセスが制御することが可能であり、さらに、ハイパーバイザ自体は、それが所与のレルムに割り当てたメモリ領域内に記憶されたデータに実際にアクセスする権利を有さなくてもよい。したがって、たとえば、ゲスト・オペレーティング・システムは、そのゲスト・オペレーティング・システムのレルム内に、すなわち、そのゲスト・オペレーティング・システムによって所有されているメモリ領域内に、記憶されたデータをそれの管理ハイパーバイザから秘密にしておくことができる。
レルムへのメモリ・アドレス空間の分割、及びそれらのレルムの所有権の制御は、処理要素８、１０、１２のそれぞれに関連するレルム管理ユニット２０、２２、２４を介して管理され、汎用メモリ管理ユニット２６、２８、３０によって提供される制御のより多数の従来の形に直交する制御プロセスである。したがって、レルム管理ユニット２０、２２、２４は、メモリ・アドレス空間のメモリ領域の所有権を行使するために、メモリ・アクセス回路を提供する。場合により、レルム所有権を行使するメモリ・アクセス回路はまた、ＭＭＵ２６、２８、３０の部分を含み得る（たとえば、ＭＭＵ２６、２８、３０内のＴＬＢは、２つの別個の構造体にアクセスする必要性を回避するために、ＲＭＵ２０、２２、２４によって提供されるレルム制御に基づいて、アクセスを制御するためのいくらかの制御データを含む）。この例示的実施例において、処理要素８、１０、１２のそれぞれは、独自のレルム管理ユニット２０、２２、２４を含み、これはパフォーマンスを目的として有益である。しかしながら、より一般的には、所有権を行使するメモリ・アクセス回路は、レルム管理ユニットの単一インスタンス、存在するすべてのレルム管理ユニット２０、２２、２４の組合せ、又は存在するそれらのレルム管理ユニット２０、２２、２４のサブセットを備え得る。したがって、所有権を行使するためのメモリ・アクセス回路は、異なる処理要素８、１０、１２に関連してシステム・オン・チップ集積回路４にわたって分散され得る、或いは１つの場所において又は何らかの他の配置において集められ得る。
汎用プロセッサ８、１０を備えた処理要素は、プログラム命令を復号及び実行するそれぞれの復号及び実行回路３２、３４を含むものとして示されている。これらのプログラム命令は、メモリ・アドレス空間の異なる所有権レルム内のメモリ領域の管理を制御するのに役立つコマンド（レルム管理コマンド又はＲＭＵコマンド）を含む。一実例として、実行されるプログラム命令は、レルム管理ユニット・コマンドとして指定された、並びにそれらがそれらの関連するレルム管理ユニット２０、２２、２４によって実行（動作）され得る順番でプログラム命令ストリーム内で遭遇されるときに関連するレルム管理ユニット２０、２２、２４に指示される、プログラム命令を含み得る。レルム管理ユニット・コマンドの実例は、新しいレルムを初期化する若しくは既存のレルムを無効にするためのコマンド、メモリ領域を指定のレルムに割り当てる、指定のレルムからメモリ領域を取り除く、暗号化を用いて第２のメモリ６に第１のメモリ１６からメモリ領域内に含まれるデータをエクスポートするためのコマンド、及び、そのデータが第２のメモリ６内で保護されるようにエクスポートされたデータで実行される他のプロセスを含む。さらに、レルム管理ユニット・コマンドは、インポートされたデータに実行される関連暗号解読及び検証動作を有して、第２のメモリ６から第１のメモリ１６にデータをインポートし戻すために提供される。
メモリ領域からのデータのそのようなエクスポート及びインポートとの関連において、オンチップ・メモリ１６などの第１のメモリは、システム・オン・チップ集積回路４内のレルム管理ユニット２０、２２、２４によって厳密に管理され、したがって、それらのレルム管理ユニット２０、２２、２４は、所有権を行使することができ、所与のメモリ領域内のデータへのアクセスを、そのメモリ領域を所有するプロセス、又はその所有するプロセスがアクセスを許可したそれらのプロセスに制限することが理解されよう。しかしながら、そのメモリ領域内のデータが、第２のメモリである外部不揮発性メモリ６などにエクスポートされるとき、次いで、レルム管理ユニット２０、２２、２４によって提供されるアクセスの制御は、もはや効果的ではなく、したがって、データは、いくつかの他のやり方で保護を必要とする。これは、それがエクスポートされる前に使用するメモリ領域内のデータを暗号化することと、次いで、それがオンチップ・メモリ１６にインポートし戻されるときに秘密鍵でそのデータを解読することとによって、達成される。
エクスポート・プロセスは、エクスポートされたデータの特性を指定するメタデータの生成を伴い得る。データがオンチップ・メモリ１６にインポートし戻されるときに、メタデータが、そのインポートされたデータについて読み取ることができ、メタデータに表されたデータの特性が、そのインポートされたデータの整合性を確保するために、インポートされたデータの特性に対してチェックすることができるように（たとえば、チェックサム、データ・サイズ、署名など）、そのようなメタデータは、第１のメモリ（オンチップ・メモリ１６）のメタデータ・メモリ領域内に別個に記憶され得、それは、レルム管理ユニット２０、２２、２４にプライベート（すなわち、既存のプロセスのいずれかにではなく、そのようなレルム管理ユニット２０、２２、２４にのみアクセス可能）にされる。それは、レルム管理ユニット２０、２２、２４のプライベート・データ（エクスポートされた領域／ページの特性を示す前述のメタデータを含む）が、オンチップ・メモリ１６からオフチップの不揮発性メモリ６にエクスポートされる必要がある（たとえば、オンチップ・メモリ１６内に空間を作るために）ということでもよく、この状況において、ＲＭＵプライベート・メタデータ自体は、その保護のために暗号化することができ、そして、エクスポートされたメタデータの特性を示す新しいメタデータは、暗号化及びエクスポートされたメタデータが、使用するためにそれがオンチップ・メモリ１６にインポートし戻されるときに、チェック及び認証され得る順番で、オンチップ・メモリ１６内に保持することができる（そのような保持されるメタデータは、エクスポートされたメタデータよりも有意に小さいサイズである）。
メモリ領域の特性を記述するそのようなメタデータ及びそれらのメモリ領域内に記憶されたデータは、分岐パターンを有するメタデータ・メモリ領域ツリーなど、階層構造の一部として配置され得る。メモリ・アドレス空間の異なる領域が、レルム管理ユニット２０、２２、２４によって所有されるメタデータ領域の役割を果たすように登録されるとき、そのようなメタデータ・メモリ領域ツリーの形態は、ソフトウェア制御下で決定され得る。そのようなメモリ領域の登録を制御するソフトウェアは、メタデータを記憶するのに役立つメモリ領域間の関係を割り当てる、割り当てを解除する、及び制御することができるが、そのようなソフトウェアは、どのプロセスがそのようなデータにアクセスできるかを制御することができるという意味で、それらのメモリ領域内に含まれるデータをそれ自体では所有しないことが理解されよう。レルム管理ユニット２０、２２、２４（すなわち、メモリ管理回路）にプライベートなメモリ領域の場合、そのようなアクセス権は、レルム管理ユニット２０、２２、２４自体のみに制限され得、そのようなＲＭＵプライベート・データは、任意の他のプロセスと共用されないことになる。
所与のメモリ領域内に記憶された所与のデータがエクスポートされるとき、次いで、内容がアクセス不可能になるように、関係するメモリ領域は無効にされる。このページを再使用するために、そのページは、その所与のメモリ領域が別のプロセスによる使用のために解放されるとき、そのような前の内容が別のプロセスにアクセス可能にされない順番で、前の内容に対して相関関係のない他のデータでメモリ領域を上書きするクリーン・コマンドを使用することによって、「有効」にされる。たとえば、所与のメモリ領域の内容は、すべて、ゼロ値に書かれてもよく、又は固定値に書かれてもよく、又はランダム値に書かれてもよく、それにより、メモリ領域の最初の内容を上書きする。他の実例では、エクスポートされたメモリ領域の内容の上書きは、後続のクリーン・コマンドではなくて、エクスポート・コマンド自体によってトリガすることができる。どちらにしても、所与のメモリ領域が、所与の所有するプロセス以外のプロセスにアクセス可能にされる前に、エクスポートされている所与の所有されているデータは、所与の所有されているデータと相関関係のない値で上書きされ得る。所与のプロセスによって所有されている所与のメモリ領域が、エクスポート・プロセスの一部としてエクスポートされようとするとき、エクスポートを実行するためにレルム・コマンドを実行しているレルム管理ユニット２０、２２、２４は、所与のプロセスから関係するメモリ領域の所有権を取得し（すなわち、領域をＲＭＵプライベートにする）、すべての他のプロセス（及び他のレルム管理ユニット）に対してそのメモリ領域のアクセスをロックし、エクスポート動作（暗号化、メタデータ生成及び上書きを含む）を実行し、次いで、そのメモリ領域へのアクセスのロックを解除し、そのメモリ領域の所有権を解放する。したがって、エクスポートされる、又はインポートされるプロセスにあるメモリ領域は、そのコマンドが実行されている間に、関係するレルム管理ユニットにプライベートにされ得る。
図２は、複数のプロセス（プログラム／スレッド）、複数の例外レベル（特権レベル）、安全及び非安全プロセッサ・ドメイン、並びに所与のメモリ領域の所有権を表す複数のレルムの関係を概略的に示す。図示されるように、特権レベルの階層は、例外レベルＥＬ０から例外レベルＥＬ３（例外レベルＥＬ３は最高レベルの特権を有する）まで広がる。システムの動作状態は、たとえば、英国ケンブリッジのＡＲＭ（登録商標）社によって提供されるＴｒｕｓｔＺｏｎｅ（登録商標）アーキテクチャを使用するプロセッサにおいて、安全ドメイン及び非安全ドメインによって表されるものとしての安全動作状態と非安全動作状態とに分けられ得る。
図２に示すように、メモリ・アクセス回路（レルム管理ユニット２０、２２、２４及び関連制御ソフトウェア（たとえば、１つのレルム管理ユニットを実行するミリコード））は、実行環境内の複数のレルムを管理する。所与のメモリ領域（メモリ・ページ）は、指定のレルムによって所有される。レルムは、その中の子レルム、及びそれらの子レルム内の孫レルムを有することができる（たとえば、レルムＡ（親）、レルムＢ（子）、及びレルムＣ（孫）を参照）。所有権がレルムＡに与えられたメモリ領域は、レルムＡによって所有されるプロセスの制御下でレルムＡからレルムＢに順に渡されるそれらの所有権を有し得る。したがって、親レルムは、自らの子レルムに領域の所有権を与えることができる。それらの子レルムは、次いで、それらがそれらの親レルムから受信したメモリ領域の所有権を渡すことができ、その所有権は、次いで、最初のレルム、すなわちレルムＡ、の孫レルムであるそれら自体の子レルム（たとえば、レルムＣ）によって所有されることになる。所与のレルム内のプロセスは、同じ特権レベルで又は異なる特権レベルで実行することができる。したがって、レルム間を移動するための便利な機構は、異なる特権レベル（例外レベル）の間でシステムを自ら移動させる例外の使用を含み得るので、多数の実際の事例において、レルム及び特権レベルは対応し得るが、プロセスが属するレルムは、プロセスの特権レベルに対する直交パラメータである。
図２に示すレルム間の関係は、異なるレルムの間の子／親関係を示し、これは、メモリ領域管理のためのコマンドの複数の異なるソースが互いに競合するときにシステムの動作を制御するための制御階層を生じさせるために使用され得る。したがって、たとえば、前述のようなメモリ領域をエクスポートするためのエクスポート・コマンドの場合、第１のエクスポート・コマンドは、レルムＢ内のオペレーティング・システム・カーネル３６など、第１のエクスポート・コマンド・ソースから所与のレルム管理ユニット（メモリ・アクセス回路）によって受信され得る。第２のエクスポート・コマンドが、次いで、レルムＡにおいて実行するハイパーバイザ・プログラム３８など、第２のコマンド・ソースから所与のレルム管理ユニットによって受信され得る。この実例では、ハイパーバイザ・プログラム３８によって発行された第２のエクスポート・コマンドが、オペレーティング・システム・カーネル３６によって発行された第１のエクスポート・コマンドの処理を中断するように、第２のエクスポート・コマンド・ソースであるハイパーバイザ・プログラム３８は、親レルムと子レルムとの関係によって確立された制御階層内でより高い優先度を有する。ハイパーバイザ３８によって発行されるものとしての第２のエクスポート・コマンドが完了したとき、オペレーティング・システム・カーネル３６によって発行されるものとしての第１のエクスポート・コマンドが再開され得る。
この実例では、第２のエクスポート・コマンドは、より高い優先度を有し、したがって、第１のエクスポート・コマンドの動作を中断する。しかしながら、第２のエクスポート・コマンドが、たとえば、レルムＣ内のアプリケーション・プログラム４０に由来した場合、次いで、これは、レルム間の関係によって確立された制御階層内でより低い優先順位を有し、したがって、アプリケーション・プログラム４０からのそのような第２のエクスポート・コマンドは、オペレーティング・システム・カーネル３６からの第１のエクスポート・コマンドの動作を中断しないことになり、そうではなく、第１のエクスポート・コマンドが完了するまで、それ自体が実行されるのを妨げられることになる。したがって、ページング動作（エクスポート及びインポート動作）は、レルム階層に関連し得る制御階層に応じて互いに中断されることがある又は中断されないことがあるという意味で、ページング動作は、互いに保護され得る。他の例示的実施例では、制御階層は、特権レベルに対応し得る。
図３は、オンチップ・メモリ１６内に記憶された複数のメモリ・ページ（メモリ領域）で異なる管理動作をそれぞれ実行するレルム管理ユニット２０及び汎用メモリ管理ユニット２６を概略的に示す。図示されるように、レルム管理ユニット２４は、複数のレルム記述子４２を使用し、各記述子は、レルムのプロパティを指定する。レルム管理ユニット２４はまた、物理アドレスによってインデックスを付けられたエントリを含むレルム・グラニュール・テーブル（又は所有権テーブル）を維持することができ、それ自体がそのメモリ領域を実際に所有するか否かをそれが制御しない場合でも、各エントリは、そのメモリ領域がどのレルムに属するか、すなわち、どのレルムがそのメモリ領域内の制御データへのアクセスを制御する排他的権利を有するか、の指示を含む、対応するメモリ領域の情報を含む。レルム記述子及びレルム・グラニュール・テーブル・エントリは、メモリ１６に記憶され得るが、ＲＭＵ自体においてキャッシュされてもよい。したがって、図３に示されるように、異なるメモリ領域は、レルム指定ＲＡ、ＲＢ、ＲＣ、ＲＤ及びＲＥによって指示されるように異なる所有するレルムを有する。メモリ領域のうちのいくつかはまた、レルム管理ユニット２０によって所有され（これにプライベートであり）、ＲＭＵプライベートのマークを付される。そのようなＲＭＵプライベート領域は、他のメモリ領域の特性を記述するメタデータを記憶するために、エクスポート又はインポートされているメモリ領域を一時的に記憶するために、或いはレルム管理ユニット２０自体の他の目的のために、使用され得る。ＲＭＵプライベート領域は、対応する所有者レルムによってまだ所有され得るが、所有者レルムによって発行された汎用読取り／書込みアクセスにアクセス可能でなくてもよい（その代わりとして、ＲＭＵ２０に発行されたＲＭＵコマンドが、ＲＭＵプライベート領域に任意の変更を行うようにＲＭＵ２０をトリガすることが必要とされ得る）。
メモリ領域のアドレス指定は、関係する具体的なシステムに応じて、仮想、中間物理又は物理アドレスでもよい。したがって、レルム管理ユニット２０、及び汎用メモリ管理ユニット２６は、受信されたアドレス（それらが仮想メモリ・アドレスであっても中間メモリ・アドレスであっても）が、関係するオンチップ・メモリ１６内のメモリ領域をより直接的に表す、物理アドレスなどの、アドレスに変換されることを可能にする、変換データを記憶することができる。そのようなアドレス変換データは、変換ルックアサイド・バッファを使用するシステム・オン・チップ集積回路４及び他の分散された制御機構内で管理及び分散され得る。
図４は、メモリ領域のエクスポート動作に関連するプログラム命令を概略的に示す。これらのプログラム命令は、プログラム命令ストリーム内に現れ、全回路内の異なる要素によって実行（動作）され得る。たとえば、レルム管理ユニット・コマンドは、それぞれのレルム管理ユニット１２、２２、２４によって実行される。仮想アドレス・アンマップ命令（ＶＵＭＡＰ：Ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｕｎｍａｐｐｉｎｇ ｉｎｓｔｒｕｃｔｉｏｎｓ）及び変換ルックアサイド・バッファ無効化命令（ＴＬＢＩ：Ｔｒａｎｓｌａｔｉｏｎ ｌｏｏｋ ａｓｉｄｅ ｂｕｆｆｅｒ ｉｎｖａｌｉｄａｔｅ ｉｎｓｔｒｕｃｔｉｏｎｓ）などの命令が、システム・オン・チップ集積回路４内でブロードキャストされ、全体としてのシステム内の場所からそれらのコマンドによって指定されたものとしての変換データの使用をパージするのに役立つ（しかし、いくつかの実例では、専用の仮想アドレス・アンマップ命令が提供されないことがあり、その代わりに、仮想アドレスのアンマッピングが、特別なアンマップ命令を使用するのではなくて、メモリへの記憶を実行することによって変換テーブル・エントリを修正することによって、実行され得る）。バリア命令ＤＳＢが、図４に示された命令シーケンス内に挿入され、先行する仮想アドレス・アンマップ命令（又は同等の記憶命令）及び変換ルックアサイド・バッファ無効化命令がシステムのすべての部分によって完了されたという確認応答が受信されるまで、そのシーケンスの処理を停止するのに役立つ。したがって、レルム管理システム自体以外のシステム内の所与のメモリ領域の仮想アドレス変換のパージが、仮想アドレス・アンマップ命令（又は同等の記憶命令）、変換ルックアサイド・バッファ無効化命令及び対応するバリア命令のシーケンスによって達成され得る。所与のメモリ領域（ページ）の仮想アドレス変換データをアンマッピングすること（及び、以って、効果的に取り除くこと）によって、そのメモリ領域に記憶されたデータのエクスポート動作が実行されようとするときに、そのようなメモリ領域がシステム内のどこかで使用中でないことが確保され得る。
バリア命令ＤＳＢが、システム内からの仮想アドレス変換データのパージが完了したことを確認する確認応答を受信した後は、次いで、レルム管理ユニットのエクスポート・コマンドが、レルム管理ユニットによって実行される。レルム管理ユニットによって所与のプロセスから受信されたそのようなエクスポート命令の実行は、指定された所与のメモリ領域に関する複数のコマンド・アクションを含むコマンド・シーケンス（レルム管理ユニット内に組み込まれたミリコードに対応する）のパフォーマンスをトリガする。これらのコマンドの目的は、たとえば図４に示されるように、アドレス変換データを集めるステップ、メモリ領域をロックするステップ、データを暗号化するステップ、外部にデータを記憶するステップ、メモリ領域に関連するメタデータを書き込むステップ、及び、次いでメモリ領域のロックを解除するステップを含む。
レルム管理ユニットによってコマンド・シーケンスの一部として実行されるアドレス変換収集のステップは、関係するアクセス動作を完了するために必要とされるアクセス制御データをそのレルム管理ユニットに集める。これは、そのエクスポート動作が進行中になると、次いで、そのエクスポート動作を完了するために必要とされるパラメータ又はデータ、たとえば、アドレス変換データ、属性データ若しくはエクスポート・プロセスによって必要とされる他のデータ、の入手不能によることがあるような、エクスポート動作が停止される可能性が低くなることを確実にする。アクセス制御データのメモリ・アクセス回路（レルム管理ユニット）の検索及び記憶の一実例として、アドレス変換ステップは、エクスポート動作を完了するために必要とされ得るすべての必要なアドレス変換データ（たとえば、仮想アドレスから中間物理アドレス（又は物理アドレス）へのマッピング・データ）を検索するのに役立つ。
アドレス変換データが検索された後は、次いで、レルム管理ユニットが、関係する領域に関連するロック・フラグをロックされた状態に設定するのに役立つ。このロック・フラグは、関係する領域の領域属性データ４２内に記憶され得る。別法として、ロック・フラグは、それを任意の他のプロセス又はレルム管理ユニットによって上書きすることができないように、エクスポート動作を実行しているレルム管理ユニットにプライベートなメモリ領域内に記憶され得る。ロック・フラグをロック状態に設定するために、レルム管理ユニットは、他のレルム管理ユニットは関係するメモリ領域をロックされた状態で現在保持していないことを判定しなければならない。したがって、領域が他のどこかでロックされていないことを示す結果が返された場合、他のどこかに記憶されたデータを制御する任意の領域のロックされたフラグ値のポーリングが実行され、ロック・フラグはロック状態に設定される。領域が他のどこかでロックされた場合、次いで、エクスポート動作は失敗し、そのエクスポート動作を命じたプロセスにエラーが報告される。ロックが取得された後は、次いで、所与のメモリ領域内のデータは、暗号化され、システム・オン・チップ集積回路の外部に、たとえば外部不揮発性メモリ６に、記憶される。前述のように、暗号化されたデータの特性を示すメタデータ（又は、暗号化の前の所与のデータ）は、次いで、生成され、レルム管理ユニットプライベート領域内に記憶され、それは、エクスポートされたデータを後で認証するために使用することができる。最後に、関係するメモリ領域は、ロックされた状態からロック解除された状態にロックされたフラグを切り替えることによって、エクスポート・コマンドを実行するレルム管理ユニットによってロック解除される。メモリ・アクセス回路（レルム管理ユニット）のハードウェア機構によって行使されるロックの使用は、ロックされたフラグがロックされた状態にあるときに受信され得るさらなる処理要素からの任意の他の（第２の）アクセス・コマンドの進展を妨げる働きをする。
図５は、ページ（メモリ領域）エクスポートを概略的に示す流れ図である。ステップ４４において、領域管理ユニット２０、２２、２４内以外のシステム内のどこかでのページの使用をパージするのに役立つ、プログラム命令が実行される（ＶＵＭＡＰ、ＴＬＢＩ、ＤＳＢ）。これは、エクスポートされようとする領域を指す変換データの無効化及びパージによって達成され得る。この変換データがパージされた後は、別のプロセス又は処理要素が、その領域へのアクセスを望む場合、次いで、それは、変換データを再フェッチしようと試みることになる。変換データの再フェッチが試みられたとき、関係する領域は、ＲＭＵプライベート状態に置かれており、そこでは、ページ・エクスポートの実行を試みる領域管理ユニット２０、２２、２４のみがそのデータにアクセスする権利を有するので、その領域を再使用しようと試みるプロセス又は処理要素は、関連のある変換データの取得に失敗することになる。
パージ要求がステップ４４において発行されたとき、処理は、プログラム・シーケンス内のバリア命令ＤＳＢを超えて続くことが安全であるポイントにおいて、アドレス・データが他のどこか（レルム管理ユニット内以外）で無効にされたことを示すそれらのパージ要求から応答が受信されるまで、ステップ４６で待つ（バリア命令ＤＳＢは、その応答が受信されるまで、処理要素８、１０、１２を停止する）。ステップ４８において、レルム管理ユニット・エクスポート初期化命令が実行される。このエクスポート初期化命令は、コマンド・コンテキスト・バッファ（ＣＣＢ：Ｃｏｍｍａｎｄ Ｃｏｎｔｅｘｔ Ｂｕｆｆｅｒ）が、コマンド・シーケンスが中断される場合、そのエクスポート動作に対応するそのコマンド・シーケンスの現在の部分的に完了された状態を表すコンテキスト・データを記憶するように確立された、ＲＭＵプライベートとして確立されたメモリ領域へのポインタを含む。代替の例示的実施例において、レルム管理ユニット自体は、コマンド・コンテキスト・バッファ（ＣＣＢ）へのポインタを生成する責任を有し得る。ステップ５０は、エクスポート・コマンド・ステップ４８内のポインタによって指示されたコマンド・コンテキスト・バッファが空であるかどうかを判定する。コマンド・コンテキスト・バッファが空である場合、次いで、ステップ５２は、これをＲＭＵプライベート領域としてセットアップする。ステップ５０においてコマンド・コンテキスト・バッファが空ではない場合、そのとき、これは、ステップ４８において実行されているエクスポート初期化コマンドが、前に中断されたエクスポート動作を再開しようと試みていることを示す。この場合、処理はステップ５４に進み、そこで、ポインタによって指し示されたコマンド・コンテキスト・バッファの内容が、その部分的に完了された状態データがＣＣＢに記憶されたときに記憶された関連メタデータを使用し、認証される。検証に合格した場合、次いで、ステップ５６は、エクスポート・コマンドの部分的に完了された状態、たとえば、任意の部分的に暗号化されたデータ、暗号化が進んだ元データ内の位置へのポインタ、部分的に完了されたコマンドのさらなる属性など、を復元するために、コマンド・コンテキスト・バッファの内容を使用するのに役立つ。ステップ４８でコマンドによって指示されたエクスポート動作の初期化の後、その処理は、ステップ５２を含むパス又はステップ５４及び５６を含むパスのいずれかを介して進み、レルム管理ユニット・エクスポート・コマンドを実行するためのコマンドが達せられるステップ５８に達する。このコマンドが達せられたとき、次いで、領域管理ユニット２０、２２、２４は、メモリ領域内のデータの一部に暗号化を実行し、宛先（ステップ４８においてＲＭＵエクスポート初期化命令内で指定されたポインタでもある）内にこれを記憶する。ステップ６０は、ステップ４８及び５８において実行されている命令を発行したコマンド・ソースより高い優先度を有するコマンド・ソースからの中断が受信されたかどうかを判定する。そのようなより高い優先度のコマンドは、前述のような制御階層（たとえば、レルム階層、優先度階層など）内のより高い優先順位を有するソースに由来することになろう。そのようなより高い優先度の中断が受信された場合、次いで、処理はステップ６２に進み、そこで、エクスポート命令が停止され、そして、エラー・コードが、ステップ４８及び５８で実行された命令を発行したコマンド・ソースに返される。ステップ６４は、コマンド・コンテキスト・バッファにコマンドの部分的に完了された状態を保存するのに役立つ。ステップ６６は、コマンド・コンテキスト・バッファ・メタデータを、これが後に検索されるときにコマンド・コンテキスト・バッファ内に記憶された部分的に完了された状態の認証に使用するためにＲＭＵプライベート・メモリ領域に記憶する。ステップ６８は、「部分的にエクスポートされた」状態におけるような及びそのような部分的エクスポートを実行するプロセスを示す部分的に完了したエクスポート・コマンドの対象となったメモリ領域にマークを付けるのに役立つ。これは、後のそのエクスポートの再開を支援する。
ステップ６０での判定が、中断はないということである場合、次いで、処理はステップ７０に進み、そこで、メモリ領域のエクスポートが完了したかどうかに関する判定が行われる。エクスポートが完了していない場合、次いで、処理はステップ５８に戻る。エクスポートが完了している場合、次いで、処理は、ステップ７２に進み、そこで、空にされてあった（その記憶データがそこからエクスポートされた）メモリ領域は、最初に記憶されたデータと相関関係のないデータで上書きされる（たとえば、ゼロに設定される、何らかの他の固定数に設定される、ランダム・データで埋められるなど）。その処理は、次いで、終了する。
前述の例示的実施例では、ＣＣＢが、関連ポインタによって指定された別個のプライベート・メモリ領域として、たとえば初期化命令内で、提供される。しかしながら、他の例示的実施例では、ＣＣＢは、別個のメモリ領域としてではなく、中断され得るコマンドによってすでに使用されたメモリ領域、たとえばコマンドによって生成された結果データが記憶される宛先メモリ領域、の一部として提供され得る。中断され得るエクスポート・コマンドの場合、エクスポートされた暗号化されたデータが、エクスポートが実行されている間にＲＭＵプライベート・メモリ領域である宛先メモリ領域内に記憶される。ＣＣＢは、たとえば、そのような宛先領域が暗号化されたデータで埋められている間に、その宛先領域の最後の部分として、提供され得る。ＣＣＢ内に記憶されたコンテキスト・データの整合性は、エクスポート動作が実行されている間に、ＲＭＵプライベートである宛先領域によって確保される。
別の例示的実施例において、ＣＣＢは、レルム記述子（ＲＤ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ）の一部として提供され得、この場合、コンテキスト・データのために利用可能な記憶空間は、ＲＤにおいて利用可能な空間によって制約され得、したがって、サポートされる割込み可能な並列コマンドの数は、それぞれのＣＣＢの役割を果たすためにＲＤと利用可能な記憶空間によって制約され得る。ＣＣＢは、別個に、又は別の目的でも使用されるメモリ領域若しくはリソースの一部として、提供され得る。
図６は、レルム間の関係と、異なるコマンド・ソースからのどのコマンドが他のソースからの部分的に完了されたコマンドを中断する／妨げることを許されるかを決定する制御階層とを概略的に示す。図示された実例は、３つのレベルのネストされたレルムを含む。親レルムＭは、例外レベルＥＬ３に対応する。子レルムＮは、例外レベルＥＬ２に対応する。レルムＮ内の２つの孫レルムは、レルムＯ及びレルムＰを含み、両方とも例外レベルＥＬ１にある。この実例では、例外レベル優先度とレルムのネスト化された階層内の相対的位置との両方が、レルムＭはレルムＮより高い優先度を有し、レルムＮはレルムＯ及びレルムＰの両方より高い優先度を有する、制御階層における順序付けを与える。レルムＯ及びレルムＰは、同等の優先度である。
図７は、ＲＭＵインポート・コマンドに続くページ（メモリ領域）インポート動作を概略的に示す流れ図である。ステップ７４は、データがインポートされ得る空のページ（メモリ領域）を取得し、クリーニングするのに役立つ。ステップ７６は、次いで、その関連する記憶されたメタデータ（ＲＭＵプライベート領域に記憶された）を使用してインポートされようとする暗号化されたデータを検証する。この検証が成功しなかった場合、次いで、エラーが生成される。検証の成功の後、ステップ７８は、暗号化されたデータを解読するのに役立ち、そして、ステップ８０は、ステップ７４において取得されたメモリ・ページにその解読されたデータを記憶するのに役立つ。メモリ・ページが、解読されたデータで埋められた後は、それは、所有するレルム（プロセス）に解放され得る。取得され、次いで埋められたページは、ページ・インポート・プロセスの間にメモリ管理回路（レルム管理ユニット２０、２２、２４）に排他的に利用可能になるようにロックされる。
図８は、異なるコマンド・ソースから並行して生じ得る２つのエクスポート・コマンドを概略的に示す。命令のシーケンスのうちの一方は、仮想マシン（たとえば、ゲスト・オペレーティング・システム）に対応するプロセスに由来する。他方のコマンド・ソースは、仮想マシンと比較してより高いレベルの特権（又はレルム階層内の潜在的により高いレベル）にあるハイパーバイザである。したがって、このハイパーバイザからのエクスポート・コマンドは、仮想マシンのために、レルム管理ユニット２０、２２、２４によって実行されている部分的に完了したエクスポート・コマンドを中断することができる。ハイパーバイザのためのエクスポートが完了されたとき、次いで、仮想マシンのためのエクスポートが再開され得る。
この実例では、レルム管理ユニット２０、２２、２４へのコマンドは、結合された初期化でもよく、メモリ・アクセス回路がエクスポート動作に対応するコマンド・シーケンスが完了されたことを報告するまで繰り返して実行されるコマンドを実行し得る。前述の実例において、エクスポート・コマンドは、コマンド・コンテキスト・バッファへのポインタを指定するエクスポート初期化コマンドの形でもよく、そして、後続のエクスポートがこれに続く他のポインタは、コマンド・シーケンスが完了したことをメモリ・アクセス回路が報告するまで繰り返して実行されるコマンドを実行する。他の例示的実施例では、エクスポート動作は、結合された初期化及び実行コマンド（割込み可能な）と、結合された初期化及び実行コマンドが中断された場合に発行される実行継続コマンドとによって制御され得る。
このデータが後で復元され得るように、コマンド・コンテキスト・バッファは、部分的に完了されたコマンド・シーケンスを表す部分的に完了された状態を記憶するために使用される。このようにして、システムは、中断が提供可能になるのに完全エクスポート動作が完了するのを待つ必要がない。さらに、部分的に完了された状態が保持されるとき、エクスポート動作はその初期点から再開される必要はないことになるので、それが繰り返して中断された場合でも、エクスポート動作の前進が確保される。
図９は、図１の処理要素８、１０、１２のうちの１つと、メモリ・アクセスを制御するためのメモリ１６に記憶された制御データとのより詳細な実例を示す。説明を容易にするために、図９はＣＰＵ０を処理要素８として示すが、処理要素は、データ処理装置２内のＧＰＵ１２又は任意の他の処理要素のＣＰＵ１ １０でもよいことが理解されよう。図９に示されるように、処理要素８は、処理回路３２（前述の復号及び実行論理を備え得る）と、変換テーブルのエントリ（共用ＭＭＵ－ＲＭＵ ＴＬＢ構造体が使用される場合にＲＭＵ２０からのレルムベースの制御データと添付され得る）をキャッシュするための１つ又は複数の変換ルックアサイド・バッファ１００を含み得るメモリ管理ユニット２６と、ＴＬＢ１００へのデータの割当てを制御する並びに所与のメモリ・アクセスが実行されることを可能にされるかどうかを制御するために使用される必要なデータを見つけるためにメモリへのウォーク・アクセスをトリガするためのテーブル・ウォーク・ユニット１０２とを含む。処理要素８はまた、たとえば、前述のページング（エクスポート／インポート）動作において使用するための、データを暗号化又は解読するための暗号動作を実行し得る暗号ユニット１０４を含み得る。処理要素８はまた、メモリ１６から読み取られたデータ又は命令をキャッシュし得るいくつかのキャッシュ１１０を含む。処理回路３２によって又はテーブル・ウォーク・ユニット１０２によってトリガされたメモリへのアクセスが、キャッシュにおいて失敗した場合、データは、メイン・メモリ１６から見つけることができる。
処理要素８はまた、前述のようなレルム管理ユニット２０を含む。いくつかの実施例において、レルム管理ユニット（ＲＭＵ：Ｒｅａｌｍ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）２０は、ハードウェア回路として提供され得る。しかしながら、後述のＲＭＵ動作のうちのいくつかは、たとえばそれらが異なるメモリ領域への複数のアクセスが実行されることを必要とする場合、ハードウェアにおいて純粋に実装するのは比較的複雑になり得る。したがって、いくつかの実例では、ＲＭＵ２０は、データ処理装置２内に記憶され得るプログラム・コードを使用して実装され得、汎用処理回路３２を使用して実行され得る。メモリ１６に書き込まれ得る及び書換可能であり得る汎用ソフトウェアとは異なり、ＲＭＵソフトウェア（ミリコード）は、それを取り除くことができないように、比較的永久的な方式でデータ処理装置にインストールすることができ、処理システムによって提供されるプラットフォームの一部として見なされ得る。たとえば、ＲＭＵプログラム・コードは、読み取り専用メモリ（ＲＯＭ）内に記憶することができる。したがって、ＲＭＵは、ハードウェア・ユニットを備えることができ、又は、処理回路３２によって実行される汎用ソフトウェアに含まれるＲＭＵコマンドによって実行するようにトリガされる、レルム管理ソフトウェアを実行する処理回路３２を備え得る。いくつかの実例では、ＲＭＵ２０は、ハードウェア及びソフトウェアの組合せを使用して実装され得、たとえば、何らかのより単純な機能性は、より高速の処理のためのハードウェア回路を使用して実装され得るが、より複雑な機能は、ミリコードを使用して実装され得る。したがって、ＲＭＵのその後の参照はハードウェア又はソフトウェア或いはその両方の組合せのいずれかを参照し得ることが理解されよう。
図９に示すように、メモリ１６は、メモリへのアクセスを制御するためにＭＭＵ２６及びＲＭＵ２０によって使用されるいくつかの制御情報を記憶することができる。これらは、どのプロセスが所与のメモリ領域にアクセスすることを可能にされるかを制御するためのメモリ・アクセス属性を定義する変換テーブル（ページ・テーブルとしても知られる）１２０、並びに仮想アドレスを物理アドレスに変換するためのアドレス・マッピング情報を含む。より大きい特権を有する例外レベルで実行するプロセスが、権限のより低い例外レベルで実行するプロセスは対応するメモリ領域にアクセスすることを可能にされるかどうかを統制する許可を設定することができるように、変換テーブル１２０は、図２に関して前述した例外レベルに基づいて定義され得る。
また、より大きい特権を有するプロセスがアクセスされるかどうかを権限のより少ないプロセスが制御することを可能にするために、いくつかのレルム管理テーブル又はレルム制御情報１２２が、ＭＭＵページ・テーブル１２０への直交方式でのメモリ・アクセスを制御するために提供される（レルム制御は、メモリ・アクセス要求がサービスされるために、それは両方のタイプのアクセス制御検査に合格する必要があり得るという意味で、ＭＭＵ制御に対して直交である）。レルム管理テーブルで、所与のメモリ領域を所有する所有者プロセス（レルム）は、より大きい特権を有する例外レベルで実行するプロセスがそのメモリ領域にアクセスすることを排除する権利を有する。レルム管理データは、所与のレルムのプロパティを記述するレルム記述子１２４を含む。各レルムは、処理回路３２によって実行される少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応する。いくつかのレルムは２つ以上のプロセスに対応してもよく、一方、他のレルムは所与のソフトウェア・プロセスの副部分のみに対応してもよい。レルムはまた、メモリ・アドレス空間の所与の領域（メモリ・アドレス空間の対応する領域内にあるプログラム命令をそれが実行しているときに所与のレルム内で実行する処理回路３２を有する）へのマッピングとして見ることができる。したがって、レルムは、１組のソフトウェア・プロセス又はソフトウェア・プロセスの一部分として、或いはメモリ・アドレス空間のエリアとしてのいずれかで見ることができる。これらの２つのビューは同等である。説明を容易にするために、後述では、少なくとも１つのソフトウェア・プロセスの少なくとも一部分としてレルムを参照することになるが、メモリ領域のコレクションとしてのレルムの対応するビューは、同等に有効である（この場合、レルムへの／からの「エントリ」及び「退出」は、そのレルムに対応するメモリ・アドレスの部分に到達する／これを去るプログラム実行に対応し得る）。
レルム管理データ１２２はまた、レルム退出又はエントリ時に所与のレルムに関連するアーキテクチャの状態を保存及び復元するために使用することができるレルム実行コンテキスト領域１２６を含む。レルム管理データはまた、どのレルムがそのメモリ領域の所有者レルムであるかを、メモリ・アドレス空間の各領域について、定義するレルム・グラニュール・テーブル（又は所有権テーブル）１２８を含む。所与のメモリ領域の所有者レルムは、そのメモリ領域内に記憶されたデータに他のレルム（より大きい特権を有するプロセスを含む）がアクセスすることを排除する権利を有する。このレルム管理データの使用について、以下でさらに詳しく論じる。一般に、レルム管理ユニット２０及びＭＭＵ２６は、そのレルムによって所有されているメモリ領域の所有者レルムによって定義された所有権を行使するメモリ・アクセス回路として見ることができる。これは、たとえば、クラウド・サーバ・オペレータによって提供されるハイパーバイザ３８の制御下で、他の異なるパーティによって提供されるいくつかの仮想マシン３６が実行し得る、クラウド・プラットフォームについて、特に有用になり得る。仮想マシンのうちの１つを提供するパーティは、それらのデータ及びコードがハイパーバイザにアクセス可能になることを望まないことがある。権限のより低い例外レベルで実行するレルムが、より大きい特権を有する例外レベルがそれのデータ又は命令にアクセスすることを排除することができる、レルムの概念を導入することによって、これは、他のパーティによって提供されるコードと物理ハードウェアが共用され得るクラウド・サービスでそれらのソフトウェアをインストールするためのコード開発者の信頼度を上げることができる、ブラインド・ハイパーバイザが提供されることを可能にする。
図１０に示すように、レルムは、ルート・レルム１３０以外の各レルムが、初期化コマンドを実行することによって子レルムを初期化した対応する親レルムを有する子レルムである、レルム階層に従って、ＲＭＵ２０によって管理される。ルート・レルム１３０は、たとえば、最も大きな特権を有する例外レベルＥＬ３において実行するモニタ・コード又はシステム・ファームウェアに関連するレルムでもよい。説明を容易にするために、図１０の実例及び後に論じられる最初の実例は、各子レルムがその親レルムより低い特権を有するレベルにおいて実行する事例を示す。しかしながら、後述するように、その親と同じ例外レベルで実行するサブレルムを確立することもまた可能である。
一般に、ＭＭＵ２６によって提供されるメモリ・アクセス制御のレルム管理部分について、子レルムは、その親レルムによって所有される任意のメモリ領域へのデフォルト・アクセス権を有する。同様に、所与のレルムの任意の子孫は、所与のレルムの所有されたメモリ領域へのアクセス権を有すると想定される。しかしながら、レルム管理制御は、例外レベルに基づいて変換テーブル１２０によって提供される制御に直交であるので、より高い特権レベルにおいて実行するプロセスは、それに応じて変換テーブル１２０のパラメータを設定することによって、権限のより少ないコードがそれのデータにアクセスすることをさらに排除することができる。したがって、一般に、所与の子レルムは、所与の子レルムによって所有された所与のメモリ領域に記憶されたデータにその親レルムがアクセスすることを排除する権利を有する。親レルムが所与のメモリ領域にアクセスすることを子レルムが実際に排除するかどうかは、所有権テーブル１２８において設定された制御属性に基づいて設定され得る（デフォルトは、親レルムは子レルムの所有された領域へのアクセス権を有さないということであるが、子レルムは、それに応じて可視性属性を設定することによって、親レルムにアクセス権を与えることを選択することができる）。複数の兄弟レルム（同じ親レルムを共有する異なる子レルム）が存在するとき、次いで、所与の子レルムは、所与の子レルムによって所有された所与のメモリ領域に記憶されたデータに兄弟レルムがアクセスすることを排除することができる。さらに、所有権テーブル１２８において設定された可視性属性は、兄弟レルムがどの程度互いのデータにアクセスすることができるかを制御することができる。別法として、子レルムがページをその親レルムに可視にした場合に、同ページは、それの兄弟レルム及び兄弟レルムのさらに子孫にも可視になるように、兄弟レルムによるアクセスは、親可視性属性に基づいて、制御され得る。いくつかの事例において、所有権テーブル１２８は、任意のレルムの下で実行する任意のプロセスがその所有するメモリ領域内のデータにアクセスすることを可能にすることを所与の所有者プロセスを許し得るグローバル可視性属性を有し得る。
図１０に示すように、各レルム１４０は、所与のレルムから退出するときに、レジスタ値など、レルムのアーキテクチャ状態を記憶するために使用することができる１つ又は複数のレルム実行コンテキスト（ＲＥＣ：Ｒｅａｌｍ Ｅｘｅｃｕｔｉｏｎ Ｃｏｎｔｅｘｔ）メモリ領域１２６に関連付けられている。所与のレルムのために提供されるＲＥＣ１２６の数は、所与のレルムの下でいくつの実行のスレッドが動作しているかに応じて決まり得る。たとえば、最初に初期化されるときのレルムは、単一の１次ＲＥＣ領域１２６と確立され得るが、次いで、そのレルムは、必要に応じてさらにＲＥＣの役割を果たすようにそのレルムによって所有される他のメモリ領域を構成することができる。ＲＥＣメモリ領域は、その実行状態がそのＲＥＣに記憶された対応するレルムによって所有される。
各レルムは、そのプロパティがレルム記述子１２４に記述されたレルムの親レルムによって所有されているメモリ領域に記憶されたレルム記述子１２４と関連付けられている。レルムの所与の世代において定義することができる子レルムの数の柔軟性のために、レルム記述子は、さらに詳しく後述されるレルム記述子ツリー（ＲＤＴ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ）と呼ばれるツリー構造を使用して、管理される。レルム記述子１２４は、セキュリティを確保するためにレルムからのエントリ又は退出時にＲＭＵ２０によってチェックすることができるレルムのプロパティを定義するために使用することができる。レルムについてのある指定のＲＭＵコマンドの実行が、レルムが安全な方式で作成される及び無効にされることを確実にするために、指定のライフサイクル状態に限定され得るように、レルム記述子はまた、様々なライフサイクル状態を通してレルムの進行を追跡することができる。
図１１及び１２は、可能なレルム階層の２つの異なる実例を示す。図１１の実例では、図２に示されたプロセスのそれぞれが、独自のレルムを定義されている。したがって、ルート・レルム１３０は、例外レベルＥＬ３において動作するモニタ・ソフトウェア又はファームウェアに対応する。ルート・レルムは２つの子レルム１４２を定義し、一方は、安全ＥＬ１で動作する安全オペレーティング・システムに対応し、もう一方は、ＥＬ２におけるハイパーバイザに対応する。ハイパーバイザは、ＥＬ１における異なるゲスト・オペレーティング・システムに対応する孫レルム１４４を定義し、それらのゲスト・オペレーティング・システムのそれぞれは、最も少ない特権を有する例外レベルＥＬ０において実行するアプリケーションに対応する曾孫レルム１４６をさらに定義する。同様に、レルム１４２内の安全オペレーティング・システムは、異なる安全アプリケーションに対応する孫レルム１４８を定義することができる。階層内の親レルムは、それが現在所有するメモリ・ページの所有者を新しい子レルムに移転することができ（後述するようにＧｒａｎｕｌｅ．Ａｄｄコマンドを使用することによって）、又はそれのページのうちの１ページを無効にし、それを子の仮想アドレス空間にマップし、ページ所有権（Ｃｌａｉｍ）コマンドを実行することによってページの所有権を子レルムが請求することを可能にすることができる。メモリ・アドレス空間の指定されたページが、コマンドを発行した親レルムによってすでに所有されていない場合、ページ所有権コマンドは拒否され得る。
図１２に示すように、特権のあらゆるレベルにおけるプロセスが別個のレルムを有することは必須ではなく、したがって、図１２に破線で示された特権レベルの境界線のうちのいくつかは、レルム境界に対応しないことがある。たとえば、図１２において、アプリケーション１５０及びそれのオペレーティング・システムは、例外レベルＥＬ２において動作するハイパーバイザ・レルム１４２と同じレルム内で実行し、そうして、単一のレルムが、ＥＬ２ハイパーバイザ・コード、ＥＬ１で動作するオペレーティング・システム、及びＥＬ０におけるアプリケーションの両方に広がる。他方で、同じハイパーバイザの下の異なるアプリケーション１５２は、独自の別個のレルムを定義され得る。この場合、レルム境界はＥＬ１とＥＬ０との間にあり、ＥＬ２－ＥＬ１レルム境界は存在しない（ハイパーバイザ及びオペレーティング・システムの両方が同レルム内で実行し得る）。別のオペレーティング・システムでは、別個のＥＬ１レルム１５４が定義され得、これは、オペレーティング・システムと同じレルム内で実行するいくつかのアプリケーション、及びそれら自体の専用のレルムを有する他のアプリケーションをさらに有し得る。同様に、安全側では、図１２の安全なＯＳ及びアプリケーションは、ＥＬ３ルート・レルム内で完全に実行し、したがって、安全側で動作しているときにレルム境界は存在しない。したがって、レルムの正確な構成は、実行されているプロセスの必要性に応じて所与のシステムの実行時間において決定され得る。ソフトウェアは、それが小さい固定数の子レルムのみを必要とするか（低レベル・ファームウェアの場合に事実であり得る）或いは多数のレルム又は様々な数のレルムを必要とするか（たとえば、未知数のゲスト仮想マシンを管理することができる、クラウド・プラットフォーム上のハイパーバイザに有用であり得る）を実行時間において判定することができる。
所与の親レルムのレルム記述子１２４は、レルム記述子ツリー（その親レルムのいくつかの子レルムのレルム管理データを定義するレルム管理ツリーの実例である）に従って、管理される。ツリーは、可変数のレベルを有する。図１３は、指定の親レルムによって管理されるそのようなレルム記述子ツリー１６０の実例を示す。ツリー１６０は、いくつかのレルム記述子ツリー・エントリ（ＲＤＴＥ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ Ｅｎｔｒｉｅｓ）１６４をそれぞれ含むいくつかのレルム記述子ツリー・グラニュール（ＲＤＴＧ：Ｒｅａｌｍ Ｄｅｓｃｒｉｐｔｏｒ Ｔｒｅｅ Ｇｒａｎｕｌｅｓ）１６２を含む。各ＲＤＴＥ１６４は、親レルムの所与の子レルムのレルム記述子１６６、又はレルム記述子ツリーの次のレベルのさらなるＲＤＴＧ１６２のいずれかへのポインタを提供する。ツリーの第１のレベルのＲＤＴＧ１６２は、親レルムに関連する（たとえば、親レルムのレルム記述子を有する）データの一部として記憶され得るレルム記述子ツリー・ポインタ１６８によって識別され得る。したがって、親レルムが、所与の子レルムに関連するＲＭＵコマンドを発行するとき、それは、必要とされる子レルムのレルム記述子１６６を見つけるために、ＲＭＵをトリガしてレルム記述子ツリーを走査することができる（そのレルム記述子がＲＭＵ２０内にすでにキャッシュされていない場合）。各ＲＤＴＧ１６２は、可変数のエントリ１６４を有し得る。
図１３のテーブルに示すように、ツリーの後続のレベルにおいてＲＤＴＧ１６２へのポインタを提供する所与のＲＤＴＥ１６４は、ポインタが示すＲＤＴＧにおけるエントリの最大数を示す位数値を含み得る。たとえば、位数値は、ポインタが示すＲＤＴＧにおけるエントリの総数に対応する２つのパワーを示し得る。ＲＤＴＥ１６４に含まれ得る他の情報は、ＲＤＴＥの状態（たとえば、ＲＤＴＥがレルム記述子ツリー・データの割当てのために空いているかどうか、及びＲＤＴＥがさらなるＲＤＴＧ１６２へのポインタ又は子レルム記述子１６６へのポインタを提供するかどうか）を示す状態値を含み得る。ポインタに加えて、ＲＤＴＥはまた、さらなるＲＤＴＥはそのＲＤＴＧ１６２に割り当てることができるかどうかを決定するために有用であり得る、空いていないＲＤＴＧへのポインタにおけるＲＤＴＥの数を追跡することができる参照数を含み得る。親レルムによってトリガされたＲＭＵコマンドは、ツリーのさらなるＲＤＴＧを確立する及び／又は既存のＲＤＴＧ内のＲＤＴＥの内容を編集するようにＲＭＵ２０を制御することができる。
図１３に示すツリーは１つの指定の親レルムの子レルムを示すことに留意されたい。それぞれの親レルムは、自らの子レルムを追跡する別個のレルム記述子ツリーを有し得る。ＲＤＴＧ１６２及び子レルム記述子１６６を含むツリーに関連するデータは、親レルムによって所有されるページ内に記憶され、そうして、他のレルムがこのデータにアクセスすることを排除することができる。したがって、より高い特権レベルで実行するプロセスが、レルムがそれが自分で直接作成した任意の子レルムよりも下に作成したものの可視性を有し得ないように、親レルムのみが、どの指定の子エルムをそれが構成したかの可視性を有し得る。
図１３に示すように、所与の親レルムの子レルムのそれぞれは、指定の子レルムを識別するためにその親レルムによって使用される、対応するレルム識別子（ＲＩＤ：Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）１６８を有し得る。ＲＩＤは、それが指定の親レルムに特有であるという点で、ローカル・レルム識別子である。異なる親レルムの子レルムは、同じローカルＲＩＤを有し得る。所与の子レルムの親レルムによって選択された任意の値を有するローカルＲＩＤを使用することは可能であるが、図１３及び１４に示す手法では、所与の子レルムのローカルＲＩＤは、可変数の可変長ビット部分を有し、可変長部分のそれぞれは、レルム記述子ツリー１６０の所与のレベル内にインデックスを付けるためにＲＭＵ２０によって使用される。たとえば、図１３のローカルＲＩＤ＝７を有する子レルムのレルム記述子は、第１のレベルＲＤＴＧ１６２のエントリ７内のレルム記述子ポインタをたどることによって、アクセスされる。ローカルＲＩＤ＝３．３を有する子レルムのレルム記述子は、ツリーの第１のレベル内のエントリ３、次いで、ツリーの第２のレベル内のエントリ３をたどることによって、アクセスされる。同様に、ローカルＲＩＤ＝１．２を有する子レルムのレルム記述子は、第１の層内のエントリ１と、第２の層内のエントリ２とをたどることによって、アクセスされる。
図１３では、ローカルＲＩＤは、１０進法の形で示されているが、図１４は、これらをどのようにして２進法の識別子を使用して表すことができるかを示す。２進法の識別子は、いくつかの可変長ビット部分１７０を有することができ、それらのビット部分のそれぞれは、ＲＤＴの対応するレベルにおいて使用するために、インデックスを指定することができる。この実例では、最も低い５ビットはツリーの第１のレベルにおけるエントリに対応し、次の４ビットは第２のレベルにおけるエントリに対応する、などとなるように、２進法のローカルＲＩＤは、最下位の端から最初に埋められる。この実例では、最下位部分は値７を提供し、次の最下位ビット部分は値１を提供するなどするので、完全なローカルＲＩＤは、７．１．３に対応する。
それぞれの可変長ビット部分１７０内で使用されることになるビットの数は、レルム記述子ツリーを介してＲＭＵ２０ステップとして走査されるＲＤＴＥ内の位数値を使用することによって決定することができる。ローカルＲＩＤの第１のビット部分の位数値は、親レルムのレルム記述子内で定義され得る（第１のレベルＲＤＴＧポインタと共に）。図１４の実例では、たとえば、３レベルの位数値はそれぞれ、５、４及び２であり、最初の５ビットはレベル１のインデックスを示すことと、その次の４ビットはレベル２のインデックスを示すことと、その次の２ビットはＲＤＴのレベル３のインデックスを示すこととを示す。最終的に、走査するべきツリーのさらなるレベルは存在しないことを示す所定のパターンを有する、ＲＩＤの端（終了）マーカー１７２が達せられ、そうして、最後のレベルのＲＤＴＧ内のポインタからアクセスされる次のメモリ領域は、必要とされる子レルムのレルム記述子を提供することになる。任意の未使用のビットは、ゼロで埋められる。図１４は、ＲＩＤが最下位の端から埋められる実例を示すが、２進法の値の最上位の端から開始するツリーを介して進むために必要とされるインデックスを連結させることによってＲＩＤを構築することもまた可能であろう。
この手法は、異なる数の子レルムが所与の親レルムによって確立されることを可能にするための、並びにそれらの子レルムのレルム記述子効率的にアクセスされることを可能にするための柔軟なインフラストラクチャを提供する。レルム識別子は、レルム記述子ツリー内を進むために必要とされるインデックスを明示的に提供するので、ツリーを通して指定のルートに任意のレルム番号をマッピングするマッピング・テーブルを維持する必要はない。ツリー構造が使用されるとき、その場合、ある指定の固定数のエントリを提供することになるテーブル構造と比較して、ツリーは、必要に応じてツリーの所与のレベルに付加的ＲＤＴＧを追加すること又は付加的ＲＤＴＥを追加することによって、その数の子レルムのために必要とされるように拡張することができる。したがって、その構造は、異なるソフトウェア・プロセスのニーズに拡張可能である。ＲＩＤのどの部分がツリーの所与のレベルにマップすべきかが正確に事前に指定されていないとき、その場合、これは、異なる深度／幅のツリーに対応するために、ＲＩＤの利用可能なビットが柔軟に割り当てられることを可能にする。
レルム管理ユニット２０は、必要とされるときに、たとえば、新しいレルムのプロパティを識別するためにレルムに入る若しくはレルムを出る及び新しいレルムへのエントリが許されるかどうかを決定するときに、或いは、ある指定のＲＭＵコマンドを実行することが適切かどうかを決定するときに、レルム記述子ツリーにアクセスする責任を有し得る。一般に、レルム管理回路は、レルム記述子ツリーの所与のレベル内にインデックスを提供する可変長ビット部分のうちの所与の１つを有する可変数の可変長ビット部分を含む所与のレルムのレルム識別子を使用するレルム記述子ツリーにインデックスを付けることができる。これは、子レルムを確立するための異なるソフトウェア・プロセスの多種多様な要件をサポートするために、レルム識別子ツリーの柔軟な寸法取りを可能にする。
レルム管理回路２０は、レルム記述子ツリーの以前のレベルにおけるエントリ・インデックスによって指定された位数値に基づいて、レルム記述子ツリーの所与のレベル内にインデックスを付けるために使用されることになる可変長ビット部分によっていくつのビットが含まれるかを判定することができる。ツリーのエントリ内に位数値を記憶することによって、次いで、ＲＩＤのどのビットがツリーの所与のレベルにマップされるために使用されることになるかを事前に定義することは必要ではなく、これはさらなる柔軟性をもたらす。
ＲＭＵは、レルム記述子ツリーの同レベルにおける異なる分岐内にインデックスを付けるための可変長ビット部分が異なる数のビットを有することを可能にし得る。すなわち、図１３では、層２内に示された両方のＲＤＴＧ１６２は、同じ位数値（したがって、同数のエントリ）を有するが、これは必須ではなく、一部の実装形態は、異なる数のエントリを有するツリーの同レベルにおいて異なるＲＤＴＧ１６２を有し得る。したがって、それぞれのレルムのＲＩＤの対応する部分は、ツリーの同レベルについて異なる数のビットを有し得る。したがって、ツリーの所与の長さ内にインデックスを付けるために使用されるビット部分の長さの変動は、単に親によって異なるだけではなく、１つの親によって管理されるツリーの異なる分岐内でも変化し得、その中で子レルムが定義され得る形でさらなる柔軟性をもたらす。
一般に、所与のレルムのＲＩＤは、所与のレルムのレルム管理データにアクセスするためにレルム記述子ツリーのそれぞれのレベルにおいて使用されることになるインデックスの連結を含み得る。インデックスがそれらがツリーを通して進むために使用されることになるであろう順番と同じ順番で連結されることは必須ではないが、これはツリー・アクセスの管理をより単純にするので、望ましくなり得る。連結が低から高へ進むか高から低へ進むかは重要ではない。インデックスの連結には、進むべきツリーのさらなるレベルがいつ存在しないかをＲＭＵ２０が判定することを可能にすることができる所定の終了パターンが続き得る。
いくつかの実装形態は、類似のツリー構造においてシステム内のすべてのレルムのレルム記述子を記憶し得るグローバル・レルム記述子ツリーに、このＲＩＤ構築技法を適用し得る（それぞれのＲＩＤがグローバルに一意の値である）。しかしながら、ソフトウェア開発は、１つのツリー内の所与の親の子レルムを定義することと、次いで、その子レルムを追跡するためにそれぞれの他の親レルムの別個のツリーを有することとによって、より単純にすることができる。したがって、レルム記述子ツリーは、所与の親レルムによって初期化された子レルムのレルム管理データを記憶するための所与の親レルムに関連するローカル・レルム記述子ツリーでもよい。したがって、レルム識別子は、所与の親レルムによって使用される指定の子レルムを識別するローカル・レルム識別子でもよい。異なる親レルムによって初期化された子レルムは、同値のローカル・レルム識別子有することを可能にされ得る。このようにして、親レルムは、他のどのようなレルムが他の親レルムによって確立されたかを意識することなく、どのＲＩＤがそれの子レルムのために使用されるかを選択することができ、親レルムがそれのレルム記述子ツリーを構成したやり方に応じて子レルムのＲＩＤは構築される。
ローカル・レルム識別子は、ソフトウェア・プロセスによって発行されたレルム・エントリ命令又はＲＭＵコマンドによって使用され得る。しかしながら、ハードウェア・インフラストラクチャは、異なる親によって作成されたレルムを区別するために、所与の子レルムの絶対識別を使用することができる。したがって、図１３及び１４に示されたローカル・レルム識別子に加えて、所与のレルムはまた、所与のレルムに一意であるグローバル・レルム識別子（又は「内部」レルム識別子）を有し得る。少なくとも１つのハードウェア構造は、ローカル・レルム識別子（ＬＲＩＤ：Ｌｏｃａｌ Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）の代わりにグローバル・レルム識別子（ＧＲＩＤ：Ｇｌｏｂａｌ Ｒｅａｌｍ ＩＤｅｎｔｉｆｉｅｒ）を使用する所与のレルムを識別することができる。たとえば、レルム・グラニュール・テーブル１２８及び／又はＴＬＢ１００は、グローバル・レルム識別子を使用し、レルムを識別することができる。
いくつかの実例では、任意の２進法の値が、その子レルムを参照するために親レルムによって使用されるＬＲＩＤと完全に無関係であり得る、所与のレルムのＧＲＩＤとして割り当てられ得る。同じレルム・アーキテクチャの異なるマイクロ・アーキテクチャの実装形態は、ＧＲＩＤを割り当てるために異なる手法を使用し得る。
しかしながら、図１５に示された１つの実例では、所与のレルムのＧＲＩＤは、それの先祖レルムのＬＲＩＤに基づいて構築され得る。これは、ＭＭＵ２６及びＲＭＵ２０によるアクセス制御に有用になり得る所与のレルムが別のレルムの子孫であるか又は別のレルムの先祖であるかのより単純な判定を可能にすることができるので、有用になり得る。具体的には、共通の先祖レルムを共有するレルムは、ＧＲＩＤの共通の接頭辞又は接尾辞部分を共有し得る。たとえば、子レルムのＧＲＩＤは、その親レルムのＧＲＩＤ及びその子レルムのＬＲＩＤの連結を含み得る。たとえば、図１５に示すように、所与のレルム１８０が、ある指定のローカル・レルム識別子Ｘを有する場合、そのとき、その子レルム１８２は、レルムＸのレルム記述子ツリー内のインデックスに基づいて形成された指定のＬＲＩＤとＸを連結させることによって形成されたＧＲＩＤをそれぞれ有し得る。たとえば、ＬＲＩＤ１．２を有する子レルムは、ＧＲＩＤ Ｘ．１．２を有し得る。同様に、ＬＲＩＤ７を有するレルムＸ．１．２の孫レルムは、ＧＲＩＤ Ｘ．１．２．７を有し得る。
いくつか事例では、ＧＲＩＤにおいて、ＬＲＩＤは、図１４に示された終了マーカー及びゼロで埋められたビットを含んで、連結され得る。別法として、ＧＲＩＤの２進法の表現は、そのような終了マーカー及びゼロで埋められたビットを排除することができ、代わりに、ＲＤＴインデックスを含むＬＲＩＤの有意の部分が、直接連結され得る。それぞれのＬＲＩＤ自体が、関連のある親レルムのＲＤＴの深度及び幅に応じた可変数のビットを有し得るとき、次いで、レルムの所与の世代のローカルＲＩＤを表して割り当てられたグローバルＲＩＤのビットの数は、可変になり得る。さらに、グローバルＲＩＤのどの部分がレルムの所与の世代に割り当てられるかのこの変動は、実行している指定のソフトウェアに基づく実行時間において変化し得るが、家系図の１つの分岐が他よりレルム識別子のより大きな部分を使用し得るように、レルムの「家系図」の異なる分岐の間で変わり得る。ＧＲＩＤの共通の接頭辞又は接尾辞は、共通の先祖を共有するレルムについては同じであるので、任意の後続の世代は、残りの部分がさらなる世代の間でどのように分けられるかにかかわらず、後の世代に特有なその残りの部分によってまだ区別することができる。
いくつかの先祖レルムのＬＲＩＤの連結としてＧＲＩＤを構築することによって、これは、第１のレルムが第２のレルムの先祖又は子孫であるかどうかのより効率的な判定を可能にする。たとえば、同じファミリ内のより早い及びより後のレルムのグローバルＲＩＤの比較が一致することを可能にするために、ビット・マスキングを使用してより後の世代に対応するグローバルＲＩＤの部分をマスク・アウトすることによって、第１のレルム及び第２のレルムのうちの１つのレルムのグローバルＲＩＤが、他方のレルムのグローバルＲＩＤの接頭辞又は接尾辞部分と一致するかどうかを判定するために、（たとえば、ＴＬＢ１００又はＲＭＵ２０内に）回路が提供され得る。
すべてのローカルＲＩＤが図１３に示されたツリー・インデックス手法の連結を使用して構築される必要はない。いくつかの事例では、ローカルＲＩＤの指定の値が、ある指定のデフォルト・レルムを参照するために確保されることが有用であることがある。現在のレルム又は現在のレルムの親レルムを指定するＲＭＵコマンドは、比較的一般的でもよい。したがって、所定のＲＩＤ値は、現在のレルムの親レルムを参照するために確保され得る。たとえば、すべてのビットが１に設定された（１の値を示す）ＬＲＩＤは、現在のレルムの親レルムを参照するために確保され得る。同様に、所定のレルム識別子値は、現在のレルム自体を参照するために確保され得る。たとえば、０のＬＲＩＤ値は、現在のレルムを参照するために使用され得る。子レルム記述子が、ＲＤＴの各レベルにおいてＲＤＴＥ０を使用し、識別される場合でも、それは、少なくとも１つのビットを１に設定され得る、この終了マーカー１７２を含み得るので、結果として生じるＲＩＤ値はゼロとまだ同等ではないことをそれは意味するので、ＬＲＩＤにおけるＲＩＤ終了マーカー１７２の使用は、ゼロの値が現在のレルムの所定のレルムＩＤ値として使用されていることをサポートするのに役立つことに留意されたい。したがって、ＲＩＤの端を示すことに加えて、終了マーカー１７２はまた、他の機能をサポートすることができる。
ＲＭＵは、それがそれのレルム記述子ツリーを確立しているときにそれが満たさなければならない制約を問い合わせるために、所与のレルムによってトリガされ得る、ある種の問合せコマンドをサポートし得る。たとえば、問合せコマンドに応答して、ＲＭＵ２０（又は処理回路３２）は、所与のレルムによって定義されることを可能にされたレルム記述子ツリー１６０のレベルの最大数、所与のレルムのツリー構造の所与のレベルにおいて許されたツリー・エントリの最大数、及び／又は所与のレルムによって初期化され得る子レルムの最大数のうちの少なくとも１つを示す、制約値を返し得る。たとえば、システムは、指定のハードウェア実装形態のために使用されるＬＲＩＤ又はＧＲＩＤにおいて利用可能なビットの数などのプロパティを示し得るレジスタを含み得る。ＲＭＵ又は処理回路は、問合せコマンドに応答して、レルム識別子（又は、適切な応答は指定のプロセッサ実装形態のためのハードワイヤードでもよい）のために利用可能なビットの数をチェックし得、さらなる子を定義するために現在のレルムのためにいくつのビットが利用可能に残っているかを判定するために、識別子のいくつのビットがグローバル・レルム識別子において先祖レルムによってすでに使用されているかを指定する情報をチェックし得る。親レルムは、それのＲＤＴをどのように構築するかを決定するために、問合せコマンドへの応答を使用することができる。
図１６は、所与のレルムのレルム記述子１６６の内容の実例を示す。これは単に１つの実例であり、他の実装形態は、掲載された情報のすべてを含まないことがあり、又は追加の情報を含み得ることが理解されよう。この実例では、レルム記述子は、以下を含む。
・レルムのグローバルＲＩＤ。したがって、ローカルＲＩＤに基づくレルム記述子ツリーを通過することによって、対応するグローバルＲＩＤは、識別することができ、これは、所与のレルムによってＴＬＢなどのハードウェア構造体にインデックスを付けるために、又は所有権テーブル若しくはＧＲＩＤに基づいて定義される他の情報をチェックするために、使用することができる。
・所与のレルムによってトリガされた所与のコマンドを受け入れるかどうかを決定するためにＲＭＵ２０によって使用され得る、所与のレルムのライフサイクル状態。
・所与のレルムのタイプ。たとえば、レルム・タイプは、後述するようなレルムが完全レルムであるかサブレルムであるかを示すことができる。
・対応するレルムの境界例外レベルを識別する、境界例外レベル（ＢＥＬ：Ｂｏｕｎｄａｒｙ Ｅｘｃｅｐｔｉｏｎ Ｌｅｖｅｌ）値。ＢＥＬは、レルムが実行することを許される最高の特権レベルを示す。たとえば、図１２のレルム１４２はＥＬ２のＢＥＬを有し得、レルム１５２はＥＬ０のＢＥＬを有し得、そして、レルム１５４はＥＬ１のＢＥＬを有し得る。ＢＥＬは、現在のレルム内で例外が取られ得るかどうか、又は例外を処理するために親レルムへのレルム退出が必要とされるかどうかを判定するために、例外が発生したときに使用することができるので、レルム記述子においてＢＥＬを識別する明示的パラメータを提供することによって、これは、複数の例外レベルにわたるレルムの柔軟性を実現する。
・レルム及びその子孫によって所有されるメモリ領域（レルム保護グラニュール又はＲＰＧ）の総数を示すリソース・カウント。これは、レルム及びその子孫によって所有されるすべてのメモリ・ページが、それらのメモリ領域が異なるレルムに割り当てられ得る前に、無効にされる（及びデータを究極的にワイプされる）ことを確実にするために使用される。たとえば、リソース・カウントは、いくつの領域がまだ消去される必要があるかを追跡するために使用することができる。
・レルムの保護されたアドレス範囲の開始及び終了アドレス。たとえば、保護されたアドレス範囲は、その中でページは対応するレルムによって所有され得るメモリ・アドレス空間の範囲を定義し得る。レルム記述子において定義された保護されたアドレス範囲をメモリ・アクセスの後続のアドレスと比較することによって、レルムによって以前所有されたメモリ領域がもはやレルムによって所有されていない事例が識別され得るので、これは、子レルム・データにアクセスする試みにおいて子レルムに以前割り当てられた領域の所有権を再請求する悪意ある親レルムに対する保護のために有用であり得る。
・所与のレルムに関連するデータを暗号化する又は解読するために暗号回路１０４によって使用される１つ又は複数の暗号化鍵。この実例では、２つの別個の暗号化鍵が提供される。レルムによって所有される内容及びメモリを暗号化／解読するためのメモリ鍵と、前述のような永続記憶装置６にメモリ１６の間でエクスポート／インポートされるデータを暗号化／解読するためのページング鍵。しかしながら、他の実例では、同じ鍵が両方の目的のために使用され得、或いは、さらなる鍵が他の指定の目的のために提供され得る。
・レルム記述子ツリーのルートを識別するレルム記述ツリー・エントリ（ＲＤＴＥ）。レルム記述子におけるＲＤＴＥは、ルートＲＤＴＧにアクセスするためのポインタ（及び、そのＲＤＴＧのためのインデックスとしていくつのビットを使用するかを定義する位数値）を提供する。
・レルムの実行に関連するアーキテクチャの状態を保存又は復元するための１次ＲＥＣ（レルム実行コンテキスト）メモリ領域へのポインタ。
図１７は、この実例ではクリーン状態、新しい状態、アクティブ状態及び無効状態を含む、所与のレルムが存在することができる１組のライフサイクル状態を示す。図１７は、以下の各状態について示す、各状態のプロパティを要約する。対応する状態内のレルムが、その親レルムによって修正されたそれのレルム記述子１６６のパラメータを有し得るかどうか、そのレルムのために指定された暗号化鍵が有効に使用され得るかどうか、レルムが任意のメモリ領域（ＲＰＧ）を所有し得るかどうか、並びに、そのレルムに関連するコードが実行可能か否か。レルム記述子のパラメータはクリーン状態において修正可能であるが、その他の状態のいずれでも修正することはできないことに留意されたい。これは、悪意ある親レルムが所与のレルムのプロパティを、それがアクティブになった後に、更新することを防止する。また、レルムは、アクティブ状態においてのみ実行可能である。
図１８は、レルムのライフサイクル状態の可能にされた遷移を示す状態機械図である。図１８に示された各状態遷移は、子目標レルムのローカルＲＩＤを指定するレルム管理コマンドを、ＲＭＵ２０に対して、発行する親レルムによってトリガされる（Ｒｅａｌｍ．Ｉｎｖａｌｉｄａｔｅコマンド２１２はまた、目標レルム自体によって発行され得る）。前のレルムはそのローカルＲＩＤのために定義されておらず、レルム記述子レジスタ・グラニュール・コマンド２００が親レルムによって実行されるとき、これは、指定されたローカルＲＩＤを有する子レルムのレルム記述子として親レルムによって所有されている所与のメモリ領域の構成をトリガする。子レルムのグローバルＲＩＤは、親レルムのグローバルＲＩＤとレルム記述子レジスタ・グラニュール・コマンド２００において指定された新しいローカルＲＩＤとの連結に基づいて、設定され得る。指定された子レルムは、次いで、クリーン状態２０２に入る。クリーン状態において、親レルムは、子レルムのレルム記述子の様々なパラメータを更新することによって、子レルムのプロパティを設定することができる。これらのプロパティは、親レルムによって発行されたさらなるＲＭＵコマンドを使用し、修正することができる（指定された子レルムがクリーン状態にない場合、コマンドを修正するそのようなレルム記述子は拒否され得る）。親レルムが、子レルムのレルム記述子のパラメータの設定を終えたとき、親レルムは、子レルムのＬＲＩＤを指定するレルム初期化コマンド２０４を実行し、これは、クリーン状態２０２から新しい状態２０６への子レルムの遷移をトリガし、この時点で、レルム記述子のパラメータは、もはや親レルムによって修正不可能である。指定されたレルムが現在、クリーン状態にない場合、レルム初期化コマンド２０４は失敗することになる。
レルムが新しい状態２０６にあるとき、レルムのローカルＲＩＤを指定するレルム・アクティブ化コマンド２０８の実行は、新しい状態２０６から、レルムが現在実行可能であるアクティブ状態２１０への遷移をトリガし、この後、対応するレルム内へのレルム・エントリは、もはや障害をトリガしないことになる。レルムは現在、完全に動作可能である。クリーン状態２０２、新しい状態２０６、及びアクティブ状態２１０のうちのいずれかにおける子レルムの親レルムによってトリガされた後続のレルム無効化コマンド２１２は、無効状態２１４への遷移をもたらすことになる。無効状態２１４を離れ、クリーン状態２０２に戻るために、親レルムは、レルム消去コマンド２１６を実行しなければならない。レルムによって所有されるページの数を追跡するリソース・カウントが、ゼロ以外の値を有する場合、レルム消去コマンド２１６は拒否される。したがって、レルム消去コマンド２１６が成功するために、親レルムは先ず、無効レルムによって所有されるあらゆるページのためにＧｒａｎｕｌｅ．Ｒｅｃｌａｉｍコマンドを発行しなければならない。Ｇｒａｎｕｌｅ．Ｒｅｃｌａｉｍコマンドは、目標メモリ・ページを指定し、目標ページの無効化をトリガしてそのページをアクセス不可能にし、そしてまた、ページの所有者レルムの参照数を１つ減らす。クリーン・コマンドが、その後に発行されてメモリ・ページを無効から有効に遷移させるとき、上書きが行われ得るので、Ｇｒａｎｕｌｅ．Ｒｅｃｌａｉｍ又はレルム消去コマンド２１６を実行するときに無効領域においてデータを実際に上書きする必要はない（後述の図２２を参照）。また、レルム消去コマンドに応答して、無効にされたレルムに関連する任意のキャッシュされたデータもまた、処理要素８、１０、１２のいずれか（ＲＭＵコマンドを実行する処理要素のみならず）のＴＬＢ１００又はキャッシュ１１０内で、無効にされ得る。グローバルＲＩＤは、キャッシュされたデータのそのような無効化をトリガするために使用され得る。
したがって、所与のレルム識別子に関連するレルムの管理されたライフサイクルを提供することによって、これは、レルムがそれのパラメータが修正され得るクリーン状態に戻り得る前に（したがって、所与のレルム識別子が、異なるレルムによる使用のためにリサイクルされ得る前に）、古いレルムに関連するいずれかのデータが同じレルム識別子の再使用を介して他のレルムに漏らされることを防止するために、同じレルム識別子を使用した前のレルムに関連するデータはメモリ及び任意のキャッシュから消去されなければならないことを確実にする。レルムがクリーン状態２０２にあるとき、それのレルム記述子はまた、レルム記述子において記憶されたメモリ領域が他の目的のために割り当てられることを可能にするレルム記述子解放コマンド２１８を実行することによって、キャンセルすることができる（この時点で、レルムはすでにクリーンであるので、消去は必要とされない）。
図１９は、レルム・グラニュール・テーブル１２８（又は所有権テーブル）のエントリの内容の実例を示す。各エントリは、メモリ・アドレス空間の所与のメモリ領域に対応する。所与のメモリ領域のサイズは、実装形態により、固定でも又は可変でもよい。所有権テーブル１２８が構造化される具体的なやり方は、実装形態の要件に応じて有意に変化し得、したがって、所与のエントリの対応するメモリ領域が識別される具体的なやり方は、変化し得る（たとえば、データは、対応する領域を識別する各エントリにおいて記憶され得、或いは、別法として、対応するエントリは、テーブル自体の中の対応する所有権エントリの位置に少なくとも部分的に基づいて識別され得る）。さらに、図１９は、所与のメモリ領域について指定され得るパラメータの指定の実例を示すが、他の実例は、より多くの情報を提供し得る、又は示された情報のタイプのうちの一部を省略し得る。
図１９に示すように、各所有権テーブル・エントリは、対応するメモリ領域について、以下を指定することができる。
・そのメモリ領域の所有者レルムを識別するグローバルＲＩＤ。所有者レルムは、他のどのレルムがメモリ領域にアクセスすることを可能にされるかを制御する属性を設定する権利を有するレルムでもよい。
・どのＲＭＵコマンドがメモリ領域で実行されることを可能にされるかを制御するために使用される対応するメモリ領域のライフサイクル状態。
・メモリ領域が所有者レルムによって所有されるようになった時点でＭＭＵ２６によってメモリ領域がマップされた先のマップされたアドレス。マップされたアドレスは、仮想アドレス又は中間物理アドレスでもよい。所有権テーブルにおいてこのアドレスを指定することによって、これは、所与のメモリ領域の所有権をレルムが取得した後に、アドレス変換テーブルを再マッピングすることによってレルム・インフラストラクチャによって提供されるセキュリティを回避しようとする潜在的な企てに対して保護することができる。
・所有者に加えてどのレルムがメモリ領域にアクセスすることができるかを指定する可視性属性。たとえば、図２０に示すように、可視性属性は、現在のレルムの親レルムは領域にアクセスすることを許可されるか否かを制御する親可視性ビットと、任意のレルムが対応するメモリ領域にアクセスすることができるかどうかを指定することができるグローバル可視性ビットとを指定することができる。一般に、レルム保護方式は、現在のレルムの子孫レルムはその親又は先祖レルムによって所有されるメモリ領域にアクセスすることを常に許可されると仮定し得る（特権レベルに基づく保護を提供する変換テーブル１２０に基づいてアクセスが許されるか否かに依存する）が、所与のレルムは、その親又は所与のレルムの直接の子孫ではない任意の他のレルムがメモリ領域にアクセスすることができるかどうかを制御し得る。いくつかの実施例において、親及びグローバル可視性ビットの両方が、所有者レルム自体によって設定され得る。別法として、親可視性ビットが所有者レルムによって設定され得る一方で、グローバル可視性ビットは、所有者レルムの親レルムによって設定されることが可能であることがある（メモリ領域の親可視性ビットがそのメモリ領域の親可視性を与えるようにすでに設定されてあることを条件として）。これは、他のどのプロセスがそれのデータにアクセスし得るかを所有者レルムがどのように制御し得るかの１つの実例にすぎない、ことが理解されよう。
図２１は、そこに所与のメモリ領域が存在し得る異なるライフサイクル状態を示すテーブルであり、そして、図２２は、それぞれのライフサイクル状態の間の遷移をトリガするコマンドを示す状態機械である。図１８に示されたレルム・ライフサイクル状態と類似のやり方で、１つのレルムの所有権から別のレルムの所有権へと渡るメモリ領域が、その領域内のデータが消去される（たとえば、ゼロに設定される）無効化プロセスを先ず経なければならないということを確保するために、メモリ領域ライフサイクル状態の間の遷移は、管理される。したがって、無効状態２２０から、ソフトウェアがメモリ領域にアクセスすることができる有効状態２２２に遷移するために、クリーン・コマンド２２４は、処理要素８で実行するソフトウェアによってトリガされ、ＲＭＵ２０によって実行される必要がある。クリーン・コマンド２２４は、指定のメモリ領域（ページ）を識別し、対応するメモリ領域のメモリ・アドレスを通ってそのメモリ領域内の各場所においてデータを無効化する／ゼロに設定するようにＲＭＵを制御する。目標とされたメモリ領域が無効以外のいずれかの状態にある場合、クリーン・コマンドは拒否される（たとえば、障害がトリガされる）。
いくつかのシステムでは、単にメモリ領域ライフサイクル状態として有効状態２２２及び無効状態２２０を提供することが十分であることがある。しかしながら、図２２の実例では、処理回路３２で実行するソフトウェア（任意のＲＭＵソフトウェア以外の）によってトリガされるＲＭＵプライベート・メモリ領域へのアクセスが拒否されることになるように、所与のメモリ領域はまた、ＲＭＵ２０自体によって排他的アクセス向けに確保された「ＲＭＵプライベート」メモリ領域として指定され得る。これは、前述のように、レルム記述子、レルム記述子ツリー・エントリ、レルム実行コンテキスト及びページングのためのメタデータなどのレルム管理データを記憶するために特に有用になり得る。ＲＭＵによって排他的アクセス向けに確保されたＲＭＵプライベート・メモリ領域として所与のメモリ領域を指定するために属性を提供することによって、これは、レルム方式によって提供されるセキュリティ保護をソフトウェア・プロセスが回避することをさもなければ可能にすることができたであろうレルム管理データへのアクセスを、メモリ領域自体の所有者プロセスを含む、ソフトウェア・プロセスが行うことを防止することができる。
したがって、クリーン・コマンド２２４は、これが通常のクリーン・コマンドであるかプライベート・クリーン・コマンドであるかを指定するプライバシ指示を、それのパラメータのうちの１つとして、指定することができる。別法として、２つの完全に別個のコマンドが、これらの目的のために提供され得る。クリーン・コマンドが通常のクリーン・コマンドであるとき、これは、前述のような有効状態２２２への遷移をトリガする。しかしながら、クリーン・コマンドがプライベート・クリーン・コマンド２２４であるとき、これは、ＲＭＵＣｌｅａｎ状態２２６への遷移をトリガし、ＲＭＵＣｌｅａｎ状態２２６では、メモリ領域はＲＭＵプライベート・メモリ領域として指定される。いくつかの実例では、全タイプＲＭＵデータは、ＲＭＵクリーン状態に対応する単一のタイプのＲＭＵプライベート・メモリ領域内に記憶され得る。
しかしながら、頑強性が、指定の形のレルム管理データにそれぞれ対応する複数のタイプのＲＭＵプライベート・メモリ領域を指定することによって、改善され得る。たとえば、図２１及び２２では、指定の目的のために指定されたＲＭＵプライベート領域にそれぞれ対応する、いくつかのＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８が、定義される。この実例では、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８は、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＤＴ（レルム記述子ツリーのＲＤＴＧを記憶するための）、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＤ（レルム記述子を記憶するための）、ＲＭＵＲｅｇｉｓｔｅｒｅｄＲＥＣ（レルム実行コンテキスト・データを記憶するための）及びＲＭＵＲｅｇｉｓｔｅｒｅｄＭＤＴ（前述のようなエクスポート／インポート動作中に使用されるページング・メタデータを記憶するための）を含む。異なる形の登録コマンド２３０が、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態２２８のうちの対応する１つにメモリ領域を遷移させるために、ＲＭＵＣｌｅａｎ状態におけるメモリ領域のＲＭＵによって実行され得る。指定された目的（ＲＤＴ、ＲＤ、ＲＥＣ又はＭＤＴ）に対応しないＲＭＵプライベート・メモリ領域にデータを記憶するためのコマンドは、拒否され得る。したがって、ＲＭＵＲｅｇｉｓｔｅｒｅｄ状態の第１のライフサイクル状態において、第１のタイプのレルム管理データを記憶するための第１のタイプのＲＭＵコマンドが可能にされ得、そして、第２のライフサイクル状態において、第２のタイプのレルム管理データを記憶するための第２のタイプのＲＭＵコマンドが可能にされ得、目標とされたメモリ領域が第２のライフサイクル状態にあるときには第１のＲＭＵコマンドが拒否され、そして、目標とされたメモリ領域が第１のライフサイクル状態あるときには第２のＲＭＵコマンドが拒否される。これは、たとえば、子レルムの動作を中断させようと試みるために、レルム記述子エントリをレルム実行コンテキスト領域に記憶しようと試みる又はその逆の、悪意ある親レルムを回避することによって、さらなるセキュリティを可能にし得る。それぞれのＲＭＵレジスタ状態２２８から、対応する形態の解放コマンド２３２は、対応するメモリ領域を無効状態２２０に返し得る。さらなるクリーン・コマンドは、領域が汎用データに再割り当てされ得る前に、前に定義されたＲＭＵプライベート領域からのデータの消去をトリガし得る。
したがって、要約すると、所与の所有者レルムによってまだ所有されているが、それがＲＭＵによって排他的アクセス向けに確保されていることを意味する所有権テーブルにおいて指定された属性を有する、少なくとも１つのＲＭＵプライベート・メモリ領域が、定義され得る。この実例では、ＲＭＵプライベート状況を制御する属性は、所有権テーブル内の対応するエントリにおいて指定されたライフサイクル状態であるが、それはまた、他のやり方で識別され得る。ＭＭＵは、所与のメモリ領域が少なくとも１つの状況属性によってＲＭＵプライベート・メモリ領域として指定されたときに１つ又は複数のソフトウェア・プロセスによるその所与のメモリ領域へのアクセスを防止し得る。したがって、ＲＭＵ自体によってトリガされていない任意のソフトウェアでトリガされたアクセスは、それがＲＭＵプライベート・メモリ領域を目標とするとき、拒否され得る。これは、所有者レルム自体によるＲＭＵプライベート・メモリ領域へのアクセスの防止を含む。
所有者レルムがそのメモリ領域内のデータにアクセスすることさえできない場合に、ＲＭＵプライベート・メモリ領域の所有者レルムを定義することが何故有用であるのかと疑問に思う人があるかもしれない。たとえば、ＲＭＵのみによってデータへのアクセスを行使するための代替手法は、ＲＭＵのための特別なレルムを定義すること、並びに、その特別なＲＭＵ所有者レルムにプライベートなものとして維持されることになるデータを記憶するためのメモリ・アドレス空間のページを割り当てることであろう。しかしながら、レルムを無効にするとき、そのレルムに関連するすべての制御データを無効化するという要件が存在することがあり、そして、この制御データが、無効にされたレルムではなくて特別なＲＭＵ所有者レルムに関連していた場合、これは、無効にされたレルムのデータの消去をより複雑にする可能性があるということを本発明者は認識した。
対照的に、ＲＭＵプライベート属性を使用することによって、所与のレルムの制御データを記憶するメモリ領域は、たとえ所有者がそれにアクセスすることができなくても、そのレルムによってまだ所有されており、これは、どのメモリ領域がその所有者レルムがキャンセルされたときに無効にされる必要があるかを識別することがより単純であるということを意味する。所与のレルムが無効にされるとき、親レルムは、指定された無効にされたレルム（又はその子孫）によって所有されているメモリ領域が無効にされる、及びアクセス不可能にされる、及び再請求コマンドをトリガした親レルムの所有権に返されるようにトリガする一連の再請求動作を単純に実行することができる（たとえば、次いでＲＭＵによる作用を受ける再請求コマンドを実行することによって）。再請求動作は、無効にされたレルムにアクセス可能なページに影響し得るのみならず、無効にされたレルムによって所有されるＲＭＵプライベート・メモリ領域も含み得る。
そのレルムによって所有されるＲＭＵプライベート・メモリ領域内のレルムの制御データを記憶することのもう１つの利点は、エクスポート動作を実行するときである。レルムのメモリ・フットプリントをゼロまで減らすために、エクスポート動作中に、そのレルムに関連する管理構造体が、通常のメモリに加えて、エクスポートされ得る。それらの構造体がレルムによって所有されることを要求することは、このエクスポート動作の管理を単純化する。
一般に、任意の種類のレルム管理データが、ＲＭＵプライベート領域において記憶され得るが、具体的には、レルム管理データは、以下のうちのいずれかを含み得る。所与のレルムのプロパティを定義するレルム記述子、所与のレルムのレルム記述子を記憶するメモリ領域を識別するレルム記述子ツリー・エントリ若しくはさらなるレルム記述子ツリー・エントリ、所与のレルム内の少なくとも１つのスレッドの実行に関連するアーキテクチャの状態を示すレルム実行コンテキスト・データ、及び所与のレルムに関連する所定の動作の中間点において使用される一時的作業データ。
一般に、ＲＭＵプライベート領域は、所与のレルムに関連する指定のレルム制御データを記憶するために使用され得るが、それはまた、レルムがアクティブになると実行されるある指定の他の動作の周囲のセキュリティを向上させるために使用され得る。たとえば、データが暗号化又は解読される前述のページング・エクスポート又はインポート動作を実行し、メタデータを使用するチェックが実行されて、そのデータが再びインポートされるときにそのデータがまだ有効であることをチェックするとき、そのような動作は、多数の周期を取り得、そのような長く続く動作は、途中で中断される可能性が高い。再び最初から動作を開始する必要のないように、そのようなデータを他のプロセス（所有者レルム自体を含む）にアクセス可能にすることなく、中断されたときにもそのような長く続く動作に関連するメタデータ又は他の一時的作業データがキャッシュ／メモリ内に保持されることを可能にすることが望ましくなり得る。ＲＭＵプライベート領域としてメモリ・システムの領域を一時的に指定することによって、この一時的作業データを保護することができる。したがって、図２１に示すように、ページ状態はまた、この一時的作業データがメモリ領域に記憶されるときに使用することができるＲＭＵＥｘｐｏｒｔｉｎｇ及びＲＭＵＩｍｐｏｒｔｉｎｇ状態を含むことができ、そして、これらの状態のうちの１つが選択されるとき、次いで、ＲＭＵのみがそのデータにアクセスすることができる。
ＲＭＵプライベートとして対応するメモリ領域を一時的に指定することから恩恵を受ける得る動作の他の実例は、以下を含み得る。所与のレルムによって所有される少なくとも１つのメモリ領域と所与のレルム以外のレルムによって所有される少なくとも１つのメモリ領域との間のデータの移転中の暗号化又は解読されたデータの生成又は検証と、別のレルムへのメモリ領域の所有権の移転と、無効にされたメモリ領域に記憶されたデータをアクセス不可能にさせるために実行される破壊的再請求動作。たとえば、アドレス空間の所与のページのすべての内容を消去するための再請求動作は、途中で中断され得、したがって、消去が完了するまで他のプロセスがそのページにアクセスすることができないことを確実にするために、そのページは、一時的にＲＭＵプライベートとして指定され得る。一般に、ＲＭＵによって実行される任意の長いレイテンシ動作は、長く続く動作を開始し、次いで、長く続く動作が完了するときにそれを変換し戻す前に、いくつかのメモリ領域のライフサイクル状態をＲＭＵプライベート状態に変換することによってそれの一時的作業データを保護させることから恩恵を受け得る。
領域が、ＲＭＵプライベートとして指定されるとき、それは、レルム管理動作を実行するために使用されるＲＭＵ２０によるアクセスのために確保される。レルム管理動作は、以下のうちの少なくとも１つを含み得る。新しいレルムを作成することと、既存のレルムのプロパティを更新することと、レルムを無効にすることと、所与のレルムによる所有権のメモリ領域を割り当てることと、所与のメモリ領域の所有者レルムを変更することと、所与のメモリ領域の状態を変えることと、所与のメモリ領域の所有者レルムによってトリガされたコマンドに応答して所与のメモリ領域へのアクセスを制御するためのアクセス制御情報を更新することと、１つ又は複数のソフトウェア・プロセスの処理中にレルム間の遷移を管理することと、所与のレルムへの所与のレルムによって所有されるメモリ領域と異なるレルムによって所有されるメモリ領域との間の所与のレルムに関連するデータの移転を管理することと、所与のレルムに関連するデータの暗号化又は暗号解読。ＲＭＵは、レルム管理動作の少なくとも一部分を実行するためのハードウェア・ユニットでもよく、又はレルム管理動作の少なくとも一部分を実行するためにレルム管理ソフトウェアを実行する処理回路３２を備えてもよく、或いはその両方の組合せでもよい。
図２２は、それが有効にアクセスされ得る、又は対応するページを無効化し得るように、所与のページをクリーニングするために所与のレルムによってトリガすることができる状態遷移を示す。図２３は、これを拡張して、１つのレルムから別のレルムに所与のページの所有権を移転するために使用することができるさらなるコマンドを示す。親レルムによる領域請求コマンド２３０の実行は、そのメモリ領域が、現在、無効状態２２０にあり、親レルムによって所有される場合に、対応するメモリ領域が指定された子レルムに移転されることを可能にする。目標メモリ領域が所与の子レルムの親レルム以外の任意のレルムによって所有されるとき、又はメモリ領域が有効である若しくはＲＭＵプライベート・ライフサイクル状態２２６、２２８のうちの１つにある場合、領域請求コマンド２３０は拒否される。これは、それ自体がアクセス権を有さない又はＲＭＵ２０によって使用中であるページの所有権を親レルムが任意に譲渡するのを防止する。ページが子レルムに譲渡された後は、次いで、その子レルムは、図２２に示すのと同じやり方で有効状態２２２に遷移するためにクリーン・コマンドを実行することができる。簡潔にするために、ＲＭＵプライベート領域の使用は図２３には示されていないが、任意の所与のレルム内で、プライベート・クリーン・コマンドは、別法として、前述のようなＲＭＵクリーン状態２２６にメモリ領域を遷移させ得る。
グラニュール請求コマンド２３０は、すでに確立された子レルムに所有権を移転するために使用される。加えて、親レルムが、子に譲渡された領域にデータを書き込むことができるように、親レルムは、新しい状態にある新しい子レルムに所有権を譲渡するようにＲＭＵ２０をトリガするグラニュール追加コマンド２３２を実行することができる。たとえば、これは、新しい子レルムが第１の時間に実行することができるように、新しい子レルムのプログラム・コードをインストールするために使用することができる。したがって、追加コマンド２３２は、対応するメモリ領域が子レルムに割り当てられたライフサイクル状態に関して、請求コマンド２３０とは異なる。追加コマンド２３２は、図１８に示された新しい状態２０６に子レルムがあるときにのみ可能にされ得る。子レルムは、所有権テーブル１２８の対応するエントリを更新するようにＲＭＵをトリガするグラニュール解放コマンド２３４を実行すること、並びに子レルムのレルム記述子内のリソース・カウントなどのプロパティを更新することなどによって、その親に所与のメモリ領域の所有権を解放して返すことができる。指定されたメモリ領域が、グラニュール解放コマンド２３４を発行した現在のレルムによって所有されていない場合、又はその領域が無効以外の状態にある場合（それが親レルムによる所有権に返され得る前に、データの破壊的クリーニングを確保することが必要とされる）、グラニュール解放コマンド２３４は拒否され得る。
親レルムが子レルムを初期化する、前述の階層的レルム構造を使用することの１つの利点は、これがレルム及びその子孫の無効化を大きく単純化するということである。所与の仮想マシン・レルムが無効にされようとする場合、そのとき、その仮想マシンの下で実行する任意のアプリケーションのレルムを無効化することもまた望ましくなり得ることは、比較的一般的である。しかしながら、無効にされようとするそれぞれのプロセスに関連する相当量のプログラム・コード、データ及び他の制御情報が存在し得る。データ消去の一部のみが実行されたとき、無効にされたレルムに関連するデータへのアクセスを継続することが不可能であるように、そのような無効化が微細に生じることを確実にすることが望ましくなり得る。各レルムが、前述のようなレルム階層なしに、他のレルムから完全に独立して確立された場合、対応するレルムＩＤによって識別される各レルムを別個に無効化するためにいくつかの別個のコマンドを提供することが必要になり得るので、これは、そのような微細な無効化を難しくし得る。
対照的に、ルート・レルム以外の各レルムが、親レルムによってトリガされたコマンドに応答して初期化された子レルムであるように、ＲＭＵがレルムを管理するレルム階層を提供することによって、その場合、目標レルムの無効化を要求するコマンドが受信されるとき、ＲＭＵ２０は、より効率的動作で、目標レルム及び目標レルムの任意の子孫レルムを処理回路にアクセス不可能にさせることができる。
具体的には、目標レルムの無効化に応答して、ＲＭＵは、目標レルムが無効であることを示すために目標レルムに関連するレルム管理データ（たとえば、レルム記述子）を更新し得るが、目標レルムの任意の子孫レルムに関連する任意のレルム管理データを更新する必要はない。子孫レルムに関連するレルム管理データは、変更されないままにすることができる。これは、所与のレルムへのアクセスがその親を介して制御され、したがって、親レルムが無効にされた場合、次いで、これは親レルムの子孫にアクセスすることもまた不可能であることを意味するので、レルム管理データが変わっていなくても、目標レルムを単純に無効化することは、任意の子孫レルムを実際にアクセス不可能にさせ得るからである。それぞれのレルムが、それの指定の子を識別するために親レルムによって定義されたローカルＲＩＤを使用するレルム・エントリ命令（後述のＥＲＥＴ命令）を使用して入られ、これは、所与の子レルムの親レルムによって所有されるメモリ領域に記憶されたレルム記述子を通過するために使用されるとき、その場合、親レルム以外のプロセスは、子レルムのレルム管理データにアクセスするためにＲＭＵをトリガすることができない。したがって、親レルムが無効にされた場合、次いで、ＲＭＵは、所与の子レルムのレルム管理データにアクセスすることができず、所与の子レルムがアクセス不可能になることを確実にする。
レルムが無効にされた後、そのレルムの親レルムは、無効にされた目標レルムによって所有された各メモリ領域を再請求するための再請求動作を実行するようにＲＭＵをトリガし得る。たとえば、図２３に示すように、子レルムによって所有されているメモリ領域の再請求コマンド２３６は、メモリ領域の無効状態２２０への復帰をトリガすることができ、メモリ領域の所有権を親レルムに移転し戻すこともできる。しかしながら、この再請求動作は、他のレルムの進行中の処理のバックグラウンドで実行することができ、無効にされたレルムの任意の子孫レルムがアクセス不可能にされることを可能にするために瞬時に実行される必要はない。図１８に示すような所与のレルムのレルム状態をアクティブから無効に変えるための単一のアクションは、その無効にされたレルムの任意の子孫レルムに関連するすべてのデータもまたアクセス不可能であることを確実にするのに十分である。任意の親レルムは、それが所有するページをそれの子に譲渡することだけでき、子はそれが所有するページを孫レルムに譲渡することのみできるので、無効にされたレルムの任意のさらなる子孫レルムもまたその範囲内のページを所有することになるので、無効にされたレルム（図１６を参照）のレルム記述子に定義された保護されたアドレス範囲は、どのページを再請求すべきかを識別するために使用することができるので、これはまた、どのページが無効にされる及び所与のレルムを無効化したときに再請求される必要があるかを追跡することが比較的簡単であることを意味する。
したがって、要約すると、レルム階層の使用は、レルムの管理及び無効化を大きく単純化する。そのような無効化、並びにメモリ内のデータの上書きと同時に、無効化はまた、無効化をトリガした処理要素８内のみならず、別のＣＰＵ又はＧＰＵなどの他の処理要素内にも保持される目標レルム及び目標レルムの任意の子孫レルムのキャッシュされたレルム管理データの無効化をトリガし得る。したがって、他の処理要素は無効にされたレルムへのアクセスを有し続けないことを確実にするために、他の処理要素への無効化のブロードキャストが存在し得る。そのような無効化をトリガするとき、所与の子レルムのグローバルＲＩＤが共通の接頭辞部分をその親レルムのグローバルＲＩＤと共用するように、キャッシュされたレルム管理データが、対応するレルムを一意に識別するグローバル・レルム識別子に関連付けられること、及び前述のようなグローバル・レルム識別子を形成することが有用になり得る。これは、所与のレルムが指定されたレルムＩＤの子孫であるかどうかを迅速に比較するためにビット・マスキング又は他の類似の動作が使用されることを可能にする。所与のレルムが、先祖レルムの無効化を介してアクセス不可能にされた場合、次いで、指定された目標レルムに入ろうとする試みは不可能である（そのレルムのためのＥＲＥＴ命令を実行するための親レルムが存在しないので）が、異なるレルム・エントリ機構を使用する他の実装形態においてでも、子孫レルムのレルム記述子がもはや位置確認不可能である場合、レルム・エントリは、失敗し、故障状態をトリガし得る。
図２４は、所与のメモリ・アクセスが許可されたかどうかを判定するために、ＭＭＵ２６及びＲＭＵ２０によって実行されるチェックの一実例を表す。ＭＭＵ２６は、所与のゲスト・オペレーティング・システムによってセットされたステージ１ページ・テーブル１２０－１の制御のもとで、仮想アドレス（ＶＡ：Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ）を中間物理アドレス（ＩＰＡ：Ｉｎｔｅｒｍｅｄｉａｔｅ Ｐｈｙｓｉｃａｌ Ａｄｄｒｅｓｓ）に変換するステージ１、及び、ハイパーバイザ３８によってセットされたステージ２ページ・テーブル１２０－２に基づいて、ステージ１変換によってもたらされた中間物理アドレスをメモリ１６にアクセスするために使用される物理アドレス（ＰＡ）に変換するステージ２アドレス変換といった、アドレス変換の２つのステージをサポートする。ハイパーバイザは、様々な仮想マシンに対して多数のステージ２ページ・テーブルのセットを定義することができ、メモリ・アクセス要求を与えられた仮想マシンＩＤ（ＶＭＩＤ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ ＩＤ）２５０は、どの特定のステージ２ページ・テーブルを使用するか識別することができる。同様に、オペレーティング・システムは、様々なアプリケーションのための多数のステージ１ページ・テーブルのセットを定義することができ、アドレス空間識別子（ＡＳＩＤ：ａｄｄｒｅｓｓ ｓｐａｃｅ ｉｄｅｎｔｉｆｉｅｒ）２５２は、どのステージ１ページ・テーブルを使用するか識別するために使用することができる。ＶＭＩＤ２５０及びＡＳＩＤ２５２は、メモリ・アクセス要求と関連付けられた現在の変換コンテキストを識別する変換コンテキスト識別子２５４と総称することができる。メモリ・アクセス要求はまた、トランザクションが読取り要求（Ｒ）か書込み要求（Ｗ）かを示す属性、又は、メモリ・アクセス要求を発行したプロセスと関連付けられた例外レベル（Ｘ）を示す属性、といった様々な属性２５６を指定する。
メモリ・アクセスを受け取ると、ＭＭＵ２６は、ステージ１ページ・テーブルからの情報に基づいて、トランザクション属性が有効であるかどうか判定することができる。たとえば、ステージ１ページ・テーブルは、あるアドレスに対して読取りトランザクションのみが許可されることを指定できる、又は、所与のアドレスに対して読み取り及び書き込みの両アクセスを可能とすることができる（いくつかの実装形態では、アドレス空間のうち書込み領域のみ定義することを可能とすることもできる）。また、ステージ１ページ・テーブルの属性は、所与の例外レベル又はそれよりも高いレベルで動作するプロセスへのアクセスを制限することができる。トランザクション属性が有効で、アクセスがステージ１ページ・テーブルによって許可された場合、ＭＭＵは対応する中間物理アドレス（ＩＰＡ）を戻すことができる。次いで、ＩＰＡはＶＭＩＤ２５０と共にステージ２ページ・テーブルにインデックス付けを行い、ステージ２ページ・テーブルは再度トランザクションの属性を確認し、有効であれば物理アドレスを戻す。すべてのトランザクションが、アクセス変換の２つのステージを経る必要があるわけではないことに留意されたい。たとえば、入力メモリ・トランザクションがＥＬ３若しくはＥＬ２、又はセキュアなドメイン内のＥＬ１若しくはＥＬ０において発行された場合、ステージ１ＭＭＵの出力は物理アドレスとして扱われ、ステージ２ＭＭＵはバイパスすることができる。
物理アドレスを入手すると、次に、ＲＭＵテーブル１２８（レルム・グラニュール・テーブル）においてその物理アドレスを検索し、ＭＭＵによって実施されたレルム保護によりメモリ・アクセスを進めることができるかどうか判定することができる。レルム・チェックについては以下の図２６でより詳細に説明する。ステージ３におけるＲＭＵチェックが成功した場合、次に有効にされた物理アドレスが出力され、メモリ・アクセスを進めることが許可される。ステージ１若しくはステージ２のアドレス変換における任意のチェック、又はステージ３において行われたＲＭＵによって実施されたレルム保護が失敗した場合、メモリ・アクセスは拒否される。したがって、レルム管理ユニットによって行われる保護は、ページ・テーブル１２０に基づく任意の既存のアドレス変換チェックに加えて、実行されるべきチェックの追加層と考えることができる。図２４で表されたチェックは、比較的実行が遅くなる可能性がある。その理由は、メモリ内に、アクセスし、メモリ・アクセス要求又は現在の変換コンテキスト又はそこからアクセスがなされるレルムのパラメータと比較する必要がある多くのテーブルが存在する可能性があるためである。こうしたチェックをメモリ・アクセスごとに実行することは可能であろうが、所与のメモリ・アクセス要求に対してチェックが首尾よく実行されたとき、ＴＬＢ１００内にデータを速やかにキャッシュすることが可能であり、その結果、次回に類似のメモリ・アクセス要求が発行されたとき、すべてのチェックを再度繰り戻すことなく許可することができる。したがって、ＴＬＢ１００において失敗がありヒットしないときにのみ、こうした許可チェックを実行するのが好ましいであろう。
図２５は、すでに有効にされたメモリ・アクセスに関するデータをキャッシュするためのＴＬＢ構造１００の一実例を表す。図２５は１つのＴＬＢを表しているが、レベル１のＴＬＢがより高速なアクセスのために変換エントリのより小型のサブセットを記憶し、レベル２又はそれ以上のレベルのＴＬＢが、レベル１のＴＬＢに失敗が発生した場合に、アクセス可能な変換エントリのより大きなセットを記憶するといった状態で、いくつかのシステムでは、キャッシュ階層に複数のレベルのＴＬＢを含むことができることが理解されよう。ＴＬＢ１００（又は「変換キャッシュ」）は、いくつかのエントリ２６０を有し、各エントリは対応するメモリ領域のためのアドレス変換データを指定する。各エントリ２６０は、データが対応する物理アドレス２６４を提供する仮想アドレスに対応した仮想的にアドレスされたタグ２６２を含む。この実例では、ＴＬＢはステージ１及びステージ２のＴＬＢが結合されたものであり、そのため、仮想アドレスは、中間物理アドレスを経由する必要なしにＴＬＢを使用して物理アドレスに直接変換することができる（対応するステージ１及びステージ２の変換は、正しい物理アドレスの位置を突き止めるためにＴＬＢがない（ＴＬＢ ｍｉｓｓ）中で実行されるであろうが、ＴＬＢは介在するＩＰＡを記憶する必要はなく、ＶＡを直接ＯＡにマッピングすることができる）。他の実例では、分離したステージ１（Ｓ１）及びステージ２（Ｓ２）のＴＬＢを使用することが可能であるが、そのケースにおいは、ＶＡ－ＰＡペア２６２、２６４は、ＶＡ－ＩＰＡペア又はＩＰＡ－ＰＡペアで置き換えることができる。ＴＬＢエントリ２６０はまた、変換コンテキスト識別子２５４（ＡＳＩＤ２５２及びＶＭＩＤ２５０から構成されている）でタグ付けされる。この実例では、２つの別々の変換コンテキスト識別子が設けられるが、他の実例では、１つの統合された変換コンテキスト識別子を使用することが可能であり、又は、分離したＳ１／Ｓ２のＴＬＢのケースでは、Ｓ１のＴＬＢはＡＳＩＤを使用し、Ｓ２のＴＬＢはＶＭＩＤを使用することができる。変換コンテキスト識別子により、同一の仮想アドレスを指定して、異なる物理アドレスを提供するＴＬＢ１００の異なるエントリにアクセスをマッピングさせる、異なるオペレーティング・システム又はアプリケーションが可能となる。
ＴＬＢ１００におけるヒットには、メモリ・アクセス要求に対して指定されたアドレス２５８の対応する部分をマッチングさせるためのタグ２６２だけでなく、メモリ・アクセスが発行された現在の変換コンテキストがマッチングした場合には、同一のエントリに記憶された変換コンテキスト識別子も必要となる。タグ２６２と変換コンテキスト識別子２５４との比較は、所与のメモリ・アクセスに対する正しい物理アドレス２６４の位置を突き止めるのに十分であると考えられるかもしれない。しかし、この比較が検索で実行される唯一の比較である場合には、ＴＬＢでヒットしたメモリ・アクセスが、レルム管理ユニット・テーブル１２８のさらなるチェックなしに受け取られると、潜在的なセキュリティの脆弱性が存在する。それは、以前に実行されたプロセスと同一のＶＭＩＤ２５０又はＡＳＩＤ２５２を有し、ＭＭＵを欺いて、実際は異なるレルムから所与のメモリ領域にアクセスするために以前に受け取られたレルムへ来た、メモリ・アクセスを受け取らせる新しいプロセスが作成されることが可能なためである。
この問題に対処するために、ＴＬＢ１００は、各ＴＬＢエントリ２６０内で、対応するメモリ領域を有する所有者レルムのグローバルＲＩＤ２７０、並びに、他のどのレルムが対応するメモリ領域にアクセスすることを許可されるかを制御するために所有者レルムによってセットされた可視性属性２７２を指定することができる。所与の変換キャッシュ１００の検索が、所与の目標メモリ領域に対する現在の変換コンテキスト及び現在のレルムから発行されたメモリ・アクセスに応答して実行されたときに、変換キャッシュ１００に失敗が発生した場合、ＴＬＢ制御回路２８０は、アクセスが許可されるかどうかチェックするために、テーブル・ウォーク・ユニット１０２をトリガして適切なページ・テーブル１２０及びＲＭＵテーブル１２８にアクセスする。ページ・テーブル又はＲＭＵテーブル１２８のどちらかが、対応するメモリ領域へアクセスすることから、変換コンテキスト、例外レベル及びレルムの現在の組合せを除外すると、そのメモリ・アクセスに応答して変換キャッシュに割り当てられるデータは何もない。特に、検索が失敗し、現在のレルムが目標メモリ領域の所有者レルムによって目標メモリ領域にアクセスすることから除外されると、アドレス変換データを変換キャッシュに割り当てることが妨害される。したがって、対応するメモリ・アクセスがＭＭＵページ・テーブル１２０及びＲＭＵテーブル１２８の両方のチェックを通過するとき、エントリはＴＬＢ１００に割り当てられる。
次に、変換キャッシュが所与のアドレスにアドレス変換を提供するエントリ２６０をすでに含んでいるかどうかチェックするために、その変換キャッシュを検索するとき、ＴＬＢ制御回路２８０は、対応するエントリ２６０で指定された変換コンテキスト識別子２５４と、メモリ・アクセス要求と共に受け取られた現在の変換コンテキストのための変換コンテキスト識別子２５４との間の第１の比較、及びまた、そのエントリ２６０によって指定されたグローバルＲＩＤ２７０と、メモリ・アクセス要求を発行した現在のレルムと関連付けられた現在のグローバルＲＩＤとの間の第２の比較に基づいて、メモリ・アクセスが変換キャッシュ１００の所与のエントリとマッチングするかどうかを判定する。ＴＬＢエントリは、メモリ領域にアクセスする許可を得ているものとして以前に確認されたレルムから、依然としてアクセスされるという追加チェックを提供することにより、たとえ悪意ある監督プロセスが、所有者レルムによってデータにアクセスすることが可能な以前に存在したプロセスと同一のＡＳＩＤ２５２又はＶＭＩＤ２５０を有する別のプロセスを生成したとしても、グローバル・レルム識別子２７０は、図１８に関して説明したように、レルム消去（ｓｃｒｕｂｂｉｎｇ）コマンド２１６の処理を受けることなく別のプロセッサに再割り当てすることができないので、これにより、現在のレルムのグローバルＲＩＤは有効であると信頼でき、ＡＳＩＤ又はＶＭＩＤに対して可能であるように「偽物」であろうはずがないと意味することを保証できる。したがって、現在のレルムのグローバルＲＩＤが、依然として所有者ＧＲＩＤ２７０及び可視性属性２７２によって示される許可を満足させる場合、これは以前に実行されたレルム・テーブル・チェックが依然として有効であることを示す。
レルム識別子の第２の比較でミスマッチを検出すると、たとえタグ比較及び変換コンテキスト比較がマッチしたとしても、エントリが割り当てられた以降に変換コンテキストＩＤ２５４とレルムＩＤ２７０との間のマッピングに変化が生じたことを示すので、アクセス要求はＴＬＢ内で失敗したと考えられる。これはアクセスが拒否されるであろうということを必ずしも意味しない。というのは、ページ・テーブル及びＲＭＵテーブルの別のウォークは、テーブル・ウォーク・ユニット１０２によってトリガされる可能性があり、レルム・チェックが成功すると、異なるエントリ２６０をＴＬＢ１００に割り当て、新たに割り当てられたエントリからの情報に基づいてメモリ・アクセスをサービスする可能性があるからである。
図２６は、所与のメモリ・アクセスがＭＭＵ２６によって許可されるかどうかを判定する方法を示す流れ図である。ステップ３００において、メモリ・アクセス要求が受け取られ、これはＴＬＢ１００内で検索される。メモリ・アクセス要求は、少なくともアクセスされる仮想アドレス、現在の変換コンテキストを示す１つ又は複数の変換コンテキスト識別子、及び現在のレルムを識別するグローバル・レルム識別子を指定する。たとえば、グローバルＲＩＤは、レルムへのエントリ時に現在のレルムのグローバルＲＩＤで書き込み可能な処理要素８の状態レジスタから読むことができる。
メモリ・アクセス要求に応答して、ＴＬＢ制御回路２８０はＴＬＢの検索を実行する。検索は少なくともＴＬＢのいくつかのエントリにアクセスする。いくつかの手法では、完全に連携されたキャッシュ構造を使用することが可能であり、このケースにおいては、少なくともレベル１のＴＬＢのすべてのエントリは検索され、ヒットしたか失敗したかを識別するために現在の要求のパラメータと比較することができる。他の手法では、１組の連携された（ｓｅｔ－ａｓｓｏｃｉａｔｉｖｅ）キャッシュ割り当てポリシーを使用することができ、このケースにおいては、ＴＬＢの所与のレベルのエントリのサブセットのみを検索し、メモリ・アクセスの目標アドレスを使用してインデックス付けする必要があるだけである。アクセスされたエントリのセットのそれぞれに対して、ＴＬＢ制御回路２８０はいくつかの比較（並行又は逐次のどちらか）を実行する。この比較には以下が含まれる。
・メモリ・アクセス要求のアドレスが、アクセスされたエントリに記憶されたタグ２６２とマッチングするかどうかを比較するためのタグ比較３０２。
・アクセスされたエントリに記憶された変換コンテキスト識別子をメモリ・アクセス要求の変換コンテキスト識別子と比較するための第１の（コンテキスト）比較３０４。
・メモリ・アクセス要求のグローバルＲＩＤをアクセスされたエントリ・セットのそれぞれに対する所有者ＲＩＤ２７０及び可視性属性２７２と比較するための第２の（レルム）比較３０６。
ステップ３０８において、制御回路２８０は、比較３０２、３０４、３０６のすべてに対してマッチを戻したＴＬＢ内にエントリが存在するかどうかを判定し、存在する場合はヒットが識別され、ステップ３１０において、マッチング・エントリ内で指定された物理アドレス２６４が戻され、その物理アドレスに基づいてメモリ・アクセスが続行することを許可される。ヒットしたケースでは、ページ・テーブル又はＲＭＵテーブルの何等の検索を実行する必要はない（メモリ・アクセスに対する所有権テーブル検索は省略可能である）。ページ・テーブル及びＲＭＵテーブルによって提供される保護は失敗時にのみ呼び出される。
３つの比較３０２、３０４、３０６のすべてとマッチするエントリがない場合、失敗が検出される。さらなるＴＬＢレベルが提供されると、ステップ３００～３０８への対応する検索は、レベル２又は後続のレベルＴＬＢで実行することができる。検索が最後のレベルＴＬＢで失敗すると、様々なページ・テーブル及びＲＭＵテーブルのウォークが実行される。したがって、ステップ３１１では、ステージ１のページ・テーブル・ウォークが実行され、ステップ３１２では、ステージ１のページ・テーブル障害が発生した（たとえば、指定された仮想アドレスに対して定義されたアドレス・マッピングが存在しないため、又は、アクセス要求の現在のパラメータ２５６が、目標の仮想アドレスに対して指定されたアクセス許可を破ったため）かどうか判定される。ステージ１の障害が発生すると、ステップ３１４では、メモリ・アクセスが拒否され、メモリ・アクセスに応答するＴＬＢ１００に対するアドレス・マッピング・データの割り当てが阻止される。
他方、アクセス要求がステージ１のページ・テーブル・チェックを通過すると、ステップ３１５でステージ２のページ・テーブル・ウォークがトリガされ、ステージ１のプロセスで戻された中間物理アドレス用のマッピング・データが入手され、ステップ３１６でステージ２のページ・テーブル障害が発生した（この場合も、アドレス・マッピングが定義されなかったため、又は、アクセスがステージ２のアクセス許可によって許可されなかったため）かどうか判定される。ステージ２の障害が発生すると、再度ステップ３１４でアクセス要求が拒否される。
ステージ２の障害が発生しないと、ステップ３１８で、ＲＭＵテーブル検索がステージ２によって戻された物理アドレスに基づいてトリガされ、ステップ３２０で、レルム障害が検出されたかどうか判定される。以下のイベントのいずれかが発生した場合、レルム障害がトリガされることがある。
・対応するメモリ領域に対するライフサイクル状態が、レルム所有権テーブル１２８内で無効であると示された場合。これは、図２２に示すクリーニング動作２２４を経ていないメモリ・アドレス空間のページが、異なるレルムによるアクセスからそのメモリ領域内の別のレルムによって以前に記憶された任意のデータを保護するために、アクセスすることができないことを保証する。
・現在のレルムは、所有者レルムによってそのメモリ領域にアクセスするための対応するメモリ領域として許可されない。所与のレルムが所与のメモリ領域にアクセスすることを許可されないいくつかの理由があろう。所有者レルムが、メモリ領域は所有者自身及びその子孫のみが見ることができると指定した場合、別のレルムはそのレルムにアクセスする許可は得られないであろう。また、現在のレルムが所有者レルムの親レルムであり、所有者レルムは、親レルムにその領域にアクセスすることを許す親可視性属性を定義していない場合、メモリ・アクセスは拒否されるであろう。また、所有者レルムそれ自体は、メモリ領域が上で説明したように目下のところＲＭＵプライベートとしてセットされている場合、メモリ領域にアクセスすることはできないであろう。ＲＭＵチェッキング・ステージにおいて、所有者レルムの子孫レルムはメモリ領域にアクセスすることを許可されよう（メモリ領域がＲＭＵプライベート領域でない限り）。したがって、このチェックにより所有者レルムによってセットされるアクセス許可が強化される。
・仮想アドレス、又は、そこからＳ１／Ｓ２変換により現在のメモリ・アクセスのための物理アドレスがマッピングされる中間物理アドレスが、図１９で表したように、対応するメモリ領域のための所有権テーブル１２８で指定されたマッピングされたアドレスとマッチしない場合、メモリ・アクセスは拒否される。これにより、悪意ある親レルムが所与のメモリ領域の所有者を子レルムに割り当てる状況を防ぐが、ページ・テーブル１２０における変換マッピングを変化させ、その結果、その子レルムによって所有されたページを指すために以前使用された同一の仮想アドレスを使用して、子レルムによってトリガされた後続のメモリ・アクセスが、今度は子レルムそれ自体によって実際に所有されていない異なる物理アドレスにマッピングすることになる。対応するメモリ領域の物理アドレスから、所有権が主張されたときにその物理アドレスを生成するために使用されたマッピング・アドレスへ戻って、所有権テーブルにリバース・マッピングを提供することにより、検出対象であるアドレス・マッピングの変更によりセキュリティ侵害が発生する可能性があり、その結果メモリ・アクセスが失敗することになる。
他のタイプのチェックも実行できることは理解できよう。レルム・チェックが成功した場合、ステップ３２２で物理アドレスが戻され、メモリ・アクセスが物理アドレスを使用して続行可能となり、ページ・テーブル１２０及び所有者レルムから入手された物理アドレス、並びに、要求された仮想アドレス及び変換コンテキストに対応する所有権テーブル１２８から入手された可視性属性を示す、新しいエントリがＴＬＢに割り当てられる。
したがって、要約すると、変換キャッシュ検索中にヒットが検出できるようにマッチする第２の比較（現在のレルムのＧＲＩＤを変換キャッシュのエントリに提供されるＧＲＩＤと比較する）を要求することにより、たとえＴＬＢエントリが割り当てられた後で所与のレルムと関連付けられた変換コンテキスト識別子に変更があったとしても、これをたとえレルム・チェックがＴＬＢヒット時に再度繰り返されなかったとしても、レルム保護を回避するために使用することはできないことを保証する。これにより、すべてのメモリ・アクセス時にレルム・チェックを繰り返すこと（これは、実行するチェックの回数を考えれば、かなりプロセッサの負荷が高い）が不必要になったことにより、効率が向上するようになる。これにより、ヒットすることは失敗することよりもはるかに一般的であるので、ほとんどのメモリ・アクセスがより早く実行できるようになる。メモリ・アクセスと変換キャッシュの所与のエントリ間の不一致は、第２の比較が、そのエントリで指定されたレルム識別子と現在のレルムのレルム識別子との不一致を識別すると検出される。次いで、これにより失敗がトリガされ、正しいアクセス制御データを見つけ出すためにページ・テーブル及びＲＭＵテーブル・ウォークをトリガすることができる（ＶＭＩＤ／ＡＳＩＤが変化するといけないのでレルム・チェックが繰り返される状態で）。
この手法は、以前アクティブであったレルムと関連付けられた消去プロセスを無効にする情報が実行される後まで、ＲＭＵが以前アクティブであったレルムと同じレルム識別子を有する新しいレルムの初期化を阻止することができるため安全である。この消去プロセスは、レルム管理データ及び無効にされたレルムと関連付けられたメモリに記憶された任意のデータの無効化だけでなく、第２の比較がそのエントリのレルム識別子と無効にされたレルムのレルム識別子とのマッチを識別した変換キャッシュの少なくとも１つのエントリの無効化も含むことができる。したがって、これは、レルムと関連付けられた変換キャッシュ１００内のすべてのデータが無効にされない限り、以前のプロセスと同じレルム識別子を使用して異なるプロセスを再作成することは不可能であることを意味している。したがって、ＴＬＢ内のマッチングしたレルム識別子を信頼して、以前に実行されたレルム・チェックは依然として有効であると示すことができる。特に、上で説明したように、各レルムはライフサイクル状態と関連付けることができ、これを使用して消去プロセスの実行を強化することができる。アドレス変換データは、現在のレルムに対する現在のライフサイクル状態がアクティブなときに、変換キャッシュに割り当てることができるだけである。所与のレルム識別子で新しいレルムを初期化するコマンドは、クリーン状態以外のどの状態においても拒否され、アクティブ状態からクリーン状態への遷移には、消去プロセスをトリガするための少なくとも１つのコマンドを含む、実行されるべき所定のコマンド・シーケンスが必要となろう。
変換キャッシュにおける失敗により所有権テーブル検索がトリガされ、これにより、いくつかのメモリ領域のそれぞれに対して、対応するメモリ領域のための所有者レルム、及び、他のどのレルムがメモリ領域にアクセスできるかを制御するための所有者レルムによってセットされたアクセス制限を指定する所有権テーブルにアクセスすることができる。ＴＬＢヒットを判定するための追加的な第２の比較を含むことにより、検索ヒット時に省略される所有権テーブル検索が可能となる。所有権テーブル検索は、ＴＬＢ失敗時に実行される。
図２５は、所有者レルムのＧＲＩＤが各ＴＬＢエントリに記憶される手法を表すが、現在のレルムのＧＲＩＤが対応するメモリ領域にアクセスするのに適切かどうかの判定を可能とする情報を表す他の方法もある。たとえば、許可されたレルムのＧＲＩＤのリストは、ＴＬＢ内で保守することが可能であり、又は、ＴＬＢは、完全なＧＲＩＤの代わりに、アクティブなレルム・リストへのインデックスを含むＴＬＢエントリでアクティブなレルムの別個のリストを保守することができる。これにより、ＴＬＢエントリ内にリストを記憶することと比較してＴＬＢエントリ・サイズを削減することができる。しかし、所有者レルムのＧＲＩＤを単純に表示することは、それにより、ＴＬＢエントリの割り当て及びチェックのプロセスが、アクティブなレルム・リストを調査する際の追加的なレベルの遠回りを避け、ＴＬＢ間のアクティブなレルム・リストの変更の同期を取る必要を避けることによって複雑性が低下するため、許可されたレルムを識別するより効果的な方法になりうる。
ＴＬＢ検索時に実行される第２の（ＧＲＩＤ）比較におけるマッチは、現在のレルム識別子が、双方の対応するＴＬＢエントリ２６０において指定されたグローバル・レルム識別子２７０と厳密に同一であることは必ずしも必要ではないということに留意されたい。すなわち、第２の比較のいくつかの形式は、部分的なマッチングを利用することができる。いくつかの実装形態では、所有者レルムはそれが所有しているページへのアクセスを許可されるだけであり、そのためこのケースでは、現在のＧＲＩＤと所有者ＧＲＩＤ２７０との厳密なマッチが必要となろう。しかし、データがレルム間で共有されるのは有用であるので、可視性属性２７２も所有者レルムがどのアクセスが他のレルムによって許可されるのかを定義できるように提供される。
したがって、ＴＬＢ１００の可視性属性２７２、及び所有者レルムのグローバルＲＩＤ２７０をキャッシュすることにより、ＴＬＢ制御回路２８０は、第２の比較が可視性属性に基づいてマッチを判定するために必要とされるマッチングの範囲を変更することが可能になる。たとえば、可視性属性２７２は、比較を実行するときにＧＲＩＤのどの部分をマスク化すべきか制御することができ、そのため、こうしたマスク化されたビットが不一致だとしても、全体的な比較のマッチングには影響しないので問題はない。たとえば、制御回路は、いくつかのケースでは、現在のレルムが、所有者レルム又は所有者レルムの子孫レルム以外のレルムを示したとき不一致と判定することができる。子孫レルムは、所有者レルムのＧＲＩＤとマッチする接頭辞又は接尾辞を有しているので、上で説明したグローバルＲＩＤフォーマットを使用して容易に識別することができる。
可視性属性の少なくとも１つの値に対して、制御回路は、現在のレルムが、所有者レルム、所有者レルムの子孫レルム、又は所有者レルムの親レルム（たとえば、親の可視性が上で説明したようにセットされる）以外のレルムのときに、不一致を判定することができる。いくつかのケースにおいて、可視性属性の少なくとも１つの値により、制御回路２８０は、どのレルムが現在のレルムであるかにかかわらず（たとえば、グローバルな可視性ビットがセットされる場合）、第２の比較のマッチを判定することができる。したがって、一般に、レルム識別子に基づく第２の比較は、通過させる必要があるが、厳密にどの要求が現在のレルムのＧＲＩＤによって満足されることになるかは、可視性ビット２７２によるであろう。子レルムを初期化した親レルムのレルム識別子に対応するビット部分を含む子レルムのレルム識別子を作成することにより、こうした部分的マッチが効率的に実行できるようになる。グローバル・レルム識別子の様々な可変長ビット部分を、様々な世代のレルムに割り当てる可変割り当てをサポートする実装形態において、ＴＬＢエントリ２６０はまた、ＧＲＩＤを形成するために連結される異なるローカルＲＩＤ間の境界の位置を識別する（親レルムを祖父母又はそれ以前の先祖レルムと区別できるようにするために）いくつかの情報を指定することができる。これにより、ＴＬＢ制御回路２８０が、レルム識別子のどの部分をマスクすべきか判定することができるようになる。他の実装形態に対しては、これは必要でないかもしれない（たとえば、任意の先祖はメモリ領域にアクセスすることが許されているが、そのレルムに対しては所有者レルムが親レルムに可視性をすでに与えている場合）。また、いくつかの実装形態では、個々のグローバル・レルム識別子が固定数ビット（３２ビットなど）を持った状態の固定したマッピングを有する場合があり、このケースでは、任意の追加的な境界定義データを提供する必要はないであろう。
図２７は、様々な例外レベルにおいて処理要素８がアクセス可能なアーキテクチャの状態の一実例を表すベン図である。図２７は、英国ケンブリッジのＡＲＭ（登録商標）社によって提供されたＡＲＭ（登録商標）に基づく一実例を表すが、他の実装形態は、所与のプロセスと関連付けられた様々な状態を有してもよい他のアーキテクチャに基づいてもよい。また、図２７は、簡単にするために一実例として使用される、各例外レベルでアクセス可能な状態のサブセットを表しているだけであるが、図２７には示していない他のレジスタもアクセス可能であることを理解されたい。
例外レベルＥＬ０で動作するとき、処理要素８は、たとえば以下を含む、３５０と名付けられたアーキテクチャの状態のサブセットにアクセスする。
・データ処理動作中に汎用データ値を記憶するための、整数レジスタ、浮動小数点レジスタ及び／又はベクトル・レジスタを含む汎用レジスタ。
・プログラム実行中に、現在の実行点を表すプログラム命令アドレスを記憶するプログラム・カウンタ（ＰＣ）・レジスタ。
・例外レベルＥＬ０で実行されたプロセスからある例外が除去されたときの、プロセッサの現在の状態についての情報を記憶するために使用される、保存されたプロセッサ状態レジスタ（ＳＰＳＲ＿ＥＬ０）。ＳＰＳＲは、たとえば、例外が発生したときの現在のプロセッサ・モードを表すＰＳＴＡＴＥ値といった、現在のプロセッサ状態についての情報を含むことができる。プロセッサ・モードは、どの命令セットが実行されたかといった他の情報だけでなく例外レベルも指定することができる。また、ＳＰＳＲレジスタは、以下で説明するレルム・エントリを制御するために使用されるレルム・エントリ・フラグＲを含むことができる。
・いったん例外が取り扱われるとＥＬＲは処理が分岐すべき復帰アドレスを提供できるように、例外が取り除かれたときの現在のプログラム・カウンタ値を記憶するために使用される例外リンク・レジスタＥＬＲ＿ＥＬ０。
・レルム・エントリが作成される子レルムのローカルＲＩＤを記憶するために使用されるレルム識別子レジスタＲＩＤ＿ＥＬ０（以下で説明するようにサブレルムを作成する機能に関して、たとえ例外レベルＥＬ０が、最も低く、特権が最低の例外レベルであっても、例外レベルＥＬ０で動作するプロセスから、依然としてレルムを入力することができる）。
・発生した例外についての情報を記憶するためにＥＬ０によって使用される例外状態レジスタ（ＥＳＲ）（たとえば、適切な例外ハンドラの選択を可能とするため）。
プロセッサ８が、例外レベルＥＬ１で動作するとき、例外レベルＥＬ０でアクセス可能な状態３５０のすべてを含む状態３５２のサブセットにアクセスするが、追加のアーキテクチャの状態を含むこともできる。たとえば、ＥＬ１において、こうしたレジスタのＥＬ０バージョンに対応した目標のために、ＥＬ１におけるプロセス動作によって使用されるＳＰＳＲ、ＥＬＲ、ＥＳＲ及びＲＩＤレジスタの横一列に並べたバージョンが存在する。ＳＰＳＲ＿ＥＬ１レジスタは、ＰＳＴＡＴＥ及びＲ値に加えて、以下で説明するようにネストされたレルム・エントリ中で使用され出ていく中間レルム・フラグ割り込みを含むこともできる。図２７は、中間レルム・フラグがＳＰＳＲ内で記憶されている場所の一実例を表すが、これは重要ではなく、他の実例ではフラグを異なるレジスタに記憶することができる。ＥＬ１ではアクセスできるがＥＬ０ではアクセスできない状態の別の実例は、ページ・テーブル・ウォーク中にＭＭＵによって使用されるステージ１のページ・テーブル１２０－１のベース・アドレスを示すアドレスを提供する、変換テーブル・ベースのレジスタＴＴＢＲ＿ＥＬ１であろう。
同じく、例外レベルＥＬ２で命令を実行するとき、処理要素８は、ＥＬ１でアクセス可能なすべての状態３５２を含む状態３５４のサブセットにアクセスするが、ＥＬ２及びステージ２の変換テーブル１２０－２のベース・アドレスを提供する仮想変換テーブル・ベースのレジスタＶＴＴＢＲ＿ＥＬ２のためのＳＰＳＲ、ＥＬＲ及びＲＩＤレジスタのさらに横一列に並べられたバージョンといった追加の状態も含む。
最後に、ＥＬ３で動作するとき、処理要素はＥＬ２でアクセス可能なサブセット３５４のすべてを含む状態３５６のサブセットにアクセスするが、レルムを入力するために例外レベルＥＬ３で動作するプロセスによって使用される、さらなるレルム識別子レジスタＲＩＤ＿ＥＬ３といった他の状態、及び、より低い例外レベルに使用される対応したレジスタに類似したさらなる例外取扱いレジスタＥＬＲ、ＳＰＳＲ、ＥＳＲも含むことができる。この場合も、図２７は単なる実例であり、他の状態も特定の例外レベルがアクセス可能な適切なサブセットに含むことができる。
したがって、各例外レベルは、ソフトウェア・プロセスをその例外レベルで処理するとき、処理回路がアクセス可能な対応するレジスタのグループと関連付けられている。最低の特権を有する例外レベル以外の所与の例外レベルに対して、所与の例外レベルでアクセス可能なレジスタのグループは、所与の例外レベルよりも低い特権を有する例外レベルでアクセス可能なレジスタのグループを含む。特定のレベルがアクセスできるこの状態の階層は、以下で説明するように、レルム・エントリ及び退出に関する状態の保存及び復元と関連付けられたオーバーヘッドを削減するために利用することができる。
レルムとの間のエントリと退出に関して、処理要素８及び／又はＲＭＵ２０は、レルム・エントリ又は退出の安全な取り扱いを保証するために、いくつかの動作を実行する必要がある。たとえば、レルム・エントリに際して、目標レルムが正しいライフサイクル状態にあることをチェックするために（たとえば、セキュリティ手段が、存在しないレルム又は所有されたページからのデータ消去を経ていないレルム入力を試みることによって回避されることを防止するために）、いくつかのチェックを実行する必要がある。また、レルムから出るに際して、より高い特権を有するレベルのプロセスが、より低い特権のレベルでレルムによって使用される状態データにアクセスできないように（本来であれば、レルム保護によって提供されるセキュリティ手段が回避されることが可能となる）、処理要素のレジスタに記憶されたアーキテクチャの状態をマスク化するのが望ましいであろう。レルム・エントリ及び退出を取り扱うための１つの手法は、ＲＭＵ２０をトリガしてレルムの入力又は退出のための適切な動作を実行させる専用のレルム・エントリ又は退出命令を提供することであろう。しかし、これには、新しい命令を使用するため、既存のソフトウェアをかなり変更する必要があろう。
以下で説明する技術において、レルム機構はレルムに入力し退出するために、例外エントリ及び戻しのためにすでに提供された仕組みを再利用する。これにより、レルム・エントリ及び退出をサポートするのに必要なソフトウェアを変更する量が削減され、アーキテクチャ及びハードウェアが単純になる。これは特に有用である。というのは、レルム境界はともかくも例外レベルの境界と一致することが多く、たとえ、新しい命令がエントリ及び退出を制御するために提供されたとしても例外を取り扱うための振る舞いはなお必要であろうし、そのため、例外機構を拡張してエントリ及び退出をさらに制御しても、全体的に費用は安くなるであろう。
したがって、現在のレルムで処理された例外から現在のレルム（ここでは、他のプロセスも同一の例外レベル、又はそれよりも低い特権を有する例外レベルで取り扱うことができる）で同様に処理された別のプロセスへ処理を通常戻す、例外リターン（ＥＲＥＴ）命令は、現在のレルムから宛先レルムへレルム・エントリをトリガするために再使用することができる。例外リターン命令の第１の変形体に応答して、処理回路は、現在の例外レベルからより低い特権を有する例外レベルへ（レルムを変更することなく）処理を切り替えることができ、一方、例外リターン命令の第２の変形体に応答して、処理回路は、現在のレルムから、現在のレルムと同じ例外レベル又はそれよりも低い（より低い特権を有する）例外レベルで動作することができる宛先レルムへ処理を切り替えることができる。例外リターン命令を使用してレルム・エントリをトリガすることにより、アーキテクチャ及びハードウェアのオーバーヘッドを大いに単純化し、レルムの使用をサポートするためのソフトウェア変更要求を削減することができる。
例外リターン命令を使用する別の利点は、典型的には例外から戻る際に、処理回路が例外リターン命令に応答して微細な１組の動作を実行することができることである。例外から戻る際に必要となる１組の動作は、これらの動作中ずっと途中で分割できないように微細に実行することが可能であり、そのため、命令が失敗し微細な１組の動作のどれもが実行されないか、命令が首尾よく実行され微細な１組の動作のすべてが実行されるかのどちらかである。例外リターン命令の第２の変形体に対して、処理回路は、第１の微細な１組の動作とは異なる第２の微細な１組の動作を同様に実行することができる。例外リターン命令が微細に完了するのを保証するために、プロセッサにすでに提供された機構は、レルム・エントリが部分的に実行されるだけの、セキュリティの脆弱性につながり得る状況を避けるために、レルム・エントリに再使用することができる。たとえば、第２の微細な動作の組は、レルム実行コンテキスト状態を利用可能とし、実行されている現在のレルムを変更し、前回同一のレルムが実行されたとき、処理が以前に実行されたプログラム・カウンタ・アドレスへの分岐を制御することを含むことができる。
例外リターン命令の第１及び第２の変形体は、同一の命令符号化を有してもよい。したがって、例外リターン命令それ自体の変更は、レルム・エントリをトリガするためには必要ではない。これにより、レガシー・コードとの互換性が向上する。所与の例外リターン命令が、第１の変形体又は第２の変形体に従って実行されるかどうかは、その命令が状態レジスタに記憶した制御値によって決まる（たとえば、制御値の第１及び第２の値は、それぞれ例外リターン命令の第１及び第２の変形体を表すことができる）。したがって、例外リターン命令が実行されるとき、現在のアーキテクチャの状態が、プロセッサを同じレルム内のより低い特権レベルに戻すか、それとも新しいレルムへエントリをトリガするか制御する。
この手法により、特に、状態レジスタの値が、レルム・スイッチは適当であることを示す一定のイベントに応答して、（ソフトウェア命令に応答して制御値を任意に設定できることに加えて）ハードウェアによって自動的にセットすることができるので、レルム・エントリをより少ないソフトウェア変更で制御できるようになる。たとえば、所与のレルムへの退出をトリガする例外状態が発生したとき、処理回路は制御値を所与のレルム用の第２の値にセットし、それにより、たとえ、例外を取り扱うための例外ハンドラ・コードがレルムを念頭に置いて書かれたものではない以前のレガシー・コードと全く同一だとしても、後続の例外リターン命令は自動的に処理を例外が発生したレルムに戻す。或いは、いくつかのアーキテクチャでは、レルムから退出するとき、状態レジスタの制御値は依然として、そのレルムにレルム・エントリをトリガする前にセットされた第２の値を含み、そのため、制御値を状態レジスタに明確にセットすることは必要ないということが期待できるであろう。
一実例において、状態レジスタの制御値は、上で説明したように現在の例外レベルと関連付けられたＳＰＳＲレジスタのＲフラグとしてよい。ＳＰＳＲレジスタは、プロセッサ・モード（例外レベルを含む）、及び、現在処理中の例外からの戻りに際して、処理はいかに継続するかに関する他の情報を提供するために、例外戻りに際して通常使用されるので、ＳＰＳＲを使用することは有益となるであろう。しかし、レルム・エントリのために、この情報はむしろレルム実行コンテキスト（ＲＥＣ）から決定することができ、そのためＳＰＳＲは必要ないであろう。例外リターン命令が、第１又は第２の変形体として取り扱かわれるかどうかを制御するＲフラグを記憶するために、ＳＰＳＲの一部を再利用することにより、この情報を記憶するために追加のレジスタを提供する必要は避けられる。したがって、ＥＲＥＴ命令の第１の変形体に応答して、より低い特権を有する例外レベルで例外を継続するために、（処理モードといった）戻し状態情報を決定するために使用される状態レジスタを使用することは有用であり得るが、例外リターン命令の第２の変形体に応答して、この戻し状態情報は代わりにメモリから決定されるので、状態レジスタそれ自体にアクセスする必要はない。特に、制御値を記憶するのに使用される状態レジスタは、例外リターン命令がそこから実行される現在の例外レベルと関連付けられた状態レジスタとすることができる。
図２７に表すように、少なくとも１つのレルム識別子レジスタが設けられ、例外リターン命令の第２の変形体に応答して、処理回路は、レルム識別子レジスタに記憶されたレルム識別子から宛先レルムを識別することができる。それぞれが例外レベルの１つと関連付けられた多くのレルム識別子レジスタが存在できるように、レルム識別子レジスタは横一列に並べることができ、例外リターン命令の第２の変形体に応答して、処理回路は、現在の例外レベルと関連付けられたレルム識別子レジスタに記憶されたレルム識別子から宛先レルムを識別することができる。レルム識別子レジスタを使用して目標レルム識別子を記憶することにより、これをＥＲＥＴ命令の命令符号化に含む必要はなく、これにより、既存のＥＲＥＴ命令のフォーマットを、レルム・エントリをトリガするために使用することができ、その結果、必要なソフトウェア変更の量が削減される。レルム識別子レジスタのレルム識別子は、親レルムによってその子レルムを参照するために使用されるローカル・レルム識別子とすることができ、そのため、レルム・エントリは親レルムから子レルムへの通過に限定することができ、第１のレルムから、第１のレルムの直接の子ではない別のレルムへ行くことは可能ではない。例外リターン命令の第２の変形体に応答して、処理回路は、ＲＩＤレジスタで識別されたレルムＩＤと関連付けられたレルムが無効なレルム（それに対してレルム記述子が定義されていない、又はレルム記述子がアクティブ以外のライフサイクル状態を定義しているＲＩＤ）であるとき、障害状態をトリガすることができる。
例外リターン命令の第２の変形体に応答して、処理回路は、例外リターン命令のために指定されたレルム実行コンテキスト（ＲＥＣ：Ｒｅａｌｍ Ｅｘｅｃｕｔｉｏｎ Ｃｏｎｔｅｘｔ）メモリ領域から、宛先レルムで処理されるスレッドと関連付けられたアーキテクチャの状態を記憶することができる。状態復元は、例外リターン命令の第２の変形体に応答して、直ちに実行することができ（たとえば、微細な１組の動作の一部として）、又は、後に実行することもできる。たとえば、状態復元はゆっくりとした方法で実行することができ、その結果、宛先レルムで処理を開始するために必要な状態は直ちに復元することができるが（たとえば、プログラム・カウンタ、処理モード情報など）、汎用レジスタなど他の状態は、後に必要なとき、又は新しいレルムの進行中の処理のバックグラウンドで徐々に復元することができる。したがって、処理回路は、すべての必要なアーキテクチャの状態がＲＥＣメモリ領域から復元される前に、宛先レルムの処理を開始することができる。
例外リターン命令の第１の変形体に応答して、処理回路は、リンク・レジスタに記憶されたプログラム命令アドレスへ分岐することができる。たとえば、これは、例外リターン命令が実行される現在の例外レベルに対応する図２７のＥＬＲとすることができる。対照的に、例外リターン命令の第２の変形体に対して、処理回路は、レルム実行コンテキスト（ＲＥＣ）メモリ領域で指定されるプログラム命令アドレスへ分岐することができる。したがって、リンク・レジスタは、例外リターン命令の第２の変形体が、新しいレルムに対して任意のアーキテクチャの状態を直接識別するためには使用されないので、リンク・レジスタは、代わりにポインタを、そこから新しいレルムのアーキテクチャの状態が復元されるＲＥＣメモリ領域へ提供するために再使用することができる。これにより、ＲＥＣポインタを復元するためにさらなるレジスタを提供する必要が避けられる。
したがって、所与のレルムにレルム・エントリを引き起こさせることを意図した例外リターン命令を実行する前に、ＲＩＤレジスタを宛先レルムのレルム識別子にセットし、宛先レルムと関連付けられたＲＥＣメモリ領域のポインタを記憶するためのリンク・レジスタをセットするために、いくつかの追加の命令を含むことができる。ＲＥＣポインタは、宛先レルムのレルム記述子から親レルムによって入手可能である。
例外リターン命令の第２の変形体に応答して、ＲＥＣメモリ領域が宛先レルム以外の所有者レルムと関連付けられるか、例外リターン命令に対して指定されたＲＥＣメモリ領域が無効なとき、障害状態を処理回路によってトリガすることができる。第１のチェックは、親レルムが子レルムを欺いて子レルム自体が作成したものではないプロセッサ状態を実行させることを防止する。というのは、子レルムによって所有されたメモリ領域のみが、そのレルムを入力する際にアクセス可能なＲＥＣメモリ領域を記憶することができるからである（上で説明したように、ＲＥＣメモリ領域はＲＭＵプライベートとしてセットされる）。ＲＥＣメモリ領域の有効性の第２のチェックは、ＲＥＣメモリ領域はレルムを入力するために一度だけ使用することができ、その後、同一のＲＥＣデータでレルムを入力しようとする後続の試みは拒否されるであろうということを保証するのに有用であろう。たとえば、各ＲＥＣは、無効か有効であるライフサイクル状態を有しているであろう。現在のレルムで所与のスレッドの処理中に発生する例外に応答して、そのスレッドのアーキテクチャの状態は対応するＲＥＣメモリ領域に保存され、その対応するＲＥＣメモリ領域は、次いで無効から有効へ移行することができる。例外リターン命令の第２の変形体を首尾よく実行したことに応答して、ＲＥＣメモリ領域は次いで有効から無効へ逆に移行することができる。これにより、親レルムが悪意を持って子レルムに、期限切れのＲＥＣメモリ領域のポインタ、異なるスレッドと関連付けられたＲＥＣメモリ領域、又は宛先レルムと関連付けられてはいるが、レルムからの前回の退出時にアーキテクチャの状態を記憶するために使用された正しいものではないいくつかの他のＲＥＣを指定することにより、不正に振る舞わせることが避けられる。
対応する方法において、レルムからの退出は、例外取扱いのために提供された機構を再使用することができる。したがって、第１のレルムによって取り扱うことができない第１のレルムの処理中に発生した例外状態に応答して、処理回路は、第１のレルムを初期化した親レルムへレルム退出をトリガすることができる。例外発生／レルム退出に際して、同一のレルム内で取り扱いが可能な例外発生に対しては実行できないいくつかの追加的な動作を実行することができる。たとえば、これにはアーキテクチャの状態のマスク化又は消去、及び、以下でより詳細に説明するように、ＲＥＣに対して状態ストレージをトリガすることが含まれる。
しかし、いくつかのケースにおいて、例外が発生する第１のレルムの親レルムによって取り扱うことができない例外が発生する場合がある。したがって、この場合には、親を超えてさらなる先祖レルムへ切り替えることが必要となろう。所与のレルムから２世代以上古い先祖レルムへ直接切り替える機能を提供することは可能かもしれないが、これにより、例外エントリ及び戻し又はレルム退出及びエントリを取り扱うために必要な状態レジスタの複雑性が増大するであろう。
むしろ、第１のレルムの親レルムが処理できる最も高い特権を有する例外レベルというよりは、より高い特権レベルを有する目標例外レベルで例外状態が処理されるとき、ネストされたレルム退出を実行することができる。ネストされたレルム退出には、発生した例外の目標例外レベルで処理することができる第２のレルムに到達するまで、子レルムから親レルムへの２つ以上の連続したレルム退出が含まれる。したがって、一度に一段階ずつレルム階層を上げることにより、アーキテクチャを単純化することができる。それぞれの連続するレルム退出において、プロセッサ状態のサブセットを対応するレルムと関連付けられたＲＥＣに保存するように実行する動作が存在する場合がある。
例外が取り扱われると、次に、ネストされたレルム退出に続く第２のレルムにおいて実行される第２の変形体の例外リターン命令に応答して、処理回路は、次いで、ネストされたレルム・エントリをトリガして第１のレルムに戻させる。これは様々な方法で取り扱うことができる。いくつかの実例において、ハードウェアは、何等の命令を必要とすることなくネストされたレルム・エントリそれ自体をトリガして、ネストされたレルム退出中に第１のレルムと第２のレルムの間で遭遇した任意の中間レルムで実行する。或いは、ハードウェアは、ネストされたレルム退出中に遭遇した連続したそれぞれのレルムに戻るネストされたレルム・エントリ・プロセスを、一度に一段階ずつ提供することにより単純化することができ、それぞれの中間レルムにおいて第２の変形体のさらなるＥＲＥＴ命令を実行する。この場合、中間レルムが、ネストされたレルム退出中に、そこから中間レルムへのレルム退出がなされる中間レルムの子レルムへの戻りをトリガすることを保証するために、所定のタイプの例外状態が子レルムで発生したことを示す例外状態レジスタをセットすることができる。たとえば、新しいタイプの例外状態（たとえば、「偽のレルム退出」）をこの中間レルムのケースを取り扱うために定義することができる。したがって、プロセッサは、中間レルムに到達すると、次に、所定のタイプの例外状態を取り扱うための例外取り扱いルーチンに対応するプログラム命令アドレスから、中間レルム内で処理を再開することができる。この例外取り扱いルーチンは、たとえば、子レルムがある未知の理由で退出したと単純に判定することができ、次に、処理をさらなる子レルムへ戻すために、第２の変形体の別の例外リターン命令を実行するために選択することができる。各中間レルムでこれを実行することにより、最終的には、元の例外が発生した元の第１のレルムは処理を再開することができる。
このネストされたレルム・エントリ及び退出手順中に、状態レジスタ内の中間レルム・フラグは、どちらのレルムが中間レルムであるかフラグを立て、適切な子レルムに対してハードウェアによって引き起こされる中間レルム・エントリをトリガするか、又は、子レルムに戻すために、次に例外ハンドラ若しくは中間レルム内の他のコードをトリガする例外状態情報の設定をトリガするために使用することができる。たとえば、中間レルム・フラグは、図２７で説明した適切なＳＰＳＲ内の割り込みフラグとすることができる。
図２８は、レルム・エントリ又は例外戻しを取り扱う方法を示す流れ図である。ステップ４００において、現在の例外レベルがＥＬｘのとき、例外リターン（ＥＲＥＴ：Ｅｘｃｅｐｔｉｏｎ Ｒｅｔｕｒｎ）命令が実行される。ＥＬｘは、処理回路によってサポートされる任意の例外レベルとすることができる。最低の特権を有する例外レベルＥＬ０からは例外戻しが発生するとは期待しないかもしれないが、サブレルムを作成する機能は、以下で説明するように、同じくＥＬ０で実行されたサブレルムへ入力をトリガするために、ＥＬ０から実行されるＥＲＥＴ命令が依然として存在し得るということを意味する。また、いくつかのタイプの例外は、例外が発生するレベルと同じ例外レベルで取り扱うことができ、この場合、例外戻しは依然としてＥＬ０から発生する。
ステップ４０２において、処理要素は、例外レベルＥＬｘと関連付けられたＳＰＳＲ内のレルム・フラグＲの現在値を判定する。レルム・フラグＲが０のとき、これは異なるレルムを入力することのない従来の例外戻しを示す。ステップ４０４において、処理要素８は、ＳＰＳＲ＿ＥＬｘ内のＰＳＴＡＴＥ値に基づいて、後続の例外戻しを動作させる目標例外レベルを決定し、リンク・レジスタＥＬＲ＿ＥＬｘを形成するために分岐するためのプログラム・カウンタ値を決定する。新しい目標例外レベル及びプログラム・カウンタ値及び例外に続く処理への戻しと関連付けられた任意の他の戻し状態は、目標例外レベル（これは例外レベルＥＬｘよりも低い特権を有するより低い例外レベルであることが多いが、同じ例外レベルＥＬｘでもあり得る）と関連付けられた適切なアーキテクチャの状態レジスタへ復元される。こうした戻り状態動作は微細に行われる。次いで、ステップ４０６において、処理は目標例外レベルで再開するが、ＥＲＥＴ命令が実行されたレルムと同じレルム内に留まる。
ステップ４０２において、レルム・フラグＲが１にセットされると、これはレルム・エントリを示し、そのため、これは従来の例外戻しのために実行されるセットとは異なる１組の第２の微細な動作をトリガする。ステップ４０８において、処理要素は、レルム管理ユニットをトリガしていくつかのレルム・チェックを行う。これには以下のチェックが含まれる。
・例外レベルＥＬｘと関連付けられたレルム識別子レジスタＲＩＤ＿ＥＬｘ内で示されたローカルＲＩＤは有効な子レルムを示す。すなわち、ＲＭＵは、指定された子レルムのためにレルム記述子ツリー３６０からアクセスされるレルム記述子をチェックし、子レルムのレルム記述子のライフサイクル状態がアクティブ状態を示しているかどうかチェックする。子レルムがアクティブ状態以外の任意の状態であれば、レルム・チェックは不成功である。
・ＲＭＵ２０はまた、リンク・レジスタＥＬＲ＿ＥＬｘのポインタによって示されるＲＥＣメモリ領域は、レルムＩＤレジスタＲＩＤ＿ＥＬｘで示される子レルムによって所有されるメモリ領域であるということをチェックする。すなわち、ＲＭＵ２０は、レルム・グラニュール・テーブル１２８（又はＲＧＴ１２８からキャッシュ化された情報）にアクセスし、ＲＥＣポインタで示されたメモリ領域に対応する適切なエントリを捜し出し、そのメモリ領域に対して指定された所有者レルムをチェックする。所有権テーブル内で示された所有者レルムは、グローバルＲＩＤとして指定することができ、これは、目標子レルムのレルム記述子で指定されたグローバルＲＩＤと比較されて、子レルムがＲＥＣの有効な所有者かどうか判定される。ＲＥＣが、ＲＩＤレジスタで指定された子レルム以外の任意のレルムによって所有されている場合、このチェックは不成功である。
・ＲＭＵ２０はまた、ＥＬＲ＿ＥＬｘで定義されたＲＥＣメモリ領域の状態が有効かどうかチェックする。ＲＥＣメモリ領域の有効性を表すことができる様々な方法がある。たとえば、各ＲＥＣメモリ領域は、それが有効かどうかを述べるフラグを含むことができる。或いは、別々のテーブルは、他のメモリ領域に記憶されたＲＥＣの有効性を定義することができる。ＲＥＣは、それが前の例外戻しに際して関連したレルムのアーキテクチャの状態を記憶するために使用されてきたが、例外からの戻しに続いて状態を復元するためにまだ使用されていない場合、有効とすることができる。ＲＥＣが無効な場合、やはりレルム・チェックは不成功である。
・ＲＭＵ２０はまた、フラッシュ・コマンドが、ＲＩＤレジスタＲＩＤ＿ＥＬｘで示された子レルム以外の任意の子レルムから、前回の退出以降に実行されたかどうかチェックする。フラッシュ・コマンドは以下でより詳細に説明するが、子レルムのＲＥＣに依然として保存される任意の状態はメモリにプッシュされるということを保証するためのコマンドである（これは、ゆっくりとした状態の保存手法をサポートする）。フラッシュ・コマンドが実行されず、システムが、異なる子レルムを以前に退出された子レルムに入力しようとする場合、まだメモリにプッシュされていないプロセッサ・レジスタ内に残された状態がなお存在し得るという危険性がある。フラッシュ・コマンドの使用を強要することにより、異なる子レルムは、以前の子レルムの状態を失う（又は他のレルムへ漏洩する）ことなく安全に入力できることが保証される。たとえば、いくつかの状態フラグを使用して、（ａ）前回のレルム退出以降にＲＩＤレジスタＲＩＤ＿ＥＬｘに変更があったかどうか、及び（ｂ）前回のレルム退出以降にフラッシュ・コマンドが実行されたかどうかを追跡することができる。前回のレルム退出以降にＲＩＤレジスタの変更が存在し、フラッシュ・コマンドが実行されなかった場合、レルム・チェックが不成功となるであろう。
任意のレルム・チェックが不成功な場合、ステップ４０９において障害がトリガされ、システムは、ＥＲＥＴ命令と関連付けられた現在のレルム内に留まる。したがって、すべてのレルム・チェックが成功しない限り子レルムに到着するのは不可能である。
すべてのレルム・チェックが成功した場合、ステップ４１０において処理要素は、レルムＩＤレジスタＲＩＤ＿ＥＬｘで示された子レルム内の処理に切り替える。たとえば、プロセッサは、現在のレルムのグローバルＲＩＤを指定する内部レジスタを有することができる（この内部レジスタはソフトウェアには見えなくともよく、図２７で表された横一列に並べられたＲＩＤとは異なる）。子レルムへの切り替えは、新しい宛先レルムのグローバルＲＩＤを内部ＲＩＤレジスタに書き込むことによって実施される。
ステップ４１２において、新しいレルムと関連付けられた状態は、ＥＬＲ＿ＥＬｘレジスタのポインタによって示されたＲＥＣメモリ領域のメモリに保存された状態に基づいて使用可能になる。ＲＥＣ領域は新しい子レルムによって所有されているので、それは今やアクセス可能であり、そのため、プログラム・カウンタ及び目標例外レベルといった戻し状態情報はＲＥＣから入手することができる。この点において、アーキテクチャの状態の選択されたサブセットは、ＲＥＣから復元することができ、又は、代替として、アーキテクチャの状態は、処理がすべての状態が完全に復元されなくても開始できるようにゆっくりと復元することができ、その結果、処理が新しいレルムから開始することができる前に遅延を削減することにより効率を向上させるために、状態は、必要に応じて、及び必要なとき、又はある期間にわたって徐々に復元することができる。
ステップ４１４において、中間レルム・フラグ割り込みが、新しいレルムと関連付けられたＳＰＳＲにセットされているかどうか判定される。ＳＰＳＲコンテンツは、ＲＥＣからアーキテクチャの状態の残りと共に復元されるであろう。中間レルム・フラグがセットされていない場合、これは、新しいレルムは元の例外が発生したレルムであることを示し（又は、レルムは、いかなる前の例外がそのレルムで発生したことなしに、初めて入力されている）、そのため、任意のさらなるレルム・エントリを子レルムへトリガする必要はない。ステップ４１６において、プログラム・カウンタがＲＥＣから入手され、次いで、ステップ４１８において、処理はＲＥＣから入手された目標例外レベルで、新しいレルムにおいて継続する。
或いは、中間レルム・フラグがセットされている場合、これは、ネストされたレルム退出が以前に発生し、ネストされたレルム・エントリが中間レルムに到達したことを示す。したがって、例外が最初に発生したレルムに戻るために、処理をさらなる子レルムへ戻す必要がある。これを取り扱うための２つの代替技術がある。第１の代替において、ステップ４２０において偽のレルム退出例外が除去され、そのため、新しいレルムと関連付けられた例外状態レジスタは、処理要素によりこのタイプの例外と関連付けられた状態コードへセットされ、次いで、処理は、例外ハンドラをトリガして処理させるこのタイプの例外と関連付けられた例外ベクトルへ分岐することができる。例外ハンドラはいかなる実際の処理を実行する必要はなく、所与の子レルムで発生した未知のタイプの例外を判定することができるだけであり、そのため、次にステップ４２２において別のＥＲＥＴ命令をトリガして実行することができる。中間レルムと関連付けられたＲＩＤ及びＥＬＲレジスタは、中間レルムが以前にさらなる子レルムを入力したとき、レジスタに配置された値を依然として有し、そのため、ＥＲＥＴ命令の実行により、次に、さらなるレルム・エントリをさらなる子レルムにトリガする。この方法は、そのさらなるレルム・エントリに対してレルム・チェックが成功したかどうかチェックするために、ステップ４０８に戻ることができ、次いで、類似の方法でネストされたプロセスに以前のレルム・エントリを継続する。
或いは、中間レルムで実行された別のＥＲＥＴ命令を使用して、ネストされたレルム・エントリを取り扱う代わりに、ステップ４２４において、ハードウェアは、中間レルム・フラグが現在のレルムにセットされていることを検出し、次に、中間レルム内の任意の命令を実行する必要なしに、さらなるレルム・エントリを子レルムにトリガすることができる。次いで、この方法は次にステップ４０８に戻ることができる。
図２９は、レルムから退出する又は例外を除去する方法を示すフロー図を表す。ステップ４３０において、例外レベルＥＬｙを目標とする所与の例外レベルＥＬｘ内で例外が発生する（ＥＬｙ≧ＥＬｘ）。目標例外レベルＥＬｙは、例外が取り扱われることとなる例外レベルである。目標例外レベルは、ＥＬｘと同じ、ＥＬｘよりも一例外レベルだけ高い、又は数例外レベル高いとすることができる。
ステップ４３２において、ＲＭＵは、目標例外レベルＥＬｙは現在のレルムの境界例外レベル（ＢＥＬ）（これは現在のレルムのレルム記述子から読み取ることができる）よりも大きいかどうか、及び、現在のレルムはサブレルムかどうかを判定する（以下のサブレルムの議論を参照されたい。図１６に表したレルム記述子のタイプ・フィールドはレルムがサブレルムかどうか指定する）。目標例外レベルＥＬｙが境界例外レベルよりも大きくない場合、これは、例外は現在のレルム内で取り扱うことができ、したがって、現在のレルムが完全なレルムの場合、レルム退出をトリガする必要はないことを示す。このケースでは、ステップ４３４において、処理要素は現在の例外レベルをＥＬｙに切り替える（たとえば、現在の状態レジスタを更新することにより）、又は、ＥＬｘ＝ＥＬｙならば、現在の例外レベルはそのままである（どちらにしても、このときの現在の例外レベルはＥＬｙである）。ステップ４３６において、例外レベルＥＬｘと関連付けられた現在の処理状態は、目標例外レベルＥＬｙがアクセス可能なレジスタに保存される。たとえば、プログラム・カウンタは、リンク・レジスタＥＬＲ＿ＥＬｙに保存することができ、例外が発生した以前の例外レベルＥＬｘは、ＳＰＳＲ＿ＥＬｙのＰＳＴＡＴＥ値で示すことができる。また、ＳＰＳＲ＿ＥＬｙレジスタのレルム・フラグＲは、例外が同じレルム内から来たことを示すために０にセットすることができる。発生した例外タイプについての情報も、例外状態レジスタＥＳＲ＿ＥＬｙに保存することができる。ステップ４３８において、処理要素は、指定された例外タイプと関連付けられた例外ベクトルへ分岐し、次いで、処理は例外を取り扱うために続行する。最終的に、例外取扱いが完了すると、ＥＲＥＴ命令が実行されて図２８について上で説明したように、以前の処理への戻しがトリガされる。
他方、ステップ４３２において、目標例外レベルＥＬｙが現在のレルムのＢＥＬよりも大きかった場合、又は、現在のレルムがサブレルム（それに対して任意の例外がサブレルムの親レルムへの退出をトリガする）の場合、例外を取り扱うためにレルム退出が必要になる。ステップ４４０において、例外が自発的なレルム退出に対応するかどうか判定する。いくつかのタイプの例外は、ユーザが処理デバイスのボタンを押下する、又は何らかの障害が発生するといった予期せぬイベントによって、トリガされる場合がある。しかし、レルムが自発的に処理を断念し、親レルムに戻ることも可能である。たとえば、子レルムがある処理ルーチンの端部に到達したかもしれない、又は、より高い例外レベルである機能を呼び出す必要があるかもしれない。子レルムが親レルムに自発的に退出し、次いで、子レルムが親レルムとデータを共有できるようにするために、子レルムのいくつかのアーキテクチャの状態が、親レルムからのアクセスのために保持されており、その結果、意図しないレルム退出に比較してマスク化及び消去されるレルムがより少なくなることは有用であろう。たとえば、他の制御レジスタはなおマスク化及び消去が可能であるが、汎用レジスタはマスク化及び消去されなくともよい。これにより、状態がレジスタから直接アクセスできるようにデータをグローバルに可視性できるメモリ領域に記憶する必要が避けられ、効率性が向上する。すなわち、自発的なレルム退出の場合、子レルムはレルム退出を制御しており、そのため、子レルムは親レルムにとってアクセス可能とするべきではない可視性可能なアーキテクチャの状態をすでに上書きしており、親レルムと共有したい任意の状態をレジスタに残すと考えることができる。自発的なレルム退出は、たとえば、マスク化又は消去が実行されない特定のタイプの例外に対応する、例外をトリガする命令の所定の変形体によってトリガすることができる。
レルム退出が自発的なレルム退出ではない場合、ステップ４４２において、アーキテクチャの状態の選択されたサブセットをマスク化することが実行される。マスク化により、隠されるべきアーキテクチャの状態は親レルムにとってアクセスできないようにすることを保証する。しかし、親レルムは依然として、そのアーキテクチャの状態を記憶するレジスタへのアクセスを試みるかもしれず、そのため、消去されたアーキテクチャ・レジスタへのいかなる後続のアクセスは、そのアーキテクチャ・レジスタと関連付けられた物理レジスタにどのような値が実際に記憶されるかにかかわらず、所定の値を戻すことを保証する、消去動作も実行することができる。すなわち、アーキテクチャの状態のマスク化されたサブセットの一部を記憶した所与のアーキテクチャ・レジスタに対して、レジスタ消去動作が実行されると、これは、所与のアーキテクチャ・レジスタに対する後続の読み取りアクセスは、それが処理回路により、レルム切り替えと後続の読み取りアクセスとの間で、そのアーキテクチャ・レジスタへの間に挟まれたいかなる書き込みアクセスなしに実行される場合、所定の値（たとえば０）を戻すことを保証する。レジスタ消去動作は様々な方法で実行することができる。たとえば、所与のアーキテクチャ・レジスタに対応する物理レジスタは、所定の値にセットすることができる（たとえば、０の値を物理レジスタに書き込みすることができる）。或いは、所与のアーキテクチャ・レジスタが第１の物理レジスタから第２の物理レジスタへ再マッピングされるように、レジスタ・リネーミングによりレジスタ消去を実行することができる。別の手法は、所与のアーキテクチャ・レジスタへの読み取りアクセスは、所定の値を戻すべきであるということを示すために、所与のアーキテクチャ・レジスタ又は所与のアーキテクチャ・レジスタにマッピングされた物理レジスタと関連付けられた状態値をセットすることである。これら最後の２つの手法を使用して、処理要素の物理レジスタ・ファイル内に、新しいレルムからアクセスできないにしてもマスク化されたアーキテクチャの状態を保持することは可能であり、その状態に対するいかなるアクセスも所定の値を戻すことになる。これは、以下で説明するように、ゆっくりとした状態の保存をサポートするのに有用である。いったん、マスク化及び消去動作が実行されると、ステップ４４４において、処理要素は、例外が発生した現在のレルムと関連付けられたＲＥＣメモリ領域に、アーキテクチャの状態のマスク化されたサブセットの保存をトリガする。この保存は直ちに、又は親レルムにおける後続の処理と重なり合ってゆっくりと行うことができる。どちらの手法が取られるかは、アーキテクチャの個々の実装形態次第であり、したがって、アーキテクチャの重要な特徴ではない。しかし、ゆっくりした状態保存は効率を向上させることができる。
レルム退出が自発的なレルム退出であった場合、非自発的なレルム退出に対してマスク化／消去される少なくともいくつかの状態は、自発的なレルム退出に対してマスク化／消去される必要がないことを除いて、ステップ４４３において、アーキテクチャの状態の縮小されたサブセットが、ステップ４４２におけるのと同じ方法でマスク化され、消去される。たとえば、アーキテクチャの状態の縮小されたサブセットは、汎用レジスタを除外することができる。ステップ４４３に続いて、上で説明したように、この方法は非自発的なレルム退出のためのステップ４４４へ継続する。
レルム退出が自発的か非自発的かにかかわらず、ステップ４４６において、処理要素は親レルムへ切り替える。子レルムの例外レベルと関連付けられ、親レルムの例外レベルによって制御されるＲＩＤ＿ＥＬｘレジスタ及びＥＬＲ＿ＥＬｘレジスタは、以前に退出した子レルムのＲＩＤポインタ及びＲＥＣポインタに依然としてセットされているので（というのは、これらは、最初の段階で子レルムを入力するためにＥＲＥＴ命令が実行される前にセットされたであろうため）、この状態に適合させる必要はなく、その結果、任意の後続のＥＲＥＴ命令は前の通り同じ子レルムへ戻るであろう。親レルムが前回退出した子レルムから異なる子レルムへ切り替えることを望む場合、こうしたレジスタを更新する必要があるだけである。同様に、親レルムのＳＰＳＲ内のレルム・フラグＲは、以前のレルム・エントリに続いて１にセットすることができ、それによりこの値を保持することができ、その結果、Ｒフラグが親レルムで実行される命令によって０にクリヤされない限り、ＥＲＥＴ命令は引き続き新しいレルムへのエントリとして扱われることになろう。
ステップ４４８において、ＲＭＵは、目標例外レベルＥＬｙが、処理が切り替えられる先の新しい親レルムのＢＥＬよりも大きいかどうか判定する。大きくない場合は、これは、例外は親レルムに取り込むことができることを示し、ステップ４５０において、処理要素８は、発生した例外のタイプを取り扱うのに適切な対応する例外ハンドラへ分岐する。目標例外レベルが親レルムのＢＥＬよりも高い場合、さらなる先祖レルムへ分岐するためにネストされたレルム退出が必要とされ、そのため、ステップ４５２において、親レルムと関連付けられた中間レルム・フラグがＳＰＳＲ内で１にセットされ、次いで、この方法はステップ４４２に戻り、そのレルムと関連付けられたアーキテクチャの状態のマスク化及び消去をトリガする（今回は、レルム退出は親レルムの制御外でトリガされたので自発的なレルム退出ではない）。次いで、この方法は、再度ループして現在のレルムと関連付けられた任意の適切な状態をマスク化又は消去し、次に、そのレルムの親レルムへ切り替える。ネストされたレルム退出は、最終的には例外を取り扱うことができるレルムに到達するまで、数回ループすることができる。
ステップ４１２，４４２，４４４において、レルムからの退出時にマスク化され、消去され、及び保存され、並びに、レルムへのエントリ時に復元されるアーキテクチャの状態のサブセットは、退出され／入力されたレルムの境界例外レベルによって決まることができる。ネストされないレルム退出及びエントリの場合、選択されたサブセットは、たとえば図２７で示すように、例外が発生した例外レベルがアクセス可能なアーキテクチャの状態のサブセットを含むことができる。したがって、各例外レベルは一群のレジスタと関連付けられており、所与のレルムの境界例外レベルよりもより特権を有する例外レベルにおいて、例外ハンドラによって取り扱われることになる所与のレルムの処理中に発生するレルム退出例外状態に応答して、レジスタのサブセットは、所与のレルムの境界例外レベルに応じて選択することができ、その例外レベルでソフトウェア・プロセスを処理するとき処理回路がアクセス可能なレジスタを含むことができる。例外がＥＬ１又はこれよりも高い例外レベルで発生すると、これは、ネストされないレルム退出のための任意のより低い例外レベルだけでなく、その例外レベルがアクセス可能なすべてのレジスタを含むことができる。同様に、レルムに戻ると、アーキテクチャの状態の対応するサブセットが復元される。
しかし、ネストされたレルム退出の場合、中間レルムに対して、中間レルムの境界例外レベルよりも低い例外レベルでアクセス可能な任意のレジスタは、中間レルムが子レルムへの入力をトリガしたので、より低い例外レベルで子レルムによって変更されたであろうと考えることができる。したがって、ネストされたレルム退出中に、中間レルムと関連付けられたＲＥＣへより低い例外レベルでアクセス可能なこうしたレジスタを、保存する必要はないであろう（以前に子レルムを入力して以降、中間レルムにおいてさらなる実行は発生していない）。逆に、ネストされたレルム・エントリ中に、中間レルムの通過中により低いレベルでアクセス可能なこうしたレジスタを復元する必要はない、というのは、こうしたレジスタはその後、より低い例外レベルでレルムによって復元されるからである。代わりに、中間レルム状態保存及び復元は、中間レルムの境界例外レベルがアクセス可能なレジスタを単純に含むことができるが、より低い例外レベルではアクセスできない。たとえば、中間レルムがＥＬ１にある場合、ネストされたレルム退出／エントリ中に保存／復元された状態は、図２７のサブセット３５２を含むことができるが、ＥＬ０でアクセス可能なサブセット３５０を除外することができる。中間レルムがＥＬ２にある場合、ネストされたレルム退出／エントリ中の状態の保存／復元されたサブセットは、ＥＬ２でアクセス可能なサブセット３５４を含むことができるが、ＥＬ１でアクセス可能なサブセット３５２を除外する。この手法により、中間レルムを通過する際に必要とされる状態保存及び復元の量が削減されて、効率を向上させることができる。
したがって、例外状態が、例外が発生する所与のレルムの親レルムの境界例外レベルよりもより大きな特権を有する目標例外レベルで、例外ハンドラによって処理されるとき、目標例外レベル又はそれよりも高いレベルに対応する境界例外レベルを有する目標レルムに到達するまで、子レルムから親レルムへ多数の連続的なレルム退出を含むネストされたレルム退出をトリガすることができる。それぞれの状態マスク化プロセス（及び状態保存）は、連続するレルム退出のそれぞれに対してトリガすることができ、それぞれの状態マスク化プロセスのおのおのは、境界例外レベルに基づいて選択された対応するレジスタのサブセットをマスク化（及び保存）することができる。最低の特権を有する例外レベル以外の境界例外レベルを有する所与の子レルムからのレルム退出に対して、ネストされたレルム退出中にマスク化／保存されたレジスタの対応したサブセットは、所与の子レルムの境界例外レベルにおいて、アクセス可能な少なくとも１つのレジスタを含むことができる、しかし、所与の子レルムの境界例外レベルよりも低い特権を有する例外レベルにおいて、処理回路がアクセス可能な少なくとも１つのレジスタを除外することができる（こうしたレジスタは、そのより低い特権を有する例外レベルでレルムを退出するとき、すでに保存されているであろうと考えることができるので）。これにより、必要な状態マスク化及び保存動作の量が削減される。
同様に、レルム・エントリ（例外戻し）に際して、中間レルム・フラグを使用して、入力されたレルムが中間レルムかどうか判定する。最低の特権を有する例外レベル以外の境界例外レベルを有するレルムのための中間レルム状態値が、所定の値（中間レルムを表す）にセットされると、レルム・エントリに際して復元されるレジスタのサブセットは、中間レルムの境界例外レベルにおいてアクセス可能な少なくとも１つのレジスタを含むことができるが、特定のレルムの境界例外レベルよりも低い特権を有する例外レベルにおいて、処理回路がアクセス可能な少なくとも１つのレジスタを除外することができる。中間状態値が所定の値以外の値にセットされると、入力されているこのレルムは最後のレルムであり、そのため、アクセスされた復元されるレジスタのサブセットは、特定のレルムの境界例外レベルにおいて処理回路がアクセス可能なすべてのレジスタを含むことができる（より低いレベルからのいかなるレジスタを除外することなく）。
このようにして、ネストされたレルム退出及びエントリ中に、状態保存及び復元動作をより効率的に行うことができる。
図３０は、ネストされないレルム・エントリ及び退出の一実例を示す。この実例において、親レルムＡは例外レベルＥＬ１における動作であり、それはＥＬ０のＢＥＬを有する子レルムＢを入力することを望んでいる。明らかに、類似のレルム・エントリ及び退出手順は他の例外レベルで実行することができる。ステップ４６０において、親レルムは、レルム識別子レジスタＲＩＤ＿ＥＬ１を子レルムＢのローカル・レルムＩＤにセットする。ローカルＲＩＤは、上で説明したように、ツリー索引を連結することにより得られるフォーマットを有する。ステップ４６２において、ＥＬ１の親レルムは、リンク・レジスタＥＬＲ＿ＥＬ１を、ポインタをレルムＢのレルム実行コンテキストに提供するアドレスにセットする。親レルムは、このポインタを所望の子レルムＢのレルム記述子から入手する。ステップ４６４において、親レルムは、ＳＰＳＲ＿ＥＬ１のレルム・フラグを１にセットする。ステップ４６６において、親レルムは、次に、ＥＲＥＴ命令を実行し、これは、レルム・フラグが１にセットされているので、レルム・エントリをトリガすると解釈される。図２８のステップ４０８において上で説明した様々なレルム・チェックが実行され、チェックが成功した場合、レルム・エントリが実行されレルムＢに切り替える。ステップ４６８において、リンク・レジスタで示されたＲＥＣから状態が復元される。この状態は、新しいレルムが実行されることになる目標例外レベルを含む。ＲＥＣがアクセスされる時点において、プロセッサは、レルムＡと関連付けられた以前の例外レベルに依然として存在し、そのため、これが原因で、たとえレルムＢへの切り替えがなされ、最終的に、そのレルムがＥＬ０から処理を開始するとしても、リンク・レジスタＥＬＲ＿ＥＬ１がＲＥＣポインタを入手するために依然としてアクセス可能である。状態復元は直ちに行うことができ、又は、レルムＢの通常処理４７０を使用して、一定の期間にわたって並行してゆっくりと行うことができる。
子レルムＢの実行中に、ステップ４７２で例外が発生すると、レルムＢと関連付けられた状態をその親レルムから隠すために１組のマスク化動作が実行される。これには、ステップ４７４でＥＬ０と関連付けられたアーキテクチャの状態の少なくとも１つのサブセットをマスク化し消去することが含まれる（マスク化／消去されるアーキテクチャの状態のサブセットは、退出が自発的又は非自発的なレルム退出かどうかによって決まる）。マスク化により、状態はアクセス不能となり、消去により、親レルムから対応するレジスタへの後続のアクセスが、戻されるべき所定の値をトリガすることを保証する。ステップ４７６において、レルムＢと関連付けられたＲＥＣへの状態保存が、アーキテクチャの状態のマスク化されたサブセットに対して実行される。この場合、子レルムはＥＬ０のＢＥＬを有しているので、状態のマスク化されたサブセットは、ＥＬ０でアクセス可能な少なくともサブセット３５０を含む。この場合も、状態保存が直ちにトリガされ、又は、親レルムにおける例外に関して進行中の処理と並列に、ゆっくりとした方法で実行することができる。次いで、ステップ４７８において、レルム退出がトリガされ親レルムＡに切り替え、ステップ４８０において、例外の処理が親レルム内で実行される。図３０のステップ４７４及びステップ４７６は、自発的なレルム退出の場合、省略することができる。
図３１は、ネストされたレルム・エントリ及び退出を表す類似の一実例を示す。所望の子レルムのＲＥＣを指し示すためのリンク・レジスタをすでにセットした、例外レベルＥＬ２の祖父レルムＡは、ステップ５００でＥＲＥＴ命令を実行し、レルムＩＤレジスタＲＩＤ＿ＥＬ２を子レルムのローカルＲＩＤにセットし、ＳＰＳＲ＿ＥＬ２でＲフラグを１にセットする。これにより、ステップ５０２でレルムＢへのレルム・エントリがトリガされ、ステップ５０４でレルムＢのＲＥＣから復元される状態がトリガされ、この場合も、直ちに又はゆっくりと実行することができる。最終的には、次に、レルムＢは、ステップ５０６でさらにＥＲＥＴ命令を実行し、この場合も、ステップ５０８でさらなるレルム・エントリをトリガするために、リンク・レジスタ、ＲＩＤレジスタ及びＲフラグをセットさせる。ステップ５０２及び５０８におけるレルム・エントリは、図２８で表すように実行することができ、そのため、レルム・チェックといったステップもなお実行できるが、簡潔にするため、図３１には示していないことに留意されたい。次いで、レルムＣへのエントリに続いて、ステップ５１０でレルムＣのアーキテクチャの状態がそのＲＥＣから復元され、ステップ５１２で、処理はレルムＣ内で再開する。
続いて、例外がステップ５１４で発生する。例外は、例外レベルＥＬ２を目標とする。たとえば、例外は、ハイパーバイザによって取り扱われる例外のタイプとすることができる（仮想化されたデバイスと関連付けられたイベント又はステージ２のアドレス変換障害など）。ステップ５１６において、任意の消去及び状態保存を含む状態マスク化プロセスが、図３０に表すように類似の方法でトリガされ、例外が発生したレルムＣの親レルムであるレルムＢへのレルム退出がステップ５１８で実行される。
ステップ５２０において、処理要素が、発生した例外の目標例外レベルはレルムＢの境界例外レベルよりも高いことを検出し、その結果、レルムＢは中間レルムであり、レルムＢの親レルムへのさらなるレルム退出が必要となる。したがって、中間レルム・フラグが、ステップ５２２でＳＰＳＲ＿ＥＬ１内にセットされ、ステップ５２４で、レジスタのサブセットのさらなる状態マスク化、消去及び保存が実行される。この場合も、レルムＡへのレルム退出に続いて、対応する状態が、プロセッサがアクセス不能なレジスタのプロセス内に何らかの方法で保持することができる場合、このプロセスの保存部分は遅らせることができる。この中間レルムのために保存されたレジスタのサブセットは、ＥＬ１でアクセス可能なレジスタ３５２を含むが、ＥＬ０でアクセス可能なレジスタ３５０は除外する。レジスタ３５０のサブセットを保存する必要はない。というのは、ステップ５０８における前のレルム・エントリ及びこれらのレジスタは、すでにレルムＣによってマスク化／消去／保存されているので、レルムＢは、これらのレジスタを変更するためにいかなる命令も実行していないからである。したがって、これにより、中間レルムに必要とされる追加のマスク化及び状態保存の量を削減する。
次いで、さらなるレルム退出５２６が、中間レルムの親であるレルムＡに対してトリガされる。この場合、レルムＡはＥＬ２で動作できるので例外を取り扱うことができ、そのため、ステップ５２８において、例外が、例外レベルＥＬ２で取り出され、処理される。例外はハイパーバイザによって処理され、いったん例外が取り扱われると、ＥＲＥＴ命令５３０が実行されて前の処理に戻る。この時点で、ＥＬＲ＿ＥＬ２及びＲＩＤ＿ＥＬ２及びＳＰＳＲ＿ＥＬ２のＲフラグの値は、依然としてＥＲＥＴ命令がステップ５００で実行される前の値と同じである。したがって、これらの値を再度セットする必要はない。ＥＲＥＴ命令５３０は、例外レベルＥＬ１でレルム・エントリをトリガして前の子レルムＢへ戻す。例外ハンドラ・コードは、例外の取扱いに続いて処理をより低い例外レベルに戻すために、レガシー・コードのこうしたＥＲＥＴ命令をすでに有している可能性があることに留意されたい。したがって、上で説明したように、レルム・エントリをトリガするためにＥＲＥＴ命令を再利用することにより、レルム保護機能を意識することなく書かれた既存の例外ハンドラ・コードが、継続して使用可能となり、プラットフォーム開発コストを削減できるようになる。
ＥＬ１でレルムＢに戻ると、処理要素は中間フラグがＳＰＳＲ＿ＥＬ１にセットされていることを検出する（ステップ５３２）。したがって、ステップ５３４において、レルムＢのＲＥＣから復元された状態は、ＥＬ１（登録済３５２）がアクセス可能な状態であるが、ＥＬ０でアクセス可能なレジスタ３５０は除外する。プロセッサ実装形態が、トリガされネストされたレルム・エントリのソフトウェアによってアシストされた方法を使用すると、ステップ５３６において、処理要素は、中間レルムのために例外状態レジスタＥＳＲ＿ＥＬ１を偽のレルム退出に対応する特定の値にセットする。処理要素は、この所定のタイプの偽のレルム退出例外を取り扱うための例外ハンドラを示す例外ベクトルに、プログラム・カウンタをセットし、次いで、例外ハンドラはステップ５３８で実行される。例外ハンドラは、いかなる実際の機能を実行する必要はなく、ＥＲＥＴ命令をトリガするだけである、又は、同様に、いくつかの他の動作を提供するだけである。最終的に、ＥＬＲ＿ＥＬ１、ＲＩＤ＿ＥＬ１及びＳＰＳＲ＿ＥＬ１レジスタは、ＥＲＥＴ命令がステップ５０６で実行される前にあったように依然としてセットされるので、レルム・エントリ５４４をトリガして、元の例外が発生した前に実行した前の子レルムへ戻すＥＲＥＴ命令がステップ５４２で実行される。この時点で、状態がステップ５４６においてレルムＣのＲＥＣから復元され、ステップ５４８で、処理は上のステップ５１０、５１２と同じ方法で続行する。
或いは、ハードウェアによってアシストされるネストされたレルム・エントリの場合、ステップ５３６～５４２は省略でき、代わりに、ステップ５３４で所要の状態のサブセットを復元させ、処理要素のハードウェアは、中間レルム・フラグから、レルムＣに対してさらなるレルム・エントリが必要であることを検出し、その結果、ステップ５５０で、ハードウェアは、実行すべきさらなるＥＲＥＴ命令５４２を必要とすることなく、後続のレルム・エントリを直接連鎖させることができる。この場合、中間レルム内で任意の命令を実行する必要はない。
こうしたネストされたレルム・エントリ及び退出手順を使用することにより、ＥＬ２のレルムがＥＬ０と関連付けられた任意のレルム値又はＲＥＣポインタに対処する必要が避けられる。現在のレルムの中間子レルムのパラメータのみがチェックの必要があるので、これによりレルムを入力するとき、クリーナー及び単純チェックができるようになる。これによりアーキテクチャ及びハードウェア実装が非常に単純化される。
図３２及び３３は、それぞれレルム退出及びレルム・エントリ時にＲＥＣとの間でのゆっくりとした状態保存及び状態復元の実例を表す。一般に、親レルムに対してレルムを退出させる際は、親レルムから状態を隠すために子レルムと関連付けられた状態をマスク化し、親レルムが消去された状態に対応するアーキテクチャ・レジスタへのアクセスを試みるとき、親レルムがいくつかの所定の値を見るであろうことを保証するために消去を実行することが望ましいであろう。こうした動作は、比較的迅速に実行することができる。しかし、子レルムの状態をいつまでも保持するための、処理回路の物理レジスタ・ファイルの空間が不十分である場合、一部のデータをＲＥＣに保存することが望ましいであろう。しかし、これにはより長い時間がかかり、本来なら親レルムで処理に使用できるメモリ帯域幅を占有し、これにより親レルムの処理を遅らせる恐れがある。同様に、レルムを入力する際に、メモリからレジスタへ状態を復元するための対応する動作には、かなりの時間がかかることがある。したがって、効率上の理由から、ＲＥＣとの間で処理要素状態の非同期的な保存／復元をサポートすることが望ましいであろう。所与のプロセッサ実装形態が、このゆっくりとした状態保存を実際に行うかどうかは、特定のプロセッサに対する実装上の選択である。たとえば、高い効率を目標としない一部のプロセッサは、どちらの状態がすでに保存され、どちらはまだかといった管理の複雑性を削減するために、状態保存動作を直ちに単純にトリガすることがより簡潔であると考えるであろう。しかし、必要に応じて効率改善を可能にするために、非同期的、ゆっくりした状態保存手法といった、アーキテクチャ機能性サポートを行うことが望ましいであろう。
したがって、元のレルムから、元のレルムよりもより特権を有する例外レベルで処理されるべき目標レルムへのレルム切り替えに応答して、処理回路は、状態のマスク化を実行し、目標レルムがアクセスできない元のレルムと関連付けられたアーキテクチャの状態データのサブセットを作ることができる。状態のマスク化されたサブセットを、必須ではない時点でメモリに保存することは可能であるが、しかし、アーキテクチャは、レルム切り替えの後で使用できるフラッシュ・コマンドを提供する。フラッシュ・コマンドが実行されると、処理回路は、少なくとも１つのＲＥＣメモリ領域にまだ保存されていないアーキテクチャの状態データのマスク化されたサブセットのうちのいずれもが、少なくとも１つのＲＥＣメモリ領域に保存された場合には、元のレルムによって所有されるということを保証する。こうしたフラッシュ・コマンドを提供することにより、アーキテクチャの状態データのサブセットが確実に保存されたことを保証する必要のある時点で、これを強行することができ、これにより、アーキテクチャの特別なマイクロ・アーキテクチャ実装を、フラッシュ・コマンドがまだ実行されていないケースでアーキテクチャの状態データのサブセットが実際にメモリに保存されるまさにそのときに、変更する自由が与えられるということを保証することができる。
状態マスク化に加えて、レルム切り替えに際して、処理回路はまた、上で述べたような、所与のアーキテクチャ・レジスタへの任意の後続の読み取りアクセスが、所定の値を戻す（介在する書き込みアクセスなしに実行された場合）ことを保証するレジスタ消去動作を実行することができる。この消去は、所与のアーキテクチャ・レジスタに対応する物理レジスタに所定の値を実際に書き込むことにより、レジスタ・リネーミングにより、又は、読み取りアクセスは、対応する物理レジスタの実際のコンテンツに代えて所定の値を戻さなければならないことを示すために、所与のアーキテクチャ・レジスタと関連付けられた他の制御状態値をセットすることにより、実行することができる。レルム切り替えに応答して実行される状態保存が、非同期的に実行されると、レルム切り替えに応答してアクセス不能とされた、アーキテクチャの状態データのサブセットの少なくとも一部が、依然として処理回路のレジスタに記憶されるとき、処理回路は目標レルムの処理を開始することができる。たとえば、プロセッサは、命令セット・アーキテクチャのアーキテクチャ・レジスタとして提供される多くのレジスタよりも大きな物理レジスタ・ファイルを有することが可能であり、そのため、一部の予備の物理レジスタを使用して、目標レルムがすでに処理を開始した後しばらくの間、以前にマスク化された状態を保持することができる。これは、アーキテクチャの状態データのサブセットの所与の項目が、依然としてレジスタに記憶されているときに、処理が元のレルムに戻ると、処理回路は、ＲＥＣからデータを復元する必要なしに、レジスタ・ファイルとの間でその所与のアーキテクチャの状態の項目へのアクセスを簡単に復元することができるので有益である。いくつかのタイプの例外では、実行されるべき比較的短い例外ハンドラだけが必要なことがあり、この場合には、いくつかのマスク化された状態が、例外から戻るときに依然としてレジスタ・ファイルに常駐している可能性がある。こうした「浅い」例外エントリ／戻りイベントは、ゆっくりとした状態保存を使用することから利益を得ることができる。
ゆっくりとした状態保存が使用されると、例外に続いて目標レルムの処理が開始されるといつも、フラッシュ・コマンド以外の所定のイベントの発生に応答して、処理回路は、ＲＥＣ領域の所与の項目の保存をトリガすることができる。この時点における処理は、すでに親レルム（これは通常は前の子レルムと関連付けられたＲＥＣへはアクセスしない）に切り替わっているが、こうした動作は、ソフトウェアではなくマイクロ・アーキテクチャ実装によってハードウェアでトリガされるので、一般的なソフトウェアによってトリガされるメモリ・アクセス（事実上、こうしたＲＥＣ保存動作は、実行前に子レルムによってすでに許可されているであろう）に必要とされるのと同じ所有権チェックを受けることはないであろう。
多くの異なるタイプの所定のイベントを使用して、以下を含む、ＲＥＣに保存されるアーキテクチャの状態データのサブセットの一定の項目をトリガすることができる。
・アーキテクチャの状態データのサブセットの所与の項目に対応したアーキテクチャ・レジスタへのレジスタ・アクセス。この手法は、レジスタ・リネーミングをサポートしないあまり複雑ではないプロセッサに有用である。この場合、各アーキテクチャ・レジスタは１つの固定物理レジスタにマッピングすることができ、そのため、親レルムと関連付けられたコードが、初回に所与のアーキテクチャ・レジスタにアクセスしようとすると、これによりメモリに保存される子レルムによって使用されるレジスタの古い値が必要になるであろう。
・アーキテクチャの状態データのサブセットの所与の項目を記憶する物理レジスタの再マッピング。レジスタ・リネーミングをサポートするシステムにおいて、アーキテクチャの状態はレジスタ・ファイルにより長く残ることができるが、最終的には、異なる値を記憶するために対応する物理レジスタを再マッピングする必要があり、この時点で、子レルムの対応するアーキテクチャの状態はＲＥＣに保存することができる。
・所定の閾値以下になるいくつかの使用可能な物理レジスタ。この場合、所与の物理レジスタの実際の再マッピングを待つよりはむしろ、状態保存は、自由な物理レジスタ（異なるアーキテクチャ・レジスタへの再割り当てに利用可能である）の番号が小さくなると先制して実行を開始することができる。
・所与のサイクルの数又は所与の期間の経過。したがって、任意の特定の処理イベントが保存をトリガする必要はないが、代わりに、ゆっくりとした状態保存により、親レルムでの処理によってトリガされた他のメモリ・アクセスに利用可能なメモリ帯域幅への影響を減らすために、子レルムのコンテキストの保存をある時間にわたって順番にＲＥＣへ単純に広げることができる。
・削減されたプロセッサ作業負荷を示すイベント、たとえば、アイドル状態のプロセッサ時間の期間、又は、状態保存を実施することを示すいくつかの他のイベントは、今や、親レルムの処理の全体的な効率への影響は小さい。この時点で、アーキテクチャの状態データの少なくとも一部のサブセットの保存をトリガすることができる。
レルム切り替えに続いて、処理回路は、レルムが前に親レルムに切り替えた元レルム以外のさらなるレルムを入力しようとする場合、処理回路は、さらなるレルムが同じ例外レベル、又は、前のレルム退出の目標レルムよりも低い特権を有する例外レベルで処理されるとき、レルム・エントリ要求を拒否することができ、フラッシュ・コマンドが、レルム切り替えとレルム・エントリ要求との間で受け取られることはない。或いは、レルム・エントリ要求は、フラッシュ・コマンドが実行されたかどうかにかかわらず受け取ることができるが、フラッシュ・コマンドが実行されなかった場合、最初の子レルムＲＥＣ状態は破損され、その結果、ＲＥＣは再使用することができず、正当なエントリが子レルムに入るのを防止する。どちらにしても、親レルムが異なる子レルムに対する処理を、前に実行された子レルムへ首尾よく向けることができる前にフラッシュ・コマンドが要求される。これにより、たとえハードウェアが、ゆっくりとした状態保存手法を使用することを選択したとしても、前の子レルムと関連付けられたすべての必要な状態は、異なる子レルムが入力された時点でメモリに保存されることが保証されるであろう。これにより、保存すべき数組の子レルム・データをバックアップする必要が避けられ、アーキテクチャが簡素化される。
フラッシュ・コマンドは、マスク化されたレジスタからの状態がＲＥＣメモリ領域に記憶することを確約することを保証する必要があるだけということに留意されたい。フラッシュ・コマンドによってトリガされる記憶動作は、処理要素８のロード／ストア待ち行列内、又は、相互接続１４、メモリ・コントローラ若しくはメモリ１６それ自体内のキューに入れられる。そのため、メモリ・セルへの実際の書き込み後まで発生しないが、処理要素の視点からは、マスク化された状態のメモリ書き込みは明確に発生する。
フラッシュ・コマンドは、処理回路の命令デコーダによってサポートされたネイティブ命令とすることができる。或いは、フラッシュ・コマンドは、命令デコーダによってデコードされた命令の処理を続行するために、所定のイベントによってトリガされたコマンドとすることができる。たとえば、フラッシュ・コマンドは、前の子レルムと関連付けられたアーキテクチャの状態のすべての必要なサブセットのために、状態保存動作がメモリにトリガされたということを保証すべきであると暗示する、いくつかの他のタイプの命令によって自動的にトリガすることができる。
上で説明したように、レルム切り替え中に保存されるアーキテクチャの状態の特別なサブセットは、元のレルムと関連付けられた境界例外レベルによって決まることがある（及び、元のレルムがネストされたレルム退出の中間レルムであるかどうかによっても決まることがある）。状態マスク化及び保存動作は、レルム切り替えが所定のタイプのレルム切り替え（たとえば、元のレルムでの自発的なレルム切り替え命令の実行によってトリガされるレルム切り替え）の場合抑制することができる。
したがって、図３２はゆっくりとした状態保存及び復元の一実例を表す。ステップ５６０において、レルム退出が上で説明したのと同じ方法で取り扱われる。レルムＢに対して隠されるべきアーキテクチャの状態のサブセットは、レルム退出時にマスク化され、消去されるが、ＲＥＣへの状態保存は遅れることがあり、そのため、ゆっくりとした状態保存プロセス５６２が、親レルムＡと関連付けられた処理５６４のバックグラウンドで実行することができる。ゆっくりとした状態保存が実行される特別な方法は、特別な処理設計のため実装選択とすることができる。ステップ５６６において、親レルムはレルム・エントリをトリガして前の子レルムへ戻す（上で説明したようにＥＲＥＴ命令を使用して）。この場合、レルム・エントリは前に退出したのと同じ子に戻るので、そのレルム・エントリに対するフラッシュ・コマンドが有効である必要はない。ゆっくりとした状態保存動作の一部５６８が依然として処理される場合、これはレルム・エントリの後で取り消すことが可能であり、その代わり、レルムＢに対する対応する状態値が、処理要素のいくつかの物理レジスタから単純に復元することができる。したがって、比較的浅い例外退出及び戻りに対して、ゆっくりとした状態保存手法を使用することは、効率を向上させるために必要なメモリ・アクセスの量を削減する助けとなる。
図３３は、レルム退出５６０が、レルムＢ１からその親レルムＡへ図３２と同じ方法で実行される別の実例を表す。しかし、今回は、同じレルムに戻るというよりは、レルムＡは処理を異なる子レルムＢ２へ切り替えることを望んでいる。したがって、親レルムはステップ５７０で、ゆっくりとした状態保存プロセス５６２のうちの残りのいかなる部分も完了したということを保証する処理要素をトリガする、フラッシュ・コマンドを実行する（すなわち、処理要素のレジスタ・ファイルに依然として存在するマスク化されたサブセットの残りすべてのアーキテクチャの状態に対する記憶動作が発行される）。ステップ５７２において、親レルムは、目標レルムＢ２に対してレルムＩＤ及びＲＥＣポインタを示すために、レルム識別子レジスタ及びリンク・レジスタをセットし、次いで、ステップ５７４で、レルム・エントリ５６６をレルムＢ２にトリガするＥＲＥＴ命令を実行する。フラッシュ・コマンドが、ＥＲＥＴ命令を実行する前に実行されなかったならば、レルム・エントリは失敗したであろう。ステップ５７８において、状態復元がレルムＢ２のＲＥＣメモリ領域から実行される（この場合も、これはゆっくりと行うことができる）。
したがって、フラッシュ・コマンドを使用することにより、プロセッサ状態から前に退出したレルムのＲＥＣへの迅速な例外退出及びトリックリングが可能となり、また、状態が処理要素のレジスタ内に保持されＲＥＣから記憶され再ロードされることのない場所への、浅い例外退出及び戻りができるようになる。
図３４は、親レルムによって初期化することができるサブレルムの概念を示す。図３４に示すように、特定の例外レベルで動作する所与の親レルム６００は、その親と同一の例外レベルで動作するサブレルム６０２を初期化することができる。完全レルム６００は、所与のソフトウェア・プロセス（又は２つ以上のプロセスの集合）に対応するが、サブレルムは、所与のソフトウェア・プロセス内の所定のアドレス範囲に対応する。完全レルムはサブレルムの親であるので、上で説明したように、サブレルムは、親完全レルムによって所有されたメモリ領域に記憶されたデータにアクセスする権利を有することができるが、サブレルムは、サブレルム６０２によって所有されたメモリ領域に記憶されたアクセス・データからその親完全レルムを除外する権利を有することができる。これは、所与のソフトウェア・プロセスのある部分をそのソフトウェア・プロセスの他の部分よりもより安全にするのを可能にするのに有用である。たとえば、モバイル・バンキング・アプリケーションのパスワードをチェックするため、又は、他の機密情報にまつわる情報を処理するためのコードの一部は、同一のアプリケーション又はオペレーティング・システムの他の部分が、その機密情報にまつわる情報にアクセスできないように、サブレルムに割り当てることができる。
サブレルムは一般に、以下に説明するようにいくつかの相違はあるものの、完全レルムと同じ方法で取り扱うことができる。サブレルムとの間でのエントリ及び退出は、例外リターン命令及び例外イベントを使用して、上で説明したのと同じ方法で取り扱うことができる。したがって、サブレルムは、同じ親の完全子レルム用と同じ方法で構成された子レルムＩＤを有することができ、上で説明したようなレルム記述子ツリー内のレルム記述子を備えることができる。サブレルムへのエントリは、ＥＲＥＴ命令を実行する前に、ＲＩＤレジスタに適切な子サブレルムＲＩＤを配置したＥＲＥＴ命令を単純に実行することによりトリガすることができる。したがって、同じタイプの（第２の変形体の）ＥＲＥＴ命令を使用して、完全レルム又はサブレルムのどちらにでもエントリをトリガすることができる。
サブレルムが完全レルムと異なる１つの点は、サブレルムは自身の子レルムを初期化することが許されていないということであろう。したがって、新しいレルムを初期化するためのレルム初期化コマンドは、現在のレルムがサブレルムの場合、拒絶されるであろう。ＲＭＵは、現在のレルムのレルム記述子内のレルム・タイプ値を使用して、現在のレルムは完全レルムかサブレルムかを判定することができる。現在サブレルムにいるとき、レルム初期化をできないようにすることにより、さらなるレルムを初期化する際にサブレルムによって使用するための追加の状態レジスタを備える必要がないため、アーキテクチャが単純化される。
同様に、現在サブレルムにいるとき、レルム・エントリ命令の実行はできないであろう。レルム・エントリ及び退出（並びに例外エントリ及び戻り）を取り扱うために使用される、上で説明したＥＬＲ、ＳＰＳＲ、ＥＳＲ及びＲＩＤレジスタといった一列に並べられたレジスタのうちのいくつかは、設計時に、所与のプロセスがいくつのサブレルムを作成するかがわからないので管理するのが難しいため、それぞれのサブレルムに対してレジスタをさらに一列に並べる必要はないということを意味するので、アーキテクチャが簡略化される。同様に、より低い特権レベルで動作するプロセスへのスイッチをトリガする例外戻しイベントは、現在のレルムが完全レルムではなくサブレルムのとき使用できなくなる。上で説明した実例において、単一タイプのＥＲＥＴ命令は、レルム・エントリ命令としても例外リターン命令としても機能するが、これはすべての実施例にとって重要ではなく、個々の命令が提供されたとき、レルム・エントリ命令も例外リターン命令も、現在のレルムがサブレルムの場合、使用できなくなる。
同様に、サブレルムにあるとき例外が発生した場合、例外を直接サブレルムから除去するよりは、処理回路は、例外を取り扱う前に、サブレルムからサブレルムを初期化した親完全レルムへ退出をトリガすることができる。したがって、例外は親完全レルムへの戻しをトリガする。親完全レルムへの例外戻しは、ＲＥＣへ対する状態マスク化、消去及び保存動作を含むことができるが、例外がより高い例外レベルでサブレルムからレルムへ直接除去されるのを防ぐことにより、ＥＬＲ、ＳＰＳＲ及びＥＳＲといった例外制御レジスタをサブレルムのためにさらに一列に並べる必要が避けられ、アーキテクチャが簡略化される。
サブレルムの場合、レルムを処理することができる最大特権レベルを示す境界例外レベルは、その親完全レルムに対する境界例外レベルに等しい。対照的に、子完全レルムの場合、境界例外レベルは、その親レルムの境界例外レベルよりもより低い特権を有する例外レベルである。
レルムが親レルムによって初期化されると、親レルムは、新しいレルムが子完全レルムになるか子サブレルムになるか選択することができ、それに応じて、適切なレルム・タイプのパラメータをレルム記述子にセットすることができる。いったん、レルムが動作すると、図１８に関して上で説明した管理されたレルム・ライフサイクルによりレルム記述子の変更が禁止されるため、親レルムはもはやレルム・タイプを変更することができない。
要約すれば、完全レルムと似ているが、例外取扱い、レルム初期化及びレルム・エントリ機能がサブレルム内で使用不能となる状態で管理されるサブレルムを導入する機能により、完全レルムのソフトウェア・プロセス内で所与のアドレス範囲に対応するコードのより小さな部分が、そのソフトウェアの他の部分から分離され、機密情報にまつわるコード又はデータのある部分に対して追加的なセキュリティを提供することができるようになる。
図３５は使用可能なシミュレータ実装を示す。前に説明した実施例は、関連する技術をサポートする特定の処理ハードウェアを動作させるための装置及び方法に関して、本発明を実装しているが、コンピュータ・プログラムの使用により実装された本明細書に記載の実施例による、命令実行環境を提供することも可能である。こうしたコンピュータ・プログラムは、ソフトウェアに基づくハードウェア・アーキテクチャの実装を提供する限り、しばしばシミュレータと呼ばれる。様々なシミュレータ・コンピュータ・プログラムとしては、エミュレータ、仮想マシン、モデル、及び動的バイナリ・トランスレータを含むバイナリ・トランスレータが挙げられる。通常、シミュレータ実装は、シミュレータ・プログラム７１０をサポートする、ホスト・オペレーティング・システム７２０をオプションとして実行させる、ホスト・プロセッサ７３０上で実行することができる。いくつかの構成では、ハードウェアと提供された命令実行環境との間にシミュレーションの複数の層、及び／又は同じホスト・プロセッサに提供された複数の異なる命令実行環境があってもよい。歴史的に見て、納得のいく速度で実行するシミュレータ実装を提供するには、強力なプロセッサが必要とされてきたが、こうした手法は、互換性又は再利用の理由で別のプロセッサにネイティブなコードを実行したいという要望があるときなど、一定の事情において正当化することができる。たとえば、シミュレータ実装は、ホスト・プロセッサ・ハードウェアによってサポートされない追加の機能を有する命令実行環境、又は、通常、異なるハードウェア・アーキテクチャと関連付けられた命令実行環境を提供することができる。シミュレータの全体像は、「Ｓｏｍｅ Ｅｆｆｉｃｉｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｉｍｕｌａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ」、１９９０年冬、ＵＳＥＮＩＸ Ｃｏｎｆｅｒｅｎｃｅ、５３～６３頁に述べられている。
シミュレートされた実施例において、特定のハードウェア構成又は機能を参照して、実施例が以前に説明された範囲で、同等の機能を適切なソフトウェア構成又は機能により提供することができる。たとえば、特定の回路をコンピュータ・プログラム・ロジックとしてシミュレートされた実施例に実装することができる。同様に、レジスタ又はキャッシュといったメモリ・ハードウェアは、ソフトウェア・データ構造としてシミュレートされた実施例に実装することができる。前に説明した実施例で参照された１つ又は複数のハードウェア要素が、ホスト・ハードウェア（たとえば、ホスト・プロセッサ７３０）に存在する配列において、いくつかのシミュレートされた実施例は、適切なホスト・ハードウェアを使用することができる。
シミュレータ・プログラム７１０は、コンピュータ可読記憶媒体（これは非一時的な媒体でよい）に記憶することができ、プログラム・インターフェース（命令実行環境）を、シミュレータ・プログラム７１０によってモデル化されているハードウェア・アーキテクチャのアプリケーション・プログラム・インターフェースと同じ目標コード７００（これは、図２に表すように、アプリケーション、オペレーティング・システム、及びハイパーバイザを含むことができる）に提供する。したがって、上で説明したレルム保護機能に基づくメモリ・アクセスの制御を含む、目標コード７００のプログラム命令は、シミュレータ・プログラム７１０を使用して命令実行環境内から実行することができ、その結果、上で説明した装置２のハードウェア機能を実際には有していないホスト・コンピュータ７３０が、これらの機能をエミュレートすることができる。
少なくともいくつかの実例は、ホスト・データ処理装置を制御して、１つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理回路と、複数のメモリ領域の所有権を実現するためのメモリ・アクセス回路であって、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所有者レルムが、前記所与のメモリ領域内に記憶されたアクセス・データから他のレルムを除外する権利を有する、メモリ・アクセス回路と、その中でルート・レルム以外の各レルムが、親レルムによってトリガされるコマンドに応答して初期化される子レルムであるレルム階層に従って、複数のレルムを管理するためのレルム管理ユニットであって、目標レルムのコマンド要求無効に応答し、目標レルム、及び処理回路がアクセスできない目標レルムの任意の子孫レルムを作成するように構成されているレルム管理ユニットと、を含む装置により、命令実行環境を提供するための命令を含む、仮想マシン・コンピュータ・プログラムを提供する。記憶媒体は仮想マシンのコンピュータ・プログラムを記憶することができる。記憶媒体は非一時的な記憶媒体とすることができる。
本出願において、「構成される」という用語は、装置の要素が定義された動作を実行することができる構成を有しているということを意味するために使用される。この文脈において、「構成」とは、ハードウェア又はソフトウェアの配置又は相互接続の方法を意味する。たとえば、装置は、定義された動作を提供する専用ハードウェアを有してもよく、又は、プロセッサ若しくは他の処理デバイスは、機能を実行するようにプログラムされてもよい。「構成される」とは、装置の要素が定義された動作を提供するために、どのような方法によってであれ、変更される必要があるということを暗示しない。
本発明の例示の実施例について、本明細書において添付図面を参照しながら詳細に説明してきたが、本発明は、これらの明確な実施例に限定されるものではなく、添付の請求項によって定義された本発明の範囲及び趣旨から逸脱することなく、当業者により様々な変更及び改変をその中で行うことができることを理解されたい。

Claims (19)

  1. １つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理回路と、
    複数のメモリ領域の所有権を行使するためのメモリ・アクセス回路であり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、前記ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を前記所有者レルムが有する、メモリ・アクセス回路と、
    ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って前記複数のレルムを管理するためのレルム管理ユニットと
    を備え、
    前記処理回路が、所与の子レルムの親レルム以外のレルムから前記所与の子レルムに入ることを禁じられ、
    目標レルムの無効化を要求するコマンドに応答して、前記レルム管理ユニットが、前記目標レルムは前記処理回路によって実行されない無効のレルムであることを示すように前記目標レルムに関連するレルム管理データを更新するが、前記目標レルムの任意の子孫レルムに関連するレルム管理データはそのままにしておき、前記目標レルム及び前記目標レルムの任意の子孫レルムを前記処理回路にアクセス不可能にさせるように構成された、装置。
  2. 前記レルム管理ユニットが、所与の子レルムの親レルムによって所有されているメモリ領域内の前記所与の子レルムに関連するレルム管理データを記憶するように構成された、請求項１に記載の装置。
  3. 前記レルム管理ユニットが、無効にされた目標レルムによって所有される各メモリ領域を再請求するための再請求動作をトリガするように構成された、請求項１から２までのいずれか一項に記載の装置。
  4. 前記処理回路が複数の処理要素を備え、前記処理要素のうちの１つでソフトウェア・プロセスによってトリガされた前記目標レルムの無効化に応答して、前記レルム管理ユニットが、少なくとも１つの他の処理要素によって保持された前記目標レルム及び前記目標レルムの任意の子孫レルムのキャッシュされたレルム管理データの無効化をトリガするように構成された、請求項１から３までのいずれか一項に記載の装置。
  5. 前記キャッシュされたレルム管理データが、前記キャッシュされたレルム管理データに関連する前記対応するレルムを識別するグローバル・レルム識別子と関連付けられ、
    所与の子レルムの前記グローバル・レルム識別子が、前記所与の子レルムの親レルムの前記グローバル・レルム識別子と共通部分を共用する、請求項４に記載の装置。
  6. 前記処理回路が、目標レルムに入ろうと試み、前記目標レルムに関連するレルム管理データがアクセス不可能であるときに、前記処理回路が、故障条件をトリガするように構成された、請求項１から５までのいずれか一項に記載の装置。
  7. 目標メモリ領域の所有権の所与の子レルムへの移転を要求する領域請求コマンドに応答して、前記レルム管理ユニットが、前記目標メモリ領域が前記所与の子レルムの親レルム以外のレルムによって所有されるときに前記領域請求コマンドを拒否するように構成された、請求項１から６までのいずれか一項に記載の装置。
  8. 各メモリ領域が、複数のライフサイクル状態のうちの１つと関連付けられ、前記レルム管理ユニットが、前記目標メモリ領域が所定のライフサイクル状態以外のライフサイクル状態にあるときに前記領域請求コマンドを拒否するように構成された、請求項７に記載の装置。
  9. 所与の子レルムが、前記所与の子レルムによって所有される所与のメモリ領域に記憶されたデータにその親レルムがアクセスすることを排除する権利を有する、請求項１から８までのいずれか一項に記載の装置。
  10. 前記メモリ・アクセス回路が、前記所与の子レルムによって設定された属性に応じて、その親レルムが、前記子レルムによって所有される前記所与のメモリ領域に記憶されたデータにアクセスすることを可能にされるかどうかを決定するように構成された、請求項９に記載の装置。
  11. 前記所与の子レルムが、前記所与のメモリ領域に記憶されたデータにその親レルムがアクセスすることを可能にするとき、前記所与の子レルムと同じ親レルムを共有する兄弟レルムもまた、前記所与のメモリ領域に記憶された前記データにアクセスすることを可能にされる、請求項１０に記載の装置。
  12. 前記メモリ・アクセス回路が、前記所与の子レルムによって設定されたグローバル可視性属性が所定の値を有するときに前記子レルムによって所有される前記所与のメモリ領域に記憶されたデータに任意のレルムがアクセスすることを許すように構成された、請求項１から１１のいずれか一項に記載の装置。
  13. 前記処理回路が、複数の特権レベルのうちの１つによるソフトウェア・プロセスを実行するように構成されており、
    所与の子レルムが、その親レルムと同じ特権レベル又はその親レルムより低い特権レベルで実行されるソフトウェア・プロセスに対応する、請求項１から１２のいずれか一項に記載の装置。
  14. 前記レルム管理ユニットが、ハードウェア・ユニットを備える、請求項１から１３のいずれか一項に記載の装置。
  15. 前記レルム管理ユニットが、レルム管理ソフトウェアを実行する前記処理回路を備える、請求項１から１４までのいずれか一項に記載の装置。
  16. １つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための手段と、
    複数のメモリ領域の所有権を行使するための手段であり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を前記所有者レルムが有する、手段と、
    ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って前記複数のレルムを管理するための手段と
    を備え、
    前記データ処理を実行するための手段が、所与の子レルムの親レルム以外のレルムから前記所与の子レルムに入ることを禁じられ、
    目標レルムの無効化を要求するコマンドに応答して、前記管理するための手段が、前記目標レルムは前記データ処理を実行するための手段によって実行されない無効のレルムであることを示すように前記目標レルムに関連するレルム管理データを更新するが、前記目標レルムの任意の子孫レルムに関連するレルム管理データはそのままにしておき、前記目標レルム及び前記目標レルムの任意の子孫レルムを前記データ処理を実行するための手段にアクセス不可能にするように構成された、装置。
  17. １つ又は複数のソフトウェア・プロセスに応答して処理回路でデータ処理を実行するステップと、
    複数のメモリ領域の所有権を行使するステップであり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、前記ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を前記所有者レルムが有し、前記複数のレルムが、ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層を有し、前記処理回路が、所与の子レルムの親レルム以外のレルムから前記所与の子レルムに入ることを禁じられるようにする、ステップと、
    目標レルムの無効化を要求するコマンドに応答して、前記目標レルムは前記処理回路によって実行されない無効のレルムであることを示すように前記目標レルムに関連するレルム管理データを更新するが、前記目標レルムの任意の子孫レルムに関連するレルム管理データはそのままにしておき、前記目標レルム及び前記目標レルムの任意の子孫レルムを前記処理回路にアクセス不可能にさせるステップと
    を含む、データ処理方法。
  18. 命令実行環境を提供するためにホスト・データ処理装置を制御するためのコンピュータ・プログラムであって、
    １つ又は複数のソフトウェア・プロセスに応答してデータ処理を実行するための処理プログラム論理と、
    複数のメモリ領域の所有権を行使するためのメモリ・アクセス・プログラム論理であり、所与のメモリ領域が、複数のレルムの中から指定された所有者レルムと関連付けられ、各レルムが、前記ソフトウェア・プロセスのうちの少なくとも１つのソフトウェア・プロセスの少なくとも一部に対応し、前記所与のメモリ領域に記憶されたデータに他のレルムがアクセスすることを排除する権利を前記所有者レルムが有する、メモリ・アクセス・プログラム論理と、
    ルート・レルム以外の各レルムは親レルムによってトリガされたコマンドに応答して初期化された子レルムであるレルム階層に従って前記複数のレルムを管理するためのレルム管理プログラム論理と
    を含み、
    前記処理プログラム論理が、所与の子レルムの親レルム以外のレルムから前記所与の子レルムに入ることを禁じられ、
    目標レルムの無効化を要求するコマンドに応答して、前記目標レルムは前記処理プログラム論理によって実行されない無効のレルムであることを示すように前記目標レルムに関連するレルム管理データを更新するが、前記目標レルムの任意の子孫レルムに関連するレルム管理データはそのままにしておき、前記レルム管理プログラム論理が、前記目標レルム及び前記目標レルムの任意の子孫レルムを前記処理プログラム論理にアクセス不可能にさせるように構成された、コンピュータ・プログラム。
  19. 請求項１８に記載の前記コンピュータ・プログラムを記憶する記憶媒体。
JP2019570883A 2017-06-28 2018-06-08 レルム階層における目標レルムの無効化 Active JP7149298B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1710342.5A GB2563883B (en) 2017-06-28 2017-06-28 Invalidation of a target realm in a realm hierarchy
GB1710342.5 2017-06-28
PCT/GB2018/051563 WO2019002810A1 (en) 2017-06-28 2018-06-08 INVALIDATION OF A TARGET DOMAIN IN A DOMAIN HIERARCHY

Publications (2)

Publication Number Publication Date
JP2020527777A JP2020527777A (ja) 2020-09-10
JP7149298B2 true JP7149298B2 (ja) 2022-10-06

Family

ID=59523700

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019570883A Active JP7149298B2 (ja) 2017-06-28 2018-06-08 レルム階層における目標レルムの無効化

Country Status (9)

Country Link
US (1) US11449437B2 (ja)
EP (1) EP3646189B1 (ja)
JP (1) JP7149298B2 (ja)
KR (1) KR20200023378A (ja)
CN (1) CN110785747B (ja)
GB (1) GB2563883B (ja)
IL (1) IL271070A (ja)
TW (1) TWI784016B (ja)
WO (1) WO2019002810A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2563886B (en) * 2017-06-28 2019-12-25 Advanced Risc Mach Ltd Realm management unit-private memory regions
CN113760185A (zh) 2017-11-07 2021-12-07 华为技术有限公司 内存块回收方法和装置
GB2578297B (en) * 2018-10-19 2021-07-14 Advanced Risc Mach Ltd Trusted intermediary realm
US11403409B2 (en) 2019-03-08 2022-08-02 International Business Machines Corporation Program interruptions for page importing/exporting
US11132305B1 (en) * 2020-06-11 2021-09-28 Ralph Crittenden Moore Automatic static region generation for memory protection units (MPUs)
EP3964959A1 (en) * 2020-09-03 2022-03-09 ARM Limited Data processing
US20220114265A1 (en) * 2020-10-08 2022-04-14 Google Llc Unified viewing of roles and permissions in a computer data processing system
GB2602480B (en) * 2020-12-31 2023-05-24 Advanced Risc Mach Ltd Context information translation cache
FR3125342B1 (fr) * 2021-07-16 2024-01-12 Stmicroelectronics Grand Ouest Sas Procédé de gestion de droits d’accès de tâches logicielles exécutées par un microcontrôleur, et circuit intégré correspondant.
US11977926B1 (en) * 2023-06-26 2024-05-07 Microsoft Technology Licensing, Llc Deployment of pod cohorts

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080077922A1 (en) 2006-09-26 2008-03-27 Andreas Christian Doring Multi-level memory architecture
WO2016203189A1 (en) 2015-06-16 2016-12-22 Arm Limited Secure initialisation

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100456264C (zh) 2006-03-02 2009-01-28 腾讯科技（深圳）有限公司 一种磁盘空间管理方法及系统
US20130238900A1 (en) 2011-12-12 2013-09-12 Cleversafe, Inc. Dispersed storage network secure hierarchical file directory
US9710622B2 (en) 2015-02-23 2017-07-18 Intel Corporation Instructions and logic to fork processes of secure enclaves and establish child enclaves in a secure enclave page cache
GB2539433B8 (en) 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Protected exception handling
GB2539435B8 (en) 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Data processing memory access control, in which an owning process for a region of memory is specified independently of privilege level
GB2539428B (en) 2015-06-16 2020-09-09 Advanced Risc Mach Ltd Data processing apparatus and method with ownership table
US10114958B2 (en) * 2015-06-16 2018-10-30 Microsoft Technology Licensing, Llc Protected regions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080077922A1 (en) 2006-09-26 2008-03-27 Andreas Christian Doring Multi-level memory architecture
WO2016203189A1 (en) 2015-06-16 2016-12-22 Arm Limited Secure initialisation

Also Published As

Publication number Publication date
US20200117616A1 (en) 2020-04-16
IL271070A (en) 2020-01-30
US11449437B2 (en) 2022-09-20
JP2020527777A (ja) 2020-09-10
TW201905707A (zh) 2019-02-01
GB2563883B (en) 2019-10-09
WO2019002810A1 (en) 2019-01-03
GB2563883A (en) 2019-01-02
GB201710342D0 (en) 2017-08-09
EP3646189A1 (en) 2020-05-06
CN110785747B (zh) 2023-09-08
TWI784016B (zh) 2022-11-21
KR20200023378A (ko) 2020-03-04
CN110785747A (zh) 2020-02-11
EP3646189B1 (en) 2021-03-31

Similar Documents

Publication Publication Date Title
JP7149298B2 (ja) レルム階層における目標レルムの無効化
US11086659B2 (en) Masking of architectural state associated with a realm
US11113209B2 (en) Realm identifier comparison for translation cache lookup
US11294676B2 (en) Exception return instruction variants for realm-based switching
US11176061B2 (en) Realm identifiers for realms for memory access control
US11016910B2 (en) Memory region locking using lock/unlock flag state for exclusive rights to control memory access
US11347660B2 (en) Sub-realms
US11194485B2 (en) Realm execution context masking and saving
US11816227B2 (en) Interrupting export of memory regions
GB2564097B (en) Memory region locking
US11237957B2 (en) Scrub-commit state for memory region
US11874778B2 (en) Realm management unit-private memory regions
GB2563882A (en) Interrupting sequences of command actions performed upon memory regions

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210601

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220323

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220401

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220620

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220902

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220926

R150 Certificate of patent or registration of utility model

Ref document number: 7149298

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150