(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続されたリモート装置に設けられたデバイスとの間でＩ／Ｏ処理を行うゲストＯＳ（Operating System）に仮想ハードウェア環境を提供するホストＯＳと、
前記ネットワークと通信するインターフェースに相当する通信手段とを備え、
前記ホストＯＳは、前記ゲストＯＳが発行したＩ／Ｏ命令をトラップするとともに、トラップした前記Ｉ／Ｏ命令をカプセル化して、前記リモート装置に向けてネットワークパケットとして送出するバス延長手段を有し、
前記リモート装置は、前記リモート装置に設けられたデバイスを示す識別子と前記リモート装置の通信部のアドレスを含む情報を送信し、
前記バス延長手段は、前記情報に基づいて、前記リモート装置に設けられたデバイスを認識するとともに、前記Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスとして前記リモート装置の通信部のアドレスを指定し、さらに、前記情報に含まれる前記リモート装置の通信部のアドレスと、前記リモート装置に設けられたデバイスを示す識別子とを関連付けて保持するテーブルを有し、前記ゲストＯＳにより発行された前記Ｉ／Ｏ命令をトラップすると、前記Ｉ／Ｏ命令の発行先のデバイスを有する前記リモート装置の通信部のアドレスを前記テーブルから抽出し、抽出したアドレスを前記Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスに指定し、
前記ホストＯＳは、前記ゲストＯＳが他のコンピュータまたは他のゲストＯＳと通信するために用いられる仮想ＮＩＣ（Network Interface Card）と、前記バス延長手段および前記仮想ＮＩＣのうちの選択した一方と前記通信部とを接続する仮想スイッチ手段とを有するデータ処理装置。
【請求項２】
前記バス延長手段は、前記送出したネットワークパケットに対する前記リモート装置からの応答ネットワークパケットを受け取ると、前記応答ネットワークパケットをデカプセル化してデータを抽出し、抽出したデータを前記ゲストＯＳに転送する請求項１に記載のデータ処理装置。
【請求項３】
前記ゲストＯＳは、前記ホストＯＳの起動後における前記ゲストＯＳの起動の際、前記ゲストＯＳが保持するデバイスドライバを用いて前記リモート装置に設けられたデバイスを初期化する請求項１から２のいずれか一項に記載のデータ処理装置。
【請求項４】
前記テーブルは、前記情報に含まれるリモート装置の通信部のアドレスと、前記リモート装置に設けられたデバイスを示す識別子と、前記リモート装置に割り当てられた前記ゲストＯＳとを関連付けて保持し、
前記バス延長手段は、前記Ｉ／Ｏ命令の発行元の前記ゲストＯＳに対して、前記Ｉ／Ｏ命令の発行先のデバイスを有する前記リモート装置が割り当てられている場合、当該リモート装置の通信部のアドレスを前記テーブルから抽出し、抽出したアドレスを前記Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスに指定する請求項１から３のいずれか一項に記載のデータ処理装置。
【請求項５】
前記リモート装置は、前記データ処理装置から前記Ｉ／Ｏ命令をカプセル化したネットワークパケットを受信すると、受信したネットワークパケットをデカプセル化して前記Ｉ／Ｏ命令を抽出して前記デバイスに転送し、
前記デバイスから前記Ｉ／Ｏ命令の実行結果のデータを取得すると、取得したデータをカプセル化して前記ホストＯＳに向けてネットワークパケットとして送出する、
請求項１から４のいずれか一項に記載のデータ処理装置。
【請求項６】
ネットワークを介して接続された請求項１から５記載のデータ処理装置およびリモート装置を備えることを特徴とするコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体等に関する。本発明は、特に、システムバス上を流れるデータを、ネットワークを介して接続されたリモート装置に転送するコンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体等に関する。
【背景技術】
【０００２】
コンピュータは、システムバス（以下「バス」ともいう。）を介して接続されたＣＰＵ（Central Processing Unit）とデバイスを備えており、ＣＰＵ上で実行されるプログラムの指示によってデバイスへのアクセスが行われる。デバイスへのアクセスは、「入出力処理」または「Ｉ／Ｏ（Input/Output）処理」と呼ばれる。一方、デバイスを制御するソフトウェアは、「ＯＳ（Operating System）」と呼ばれる。ＯＳのうちの特にデバイスを制御するためのソフトウェアは、「デバイスドライバ」と呼ばれる。また、ＯＳ上では、複数のユーザープログラムがＯＳの制御によって実行される。ユーザープログラムからデバイスに直接アクセスできないようにするために、ＯＳとユーザープログラムとでは実行権限が異なる。【０００３】
ＣＰＵの例として、Intel社のXeon（登録商標）やAtom（登録商標）などがある。一方、ＯＳの例として、Linux（登録商標）やMicrosoft社のWindows（登録商標）がある。また、システムバスの例として、ＰＣＩ（Peripheral Component Interconnect）やPCI-Expressがある。さらに、デバイスの例として、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）やネットワークインターフェースカード（ＮＩＣ：Network Interface Card）などがある。【０００４】
デバイスはコンピュータの起動時にＢＩＯＳ（Basic Input/Output System）によってスキャンされ、ＩＤ（識別子、Identifier）やメモリ領域などが割り当てられる。この時点では、デバイスは利用可能な状態ではない。ＯＳの起動後、スキャンされたデバイスのうちのＯＳが対応しているデバイスに対するデバイスドライバによって、デバイスの初期化が行われる。これにより、デバイスは利用可能な状態となる。【０００５】
実行中のＯＳがデバイスにアクセスする方法として、Ｉ／Ｏ命令の発行と、ＭＭＩＯ（Memory-Mapped I/O）によるアクセスの２通りの方法が知られている。前者の方法では、ＣＰＵの命令セットとしてＩ／Ｏ命令が定義されている。したがって、プログラムがＣＰＵ命令を発行することによってバスにＩ／Ｏリクエストが出力され、デバイスへのアクセスが行われる。一方、後者の方法では、ＯＳが特定のメモリアドレスにアクセスした際、ＣＰＵまたはバスを制御するチップセットが、これをＩ／Ｏ処理に変換してバスに出力することで、デバイスへのアクセスが行われる。上述のように、ＢＩＯＳがデバイスをスキャンするとき、デバイスが要求するメモリ空間サイズを物理メモリ空間に割り当てるため、割り当てられた物理メモリ空間へのメモリアクセスがＩ／Ｏリクエストに置き換わる。以下では、これら２つのデバイスアクセスの方法を総称して「Ｉ／Ｏ命令」という。デバイスにアクセスする際には、デバイスを特定するＩＤ（メモリアドレス、デバイスが挿入されたスロットのＩＤなど）をＩ／Ｏ命令で指定する。【０００６】
以前は、単一のＣＰＵ性能が十分ではなかったため、ＣＰＵ上では単一のＯＳが実行されていた。しかし、最近では、ＣＰＵの高性能化により、多少のソフトウェアオーバヘッドを許容できるようになってきている。これに伴い、ハードウェアを仮想化して、単一のＣＰＵ上で複数の仮想ハードウェア環境を稼働させることが可能になっている。【０００７】
図１５は、このような仮想化コンピュータの構成を例示するブロック図である。図１５に示すような仮想ハードウェア環境を管理するＯＳを、ホストＯＳ１０４と呼ぶ。一方、仮想ハードウェア環境上で実行されるＯＳを、ゲストＯＳ１０８と呼ぶ。ホストＯＳ１０４は１つであるが、ゲストＯＳ１０８は複数実行することができる。また、ゲストＯＳ１０８はホストＯＳ１０４と種類が異なってもよく、ゲストＯＳ１０８の種類が互いに異なっていてもよい。仮想ハードウェア環境を提供するホストＯＳ１０４の例として、KVM（Kernel-based Virtual Machine）やVMWare社のVMWare（登録商標）やESXiサーバなどが知られている。【０００８】
一般に、仮想化環境においては、ホストＯＳ１０４に繋がっているデバイスＢ１０３をゲストＯＳ１０８に対して直接認識させる代わりに、ゲストＯＳ１０８に対して仮想化されたデバイスＡ（以下、「仮想デバイス」という。）１０６が提供される。すなわち、ホストＯＳ１０４が有するデバイスドライバＢ１０５は、デバイスＢ１０３を制御する。一方、ゲストＯＳ１０８が有するデバイスドライバＡ１０９は、仮想デバイスＡ１０６を制御する。このとき、ゲストＯＳ１０８のデバイスドライバＡ１０９が発行したＩ／Ｏ命令をデバイスＢ１０３のデバイスドライバが解釈できるように、ホストＯＳ１０４内で変換が行われる。【０００９】
一方、デバイスの管理をホストＯＳではなくゲストＯＳのデバイスドライバが行う「パススルー技術」が、特許文献１に開示されている。特許文献１に記載された技術によると、コンピュータに繋がっている一部のデバイスを、ホストＯＳの代わりにゲストＯＳが制御することができる。【００１０】
また、バスを仮想的に延長する技術が、特許文献２に開示されている。特許文献２に記載された技術によると、PCI-Express上のデータをイーサネット（Ethernet、登録商標）などのネットワークに転送することで、ＣＰＵとデバイスの距離を物理的に延長することが可能となる。PCI-Expressバスでは、データをパケットの形式で転送している。ここで、パケットとは、２点間の通信を行うための転送単位のことであり、一般に、送信元と送信先のアドレスがパケット内に記載されている。【００１１】
図１６は、特許文献２に記載されたバス延長技術を適用したコンピュータの構成を例示するブロック図である。図１６を参照すると、特許文献２に記載された技術では、ＣＰＵ２０１側に上流ブリッジ２０２が設けられ、デバイス（周辺機器５００）側に下流ブリッジ４００が設けられている。ブリッジ２０２、４００は、パケットのカプセル化またはデカプセル化（すなわち、カプセル化の解除）を行う。カプセル化によって、Ethernetのネットワーク上にバスのデータを流すことが可能になる。Ethernetもパケットによってデータを転送しているため、以下ではネットワーク上を流れるパケットのことを「ネットワークパケット」と呼ぶ。【００１２】
また、特許文献３には、ＰＣ（Personal Computer）からネットワークを介して接続されたプリンタにデータ送信を行う場合、プリンタドライバがＰＣにおいて発生したアクセス要求に応じた制御コマンドを生成し、ＵＳＢ（Universal Serial Bus）プリンタクラスドライバが制御コマンドをＵＳＢパケットに変換し、ネットワークプロトコル層がＵＳＢパケットをネットワークパケットとしてデバイスサーバに送出する技術が記載されている。
また、特許文献４には、Ｉ／Ｏデバイスに共通する管理だけを仮想化ブリッジで行い、個別のＩ／Ｏデバイスに依存する処理は、各々の製造者から提供されるソフトウェアを用いてネットワークで接続したシステムマネージャから行う技術が記載されている。
また、特許文献５には、入出力装置がホストコンピュータシステムに動的に連結されるように、入出力装置をホストコンピュータシステム装置から分離し、当該入出力装置をシステム装置に連結する配置を提供する技術が記載されている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１０−２３７７３７号公報
【特許文献２】特開２００７−２１９８７３号公報
【特許文献３】特開２０１０−１１３６０６号公報
【特許文献４】国際公開第２０１３／１５０７９２号
【特許文献５】特表２００５−５２１１１５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。以下の分析は、本発明者によってなされたものである。【００１５】
特許文献１に記載されたパススルー技術（図１５）と、特許文献２に記載されたバス延長技術（図１６）を組み合わせることにより、ゲストＯＳがネットワークを介して接続された遠隔デバイスを直接制御するコンピュータシステムを実現することが可能となる。【００１６】
しかしながら、特許文献１、２に記載された技術を組み合わせたコンピュータシステムによると、ゲストＯＳ１０８が発行したＩ／Ｏ命令を上流ブリッジ（バス延長部（ホスト））２０２がカプセル化してネットワークに送出する必要がある。しかしながら、上流ブリッジ２０２はＰＣカード等のハードウェアとして実現されるため、ＰＣカードスロットを備えていないコンピュータ（例えば、一部のノートＰＣ、タブレット端末など）では利用することができない。したがって、ゲストＯＳがネットワークを介して接続された遠隔デバイスを直接制御するパススルー技術の適用範囲が、ゲストＯＳが稼働するコンピュータの仕様や使用状況（例えば、スロットの空きの有無等）により制限されるという問題がある。【００１７】
そこで、ネットワークを介して接続された遠隔デバイスをゲストＯＳが直接制御するパススルー技術の適用範囲を拡げることが課題となる。本発明の主たる目的は、かかる課題解決に寄与するコンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体を提供することにある。
【課題を解決するための手段】
【００１８】
本発明の第１の態様に係るデータ処理装置は、ネットワークを介して接続されたリモート装置に設けられたデバイスとの間でＩ／Ｏ処理を行うゲストＯＳ（Operating System）に仮想ハードウェア環境を提供するホストＯＳと前記ネットワークと通信するインターフェースに相当する通信手段とを備え、前記ホストＯＳは、前記ゲストＯＳが発行したＩ／Ｏ命令をトラップするとともに、トラップした前記Ｉ／Ｏ命令をカプセル化して、前記リモート装置に向けてネットワークパケットとして送出するバス延長手段を有し、前記リモート装置は、前記リモート装置に設けられたデバイスを示す識別子と前記リモート装置の通信部のアドレスを含む情報を送信し、前記バス延長手段は、前記情報に基づいて、前記リモート装置に設けられたデバイスを認識するとともに、前記Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスとして前記リモート装置の通信部のアドレスを指定し、さらに前記情報に含まれる前記リモート装置の通信部のアドレスと、前記リモート装置に設けられたデバイスを示す識別子とを関連付けて保持するテーブルを有し、前記ゲストＯＳにより発行された前記Ｉ／Ｏ命令をトラップすると、前記Ｉ／Ｏ命令の発行先のデバイスを有する前記リモート装置の通信部のアドレスを前記テーブルから抽出し、抽出したアドレスを前記Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスに指定し、前記ホストＯＳは、前記ゲストＯＳが他のコンピュータまたは他のゲストＯＳと通信するために用いられる仮想ＮＩＣ（Network Interface Card）と、前記バス延長手段および前記仮想ＮＩＣのうちの選択した一方と前記通信部とを接続する仮想スイッチ手段とを有する。
【００１９】
本発明の第２の態様に係るコンピュータシステムは、ネットワークを介して接続された第１の態様に係るデータ処理装置およびリモート装置を備える。
【発明の効果】
【００２２】
本発明に係るコンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体によると、ネットワークを介して接続された遠隔デバイスをゲストＯＳが直接制御するパススルー技術の適用範囲を拡げることが可能となる。
【図面の簡単な説明】
【００２３】
【図１】本発明の一実施形態に係るデータ処理装置を備えたコンピュータシステムの構成を例示するブロック図である。
【図２】本発明の第１の実施形態に係るコンピュータシステムの構成を例示する図である。
【図３】第１の実施形態におけるリモート装置の構成を例示するブロック図である。
【図４】第１の実施形態におけるデータ処理装置の構成を例示するブロック図である。
【図５】第１の実施形態におけるリモート装置の起動の動作を例示するフロー図である。
【図６】第１の実施形態におけるデータ処理装置の起動の動作を例示するフロー図である。
【図７】第１の実施形態におけるデータ処理装置のＩ／Ｏ命令の処理の動作を例示するフロー図である。
【図８】第１の実施形態におけるリモート装置が受け取ったネットワークパケットの処理の動作を例示するフロー図である。
【図９】第１の実施形態における遠隔デバイスが送信したデータの処理の動作を例示するフロー図である。
【図１０】第１の実施形態におけるデータ処理装置が受け取ったネットワークパケットの処理の動作を例示するフロー図である。
【図１１】本発明の第２の実施形態に係るコンピュータシステムの構成を例示する図である。
【図１２】第２の実施形態におけるバス延長部（ホスト）が保持する対応表を例示する図である。
【図１３】本発明の第３の実施形態に係るデータ処理装置の構成を例示するブロック図である。
【図１４】第３の実施形態におけるバス延長部（ホスト）が保持する対応表を例示する図である。
【図１５】仮想化コンピュータの構成を例示するブロック図である。
【図１６】バス延長技術を適用したコンピュータの構成を例示するブロック図である。
【発明を実施するための形態】
【００２４】
はじめに、一実施形態の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。
【００２５】
図１は、一実施形態に係るデータ処理装置１０を備えたコンピュータシステムの構成を例示するブロック図である。図１を参照すると、データ処理装置１０は、ネットワーク３０を介して接続されたリモート装置２０に設けられたデバイス（遠隔デバイス２６）との間でＩ／Ｏ処理を行うゲストＯＳ（Operating System）１８に対して、仮想ハードウェア環境を提供するホストＯＳ１４を備えている。ホストＯＳ１４は、ゲストＯＳ１８が発行したＩ／Ｏ命令をトラップするとともに、トラップしたＩ／Ｏ命令をカプセル化して、リモート装置２０に向けてネットワークパケットとして送出するバス延長部１６を有する。また、バス延長部１６は、送出したネットワークパケットに対するリモート装置２０からの応答ネットワークパケットを受け取ると、応答ネットワークパケットをデカプセル化してデータを抽出し、抽出したデータをゲストＯＳ１８に転送する。
【００２６】
リモート装置２０は、リモート装置２０に設けられた遠隔デバイス２６を示す識別子とリモート装置２０の通信部のアドレスを含む情報を送信する。バス延長部１６は、リモート装置２０から送信された上記情報に基づいて、リモート装置２０に設けられた遠隔デバイス２６を認識するとともに、Ｉ／Ｏ命令をカプセル化したネットワークパケットの宛先アドレスとしてリモート装置２０の通信部のアドレスを指定する。
【００２７】
一実施形態のデータ処理装置１０では、ホストＯＳ１４に設けられたバス延長部１６がゲストＯＳ１８が発行したＩ／Ｏ命令をトラップするとともに、トラップしたＩ／Ｏ命令をカプセル化して、リモート装置２０に向けてネットワークパケットとして送出する。このとき、特許文献１、２に記載された技術（図１５、図１６）を組み合わせたコンピュータシステムのように、ゲストＯＳが発行したＩ／Ｏ命令を上流ブリッジ（バス延長部（ホスト））がカプセル化してネットワークに送出する必要がなくなる。したがって、一実施形態のデータ処理装置１０によると、ゲストＯＳが遠隔デバイスを直接制御するパススルー技術の適用の可否が、ゲストＯＳが稼働するコンピュータの仕様や使用状況（スロットの空き具合など）によって制限されず、適用範囲を拡げることができる。
【００２８】
また、ゲストＯＳ１８は、ホストＯＳ１４の起動後におけるゲストＯＳ１８の起動の際、ゲストＯＳ１８が保持するデバイスドライバを用いてリモート装置２０に設けられた遠隔デバイス２６を初期化する。これにより、ゲストＯＳ１８に割り当てる遠隔デバイスを、ホストＯＳ１４の起動時に認識する必要がなくなり、ホストＯＳ１４の起動を高速化することが可能となる。
【００２９】
＜第1の実施形態＞
[構成]
次に、第１の実施形態に係るコンピュータシステムについて、図面を参照して詳細に説明する。
【００３０】
図２を参照すると、本実施形態のコンピュータシステムは、プログラム制御により動作するデータ処理装置１０と、リモート装置２０とを備えている。データ処理装置１０とリモート装置２０は、ネットワーク３０を介して接続されている。
【００３１】
図３は、リモート装置２０の構成を例示するブロック図である。以下、図３を参照して、リモート装置２０の構成について詳細に説明する。
【００３２】
リモート装置２０は、通信部２２、バス延長部（リモート）２４、および、遠隔デバイス２６を備えている。リモート装置２０は、複数の遠隔デバイス２６を有していてもよい。遠隔デバイス２６は、システムバス１９に繋がるものであればよい。遠隔デバイス２６として、例えば、バスに直接接続できるハードディスクやネットワークインターフェースカードなどがある。バス延長部（リモート）２４は、後述するバス延長部（ホスト）と対になる。バス延長部（リモート）２４は、遠隔デバイス２６向けのデータ、および、遠隔デバイス２６から送出されたバス上のデータを、それぞれ、デカプセル化およびカプセル化する。また、バス延長部（リモート）２４は、送信レート制御やネットワーク上でネットワークパケットが損失したときのための再送制御などの機能を備えていてもよい。
【００３３】
通信部２２は、ネットワーク３０と通信するためのインターフェース部である。ネットワーク３０の例として、EthernetやInfiniBand（登録商標）などがある。ただし、本発明において、ネットワーク３０はこれらに限られず、コンピュータが利用できるネットワークであればよい。通信部２２には、ネットワーク３０上で一意に特定できるようなアドレス（例えば、ＭＡＣ（Media Access Control）アドレス）が付与されている。
【００３４】
バス延長部（リモート）２４は、ネットワーク３０に向かって通信部２２経由でハートビート（ＨＢ：Heart Beat）情報を間欠的に送信する。一般に、このハートビートはブロードキャストされる。しかし、バス延長部（リモート）２４は、予めホスト側のアドレスを把握している場合、当該アドレスによって特定されるホストに対してのみハートビート情報を送出してもよい。ハートビート情報は、リモート装置２０に搭載されている遠隔デバイス２６の情報と、通信部２２のアドレスを含む。
【００３５】
図４は、データ処理装置１０の構成を例示するブロック図である。以下、図４を参照して、データ処理装置１０の構成について詳細に説明する。
【００３６】
データ処理装置１０は、ＣＰＵ１１、周辺デバイス１２および通信部１３を備えている。ＣＰＵ１１上では、ホストＯＳ１４とゲストＯＳ１８を含む各種プログラムが実行される。
【００３７】
周辺デバイス１２は、システムバス１９に接続可能なデバイスである。
【００３８】
通信部１３は、リモート装置２０の通信部２２と同様に、ネットワーク３０と通信するためのインターフェース部である。
【００３９】
ホストＯＳ１４は、仮想スイッチ部１５とバス延長部（ホスト）１６を備えている。バス延長部（ホスト）１６は、リモート装置２０のバス延長部（リモート）２４と対をなす。バス延長部（ホスト）１６は、ネットワーク３０に送出する際には、バス上を流れるデータパケットをカプセル化してからネットワークに送出する。一方、バス延長部（ホスト）１６は、ネットワーク３０からカプセル化されたネットワークパケットを受け取ると、そのカプセル化を解いて（デカプセル化して）から配下のデバイスにデータパケットを転送する。ネットワーク３０としてEthernetがあり、通信プロトコルとしてＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）などがある。ただし、本発明におけるネットワークおよび通信プロトコルは、これらに限定されない。
【００４０】
ホストＯＳ１４は、さらに仮想ＮＩＣ１７を備えていてもよい。仮想ＮＩＣ１７は、ゲストＯＳ１８が他のコンピュータと通信するため、または、複数のゲストＯＳ間で通信するために利用される仮想デバイスである。本実施形態では、図１６のコンピュータとは異なり、バス延長部（ホスト）１６と仮想ＮＩＣ１７が通信部１３を共有して利用することが可能となっている。ただし、バス延長部（ホスト）１６と仮想ＮＩＣ１７は、個別に通信部を有していてもよい。なお、仮想ＮＩＣ１７が必要でない場合、ホストＯＳ１４内の仮想スイッチ部１５を省略してもよい。
【００４１】
ゲストＯＳ１８は、リモート装置２０の遠隔デバイス２６を制御するためのデバイスドライバを備えている。
【００４２】
[動作]
次に、図５ないし図１０のフロー図を参照して本実施形態のコンピュータシステムの動作について詳細に説明する。
【００４３】
図５は、リモート装置２０の起動の流れを例示するフロー図である。以下、図５のフロー図を参照して詳細に説明する。
【００４４】
リモート装置２０を起動すると、まず、通信部２２とバス延長部（リモート）２４が起動する（ステップＳ１１）。このとき、遠隔デバイス２６には通電されるものの、遠隔デバイス２６上のハードウェアによる初期化が行われるに過ぎず、デバイスドライバによる初期化は行われない。
【００４５】
次に、バス延長部（リモート）２４は、ネットワーク３０に向かって通信部２２経由でハートビートのパケットを間欠的に送信する（ステップＳ１２）。ホストＯＳ１４が起動していない場合、ハートビートは受け取られることなく、ネットワーク３０上で破棄される。
【００４６】
図６は、データ処理装置１０の起動の流れを例示するフロー図である。以下、図６のフロー図を参照して詳細に説明する。
【００４７】
データ処理装置１０が起動すると、まず、ホストＯＳ１４が起動する（ステップＳ２１）。ホストＯＳ１４は、データ処理装置１０内にある周辺デバイス１２や通信部１３の初期化を行う。これによって、データ処理装置１０内にある通信部１３が利用可能となる。
【００４８】
次に、バス延長部（ホスト）１６と仮想スイッチ部１５が起動する（ステップＳ２２）。
【００４９】
リモート装置２０を起動するタイミングは、リモート装置２０を接続するゲストＯＳ１８の起動前であれば、任意のタイミングでよい。なお、リモート装置２０の起動時の動作は、図５を参照して説明したとおりである。
【００５０】
この時点で、リモート装置２０は起動しており、バス延長部（ホスト）１６はリモート装置２０のハートビート（ＨＢ：Heart Beat）を受け取る（ステップＳ２３）。これによって、バス延長部（ホスト）１６はリモート装置２０に繋がっている遠隔デバイス２６を認識し、その情報を取得することができる。また、バス延長部（ホスト）１６は、ハートビート情報に基づいて、リモート装置２０の通信部２２のアドレスを取得する。
【００５１】
次に、ゲストＯＳ１８を起動する（ステップＳ２４）。ゲストＯＳ１８が起動する際のデバイススキャンの際に、バス延長部（ホスト）１６は遠隔デバイス２６がゲストＯＳ１８のデバイスとして存在するように見せる。具体的には、バス延長部（ホスト）１６は、デバイススキャンのＩ／Ｏ命令をカプセル化してネットワークパケットとして仮想スイッチ部１５に送信する。そして、バス延長部（ホスト）１６は、リモート装置２０からの返答のネットワークパケットを仮想スイッチ部１５から受け取ってそれをデカプセル化してゲストＯＳ１８に渡す。ゲストＯＳ１８が当該遠隔デバイス２６に対応するデバイスドライバを有している場合、ゲストＯＳ１８は遠隔デバイス２６を初期化する（ステップＳ２５）。
【００５２】
ゲストＯＳ１８は、初期化された遠隔デバイス２６を、必要に応じてアクセスする（ステップＳ２６）。
【００５３】
特許文献１、２に記載された技術を組み合わせたコンピュータシステムによると、ホストＯＳの起動時に、ゲストＯＳに割り当てる遠隔デバイスをスキャンする必要があるため、ホストＯＳの起動に長い時間を要するという問題がある。しかし、本実施形態のデータ処理装置の起動の流れ（図６）によると、ホストＯＳの起動時には、遠隔デバイス２６を認識・初期化する必要がないため、ホストＯＳの起動を高速化することが可能となる。すなわち、本実施形態によると、ネットワークを介して接続されたデバイスをゲストＯＳに割り当て可能とする環境において、ホストＯＳの起動を高速化することが可能となる。
【００５４】
次に、ゲストＯＳ１８から遠隔デバイス２６へのＩ／Ｏの流れを説明する。
【００５５】
図７はゲストＯＳ１８が発行したＩ／Ｏ命令をホストＯＳ１４が処理する流れを例示するフロー図である。以下、図７のフロー図を参照して詳細に説明する。
【００５６】
まず、ゲストＯＳ１８がＩ／Ｏ命令を発行する（ステップＳ３１）。
【００５７】
このＩ／Ｏ命令をホストＯＳ１４がトラップし（ステップＳ３２）、ホストＯＳ１４に制御が移る。Ｉ／Ｏ命令をトラップする方法として、例えば、ゲストＯＳ１８が実行中はＩ／Ｏ命令を発行禁止にして、不正命令発行のトラップをホストＯＳ１４が捕まえる方法を用いることができる。また、ＭＭＩＯ（Memory-Mapped I/O）の場合には、デバイスに割り当てられた物理メモリ空間の領域をアクセス禁止属性にして、不正メモリアクセスのトラップをホストＯＳ１４が捕まえる方法を用いることができる。ただし、本発明におけるＩ／Ｏ命令をトラップする方法は、これらに限定されない。
【００５８】
バス延長部（ホスト）１６は、発行されたＩ／Ｏ命令が、認識しているリモート装置２０向けのものであるかをチェックする（ステップＳ３３）。
【００５９】
Ｉ／Ｏ命令がリモート装置２０向けのものでない場合（ステップＳ３３のＮｏ）、バス延長部（ホスト）１６は、そのＩ／Ｏ命令が実行されるべきデバイスに対して通常のＩ／Ｏ処理を実行する（ステップＳ３４）。
【００６０】
一方、Ｉ／Ｏ命令がリモート装置向けのものである場合（ステップＳ３３のＹｅｓ）、バス延長部（ホスト）１６はＩ／Ｏ命令をカプセル化する（ステップＳ３５）。このとき、バス延長部（ホスト）１６は、ネットワークパケットの宛先をリモート装置の通信部のアドレスとする。
【００６１】
バス延長部（ホスト）１６は、カプセル化されたＩ／Ｏ命令を仮想スイッチ部１５に渡す。仮想スイッチ部１５は、通信部１３およびネットワーク３０を経由してリモート装置２０に向けてネットワークパケットを送信する（ステップＳ３６）。
【００６２】
図８は、リモート装置２０がネットワーク３０からネットワークパケットを受信して処理する流れを例示するフロー図である。以下、図８のフロー図を参照して詳細に説明する。
【００６３】
まず、リモート装置２０の通信部２２がネットワークパケットをネットワーク３０から受信する（ステップＳ４１）。バス延長部（リモート）２４は、ネットワークパケットをデカプセル化して（ステップＳ４２）、取り出したＩ／Ｏ命令が、リモート装置２０に繋がっている遠隔デバイス２６向けのものであるかどうかを確認する（ステップＳ４３）。
【００６４】
取り出したＩ／Ｏ命令がリモート装置２０に繋がっている遠隔デバイス２６向けのＩ／Ｏ命令でない場合（ステップＳ４３のＮｏ）、バス延長部（リモート）２４は当該Ｉ／Ｏ命令を廃棄する（ステップＳ４４）。
【００６５】
一方、取り出したＩ／Ｏ命令がリモート装置に繋がっている遠隔デバイス向けのＩ／Ｏ命令である場合（ステップＳ４３のＹｅｓ）、バス延長部（リモート）２４は当該Ｉ／Ｏ命令を遠隔デバイス２６に対して発行する（ステップＳ４５）。遠隔デバイス２６は、発行されたＩ／Ｏ命令を処理する。
【００６６】
図９はリモート装置２０に繋がっている遠隔デバイス２６がデータを送信する際の処理の流れを例示するフロー図である。以下、図９のフロー図を参照して詳細に説明する。
【００６７】
まず、遠隔デバイス２６がデータを送信する（ステップＳ５１）。遠隔デバイス２６がデータを送信する場合として、ホストＯＳ１４から発行されたＩ／Ｏ命令が遠隔デバイス２６からデータをメモリに読み込む命令であるとき、遠隔デバイス２６からメモリにデータを送信する場合が考えられる。
【００６８】
バス延長部（リモート）２４は、遠隔デバイス２６から送信されたデータをカプセル化して通信部２２に渡す（ステップＳ５２）。バス延長部（リモート）は、カプセル化されたネットワークパケットの宛先を、通信部１３のアドレスとする。また、バス延長部１６、２４間の通信であることを明示するために、ネットワークパケットの種別フィールド（例えば、EthernetにおけるEtherタイプ）を特定の値にする。その後、通信部２２は、ネットワークパケットをホストＯＳ１４に向けてネットワーク３０に送信する（ステップＳ５３）。
【００６９】
図１０は、通信部１３がネットワーク３０からネットワークパケットを受信して処理する流れを例示するフロー図である。以下、図１０のフロー図を参照して詳細に説明する。
【００７０】
まず、通信部１３は、ネットワークパケットをネットワーク３０から受信し、ホストＯＳ１４の仮想スイッチ部１５に渡す（ステップＳ６１）。
【００７１】
仮想スイッチ部１５は、受信したネットワークパケットがリモート装置２０からのものかどうかを確認するためにパケットの種別フィールドをチェックする（ステップＳ６２）。
【００７２】
パケットがリモート装置２０からのネットワークパケットではない場合（ステップＳ６２のＮｏ）、通常のネットワーク通信であるため、仮想スイッチ部１５はネットワークパケットを仮想ＮＩＣ１７に転送する（ステップＳ６３）。
【００７３】
一方、パケットがリモート装置からのネットワークパケットである場合（ステップＳ６２のＹｅｓ）、仮想スイッチ部１５はネットワークパケットをバス延長部（ホスト）１６に渡す。バス延長部（ホスト）１６は、ネットワークパケットをデカプセル化してデータを取り出し（ステップＳ６４）、ゲストＯＳ１８にデータを送る（ステップＳ６５）。
【００７４】
[効果]
次に、本実施形態のコンピュータシステムの効果について説明する。本実施形態では、ホストＯＳ１４に設けられたバス延長部（ホスト）１６がゲストＯＳ１８によって発行されたＩ／Ｏ命令をカプセル化してネットワーク３０に送出する。すなわち、本実施形態によると、特許文献１（図１５）および特許文献２（図１６）を組み合わせたときに必要とされた、上流ブリッジ（バス延長部（ホスト））２０２によるＩ／Ｏ命令のカプセル化が不要となる。したがって、本実施形態によると、ゲストＯＳが稼働するデータ処理装置１０が上流ブリッジを装着可能なスロット（例えば、ＰＣカードスロット）を備えていないコンピュータであっても、ゲストＯＳ１８が遠隔デバイス２６を直接制御するパススルー技術を適用することができる。また、本実施形態によると、バス延長部（ホスト）１６がソフトウェアで実装されるため、ホストコンピュータ（データ処理装置１０）上に拡張スロットの空きがなくても、遠隔デバイスを利用することができる。以上より、本実施形態によると、パススルー技術の適用範囲を拡げることが可能となる。
【００７５】
また、本実施形態では、バス延長部（ホスト）１６が遠隔デバイス２６のゲストＯＳ１８への割り当てを管理しているため、ホストＯＳ１４の起動時に遠隔デバイス２６を認識する必要がなくなる。したがって、ホストＯＳ１４を高速に起動することが可能となる。
【００７６】
＜第２の実施形態＞
次に、第２の実施形態に係るコンピュータシステムについて、図面を参照して説明する本実施形態では、コンピュータシステムは、データ処理装置と複数のリモート装置を備えている。
【００７７】
[構成]
図１１は、本実施形態のコンピュータシステムの構成を例示する図である。図１１を参照すると、一例として、コンピュータシステムは、２台のリモート装置２０Ａ、２０Ｂを備えている。ただし、本実施形態におけるリモート装置の台数は図示の態様に限定されない。
【００７８】
本実施形態のデータ処理装置１０の構成は、第１の実施形態におけるデータ処理装置１０の構成（図４）と同様である。また、本実施形態のリモート装置２０Ａ、２０Ｂの構成は、第１の実施形態におけるリモート装置の構成（図３）と同様である。ただし、本実施形態では、リモート装置２０Ａ、２０Ｂの台数が複数になるため、バス延長部（ホスト）１６は、リモート装置２０Ａ、２０Ｂのそれぞれが有する遠隔デバイス２６と、リモート装置２０Ａ、２０Ｂのそれぞれの通信部２２との対応表を有する。
【００７９】
図１２は、バス延長部（ホスト）１６が保持する対応表の内容を例示する図である。図１２を参照すると、対応表は各リモート装置２０Ａ、２０Ｂの通信部２２のＭＡＣアドレスと、遠隔デバイス２６の情報とを関連付けて保持する。ここでは、一例として、リモート装置２０Ａの通信部２２のＭＡＣアドレスを「00:00:00:00:00:10」とし、リモート装置２０Ａは遠隔デバイス２６としてＡ社製のストレージａを有するものとする。一方、リモート装置２０Ｂの通信部２２のＭＡＣアドレスを「00:00:00:00:00:20」とし、リモート装置２０Ｂは遠隔デバイス２６としてＢ社製のキーボートｂを有するものとする。
【００８０】
バス延長部（ホスト）１６は、図１２に示したＭＡＣアドレスと遠隔デバイス２６の情報の対応関係を、リモート装置２０Ａ、２０Ｂから送出された（図５のステップＳ１２）ハートビートを受信する（図６のステップＳ２３）ことにより生成することができる。
【００８１】
ゲストＯＳ１８から遠隔デバイス２６へのアクセス処理は、次のように行われる。一例として、アクセス処理が、ゲストＯＳ１８から「Ａ社製のストレージａ」に対するデータ送信である場合について説明する。
【００８２】
図７を参照すると、ホストＯＳ１４のバス延長部（ホスト）１６は、ゲストＯＳ１８が発行した（ステップＳ３１）Ｉ／Ｏ命令をトラップする（ステップＳ３２）。
【００８３】
次に、バス延長部（ホスト）１６は、発行されたＩ／Ｏ命令はバス延長部（ホスト）１６が認識しているリモート装置２０Ａ向けのものであることを確認する（ステップＳ３３のＹｅｓ）。ここで、バス延長部（ホスト）１６は、図１２に示した対応表を用いて、「Ａ社製のストレージａ」を有するリモート装置２０ＡのＭＡＣアドレスを検索し、アドレス「00:00:00:00:00:10」を抽出する。
【００８４】
次に、バス延長部（ホスト）１６は、リモート装置２０Ａの通信部２２のアドレス「00:00:00:00:00:10」を宛先として、Ｉ／Ｏ命令をカプセル化したネットワークパケットを生成する（ステップＳ３５）。
【００８５】
次に、バス延長部（ホスト）１６は、生成したネットワークパケットをリモート装置２０Ａに向けて送出する（ステップＳ３６）。
【００８６】
[効果]
本実施形態のコンピュータシステムでは、ホストＯＳ１４上のバス延長部（ホスト）１６は、リモート装置の通信部のアドレスとリモート装置が有する遠隔デバイスとを関連付けた対応表（図１２）を備えている。バス延長部（ホスト）１６は、ゲストＯＳ１８によって発行された遠隔デバイス向けのＩ／Ｏ命令をカプセル化し、対応表に基づいて、当該遠隔デバイスを有するリモート装置の通信部のアドレスを宛先として送出する。かかるコンピュータシステムによると、Ｉ／Ｏ命令のハードウェアによるカプセル化が不要となる。そして、データ処理装置１０の拡張スロットに空きがない状況であっても、複数のリモート装置のそれぞれに設けられた遠隔デバイスをゲストＯＳから直接制御することができる。
【００８７】
＜第３の実施形態＞
次に、第３の実施形態に係るコンピュータシステムについて、図面を参照して説明する本実施形態では、データ処理装置上において複数のゲストＯＳが稼働する。
【００８８】
[構成]
図１３は、本実施形態のコンピュータシステムにおけるデータ処理装置１０の構成を例示するブロック図である。図１３を参照すると、データ処置装置１０において、２つのゲストＯＳ１８Ａ、１８Ｂが稼働する。ただし、本実施形態におけるゲストＯＳの個数は図示の態様に限定されない。
【００８９】
ゲストＯＳ１８Ａ、１８Ｂのそれぞれに対して、仮想ＮＩＣ１７Ａ、１７Ｂが割り当てられる。一方、バス延長部（ホスト）１６は、ゲストＯＳ１８Ａ、１８Ｂの間で共有されている。また、本実施形態では、バス延長部（ホスト）１６は各ゲストＯＳ１８Ａ、１８Ｂと遠隔デバイス２６の対応表を保持している。
【００９０】
図１４は、バス延長部（ホスト）１６が保持する対応表の内容を例示する図である。図１４を参照すると、対応表は各リモート装置２０Ａ、２０Ｂの通信部２２のＭＡＣアドレスと、遠隔デバイス２６の情報と、管理ゲストＯＳとを関連付けて保持する。バス延長部（ホスト）１６は、リモート装置２０から送出されたハートビートを受信することによって、通信部２２のＭＡＣアドレスと遠隔デバイス２６の情報との対応関係を把握することができる。一方、複数のリモート装置２０Ａ、２０Ｂに対するゲストＯＳの割り当ては、事前に設定される。図１４の対応表に含まれる管理ゲストＯＳは、リモート装置２０Ａ、２０Ｂを、ホストＯＳ１４上のいずれのゲストＯＳ１８Ａ、１８Ｂに割り当てるかを示す。なお、割り当ての際に、ゲストＯＳ１８Ａ、１８Ｂのそれぞれに対して、識別子（ＩＤ：Identifier）が割り振られる。
【００９１】
ここでは、一例として、リモート装置２０Ａの通信部２２のＭＡＣアドレスを「00:00:00:00:00:10」とし、リモート装置２０Ａは遠隔デバイス２６としてＡ社製のストレージａを有するものとする。一方、リモート装置２０Ｂの通信部２２のＭＡＣアドレスを「00:00:00:00:00:20」とし、リモート装置２０Ｂは遠隔デバイス２６としてＢ社製のキーボートｂを有するものとする。また、リモート装置２０Ａは識別子「Ａ」が割り振られたゲストＯＳ１８Ａに割り当てられ、リモート装置２０Ｂは識別子「Ｂ」が割り振られたゲストＯＳ１８Ｂに割り当てられているものとする。
【００９２】
ゲストＯＳから遠隔デバイス２６へのアクセスの処理は、次のように行われる。一例として、アクセス処理がゲストＯＳ１８Ｂから「Ｂ社製のキーボードｂ」に対するデータ送信である場合について説明する。
【００９３】
図７を参照すると、ホストＯＳ１４のバス延長部（ホスト）１６は、ゲストＯＳ１８Ｂが発行した（ステップＳ３１）Ｉ／Ｏ命令をトラップする（ステップＳ３２）。
【００９４】
次に、バス延長部（ホスト）１６は、発行されたＩ／Ｏ命令はバス延長部（ホスト）１６が認識しているリモート装置２０Ｂ向けのものであることを確認する（ステップＳ３３のＹｅｓ）。ここで、バス延長部（ホスト）１６は、図１４に示した対応表を用いて、「Ｂ社製のキーボードｂ」を有するリモート装置２０ＢのＭＡＣアドレスを検索し、アドレス「00:00:00:00:00:20」を抽出する。
【００９５】
次に、バス延長部（ホスト）１６は、リモート装置２０Ｂの通信部２２のアドレス「00:00:00:00:00:20」を宛先として、Ｉ／Ｏ命令をカプセル化したネットワークパケットを生成する（ステップＳ３５）。
【００９６】
次に、バス延長部（ホスト）１６は、生成したネットワークパケットをリモート装置２０Ｂに向けて送出する（ステップＳ３６）。
【００９７】
なお、割当表で対応付けられていないゲストＯＳと遠隔デバイス２６（リモート装置２０）との間では、データの送受信は許可されない。また、ゲストＯＳは、割当表で対応付けられてない遠隔デバイス２６を認識することができない。図１４に例示した対応表の場合、ゲストＯＳ１８Ａは、リモート装置２０Ｂを認識することができない。同様に、ゲストＯＳ１８Ｂは、リモート装置２０Ａを認識することができない。
【００９８】
[効果]
本実施形態のコンピュータシステムでは、ホストＯＳ１４上のバス延長部（ホスト）１６が、リモート装置の通信部のアドレスとリモート装置が有する遠隔デバイスとリモート装置が割り当てられたゲストＯＳの識別子を関連付けた対応表（図１４）を備えている。
バス延長部（ホスト）１６は、対応表を参照することにより、ゲストＯＳによって発行された遠隔デバイス向けのＩ／Ｏ命令をカプセル化し、ゲストＯＳに割り当てられた遠隔デバイスを有するリモート装置の通信部のアドレスを宛先として送出する。かかるコンピュータシステムによると、Ｉ／Ｏ命令のハードウェアによるカプセル化が不要となる。そして、データ処理装置１０の拡張スロットに空きがない状況であっても、複数のゲストＯＳは、割り当てられたリモート装置上の遠隔デバイスを直接制御することが可能となる。
【００９９】
本発明の各実施形態に係るコンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体は、コンピュータとデバイスとがネットワークを介して離れているような環境において、ネットワークを介して接続された遠隔デバイスをゲストＯＳに割り当てる用途に適用できる。特に、本発明の各実施形態に係るコンピュータシステム、データ処理装置、バスデータ転送方法、および、コンピュータ可読記録媒体は、コンピュータにデバイス用の空きスロットがない場合に遠隔デバイスを利用可能とする用途に適用することができる。
【０１００】
なお、上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更及び調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本願に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
この出願は、２０１４年３月２８日に出願された日本出願特願２０１４−０６８１４０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１０１】
１０    データ処理装置
１１    ＣＰＵ（Central Processing Unit）
１２    周辺デバイス
１３    通信部
１４    ホストＯＳ（Operating System）
１５    仮想スイッチ部
１６    バス延長部（ホスト）
１７、１７Ａ、１７Ｂ    仮想ＮＩＣ（Network Interface Card）
１８、１８Ａ、１８Ｂ    ゲストＯＳ
１９    システムバス
２０、２０Ａ、２０Ｂ    リモート装置
２２    通信部
２４    バス延長部（リモート）
２６    遠隔デバイス
３０    ネットワーク
１００    コンピュータ
１０１    ＣＰＵ
１０２    周辺機器
１０３    デバイスＢ
１０４    ホストＯＳ
１０５    デバイスドライバＢ
１０６    仮想デバイスＡ
１０８    ゲストＯＳ
１０９    デバイスドライバＡ
１１９    システムバス
２００    コンピュータ
２０１    ＣＰＵ
２０２    上流ブリッジ（バス延長部（ホスト））
２０３    イーサネットアダプタ
２０４    通信部
２０６    ＯＳ
２０７    デバイスドライバＡ
２１９    システムバス
３００    コンピュータ
３０２    通信部
４００    下流ブリッジ（バス延長部（リモート））
４０２    イーサネットアダプタ
５００    周辺機器（遠隔デバイスＡ）
６０２    イーサスイッチ
６０４    ネットワークスイッチ
【図１】
0006458798.tif 000002
【図２】
0006458798.tif 000003
【図３】
0006458798.tif 000004
【図４】
0006458798.tif 000005
【図５】
0006458798.tif 000006
【図６】
0006458798.tif 000007
【図７】
0006458798.tif 000008
【図８】
0006458798.tif 000009
【図９】
0006458798.tif 000010
【図１０】
0006458798.tif 000011
【図１１】
0006458798.tif 000012
【図１２】
0006458798.tif 000013
【図１３】
0006458798.tif 000014
【図１４】
0006458798.tif 000015
【図１５】
0006458798.tif 000016
【図１６】
0006458798.tif 000017