特表2024-508882 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ アドバンスト・マイクロ・ディバイシズ・インコーポレイテッドの特許一覧 ▶ エーティーアイ・テクノロジーズ・ユーエルシーの特許一覧

特表2024-508882データ移動を容易にするために複数のアドレス空間をサポートする方法、システム及び装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-02-28

(54)【発明の名称】データ移動を容易にするために複数のアドレス空間をサポートする方法、システム及び装置

(51)【国際特許分類】

G06F 13/28 20060101AFI20240220BHJP

G06F 13/14 20060101ALI20240220BHJP

G06F 13/36 20060101ALI20240220BHJP

G06F 12/1036 20160101ALI20240220BHJP

【ＦＩ】

G06F13/28 310L

G06F13/14 310F

G06F13/36 310E

G06F12/1036 100

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023553175

(86)(22)【出願日】2022-03-01

(85)【翻訳文提出日】2023-09-26

(86)【国際出願番号】 US2022018331

(87)【国際公開番号】W WO2022187239

(87)【国際公開日】2022-09-09

(31)【優先権主張番号】17/189,844

(32)【優先日】2021-03-02

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】591016172

【氏名又は名称】アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド

【氏名又は名称原語表記】ＡＤＶＡＮＣＥＤＭＩＣＲＯＤＥＶＩＣＥＳＩＮＣＯＲＰＯＲＡＴＥＤ

(71)【出願人】

【識別番号】508301087

【氏名又は名称】エーティーアイ・テクノロジーズ・ユーエルシー

【氏名又は名称原語表記】ＡＴＩＴＥＣＨＮＯＬＯＧＩＥＳＵＬＣ

【住所又は居所原語表記】ＯｎｅＣｏｍｍｅｒｃｅＶａｌｌｅｙＤｒｉｖｅＥａｓｔ，Ｍａｒｋｈａｍ，Ｏｎｔａｒｉｏ，Ｌ３Ｔ７Ｘ６Ｃａｎａｄａ

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川裕司

(74)【代理人】

【識別番号】100111615

【弁理士】

【氏名又は名称】佐野良太

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨圭介

(72)【発明者】

【氏名】フィリップン

(72)【発明者】

【氏名】ニッポンラヴァル

(72)【発明者】

【氏名】ブヘンシュー

(72)【発明者】

【氏名】ロスチスラフエス．ドブリン

(72)【発明者】

【氏名】ショーンハン

【テーマコード（参考）】

5B205

【Ｆターム（参考）】

5B205KK16

5B205MM36

5B205MM51

(57)【要約】

方法、システム及び装置は、データ移動を容易にするために複数のアドレス空間に対するサポートを提供する。１つのシステムは、ホストプロセッサと、メモリと、ホストプロセッサ及びメモリに結合されたデータファブリックと、複数の入出力メモリ管理ユニット（ＩＯＭＭＵ）であって、複数のＩＯＭＭＵの各々がデータファブリックに結合される、複数のＩＯＭＭＵと、複数のルートポートであって、ルートポートの各々が、複数のＩＯＭＭＵのうち対応するＩＯＭＭＵに結合される、複数のルートポートと、複数の周辺コンポーネントエンドポイントであって、複数の周辺コンポーネントエンドポイントの各々が、複数のルートポートのうち対応するルートポートに結合される、複数の周辺コンポーネントエンドポイントと、を備え、ルートポートの各々がハードウェア制御ロジックを備え、ハードウェア制御ロジックは、複数のルートポートを同期させ、対応する周辺コンポーネントエンドポイントからダイレクトメモリアクセス（ＤＭＡ）要求を受信し、複数のＩＯＭＭＵのうち対応するＩＯＭＭＵにＤＭＡ要求を提供するように動作する。
【選択図】図１２

【特許請求の範囲】

【請求項1】

複数のアドレス空間の間でデータ移動を提供するための方法であって、
複数のルートポートのうち何れかのルートポートが、前記複数のルートポートのうち別のルートポートのコンテキストデータを記憶することであって、前記ルートポートの各々は、複数の入出力メモリ管理ユニット（ＩＯＭＭＵ）のうち対応するＩＯＭＭＵと、複数の周辺コンポーネントエンドポイントのうち対応する周辺コンポーネントエンドポイントと、に結合されており、前記複数のＩＯＭＭＵの各々は、前記複数のアドレス空間のうち異なるアドレス空間に関連付けられた、異なる周辺コンポーネントエンドポイントに関連付けられている、ことと、
前記ルートポートが、ダイレクトメモリアクセス（ＤＭＡ）要求を受信することであって、前記ＤＭＡ要求は、コンテキストデータと、前記複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能の機能識別子と、を含む、ことと、
前記ＤＭＡ要求に応じて、前記別のＩＯＭＭＵに属するメモリアドレス空間へのダイレクトメモリアクセスを、前記ルートポートを介して提供することと、を含む、
方法。

【請求項2】

前記ルートポートの各々は、複数のレジスタを含む、
請求項１の方法。

【請求項3】

前記ルートポートが、前記ルートポートの前記複数のレジスタを、前記複数のルートポートの複数のレジスタと同期させることを更に含む、
請求項２の方法。

【請求項4】

前記ルートポートの前記複数のレジスタを、前記複数のルートポートの前記複数のレジスタと同期させることは、
前記ルートポートが、前記ルートポートの前記複数のレジスタを、前記複数のルートポートの前記複数のレジスタの前記コンテキストデータを用いて初期化することと、
前記ルートポートが、前記複数のルートポートの前記複数のレジスタへの変更を追跡することと、を含む、
請求項３の方法。

【請求項5】

前記ルートポートの前記複数のレジスタを、前記複数のルートポートの前記複数のレジスタの前記コンテキストデータを用いて初期化することは、
前記複数のルートポートの各々のルートポートが、前記ルートポートのコンテキストＩＤを受信することを含む、
請求項４の方法。

【請求項6】

前記複数のルートポートの前記複数のレジスタへの変更を追跡することは、
前記ルートポートのレジスタが変更される場合に、前記ルートポートが、メッセージを前記複数のルートポートに送信することと、
前記複数のルートポートのうち別のルートポートのレジスタが変更される場合に、前記ルートポートが、前記複数のルートポートのうち前記別のルートポートからメッセージを受信することと、を含む、
請求項４の方法。

【請求項7】

前記送信すること及び前記受信することは、レジスタバスを介して行われる、
請求項６の方法。

【請求項8】

前記機能は、ＰＣＩｅエンドポイント機能である、
請求項１の方法。

【請求項9】

前記周辺コンポーネントエンドポイント機能は、物理機能、及び、複数の仮想機能のうち何れかの仮想機能のうち少なくとも１つである、
請求項１の方法。

【請求項10】

データ移動を容易にするために複数のメモリアドレス空間をサポートするための方法であって、
複数のルートポートのうち何れかのルートポートにおいて、前記複数のルートポートのうち別のルートポートのコンテキストデータを受信することであって、前記複数のルートポートの各ルートポートは、複数の入出力メモリ管理ユニット（ＩＯＭＭＵ）のうち対応するＩＯＭＭＵと、複数の周辺コンポーネントエンドポイントのうち対応する周辺コンポーネントエンドポイントと、に結合されている、ことと、
前記ルートポートが、前記ルートポートの複数のレジスタを、前記複数のルートポートの複数のレジスタと同期させることと、
ルートポートに結合された前記対応する周辺コンポーネントエンドポイントからダイレクトメモリアクセス（ＤＭＡ）要求を受信することであって、前記ＤＭＡ要求は、コンテキストデータと、前記複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能の機能識別子と、を含む、ことと、
前記ルートポートが、前記複数のＩＯＭＭＵのうち前記対応するＩＯＭＭＵに前記ＤＭＡ要求を提供することと、を含む、
方法。

【請求項11】

前記複数のＩＯＭＭＵの各々は、前記複数のＩＯＭＭＵのそれぞれのＩＯＭＭＵに属するメモリアドレス空間をマッピングする複数のメモリマップト入出力（ＭＭＩＯ）レジスタを含み、
前記方法は、
前記ＩＯＭＭＵが、前記ルートポートから提供された前記ＤＭＡ要求の前記コンテキストデータに基づいて、前記ＩＯＭＭＵの前記複数のＭＭＩＯレジスタにアクセスすることと、
前記ＩＯＭＭＵから、アクセスされた前記複数のＭＭＩＯレジスタに基づいて、前記別のＩＯＭＭＵに属するコンテキストによって参照されるページテーブルにアクセスすることと、
前記ＩＯＭＭＵが、アクセスされた前記ページテーブルを使用して、前記ＤＭＡ要求のアドレス変換を実行することと、
前記ＩＯＭＭＵが、前記ＤＭＡ要求及び変換されたアドレスに基づいて、メモリアクセスを実行することと、を更に含む、
請求項１０の方法。

【請求項12】

【請求項13】

前記ルートポートの前記複数のレジスタを、前記複数のルートポートの前記複数のレジスタの前記コンテキストデータを用いて初期化することは、
前記複数のルートポートの各々のルートポートが、前記ルートポートのコンテキストＩＤ及び前記ルートポートのアドレスを受信することを含む、
請求項１２の方法。

【請求項14】

【請求項15】

前記送信すること及び前記受信することは、レジスタバスを介して行われる、
請求項１４の方法。

【請求項16】

データ処理システムであって、
ホストプロセッサと、
メモリと、
前記ホストプロセッサ及び前記メモリに結合されたデータファブリックと、
複数の入出力メモリ管理ユニット（ＩＯＭＭＵ）であって、前記複数のＩＯＭＭＵの各々が前記データファブリックに結合されている、複数のＩＯＭＭＵと、
複数のルートポートであって、前記ルートポートの各々が、前記複数のＩＯＭＭＵのうち対応するＩＯＭＭＵに結合されている、複数のルートポートと、
複数の周辺コンポーネントエンドポイントであって、前記複数の周辺コンポーネントエンドポイントの各々が、前記複数のルートポートのうち対応するルートポートに結合されている、複数の周辺コンポーネントエンドポイントと、を備え、
前記ルートポートの各々は、ハードウェア制御ロジックを備え、
前記ハードウェア制御ロジックは、
前記複数のルートポートを同期させることと、
前記ルートポートに結合された前記複数の周辺コンポーネントエンドポイントのうち対応する周辺コンポーネントエンドポイントからダイレクトメモリアクセス（ＤＭＡ）要求を受信することであって、前記ＤＭＡ要求は、コンテキストデータを含み、前記複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能に対する機能識別子を要求する、ことと、
前記複数のＩＯＭＭＵのうち前記対応するＩＯＭＭＵに前記ＤＭＡ要求を提供することと、
を行うように構成されている、
データ処理システム。

【請求項17】

前記ルートポートの各々は、複数のレジスタを備え、
前記ハードウェア制御ロジックは、レジスタバスを介して前記複数のルートポートの前記複数のレジスタの各々と通信するように構成されている、
請求項１６のシステム。

【請求項18】

前記複数の周辺コンポーネントエンドポイントの各々は、ハードウェア制御ロジックを備え、
前記ハードウェア制御ロジックは、
前記少なくとも１つの他のＩＯＭＭＵの前記複数のＭＭＩＯレジスタを同期させることと、
前記対応するルートポートを介して、前記対応するＩＯＭＭＵに結合された前記対応する周辺コンポーネントエンドポイントから、前記ＤＭＡ要求を受信することと、
前記ＤＭＡ要求の前記コンテキストデータに基づいて、前記ＩＯＭＭＵの前記複数のＭＭＩＯレジスタにアクセスすることと、
前記ＩＯＭＭＵから、前記アクセスされた複数のＭＭＩＯレジスタに基づいて、前記少なくとも１つの他のＩＯＭＭＵに属する前記メモリアドレス空間に割り当てられた前記機能にアクセスすることと、
を行うように構成されている、
請求項１６のシステム。

【請求項19】

前記メモリは、周辺コンポーネントエンドポイント割り込み情報を記憶するメモリカーブアウトを含む、
請求項１６のシステム。

【請求項20】

前記周辺コンポーネントエンドポイントの各々は、割り込み要求を受信した場合に、前記メモリのメモリカーブから周辺コンポーネントエンドポイント割り込み情報を取得するように動作するハードウェア制御ロジックを備える、
請求項１９のシステム。

【発明の詳細な説明】

【背景技術】

【0001】

ソフトウェアベースのコピーループをオフロードするために、ダイレクトメモリアクセス（ＤＭＡ）データムーバデバイスが使用される。オフロードは、中央処理装置（ＣＰＵ）実行サイクルを解放するために望ましい。しかしながら、ＤＭＡの採用は、特定の特権ソフトウェアに限定される可能性があり、非常にデバイス固有のインタフェースを採用する入出力（Ｉ／Ｏ）使用ケースは、前向きの互換性（forward compatible）がない。加えて、制限により、ユーザモードアプリケーションの使用は、非仮想化環境では困難になり、マルチテナント仮想化環境では極めて困難になる。

【0002】

特定のアーキテクチャにおいて、入出力メモリ管理ユニット（ＩＯＭＭＵ）は、ルートコンプレックスを介してシステムファブリックにルーティングされるメモリトランザクションを処理する。複数のルートコンプレックスを有するシステムでは、別々のソフトウェア可視ＩＯＭＭＵが各ルートコンプレックスに必要とされる。特定のシステムでは、複数のスマートデータアクセラレータインタフェース（ＳＤＸＩ）エンジンが複数のソケットにわたって分散され、ＳＤＸＩエンジンは、複数のルートコンプレックスへのインタフェースを有し、マルチアドレス空間ＤＭＡ動作を実行することができる周辺コンポーネント相互接続エクスプレス（ＰＣＩｅ）エンドポイント等の周辺コンポーネントエンドポイントである。

【0003】

これらのシステムでは、ＳＤＸＩエンジンは、適切な保護及びアドレス変換を適用するために、ＤＭＡを正しいルートコンプレックスにルーティングするために、ケーブル又は相互接続を介して接続される可能性がある物理チャネル上で通信することを必要とする可能性がある。そのような通信は、余分なＩ／Ｏ帯域幅オーバーヘッドを必要とし、システムの全体的なＩ／Ｏ性能に影響を与える。したがって、ＳＤＸＩエンジン間の直接物理チャネルのコストなしに通信するＳＤＸＩエンジンが必要とされている。

