ＤＭＡセキュリティチェック回路及びＤＭＡセキュリティチェック方法
【課題】ＩＯ ＴＬＢ（I/O Translation Look aside Buffer）でキャッシュミスした場合にＤＭＡが待たされることを防止する。
【解決手段】ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路が、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断する。
【解決手段】ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路が、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスに関し、より詳細には、各ＤＭＡ（Direct Memory Access）のアドレスが妥当であるか否かのチェックに関する。
【背景技術】
【０００２】
一般的なコンピュータシステムの構成及び動作について図１を参照して説明する。
【０００３】
図１を参照すると、一般的なコンピュータシステムはメモリ１００、ＣＰＵ２００、ルートコンプレックス３００及びＨＢＡ４００を有する。
【０００４】
また、メモリ１００上にはＴＬＢ（Translation Look aside Buffer）１１０が設けられている。
【０００５】
ルートコンプレックス３００はＣＰＵ２００のサウスブリッジとして存在する。なお、ルートコンプレックス３００を複数の任意の個数のＣＰＵでシェアする事も可能である。ＣＰＵ２００は別ポートでメモリ１００に接続され、ルートコンプレックス３００からのリクエスト、ＣＰＵ２００からのリプライデータを適宜ＣＰＵ２００にてルーティングする。ルートコンプレックス３００は配下にＨＢＡ４００を複数個持つ。そして、ルートコンプレックス３００は、ＣＰＵ２００からＨＢＡ４００へのリード・ライト、あるいはＨＢＡ４００からのＤＭＡ要求を適切なＣＰＵ２００へ、またそのリプライを適切なＨＢＡ４００へルーティングする。
【０００６】
一方、近年ＯＳ（Operating System）の仮想化技術により、図１に示すような１つのシステム上で複数のＯＳが混在して動作することが可能となった。しかしながら安全で安定した装置で在るためには、複数のＯＳがそれぞれ互いのメモリ領域を侵犯しないことが重要となる。
【０００７】
この点、ＣＰＵが直接行うメモリトランザクションに関してはゲストＯＳに提示するページ情報によって、複数のＯＳがそれぞれ互いのメモリ領域を侵犯しないことを達成できる。
【０００８】
一方、一般的な仕様である物理アドレスでメモリを直接操作するＩ／Ｏ ＤＭＡは、ＣＰＵが直接関与しない所で発生するので、ゲストＯＳ間での干渉のチェックが必要であり、この干渉のチェックを行うために少なからずＩ／Ｏ性能か、使用できるＩ／Ｏ数か、の何れかを制限しなくてはならないというトレードオフが発生していた。
【０００９】
上述の問題を解消するために、現在ＰＣＩ−ＳＩＧでＩＯＶの仕様化を策定中である。ＩＯＶは一つのＨＢＡ上に複数のＨＢＡが存在しているかの様に見せる事が可能であり、それぞれのゲストＯＳに異なるＨＢＡとして見せることが可能である。図２を参照するとＨＢＡ４００上に仮想ＨＢＡが複数（例として、仮想ＨＢＡ４０１−１、４０１−２及び４０１−ｎを図示する。）存在するように見せていることが分かる。
【００１０】
また、ＤＭＡリクエストに対してチェックを行う事により、ゲストＯＳ間の干渉を監視する。
【００１１】
このような、ＩＯＶを利用した技術の具体例として、例えば特許文献１に記載の技術が挙げられる。特許文献１に記載の技術では、ＩＯＶによる仮想化及びリクエストに対してのチェックを利用する。物理的には一つのホスト２で二つの仮想マシン（ＶＭ０，ＶＭ１）を動作させる。これら二つの仮想マシンは同じプログラムを実行し、同一の演算処理を行なっている。そして、仮想インターフェースＶＩＦ０，ＶＩＦ１へのアクセスを、Ｉ／Ｏデバイス１内部に備えられたcheckerよって一致しているかどうか検査する、これによりＩ／Ｏデバイスに対するＩ／Ｏアクセスの信頼性を向上させることが可能となる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００９−２３８０６８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
上述したように、ＩＯＶは一般的に利用されている。しかしながらＩＯＶにおいては、解決すべき課題が存在している。この課題について説明するためにＩＯＶについて更に詳細に説明する。
【００１４】
具体的には、ＤＭＡに含まれるリクエストＩＤにはバス番号、デバイス番号、ファンクション番号が含まれており、これとゲストＯＳが対応付けられている。更にゲストＯＳと論理空間はＴＬＢにより対応付けられている。そのため、リクエストＩＤよりゲストＯＳを特定し、ＤＭＡのアドレスがそのゲストＯＳ用の空間であるかをチェックすれば良い。これを実現する為、ＩＯＶではチェック機構の簡易化のために、ＤＭＡを論理アドレスで行わせる仕様としている。もっとも、論理アドレスそのままではメモリ側に発行できないので、ルートコンプレックスにて論理から物理に変換する機構が新たに設けられている。この機構はメモリ上のＴＬＢに対し、その変換結果をＩＯ ＴＬＢ（I/O Translation Look aside Buffer）としてルートコンプレックス上に持ち、ＤＭＡリクエストに対してＩＯ ＴＬＢを索引してアドレス変換を行うものである。
【００１５】
しかしながら、上述のようなＩＯＶにおいては、次のような課題がある。
【００１６】
第１の課題は、ＩＯ ＴＬＢでキャッシュミスした場合にＤＭＡが待たされるということである。
【００１７】
第２の課題は、ＯＳの仮想数が増えると必要なＩ／Ｏ数も増えるため、ＩＯ ＴＬＢのサイズが仮想数とＩ／Ｏ性能を決定する要因となる事である。
【００１８】
そこで、本発明はＤＭＡの待ち合わせを発生させずに、小さなサイズのＩＯ ＴＬＢでもＩ／Ｏ性能を低下させることが無く、ＤＭＡ監視が可能な、ＤＭＡセキュリティチェック回路及びＤＭＡセキュリティチェック方法を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の第１の観点によれば、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路において、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック回路が提供される。
【００２０】
本発明の第２の観点によれば、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスが行うＤＭＡ（Direct Memory Access）セキュリティチェック方法において、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック方法が提供される。
【発明の効果】
【００２１】
本発明によれば、ディスクリプタフェッチ時にゲストＯＳとアドレス妥当性を検証していることから、ＤＭＡが待たされることを無くすことが可能となる。
【００２２】
また、本発明によれば、ディスクリプタフェッチ時にアドレス変換を行うことから小さなサイズのＩＯ ＴＬＢであってもＩ／Ｏ性能を低下させないことが可能となる。
【図面の簡単な説明】
【００２３】
【図１】一般的なコンピュータシステムの基本的構成を表す図である。
【図２】仮想ＨＢＡについて示すイメージ図である。
【図３】本発明の実施形態の基本的構成を表す図である。
【図４】ＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて表す図である。
【図５】本発明の実施形態の基本的動作を表すフローチャートである。
【発明を実施するための形態】
【００２４】
次に、本発明の実施形態について図面を用いて詳細に説明する。
【００２５】
図３を参照すると、本実施形態はルートコンプレックス３００と、ＨＢＡ４００を有する。ルートコンプレックス３００は、図１に示したようにＣＰＵ２００と接続されている。ここで、ルートコンプレックス３００は、本願発明における「ＤＭＡセキュリティチェック回路」に相当する。なお図１に示した構成については既に説明をしているため、再度の説明は省略する。
【００２６】
また、本実施形態のルートコンプレックス３００はＩＯ ＴＬＢ３１０、アドレス変換部３２０、区間一致判定部３３０、ポート選択部３４０、アドレス抽出部３５０及びディスクリプタ検知部３６０を有する。
【００２７】
ここで本実施形態の各部について説明するにあたり、前提として、仮想ＯＳを一つの装置に混在させる一般的技術及びＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて説明する。
【００２８】
仮想ＯＳを一つの装置に混在させる一般的技術には、各ゲストＯＳのＩ／Ｏ ＤＭＡ転送を互いの物理メモリ領域の干渉を無くすように監視するという課題が合った。その課題を克服する為に一般的には３つの手段が存在する。
【００２９】
１つ目はサービスＶＭモデルで、各ゲストＯＳが行うＨＢＡへのアクセスは全てホストＯＳを介して行い、ホストＯＳにて監視するという方法である。課題としてはゲストＯＳの改造が必要になるのと、ホストＯＳ側でどのゲストＯＳに対し実行するかの調停が発生する為、Ｉ／Ｏ性能が出ない点が上げられる。
【００３０】
２つ目はハイパーバイザーモデルで、ハイパーバイザーで各ゲストＯＳのＩ／Ｏ命令をエミュレーションする事により行う。監視と言う点では１つ目と同じではあるが、各ゲストＯＳ毎にエミュレータを割り付けられるので調停が無く、性能面では多少優位にある。課題としては仮想数によりハイパーバイザーが巨大になってしまうのと、エミュレーションのためＨＢＡの特殊機能はサポートが難しく、標準的な機能に留まる点が上げられる。
【００３１】
３つ目はゲストＯＳ毎に異なるＨＢＡを割り付ける方法で、性能面では単一ＯＳと遜色無く、ＨＢＡの特殊機能も利用可能となる。しかし、課題としてはゲストＯＳ数の分だけＩ／Ｏ数が必要となるので、搭載可能なＩ／Ｏ数により構成できる仮想数が制限されてしまう点がある。
【００３２】
上述した課題を克服するべく、近年Ｉ／Ｏの仮想化（ＩＯＶ）が標準化されようとしている。ＩＯＶではＨＢＡ内も仮想化させ、バス番号、デバイス番号、ファンクション番号等が異なるデバイスとしてＯＳ側に見せる事が可能となる。このことから、図２に示すように単一の物理ポートしか持たないＨＢＡであっても、ＨＢＡの空間としては複数個持つ事が可能となる。
【００３３】
また、ＤＭＡアドレスの干渉チェックは、一般的には物理アドレスで行われていたＤＭＡを論理アドレスで行う事により、ＤＭＡパケットのリクエストＩＤに含まれるバス番号、デバイス番号、ファンクション番号と、アクセスしようとしている論理空間が予め設定された紐付けと合致しているかどうかをルートコンプレックス（チップセット）にて行う。この為、ルートコンプレックスには一般的には無かったＩＯ ＴＬＢというメモリ上にあるＴＬＢのキャッシュが必要となり、ＤＭＡリクエスト内のアドレスに対して論理空間から物理空間への変換が必要性となった。課題としてはＩＯ ＴＬＢは論理アドレスから物理アドレスに変換する際の変換結果をキャッシュしたものであり、ゲストＯＳの仮想数が増えてＤＭＡが多数入り混じるとＩＯ ＴＬＢのキャッシュミスを誘発し、結果メモリ上にて再度変換の必要性が生じる。このため仮想ＯＳの多重度の高いシステムにおいては、ＤＭＡの待ち合わせが発生するかもしれず、ＩＯ ＴＬＢのサイズが許容する仮想数と、Ｉ／Ｏ性能を決定する要因となってしまう点である。
【００３４】
図４を参照して、ＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて詳細に説明する。図４に示すルートコンプレックス３００は、ＩＯ ＴＬＢ３１０、アドレス変換部３２０及び区間一致判定部３３０を有する。
【００３５】
ＨＢＡ４００より上げられる全てのＤＭＡリクエストに対しアドレス変換部３２０にて論理アドレスから物理アドレスに変換する。
【００３６】
変換はＩＯ ＴＬＢ３１０に対し論理アドレスにて索引し、物理アドレスを得ることにより行われる。この際に、ＩＯ ＴＬＢ３１０は索引として与えられた論理アドレスの登録が無かった場合はＣＰＵ２００に対して変換を要求する。変換した結果はキャッシュとしてＩＯ ＴＬＢ３１０に登録するため、一つのエントリをＬＲＵ（Least Recently Used）に従い置き換える。区間一致判定部３３０はリクエストＩＤと論理アドレスが同一ＯＳに対して割当てられているものかどうかを判定し、合致しない場合はリクエストに呼応したコンプリーションを例外としてＨＢＡ４００側に返す。
【００３７】
一方、本実施形態では、図４に示したルートコンプレックス３００のようにデータの送受信を行うＤＭＡ時にチェックを行うのでは無く、ディスクリプタフェッチのＤＭＡ時にリプライデータに含まれるアドレス部分をチェックする事により各ゲストＯＳ間の干渉のチェック行う。これを実現するにはＩＯＶの標準仕様に対し以下の３つの改造が必要である。
【００３８】
１つ目はＩＯＶのＤＭＡを論理アドレスでは無く、通常通り物理アドレスで行わせる点である。これによりデバイスとの送受信ＤＭＡ発行時には待ち合わせが発生しない。
【００３９】
２つ目はＤＭＡリードで要求されたアドレスがディスクリプタ領域であるかどうかを検知する為、予めディスクリプタ領域の論理メモリアドレスを登録しておき、合致した場合はそのリプライを監視する手段が必要である。
【００４０】
３つ目はそのリプライデータの何処にバッファのアドレスが書かれているかの登録がルートコンプレックス側に必要となり、抽出したアドレスに対して論理アドレスから物理アドレスへの変換が必要である。
【００４１】
次に、図２を参照して本実施形態の説明に戻る。
【００４２】
図２においてはＩＯ ＴＬＢ３１０は、アドレス変換部３２０から送られてくる論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録する。
【００４３】
ディスクリプタ検知部３６０は、ＤＭＡリード要求に対し物理アドレスを取得し、そのアドレスが予め登録されているディスクリプタ領域であるかを判定する。
【００４４】
アドレス抽出部３５０は、ディスクリプタフェッチに対するリプライデータからアドレス部分を抽出する。
【００４５】
アドレス変換部３２０は、ディスクリプタに含まれる論理アドレスを物理アドレスに変換する。変換の際にＩＯ ＴＬＢ３１０を索引する。変換したアドレスはＤＭＡのコンプリーションデータとしてＨＢＡ４００に返却する。
【００４６】
空間一致判定部３３０は、アドレス抽出部３５０で抽出したアドレスと、リプライデータに含まれるリクエストＩＤとで予め設定された各ゲストＯＳに対する対応が取れているかを判定する。判定した結果、一致が取れない場合はシステム例外としてエラーをＣＰＵ２００に報告する。
【００４７】
ポート選択部３４０は一般的なポート選択部である。通常ルートコンプレックス３００配下には複数のＰＣＩ Ｅｘｐｒｅｓｓポートが存在し、どのＨＢＡ４００のリクエストを選択するかの調停を行う。通常はメモリ側に発行できるリクエスト数は制限しているため、制限数を越えた場合はクレジットが無い事を宣言してＨＢＡ４００側に待たせる役目も果たす。ＤＭＡリードの場合はコンプリーションバッファのサイズにより使用可能なクレジット数が決まっている。
【００４８】
図３及び図５のフローチャートを参照して本実施形態の動作について説明する。
【００４９】
まず、ルートコンプレックス３００がＨＢＡ４００からのＤＭＡリード要求を受ける（ステップＳ１０）。そしてルートコンプレックス３００はこのＤＭＡリード要求に対し、ディスクリプタ検知部３６０により該ＤＭＡがディスクリプタフェッチかどうかを判定する（ステップＳ１１）。
【００５０】
そして、ディスクリプタフェッチであった場合は（ステップＳ１１においてＹｅｓ）アドレス抽出部３５０にリクエストＩＤを通知する（ステップＳ１２）。
【００５１】
アドレス抽出部３５０はリクエストＩＤと一致するリプライデータの中からバッファアドレス部分を抽出し、アドレス変換部３２０と空間一致判定部３３０に引き渡す（ステップＳ１３）。
【００５２】
アドレス変換部３２０は論理アドレスにてＩＯ ＴＬＢ３１０を索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとしてＨＢＡ４００に引き渡す（ステップＳ１４）。
【００５３】
但し空間一致判定部３３０でゲストＯＳ間の干渉チェックを並行して行う。具体的には、アドレス抽出部３５０で抽出したアドレスと、リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し（ステップＳ１５）、論理アドレスとリクエストＩＤの対応一致がとれたもの（同じゲスト空間のもの）のみをコンプリーションとして返却し（ステップＳ１５においてＹｅｓ、ステップＳ１６）、一致しない場合は（ステップＳ１５においてＮｏ）システム例外としてエラーをＣＰＵに報告する（ステップＳ１７）。
【００５４】
以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。
【００５５】
第１の効果はキャッシュミスの不特定要因による性能の劣化が無くなることである。
【００５６】
その理由は、ディスクリプタフェッチ時にゲストＯＳとアドレスの妥当性を検証しているので、デバイスとのデータ送受信の為のＤＭＡは止まる事無く動作できるからである。
【００５７】
第２の効果はハードウェア資源を節約出来ることである。
【００５８】
その理由は、ディスクリプタフェッチ時にアドレス変換を行うので、多数のゲストＯＳによるＤＭＡが入り混じった状況下においてＩＯ ＴＬＢのキャッシュが小さなサイズであっても、一度のキャッシュフィルでディスクリプタ内全ての変換が可能だからである。
【００５９】
なお、本発明の実施形態であるＤＭＡセキュリティチェック回路は、ハードウェアにより実現することもできるが、コンピュータをそのＤＭＡセキュリティチェック回路として機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００６０】
また、本発明の実施形態によるＤＭＡセキュリティチェック方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００６１】
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【産業上の利用可能性】
【００６２】
本発明は、例えばクラウド、ブレードサーバ等の仮想化を行えるコンピュータシステムに好適である。
【符号の説明】
【００６３】
１００ メモリ
１１０ ＴＬＢ
２００ ＣＰＵ
３００ ルートコンプレックス
３１０ ＩＯ ＴＬＢ
３２０ アドレス変換部
３３０ 区間一致判定部
３４０ ポート選択部
３５０ アドレス抽出部
３６０ ディスクリプタ検知部
４００ ＨＢＡ
【技術分野】
【０００１】
本発明は、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスに関し、より詳細には、各ＤＭＡ（Direct Memory Access）のアドレスが妥当であるか否かのチェックに関する。
【背景技術】
【０００２】
一般的なコンピュータシステムの構成及び動作について図１を参照して説明する。
【０００３】
図１を参照すると、一般的なコンピュータシステムはメモリ１００、ＣＰＵ２００、ルートコンプレックス３００及びＨＢＡ４００を有する。
【０００４】
また、メモリ１００上にはＴＬＢ（Translation Look aside Buffer）１１０が設けられている。
【０００５】
ルートコンプレックス３００はＣＰＵ２００のサウスブリッジとして存在する。なお、ルートコンプレックス３００を複数の任意の個数のＣＰＵでシェアする事も可能である。ＣＰＵ２００は別ポートでメモリ１００に接続され、ルートコンプレックス３００からのリクエスト、ＣＰＵ２００からのリプライデータを適宜ＣＰＵ２００にてルーティングする。ルートコンプレックス３００は配下にＨＢＡ４００を複数個持つ。そして、ルートコンプレックス３００は、ＣＰＵ２００からＨＢＡ４００へのリード・ライト、あるいはＨＢＡ４００からのＤＭＡ要求を適切なＣＰＵ２００へ、またそのリプライを適切なＨＢＡ４００へルーティングする。
【０００６】
一方、近年ＯＳ（Operating System）の仮想化技術により、図１に示すような１つのシステム上で複数のＯＳが混在して動作することが可能となった。しかしながら安全で安定した装置で在るためには、複数のＯＳがそれぞれ互いのメモリ領域を侵犯しないことが重要となる。
【０００７】
この点、ＣＰＵが直接行うメモリトランザクションに関してはゲストＯＳに提示するページ情報によって、複数のＯＳがそれぞれ互いのメモリ領域を侵犯しないことを達成できる。
【０００８】
一方、一般的な仕様である物理アドレスでメモリを直接操作するＩ／Ｏ ＤＭＡは、ＣＰＵが直接関与しない所で発生するので、ゲストＯＳ間での干渉のチェックが必要であり、この干渉のチェックを行うために少なからずＩ／Ｏ性能か、使用できるＩ／Ｏ数か、の何れかを制限しなくてはならないというトレードオフが発生していた。
【０００９】
上述の問題を解消するために、現在ＰＣＩ−ＳＩＧでＩＯＶの仕様化を策定中である。ＩＯＶは一つのＨＢＡ上に複数のＨＢＡが存在しているかの様に見せる事が可能であり、それぞれのゲストＯＳに異なるＨＢＡとして見せることが可能である。図２を参照するとＨＢＡ４００上に仮想ＨＢＡが複数（例として、仮想ＨＢＡ４０１−１、４０１−２及び４０１−ｎを図示する。）存在するように見せていることが分かる。
【００１０】
また、ＤＭＡリクエストに対してチェックを行う事により、ゲストＯＳ間の干渉を監視する。
【００１１】
このような、ＩＯＶを利用した技術の具体例として、例えば特許文献１に記載の技術が挙げられる。特許文献１に記載の技術では、ＩＯＶによる仮想化及びリクエストに対してのチェックを利用する。物理的には一つのホスト２で二つの仮想マシン（ＶＭ０，ＶＭ１）を動作させる。これら二つの仮想マシンは同じプログラムを実行し、同一の演算処理を行なっている。そして、仮想インターフェースＶＩＦ０，ＶＩＦ１へのアクセスを、Ｉ／Ｏデバイス１内部に備えられたcheckerよって一致しているかどうか検査する、これによりＩ／Ｏデバイスに対するＩ／Ｏアクセスの信頼性を向上させることが可能となる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００９−２３８０６８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
上述したように、ＩＯＶは一般的に利用されている。しかしながらＩＯＶにおいては、解決すべき課題が存在している。この課題について説明するためにＩＯＶについて更に詳細に説明する。
【００１４】
具体的には、ＤＭＡに含まれるリクエストＩＤにはバス番号、デバイス番号、ファンクション番号が含まれており、これとゲストＯＳが対応付けられている。更にゲストＯＳと論理空間はＴＬＢにより対応付けられている。そのため、リクエストＩＤよりゲストＯＳを特定し、ＤＭＡのアドレスがそのゲストＯＳ用の空間であるかをチェックすれば良い。これを実現する為、ＩＯＶではチェック機構の簡易化のために、ＤＭＡを論理アドレスで行わせる仕様としている。もっとも、論理アドレスそのままではメモリ側に発行できないので、ルートコンプレックスにて論理から物理に変換する機構が新たに設けられている。この機構はメモリ上のＴＬＢに対し、その変換結果をＩＯ ＴＬＢ（I/O Translation Look aside Buffer）としてルートコンプレックス上に持ち、ＤＭＡリクエストに対してＩＯ ＴＬＢを索引してアドレス変換を行うものである。
【００１５】
しかしながら、上述のようなＩＯＶにおいては、次のような課題がある。
【００１６】
第１の課題は、ＩＯ ＴＬＢでキャッシュミスした場合にＤＭＡが待たされるということである。
【００１７】
第２の課題は、ＯＳの仮想数が増えると必要なＩ／Ｏ数も増えるため、ＩＯ ＴＬＢのサイズが仮想数とＩ／Ｏ性能を決定する要因となる事である。
【００１８】
そこで、本発明はＤＭＡの待ち合わせを発生させずに、小さなサイズのＩＯ ＴＬＢでもＩ／Ｏ性能を低下させることが無く、ＤＭＡ監視が可能な、ＤＭＡセキュリティチェック回路及びＤＭＡセキュリティチェック方法を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の第１の観点によれば、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路において、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック回路が提供される。
【００２０】
本発明の第２の観点によれば、ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスが行うＤＭＡ（Direct Memory Access）セキュリティチェック方法において、ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック方法が提供される。
【発明の効果】
【００２１】
本発明によれば、ディスクリプタフェッチ時にゲストＯＳとアドレス妥当性を検証していることから、ＤＭＡが待たされることを無くすことが可能となる。
【００２２】
また、本発明によれば、ディスクリプタフェッチ時にアドレス変換を行うことから小さなサイズのＩＯ ＴＬＢであってもＩ／Ｏ性能を低下させないことが可能となる。
【図面の簡単な説明】
【００２３】
【図１】一般的なコンピュータシステムの基本的構成を表す図である。
【図２】仮想ＨＢＡについて示すイメージ図である。
【図３】本発明の実施形態の基本的構成を表す図である。
【図４】ＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて表す図である。
【図５】本発明の実施形態の基本的動作を表すフローチャートである。
【発明を実施するための形態】
【００２４】
次に、本発明の実施形態について図面を用いて詳細に説明する。
【００２５】
図３を参照すると、本実施形態はルートコンプレックス３００と、ＨＢＡ４００を有する。ルートコンプレックス３００は、図１に示したようにＣＰＵ２００と接続されている。ここで、ルートコンプレックス３００は、本願発明における「ＤＭＡセキュリティチェック回路」に相当する。なお図１に示した構成については既に説明をしているため、再度の説明は省略する。
【００２６】
また、本実施形態のルートコンプレックス３００はＩＯ ＴＬＢ３１０、アドレス変換部３２０、区間一致判定部３３０、ポート選択部３４０、アドレス抽出部３５０及びディスクリプタ検知部３６０を有する。
【００２７】
ここで本実施形態の各部について説明するにあたり、前提として、仮想ＯＳを一つの装置に混在させる一般的技術及びＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて説明する。
【００２８】
仮想ＯＳを一つの装置に混在させる一般的技術には、各ゲストＯＳのＩ／Ｏ ＤＭＡ転送を互いの物理メモリ領域の干渉を無くすように監視するという課題が合った。その課題を克服する為に一般的には３つの手段が存在する。
【００２９】
１つ目はサービスＶＭモデルで、各ゲストＯＳが行うＨＢＡへのアクセスは全てホストＯＳを介して行い、ホストＯＳにて監視するという方法である。課題としてはゲストＯＳの改造が必要になるのと、ホストＯＳ側でどのゲストＯＳに対し実行するかの調停が発生する為、Ｉ／Ｏ性能が出ない点が上げられる。
【００３０】
２つ目はハイパーバイザーモデルで、ハイパーバイザーで各ゲストＯＳのＩ／Ｏ命令をエミュレーションする事により行う。監視と言う点では１つ目と同じではあるが、各ゲストＯＳ毎にエミュレータを割り付けられるので調停が無く、性能面では多少優位にある。課題としては仮想数によりハイパーバイザーが巨大になってしまうのと、エミュレーションのためＨＢＡの特殊機能はサポートが難しく、標準的な機能に留まる点が上げられる。
【００３１】
３つ目はゲストＯＳ毎に異なるＨＢＡを割り付ける方法で、性能面では単一ＯＳと遜色無く、ＨＢＡの特殊機能も利用可能となる。しかし、課題としてはゲストＯＳ数の分だけＩ／Ｏ数が必要となるので、搭載可能なＩ／Ｏ数により構成できる仮想数が制限されてしまう点がある。
【００３２】
上述した課題を克服するべく、近年Ｉ／Ｏの仮想化（ＩＯＶ）が標準化されようとしている。ＩＯＶではＨＢＡ内も仮想化させ、バス番号、デバイス番号、ファンクション番号等が異なるデバイスとしてＯＳ側に見せる事が可能となる。このことから、図２に示すように単一の物理ポートしか持たないＨＢＡであっても、ＨＢＡの空間としては複数個持つ事が可能となる。
【００３３】
また、ＤＭＡアドレスの干渉チェックは、一般的には物理アドレスで行われていたＤＭＡを論理アドレスで行う事により、ＤＭＡパケットのリクエストＩＤに含まれるバス番号、デバイス番号、ファンクション番号と、アクセスしようとしている論理空間が予め設定された紐付けと合致しているかどうかをルートコンプレックス（チップセット）にて行う。この為、ルートコンプレックスには一般的には無かったＩＯ ＴＬＢというメモリ上にあるＴＬＢのキャッシュが必要となり、ＤＭＡリクエスト内のアドレスに対して論理空間から物理空間への変換が必要性となった。課題としてはＩＯ ＴＬＢは論理アドレスから物理アドレスに変換する際の変換結果をキャッシュしたものであり、ゲストＯＳの仮想数が増えてＤＭＡが多数入り混じるとＩＯ ＴＬＢのキャッシュミスを誘発し、結果メモリ上にて再度変換の必要性が生じる。このため仮想ＯＳの多重度の高いシステムにおいては、ＤＭＡの待ち合わせが発生するかもしれず、ＩＯ ＴＬＢのサイズが許容する仮想数と、Ｉ／Ｏ性能を決定する要因となってしまう点である。
【００３４】
図４を参照して、ＰＣＩ−ＳＩＧが策定中のＩＯＶに対応したルートコンプレックスについて詳細に説明する。図４に示すルートコンプレックス３００は、ＩＯ ＴＬＢ３１０、アドレス変換部３２０及び区間一致判定部３３０を有する。
【００３５】
ＨＢＡ４００より上げられる全てのＤＭＡリクエストに対しアドレス変換部３２０にて論理アドレスから物理アドレスに変換する。
【００３６】
変換はＩＯ ＴＬＢ３１０に対し論理アドレスにて索引し、物理アドレスを得ることにより行われる。この際に、ＩＯ ＴＬＢ３１０は索引として与えられた論理アドレスの登録が無かった場合はＣＰＵ２００に対して変換を要求する。変換した結果はキャッシュとしてＩＯ ＴＬＢ３１０に登録するため、一つのエントリをＬＲＵ（Least Recently Used）に従い置き換える。区間一致判定部３３０はリクエストＩＤと論理アドレスが同一ＯＳに対して割当てられているものかどうかを判定し、合致しない場合はリクエストに呼応したコンプリーションを例外としてＨＢＡ４００側に返す。
【００３７】
一方、本実施形態では、図４に示したルートコンプレックス３００のようにデータの送受信を行うＤＭＡ時にチェックを行うのでは無く、ディスクリプタフェッチのＤＭＡ時にリプライデータに含まれるアドレス部分をチェックする事により各ゲストＯＳ間の干渉のチェック行う。これを実現するにはＩＯＶの標準仕様に対し以下の３つの改造が必要である。
【００３８】
１つ目はＩＯＶのＤＭＡを論理アドレスでは無く、通常通り物理アドレスで行わせる点である。これによりデバイスとの送受信ＤＭＡ発行時には待ち合わせが発生しない。
【００３９】
２つ目はＤＭＡリードで要求されたアドレスがディスクリプタ領域であるかどうかを検知する為、予めディスクリプタ領域の論理メモリアドレスを登録しておき、合致した場合はそのリプライを監視する手段が必要である。
【００４０】
３つ目はそのリプライデータの何処にバッファのアドレスが書かれているかの登録がルートコンプレックス側に必要となり、抽出したアドレスに対して論理アドレスから物理アドレスへの変換が必要である。
【００４１】
次に、図２を参照して本実施形態の説明に戻る。
【００４２】
図２においてはＩＯ ＴＬＢ３１０は、アドレス変換部３２０から送られてくる論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録する。
【００４３】
ディスクリプタ検知部３６０は、ＤＭＡリード要求に対し物理アドレスを取得し、そのアドレスが予め登録されているディスクリプタ領域であるかを判定する。
【００４４】
アドレス抽出部３５０は、ディスクリプタフェッチに対するリプライデータからアドレス部分を抽出する。
【００４５】
アドレス変換部３２０は、ディスクリプタに含まれる論理アドレスを物理アドレスに変換する。変換の際にＩＯ ＴＬＢ３１０を索引する。変換したアドレスはＤＭＡのコンプリーションデータとしてＨＢＡ４００に返却する。
【００４６】
空間一致判定部３３０は、アドレス抽出部３５０で抽出したアドレスと、リプライデータに含まれるリクエストＩＤとで予め設定された各ゲストＯＳに対する対応が取れているかを判定する。判定した結果、一致が取れない場合はシステム例外としてエラーをＣＰＵ２００に報告する。
【００４７】
ポート選択部３４０は一般的なポート選択部である。通常ルートコンプレックス３００配下には複数のＰＣＩ Ｅｘｐｒｅｓｓポートが存在し、どのＨＢＡ４００のリクエストを選択するかの調停を行う。通常はメモリ側に発行できるリクエスト数は制限しているため、制限数を越えた場合はクレジットが無い事を宣言してＨＢＡ４００側に待たせる役目も果たす。ＤＭＡリードの場合はコンプリーションバッファのサイズにより使用可能なクレジット数が決まっている。
【００４８】
図３及び図５のフローチャートを参照して本実施形態の動作について説明する。
【００４９】
まず、ルートコンプレックス３００がＨＢＡ４００からのＤＭＡリード要求を受ける（ステップＳ１０）。そしてルートコンプレックス３００はこのＤＭＡリード要求に対し、ディスクリプタ検知部３６０により該ＤＭＡがディスクリプタフェッチかどうかを判定する（ステップＳ１１）。
【００５０】
そして、ディスクリプタフェッチであった場合は（ステップＳ１１においてＹｅｓ）アドレス抽出部３５０にリクエストＩＤを通知する（ステップＳ１２）。
【００５１】
アドレス抽出部３５０はリクエストＩＤと一致するリプライデータの中からバッファアドレス部分を抽出し、アドレス変換部３２０と空間一致判定部３３０に引き渡す（ステップＳ１３）。
【００５２】
アドレス変換部３２０は論理アドレスにてＩＯ ＴＬＢ３１０を索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとしてＨＢＡ４００に引き渡す（ステップＳ１４）。
【００５３】
但し空間一致判定部３３０でゲストＯＳ間の干渉チェックを並行して行う。具体的には、アドレス抽出部３５０で抽出したアドレスと、リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し（ステップＳ１５）、論理アドレスとリクエストＩＤの対応一致がとれたもの（同じゲスト空間のもの）のみをコンプリーションとして返却し（ステップＳ１５においてＹｅｓ、ステップＳ１６）、一致しない場合は（ステップＳ１５においてＮｏ）システム例外としてエラーをＣＰＵに報告する（ステップＳ１７）。
【００５４】
以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。
【００５５】
第１の効果はキャッシュミスの不特定要因による性能の劣化が無くなることである。
【００５６】
その理由は、ディスクリプタフェッチ時にゲストＯＳとアドレスの妥当性を検証しているので、デバイスとのデータ送受信の為のＤＭＡは止まる事無く動作できるからである。
【００５７】
第２の効果はハードウェア資源を節約出来ることである。
【００５８】
その理由は、ディスクリプタフェッチ時にアドレス変換を行うので、多数のゲストＯＳによるＤＭＡが入り混じった状況下においてＩＯ ＴＬＢのキャッシュが小さなサイズであっても、一度のキャッシュフィルでディスクリプタ内全ての変換が可能だからである。
【００５９】
なお、本発明の実施形態であるＤＭＡセキュリティチェック回路は、ハードウェアにより実現することもできるが、コンピュータをそのＤＭＡセキュリティチェック回路として機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００６０】
また、本発明の実施形態によるＤＭＡセキュリティチェック方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００６１】
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【産業上の利用可能性】
【００６２】
本発明は、例えばクラウド、ブレードサーバ等の仮想化を行えるコンピュータシステムに好適である。
【符号の説明】
【００６３】
１００ メモリ
１１０ ＴＬＢ
２００ ＣＰＵ
３００ ルートコンプレックス
３１０ ＩＯ ＴＬＢ
３２０ アドレス変換部
３３０ 区間一致判定部
３４０ ポート選択部
３５０ アドレス抽出部
３６０ ディスクリプタ検知部
４００ ＨＢＡ
【特許請求の範囲】
【請求項１】
ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路において、
ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック回路。
【請求項２】
請求項１に記載のセキュリティチェック回路において、
前記リプライデータから抽出された論理アドレスを物理アドレスに変換するために、予めディスクリプタの書式をアドレス別に登録していることを特徴とするセキュリティチェック回路。
【請求項３】
請求項１又は２に記載のセキュリティチェック回路において、
前記ディスクリプタフェッチを検知した場合に前記リプライデータから抽出された論理アドレスを物理アドレスに変換することによりコンプリーションデータを生成し当該コンプリーションデータを前記ＨＢＡに引き渡すことを特徴とするセキュリティチェック回路。
【請求項４】
請求項１乃至３の何れか１項に記載のセキュリティチェック回路において、
前記判定の結果適切であると判断できなかった場合は、システム例外としてエラーをＣＰＵに報告することを特徴とするセキュリティチェック回路。
【請求項５】
請求項１乃至４の何れか１項に記載のセキュリティチェック回路において、
問い合わせを受けた論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録するＩＯ ＴＬＢ（I/O Translation Look aside Buffer）と、
前記ＨＢＡからのＤＭＡリード要求に対し、該ＤＭＡがディスクリプタフェッチかどうかを判定するディスクリプタ検知手段と、
前記ＤＭＡがディスクリプタフェッチだった場合に当該ＤＭＡの前記リクエストＩＤを通知され、当該リクエストＩＤと一致するリプライデータの中からアドレス部分を抽出するアドレス抽出手段と、
前記抽出されたアドレスに基づき前記ＩＯ ＴＬＢを索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとするアドレス変換手段と、
前記アドレス変換手段の動作と並行して前記アドレスが適切か否かの判断を行う空間一致判定手段と、
を備えることを特徴とするセキュリティチェック回路。
【請求項６】
ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスが行うＤＭＡ（Direct Memory Access）セキュリティチェック方法において、
ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック方法。
【請求項７】
請求項６に記載のセキュリティチェック方法において、
前記リプライデータから抽出された論理アドレスを物理アドレスに変換するために、予めディスクリプタの書式をアドレス別に登録していることを特徴とするセキュリティチェック方法。
【請求項８】
請求項６又は７に記載のセキュリティチェック方法において、
前記ディスクリプタフェッチを検知した場合に前記リプライデータから抽出された論理アドレスを物理アドレスに変換することによりコンプリーションデータを生成し当該コンプリーションデータを前記ＨＢＡに引き渡すことを特徴とするセキュリティチェック方法。
【請求項９】
請求項６乃至８の何れか１項に記載のセキュリティチェック方法において、
前記判定の結果適切であると判断できなかった場合は、システム例外としてエラーをＣＰＵに報告することを特徴とするセキュリティチェック方法。
【請求項１０】
請求項６乃至９の何れか１項に記載のセキュリティチェック方法において、
問い合わせを受けた論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録するＩＯ ＴＬＢ（I/O Translation Look aside Buffer）を用意するステップと、
前記ＨＢＡからのＤＭＡリード要求に対し、該ＤＭＡがディスクリプタフェッチかどうかを判定するディスクリプタ検知ステップと、
前記ＤＭＡがディスクリプタフェッチだった場合に当該ＤＭＡの前記リクエストＩＤを通知され、当該リクエストＩＤと一致するリプライデータの中からアドレス部分を抽出するアドレス抽出ステップと、
前記抽出されたアドレスに基づき前記ＩＯ ＴＬＢを索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとするアドレス変換ステップと、
前記アドレス変換ステップの動作と並行して前記アドレスが適切か否かの判断を行う空間一致判定ステップと、
を備えることを特徴とするセキュリティチェック方法。
【請求項１】
ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したＤＭＡ（Direct Memory Access）セキュリティチェック回路において、
ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック回路。
【請求項２】
請求項１に記載のセキュリティチェック回路において、
前記リプライデータから抽出された論理アドレスを物理アドレスに変換するために、予めディスクリプタの書式をアドレス別に登録していることを特徴とするセキュリティチェック回路。
【請求項３】
請求項１又は２に記載のセキュリティチェック回路において、
前記ディスクリプタフェッチを検知した場合に前記リプライデータから抽出された論理アドレスを物理アドレスに変換することによりコンプリーションデータを生成し当該コンプリーションデータを前記ＨＢＡに引き渡すことを特徴とするセキュリティチェック回路。
【請求項４】
請求項１乃至３の何れか１項に記載のセキュリティチェック回路において、
前記判定の結果適切であると判断できなかった場合は、システム例外としてエラーをＣＰＵに報告することを特徴とするセキュリティチェック回路。
【請求項５】
請求項１乃至４の何れか１項に記載のセキュリティチェック回路において、
問い合わせを受けた論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録するＩＯ ＴＬＢ（I/O Translation Look aside Buffer）と、
前記ＨＢＡからのＤＭＡリード要求に対し、該ＤＭＡがディスクリプタフェッチかどうかを判定するディスクリプタ検知手段と、
前記ＤＭＡがディスクリプタフェッチだった場合に当該ＤＭＡの前記リクエストＩＤを通知され、当該リクエストＩＤと一致するリプライデータの中からアドレス部分を抽出するアドレス抽出手段と、
前記抽出されたアドレスに基づき前記ＩＯ ＴＬＢを索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとするアドレス変換手段と、
前記アドレス変換手段の動作と並行して前記アドレスが適切か否かの判断を行う空間一致判定手段と、
を備えることを特徴とするセキュリティチェック回路。
【請求項６】
ＩＯＶ（I/O Virtualization） ＨＢＡ（Host Bus Adapter）に対応したルートコンプレックスが行うＤＭＡ（Direct Memory Access）セキュリティチェック方法において、
ＨＢＡからのＤＭＡリード要求に対しディスクリプタフェッチを検知した場合に、当該ＤＭＡリード要求のリプライデータの中から抽出した論理アドレスと、当該リプライデータに含まれるリクエストＩＤとが同じゲスト空間のものであるかを判定し、同じゲスト空間のものである場合に当該リプライデータに含まれるアドレスが適切であると判断することを特徴とするセキュリティチェック方法。
【請求項７】
請求項６に記載のセキュリティチェック方法において、
前記リプライデータから抽出された論理アドレスを物理アドレスに変換するために、予めディスクリプタの書式をアドレス別に登録していることを特徴とするセキュリティチェック方法。
【請求項８】
請求項６又は７に記載のセキュリティチェック方法において、
前記ディスクリプタフェッチを検知した場合に前記リプライデータから抽出された論理アドレスを物理アドレスに変換することによりコンプリーションデータを生成し当該コンプリーションデータを前記ＨＢＡに引き渡すことを特徴とするセキュリティチェック方法。
【請求項９】
請求項６乃至８の何れか１項に記載のセキュリティチェック方法において、
前記判定の結果適切であると判断できなかった場合は、システム例外としてエラーをＣＰＵに報告することを特徴とするセキュリティチェック方法。
【請求項１０】
請求項６乃至９の何れか１項に記載のセキュリティチェック方法において、
問い合わせを受けた論理アドレスに対してキャッシュ登録があればその物理アドレスを返却し、無い場合はＣＰＵに対し変換を要求してその結果を新たにキャッシュデータとして登録するＩＯ ＴＬＢ（I/O Translation Look aside Buffer）を用意するステップと、
前記ＨＢＡからのＤＭＡリード要求に対し、該ＤＭＡがディスクリプタフェッチかどうかを判定するディスクリプタ検知ステップと、
前記ＤＭＡがディスクリプタフェッチだった場合に当該ＤＭＡの前記リクエストＩＤを通知され、当該リクエストＩＤと一致するリプライデータの中からアドレス部分を抽出するアドレス抽出ステップと、
前記抽出されたアドレスに基づき前記ＩＯ ＴＬＢを索引して物理アドレスを取得し、得られた物理アドレスを元のディスクリプタのアドレスと置換してコンプリーションデータとするアドレス変換ステップと、
前記アドレス変換ステップの動作と並行して前記アドレスが適切か否かの判断を行う空間一致判定ステップと、
を備えることを特徴とするセキュリティチェック方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１１−２０３９３７（Ｐ２０１１−２０３９３７Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１０−６９７８２（Ｐ２０１０−６９７８２）
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]