(57)【要約】【課題】複数クライアントによる単一物理デバイスの共有を提供する。【解決手段】物理デバイスは、コンピュータシステムのコア入出力機能を実行するコア機能回路を備える。複数のクライアントインターフェース回路が設けられ、コア機能回路にアクセスするべく、それぞれがシステム内のソフトウェアクライアントに対して完結したデバイスとして提示される。多重化回路が、複数のクライアントインターフェースとコア入出力機能を接続する。これ以外の実施形態も説明および請求される。【選択図】図１
2008503015.tif 000002
【特許請求の範囲】
【請求項１】
物理デバイスであって、
コンピュータシステムのコア機能を実行するコア機能回路と、
複数のクライアントインターフェース回路であって、前記コア機能回路にアクセスするべく、それぞれが、前記システム内のソフトウェアクライアントに対して完結したデバイスとして提示される複数のクライアントインターフェース回路と、
前記複数のクライアントインターフェース回路を前記コア機能回路に接続する多重化回路と
を備えるデバイス。
【請求項２】
前記コア機能はディスプレイグラフィクスアダプタの主要機能である
請求項１に記載のデバイス。
【請求項３】
前記主要機能は画像描画である
請求項１に記載のデバイス。
【請求項４】
前記コア機能はネットワークインターフェースコントローラの主要機能である
請求項１に記載のデバイス。
【請求項５】
前記主要機能はＴＣＰ／ＩＰパケットオフロードである
請求項４に記載のデバイス。
【請求項６】
前記複数のクライアントインターフェースは、ソフトウェアクライアントに対して複数の異なる入出力デバイス機能を露出する
請求項１に記載のデバイス。
【請求項７】
前記複数のクライアントインターフェースのうちの１つは信頼性のあるグラフィクスアダプタを露出し、別のクライアントインターフェースは信頼性のないグラフィクスアダプタを露出する
請求項１に記載のデバイス。
【請求項８】
前記複数のクライアントインターフェースはそれぞれ、前記コア機能回路の動作をコンフィグレーションするためのレジスタセットを別々に持っていて、
１つのセットはソフトウェアクライアントには入出力デバイスの古いバージョンに見え、別のセットは当該ソフトウェアクライアントには当該入出力デバイスの新しいバージョンのように見える
請求項１に記載のデバイス。
【請求項９】
前記システム内の複数の仮想マシン（ＶＭ）による前記コア機能回路に対するアクセスを制御するべく、前記システムのサービスＶＭソフトウェアによって使用される制御インターフェース回路をさらに備え、前記複数のＶＭはそれぞれ、前記複数のクライアントインターフェース回路を介して前記コア機能回路にアクセスする
請求項１に記載のデバイス。
【請求項１０】
前記コア機能はディスプレイグラフィクスアダプタの主要機能であって、前記制御インターフェースによって前記サービスＶＭソフトウェアは、前記コア機能回路を利用して、前記複数のＶＭ用の複数のウィンドウをそれぞれどのように表示するか選択できるようになる
請求項９に記載のデバイス。
【請求項１１】
副多重化回路を介して前記コア機能回路に接続された複数のワールドインターフェース回路であって、前記コア機能回路での信号方式と前記デバイスに対して外部の信号方式との間で変換を行うための複数のワールドインターフェース回路
をさらに備える請求項１に記載のデバイス。
【請求項１２】
前記複数のワールドインターフェース回路は、前記コア機能回路での信号方式とコンピュータ周辺バスでの信号方式との間で変換を行う
請求項１１に記載のデバイス。
【請求項１３】
前記複数のワールドインターフェース回路は、前記コア機能回路での信号方式とＬＡＮノード相互接続媒体の信号方式との間で変換を行う
請求項１１に記載のデバイス。
【請求項１４】
複数の作業待ち行列をさらに備え、当該複数の作業待ち行列はそれぞれ、前記複数のクライアントインターフェース回路のうちの１つと前記コア機能回路の間に接続され、前記制御インターフェース回路によって前記サービスＶＭは、待ち行列の状態のファンクションとしてどの待ち行列が前記コア機能回路に入力されるか選択できるようになる
請求項９に記載のデバイス。
【請求項１５】
入出力デバイスであって、
コンピュータシステムのコア入出力機能を実行するためのコア入出力機能回路と、
複数のクライアントインターフェース回路であって、いずれも、同じコア入出力機能を呼び出すために前記コア入出力機能回路にアクセスするべく、前記システム内の仮想マシン（ＶＭ）が使用することができる複数のクライアントインターフェース回路
を備える入出力デバイス。
【請求項１６】
前記複数のクライアントインターフェース回路はそれぞれ、前記入出力デバイスの外部からアクセスできるレジスタセットを別々に有し、各セットはオフセット以外は同じアドレス範囲を持つ
請求項１５に記載の入出力デバイス。
【請求項１７】
前記複数のクライアントインターフェース回路のうち１つは、グラフィクスアダプタ機能によって描画された出力データが無許可で複製されるのを防ぐべく、前記グラフィクスアダプタ機能に対してコンテンツ保護インターフェースを提示し、前記複数のクライアントインターフェース回路のうち別の１つは、前記グラフィクスアダプタ機能に対して安全でないインターフェースを提示する
請求項１５に記載の入出力デバイス。
【請求項１８】
前記複数のクライアントインターフェース回路を介して前記入出力デバイスにそれぞれアクセスする複数の仮想マシンクライアントの需要に前記入出力デバイスのリソースをより一致させるべく、前記入出力デバイスはソフトウェアに、自由にクライアントインターフェースの数を変える能力を付与できる
請求項１５に記載の入出力デバイス。
【請求項１９】
仮想マシン機能を有するコンピュータシステムであって、
プロセッサと、
仮想マシンモニタ（ＶＭＭ）を格納しているメモリであって、当該ＶＭＭは、複数のクライアントプログラムを実行するための、前記システムに含まれる複数の仮想マシン（ＶＭ）をそれぞれ管理するべく前記プロセッサによってアクセスされるメモリと、
ハードウェアに複数のインターフェースを有する入出力デバイスであって、各インターフェースは、前記複数のＶＭで実行される前記複数のクライアントプログラムのそれぞれに対して、別々の入出力デバイスとして提示される入出力デバイスと
を備えるシステム。
【請求項２０】
前記メモリはさらに、前記プロセッサによってアクセスされるサービスＶＭを格納し、
前記入出力デバイスはさらに、前記コア入出力機能回路をコンフィグレーションするべく、前記サービスＶＭによって用いられる制御インターフェースをハードウェアに有する
請求項１９に記載のシステム。
【請求項２１】
前記入出力デバイスはさらに
ハードウェアに、前記コア入出力機能回路の信号方式と前記入出力デバイスの外部の信号方式との間で変換を行うワールドインターフェースを有する
請求項２０に記載のシステム。
【請求項２２】
仮想化装置であって、
コンピュータシステムのコア入出力機能を実行するための手段と、
前記コア入出力機能にアクセスするために、複数の仮想マシン（ＶＭ）クライアントに対して複数の完結したインターフェースを提示するための手段であって、各インターフェースは、同一のデバイスドライバによって別々の入出力デバイスとしてアクセスされ得るという点において完結している手段と、
前記コア入出力機能実行手段と前記完結インターフェース提示手段との間でメッセージを渡すための手段と
を備える仮想化装置。
【請求項２３】
前記完結インターフェースはそれぞれ別々の、ａ）一意的なデバイス識別番号、およびｂ）同一のバス上に露出した別々のコンフィグレーションレジスタセットを有する入出力デバイスを提示する
請求項２２に記載の仮想化装置。
【請求項２４】
各コンフィグレーションレジスタセットは、別々のＰＣＩデバイスＩＤ、ベンダＩＤ、改訂ＩＤ、およびクラスコードを格納する
請求項２３に記載の仮想化装置。
【請求項２５】
入出力デバイスを共有するための方法であって、
コンピュータシステム内でプラグアンドプレイ発見プロセスを実行することと、
前記プロセスによって前記システム内に複数の入出力デバイスが存在することを検出することとを含み、前記検出された複数の入出力デバイスは実際には前記システムに接続されている単一の物理入出力デバイスに基づくものであり、そのコア入出力機能は当該物理入出力デバイス内の複数のハードウェアクライアントインターフェースが共有している
方法。
【請求項２６】
前記検出は、前記検出された入出力デバイスそれぞれの一意的なＰＣＩデバイス識別番号を、共有される前記コア入出力機能を含む単一のグラフィクスアダプタカードから読み出すことを含む
請求項２５に記載の方法。
【請求項２７】
前記複数の検出された入出力デバイスを前記システム内の複数の仮想マシン（ＶＭ）にそれぞれ割り当てること
をさらに含む請求項２５に記載の方法。
【請求項２８】
前記複数のＶＭに処理を提供する時に、前記複数のＶＭのうち１つに対してほかに対する優先権を与える優先政策に従って共有されるように前記コア入出力機能をコンフィグレーションすること
をさらに含む請求項２７に記載の方法。
【請求項２９】
データが格納された機械可読媒体を有する製品であって、コンピュータシステム内のプロセッサによってアクセスされると、前記システム内の物理デバイスの制御インターフェースとの間で読み出しおよび書き込みを行い、それぞれが前記システム中のデバイスドライバプログラムに対して完結したデバイスとして提示される、ハードウェアの複数のクライアントインターフェースによる、前記デバイスの同一のコア機能に対するアクセスを制御する製品。
【請求項３０】
前記データは前記システム用の仮想化ソフトウェアの一部である
請求項２９に記載の製品。
【請求項３１】
前記データの前記読み書きを行うことによって、前記クライアントインターフェースからの画像を複数のディスプレイウィンドウ内にそれぞれ描画および表示するための前記コア機能用のスケジューリング政策を前記物理デバイスにプログラミングする
請求項３０に記載の製品。
【請求項３２】
前記データは前記物理デバイスをプログラミングして、前記コア機能に対して命令を与える待ち行列を、前記複数のクライアントインターフェースと対応付けられた待ち行列から選択させる
請求項３０に記載の製品。
【請求項３３】
前記データの前記読み書きを行うことによって、前記物理デバイスに対して電力管理処理を行う
請求項３０に記載の製品。
【請求項３４】
前記データの前記読み書きは、前記複数のクライアントインターフェースの１つに対して外部キャプチャストリームをルーティングするために実行される
請求項３０に記載の製品。
【請求項３５】
仮想マシン機能を有するマルチプロセッサコンピュータシステムであって、
複数のプロセッサと、
仮想マシンモニタ（ＶＭＭ）が格納されたメモリであって、当該ＶＭＭは前記複数のプロセッサのうち１つによって、複数のクライアントプログラムをそれぞれ実行するための前記システムにある複数の仮想マシン（ＶＭ）を管理するために実行されるメモリと、
コア機能およびハードウェア内にある複数のインターフェースを有する入出力デバイスとを備え、前記複数のインターフェースはそれぞれ、前記複数のＶＭ内で実行される前記複数のクライアントプログラムそれぞれに対して別々の入出力デバイスとして提示され、前記複数のＶＭは前記入出力デバイスの前記コア機能に前記複数のインターフェースを介して同時にアクセスでき、該アクセスにおいて互いを認識することはなく、また前記ＶＭＭが前記複数のＶＭ間でアービトレーションを行う必要はない
マルチプロセッサコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は広くはコンピュータシステムに関し、具体的には複数のプログラムによる１つの物理デバイスの共有を可能にする仮想化技術に関する。
【背景技術】
【０００２】
コンピュータ用に数多くの異なるオペレーティングシステム（ＯＳ）プログラム（例えばＬＩＮＵＸ、ＭＡＣＩＮＴＯＳＨ、ＭＩＣＲＯＳＯＦＴ  ＷＩＮＤＯＷＳ）が広く利用されている中、多岐にわたるさまざまな種類のアプリケーションプログラムが消費者に提供されているが、残念なことにそういったアプリケーションプログラムは同一ＯＳ上で実行できるようにはデザインされていない。仮想化技術によれば、仮想マシンモニタ（ＶＭＭ）を実行している単一のホストコンピュータは、該ホストの複数のアブストラクションを提示できるので、該ホストの基礎となるハードウェアは１以上の独立して動作する仮想マシン（ＶＭ）となる。各ＶＭは、それぞれのオペレーティングシステム（ＯＳ）および／または１以上のソフトウェアアプリケーションを実行する自己完結型プラットフォームとして機能するとしてもよい。ＶＭＭはホスト上のリソースの割り当てを管理するとともに、ラウンド・ロビン方式またはそれ以外の所定のスキームに従って、さまざまな仮想マシン間で多重化を行うべく、必要に応じてコンテキストスイッチを実行する。例えば、ＶＭ環境において各ＯＳは、それぞれ別のハードウェアプラットフォームまたは「ベアメタル」上で実行されているという幻想を持つ。各ＯＳはまた、利用可能な入出力デバイス（例えば、キーボードコントローラ、ハードディスクドライブコントローラ、ネットワークインターフェースコントローラおよびグラフィクスディスプレイアダプタ）の完全なセットを「見る」。
【０００３】
オペレーティングシステムが入出力デバイスと通信を行う場合には、以下に説明する技術が用いられる。ＯＳが実際にベアメタル上で実行されている場合は、物理入出力デバイスのハードウェアクライアントインターフェースがバス上に露出している。クライアントインターフェースは、一連のメモリマップドレジスタ（メモリマップド入出力、ＭＭＩＯ）または入出力ポート（ＩＯＰ）であってよく、メモリマップド入出力アドレススペースまたはコンピュータシステムの入出力アドレススペースを介してアドレスを指定することができる。プロセッサは、割り当てられたアドレススペースを対象としたＯＳトランザクションをバス上で発行することによって物理デバイス内の記憶位置に対して読み書きを実行できる。
【０００４】
一方仮想化の場合、（複数のゲストＯＳを実行するために）複数のＶＭが存在する場合がある。その場合、ゲストに対して入出力機能を付与するために利用される基本技術は２通りある。まず１つ目は、デバイスへの排他的アクセスをＶＭに与える方法がある。ＶＭＭは、このＶＭによるＭＭＩＯまたはＩＯＰに対するアクセスをすべて、ターゲットとなる入出力デバイスに直接送信するよう取り計らう。このようにすることによって、ＶＭはデバイスとの間で通信を行う上で最大性能を実現する経路を持つことになる。この方法はデバイス割り当てと呼ばれることがある。この方法の最大の問題点は、単一のＶＭにしか入出力デバイスを割り当てることができないことである。
【０００５】
何らかの方法により複数のＶＭで入出力デバイスを共有したい場合によく用いられる方法として、ＶＭＭが物理入出力デバイスを１以上の「仮想デバイス」としてエミュレーションすることが挙げられる。この場合、物理デバイスを対象としたあるＯＳからのトランザクションはＶＭＭが傍受する。ＶＭＭは、（例えば、ネットワークインターフェースを用いてシリアルポートをシミュレーションすることによって）デバイスをエミュレーションすることを選択してもよいし、複数のクライアントＶＭからの要求を１つの入出力デバイスに多重化してもよい（例えば、ハードドライブを複数の仮想ドライブに分割する）。
【０００６】
上述の仮想化プロセスを次のように解釈することもできる。ＶＭが、仮想デバイスおよび物理デバイスの両方から成る入出力デバイスセットに対してアクセスを有する必要があるとする。物理デバイスが１つのＶＭに割り当てられている場合、この物理デバイスはほかの仮想マシンには利用不可能である。従って、物理デバイスを複数のＶＭによって共有しなければならない場合、ＶＭＭは通常各ＶＭに対して仮想デバイスを実現する。ＶＭＭはこの場合、これらの仮想デバイスからの、物理デバイスのハードウェアクライアントインターフェースに対するアクセスについて、アービトレーションを行う。
【図面の簡単な説明】
【０００７】
本発明の実施形態を添付図面に図示するが、図示された実施形態は本発明の例を挙げたものであって本発明を限定するものではない。また添付図面では、同様の構成要素を同様の参照番号を用いて示す。本明細書の開示において本発明の「一」実施形態と言及されている場合、それらは必ずしも同じ実施形態を指すものではなく、また少なくとも１つの実施形態を意味するものである。
【０００８】
【図１】「デザインによって共有可能な」物理デバイスを示すブロック図である。
【０００９】
【図２】共有可能なデバイスを備え仮想化プロセスを実行するコンピュータシステムを示すブロック図である。
【００１０】
【図３】コンピュータシステム内で共有可能な入出力デバイスを発見することを含む仮想化プロセスを示すフローチャートである。
【発明を実施するための最良の形態】
【００１１】
図１は、「デザインによって共有可能な」物理デバイスを示すブロック図である。この共有可能デバイス１００は、この実施例ではコンピュータシステムのコア入出力機能を実行するコア機能回路１０４を有する。コア入出力機能の例を挙げると、グラフィクスアダプタの場合には画像描画やネットワークインターフェースコントローラの場合はＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットのオフロードがある。コア入出力機能回路は、ハードワイヤードおよび／またはプログラム可能なロジックとプログラミングされたプロセッサなどの公知技術の組み合わせとして実現されるとしてもよい。
【００１２】
システムが備えるソフトウェア仮想マシン（ＶＭ）クライアント１０８は、複数のクライアントインターフェース回路１１２（または単にクライアントインターフェース１１２）のいずれか１つを介して、コア機能回路１０４にアクセスする。ＶＭクライアント１０８はデバイスドライバを有する、ＭＩＣＲＯＳＯＦＴ  ＷＩＮＤＯＷＳまたはＬＩＮＵＸのようなオペレーティングシステムであってもよい。クライアントインターフェース１１２は多重化回路１１６を介してコア機能回路１０４に接続され、クライアントインターフェースを介してＶＭクライアントがコア機能を共有できるようにする。多重化回路１１６は、多重化ロジックと、コア機能回路とクライアントインターフェース１１２のうちいずれか１つをそれぞれ接続するために必要な信号線を含むとしてもよい。
【００１３】
各クライアントインターフェース１１２は、完結且つ独立したデバイスとしてシステム中のソフトウェアクライアント（例えばＶＭクライアント１０８）に提示される。インターフェース１１２は、それが設けられているバスが必要とする機能のすべての実施形態を実現するとしてもよい。クライアントインターフェース１１２は、デバイス中のロジックの信号方式と外部のバスの信号方式の間で変換を行うアナログ回路を含むとしてもよい。外部のバスがシリアル且つ二地点間タイプの場合、一連のレジスタのうち１つをそれぞれバスの送信媒体と接続するために多重化スイッチ回路がさらに設けられるとしてもよい。
【００１４】
本発明の実施形態によっては、各クライアントインターフェース１１２が、（物理デバイスが接続されている）同一バス上で同一の機能発見機構および同一のＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）コンパチブル・コンフィグレーション機構を支持するとしてもよい。しかしこのような実施形態によると、（各クライアントインターフェースは実質的に異なるデバイスを表現するので）各クライアントインターフェースは異なるＰＣＩデバイス識別番号を持つことになる。さらに、各クライアントインターフェースが特定するＰＣＩコンパチブル機能のセットはそれぞれ別々となる。クライアントインターフェースはもちろん、例えばコンピュータシステム内で構成要素同士を接続するために利用されるほかの入出力プロトコルまたはバス通信プロトコルに準拠するようにデザインされるとしてもよい。
［ｍａｇ２］
【００１５】
各クライアントインターフェースは、該インターフェースに関する情報を取得し該インターフェースをコンフィグレーションするべくソフトウェアクライアントが利用するレジスタセットを有し、そのレジスタセットはクライアントインターフェース毎に異なるとしてもよい。各レジスタセットは物理デバイスの外部から同じバスを介してアクセスできるとしてもよい。このバスは、シリアルでもパラレルでもよいし、マルチドロップタイプでも二地点間タイプでもよい。例えばプラグアンドプレイサブシステムは、ＭＭＩＯ領域のベースアドレスを定義するのにＰＣＩコンフィグレーションレジスタを用いるとしてもよい。ＰＣＩコンパチブル・コンフィグレーションレジスタの１セットは以下に挙げる公知のレジスタの一部またはすべてを含むとしてもよい：ベンダＩＤ、デバイスＩＤ（コンフィグレーションレジスタアドレスのオフセットを決定）、改訂ＩＤ、クラスコード、サブシステムベンダＩＤおよびサブシステムＩＤである。ここで挙げたレジスタの組み合わせを通常ＯＳが用いてどのドライバをデバイスのために読み込むか決定する。［ｍａｇ３］共有可能デバイスで実施される場合、（あるクライアントインターフェースの）各レジスタセットは、オフセットが異なる以外は同じアドレス範囲にあるとしてもよい。［ｍａｇ４］
【００１６】
ベースアドレスレジスタ（ＢＡＲ）を設定することによって、デバイスが使用するベースアドレスを特定するとしてもよい。［ｍａｇ５］ゲストがＢＡＲの設定を試みた場合この要求を傍受して変更するように、ＶＭＭはデザインされるとしてもよい。このような構成とするにはいくつか理由がある。まず、２つのＶＭがそれぞれ、１つのインターフェース内にあるＢＡＲを同じ値に設定しようと試みていることに気づかない可能性がある。この様な事態が発生しないようにＶＭＭがデザインされるとしてもよい。第２に、各ＶＭは、ゼロに基づいたアドレススペース（いわゆる、ゲスト物理アドレス、ＧＰＡ）で実行されていると信じていることがある。ＢＡＲがゲストによって設定される場合、ゼロに基づいたＧＰＡを、ＢＡＲに読み込まれる前に、実際のホスト物理アドレス（ＨＰＡ）に変換する必要がある。さらに、ＶＭＭはゲストＶＭのメモリ管理テーブルを修正してこの変換を反映させなければならない。
【００１７】
［ｍａｇ６］共有可能デバイス１００は、コア機能回路１０４が比較的複雑および／または大型で、複製が非常に高価である場合に（且つ複製することによって得られる並列処理という性能向上が必要ない場合に）、さらに望ましい解決方法となるとしてもよい。また、（図２を参照して後述される）入出力の仮想化の実施例において用いることも有用である。その場合、共有可能デバイス１００は仮想マシンモニタ（ＶＭＭ）が各トランザクションに関与せずにすむようにするので、（特に待ち時間の長さに影響を受けやすい）グラフィクスおよびネットワークに関連するトランザクションの待ち時間が短縮される。さらに、実施形態によっては、ＶＭＭのデザインおよび実施を大幅に簡潔にできるので、ソフトウェアの動作をより安定させることができる。これは、複数のクライアントインターフェースを備えることによって、対応する複数の仮想デバイスをＶＭＭが支持する必要がなくなる（例えば、ＶＭＭはデバイスそのものまたは各仮想デバイス用のＰＣＩコンフィグレーションスペースをエミュレーションする必要がなくなる［ｍａｇ７］）ためであるとしてもよい。
【００１８】
ソフトウェアクライアントは、共有可能デバイスの同一の主要機能を呼び出す時にクライアントインターフェース１１２のいずれを用いてもよい。この主要機能は、ディスプレイグラフィクスアダプタのような入出力デバイスの主要機能（例えば、ビットマップ表示画像を生成する画像描画機能）であってもよい。この場合、共有可能デバイスは、コンピュータシステムチップセットのグラフィクス入出力部分の一部として、または１つのグラフィクスアダプタカードとして実施されるとしてもよい。後者の場合、クライアントインターフェースは該カードとコンピュータシステムのバスを取り外し可能に接続するための電気コネクタをさらに含むとしてよい。その場合インターフェースはすべて、同じコネクタを介してアクセスできる。
【００１９】
ほかの主要機能としては、ネットワークインターフェースコントローラ（ＮＩＣ）の主要機能であってもよい。そのような実施形態では、各ソフトウェアクライアント（例えば、ＶＭクライアント１０８）はネットワークに含まれる別々のエンドノードであってもよい。ＶＭクライアント１０８は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットオフロード（出力パケットを生成して入力パケットをデコード）やＭＡＣ（媒体アクセス制御）のアドレスフィルタリングといった主要機能に基づいてネットワークと通信を行う。その場合、共有可能デバイスは１つのネットワークインターフェースコントローラカードであってもよい。各クライアントインターフェースは、それぞれ別々のＭＡＣアドレスを含む、完結した、もしくは完全に有効なＮＩＣとして提示される。入力パケットは正しいクライアントインターフェースに、続いて対応するＶＭクライアントに自動的にルーティングされる。このような動作を達成するに当たり、入力パケットをそれぞれ評価するためにＣＰＵサイクルを消費する必要がなく（ＶＭＭ）、且つパケットが該システム中のＶＭを対象としているか否かに関わらずＣＰＵがすべての入力パケットを確認するモードであるプロミスキャス・モードにＮＩＣを入れる必要がない。［ｍａｇ８］
【００２０】
共有可能デバイス１００のクライアントインターフェースは、ソフトウェアクライアントに対して完結且つ独立デバイスとして提示されるが、同一のデバイスである必要はない。より一般的に言うと、クライアントインターフェース１１２のうち１以上がＶＭクライアントに対して（コア機能１０４によって実現される）異なるデバイス機能を提示する場合、共有可能デバイス１００は異種インターフェースを有するとしてもよい。例を挙げると、共有可能デバイスがディスプレイグラフィクスアダプタの場合がある。この場合、共有デバイスのクライアントインターフェースのうち１つがあるデバイスの古いバージョン（例えば、レガシーデバイス）としてソフトウェアクライアントに提示され、別の１つのクライアントインターフェースは新しいバージョンとしてソフトウェアクライアントに提示されることがある。別の例には、コア入出力機能が、複数のプログラム可能な演算素子を持つスケーラブルコンピュータアーキテクチャとして実現されているグラフィクスアダプタがある。クライアントインターフェースの１つが、ほかのクライアントインターフェースよりも大きい演算素子のサブセットにアクセスするようにデザインまたはプログラミングされ、同じタイプだがより強力な入出力機能を提示するように構成するとしてもよい。［ｍａｇ９］
【００２１】
これ以外の例では、共有可能デバイス１００が備えているクライアントインターフェースは、その幾つかが、より完結したものであってもよい。例えば、一部のクライアントインターフェースがより高い性能（例えば、コア機能で異なるタイプのグラフィクス描画機能）を示すとしてもよい。インターフェースを複雑化すれば、対応付けられたデバイスドライバプログラムも複雑化する可能性が高いと思われる。複雑なデバイスドライバほどバグまたは抜け穴が存在しやすくセキュリティ分析に応じた修正が難しいので、攻撃に対してより脆弱であると思われる。このように複雑さゆえに、上記のインターフェースは信頼性または安全性がないと思われてしまう。同時に、共有可能デバイスは、主要入出力機能の低性能バージョン（例えば、基本的な画像描画と表示に限定）を示す１以上の別のクライアントインターフェースを有するとしてもよい。このような後者のインターフェースは、信頼性および安全性がより高いと思われる。
【００２２】
例えば、あるインターフェースは（複雑性または固有デザインに基づいて）ユーザの機密データ（例えば、ユーザの社会保障番号や金銭に関するデータなど、システムのユーザが生成および「所有」するデータ）を保護するために必要な程度、信頼性が十分に高いと判断されるとしてもよい。（グラフィクスデバイス用の）このインターフェースは、個人の会計および税に関する処理を行うソフトウェアなどのアプリケーションプログラムの出力を排他的に表示するために使用されるとしてもよい。このような構成とすることによって、例えば、システムに侵入してユーザに関する機密個人情報を探す、第三者の悪意あるソフトウェア素子による攻撃からの保護に貢献する。
【００２３】
別の場合を考えると、比較的簡潔なインターフェースを用いてより高いレベルのコンテンツ保護を実現することもできる。例えば、システムのユーザが、コア機能の出力に含まれる、著作権が保護された第三者のデータを取得できないようにする。例を挙げると、ユーザは、コンテンツが保護されたインターフェースだけと対応付けられたＶＭクライアントでＤＶＤプレーヤーアプリケーションプログラムを実行することによって、映画のデータストリームがそのインターフェースによってのみ描画されるとしてもよい。または、コンテンツを保護するクライアントインターフェースは、デバイスドライバ層が介在することなく、アプリケーションプログラムによって直接アクセスされるようにデザインされるとしてもよい。このタイプのより簡潔なインターフェースは、アプリケーションプログラムとコアグラフィクス描画／表示機能の間の経路を少なくすることによって、攻撃される機会をさらに減らすことができる。
【００２４】
複数のクライアントインターフェースを有する単一の共有可能デバイス１００は、アクティブなインターフェースの数を変更する機能を付加することによって、さらに性能を向上させるとしてもよい。このような付加機能は、システム内で実行されている所定のソフトウェア（例えば、図２を参照して後述するサービスＶＭ１３０またはＶＭＭ２２４）に、クライアントインターフェースの一部をイネーブル／ディセーブルするコンフィグレーションレジスタへのアクセスを付与するように、デザインされるとしてもよい。このような構成とすることによって、入出力デバイスのリソースの割当を制御することができ、例えばシステム内で実行されているＶＭクライアントの需要により適切に応じるようになる。
【００２５】
図１に示す共有可能デバイス１００はさらに、１以上のワールドインターフェース回路（または単にワールドインターフェース）１２０を備えるとしてもよい。複数ある場合、ワールドインターフェースは副多重化回路１２２を介してコア機能回路１０４に接続される。各ワールドインターフェース１２０は、コア機能回路１０４の信号方式とデバイスの外部の信号方式の間で変換を行うデジタル回路および／またはアナログ回路を有するとしてもよい。ワールドインターフェースはそれぞれ、有線リンクまたは無線リンクを介して、ディスプレイモニタまたはデジタルカメラなどのコンピュータシステムの周辺機器と通信するために必要なコネクタおよび／またはほかのハードウェアを有するとしてもよい。ネットワークインターフェースコントローラの場合、ワールドインターフェースは、ローカル・エリア・ネットワーク（ＬＡＮ）ノード相互接続媒体に接続されるネットワークポートと呼ばれるとしてもよい。このようなポートは、ＬＡＮケーブル（例えばイーサネットケーブル）と接続される、または例えば無線アクセスポイントとの間で通信を行う、無線送信機および無線受信機または回路を有するとしてもよい。
【００２６】
実施形態によっては、共有可能デバイス１００は、システム中のソフトウェア（サービスＶＭ１３０）が使用する制御インターフェース回路（または、単に制御インターフェース）１２６を備えるとしてもよい。制御インターフェース１２６はさまざまな目的を実現するために用いられるとしてもよい。例えば、複数の異なるクライアントからのデータを合成するための機構であってもよい（例えば、同じ表示画面のどこに各ＶＭの出力を表示すべきか制御する）。制御インターフェースは、複数のＶＭクライアントからのコマンドが競合するという問題を解決するためにも用いられるとしてもよい［ｍａｇ１０］。例えば、ＶＭクライアント１０８による（対応するクライアントインターフェース１１２を介した）コア機能へのアクセスを制御するための別の方法を提供するとしてもよい。例えば、共有可能グラフィクスアダプタが備える制御インターフェースは、複数のウィンドウを表示する上での所定のスケジューリング政策を、サービスＶＭ１３０がデバイスにプログラミングできるようにデザインされているとしてもよい。例を挙げると、所定の期間中はＶＭクライアントに対する優先順位が平等でないスケジューリング政策や、コア機能の機能ブロックの一部（すべてではない）を所定のＶＭクライアントに割り当てるスケジューリング政策がある。そのような実施形態によると、共有可能デバイスはさらに、各クライアントインターフェース１１２に１つ、クライアントインターフェース１１２とコア機能回路１０４の間に接続される作業待ち行列（不図示）を備えるとしてもよい。制御インターフェースは、待ち行列の状態（例えば、深さ、空きの程度、優先度など）のファンクションとして、コア機能回路に命令を与える待ち行列をサービスＶＭに選択させる。［ｍａｇ１１］制御インターフェースはまた、例えば、各ＶＭが別々のモニタに割り当てられるマルチモニタや、同じモニタ上でのマルチウィンドウなど、グラフィクスの描画および表示のコンフィグレーションに利用されるとしてもよい。グラフィクスアダプタの消費電力も制御インターフェースによって管理されるとしてよい。なお、共有可能デバイスには制御インターフェースを必ず設けなくてもよい。例えば、共有可能ＮＩＣには単純に、複数の異なるクライアントインターフェースを平等に、もしくは適切であれば不平等に扱うアービトレーション政策が、一度プログラミングされる（またはおそらくハードワイヤードとする）としてもよい。
【００２７】
ＮＩＣの場合、制御インターフェースはサービスＶＭに、ＶＭクライアント単位で割当られたもしくは保護された帯域幅を変更させるとしてもよい。サウンドカードの場合、制御インターフェースはサービスＶＭに、複数の異なるＶＭクライアントソースからの音声の合成を制御させるとしてもよい。またこれ以外の可能性としては、制御インターフェースに基づき、ビデオキャプチャストリームおよび／またはオーディオキャプチャストリームを所定のＶＭクライアントにルーティングさせることができる。例えば、制御インターフェースにおいて、複数の異なる媒体アクセスコントローラ（ＭＡＣ）のそれぞれと対応するＶＭクライアントを対応付けをソフトウェアが示すとしてもよい。
【００２８】
図２は、共有可能デバイス１００を備え仮想化プロセスを実行するコンピュータシステムを示すブロック図である。共有可能デバイス１００はシステムの物理ホストハードウェア２０４の一部であり、ベアメタルとも呼ばれる。ホストハードウェア２０４は、キーボードコントローラ、ハードディスクドライブコントローラおよびグラフィクスディスプレイアダプタのような、一連の利用可能な入出力デバイス（不図示）を有するとしてもよい。これらの入出力デバイスは、ユーザ入力デバイス２０８（キーボードとマウスの組み合わせとして本例では描かれている）、不揮発性大容量記憶デバイス（ハードディスクドライブ２１２として本例では描かれている）、ディスプレイモニタ２１４、およびＮＩＣアダプタカード２１６といった周辺機器と通信を行うために用いられる［ｍａｇ１２］。［ｍａｇ１３］
【００２９】
仮想化は、仮想マシンモニタ（ＶＭＭ）２４４と呼ばれるプログラムを用いて実現される。ＶＭＭ２４４はホストハードウェアプラットフォーム２０４を複数の独立した仮想マシン（ＶＭ）２２８に「分割する」。各ＶＭ２２８は基本的に、その中で実行されているソフトウェアに対して、図示しているように入出力デバイスと周辺機器を含む完結したコンピュータシステムとして見える。ＶＭＭ２２４は、各ＶＭ２２８が実行される環境を提供し、ＶＭ間の分離状態を維持するために用いられてもよい（分離状態を維持する別の方法としては、ハードウェアＣＰＵ拡張の利用が挙げられる）。［ｍａｇ１４］ＶＭ２２８で実行されるソフトウェアは、ＶＭ２２８ごとに異なるゲストＯＳ２３２を含むとしてもよい。ＶＭ環境では、各ゲストＯＳ２３２はそれぞれ別のハードウェアプラットフォーム上で実行されているという幻想を持つ。ゲストＯＳ２３２はこのため、同じシステム内で別のオペレーティングシステムも実行されていることや、基礎となるコンピュータシステムが分割されていることに気付かないこともある。
【００３０】
仮想化プロセスを実行することによって、対応するゲストオペレーティングシステム２３２に加えてアプリケーションプログラム２３６も、複数の異なるＶＭ２２８で実行され得る。複数あるアプリケーションプログラム２３６は、１つのディスプレイモニタ２１４上で、別々のウィンドウを利用することによって（例えばＶＭ毎に１つのウィンドウ）、同時に情報を表示するとしてもよい。これが可能であるのは、本例ではグラフィクスアダプタとして示される共有可能デバイス１００のおかげである。ＶＭＭ２２４はそのような共有可能デバイス１００の存在を知ることができるように構成されているので、（例えば、サービスＶＭ１３０を介して、図１を参照のこと）共有可能デバイス１００を管理することができる。物理デバイスを共有するために純粋にソフトウェア技術を用いるのでは多くの問題点が発生するが、こういった問題点を生じさせない。例えば、物理デバイスを適切に共有できるように、その詳細な動作を理解しなければならないような比較的複雑なＶＭＭをデザイン且つ実現する必要がないとしてもよい。これは、ハードウェア内に各ゲストＯＳ２３２が簡単に認識できる複数のクライアントインターフェースが利用可能なためである。
【００３１】
上述した共有可能デバイスの概念の利点をさらに、例を用いて以下に説明する。マルチプロセッサシステムまたは１つの中央演算処理装置（ＣＰＵ）が２以上のＣＰＵとして振舞う（スケジューリングに関してだけでなく、十分に実行能力が残っているためこうなる）ハイパースレッドＣＰＵを持つものを例に挙げる。プロセッサ１がＶＭ０用のコードを実行しており、プロセッサ２がＶＭ１用のコードを実行しているとする。続いて、各ＶＭが同時に同じ入出力デバイスにアクセスしたい場合を考える。共有不可能な入出力デバイスの場合は、どの時点においても１つのコンテキストでしか動作できない。このため、２つのＶＭのうち１つしかデバイスにアクセスできない。一方のＶＭはデバイスにアクセスしようと試みたが、この試みは、間違ったコンテキストでデバイスにアクセスしたことになってしまう。
【００３２】
本発明の実施形態によると、（ＶＭとハードウェアクライアントインターフェース間の）「会話」および（コア機能回路が実行している）「仕事」がお互いから分離され、上述したコンテキストスイッチが必要ないこともある。それは、各ＶＭには別々のハードウェアクライアントインターフェースが割り当てられているので、必要とされている入出力デバイスのコンテキストスイッチを行うことなく、ＶＭは対応するクライアントインターフェース回路に入出力要求を送信できるためである。このため、上述したアクセスに関する問題が解決される。
【００３３】
別の例として、ＶＭ０とＶＭ１の両方を実行しているＣＰＵを挙げる。ＶＭ０では、アプリケーションソフトウェアがＣＰＵを比較的多く利用している（例えば、定数ｐｉを計算する）が、グラフィクスアダプタについては非常に利用が少ない（例えば、ディスプレイウィンドウの時計を更新）。別のＶＭウィンドウでは、グラフィクスパターンは定期的にグラフィクスアダプタによって更新されているが、ＣＰＵは非常にわずかしか利用していない。ここで、ＣＰＵとグラフィクスアダプタがともにコンテキストスイッチされる（所定時間の一部ではグラフィクスアダプタとＣＰＵをＶＭ０に与え、残りの時間ではＶＭ１に与える）と仮定する。その場合、ＶＭ０はグラフィクスについて比較的少ない需要しか持っていないので、ＶＭ０に与えられた時間ではグラフィクスサイクルが無駄／アイドル状態になり、ＶＭ１はＣＰＵへの需要が少ないのでＶＭ１に与えられた時間ではＣＰＵサイクルが無駄／アイドル状態になってしまう。これは、ＣＰＵとグラフィクスアダプタのコア機能が常に同じコンテキストにあるからである。このようにシステムリソースを非効率に使用する状態を避けるには、本発明の実施形態にあるように、ＣＰＵの作業をグラフィクスアダプタの作業とは無関係にスケジューリングするとしてもよい。グラフィクスアダプタにおいて複数の異なるハードウェアクライアントインターフェースが利用可能なので、ＣＰＵは、大半の時間をＶＭ０のために費やしながらグラフィクスアダプタにも時々アクセスするようにスケジューリングされるとしてもよい。一方、グラフィクスアダプタのコア機能は、大半の時間をＶＭ１に費やしながらも時折はＶＭ０のために動作するように割り込まれるようにスケジューリングされるとしてもよい。
【００３４】
図３は、コンピュータシステム内で共有可能な入出力デバイスを発見および共有することを含む仮想化プロセスを示すフローチャートである。このシステムは図２に示したものであってもよい。この方法は、プラグアンドプレイ発見プロセスが該システム内で実行される動作３０４から始まる。例えばこれは、従来のＰＣＩデバイスおよび機能をエミュレーションするプロセス（ＰＣＩコンフィグレーションプロセスとも呼ぶ）の一部であるとしてもよい。発見プロセスでは、単一のグラフィクスアダプタカードの異なるクライアントインターフェースから各デバイス用の一意的なＰＣＩデバイス識別番号を読み取ることによって、複数の入出力デバイスを検出するとしてもよい。この動作は、システムの電源が入った後に、ＢＩＯＳ（Ｂａｓｉｃ  Ｉ／Ｏ  Ｓｙｓｔｅｍ）ファームウェアおよび／またはシステムのプロセッサが実行しているＶＭＭによって実行されるとしてもよい。アダプタカードは、複数のハードウェアクライアントインターフェースがそのコア入出力機能を共有する、共有可能入出力デバイスの例である。発見プロセスではさらに、制御インターフェース１２６（図２を参照のこと）の形態をとる別のデバイスも検出するとしてもよい。
【００３５】
別の実施形態によると、最初のブート中にＢＩＯＳが制御インターフェースだけを発見するとしてもよい。その後、ＶＭＭが制御インターフェースを利用して１以上のクライアントインターフェースを必要に応じて生成するとしてもよい。このようなインターフェースはすべて同時に生成してもよいし、必要になった時に生成されるとしてもよい。インターフェースが生成されると、ＶＭＭは新たに生成されたインターフェースの「挿入」を示すホットプラグイベントを見ることになる。例えば、米国特許出願第１０／７９４，４６９号（発明の名称：「仮想マシン間で物理デバイスを動的に再割当するための方法、装置およびシステム」、発明者：Ｌａｎｔｚ  ｅｔ  ａｌ．、出願日：２００４年３月５日、本願と同じ譲渡人に譲渡されている）を参照されたい。［ｍａｇ１５］
【００３６】
該方法は続いて、ＶＭＭ、またはサービスＶＭが１以上のＶＭを生成し、検出された入出力デバイスの１以上を生成されたＶＭに割り当てる、動作３０８に進む。本例では、検出されたデバイスはそれぞれ、システム内の各ＶＭのグラフィクスアダプタとなる。続いてサービスＶＭに基づき、制御インターフェースを介してアダプタをコンフィグレーションし、アダプタのコア入出力機能が、例えばある１つのＶＭに優先権を与える優先政策に従って共有されるようにする（動作３１２）。この後、ＶＭが実行されると、ＶＭＭは待機状態に入り基本的に入出力トランザクションには関わらない。これは、各ＶＭがこの段階では、ディスプレイグラフィクスを対象としたＯＳコールを、（例えば、割当られたハードウェアクライアントインターフェースを指し示すべくアドレスオフセットを追加することによって）容易に修正または傍受できるからである。
【００３７】
本発明は実施形態によっては、命令を格納した機械可読媒体またはコンピュータ可読媒体を備えるコンピュータプログラム製品またはソフトウェアとして提供されるとしてもよい。この命令により、コンピュータ（またはそれ以外の電子デバイス）がプログラミングされ本発明の実施形態に係るプロセスが実行される。ほかの実施形態によると、演算は、マイクロコードまたはハードワイヤードロジックを含むハードウェア素子によって実行されるとしてもよいし、プログラミングされたコンピュータ素子とカスタムハードウェア素子を自由に組み合わせたものによって実行されるとしてもよい。
【００３８】
機械可読媒体は、機械（例えば、１以上のプロセッサ、デスクトップコンピュータ、携帯可能コンピュータ、製造用設備またはプロセッサを有するその他のデバイス）によってアクセスできる形態で情報を提供（つまり格納または送信）するものであればどのような機構であってもよい。例を挙げると、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、磁気回転ディスク格納媒体、光ディスク格納媒体ならびに電気的、光学的、音的といった形態の伝播信号（例えば、搬送波や赤外線信号など）といった追記型／非追記型媒体がある。
【００３９】
要約すると、複数のクライアントが１つの物理デバイスを共有するための技術の実施形態を数多く説明してきた。上述の記載内容では、具体的な実施形態の例を挙げて本発明を説明してきた。しかしながら、本願の請求項に記載されている、より広い本発明の目的および範囲から離れることなく、開示した実施形態をさまざまに変形できることは明らかである。例えば、ＶＭＭが実行されるコンピュータシステムは複数のプロセッサ（ＣＰＵ）を備え、ＶＭクライアントはそれぞれ例えば異なるプロセッサで実行されるとしてもよい。そのようなシステム内の共有可能デバイスに複数のクライアントインターフェースがあるので、複数の異なるＶＭクライアントが、お互いに気付くことなく、該デバイスのコア機能に同時にアクセスできるようになる。この時ＶＭクライアントは、ＶＭクライアントの観点からは、互いに干渉することはない。ここで同時にアクセスとは例えば、あるトランザクション要求が入出力デバイスによって取得されつつあるがまだ完了しておらず、別のトランザクション要求も同じ入出力デバイスによって取得されつつあるがまだ完了していないことを意味する。仮想化されていないシステムでは、ＯＳは通常そのような状態が許されないようにする（例えば、２つのＣＰＵが同時に同じデバイスをプログラミングすることは許可されていない）。しかし、本明細書で説明した実施形態に係るＶＭシステムによると、ＶＭＭがそのような責任を負わずにすむのが望ましい（入出力デバイスへのアクセスをすべて監視する必要がある、またはそのようなアクセスすべてに関わらなくてはいけないソフトウェアが複雑であるのが理由である）。従ってそのようなシステムでは、ＶＭクライアントまたはゲストが同じ入出力デバイスにアクセスしている時に、ＶＭクライアント間またはゲスト間で調整が行われない。しかしそのようなアクセスは、上述した複数のクライアントインターフェースという特性により、入出力デバイスのコア機能に適切にルーティングされる。このため、このような方法は、マルチプロセッサＶＭシステムにおいて特に有用である。本明細書および添付の図面は、本発明を説明するためのものであって、本発明を限定するものではないと理解されたい。
【図１】
2008503015.tif 000003
【図２】
2008503015.tif 000004
【図３】
2008503015.tif 000005
【国際調査報告】
2008503015.tif 000006
2008503015.tif 000007
2008503015.tif 000008