【0004】

実施形態は、同様の符号が同様の要素を表す以下の図を伴う場合に、以下の説明を考慮してより容易に理解されるであろう。

【図面の簡単な説明】

【0005】

【図1】本開示の実施形態による、ＩＯＭＭＵを含むプラットフォームアーキテクチャの一例を示す図である。

【図2】本開示の実施形態による、ＩＯＭＭＵ及びＳＤＸＩエンジンを含むプラットフォームアーキテクチャの一例を示す図である。

【図3】本開示の実施形態による、複数のＩＯＭＭＵを含むプラットフォームアーキテクチャの一例を示す図である。

【図4】いくつかの実施形態による、図３のＭＭＩＯレジスタ更新フローのブロック図である。

【図5】いくつかの実施形態による、図３のＤＭＡ要求フローのブロック図である。

【図6】本開示の実施形態による、複数のアドレス空間の間のデータ移動を提供するための方法を示すフローチャートである。

【図7】本開示の実施形態による、ハイパーバイザと少なくとも１つの仮想マシンとの間のデータ移動を容易にするために複数のメモリアドレス空間をサポートするための方法を示すフローチャートである。

【図8】本開示の実施形態による、プラットフォームアーキテクチャ８００の別の例を示す図である。

【図9】いくつかの実施形態による、図８の割り込みトランザクションのブロック図である。

【図10】いくつかの実施形態による、図８の割り込みトランザクションのブロック図である。

【図11】いくつかの実施形態による、図８の割り込みレジスタのソフトウェアプログラミングのためのブロック図である。

【図12】いくつかの実施形態による、図８のＤＭＡ要求フローのブロック図である。

【図13】本開示の実施形態による、複数のアドレス空間の間のデータ移動を提供するための方法を示すフローチャートである。

【図14】本開示の実施形態による、データ移動を容易にするために複数のメモリアドレス空間をサポートするための方法を示すフローチャートである。

【発明を実施するための形態】

【0006】

当業者は、本開示の様々な実装及び実施形態が本明細書に従って実施され得ることを認識するであろう。これらの実装及び実施形態の全ては、本開示の範囲内に含まれることが意図されている。

【0007】

本明細書で使用される場合、用語「含む（comprises）」、「含んでいる（comprising）」、「有する（have）」、「有している（having）」、「含む（include）」、「含んでいる（including）」、又は、それらの任意の他の変形は、要素のリストを含むプロセス、方法、物品又は装置が、それらの要素のみを含むのではなく、明示的に列挙されていない又はそのようなプロセス、方法、物品又は装置に固有の他の要素を含み得るように、非排他的な包含をカバーすることが意図される。「例示的」という用語は、「理想的」ではなく「例」の意味で使用される。更に、「又は」という用語は、排他的な「又は」ではなく、包括的な「又は」を意味することが意図されている。すなわち、特に明記しない限り又はコンテキストから明らかでない限り、「ＸはＡ又はＢを用いる」という句は、全てのあり得る順列の何れかを意味することが意図される。例えば、「ＸはＡ又はＢを使用する」という句は、以下のインスタンスの何れかによって満たされる：ＸはＡを使用する、ＸはＢを使用する、又は、ＸはＡ及びＢの両方を使用する。加えて、本願及び添付の特許請求の範囲で使用される冠詞「一つの（a）」及び「一つの（an）」は、別段の指定がない限り又は単数形を対象とすることが文脈から明らかでない限り、一般に「１つ以上」を意味すると解釈されるべきである。

【0008】

簡潔にするために、方法を実施するために使用されるシステム及びサーバに関連する従来の技術、並びに、システム及びサーバ（並びにシステムの個々の動作構成要素）の他の機能的側面は、本明細書では詳細に説明されない場合がある。更に、本明細書に含まれる様々な図に示される接続線は、様々な要素間の例示的な機能的関係及び／又は物理的結合を表すことを意図している。多くの代替及び／又は追加の機能的関係又は物理的接続が、発明の実施形態に存在し得ることに留意されたい。

【0009】

ここで、本開示の例示的な実施形態を詳細に参照し、その例が添付の図面に示されている。可能な限り、同一又は同様の部分を指すために、図面全体を通して同一の符号が使用される。

【0010】

本開示は、概して、とりわけ、コンテキストに基づいて１つ以上のアドレス変換を提供するために、ＰＣＩｅバスアーキテクチャ等の周辺コンポーネントバスアーキテクチャと、周辺コンポーネントバスアーキテクチャ及びＩＯＭＭＵアーキテクチャをマルチコンテキストアウェアアーキテクチャに変えるＩＯＭＭＵアーキテクチャと、を仮想化する方法、システム及び装置に関する。各マルチコンテキストアウェアＩＯＭＭＵインスタンスは、異なるルートコンプレックスへのインタフェースを有することができるＳＤＸＩエンジン等のマルチインタフェースデバイス内の所定のインタフェースに対してアクセスチェック及びアドレス変換を実行することができる。これにより、少なくとも２つのＩＯＭＭＵインスタンスがコンテキスト情報を交換し、互いに代わって動作することが可能になる。ＳＤＸＩエンジンのグループ化は、機能グループと呼ばれる相互接続されたインスタンスの集合を含むことができる。更に、各ＩＯＭＭＵコンテキストが任意の他のコンテキストと同じようにプログラムされるという仮定がなされない。各ＩＯＭＭＵコンテキストの全ては、同じデータ構造（デバイステーブル、ページテーブル、リンガーバッファ等）を指してもよく、又は、アドレス空間識別子（ドメインＩＤ）等の符号化を再利用してもよい。更に、マルチコンテキストアウェアＩＯＭＭＵの変換ルックアサイドバッファ（ＴＬＢ）は、適切なコンテキスト識別子でタグ付けされるように拡張される。

【0011】

ＩＯＭＭＵは、周辺デバイスからのＤＭＡ転送に対するアドレス変換及びシステムメモリアクセス保護のサポートを追加することによって、システムアーキテクチャを拡張する。また、ＩＯＭＭＵは、周辺デバイスからの割り込みをフィルタリング及び再マッピングする。ＩＯＭＭＵは、システム内のＩ／Ｏデバイス、ＳＤＸＩエンジン、周辺コンポーネントデバイス及び／又はＰＣＩｅデバイス等の各周辺コンポーネントエンドポイントが特定のドメイン及びＩ／Ｏページテーブルの個別のセットに割り当てられることを可能にする保護ドメインの概念を拡張する。周辺コンポーネントエンドポイントがシステムメモリの読取り又は書込みを試みる場合、ＩＯＭＭＵはアクセスを傍受し、デバイスが割り当てられているドメインを決定し、そのドメインに関連付けられたＴＬＢエントリ又はその周辺コンポーネントエンドポイントに関連付けられたＩ／Ｏページテーブルを使用して、アクセスが許可されるべきかどうか、及び、アクセスされるべきシステムメモリ内の実際の位置を決定する。

【0012】

ＩＯＭＭＵは、リモートＩ／Ｏ変換ルックアサイドバッファ（ＩＯＴＬＢ：Translation Look-aside Buffer）に対するサポートを含むことができ、ＩＯＴＬＢは、例えば、ＰＣＩｅアドレス変換キャッシュ等の事前変換されたアドレスを保持する周辺デバイス内に配置されたバッファである。ＩＯＴＬＢサポートを有する信頼できる周辺コンポーネントは、ＩＯＭＭＵと協働して、それ自体のアドレス変換のキャッシュを維持することができ、これにより、周辺コンポーネントエンドポイントが異なる使用モデル及びワーキングセットサイズを有し得るＩＯＭＭＵを有するスケーラブルシステムを生成するためのフレームワークが生成される。

【0013】

ＩＯＭＭＵによって提供される主要なシステムリソースは、とりわけ、Ｉ／ＯＤＭＡアクセス許可チェック及びメモリベースの変換テーブルを使用するアドレス変換と、周辺コンポーネントエンドポイントが特定のドメインに割り当てられることを可能にし、周辺コンポーネントエンドポイントのページテーブルへのポインタを含むデバイステーブルである、ロングモードページテーブルフォーマットと互換性のあるゲスト変換テーブルのサポートと、ＩＯＭＭＵが周辺コンポーネントエンドポイント割り込みのための許可チェック及び割り込み再マッピングを提供するために使用する割り込み再マッピングテーブルと、ＩＯＭＭＵがゲストＶＭに割り込みを配信するために使用するゲスト仮想ＡＰＩＣ機構と、ＩＯＭＭＵと１つ以上のシステムプロセッサとの間でコマンド及びステータス情報を交換するためのメモリベースのキューと、周辺ページ要求（ＰＰＲ）ログのサポートと、ＰＰＲ及びイベントログオーバーフローを軽減するための特徴（features）と、特権周辺コンポーネントエンドポイントがシステムメモリの定義領域に直接アクセスすることを可能にするためのハードウェアベース機構のサポートと、を含む。

【0014】

特に、ＩＯＭＭＵは、中央処理装置（ＣＰＵ）によるメモリアクセスではなく、周辺コンポーネントエンドポイントによるＤＭＡのためのアドレス変換及びページ保護を提供する。更に、ＩＯＭＭＵは、未変換のポストされた要求を処理する場合に、失敗した変換の周辺コンポーネントエンドポイントに直接的な指示を提供しなくてもよい。ＩＯＭＭＵによってサポートされるシステムは、ＡＭＤＩｎｆｉｎｉｔｙＦａｂｒｉｃ、ＤａｔａＦａｂｒｉｃリンク又は他の手段等のデータファブリックによって互いに接続されたいくつかのプロセッサ及びデバイスノードから構成され得る。ＩＯＭＭＵは、システムファブリック内のそのノードを介してルーティングされるメモリトランザクションを処理することができる。周辺コンポーネントエンドポイントへの複数のリンク及びバスを有するシステムにおいて、複数のＩＯＭＭＵは、各Ｉ／Ｏリンク又はバスに適切な保護及び変換が適用されることを保証する。

【0015】

図１は、本開示の実施形態による、ＩＯＭＭＵを含むプラットフォームアーキテクチャの一例を示す図である。例示的なアーキテクチャ１００は、データ移動を容易にするために複数のアドレス空間をサポートするために提供される。図１に示すように、アーキテクチャ１００は、ＩＯＭＭＵ１０２と、ＳＤＸＩエンジン１０４等の周辺コンポーネントエンドポイントと、データファブリック１０６と、メモリデバイス１０８と、ＣＰＵ１１０と、を含む。ＩＯＭＭＵ１０２は、マルチコンテキストＩＯＭＭＵである。本発明で使用する場合、コンテキストは、カーネルが実行される環境と、同期及びメモリ管理が定義されるドメインと、を考慮している。コンテキストは、１組のＩＯＭＭＵＭＭＩＯレジスタと、メモリ内のページテーブルと、コマンドキュー等の様々なリングバッファと、を含む。コマンドキューは、ＩＯＭＭＵ変換ルックアサイドバッファ（ＴＬＢ）管理のために、すなわち、例えばページテーブル等の基礎となるメモリデータ構造の変化に起因してＴＬＢエントリを無効化すべきであることをＩＯＭＭＵに示すために使用することができる。ＩＯＭＭＵ１０２は、デバイスメモリアクセスのために仮想から物理アドレス変換を実行するロジックを含む。また、アーキテクチャ１００は、ＩＯＭＭＵ１０２とＣＰＵ１１０及び／又は他のＩＯＭＭＵとの間の通信を容易にするために、データファブリック１０６に結合されたＩ／Ｏスイッチ１１２を含んでもよい。また、Ｉ／Ｏスイッチ１１２は、ＩＯＭＭＵ１０２に組み込まれ得る。

【0016】

いくつかの実施形態では、ＩＯＭＭＵ１０２は、ＤＭＡポート１１４、ＭＭＩＯレジスタ１１６、変換索引バッファ（ＴＬＢ）１１８、作業待ち行列１２０、ページテーブルウォーカー１２２、イベントロガー１２４、コマンドプロセッサ１２６及びＰＰＲロガー１２８を含むか、それらへのアクセスを有する。Ｉ／Ｏスイッチ１１２、ＤＭＡポート１１４、ページテーブルウォーカー１２２、イベントロガー１２４、コマンドプロセッサ１２６及びＰＰＲロガー１２８は、相互接続１１５を介して互いに接続される。ページテーブルウォーカー１２２、イベントロガー１２４、コマンドプロセッサ１２６及びＰＰＲロガー１２８は、相互接続１１７を介して互いに接続される。

【0017】

ＤＭＡポート１１４は、既に変換されたＤＭＡトランザクションを容易にする。ＴＬＢ１１８は、一例として、コンテンツアドレス指定可能メモリ（ＣＡＭ）で実装されており、システムメモリ１０８内のデータの要求に対するロジック（すなわち、仮想）メモリアドレスの物理的メモリアドレスへの変換を加速する。作業待ち行列１２０は、制御及びステータス情報等の全ての関連するメモリデータ構造と共に、動作を実行するために使用される。デッドロックを回避するために、ＩＯＭＭＵは、ページテーブルウォーク要求のためにページテーブルウォーカー１１２を使用する。ＴＬＢミス時に、ページテーブルウォーカー１１２は、所望の仮想アドレスから物理アドレスへのマッピングを見つけるために、メモリ内ページテーブルをウォークする。変換は、ＴＬＢ階層でミスしたものがＩＯＭＭＵのページウォーク要求バッファにキューアップすることを要求する。ＩＯＭＭＵが任意の種類のイベントを検出すると、イベントロガー１２４は、システムメモリ内に位置するイベントログに適切なイベントエントリを書き込む。ホストソフトウェアは、ＩＯＭＭＵを制御し、コマンドをコマンドプロセッサ１２６に書き込む。次に、ＩＯＭＭＵは、コマンドを読み取り、それ自体のペースでそれらを実行する。

【0018】

各ＩＯＭＭＵ１０２は、ローカルＭＭＩＯレジスタ１１６ａ及びリモートコンテキストレジスタ１１６ｂを含むＭＭＩＯレジスタ１１６を含む。ローカルＭＭＩＯレジスタ１１６ａは、ドライバソフトウェアによって直接プログラムされ、ローカルコンテキストに対応する。リモートコンテキストＭＭＩＯレジスタ１１６ｂは、他の全てのＩＯＭＭＵインスタンスのＭＭＩＯレジスタのサブセットのシャドウコピーである。ＩＯＭＭＵは、他のＩＯＭＭＵのＭＭＩＯレジスタプログラミングを追跡して、ローカルＩＯＭＭＵに属さないメモリ構造にアクセスし、これにより、ＳＤＸＩエンジン要求が別のＩＯＭＭＵによって仮想的に変換されたように見えるようになる。ＩＯＭＭＵは、他のＩＯＭＭＵに関連付けられたデータ構造をキャッシュし、ドメインＩＤ及びＢＤＦ（登録商標）割り当て等の異なるＩＯＭＭＵコンテキストへのＳＤＸＩエンジントラフィックによって共有されないデータ構造がコンテキスト固有であることを保証することができる。

【0019】

各ＩＯＭＭＵには、ローカルコンテキストＤＭＡを変換するためのローカルコンテキストＭＭＩＯレジスタ１１６ａが設けられている。各ＩＯＭＭＵには、非ローカルコンテキストからＤＭＡを変換するためのリモートコンテキストＭＭＩＯレジスタ１１６ｂも設けられる。各ＩＯＭＭＵは、他の各ＩＯＭＭＵ内のローカルコンテキストＭＭＩＯレジスタに対応するリモートコンテキストＭＭＩＯレジスタ１１６ｂのバージョンを維持する。各ＩＯＭＭＵは、他の各ＩＯＭＭＵに対応するこれらのレジスタのバージョンを維持する。非ＭＭＩＯレジスタは、ＩＯＭＭＵコンテキストにわたって同一にプログラムされ、したがって、コンテキストごとにシャドウ化されない。

【0020】

ＩＯＭＭＵメッセージは、以下で説明するように、適用可能なＭＭＩＯレジスタが書き込まれた場合に、他のＩＯＭＭＵインスタンス内の全てのリモートコンテキストＭＭＩＯレジスタ１１６ｂを自動的に更新するために使用される。例えば、本開示のいくつかの実施形態では、合計２２×３２ビットレジスタがシャドウ化され、ＩＯＭＭＵデバイステーブルベースアドレスレジスタメッセージ及びＩＯＭＭＵ除外ベースレジスタメッセージ等のＩＯＭＭＵＭＭＩＯメッセージタイプが、全てのＭＭＩＯレジスタ１１６を自動的に更新する場合に使用される。

【0021】

他のＩＯＭＭＵに対応するレジスタを維持するＭＭＩＯレジスタ１１６は、システム内の全てのＩＯＭＭＵに対するマルチコンテキストＩＯＭＭＵサポートをイネーブルにする前に書き込まれない。両方のＩＯＭＭＵＭＭＩＯメッセージタイプは、初期値がレジスタ構成可能であり、３２等の所定の値にデフォルトであり得るＭＭＩＯメッセージクレジットを必要とする。スレーブＩＯＭＭＵは、レジスタ更新を肯定応答するためにＩＯＭＭＵメッセージのＭＭＩＯクレジットフィールドを使用する。全てのＭＭＩＯレジスタ１１６は、他のＩＯＭＭＵインスタンスから独立してプログラムされる。更に、例えば、ＳＤＸＩエンジンは、ＳＤＸＩエンジンが物理的に接続されているＩＯＭＭＵインスタンスに対してイネーブル／ディスエーブル用のＩＯＭＭＵレジスタがディスエーブルされている場合であっても、そのレジスタが設定されているＩＯＭＭＵインスタンスを仮想的に対象とすることができる。

【0022】

ＩＯＭＭＵの各々のＭＭＩＯレジスタ１１６は、ＩＯＭＭＵが特定のコンテキストに対してイネーブル／ディスエーブルであるかどうかのレジスタ、特定のコンテキストへのＳＤＸＩアクセスによってトリガされたイベントログがコンテキスト所有ＩＯＭＭＵに転送されるかどうかを制御するレジスタ、特定のＩＯＭＭＵコンテキストに関連付けられたテーブルウォークアクセスがコヒーレントでなければならないかどうかのレジスタ、ＰＰＲｓメッセージがＩＯＭＭＵコンテキスト所有者に転送され得るかどうかのレジスタ、特定のＩＯＭＭＵコンテキストがゲスト変換をサポートするかどうかのレジスタ、特定のＩＯＭＭＵコンテキストがＡＶＩＣをサポートするかどうかのレジスタ、及び、特定のコンテキストへのＳＤＸＩエンジンＡＶＩＣ割り込みによってトリガされたＧＡログがコンテキスト所有ＩＯＭＭＵに転送されるかどうかを制御するレジスタを含む。

【0023】

また、ＩＯＭＭＵの各々に対するＭＭＩＯレジスタ１１６は、特定のＩＯＭＭＵコンテキストによってサポートされるＤＴＥセグメントの数を指定し、デバイスストリームＩＤの何れのビットがＤＴＥテーブルにインデックスを付けるために使用されるかを決定するためのレジスタを含み、拡張ページ要求インタフェース（ＰＲＩ）を指定するための特定のＩＯＭＭＵコンテキストレジスタに対するユーザのみの許可を有するゲストアクセスを指定するためのレジスタは、特定のＩＯＭＭＵコンテキストに対してイネーブルにされ、ＳＤＸＩエンジンＤＴＥが構成されている場合、特定のＩＯＭＭＵはＰＲＩをアボートすることができ、ＩＯＭＭＵはイベントログをコンテキスト所有ＩＯＭＭＵに適用可能に転送する。

【0024】

ＩＯＭＭＵの各々に対するＭＭＩＯレジスタ１１６は、ゲストダーティが特定のＩＯＭＭＵコンテキストに対してビットイネーブルにされているかどうか、Ｘ２ＡＰＩＣサポートが特定のＩＯＭＭＵコンテキストに対してイネーブルにされているかどうか、ＩＯＭＭＵ仮想化が特定のＩＯＭＭＵコンテキストの下でデバイスによって使用され得るかどうか、ゲストアクセスビットサポートが特定のＩＯＭＭＵコンテキストに対してイネーブルにされているかどうか、及び、ＡＶＩＣＧＡＰＰＩが特定のＩＯＭＭＵコンテキストに対してイネーブルにされているかどうかを指定するためのレジスタを更に含む。

【0025】

ＭＭＩＯレジスタ１１６のＭＭＩＯ制御及びステータスレジスタは、第１レベルデバイステーブルのバイト整列ベースアドレスのビットを指定するデバイステーブルベースアドレス用のレジスタであるＩＯＭＭＵデバイステーブルベースアドレスレジスタと、デバイステーブルのサイズを指定する値を含むデバイステーブルのサイズ用のレジスタと、を含む。デバイステーブルセグメント化がサポートされていないか又はイネーブルにされていない場合、このレジスタは、単一の統合されたデバイステーブルのベースアドレスを確立する。デバイステーブルセグメント化がサポートされ、イネーブルにされる場合、レジスタは、デバイステーブルのセグメント０のベースアドレスレジスタとして働く。

【0026】

ＭＭＩＯレジスタ１１６のＭＭＩＯ制御及びステータスレジスタは、ＩＯＭＭＵ除外範囲のベースデバイス仮想アドレスを指定するためのＩＯＭＭＵ除外ベースレジスタを含む。除外範囲内のアドレスをターゲットとするデバイスアクセスは、デバイステーブル内のビットがデバイスに対して設定されている場合、又は、許可ビットがこのレジスタに設定されている場合、変換もアクセスチェックもされない。除外範囲テストは、有効な所定のプレフィックスを提示するデバイストランザクションには適用されない。いくつかの実施形態において、ＭＭＩＯレジスタ１１６のＭＭＩＯ制御及びステータスレジスタは、ＩＯＭＭＵ除外範囲の限界を指定するためのＩＯＭＭＵ除外範囲制限レジスタを含む。

【0027】

上述したように、ＩＯＭＭＵメッセージは、適用可能なＭＭＩＯレジスタ１１６が書き込まれた場合に、他のＩＯＭＭＵインスタンス内の全てのＭＭＩＯレジスタ１１６を自動的に更新するために使用される。例えば、ＩＯＭＭＵデバイステーブルベースアドレスレジスタメッセージは、所定のフォーマットであり、適用可能なレジスタ内の何れかのフィールドが変更された場合にＩＯＭＭＵが送信するＩＯＭＭＵデバイステーブルベースアドレスレジスタを含む。ＩＯＭＭＵ除外ベースレジスタメッセージは、所定のフォーマットであり、ＭＭＩＯ除外ベースレジスタとＩＯＭＭＵ除外範囲制限レジスタとを含み、適用可能なレジスタ内の何れかのフィールドが変更された場合にＩＯＭＭＵがこれらを送信する。

【0028】

ＩＯＭＭＵ１０２のマルチＩＯＭＭＵ同期ロジック１５０は、ＩＯＭＭＵメッセージの処理、ＭＭＩＯレジスタ１１６の同期、及び、ＩＯＭＭＵのコンテキスト復号を容易にする。マルチＩＯＭＭＵ同期ロジック１５０は、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタを同期させ、ダイレクトメモリアクセス（ＤＭＡ）要求を受信し、ＤＭＡ要求のコンテキストデータに基づいてＩＯＭＭＵの複数のＭＭＩＯレジスタにアクセスし、メモリアドレス空間に割り当てられた仮想及び／又は物理機能のアクセスを支援する等の動作を行うハードウェア制御ロジックである。

【0029】

本開示の実施形態では、特定の周辺コンポーネントエンドポイントであるＳＤＸＩエンジン１０４は、ホストシステム上の少なくとも２つの個別のアドレスドメイン間のデータの低レイテンシ及び高帯域幅転送を容易にするソフトウェア及びハードウェアソリューションである。図２は、本開示の実施形態による、ＩＯＭＭＵ及びＳＤＸＩエンジンを含むプラットフォームアーキテクチャ２００の一例を示す図である。ＤＭＡエンジン２４０Ａ及び２４０Ｂをそれぞれ含むＳＤＸＩエンジン２０４Ａ及び２０４Ｂは、単一ルートＩ／Ｏ仮想化物理機能（ＳＲ－ＩＯＶＰＦ）及び複数の単一ルートＩ／Ｏ仮想機能（ＳＲ－ＩＯＶＶＦ）を通してソフトウェアにさらされ、その各々は、メモリデバイス２０８内の異なるアドレスドメイン、及び、これらの機能間でデータを移動させる能力にマッピングされ得る。ＳＤＸＩエンジン２０４Ａ及び２０４Ｂは、ハイパーバイザ（ＨＶ）及びＣＰＵリソースをオフロードし、少なくとも２つのゲストオペレーティングシステム（ＯＳ）又はゲストＯＳとＨＶとの間のデータ転送を維持するために必要なソフトウェアスタックの複雑さを低減する。

【0030】

帯域幅要件を満たすために、ＳＤＸＩエンジン２０４Ａ及び２０４Ｂは、個別のＩＯＭＭＵ２０２Ａ及び２０２Ｂと統合され、データファブリック２０６のデータファブリック経路は、システムメモリ２０８に統合される。例えば、システムでは、ソケットごとに４つのＳＤＸＩエンジンが存在し、４つのソケット能力を有し、したがって、システム内に最大１６個のＳＤＸＩエンジンが存在し得る。ソフトウェアオーバーヘッドを低減し、ソフトウェアからのシステムレベル実装を不明瞭にするために、仮想マシン（ＶＭ）及びＨＶは、ＳＤＸＩエンジンのための複数のデバイステーブルエントリ（ＤＴＥ）を維持することを回避する。各ＳＤＸＩエンジンは、物理機能（ＰＦ）及び複数のＶＦを有するが、各ＶＭは、１つのＶＦにアタッチする必要があるだけであり、いくつのＳＤＸＩエンジンインスタンスがシステム上に存在するかにかかわらず、全てのＳＤＸＩエンジンインスタンスを利用して、任意の他のＳＤＸＩエンジンＰＦ／ＶＦ間のデータ転送を容易にすることができる。したがって、システムは、本開示の実施形態で説明されるように、１つのＩＯＭＭＵインスタンスの下のＩ／Ｏデバイスが、別のＩＯＭＭＵインスタンスに仮想的に接続されているように見えることを可能にする。

【0031】

マルチコンテキストＩＯＭＭＵ機能の使用をイネーブルにする場合、各ＩＯＭＭＵインスタンスは、一意のコンテキストＩＤに割り当てられる。ＳＤＸＩエンジンは、機能グループ内の全てのＳＤＸＩエンジン上のＰＦ及びＶＦ等の全ての機能のセットのうち何れの機能がＤＭＡ要求を生成しているかを示す。ＤＭＡ要求を受信するＩＯＭＭＵは、これらの指標を使用して、ＤＭＡ要求を変換するために何れのＩＯＭＭＵコンテキストを使用するかを決定する。機能番号は、標準的なリクエスタＩＤ（バス／デバイス／機能）を使用して、例えばＰＣＩｅバス等のバスを介して通信され得る。また、追加の機能識別情報は、セグメントＩＤ等のバスを介して又は独自の手段を介して通信することができる。指標が設定されていない場合、要求は、コンテキストがＩＯＭＭＵの一意のコンテキストＩＤにプログラムされているかのように処理され、デバイスはＩＯＭＭＵに物理的に接続される。

【0032】

各ＳＤＸＩエンジンは、識別子フィールドで符号化された複数のＶＦにまたがる。バスデバイス機能（ＢＤＦ（登録商標））割り当ては、ＩＯＭＭＵコンテキストに関連しており、したがって、ＮＢＩＦ二次／従属バス番号等のハブ番号に基づいて導出されるＳＤＸＩエンジンバス番号範囲もコンテキスト固有である。ＩＯＭＭＵコンテキストにわたって、ＢＤＦ（登録商標）割り当ては、異なるデバイス間で重複する可能性があり、これらのデバイスは、必ずしもメモリページを共有せず、異なるＤＴＥを有する。

【0033】

いくつかの要求は、イベントログ、ゲストＡｖｉｃ（ＧＡ）ログ、及び、周辺ページ要求（ＰＰＲ）ログ等のＩＯＭＭＵ制御メモリデータ構造への書込みを必要とする。ＩＯＭＭＵは、ＩＯＭＭＵメッセージを通じて適切なログを仮想ターゲットＩＯＭＭＵに転送する。ＳＤＸＩエンジンは、下流向き要求のターゲットとすることができ、これらの要求は、後述するように、ＩＯＭＭＵによって生成された周辺ページ要求（ＰＰＲ）応答及びＩ／Ｏ変換ルックアサイドバッファ（ＩＯＴＬＢ）無効化メッセージを含む。

【0034】

各ＩＯＭＭＵは、ＩＯＭＭＵマルチコンテキスト機能のイネーブル／初期化、特定の要求タイプを処理し、対応するＩＯＭＭＵからのメッセージを送受信するように構成される。ＳＤＸＩ初期化のために、ＩＯＭＭＵは、ローカルＩＯＭＭＵのコンテキストＩＤを符号化する初期化レジスタと、対応するＩＯＭＭＵインスタンスのコンテキストＩＤを符号化する複数の他の初期化レジスタと、を定義する。他の初期化レジスタは、特定のコンテキストに割り当てられた他のＩＯＭＭＵのステータス及び位置を符号化する。両方の初期化レジスタは、ＩＯＭＭＵがイネーブルにされ、ＳＤＸＩエンジンがクロスコンテキスト要求の送信を開始する前にプログラムされる。

【0035】

各ＩＯＭＭＵの初期化レジスタは、ローカルＩＯＭＭＵ内のマルチコンテキストアウェアを可能にするレジスタと、ローカルＩＯＭＭＵインスタンスのコンテキストＩＤの値を含むレジスタと、システム内のＩＯＭＭＵコンテキストの総数を含むレジスタと、を含む。また、各ＩＯＭＭＵ初期化レジスタは、システム内の各ＩＯＭＭＵコンテキストのためのＩＯＭＭＵコンテキスト識別子制御レジスタを含む。ＩＯＭＭＵコンテキスト識別子制御レジスタは、他のＩＯＭＭＵがマルチコンテキストアウェアであるか否かを識別するレジスタと、マルチコンテキストアウェアである他のＩＯＭＭＵに関連付けられた周辺コンポーネントエンドポイントセグメント識別子と、マルチコンテキストアウェアである他のＩＯＭＭＵに関連付けられたバス番号と、を含む。ＩＯＭＭＵコンテキスト識別子制御レジスタは、ホストシステム内の全てのＩＯＭＭＵインスタンスにわたって同じようにプログラムされる。更に、ＩＯＭＭＵコンテキスト識別子制御レジスタのうち何れかは、ローカルＩＯＭＭＵに対応し、ローカルＩＯＭＭＵのバス及びセグメントＩＤを符号化する。

【0036】

また、各ＩＯＭＭＵは、バッファ粒度ごとにＩＯＭＭＵに利用可能なデフォルト数のクレジットをオーバーライドする構成レジスタを含む。例えば、システムは、必要に応じて各タイプの１つの未処理メッセージのみを許可するように、又は、タイプごとにすなわち１つの未処理ＭＭＩＯレジスタ更新メッセージのみを許可するように構成することができる。利用可能なクレジットの数はブート中にプログラムされ、上述したように、マルチコンテキストサポートがイネーブルにされる前又は後にプログラムすることができる。

【0037】

利用可能なクレジットの数は、システム内のＳＤＸＩエンジンの数に依存し得る。例えば、１６個未満のコンテキストがサポートされる場合、利用可能なクレジットの数は、１ソケットシステム等においてスケーリングすることができ、ＩＯＭＭＵコンテキストごとのクレジットの数は、３２ではなく１６０に増加することができる。各ＩＯＭＭＵの構成レジスタは、サポートされる未処理のＰＰＲログメッセージの総数、サポートされる未処理のイベントログメッセージの総数、サポートされる未処理のコマンドプロセッサの総数、サポートされる未処理のＧＡログメッセージの総数、及び、サポートされる未処理のＭＭＩＯレジスタ更新メッセージの総数を含む。

【0038】

異なるＩＯＭＭＵの下で物理的にＳＤＸＩエンジンにサービスを提供するが、ＰＰＲＬｏｇ、ＧＡＬｏｇ、ＥＬＬｏｇ、コマンドプロセッサ等のＩＯＭＭＵの共有データ構造にアクセスすることをサポートし、ＩＯＭＭＵインスタンスにわたってＭＭＩＯレジスタプログラミングを同期させるために、ＩＯＭＭＵメッセージを使用して、マルチＩＯＭＭＵ同期ロジック１５０を介してＩＯＭＭＵ間でデータを転送する。ＩＯＭＭＵメッセージは、ＲｏｕｔｅＢｙＩＤ復号を用いて送信され、他のＩＯＭＭＵのみをターゲットとすることが予想される。

【0039】

ＩＯＭＭＵメッセージは、ＩＯＭＭＵのバスデバイス機能に基づいて、他のＩＯＭＭＵの対応するＩ／Ｏスイッチを介して、ＩＯＭＭＵからＩ／Ｏスイッチ１１２を介してデータファブリックに転送され、データファブリックから他のＩＯＭＭＵに転送され得る。ＩＯＭＭＵによって生成されたＩＯＭＭＵメッセージは、所定のフォーマットを有し、そのままデータファブリックに送信され得る。他のＩＯＭＭＵによってデータファブリックから受信されたメッセージは、必要に応じて、ＩＯＭＭＵ、マルチＩＯＭＭＵ同期ロジック１５０に転送される前に、他の所定のフォーマットに変換され得る。

【0040】

各ＩＯＭＭＵは、同じサイクルで処理することができない他のＩＯＭＭＵからのデータを受け入れるために、ＩＯＭＭＵインスタンスごとに所定量のバッファを実装する。これらのデータタイプは、ＰＰＲログ、イベントログ及びＧＡログ、並びに、コマンドプロセッサコマンドバッファのためのものである。各エントリは所定数のビットとすることができ、各バッファは所定量までのエントリを記憶することができる。上述のクレジット方式は、使用されたクレジット及び利用可能なクレジットを追跡するために使用される。クレジットは、クレジットタイプごとに個別のフィールドを有するＩＯＭＭＵメッセージを介して解放される。ＩＯＭＭＵは、リセット後に他の各ＩＯＭＭＵバッファに対して所定数のクレジットを有する。レジスタオーバーライドは、デバッグ目的のために提供されることができ、より少ない最大数のＳＤＸＩエンジンがサポートされながら、より大きいデータが転送されることを可能にする。

【0041】

ＩＯＭＭＵは、データからのメッセージコード及びフィールドを使用して、受信されたＩＯＭＭＵメッセージが所定のＩＯＭＭＵメッセージフォーマットであることを確認する。所定のＩＯＭＭＵメッセージフォーマットでないメッセージは、サポートされなくてもよく、アボートされ得る。例えば、ＩＯＭＭＵメッセージは、５１２ビットの最小データサイズであってもよく、最初の２５６ビットのデータは、カプセル化された周辺コンポーネントメッセージフィールドを含み、２番目の２５６ビットは、ＩＯＭＭＵ固有フィールドを含む。最初の５１２ビットの後のデータペイロードは、１２８ビット整列され、ＩＯＭＭＵメッセージタイプデータとして扱われる。

【0042】

ＩＯＭＭＵメッセージは、ＩＯＭＭＵインスタンスＩＤ、クレジット解放等のメッセージタイプ、イベントログタイプ、ＰＰＲタイプ、コマンドプロセッサタイプ、ＧＡログタイプ、ＭＭＩＯ制御及びステータスレジスタ更新、ＩＯＭＭＵ除外ベースレジスタ更新、並びに、ＳＤＸＩエラーのためのフィールドを含む。また、ＩＯＭＭＵメッセージは、ＳＤＸＩ物理機能のバス番号のためのフィールドを含む。例えば、ＩＯＭＭＵは、ＳＤＸＩバス番号を記憶し、それを使用して自動ＰＰＲ応答及びＰＰＲ応答をＳＤＸＩエンジンに直接ルーティングする。また、ＩＯＭＭＵメッセージは、以下に説明するように、ＩＯＭＭＵデバイステーブルベースアドレスレジスタメッセージ及びＩＯＭＭＵ除外ベースレジスタメッセージ等のＩＯＭＭＵＭＭＩＯメッセージタイプのフィールドクレジット、スレーブＩＯＭＭＵにリリースバックされるＰＰＲクレジットのフィールド、スレーブＩＯＭＭＵにリリースバックされるイベントログクレジットのフィールド、マスタＩＯＭＭＵにリリースバックされるコマンドプロセッサクレジットのフィールド、スレーブＩＯＭＭＵにリリースバックされるＧＡログクレジットのフィールド、マスタＩＯＭＭＵがＳＤＸＩエンジンデバイス識別子及び機能識別子を記憶し、それを使用して自動ＰＰＲ応答及びＰＰＲ応答をＳＤＸＩエンジン物理デバイス及び機能に直接ルーティングするＳＤＸＩエンジンの物理デバイス番号及び機能番号のフィールド、並びに、対応するメッセージタイプのＳＤＸＩメッセージペイロードのフィールドを含む。

【0043】

図３は、本開示の実施形態による、複数のＩＯＭＭＵを含むプラットフォームアーキテクチャの一例を示す図である。例示的なアーキテクチャ３００は、データ移動を容易にするために複数のアドレス空間をサポートするために提供される。図３に示すように、アーキテクチャ３００は、ＩＯＭＭＵ３０２Ａ及び３０２Ｂと、ＳＤＸＩエンジン３０４Ａ及び３０４Ｂ等の周辺コンポーネントエンドポイントと、データファブリック３０６と、メモリデバイス３０８と、ＣＰＵ３１０と、を含む。ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、マルチコンテキストＩＯＭＭＵである。ＩＯＭＭＵ３０２Ａ及び３０２Ｂの各々は、デバイスのメモリページアクセスのために仮想から物理アドレス変換を実行するロジックを含む。また、アーキテクチャ３００は、ＩＯＭＭＵ３０２Ａ及び３０２ＢとＣＰＵ３１０との間の通信を容易にするために、データファブリック３０６に結合されたＩ／Ｏスイッチ３１２Ａ及び３１２Ｂを含んでもよい。Ｉ／Ｏスイッチ３１２Ａ及び３１２Ｂは、それぞれＩＯＭＭＵ３０２Ａ及び３０２Ｂに組み込むこともできる。

【0044】

いくつかの実施形態では、ＩＯＭＭＵ３０２Ａ及び３０２Ｂの各々は、ＤＭＡポート３１４と、ローカルＭＭＩＯレジスタ３１６等のローカルＭＭＩＯレジスタ及びリモートコンテキストＭＭＩＯレジスタ１１６ｂ等のリモートコンテキストＭＭＩＯレジスタを含むＭＭＩＯレジスタ１１６ａと、変換ルックアサイドバッファ（ＴＬＢ）３１８と、作業待ち行列３２０と、ページテーブルウォーカー３２２と、イベントロガー３２４と、コマンドプロセッサ３２６と、ＰＰＲロガー３２８と、を含むか、それらにアクセスする。Ｉ／Ｏスイッチ３１２Ａ／３１２Ｂ、ＤＭＡポート３１４、ページテーブルウォーカー３２２、イベントロガー３２４、コマンドプロセッサ３２６及びＰＰＲロガー３２８は、相互接続３１５を介して互いに接続される。ページテーブルウォーカー３２２、イベントロガー３２４、コマンドプロセッサ３２６及びＰＰＲロガー３２８は、相互接続３１７を介して互いに接続される。

【0045】

ＩＯＭＭＵ３０２Ａ及び３０２Ｂのうち１つ以上は、非ローカルＩＯＭＭＵコンテキストに属するＩＯＭＭＵによる変換を必要とするＤＭＡ要求をそれぞれのＳＤＸＩエンジン３０４Ａ及び３０４Ｂから受信してもよい。これらの要求は、ｓＡＴＳ及び非ｓＡＴＳモードで動作する、ＤＭＡ未変換、ＤＭＡ変換又はＤＭＡ事前変換タイプのものである。

【0046】

ＳＤＸＩエンジン３０４Ａ及び３０４Ｂは、固定及びアービトレートされた再マップ可能割り込み、並びに、他の割り込みを送信することができる。ＳＤＸＩエンジン３０４Ａ及び３０４Ｂは、図３に示すように、機能グループ３７５と呼ばれる相互接続されたインスタンスの集合を含むことができるＳＤＸＩエンジンのグループ化であってもよい。ＩＯＭＭＵは、要求されたＩＯＭＭＵコンテキストからのＤＴＥ及びＩＲＴＥ構造を使用して割り込みを処理する。ＡＶＩＣがイネーブルにされている場合、ＩＯＭＭＵは、ＧＡログの生成を必要とする可能性があり、これらは、新しいＩＯＭＭＵＶＤＭサポートを介して、ＧＡログバッファ内のシリアル化された記憶のためにＩＯＭＭＵコンテキスト所有者に転送される。

【0047】

ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、それ自身のＩＯＭＭＵコンテキストに関連付けられたイベントログを維持し、他のＩＯＭＭＵからのイベントログがそのコンテキストに適用可能である場合、それらを受け入れる。同様に、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、コンテキストがイベントログをサポートする場合、適用可能なようにイベントログをＩＯＭＭＵコンテキストオーナーに転送する。ＩＯＭＭＵメッセージは、ＩＯＭＭＵ３０２Ａ及び３０２Ｂにわたってイベントログを転送するために使用される。ＩＯＭＭＵマスタは、イベントログメッセージタイプを有するメッセージを受信すると、メッセージペイロードを有するイベントログバッファに直接書き込む。ＩＯＭＭＵスレーブは、ソフトウェア可視イベントログバッファにプッシュされるように、正しいイベントログフィールドを有するペイロードをフォーマットする。

【0048】

ＳＤＸＩエンジン３０４Ａ及び３０４Ｂは、異なるＩＯＭＭＵインスタンスを仮想的にターゲットとするコンテキストに適用可能なＰＰＲをＩＯＭＭＵ３０２Ａ及び３０２Ｂにそれぞれ発行することができる。拡張ＰＲＩがサポートされている場合、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、ＤＴＥをフェッチし、メッセージを介してＰＰＲ要求をＩＯＭＭＵコンテキストマスタに転送する前に、適用可能なチェックを実行する。拡張ＰＲＩ機能がサポートされていない場合、ＤＴＥはフェッチされないが、要求は依然として転送される。ＩＯＭＭＵ３０２Ａ及び３０２Ｂがメッセージを介してＰＰＲログを受信すると、これは、このＩＯＭＭＵのコンテキストを仮想的にターゲットとするが、異なるＩＯＭＭＵの下に物理的に配置されたＰＰＲ要求に対応する。ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、ソフトウェアによるサービスのために、これらを関連するＰＰＲバッファに記録する。

【0049】

拡張ＰＲＩサポートがイネーブルにされている場合、ＰＰＲは、ＩＯＭＭＵマスタによって受信された場合に、ＤＴＥの再フェッチを含む追加の処理を必要とする。性能強化として、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、ＰＰＲコマンドに付加され、ＩＯＭＭＵスレーブによって設定され、必要とされない場合にＤＴＥをフェッチすることを回避するためにＩＯＭＭＵマスタによって使用されるＤＴＥ＿ＩＧＮＯＲＥビットを実装することができる。

【0050】

ＰＰＲ自動応答メッセージ、及び、コマンドバッファからフェッチされた通常のＰＰＲ応答メッセージは、正しいＳＤＸＩエンジン３０４Ａ／３０４Ｂリクエスタに直接転送される。これを容易にするために、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、発行ＳＤＸＩエンジン３０４Ａ／３０４ＢのＩＯＭＭＵコンテキストをＰＰＲページ要求グループインデックスフィールドの最上位ビットに符号化する。これは、システム上でサポートされるＩＯＭＭＵコンテキストの数に依存して、ＳＤＸＩエンジン３０４Ａ／３０４Ｂに利用可能なＰＰＲインデックスグループの数を制限する。ＩＯＭＭＵの下にないＳＤＸＩエンジン３０４Ａ／３０４ＢをターゲットとするＰＰＲ自動応答メッセージは、所定のメッセージフォーマットでデータファブリックを介して送信される。ＳＤＸＩエンジン３０４Ａ／３０４ＢのターゲットバスＩＤ及び物理デバイス機能は、元のＰＰＲ要求のメッセージから記憶され、全てのＰＰＲ応答がこの宛先に転送される。ＳＤＸＩエンジン３０４Ａ／３０４Ｂは、グループインデックスフィールドを使用して、ＰＲＧ応答をＰＰＲ要求にマッピングする。

【0051】

上述したように、各ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、そのコンテキストに関連付けられたＩＯＭＭＵデータ構造を無効化するために使用されるコマンドプロセッサ３２６を含む。各ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、ＩＯＭＭＵメッセージフォーマットを用いてコマンドアクションテーブルに記述されているようにコマンドを他のＩＯＭＭＵに転送する。コマンドは、ＨＶコマンドキュー又はＩＯＭＭＵコマンドキューの何れかから生じ得る。

【0052】

ＩＯＭＭＵメッセージを介してコマンドを受信するＩＯＭＭＵ３０２Ａ及び３０２Ｂは、同じコンテキストからのコマンドに対してシリアルにコマンドをサービスする。デッドロックを防止するために、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、異なるコンテキストからのコマンドを並列に処理することができる。ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、いくつかのＩＯＭＭＵインスタンスに対するコマンドプロセッサクレジットが不足している場合、自身のコンテキスト上でコマンドの処理を停止することができるが、他のＩＯＭＭＵコンテキストからのコマンドを処理することができなければならない。

【0053】

ＩＯＭＭＵコマンドプロセッサを介して受信された完了待ちコマンドが、ＩＯＭＭＵメッセージを用いて他の全てのＩＯＭＭＵに転送されると、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、全てのコマンドプロセッサクレジットが返されるまで、より多くのコマンドの発行を停止することができる。また、ＩＯＭＭＵ３０２Ａ及び３０２Ｂは、完了待ちライトバック又は割り込みを実行する前に、同期機構として全てのクレジットを待つことができる。

【0054】

【表1】

【0055】

ＩＯＭＭＵ３０２Ａ及び３０２Ｂのマスタコマンドプロセッサ３２６は、ＡＴＳがイネーブルにされている場合、それぞれＳＤＸＩエンジン３０４Ａ及び３０４ＢのＡＴキャッシュをフラッシュアウトするために使用され得る。ＳＤＸＩＩＯＴＬＢキャッシュを無効にするために、ＩＯＴＬＢ無効化コマンドがＩＯＭＭＵコマンドプロセッサ３２６にプッシュされ、その後に完了待ちコマンドが続く。ＩＯＭＭＵは、ＳＤＸＩＳＲ－ＩＯＶ範囲を対象とするコマンドプロセッサ３２６からの任意のＩＯＴＬＢ無効化をフィルタリングしてドロップし、次いで、ＩＯＭＭＵは、ＳＤＸＩエンジン物理デバイス機能のアドレス空間全体を無効化する単一の内部ＩＯＴＬＢを生成する。ＩＯＭＭＵは、最後に実行された完了待ちコマンド以降にＳＤＸＩターゲットＩＯＴＬＢ無効化を受信しない限り、ＳＤＸＩエンジンに内部ＩＯＴＬＢ無効化を発行しない。任意のＩＯＴＬＢ無効化コマンドを受信すると、ＳＤＸＩエンジンは、全てのＩＯＭＭＵコンテキスト及び仮想／物理機能にわたって、全ての内部に記憶された変換データをクリアした後に、ＩＯＴＬＢに肯定応答する。ＩＯＭＭＵは、ＩＯＭＭＵメッセージを介してスレーブＩＯＭＭＵコンテキストに転送される完了待ちコマンドのためのフィールドを設定する。ＩＯＭＭＵスレーブコンテキストが、フィールドが設定された完了待ちを受信した場合、ＩＯＭＭＵは、内部ＩＯＴＬＢをＳＤＸＩエンジンに発行する。

【0056】

図４は、いくつかの実施形態による、図３のＭＭＩＯレジスタ更新フローのブロック図である。図４に示されるように、ソフトウェアは、長い破線によって示されるような構成及び初期化経路を使用して、ＩＯＭＭＵ３０２Ｂ内のローカルコンテキストを直接プログラムする。ＩＯＭＭＵ３０２Ｂは、ＩＯＭＭＵメッセージを使用して、ＩＯＭＭＵ３０２Ａ等の他の全てのＩＯＭＭＵにローカルレジスタをマルチキャストする。

【0057】

図５は、いくつかの実施形態による、図３のＤＭＡ要求フローのブロック図である。図５に示されるように、ＳＤＸＩエンジン３０４Ａのクロスコンテキスト要求発行装置３５５からの各ＤＭＡ要求は、ＩＯＭＭＵコンテキスト識別子を搬送し、ＩＯＭＭＵ３０２ＡのマルチＩＯＭＭＵ同期ロジック３５０によって、ＤＭＡ要求を変換するために何れのＩＯＭＭＵコンテキストを使用するかを識別するために使用される。各ＩＯＭＭＵコンテキストは、独立してプログラムされることが可能であり、ドメインＩＤ等のための異なるデータ構造又は再使用符号化を指すことが可能である。ＴＬＢは、一致するコンテキストの変換を検索するために、コンテキスト識別子で更にタグ付けされる。ＭＭＩＯレジスタ３１６のコンテキストレジスタは、着信コンテキスト識別子に基づいて使用される。コンテキストレジスタは、リモートＩＯＭＭＵコンテキストを使用して変換される各コンテキストＤＭＡアクセスがローカルＩＯＭＭＵコンテキストの物理ＤＭＡポートを介して依然として発生するため、ソフトウェアによって独立してプログラムされ得るデバイステーブル等のデータ構造を指す。

【0058】

図６は、本開示の実施形態による、複数のアドレス空間の間のデータ移動を提供するための方法を示すフローチャートである。動作は、任意の適切な順序で実行されてもよい。図６に示すように、方法６００は、ＩＯＭＭＵ３０２Ａ及び３０２ＢのマルチＩＯＭＭＵ同期ロジック３５０等によって、複数のＩＯＭＭＵのうち別のＩＯＭＭＵのコンテキストデータを記憶するステップ６０２を含む。ＩＯＭＭＵ３０２Ａ及び３０２Ｂ等の複数のＩＯＭＭＵの各々は、複数のアドレス空間のうち異なるアドレス空間に関連付けられたＳＤＸＩエンジン３０４Ａ及び３０４Ｂのクロスコンテキスト要求発行装置３５５等の異なるメモリアクセス要求装置に関連付けられる。ＩＯＭＭＵの各々は、複数のアドレス空間の各々に関連付けられたメモリアクセス要求装置のためのアドレス変換をマッピング／提供する、ＭＭＩＯレジスタ３１６等の複数のメモリマップト入出力（ＭＭＩＯ）レジスタを含む。

【0059】

図６に示されるように、方法６００は、ＩＯＭＭＵによって、ＩＯＭＭＵの複数のＭＭＩＯレジスタを複数のＩＯＭＭＵの複数のＭＭＩＯレジスタと同期させるステップ６０４を含む。ＩＯＭＭＵの複数のＭＭＩＯレジスタを複数のＩＯＭＭＵの複数のＭＭＩＯレジスタと同期させることは、ＩＯＭＭＵによって、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタのコンテキストデータを用いてＩＯＭＭＵの複数のＭＭＩＯレジスタを初期化することと、ＩＯＭＭＵによって、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタに対する変更を追跡することと、を含む。複数のＩＯＭＭＵの複数のＭＭＩＯレジスタのコンテキストデータを用いてＩＯＭＭＵの複数のＭＭＩＯレジスタを初期化することは、ＩＯＭＭＵによって、複数のＩＯＭＭＵの各ＩＯＭＭＵについて、ＩＯＭＭＵのコンテキストＩＤ及びＩＯＭＭＵのアドレスを受信することを含む。更に、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタに対する変更を追跡することは、ＩＯＭＭＵのＭＭＩＯレジスタが変更された場合に、ＩＯＭＭＵによって複数のＩＯＭＭＵにメッセージを送信することと、複数のＩＯＭＭＵの別のＩＯＭＭＵのＭＭＩＯレジスタが変更された場合に、ＩＯＭＭＵによって複数のＩＯＭＭＵの別のＩＯＭＭＵからメッセージを受信することと、を含む。

【0060】

ブロック６０６に示すように、方法６００は、ＩＯＭＭＵ３０２Ａ及び／又は３０２Ｂ等のＩＯＭＭＵによって、ダイレクトメモリアクセス（ＤＭＡ）要求を受信することを含み、ＤＭＡ要求は、コンテキストデータと、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能のＰＣＩセグメント／バス／デバイス／機能等の機能識別子と、を含む。例えば、ＤＭＡ要求は、ＩＯＭＭＵが要求されたアドレスに対してアドレス変換を実行するために、必要とされる適切なＩＯＭＭＵコンテキストを識別するために使用される機能識別子と共に発行される。すなわち、各ＩＯＭＭＵコンテキストは、機能識別子空間の一意のサブセットに関連付けられる。機能識別子は、複数のアドレス空間に関連付けられてもよく、ＤＭＡ要求は、任意選択で、プロセスアドレス空間識別子（ＰＡＳＩＤ）を含んでもよく、機能識別子とＰＡＳＩＤの組合せは、アドレス変換に使用される、例えば、ゲスト及びホストページテーブル等のページテーブル又はネストされたページテーブルのセットを参照するために組み合わされる。

【0061】

ＤＭＡ要求は、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに結合されたＳＤＸＩエンジン３０４Ａ及び３０４Ｂのクロスコンテキスト要求発行装置３５５等の周辺コンポーネントエンドポイントから受信される。機能は、周辺コンポーネントエンドポイント機能であり、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに結合された周辺コンポーネントエンドポイントの物理機能及び複数の仮想機能のうち何れかの仮想機能のうち少なくとも１つである。（図２参照）。

【0062】

ブロック６０８に示すように、方法６００は、ＩＯＭＭＵ３０２Ａ及び３０２ＢのＤＭＡポート３１４、作業待ち行列３１０、ＴＬＢ３１８、ＭＭＩＯレジスタ３１６、及び、マルチＩＯＭＭＵ同期ロジック３５０等のＩＯＭＭＵによって、ＤＭＡ要求に応じて別のＩＯＭＭＵに属するメモリアドレス空間へのダイレクトメモリアクセスを提供することを含む。

【0063】

図７は、本開示の実施形態による、ハイパーバイザと少なくとも１つの仮想マシンとの間等のデータ移動を容易にするために複数のメモリアドレス空間をサポートするための方法を示すフローチャートである。動作は、任意の適切な順序で実行されてもよい。図７に示すように、方法７００は、ＩＯＭＭＵ３０２Ａ及び３０２ＢのマルチＩＯＭＭＵ同期ロジック３５０等によって、複数のＩＯＭＭＵの入出力メモリ管理ユニット（ＩＯＭＭＵ）において、複数のＩＯＭＭＵの別のＩＯＭＭＵのコンテキストデータを受信するステップ７０２を含む。複数のＩＯＭＭＵの各々は、ＭＭＩＯレジスタ３１６等の複数のメモリマップト入出力（ＭＭＩＯ）レジスタを含み、ＭＭＩＯレジスタは、複数のＩＯＭＭＵのそれぞれのＩＯＭＭＵに属するメモリアドレス空間のための、ページテーブル等のメモリデータ構造と組み合わせてアドレス変換を提供する。

【0064】

図７に示されるように、方法７００は、ＩＯＭＭＵによって、ＩＯＭＭＵの複数のＭＭＩＯレジスタを複数のＩＯＭＭＵの複数のＭＭＩＯレジスタと同期させるステップ７０４を含む。ＩＯＭＭＵの複数のＭＭＩＯレジスタを複数のＩＯＭＭＵの複数のＭＭＩＯレジスタと同期させることは、ＩＯＭＭＵによって、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタのコンテキストデータを用いてＩＯＭＭＵの複数のＭＭＩＯレジスタを初期化することと、ＩＯＭＭＵによって、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタに対する変更を追跡することと、を含む。複数のＩＯＭＭＵの複数のＭＭＩＯレジスタのコンテキストデータを用いてＩＯＭＭＵの複数のＭＭＩＯレジスタを初期化することは、ＩＯＭＭＵによって、複数のＩＯＭＭＵの各ＩＯＭＭＵについて、ＩＯＭＭＵのコンテキストＩＤ及びＩＯＭＭＵの位置を受信することを含む。更に、複数のＩＯＭＭＵの複数のＭＭＩＯレジスタに対する変更を追跡することは、ＩＯＭＭＵのＭＭＩＯレジスタが変更された場合に、ＩＯＭＭＵによって複数のＩＯＭＭＵにメッセージを送信することと、複数のＩＯＭＭＵの別のＩＯＭＭＵのＭＭＩＯレジスタが変更された場合に、ＩＯＭＭＵによって複数のＩＯＭＭＵの別のＩＯＭＭＵからメッセージを受信することとを含む。

【0065】

ブロック７０６に示すように、方法７００は、ＩＯＭＭＵ３０２Ａ及び／又は３０２Ｂ等のＩＯＭＭＵに結合された周辺コンポーネントエンドポイントからダイレクトメモリアクセス（ＤＭＡ）要求を受信することを含み、ＤＭＡ要求は、コンテキストデータと、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能のＰＣＩセグメント／バス／デバイス／機能等の機能識別子と、を含む。例えば、ＤＭＡ要求は、ＩＯＭＭＵが要求されたアドレスに対してアドレス変換を実行するために、必要とされる適切なＩＯＭＭＵコンテキストを識別するために使用される機能識別子と共に発行される。すなわち、各ＩＯＭＭＵコンテキストは、機能識別子空間の一意のサブセットに関連付けられる。機能識別子は、複数のアドレス空間に関連付けられてもよく、ＤＭＡ要求は、任意選択で、プロセスアドレス空間識別子（ＰＡＳＩＤ）を含んでもよく、機能識別子とＰＡＳＩＤの組合せは、アドレス変換に使用される、例えば、ゲスト及びホストページテーブル等のページテーブル又はネストされたページテーブルのセットを参照するために組み合わされる。

【0066】

【0067】

ブロック７０８に示されるように、方法７００は、ＩＯＭＭＵによって、ＤＭＡ要求のコンテキストデータに基づいて、ＩＯＭＭＵの複数のＭＭＩＯレジスタにアクセスすることを含む。ＤＭＡ要求のコンテキストデータに基づいて、ＩＯＭＭＵの複数のＭＭＩＯレジスタにアクセスすることは、ＤＭＡ要求のコンテキストデータを復号することと、復号されたコンテキストデータに基づいて、複数のＭＭＩＯレジスタのうち特定の複数のＭＭＩＯレジスタにアクセスすることと、復号されたコンテキストデータに基づいて変換ルックアサイドバッファをロードすることと、復号されたコンテキストデータに基づいて、ＤＭＡ要求を変換することと、を含む。次いで、ブロック７１０に示すように、方法７００は、アクセスされた複数のＭＭＩＯレジスタに基づいて、ＩＯＭＭＵから、別のＩＯＭＭＵに属するコンテキストによって参照されるページテーブルにアクセスすることを含む。特に、別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能にアクセスすることは、アクセスされた特定の複数のＭＭＩＯレジスタ及び変換されたＤＭＡ要求に基づく。次いで、ブロック７１２に示すように、方法７００は、ＩＯＭＭＵによって、アクセスされたページテーブルを使用してＤＭＡ要求に対するアドレス変換を実行することを含む。最後に、ブロック７１４に示すように、方法７００は、ＩＯＭＭＵによって、ＤＭＡ要求及び変換されたアドレスに基づいてメモリアクセスを実行することを含む。

【0068】

上述したように、本開示は、ソフトウェアトランスペアレントな方法で、複数のルートツリーにおいて、周辺コンポーネントデバイス、ＳＤＸＩエンジン、及び、ＰＣＩエンドポイント等のＩ／Ｏデバイスのための保護及びアドレス変換を提供するコンテキストアウェアＩＯＭＭＵに関する。このソリューションは、コンテキストアウェアＩＯＭＭＵを使用してリモートＤＭＡを実行するために、異なるルートコンプレックスの下で接続された高度なこれらのＩ／Ｏデバイスを可能にする。

【0069】

コンテキストアウェアＩＯＭＭＵは、システムオンチップ等のチップ、Ｉ／Ｏ電力及び性能の分析によって検出可能であり得る。更に、チップの相互接続を検討すると、周辺コンポーネントエンドポイント間に直接的な物理的接続が存在するかどうかが示される。例えば、変換サービスが特定のコンポーネントの一部であり、周辺コンポーネントエンドポイント間に大量の直接物理接続が存在せず、ソフトウェアがシステムにおいてＩＯＭＭＵを報告させるようにプログラムされている場合、コンテキストアウェアＩＯＭＭＵが存在する可能性が高い。

【0070】

図８は、本開示の実施形態による、プラットフォームアーキテクチャ８００の別の例を示す。ＤＭＡエンジン８４０Ａ及び８４０Ｂをそれぞれ含むＳＤＸＩエンジン８０４Ａ及び８０４Ｂは、ＳＲ－ＩＯＶＰＦ及び複数のＳＲ－ＩＯＶＶＦを通してソフトウェアにさらされ、その各々は、メモリデバイス８０８内の異なるアドレスドメイン及びこれらの機能間でデータを移動させる能力にマッピングされ得る。ＳＤＸＩエンジン８０４Ａ及び８０４Ｂは、ＨＶ及びＣＰＵリソースをオフロードし、少なくとも２つのゲストＯＳ又はゲストＯＳとＨＶとの間のデータ転送を維持するために必要とされるソフトウェアスタックの複雑さを低減する。

【0071】

帯域幅要件を満たすために、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂは、それぞれのルートポート８６０Ａ及び８６０Ｂを介して個別のＩＯＭＭＵ８０２Ａ及び８０２Ｂと統合され、データファブリック８０６のデータファブリック経路は、システムメモリ８０８に統合される。例えば、システムでは、ソケットごとに４つのＳＤＸＩエンジンが存在し、４つのソケット能力を有し、したがって、システム内に最大１６個のＳＤＸＩエンジンが存在し得る。ソフトウェアオーバーヘッドを低減し、ソフトウェアからのシステムレベル実装を不明瞭にするために、ＶＭ及びＨＶは、ＳＤＸＩエンジンのための複数のＤＴＥを維持することを回避する。各ＳＤＸＩエンジンは、ＰＦ及び複数のＶＦを有するが、各ＶＭは、１つのＶＦにアタッチする必要があるだけであり、いくつのＳＤＸＩエンジンインスタンスがシステム上に存在するかにかかわらず、全てのＳＤＸＩエンジンインスタンスを利用して、任意の他のＳＤＸＩエンジンＰＦ／ＶＦ間のデータ転送を容易にすることができる。したがって、システムは、本開示の実施形態で説明されるように、１つのＩＯＭＭＵインスタンスの下のＩ／Ｏデバイスが、別のＩＯＭＭＵインスタンスに仮想的に接続されているように見えることを可能にする。本開示の特定の実施形態では、システムトポロジは、同じルートコンプレックス内の２つのルートポートのうち何れかに各々接続された２つのＳＤＸＩエンジンが存在する場合を含むことができる。両方のルートポートは、システム内の複数のＩＯＭＭＵのうち単一のＩＯＭＭＵによってサービスされる。

【0072】

図８に示すように、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂは、互いのリクエスタＩＤを使用してＤＭＡ要求を生成することができる機能の集合である機能グループ内にある。マルチコンテキストＩＯＭＭＵ機能の使用をイネーブルにする場合、各ＩＯＭＭＵインスタンスは、一意のコンテキストＩＤに割り当てられる。ＳＤＸＩエンジン８０４Ａ又はＳＤＸＩエンジン８０４Ｂ等のＳＤＸＩエンジンは、機能グループ内の全てのＳＤＸＩエンジン上のＰＦ及びＶＦのような全ての機能のセットのうち何れの機能がＤＭＡ要求を生成しているかを示す。ＤＭＡ要求を受信するＩＯＭＭＵは、これらの指標を使用して、ＤＭＡ要求を変換するために何れのＩＯＭＭＵコンテキストを使用するかを決定する。機能番号は、標準的なリクエスタＩＤ（バス／デバイス／機能）を使用して、例えばＰＣＩｅバス等のバスを介して通信され得る。また、追加の機能識別情報は、セグメントＩＤ等のバスを介して又はユーザビット等の独自の手段を介してシステムハブに伝達されてもよい。指標が設定されていない場合、要求は、コンテキストがＩＯＭＭＵの一意のコンテキストＩＤにプログラムされているかのように処理され、デバイスはＩＯＭＭＵに物理的に接続される。

【0073】

各ＳＤＸＩエンジンは、識別子フィールドで符号化された複数のＶＦにまたがる。ＢＤＦ（登録商標）割り当ては、ＩＯＭＭＵコンテキストに関連しており、したがって、ＮＢＩＦ二次／従属バス番号等のハブ番号に基づいて導出されるＳＤＸＩエンジンバス番号範囲もコンテキスト固有である。ＩＯＭＭＵコンテキストにわたって、ＢＤＦ（登録商標）割り当ては、異なるデバイス間で重複する可能性があり、これらのデバイスは、必ずしもメモリページを共有せず、異なるＤＴＥを有する。

【0074】

ルートポート８６０Ａ及び８６０Ｂは、デバイスメモリアクセスのための仮想アドレスから物理アドレス変換への実行を支援するハードウェア制御ロジックを含む。上述したように、ＳＤＸＩエンジン８０４Ａ及びＳＤＸＩエンジン８０４Ｂは、ＶＭ間、コンテナ間、又は、セキュリティポリシーが分離されたアドレス空間を必要とする通信を加速するためのソフトウェア及びハードウェアソリューションを提供する。ＳＤＸＩエンジンは、異なる保護されたメモリ空間間でデータを移動させることを可能にする高度なデータムーバ能力と、ＣＰＵ及びメモリリソースのより良好な使用と、を使用して、２つの周辺コンポーネントデバイス間をブリッジする独自のハードウェア設計を介してこれを達成し、これは、レイテンシの大幅な減少、帯域幅の増加を達成し、したがって、より大きいＶＭスケーリングを可能にする。

【0075】

図示した実施形態において、ＳＤＸＩエンジン８０４Ａ及びＳＤＸＩエンジン８０４Ｂの各々は、ルートポート８６０Ａ及び８６０Ｂを含む複数の周辺コンポーネント相互接続バスを介して、それぞれのＩＯＭＭＵ８０２Ａ及び８０２Ｂと相互接続される。ＩＯＭＭＵ８０２Ａ及び８０２Ｂは、Ｉ／Ｏリソース、メモリデバイス８０８、及び、プラットフォームアーキテクチャ８００の他のコンポーネントの間のインタフェースとして動作する。上述したように、プラットフォームアーキテクチャ８００は、物理リソースが複数のＶＭをサポートする仮想化環境を提供し、各ＶＭは、個別のゲストＯＳカーネルと、対応するＶＭのゲストＯＳカーネルによってサポートされる１つ以上のゲストソフトウェアアプリケーションと、を実装する。

【0076】

ＳＤＸＩエンジンは、物理的に接続されたルートポートに属し、同じグループＩＤ値の他のＳＤＸＩエンジンのための変換を処理する能力を有する。ルートポート８６０Ａ及び８６０Ｂを含む複数の周辺コンポーネント相互接続バスは、１つのＳＤＸＩエンジンインスタンスが別のＳＤＸＩエンジンインスタンスの代わりにＤＭＡ及び割り込みを生成することができるように、任意の他のインスタンスとして動作することができ、複数の周辺コンポーネント相互接続バスは、例えばＭＳＩ－Ｘ、ＢｕｓＭａｓｔｅｒＥｎ、ＡＣＳ等の適切な制御を使用することができる。ルートポート８６０Ａ及び８６０Ｂを含む複数の周辺コンポーネント相互接続バスは、割り込み生成、バスマスタイネーブルブロッキングＤＭＡ、エラー報告等の制御によって駆動されるロジックと共に、ルートポート及びエンドポイントコンポーネントの両方のための周辺コンポーネント構成空間レジスタを含む。ＳＤＸＩエンジンの各物理インスタンスは、１つのＰＦと、１つのルートポートの下に位置するいくつかのＶＦ、例えば６４個のＶＦとを有するＳＲ－ＩＯＶ周辺コンポーネントエンドポイントである。各ＳＤＸＩエンジンインスタンスは、異なるルートポートの下に存在し、各周辺コンポーネント相互接続バスインスタンスは、それ自体のローカルにアタッチされたＳＤＸＩエンジンインスタンスのためのＳＤＸＩエンジンルートポート及びエンドポイントレジスタの全てと、全ての他の周辺コンポーネント相互接続バスインスタンス／ＳＤＸＩエンジンインスタンスによってホストされる同等のレジスタ／ロジックと、を含む。

【0077】

図８に示されるように、ルートポート８６０Ａ及びＳＤＸＩエンジン８０４Ａは、ＰＦ０及びＶＦ０^＊のソフトウェアビューを含み、ＳＤＸＩエンジン８０４Ａは、ＰＦ０、ＰＦ１、ＶＦ０^＊又はＶＦ１^＊識別子を使用してＤＭＡを生成することができる。ルートポート８６０Ｂ及びＳＤＸＩエンジン８０４Ｂは、ＰＦ１及びＶＦ１^＊のソフトウェアビューを含み、ＳＤＸＩエンジン８０４Ｂは、ＰＦ０、ＰＦ１、ＶＦ０^＊又はＶＦ１^＊識別子を使用してＤＭＡを生成することができる。ＳＤＸＩエンジン８０４Ａの場合、ソフトウェアは、ＰＦ０及びＶＦ０^＊の一次構成空間を直接書き込むことができ、ＰＦ１及びＶＦ１^＊の二次構成空間は、その状態が一次構成から順方向であるコピーである。同様に、ＳＤＸＩエンジン８０４Ｂの場合、ソフトウェアは、ＰＦ１及びＶＦ１^＊の一次構成空間を直接書き込むことができ、ＰＦ０及びＶＦ０^＊の二次構成空間は、その状態が一次構成から順方向であるコピーである。更に、レジスタ状態及び特別な場合のデータの低帯域幅交換は、例えばバスを介して、ＳＤＸＩエンジン８０４Ａと８０４Ｂとの間、及び、ルートポート８６０Ａと８６０Ｂとの間を流れることができる。追加的及び／又は代替的に、データファブリック８０６は、この情報を転送するために使用され得る。

【0078】

ルートポートメッセージ／通信は、適用可能な更新が書き込まれた場合に、他のＳＤＸＩエンジン及びＩＯＭＭＵインスタンスに接続された全てのリモートルートポートを自動的に更新するために使用される。例えば、ローカルルートポートは構成を監視し、リモート範囲がヒットした場合、リモートルートポートへの一致する値のトランザクションを行うことができる。リモートルートポートは、トランザクションを受信し、ルックアップテーブル値に従ってデコードする。

【0079】

各ルートポートは、その構成レジスタ／内部レジスタの少なくとも一部を他のリモートルートポートにシャドウする。例えば、１６個のルートポートがある場合、シャドウ機構は、そのシャドウ化されるべきレジスタの値に変化が検出されている限り、１ＤＷのサイズでの１対１５ブロードキャストである。

【0080】

リモートルートポートにおいて、各ルートポートは、１５個の他のルートポートのような他のリモートルートポートからのシャドウ化レジスタコピーを維持する。単一ルートポートの場合、リモートルートポートコピー及びローカルルートポートの内部レジスタは、ルックアップテーブル（ＬＵＴ）を構成する。ＳＤＸＩエンジンのためのＤＭＡトランザクションが存在すると、トランザクションの属性（インスタンスＩＤによって示されるリモートノード、ＰＦであるかＶＦであるか、ＶＦＩＤ等）に従って、ＬＵＴから情報を得るための内部チェックが存在し、次いで、対応する周辺コンポーネント関連チェックを実行する。

【0081】

例えば、構成レジスタ／内部レジスタのその部分を他のリモートルートポートにシャドウする能力を有するＳＤＸＩエンジン機能を有するルートポートの場合、ＳＤＸＩエンジンＰＦ関連レジスタ（ＰＦごと）、ポート０関連レジスタ（ポートごと）、及び、ＳＤＸＩエンジンＶＦ関連レジスタ（ＶＦごと）を含む。リモートルートポートのローカルルートポート認識を可能にするために、初期構成段階において、ファームウェアは、リモートトランザクションを可能にするようにいくつかのレジスタをプログラムすることができる。

【0082】

ＳＤＸＩエンジンが周辺コンポーネントエンドポイント機能として動作する場合、ルートポートは、その周辺コンポーネント構成レジスタを物理的にルートポート内に保持し、ＳＤＸＩエンジン用の周辺コンポーネントパッケージを送受信し、ＤＭＡトランザクションを処理し、ＳＤＸＩエンジン用の周辺コンポーネントイベント管理を処理する。上述したように、各ＳＤＸＩエンジン８０４Ａ及び８０４Ｂは、ＰＦ及び複数のＶＦを有する。各ＶＭは、１つのＶＦにアタッチする必要があるだけであり、いくつのＳＤＸＩエンジンインスタンスがシステム上に存在するかにかかわらず、全てのＳＤＸＩエンジンインスタンスを利用して、任意の他のＳＤＸＩエンジンＰＦ／ＶＦ間のデータ転送を容易にすることができる。したがって、システムは、本開示の実施形態で説明されるように、１つのＩＯＭＭＵインスタンス及び１つのルートポートインスタンスの下のＩ／Ｏデバイスが、別のＩＯＭＭＵインスタンス及び別のルートポートインスタンスに仮想的に接続されているように見えることを可能にする。ソフトウェアは、ＳＤＸＩエンジンエンドポイント及び関連するルートポート構成空間レジスタの一次コピーに書き込む。ハードウェアは（非割り込み）情報を他の全てのインスタンスに転送する。

【0083】

また、プラットフォームアーキテクチャ８００は、ＭＳＩ又はＭＳＩ－Ｘ割り込みを使用する信号割り込み等の割り込みの配信をサポートする。例えば、各ＳＤＸＩエンジン８０４Ａ及び８０４Ｂに対して１つのＰＦ及び１２８のＶＦが存在し、各機能が１つのＭＳＩベクトル及び１４０のＭＳＩ－Ｘベクトルをサポートする場合、ベクトル情報を記憶するために多くの空間が必要とされる。このエリアのサイズを減少させるために、ＭＳＩ／ＭＳＩ－Ｘ能力のいくつかのレジスタが、メモリデバイス８０８のメモリカーブアウト８０８Ｂに記憶される。割り込みの配信をサポートするために、ＳＤＸＩエンジンエンドポイント機能のためのレジスタ状態が交換される。例えば、各エンドポイント機能（ＰＦ又はＶＦ）は、交換されるルートポートバージョンとは別のバスマスタイネーブル制御も含む。割り込みは、エンドポイント機能構成／ＭＭＩＯ空間においてプログラムされる。

【0084】

ソフトウェアがＳＤＸＩエンジン機能のこれらのＭＳＩ／ＭＳＩ－Ｘ能力にアクセスしたい場合、ＳＤＸＩエンジンは、ルートポート８６０Ａ／８６０Ｂを介して、メモリデバイス８０８のメモリカーブアウト８０８Ｂから情報を取得し、ソフトウェアに戻る。ＭＳＩ能力の場合、メッセージアドレス、メッセージ上位アドレス、メッセージデータ、マスクビット、及び、保留ビットは、メモリデバイス８０８のメモリカーブアウト８０８Ｂに記憶される。ＭＳＩ－Ｘ能力の場合、メッセージアドレス、メッセージ上位アドレス、メッセージデータ、ＳＴテーブル、マスクビット、及び、保留ビットは、メモリデバイス８０８のメモリカーブアウト８０８Ｂに記憶される。他のタイプは、必要に応じてエンドポイント機能内に記憶される。

【0085】

ＳＤＸＩエンジンエンドポイント機能のこれらのＭＳＩ／ＭＳＩ－Ｘ能力を有効にするために、初期構成段階において、ファームウェアは、リモートトランザクションを可能にするようにいくつかのレジスタをプログラムすることができる。ファームウェアは、メモリデバイス８０８内のＭＳＩ／ＭＳＩ－Ｘ能力のための空間を確保し、メモリデバイス８０８のメモリカーブアウト８０８Ｂを有効にすることができる。ファームウェアは、ルートポート８６０Ａ／８６０Ｂを介して、メモリデバイス８０８内のメモリカーブアウト８０８Ｂのベースアドレスを示し、メモリデバイス８０８内のメモリカーブアウト８０８Ｂが準備完了であることを示す、ＳＤＸＩエンジンエンドポイント機能内のレジスタに書き込むことができる。ソフトウェアは、ＭＳＩ／ＭＳＩ－Ｘ能力を構成するために、ルートポート８６０Ａ／８６０Ｂを介して構成送信を送信することができ、ソフトウェアは、ＳＤＸＩエンジンエンドポイント機能においてＭＳＩ／ＭＳＩ－Ｘ能力をイネーブルにすることができる。次いで、ハードウェアは、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂ割り込みを受信する準備ができており、ＣＰＵ８８０は、ＭＳＩ／ＭＳＩ－Ｘ能力にアクセスすることができる。

【0086】

図９は、いくつかの実施形態による、図８の割り込みトランザクションのブロック図である。図９に示すように、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂの各々は、論理的にＭＳＩ／ＭＳＩ－Ｘ割り込み制御レジスタを含む。しかしながら、実レジスタに記憶する代わりに、情報は、ＳＤＸＩエンジンの全てのインスタンスによってアクセス可能なメモリデバイス８０８の共有メモリカーブアウト８０８Ｂに記憶される。ソフトウェアは、エンドポイント構成空間の一次インスタンスに書き込み、次に、その情報をメモリデバイス８０８の共有メモリカーブアウト８０８Ｂに反映する。ＭＳＩ制御は、構成空間に完全に配置することができる。ＭＳＩ－Ｘの場合、ほとんどの情報（アドレス／データ等）は、ＭＭＩＯ空間を介してソフトウェアによってアクセスすることができる。デバイス割り込み時に、一次インスタンス及び二次インスタンスは、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂからの情報にアクセスすることができる。図９は、ＳＤＸＩエンジン８０４ＡのＤＭＡ８４０ＡからのＰＦ０割り込みを示しており、これは、長い破線で示されているように、ローカル機能ＰＦ０からの割り込みである。ＰＦ０割り込みがＳＤＸＩエンジン８０４ＡのＤＭＡ８４０Ａからのものである場合、エンドポイントＭＳＩ／ＭＳＩ－Ｘ割り込み情報ＰＦ０は、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂから取り出される。次いで、割り込み情報が返され、次いで、割り込みを、ルートポート８６０Ａ、ＩＯＭＭＵ８０２Ａ及びデータファブリック８０６を介して、ＣＰＵ８８０等の割り込みターゲットに送信することができる。

【0087】

図１０は、いくつかの実施形態による、図８の割り込みトランザクションのブロック図である。図１０に示すように、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂの各々は、論理的にＭＳＩ／ＭＳＩ－Ｘ割り込み制御レジスタを含む。しかしながら、上述したように、実レジスタに記憶する代わりに、情報は、ＳＤＸＩエンジンの全てのインスタンスによってアクセス可能なメモリデバイス８０８の共有メモリカーブアウト８０８Ｂに記憶される。ソフトウェアは、エンドポイント構成空間の一次インスタンスに書き込み、次に、その情報をメモリデバイス８０８の共有メモリカーブアウト８０８Ｂに反映する。デバイス割り込み時に、一次インスタンス及び二次インスタンスは、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂからの情報にアクセスすることができる。図１０は、ＳＤＸＩエンジン８０４ＢのＤＭＡ８４０ＢからのＶＦ０＿ｎ割り込みを示し、これは、長い破線によって示されるようなリモート機能ＶＦ０＿ｎからの割り込みである。ＶＦ０＿ｎ割り込みがＳＤＸＩエンジン８０４ＢのＤＭＡ８４０Ｂからのものである場合、エンドポイントＭＳＩ／ＭＳＩ－Ｘ割り込み情報ＶＦ０＿ｎは、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂから取り出される。次いで、割り込み情報が返され、次いで、割り込みを、ルートポート８６０Ｂ、ＩＯＭＭＵ８０２Ｂ及びデータファブリック８０６を介して、ＣＰＵ８８０等の割り込みターゲットに送信することができる。

【0088】

図１１は、いくつかの実施形態による、図８の割り込みレジスタのソフトウェアプログラミングのためのブロック図である。図１１に示されるように、ＶＦ０＿０ソフトウェアドライバは、ＶＦ０＿０ＭＳＩ／ＭＳＩ－Ｘレジスタをプログラムすることができ、そのデータは、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂに配置される。ＶＦ０＿０ＭＳＩ／ＭＳＩ－Ｘレジスタのソフトウェアプログラミングのみが図１１に示されているが、ソフトウェアは、エンドポイント構成空間の一次インスタンスの何れかに書き込むことができ、それは、次いで、情報をメモリデバイス８０８の共有メモリカーブアウト８０８Ｂに反映する。デバイス割り込み時に、一次インスタンス及び二次インスタンスは、メモリデバイス８０８の共有メモリカーブアウト８０８Ｂからの情報にアクセスすることができる。

【0089】

図１２は、いくつかの実施形態による、図８のＤＭＡ要求フローのブロック図である。図１２に示すように、各ＤＭＡは、クロスコンテキスト要求発行装置から要求する（例えば、図３を参照されたい。）。ＳＤＸＩエンジン８０４ＢのＤＭＡ８４０ＢからのＤＭＡは、何れの機能が使用されているか（一次／ローカルであるか二次／リモートであるか）にかかわらず、ルートポートインフラストラクチャの同じ部分に流れ込む。要求を処理するために、バスマスタイネーブルの適切なコピー等のように、全ての適切なルートポート制御が適用される。各ＤＭＡ要求は、ルートポート８６０Ｂ及び／又はＩＯＭＭＵ８０２Ｂによって使用されるコンテキスト識別子を搬送して、ＤＭＡ要求を通信し、ＤＭＡ要求を変換するために何れのコンテキストを使用するかを識別する。各コンテキストは、独立してプログラムされることが可能であり、ドメインＩＤ等のための異なるデータ構造又は再使用符号化を指すことが可能である。ルートポート８６０Ｂ及び／又はＩＯＭＭＵ８０２Ｂのコンテキストレジスタは、着信コンテキスト識別子に基づいて使用される。コンテキストレジスタは、リモートコンテキストを使用して変換される各コンテキストＤＭＡアクセスがローカルコンテキストの物理ＤＭＡポートを介して依然として発生するため、ソフトウェアによって独立してプログラムされ得るデバイステーブル等のデータ構造を指す。長い破線によって示されるように、例示的なＤＭＡフローは、ＰＦ１アドレス空間からのフェッチ記述子コマンドを含む。一点鎖線によって示されるように、例示的なＤＭＡフローは、ＶＦ０＿０アドレス空間を使用するソースバッファからの読取りデータを含む。一点鎖線によって示されるように、例示的なＤＭＡフローは、ＶＦ１＿０アドレス空間を使用する宛先バッファへの書込みデータを含む。

【0090】

図１３は、本開示の実施形態による、複数のアドレス空間の間のデータ移動を提供するための方法を示すフローチャートである。動作は、任意の適切な順序で実行されてもよい。図１３に示されるように、方法１３００は、ルートポート８６０Ａ及び８６０Ｂ等によって、複数のルートポートのうち別のルートポートのコンテキストデータを記憶するステップ１３０２を含む。複数のルートポートの各ルートポートは、複数のＩＯＭＭＵのうち対応するＩＯＭＭＵと、複数の周辺コンポーネントエンドポイントのうち対応する周辺コンポーネントエンドポイントと、に結合される。例えば、ルートポート８６０Ａ及び８６０Ｂのような複数のルートポートの各々は、複数のアドレス空間のうちの異なるアドレス空間に関連付けられたクロスコンテキスト要求発行装置、例えば、ＳＤＸＩエンジン８０４Ａ及び８０４ＢのＤＭＡ８４０Ａ又は８４０Ｂのような異なるメモリアクセス要求元（周辺コンポーネントエンドポイント）に関連付けられる。また、ルートポート８６０Ａ及び８６０Ｂ等の複数のルートポートの各々は、ＩＯＭＭＵ８０２Ａ及び８０２Ｂ等の異なるＩＯＭＭＵに関連付けられ、ＩＯＭＭＵは、複数のアドレス空間のうち異なるアドレス空間に関連付けられる。各ルートポートは、複数のレジスタを含む。複数のレジスタは、例えば、ルートポートを介してＤＭＡを許可するか否かを制御するバスマスタイネーブル用のレジスタを含む。また、複数のレジスタは、例えば、（バス／デバイス／機能の）要求に関連付けられたバス番号がルートポートに割り当てられたバス番号の範囲内にあるかどうか等のように、ＤＭＡ要求に対する基本的なセキュリティチェックを提供するＰＣＩｅＡＣＳ制御のためのレジスタを含む。

【0091】

図１３に示されるように、方法１３００は、ルートポートによって、ルートポートの複数のレジスタを複数のルートポートの複数のレジスタと同期させるステップ１３０４を含む。ルートポートの複数のレジスタを複数のルートポートの複数のレジスタと同期させることは、ルートポートによって、複数のルートポートの複数のレジスタのコンテキストデータを用いてルートポートの複数のレジスタを初期化することと、ルートポートによって、複数のルートポートの複数のレジスタに対する変更を追跡することと、を含む。複数のルートポートの複数のレジスタのコンテキストデータを用いてルートポートの複数のレジスタを初期化することは、複数のルートポートの各ルートポートについて、ルートポートによって、ルートポートのコンテキストＩＤ及びルートポートのアドレスを受信することを含む。更に、複数のルートポートの複数のレジスタに対する変更を追跡することは、ルートポートのレジスタが変更された場合に、ルートポートによって複数のルートポートにメッセージを送信することと、複数のルートポートの別のルートポートのレジスタが変更された場合に、ルートポートによって複数のルートポートの別のルートポートからメッセージを受信することと、を含む。

【0092】

ブロック１３０６に示されるように、方法１３００は、ルートポート８６０Ａ及び／又は８６０Ｂ等のルートポートによって、ダイレクトメモリアクセス（ＤＭＡ）要求を受信することを含み、ＤＭＡ要求は、コンテキストデータと、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能のＰＣＩセグメント／バス／デバイス／機能等の機能識別子と、を含む。例えば、ＤＭＡ要求は、対応するＩＯＭＭＵが要求されたアドレスに対してアドレス変換を実行するために、必要とされる適切なＩＯＭＭＵコンテキストを識別するために使用される機能識別子と共に発行される。すなわち、各ＩＯＭＭＵコンテキストは、機能識別子空間の一意のサブセットに関連付けられる。機能識別子は、複数のアドレス空間に関連付けられてもよく、ＤＭＡ要求は、任意選択で、プロセスアドレス空間識別子（ＰＡＳＩＤ）を含んでもよく、機能識別子とＰＡＳＩＤの組合せは、アドレス変換に使用される、例えば、ゲスト及びホストページテーブル等のページテーブル又はネストされたページテーブルのセットを参照するために組み合わされる。ＤＭＡ要求は、複数のルートポートのうち何れかのルートポートを介して複数のＩＯＭＭＵのうちの対応するＩＯＭＭＵに結合された、ＳＤＸＩエンジン８０４Ａ／８０４Ｂのクロスコンテキスト要求発行装置（ＤＭＡ８４０Ａ又はＤＭＡ８４０Ｂ）等の対応する周辺コンポーネントエンドポイントから受信される。機能は、周辺コンポーネントエンドポイント機能であり、複数のルートポートのうちの別のルートポートを介して複数のＩＯＭＭＵのうち別のＩＯＭＭＵに結合された複数の周辺コンポーネントエンドポイントのうち別の周辺コンポーネントエンドポイントの物理機能及び複数の仮想機能のうち何れかの仮想機能のうち少なくとも１つである。

【0093】

ブロック１３０８に示すように、方法１３００は、ＤＭＡ要求に応じて、別のＩＯＭＭＵに属するメモリアドレス空間へのダイレクトメモリアクセスを、ルートポートを介して提供することを含む。

【0094】

図１４は、本開示の実施形態による、ハイパーバイザと少なくとも１つの仮想マシンとの間等のデータ移動を容易にするために複数のメモリアドレス空間をサポートするための方法を示すフローチャートである。動作は、任意の適切な順序で実行されてもよい。図１４に示すように、方法１４００は、ルートポート８６０Ａ及び８６０Ｂ等の複数のルートポートのうち何れかのルートポートにおいて、複数のルートポートのうち別のルートポートのコンテキストデータを受信するステップ１４０２を含む。複数のルートポートの各ルートポートは、ＩＯＭＭＵ８０２Ａ及び８０２Ｂ等の複数のＩＯＭＭＵの対応する入出力メモリ管理ユニット（ＩＯＭＭＵ）と、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂ等の複数の周辺コンポーネントエンドポイントの対応する周辺コンポーネントエンドポイントと、に結合されている。複数のルートポートの各々は、複数のレジスタを含む。

【0095】

図１４に示されるように、方法１４００は、ルートポートによって、ルートポートの複数のレジスタを複数のルートポートの複数のレジスタと同期させるステップ１４０４を含む。ルートポートの複数のレジスタを複数のルートポートの複数のレジスタと同期させることは、ルートポートによって、複数のルートポートの複数のレジスタのコンテキストデータを用いてルートポートの複数のレジスタを初期化することと、ルートポートによって、複数のルートポートの複数のレジスタに対する変更を追跡することと、を含む。複数のルートポートの複数のレジスタのコンテキストデータを用いてルートポートの複数のレジスタを初期化することは、複数のルートポートの各ルートポートについて、ルートポートによって、ルートのコンテキストＩＤ及びルートポートのアドレスを受信することを含む。更に、複数のルートポートの複数のレジスタに対する変更を追跡することは、ルートポートのレジスタが変更された場合に、ルートポートによって複数のルートポートにメッセージを送信することと、複数のルートポートの別のルートポートのレジスタが変更された場合に、ルートポートによって複数のルートポートの別のルートポートからメッセージを受信することと、を含む。

【0096】

例えば、複数のルートポートにおいて、各ルートポートは、１５個の他のルートポート等の他のリモートルートポートからのシャドウ化レジスタコピーを維持する。単一ルートポートの場合、リモートルートポートコピー及びローカルルートポートの内部レジスタは、ＬＵＴを構成する。ＳＤＸＩエンジンのためのＤＭＡトランザクションが存在すると、トランザクションの属性（インスタンスＩＤによって示されるリモートノード、ＰＦであるかＶＦであるか、ＶＦＩＤ等）に従って、ＬＵＴから情報を得るための内部チェックが存在し、次いで、対応する周辺コンポーネント関連チェックを実行する。例えば、構成レジスタ／内部レジスタのその部分を他のリモートルートポートにシャドウする能力を有するＳＤＸＩエンジン機能を有するルートポートの場合、ＳＤＸＩエンジンＰＦ関連レジスタ（ＰＦごと）、ポート０関連レジスタ（ポートごと）、及び、ＳＤＸＩエンジンＶＦ関連レジスタ（ＶＦごと）を含む。

【0097】

ブロック１４０６に示すように、方法１４００は、ルートポート８６０Ａ／８６０Ｂ等のルートポートに結合された周辺コンポーネントエンドポイントから、ダイレクトメモリアクセス（ＤＭＡ）要求を受信することを含み、ＤＭＡ要求は、コンテキストデータと、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能のＰＣＩセグメント／バス／デバイス／機能等の機能識別子と、を含む。例えば、ＤＭＡ要求は、ＩＯＭＭＵが要求されたアドレスに対してアドレス変換を実行するために、必要とされる適切なＩＯＭＭＵコンテキストを識別するために使用される機能識別子と共に発行される。すなわち、各ＩＯＭＭＵコンテキストは、機能識別子空間の一意のサブセットに関連付けられる。機能識別子は、複数のアドレス空間に関連付けられてもよく、ＤＭＡ要求は、任意選択で、プロセスアドレス空間識別子（ＰＡＳＩＤ）を含んでもよく、機能識別子とＰＡＳＩＤの組合せは、アドレス変換に使用される、例えば、ゲスト及びホストページテーブル等のページテーブル又はネストされたページテーブルのセットを参照するために組み合わされる。

【0098】

ＤＭＡ要求は、ＳＤＸＩエンジン８０４Ａ及び８０４Ｂ等の対応する周辺コンポーネントエンドポイントから受信される。ブロック１４０８において、ルートポートは、複数のＩＯＭＭＵのうち対応するＩＯＭＭＵにＤＭＡ要求を提供することができる。機能は、周辺コンポーネントエンドポイント機能であり、複数のＩＯＭＭＵのうち別のＩＯＭＭＵに結合された周辺コンポーネントエンドポイントの物理機能及び複数の仮想機能のうち何れかの仮想機能のうち少なくとも１つである。

【0099】

ブロック１４１０に示されるように、方法１４００は、ＩＯＭＭＵによって、ＤＭＡ要求のコンテキストデータに基づいてＩＯＭＭＵの複数のＭＭＩＯレジスタにアクセスすることを含む。ＤＭＡ要求のコンテキストデータに基づいて、ＩＯＭＭＵの複数のＭＭＩＯレジスタにアクセスすることは、ＤＭＡ要求のコンテキストデータを復号することと、復号されたコンテキストデータに基づいて、複数のＭＭＩＯレジスタのうちの特定の複数のＭＭＩＯレジスタにアクセスすることと、復号されたコンテキストデータに基づいて変換ルックアサイドバッファをロードすることと、復号されたコンテキストデータに基づいてＤＭＡ要求を変換することと、を含む。次いで、ブロック１４１２に示すように、方法１４００は、アクセスされた複数のＭＭＩＯレジスタに基づいて、ＩＯＭＭＵから、別のＩＯＭＭＵに属するコンテキストによって参照されるページテーブルにアクセスすることを含む。特に、別のＩＯＭＭＵに属するメモリアドレス空間に割り当てられた機能にアクセスすることは、アクセスされた特定の複数のＭＭＩＯレジスタ及び変換されたＤＭＡ要求に基づく。次いで、ブロック１４１４に示すように、方法１４００は、ＩＯＭＭＵによって、アクセスされたページテーブルを使用してＤＭＡ要求に対するアドレス変換を実行することを含む。最後に、ブロック１４１６に示すように、方法１４００は、ＩＯＭＭＵによって、ＤＭＡ要求及び変換されたアドレスに基づいてメモリアクセスを実行することを含む。

【0100】

上述したように、本開示は、特に、ソフトウェアトランスペアレントな方法で複数のルートツリーにおいて、周辺コンポーネントデバイス、ＳＤＸＩエンジン、及び、ＰＣＩエンドポイント等のＩ／Ｏデバイスのための保護及びアドレス変換を提供するコンテキストアウェアルートポート及びＩＯＭＭＵに関する。このソリューションは、コンテキストアウェアＩＯＭＭＵを使用してリモートＤＭＡを実行するために、異なるルートコンプレックスの下で接続された高度なこれらのＩ／Ｏデバイスを可能にする。

【0101】

コンテキストアウェアＩＯＭＭＵ及びルートポートは、システムオンチップ等のチップ、Ｉ／Ｏ電力及び性能の分析によって検出可能であり得る。更に、チップの相互接続を検討すると、周辺コンポーネントエンドポイント間に直接的な物理的接続が存在するかどうかが示される。例えば、変換サービスが特定のコンポーネントの一部であり、周辺コンポーネントエンドポイント間に大量の直接物理接続が存在せず、ソフトウェアがシステムにおいてＩＯＭＭＵを報告させるようにプログラムされている場合、コンテキストアウェアＩＯＭＭＵが存在する可能性が高い。

【0102】

特徴及び要素が特定の組み合わせで上に説明されているが、各特徴又は要素は、他の特徴及び要素を用いずに単独で、又は、他の特徴及び要素を用いて若しくは用いずに様々な組み合わせで使用することができる。いくつかの実施形態において本明細書に記載される装置は、汎用コンピュータ又はプロセッサによる実施のために非一時的なコンピュータ可読記憶媒体に組み込まれるコンピュータプログラム、ソフトウェア又はファームウェアにおいて実施され得る。コンピュータ可読記憶媒体の例としては、読み取り専用メモリ（read only memory、ＲＯＭ）、ランダムアクセスメモリ（random－access memory、RAM）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体（例えば、内蔵ハードディスク及びリムーバブルディスク）、磁気光学媒体、並びに、光学媒体（例えば、ＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk、ＤＶＤ））が挙げられる。

【0103】

様々な実施形態の前述の詳細な説明では、その一部を形成し、本発明を実施することができる特定の好ましい実施形態を例として示す添付図面を参照した。これらの実施形態は、当業者が本発明を実施することを可能にするために十分詳細に説明されており、他の実施形態が利用されてもよく、本発明の範囲から逸脱することなく論理的、機械的及び電気的変更が行われてもよいことを理解されたい。当業者が本発明を実施することを可能にするために必要でない詳細を避けるために、説明は、当業者に知られている特定の情報を省略する場合がある。更に、本開示の教示を組み込む多くの他の様々な実施形態が、当業者によって容易に構築され得る。したがって、本発明は、本明細書に記載の特定の形態に限定されることを意図するものではなく、逆に、本発明の範囲内に合理的に含まれ得るそのような代替形態、修正形態及び均等物を包含することを意図するものである。したがって、前述の詳細な説明は、限定的な意味で解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲によってのみ定義される。本明細書に記載される実施形態及び実施例の上記の詳細な説明は、限定ではなく、例示及び説明のためにのみ提示されている。例えば、説明された動作は、任意の好適な順序又は方法で行われる。したがって、本発明は、上記で開示され、本明細書で特許請求される基本的な基礎原理の範囲内に入るあらゆる修正、変形又は等価物を包含することが企図される。

【0104】

上記の詳細な説明及びそこに記載される実施例は、限定のためではなく、例示及び説明のためにのみ提示されている。

【図1】