JP7196439B2 - 仮想化環境におけるデバイスへのアクセス方法 - Google Patents

Description

本発明は、仮想的なコンピュータシステムを構築した仮想化環境においてデバイスにアクセスするためのアクセス方法に関する。

近年、ハードウェア上に仮想的なコンピュータシステムを構築した仮想化環境の採用が進んでいる。このような仮想化環境では、一般的に、１つのハードウェア上でハイパーバイザを動作させ、そのハイパーバイザ上で複数の仮想的なコンピュータシステムを動作させている。これにより、例えば複数の処理を並列して実行することが可能になる等、システムの高集積化や高性能化を実現することができる。以下、仮想的なコンピュータシステムを仮想マシンと称し、ハードウェアが備えるＣＰＵを物理ＣＰＵ、デバイスを物理デバイス、仮想マシン上に仮想化されたＣＰＵを仮想ＣＰＵ、デバイスを仮想デバイスと称する。

さて、仮想マシンは、ハードウェアが備えるストレージやネットワークインターフェース等の物理デバイスにアクセスしながら動作する。このとき、仮想マシン上では、仮想ＣＰＵが仮想デバイスにアクセスすることによって、物理デバイスにアクセスしている。そのため、複数の仮想マシンが構築されている場合であっても、各仮想マシンは、他の仮想マシンの存在を特段考慮することなく独自に動作することができる。

ただし、１つの物理デバイスに対して複数の仮想マシンから同時にアクセスすることはできないため、複数の仮想マシンが構築されている場合には、各仮想マシンは、物理デバイスを排他的に利用することになる。その場合、アクセスするタイミングによっては他の仮想マシンからのアクセスの完了を待機する排他待ちが発生することから、排他待ちを効率的よく実現するためにｖｉｒｔｉｏと呼ばれる仮想化技術が存在している。

ｖｉｒｔｉｏは、ハイパーバイザ上のデバイスドライバが各仮想マシンからのアクセスの要求をキューイングし、物理デバイスへのアクセスが完了するとその要求に対して応答を返す構成となっている。このため、物理デバイスへのアクセスの要求とその要求に対する応答とが切り分けられ、アクセスを要求してから応答が返ってくるまでの期間がいわゆるＩ／Ｏ待ちの状態となることから、アクセス元となった仮想ＣＰＵではＩ／Ｏ待ちの期間に他のタスクを実行することが可能になる。そして、このようなｖｉｒｔｉｏに対しては、例えば特許文献１のように割り込みのオーバーヘッドを改善する等、仮想化環境を効率化するための提案がなされている。

特表２０１７－５１８５８９号公報

ところで、物理デバイスの中には、アクセスの要求と応答とを切り分けることが困難なデバイスが存在する。例えば、ＧＰＵ（Graphics Processing Unit）は、独自のレジスタをアクセスして複雑な構造を持つ描画要求メモリを伝達する必要があることから、アクセスの要求と応答とを切り分けることが一般的に困難である。そのため、従来では、ＧＰＵにアクセスする場合には、描画要求メモリへのread/write命令をトリガーとする描画の開始から描画が完了するまでの処理を一括で実行するようにしていた。

しかしながら、アクセスの終了までの処理を一括で実行する場合、アクセス元となる仮想ＣＰＵは、描画が完了するまでＧＰＵのレジスタへのｒｅａｄ／ｗｒｉｔｅ命令を実行中になる。その場合、描画を処理するタスクをＩ／Ｏ待ちの状態にすることができないことから、アクセス元の仮想ＣＰＵは、ＧＰＵからの応答を待っているだけの状態であったとしても、その待ち時間に他のタスクを実行することができなかった。

このように仮想ＣＰＵが占有された状態になると、他のタスクに切り替えることができなくなり、仮想マシンの処理能力が低下することになるとともに、割り当てた物理ＣＰＵの利用効率も低下してしまう等、仮想化環境全体のパフォーマンスの低下を招いていた。

本発明の目的は、ハードウェア上に仮想的なコンピュータシステムを構築した仮想化環境において、アクセス元のＣＰＵを占有するタイプのデバイスにアクセスする際のパフォーマンスの低下を抑制することができるアクセス方法を提供することにある。

上記目的を達成するために、本発明は、仮想マシン上に、常には物理ＣＰＵに割り当てられている常駐型の仮想ＣＰＵと、常には物理ＣＰＵが割り当てられていない非常駐型の仮想ＣＰＵとを実装し、常駐型の仮想ＣＰＵから占有型の物理デバイスに対応する仮想デバイスにアクセスする際、当該仮想デバイスにアクセスする処理を非常駐型の仮想ＣＰＵに代行させるアクセス方法を採用している。

この場合、当初のアクセス元である常駐型の仮想ＣＰＵは、仮想デバイスにアクセスする処理から開放されることから、他の処理を実行することが可能になる。一方、仮想デバイスにアクセスする処理を代行する非常駐型の仮想ＣＰＵは、仮想マシン上においては仮想デバイスに占有された状態になるものの、その状態は、ハイパーバイザから見れば物理デバイスからの応答を待ち合わせて何も動作していないものとして認識される。

そのため、ハイパーバイザ上では、何も動作していない非常駐型の仮想ＣＰＵへの物理ＣＰＵの割り当てを解除でき、割り当てが解除された物理ＣＰＵを、他の処理を実行することが可能な状態となっている常駐型の仮想ＣＰＵに割り当てることができる。

これにより、仮想化環境において占有型の物理デバイスにアクセスする際、仮想マシン上では、非常駐型の仮想ＣＰＵによってアクセスする処理を継続したまま、常駐型の仮想ＣＰＵによって他の処理を実行することができる。したがって、アクセス元のＣＰＵを占有する占有型の物理デバイスにアクセスする場合であっても、仮想化環境のパフォーマンスが低下することを抑制できる。

第１実施形態による仮想化環境の一例を模式的に示す図 アクセス時の作動と物理ＣＰＵの割り当て状態との一例を模式的に示す図 第２実施形態による仮想化環境の一例を模式的に示す図

以下、複数の実施形態について図面を参照しながら説明する。また、各実施形態において実質的に共通する構成には同一の符号を付して説明する。

（第１実施形態）
以下、第１実施形態について、図１および図２を参照しながら説明する。
図１に示すように、本実施形態の仮想化環境１は、ハードウェア１００、ハードウェア１００上で動作するハイパーバイザ２００、ハイパーバイザ２００上で動作する複数の仮想マシン３００を含んで構成されている。以下、ハードウェア１００が備えるＣＰＵを物理ＣＰＵ、デバイスを物理デバイス、仮想マシン３００上に仮想化されたＣＰＵを仮想ＣＰＵ、デバイスを仮想デバイスと称して説明する。

ハードウェア１００は、物理ＣＰＵに相当する例えば４つのｐＣＰＵ１０１～ｐＣＰＵ１０４、物理デバイスに相当するＧＰＵ１０５（Graphics Processing Unit）、ＰＩＣ１０６（Programmable Interrupt Controller）、およびＴＩＭＥＲ１０７等を備えている。本実施形態の場合、ハードウェア１００上には４つのＣＰＵコアを単一パッケージに収容したＣＰＵが設けられており、これら４つのＣＰＵコアをそれぞれ個別の物理ＣＰＵとして扱っている。また、各物理ＣＰＵは、ｐＣＰＵ１０１およびｐＣＰＵ１０２がＶＭ０の仮想マシン３００に割り当てられ、ｐＣＰＵ１０３およびｐＣＰＵ１０４がＶＭ１の仮想マシン３００に割り当てられている。

ＧＰＵ１０５は、周知のようにディスプレイ２への描画を処理する機能を有しており、本実施形態では、独自のレジスタに複雑な構造を持つ描画要求メモリを伝達することで描画を処理する。このＧＰＵ１０５は、詳細は後述するが、ＧＰＵ１０５へのアクセスの要求と応答とを切り分けることが困難であり、レジスタへのアクセス中にはアクセス元のＣＰＵを占有するタイプのインターフェースを備えた占有型の物理デバイスに相当する。また、このＧＰＵ１０５は、それぞれの仮想マシン３００によって共有される共有デバイスでもある。

ＰＩＣ１０６は、ＧＰＵ１０５等の物理デバイスからの割り込みの設定や割り込みの有効化／無効化あるいは割り込みの通知先となるＣＰＵの設定等、ハイパーバイザ２００上で発生する割り込みを制御するための周知の機能を有している。ＴＩＭＥＲ１０７は、ハイパーバイザ２００上で必要となる各種の時間を計時する機能を有しており、例えばタイマ割り込み等の周知の処理に利用される。なお、図示は省略するが、ハードウェア１００上には、例えばｅＭＭＣ（embedded Multi Media Card）等のストレージデバイスやＮＩＣ（Network Interface Card）のような通信デバイス等の物理デバイス等も設けられている。

ハイパーバイザ２００は、周知のようにハードウェア１００を仮想化することによって例えば複数の仮想マシン３００を動作させるソフトウェアである。本実施形態では、ハードウェア１００上でハイパーバイザ２００が直接動作し、そのハイパーバイザ２００上で仮想マシン３００が動作するベアメタル型あるいはネイティブ型と称されるものを想定している。このハイパーバイザ２００には、ハイパーバイザスケジューラ２０１、ｖＧＰＵドライバ２０２等が設けられている。

ハイパーバイザスケジューラ２０１は、各仮想マシン３００のスケジューリング等を行うソフトウェアである。ｖＧＰＵドライバ２０２は、仮想マシン３００上に仮想デバイスを実現するためのドライバソフトウェアであり、本実施形態ではＧＰＵ１０５を仮想化した仮想デバイスであるｖＧＰＵ３０５を仮想マシン３００上に実現している。

ｖＧＰＵドライバ２０２は、各仮想マシン３００からのアクセスを排他的に処理する排他ロック機能２０３を有している。なお、図１では、排他ロック機能２０３をｌｏｃｋとして示している。ｖＧＰＵドライバ２０２は、各仮想マシン３００から物理デバイスへのアクセスが要求された場合、排他ロック機能２０３により各仮想マシン３００からのアクセスを排他的に処理することで、それぞれの仮想マシン３００からのアクセスの要求に対して正しく物理デバイスを利用できるように制御する。なお、図１では図示を省略しているが、ハイパーバイザ２００には他のアプリケーションや他の物理デバイス用のドライバソフトウェア等も実装されている。

仮想マシン３００は、周知のようにハイパーバイザ２００上で動作する仮想的なコンピュータシステムであり、仮想ＣＰＵ上で仮想ＯＳ（Operating System）を動作させ、仮想デバイスにアクセスしながら各種の処理を実行するように構成されている。本実施形態では、ハイパーバイザ２００上に構築されているＶＭ０およびＶＭ１の２つの仮想マシン３００は同一構成となっている。そのため、以下では主としてＶＭ０の仮想マシン３００を例にして説明する。なお、異なる構成の仮想マシン３００を構築することも可能である。

仮想マシン３００は、仮想ＣＰＵに相当するｖＣＰＵ３０１、ｖＣＰＵ３０２およびｖＣＰＵ３０３、仮想デバイスに相当するｖＧＰＵ３０５、ｖＰＩＣ３０６、ｖＴＩＭＥＲ３０７等を備えている。このうち、ｖＣＰＵ３０１およびｖＣＰＵ３０２は、常には物理ＣＰＵに割り当てられて動作可能になっている常駐型の仮想ＣＰＵに相当し、ｖＣＰＵ３０３は、常には物理ＣＰＵに割り当てられておらず、必要に応じて物理ＣＰＵが割り当てられて動作可能になる非常駐型の仮想ＣＰＵに相当する。つまり、仮想マシン３００は、常には動作可能な仮想ＣＰＵが、割り当てられる物理ＣＰＵの数だけ実装されている。

各仮想ＣＰＵには、割り当て可能な物理ＣＰＵを示すｃｐｕｍａｓｋがそれぞれ設定されている。このｃｐｕｍａｓｋには、割り当てが可能な物理ＣＰＵの識別情報が例えばビット列として設定されている。例えばＶＭ０の場合、ｖＣＰＵ３０１、ｖＣＰＵ３０２およびｖＣＰＵ３０３の３つの仮想ＣＰＵには、それぞれｐＣＰＵ１０１およびｐＣＰＵ１０２の２つの物理ＣＰＵが割り当て可能であることを示す値が設定されている。なお、ＶＭ１の場合、３つの仮想ＣＰＵのｃｐｕｍａｓｋには、ｐＣＰＵ１０３とｐＣＰＵ１０４の２つの物理ＣＰＵが割り当て可能であることを示す値が設定される。つまり、各仮想マシン３００上の各仮想ＣＰＵには、それぞれ物理ＣＰＵが重複しないように割り当てられている。

これにより、各仮想マシン３００の仮想ＣＰＵに対して物理ＣＰＵが個別に配分され、互いの仮想マシン３００の動作が他方の仮想マシン３００のパフォーマンスに影響を与えるおそれを無くすことができる。なお、ｃｐｕｍａｓｋは割り当て可能な物理ＣＰＵを識別する値であって、実際にどの物理ＣＰＵが割り当てられるかは、ハイパーバイザスケジューラ２０１によって管理される。

仮想マシン３００上には、周知のように、各種のタスクＴ０～ＴＮを起動するタスク起動処理３０８、起動されたタスクのスケジューリング等を行うＯＳスケジューラ３０９が実装されている。また、仮想マシン３００上には、仮想デバイスにアクセスするためのドライバソフトウェアである仮想ドライバが実装されている。本実施形態では、ｖＧＰＵ３０５にアクセスするためのグラフィックドライバ３１０を想定している。なお、図１では図示を省略しているが、他の仮想デバイス用のドライバソフトウェアも実装されている。

各タスクには、タスク起動処理３０８によってｃｐｕｍａｓｋｖが設定される。このｃｐｕｍａｓｋｖは、そのタスクを実行可能な仮想ＣＰＵの番号等の識別情報が設定されている。本実施形態の場合、各タスクのｃｐｕｍａｓｋｖには、常駐型の仮想ＣＰＵであるｖＣＰＵ３０１およびｖＣＰＵ３０２での実行を許可する一方、非常駐型の仮想ＣＰＵであるｖＣＰＵ３０３での実行を許可しない値が設定される。そのため、起動したタスクは、ｃｐｕｍａｓｋｖを参照したＯＳスケジューラ３０９によって、ｖＣＰＵ３０１またはｖＣＰＵ３０２のいずれかに割り振られる。このとき、ＯＳスケジューラ３０９は、各仮想ＣＰＵが均等に使用されるようにタスクを割り振る。

グラフィックドライバ３１０は、占有型の仮想デバイスであるｖＧＰＵ３０５にアクセスするためのものであり、仮想デバイスにアクセスするアクセス部分（ｓ）を有するシステムコール部３１１と、アクセス部分（ｉ）を有する割り込みハンドラ部３１２とを含んでいる。なお、システムコール部３１１および割り込みハンドラ部３１２の動作は周知であるので、説明を省略する。

また、グラフィックドライバ３１０は、ｃｐｕｍａｓｋ変更処理３１３、および、ＩＲＱｍａｓｋ設定処理３１４を有している。詳細は後述するが、ｃｐｕｍａｓｋ変更処理３１３は、詳細は後述するがタスクに設定されているｃｐｕｍａｓｋを変更する処理であり、ＩＲＱｍａｓｋ設定処理３１４は、割り込みハンドラ部３１２を動作させる仮想ＣＰＵを示すＩＲＱｍａｓｋ３１５を設定する処理である。ｖＧＰＵ３０５の場合、仮想マシン３００の起動時に、ＩＲＱｍａｓｋ設定処理３１４によって割り込みハンドラ部３１２がｖＣＰＵ３０３でのみ動作するように設定されている。

次に、上記した構成の作用について説明する。
まず、ハイパーバイザ２００を採用した仮想化環境１の動作について簡単に説明する。ハイパーバイザ２００は、ハイパーバイザスケジューラ２０１、物理ＣＰＵ、ＰＩＣ１０６やＴＩＭＥＲ１０７等を利用しつつ仮想マシン３００を並列動作させている。このとき、各仮想マシン３００のリアルタイム性能を最大限に活かすため、ｃｐｕｍａｓｋを設定して物理ＣＰＵをそれぞれの仮想マシン３００に対して個別に配分し、他の仮想マシン３００の影響を受けないように、また、他の仮想マシン３００に影響を与えないようにしている。

具体的には、例えばｖＣＰＵ３０１とｖＣＰＵ３０２が稼動状態となっており、ｖＣＰＵ３０３が待機状態となっている場合には、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１とｖＣＰＵ３０２のｃｐｕｍａｓｋを参照して、例えばｐＣＰＵ１０１をｖＣＰＵ３０１に割り当て、ｐＣＰＵ１０２をｖＣＰＵ３０２に割り当てる。なお、ここで言う稼動状態とは、仮想ＣＰＵに何らかの処理が割り振られた状態を意味しており、稼動状態の仮想ＣＰＵに物理ＣＰＵが割り当てられると、その仮想ＣＰＵは動作可能な状態になる。

一方、ハイパーバイザ２００は、ｖＣＰＵ３０３が稼動状態になると、ｐＣＰＵ１０１またはｐＣＰＵ１０２をｖＣＰＵ３０３に割り当て、その期間はｖＣＰＵ３０１かｖＣＰＵ３０２のいずれかは物理ＣＰＵ待ちの状態になる。このように、ハイパーバイザ２００は、仮想ＣＰＵに対して極力均等に物理ＣＰＵが割り当てることで、仮想化環境１が効率的に動作するようにしている。これにより、各仮想マシン３００は、２つの物理ＣＰＵを備えたＯＳと同等の性能で動作することができ、複数のタスクの同時実行がハイパーバイザ２００を使わない通常のＯＳと同様に実現されている。

さて、このような仮想化環境１では、各仮想マシン３００は、ハードウェア１００上のＧＰＵ１０５や上記したｅＭＭＣあるいはＮＩＣ等の物理デバイスを共有してアクセスすることがある。そのため、仮想化環境１では、例えばｖＧＰＵドライバ２０２をハイパーバイザ２００上で動作させ、仮想マシン３００上に仮想デバイスを実現することにより、各仮想マシン３００では独立したデバイスのようにアクセスすることを可能としている。

ただし、ハードウェア１００が備える物理デバイスが１つの場合には、複数の仮想マシン３００からのアクセスの要求は時分割で排他的に処理されることになる。その場合、他の仮想マシン３００がアクセスしている場合には排他待ち状態となることから、前述したｖｉｒｔｉｏのような仮想化技術が存在している。

ただし、物理デバイスの中には、本実施形態のＧＰＵ１０５のようにアクセスの要求と応答とを切り分けることが困難であり、また、アクセス時にレジスタ命令の実行中となってタスクをＩ／Ｏ待ちの状態にすることができないような占有型のデバイスが存在する。このような占有型のデバイスにアクセスする場合には、例えばＧＰＵ１０５からの応答を待っているだけの状態であったとしても、その待ち時間に他のタスクを実行することができないことから、仮想化環境１のパフォーマンスが低下することになる。

具体的には、ＧＰＵ１０５で言えば描画実行中には描画以外のタスクを実行できず、ＣＰＵの有効活用ができないことから、他処理の遅延を招いてしまうことになる。特に、描画処理では大量の仮想マシン３００上のメモリにアクセスすることから、その待ち時間が例えば数十ミリ秒かかってしまうようなケースも想定される。その場合、他のタスクが実行できなくなると、画像とともに音声再生のタスクを同時実行している場合には、音切れを発生させてしまう。また、リアルタイム性を求める処理が実行されない場合や遅延する場合も想定される。

そこで、本実施形態では、占有型のデバイスへのアクセス中には仮想ＣＰＵが占有されて他のタスクへの切り替えはできないものの、物理ＣＰＵは何も処理をしていない状態になっていることに着目し、仮想化環境１のパフォーマンスが低下することを抑制している。

以下、仮想マシン３００上で起動されたタスクＴ０からＧＰＵ１０５に対するアクセスの要求が発行される場合を例にして、本実施形態のアクセス方法について説明する。なお、一般的なＯＳの場合にはアプリケーションはプロセス空間を有するものでありスレッドと称されることもあるが、本明細書では、アプリケーションであってもＯＳ内部で実行されるものであっても、同時に実行可能なプログラム単位をタスクと称している。

さて、仮想マシン３００上でタスクＴ０が起動されると、タスクＴ０は、ｃｐｕｍａｓｋｖの設定によりｖＣＰＵ３０１またはｖＣＰＵ３０２に割り当てられる。ここでは、図２に示すように、例えば時刻ｔ０においてタスクＴ０が起動され、タスクＴ０がｖＣＰＵ３０１に割り当てられたとする。なお、図２の物理ＣＰＵの割り当て状態として示すように、タスクＴ０を実行するｖＣＰＵ３０１には物理ＣＰＵとしてｐＣＰＵ１０１が割り当てられているものとする。また、図２において各タスクに対応して設けた太線は、物理ＣＰＵが割り当てられていることを示している。

タスクＴ０が実行されてグラフィックドライバ３１０を呼び出されると、タスクＴ０ではシステムコール部３１１が動作する。システムコール部３１１では、まず、タスクＴ０のｃｐｕｍａｓｋｖ０をｖＣＰＵ３０３でのみ実行可能となるように変更するｃｐｕｍａｓｋ変更処理３１３が実行される。また、このｃｐｕｍａｓｋ変更処理３１３では、ｃｐｕｍａｓｋｖ０がｖＣＰＵ３０１およびｖＣＰＵ３０２を含まない値に変更されたことを確認すると、タスクＴ０を実行可能になったｖＣＰＵ３０３にタスクＴ０を再割り当てするようにＯＳスケジューラ３０９に指示が出される。

ＯＳスケジューラ３０９に指示が出されると、ｖＣＰＵ３０３が他のタスクに使用されている場合には一旦待ち状態となるが、ｖＣＰＵ３０３が使われていなかった場合あるいは待ち状態が終了した場合には、ｖＣＰＵ３０３にタスクＴ０が割り当られてｖＣＰＵ３０３が稼動状態になる。仮想ＣＰＵの稼動状態はハイパーバイザ２００上のハイパーバイザスケジューラ２０１によってチェックされていることから、ｖＣＰＵ３０３が稼動状態になったこともハイパーバイザスケジューラ２０１に検知されることになる。

ｖＣＰＵ３０３が稼動状態になったことを検知したハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１およびｖＣＰＵ３０２に加えて、ｖＣＰＵ３０３を物理ＣＰＵの割り当て対象とする。この状態では一時的には３つの仮想ＣＰＵが２つの物理ＣＰＵ上で動作することになるため、例えば図２の時刻ｔ１においてｖＣＰＵ３０３にｐＣＰＵ１０１が割り当てられたとすると、それまでｐＣＰＵ１０１が割り当てられていたｖＣＰＵ３０１は一時的に物理ＣＰＵ待ちの状態になる。つまり、時刻ｔ１において、タスクＴ０を実行する仮想ＣＰＵが、ｖＣＰＵ３０１からｖＣＰＵ３０３に切り替えられる。

この時点でシステムコール部３１１がｖＣＰＵ３０３で動作可能な状態になることから、システムコール部３１１の処理をｖＣＰＵ３０３上で継続することができる。そのため、システムコール部３１１は、アクセス部分（ｓ）を呼び出し、アクセス部分（ｓ）はｖＧＰＵ３０５のレジスタにアクセスする。ｖＧＰＵ３０５へのアクセスはハイパーバイザ２００上のｖＧＰＵドライバ２０２に伝達されるものの、他の仮想マシン３００の実行の待ち合わせやＧＰＵ１０５へアクセスする準備のために排他ロック機能２０３によって一旦待機する。このとき、ｖＣＰＵ３０３は、ロック解除待ちで待機状態になる。

例えば図２の時刻ｔ２においてｖＣＰＵ３０３が待機状態になったとすると、処理が仮想マシン３００からハイパーバイザ２００に移管されるＶＭホスト切り替えが行われる。このとき、ハイパーバイザスケジューラ２０１は、待機状態になって何も処理を行っていないｖＣＰＵ３０３へのｐＣＰＵ１０１の割り当てを解除するとともに、物理ＣＰＵ待ちの状態となっているｖＣＰＵ３０１にｐＣＰＵ１０１を再び割り当ててｖＣＰＵ３０１を動作可能な状態とする。ｖＣＰＵ３０１が動作可能な状態になると、仮想マシン３００上では例えばタスクＴ１をｖＣＰＵ３０１で実行することが可能になる。

そのため、３つの仮想ＣＰＵに２つの物理ＣＰＵを割り当てている状態であっても、ｖＣＰＵ３０３は待機状態となっていることから物理ＣＰＵの割り当てを解除でき、その結果、実質的にｖＣＰＵ３０１とｖＣＰＵ３０２の２つの仮想ＣＰＵで２つの物理ＣＰＵを占有的に使用することが可能になる。このため、仮にアクセス部分（s）のレジスタへのアクセスが遅延したりアクセスに時間を要したりする場合であっても、仮想化環境１全体としての性能は実質的に２つの仮想ＣＰＵに２つの物理ＣＰＵを割り当てた状態と同等となり、仮想化環境１のパフォーマンスを維持することが可能になる。

さて、ｖＧＰＵドライバ２０２にて排他待ちのロックが解除されてＧＰＵ１０５へのアクセスが終了すると、その結果がアクセス部分（ｓ）に返されることから、タスクＴ０が動作可能な状態、より具体的に言えば、中断していたアクセス部分（ｓ）が動作を再開可能な状態になる。この場合、ｖＣＰＵ３０３に物理ＣＰＵを割り当てる必要があるが、タスクＴ０が動作可能な状態になったことを検知したハイパーバイザスケジューラ２０１により所定のスケジューリング時間後に物理ＣＰＵの割り当てが見直され、ｖＣＰＵ３０３に例えばｐＣＰＵ１０１が割り当てられる。これにより、アクセス部分（ｓ）は動作を再開する。

そして、アクセス部分（ｓ）の処理が終わると、ｃｐｕｍａｓｋ変更処理３１３によって、ｃｐｕｍａｓｋｖ０を、ｖＣＰＵ３０１およびｖＣＰＵ３０２での実行を許可する一方、ｖＣＰＵ３０３での実行を許可しない値に変更する。つまり、ｃｐｕｍａｓｋｖ０は元の値に戻される。その結果、タスクＴ０がｖＣＰＵ３０１またはｖＣＰＵ３０２の動作待ちになるとともに、ｖＣＰＵ３０３が何も処理をしていない状態になる。

そのため、ハイパーバイザスケジューラ２０１は、何も処理をしていないｖＣＰＵ３０３を物理ＣＰＵの割り当てを解除し、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵを割り当てるように動作する。これにより、ｖＣＰＵ３０１とｖＣＰＵ３０２は、それぞれｐＣＰＵ１０１とｐＣＰＵ１０２をフルタイムで利用可能な状態に復帰する。

ここで注目すべきは、レジスタへのアクセス中は、タスクＴ０としては待機状態ではなくｖＣＰＵ３０３上で動作状態であったことである。ＯＳスケジューラ３０９は、動作状態にあるタスクから他のタスクに切り替えることができないため、従来であれば、タスクＴ０を実行していたｖＣＰＵ３０１に他のタスクを実行させることができなかった。

これに対して、本実施形態では、ｃｐｕｍａｓｋ変更処理３１３によってタスクＴ０の実行主体をｖＣＰＵ３０１からｖＣＰＵ３０３に切り替えている。つまり、ｖＧＰＵ３０５にアクセスする処理をｖＣＰＵ３０３に代行させている。この状態では３つの仮想ＣＰＵが動作することになるものの、実質的にはｖＧＰＵドライバ２０２は排他待ちの状態になっていることから、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０３には物理ＣＰＵを割り当てず、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵが割り当てている。

つまり、非常駐型の仮想ＣＰＵであるｖＣＰＵ３０３を設けて、ｖＣＰＵ３０３がｖＧＰＵ３０５の動作完了を待ち合わせて待機状態となるように構成したことにより、ｖＣＰＵ３０１をタスクＴ０から開放することが可能となり、ｖＣＰＵ３０１に他のタスクを実行させることができ、仮想化環境１全体として効率的な動作が可能になったのである。

ところで、グラフィックドライバ３０１のシステムコール部３１１は、ｖＧＰＵ３０５のレジスタへのアクセスだけでシステムコールの目的を果たすものもあれば、ｖＧＰＵ３０５の状態の変化を待ち合わせてからレジスタアクセスをする場合もある。この場合、システムコール部３１１は要求内容をメモリ上に記録し、ｖＧＰＵ３０５の状態変化があったときに動作するように設定して終了する。

ｖＧＰＵ３０５の状態変化は、割り込みによって通知される。このとき、ＰＩＣ１０６によってハイパーバイザスケジューラ２０１に割り込みが通知される。通知された割り込みは、ｖＰＩＣ３０６のＩＲＱｍａｓｋ３１５によってｖＣＰＵ３０３が設定されていることから、ｖＣＰＵ３０３で処理されることになる。そのため、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０３の割込みハンドラ部を動作させるために、ｖＣＰＵ３０３に物理ＣＰＵを割り当てる。

割り込みハンドラ部３１２が動作してアクセス部分（ｉ）がｖＧＰＵ３０５のレジスタにアクセスすると、ｖＧＰＵ３０５へのアクセスはハイパーバイザ２００上のｖＧＰＵドライバ２０２に伝達されるものの、他の仮想マシン３００の実行の待ち合わせやＧＰＵ１０５へアクセスする準備のために排他ロック機能２０３によって一旦待機する。このとき、ｖＣＰＵ３０３は、ロック解除待ちで待機状態になる。このとき、ハイパーバイザスケジューラ２０１は、アクセス部分（ｓ）と同様に、排他待ち状態となったｖＣＰＵ３０３への物理ＣＰＵの割り当てを解除するとともに、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵを割り当てて動作させる。これにより、アクセス部（ｉ）のレジスタへのアクセス待ちの間も仮想マシン３００上の他のタスクを動作可能にすることができるようになる。

そして、ｖＧＰＵドライバ２０２の排他待ちが完了すると、アクセス部分（ｉ）が動作を再開し、ｖＧＰＵドライバ２０２を経由してＧＰＵ１０５のアクセスが可能となる。また、割込みハンドラ部３１２の動作が終了すると、ｖＣＰＵ３０３が空きとなり、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１とｖＣＰＵ３０２の処理だけを行うようになる。

このように、本実施形態では、グラフィックドライバ３１０において、アクセス部分（ｓ）およびアクセス部分（ｉ）の処理を非常駐型のｖＣＰＵ３０３で行うことにより、レジスタへのアクセスを待ち合わせてアクセス元のＣＰＵが占有されるような場合であっても、他のタスクが常駐型の仮想ＣＰＵで動作できるアクセス方法を採用している。

以上説明したアクセス方法によれば、次のような効果を得ることができる。
アクセス方法は、仮想化環境１において、仮想マシン３００上に、常には物理ＣＰＵが割り当てられている常駐型の仮想ＣＰＵ（ｖＣＰＵ３０１、ｖＣＰＵ３０２）と、常には物理ＣＰＵが割り当てられていない非常駐型の仮想ＣＰＵ（ｖＣＰＵ３０３）とを実装し、常駐型の仮想ＣＰＵから占有型の物理デバイスに対応する仮想デバイスにアクセスする際、当該仮想デバイスにアクセスする処理を非常駐型の仮想ＣＰＵに代行させる。

これにより、アクセス元となる常駐型の仮想ＣＰＵから非常駐型の仮想ＣＰＵに処理が移管され、非常駐型の仮想ＣＰＵがアクセス中に占有状態になったとしても、常駐型の仮想ＣＰＵにおいて他のタスクを実行することが可能になる。この場合、アクセス中に占有状態になった非常駐型の仮想ＣＰＵが実質的に何も処理をしていない待機状態になれば物理ＣＰＵの割り当てを解除できるため、占有型のデバイスへのタスクを継続したまま、常駐型の仮想ＣＰＵに物理ＣＰＵを割り当てて他のタスクを実行させることができる。

したがって、占有型の物理デバイスにアクセスする場合であっても物理ＣＰＵを有効的に利用することができ、ハードウェア１００上に仮想的なコンピュータシステムを構築した仮想化環境１において、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。
また、システムコール要求におけるレジスタアクセスは、システムコール呼び出しの延長時に行うものと、割り込みの延長時に行うものとの２つが想定されるものの、いずれの場合にも上記したアクセス方法を適用でき、占有型のデバイスへのアクセス時に物理ＣＰＵを有効活用することができる。

この場合、非常駐型の仮想ＣＰＵは稼動状態でなければ物理ＣＰＵの割り当て対象とはならないため、単純に３つの常駐型の仮想ＣＰＵを設けて時系列で３つの仮想ＣＰＵをスケジューリングする構成とは異なり、仮想化環境１のパフォーマンスに影響を与えることもない。したがって、仮想化環境１にリアルタイム性が求められる場合において、特に有意となる。

この場合、本実施形態のように、占有型の仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部３１１と割り込みハンドラ部３１２とを含み、前記システムコール部３１１と前記割り込みハンドラ部３１２のそれぞれに仮想デバイスにアクセスするアクセス部分が設けられている仮想ドライバを実装し、常駐型の仮想ＣＰＵから占有型の仮想デバイスにアクセスする際、少なくともアクセス部分（ｓ、ｉ）を非常駐型の仮想ＣＰＵで代行するアクセス方法を採用することができる。

このような構成によっても、アクセス部分（ｓ）を切り分けて処理することが難しいデバイスであっても占有型のデバイスへのアクセスを非常駐型の仮想ＣＰＵに容易に代行させることが可能となり、上記したように占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。

また、本実施形態のように、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させる場合であっても、それぞれの仮想マシン３００において上記したアクセス方法を採用することにより、各仮想マシン３００の性能を維持することができる。つまり、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させ、複数の仮想マシン３００に物理ＣＰＵを重複しないように割り当てる構成とすることで、より厳密には、各仮想マシン３００上の各仮想ＣＰＵにそれぞれ物理ＣＰＵを重複しないように割り当てることで、仮想化環境１の性能が最も高くなると期待できる。

また、本実施形態ではハードウェア１００が１つの占有型の物理デバイスを備える構成を例示したが、ハードウェア１００が複数の占有型の物理デバイスを備えている場合には、ハードウェア１００が備える占有型の物理デバイスと同じ数の非常駐型の仮想ＣＰＵを実装することにより、上記したアクセス方法を採用することができる。

換言すると、仮想マシン３００に割り当てられる物理ＣＰＵの数に等しい常駐型の仮想ＣＰＵと、仮想マシン３００においてアクセス対象となる占有型の物理デバイスの数に等しい非常駐型の仮想ＣＰＵとを設けることにより、占有型の物理デバイスにアクセスするとき以外の期間においては従来と同等の性能を確保することができるとともに、占有型の物理デバイスにアクセスする期間においては従来では不可能であった別のタスクの実行が可能となり、仮想化環境１の性能を向上させることができる。

ただし、常駐型の仮想ＣＰＵは、必要とされる場合には、仮想マシン３００に割り当てられる物理ＣＰＵの数よりも多くすることもできる。そのような構成であっても、非常駐型の仮想ＣＰＵを別途設けることにより、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。

（第２実施形態）
以下、第２実施形態について、図３を参照しながら説明する。第２実施形態では、システムコール部３１１で動作するアクセス部分（ｓ）を専用タスクとしている点において第１実施形態と異なっている。

図３に示すように、本実施形態の仮想化環境１は、ハードウェア１００、ハードウェア１００上で動作するハイパーバイザ２００、ハイパーバイザ２００上で動作する複数の仮想マシン３００を含んで構成されており、そのハードウェア１００上でハイパーバイザ２００が動作するとともに、そのハイパーバイザ２００上でＶＭ０およびＶＭ１の２つの仮想マシン３００が動作している。

ハードウェア１００は、第１実施形態と同様に、物理ＣＰＵに相当する４つのｐＣＰＵ１０１～ｐＣＰＵ１０４、物理デバイスに相当するＧＰＵ１０５、ＰＩＣ１０６、およびＴＩＭＥＲ１０７等を備えている。このうち、ｐＣＰＵ１０１およびｐＣＰＵ１０２は、ＶＭ０の仮想マシン３００に割り当てられ、ｐＣＰＵ１０３およびｐＣＰＵ１０４は、ＶＭ１の仮想マシン３００に割り当てられている。

ＧＰＵ１０５は、第１実施形態と同様に、ＧＰＵ１０５へのアクセスの要求と応答とを切り分けることが困難であり、レジスタへのアクセス中にはアクセス元のＣＰＵを占有するタイプのインターフェースを備えた占有型の物理デバイスを想定している。

ハイパーバイザ２００は、第１実施形態と同様に、ハイパーバイザスケジューラ２０１、ｖＧＰＵドライバ２０２等が設けられている。仮想マシン３００は、第１実施形態と同様に、常駐型の仮想ＣＰＵに相当するｖＣＰＵ３０１およびｖＣＰＵ３０２、非常駐型の仮想ＣＰＵに相当するｖＣＰＵ３０３、仮想デバイスに相当するｖＧＰＵ３０５、ｖＰＩＣ３０６、ｖＴＩＭＥＲ３０７等を備えているとともに、各種のタスクを起動するタスク起動処理３０８、起動されたタスクのスケジューリング等を行うＯＳスケジューラ３０９が実装されている。

また、仮想マシン３００上には、仮想ドライバとしてのグラフィックドライバ４１０が実装されている。本実施形態のグラフィックドライバ４１０は、専用タスク要求処理４１１により、システムコール部３１１から行われるｖＧＰＵ３０５へのアクセスを処理するアクセス部分（ｓ）を専用タスクＴＳとして呼び出し可能に構成されている。この専用タスクＴＳは、ｖＣＰＵ３０３でのみ動作が可能となるようにｃｐｕｍａｓｋｖＳが設定されている。

さて、仮想マシン３００上で起動したタスクＴ０からｖＧＰＵ３０５へのアクセスが発生すると、グラフィックドライバ４１０が呼び出されてシステムコール部３１１が動作する。すると、システムコール部３１１は、専用タスク要求処理４１１によって専用タスクＴＳのアクセス部分（ｓ）に処理の開始を要求するとともに、アクセス部分（ｓ）の処理の完了を待ち合わせる。この時点でｖＣＰＵ３０１は待ち状態となることから、他のタスクをｖＣＰＵ３０１上で動作させることが可能になる。つまり、専用タスクＴＳの実行中にｖＣＰＵ３０３が待ち状態になれば、ｖＣＰＵ３０１を動作させることができる。

この専用タスクＴＳは、ｃｐｕｍａｓｋｖＳの設定によってｖＣＰＵ３０３で処理を開始する。この状態では物理ＣＰＵを割り当てる仮想ＣＰＵが３つになるため、ハイパーバイザスケジューラ２０１は、ｐＣＰＵ１０１とｐＣＰＵ１０２を３つの仮想ＣＰＵに均等に配分しようとする。そして、ｖＣＰＵ３０３に物理ＣＰＵが割り当てられると、専用タスクＴＳのアクセス部分（ｓ）は、処理を開始してｖＧＰＵドライバ２０２をアクセスし、他の仮想マシン３００の排他待ちであれば一時的に処理を待機し、排他待ちが解除されると処理を再開する。

アクセス部分（ｓ）の処理が完了すると、ｖＣＰＵ３０３は、処理がなくなって待機状態となるとともに、完了が通知された専用タスク要求処理４１１が動作を再開し、システムコール部３１１は、第１実施形態と同様に割り込みハンドラ部３１２が動作するまでｖＧＰＵ３０５の動作完了待ちの状態となる。

このように、本実施形態では、アクセス部分（ｓ）を専用タスクとしてグラフィックドライバ４１０から呼び出す構成としたことにより、アクセスの要求つまりはアクセス部分（ｓ）への処理の開始と、その要求に対する応答つまりはアクセス部分（ｓ）の処理の完了とを切り離すことが可能になる。これにより、ｖＧＰＵ３０５へのアクセスを言わば擬似的なＩ／Ｏとして行うことが可能となり、そのＩ／Ｏ待ちの期間に他のタスクを実行することが可能になる。

したがって、占有型の物理デバイスにアクセスする場合であっても物理ＣＰＵを有効的に利用することができ、ハードウェア１００上に仮想的なコンピュータシステムを構築した仮想化環境１において、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。

この場合、第１実施形態と同様に、仮想化環境１のリソースを無駄に減らすことがなく、また、仮想化環境１のパフォーマンスに影響を与えることもないことから、仮想化環境１にリアルタイム性が求められる場合において特に有意となる。また、タスク起動処理３０８やＯＳスケジューラ３０９等の基本的な部分に手を加える必要もない。

また。本実施形態のように、占有型の仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部３１１と割り込みハンドラ部３１２とを含み、システムコール部３１１から行われる仮想デバイスへのアクセスを処理するアクセス部分を、専用タスクＴＳとして呼び出し可能に構成した仮想ドライバを実装し、常駐型の仮想ＣＰＵから占有型の仮想デバイスにアクセスする際、専用タスクＴＳを非常駐型の仮想ＣＰＵで実行することにより、仮想デバイスへのアクセスを擬似的なＩ／Ｏとして行うことが可能となる。

これにより、仮想ＣＰＵの動作が第１実施形態よりもシンプルなものになるため、アクセス部分（ｓ）を明確に分離できるデバイスを対象とする場合に容易に上記したアクセス方法を実現することができる。

ただし、アクセス部分（ｓ）が明確に分離できないデバイスを対象とする場合には第１実施形態のアクセス方法の方がよい場合もあるため、例えば対象となる占有型の物理デバイスが複数存在する場合には、物理デバイスによって第１実施形態のアクセス方法と第２実施形態のアクセス方法とを使い分けできるように、占有型の物理デバイスと同じ数の非常駐型の仮想ＣＰＵを実装するとともに、それぞれに適した複数の仮想ドライバを実装する構成とすることもできる。

（その他の実施形態）
第２実施形態では、仮想マシン３００上に専用タスクＴＳを設ける構成を例示したが、ハイパーバイザ２００上で類似の処理は行う構成とすることもできる。具体的には、ハイパーバイザ２００上のハイパーバイザスケジューラ２０１に、仮想マシン３００に加えて、占有型の物理デバイスに直接的にアクセス可能に構成したタスクをスケジューリング対象として配置し、非常駐型の仮想ＣＰＵからアクセスの要求があった際、ハイパーバイザ２００上に配置したタスクを用いて占有型の物理デバイスにアクセスする構成とすることができる。

このような構成の場合、ハイパーバイザ２００上のｖＧＰＵドライバ２０２は、タスクが物理デバイスへのアクセスを処理しているとき、第２実施形態のように、物理デバイスの動作が完了するまで仮想マシン３００側からの処理を待ち合わせることが可能になる。そのため、非常駐型の仮想ＣＰＵからのアクセスの要求を擬似的なＩ／Ｏとして扱うことができ、Ｉ／Ｏ待ちの期間には非常駐型の仮想ＣＰＵへの物理ＣＰＵの割り当てを解除できることから、常駐型の仮想ＣＰＵにおいて他のタスクを実行することができる。

これにより、デバイスにアクセスする際のパフォーマンスの低下を抑制することができる、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させる場合であっても各仮想マシン３００の性能を維持することができる等、各実施形態と同様の効果を得ることができる。また、タスクをハイパーバイザスケジューラ２０１上に配置していることから、仮想マシン３００上のＯＳスケジューラ３０９を介さずにその動作をスケジューリングすることができるため、例えばリアルタイム性が求められるアプリケーションに適用する等、優先度が高い処理に好適なものとなる。

各実施形態では占有型の物理デバイスへのアクセスを非常駐型の仮想ＣＰＵに代行させる例を示したが、アクセスに要する時間に基づいて非常駐型の仮想ＣＰＵに代行させるか否かを選択する構成とすることができる。具体的には、事前テスト等により計測した占有型の物理デバイスへのアクセスに要する最大待ち時間を予め設定し、最大待ち時間が予め設定した規定時間よりも長い場合にはアクセスする処理を非常駐型の仮想ＣＰＵに代行させる一方、最大待ち時間が規定時間よりも短い場合にはアクセスする処理を常駐型の仮想ＣＰＵで実行する構成とすることができる。

これにより、例えばアクセスを代行させる処理に要する時間がアクセスを代行させることで得られる物理ＣＰＵの利用時間よりも長くなる場合等にはアクセスを代行させないことが可能となり、仮想化環境のパフォーマンスを意図せずに低下させてしまうことを抑制できる。

各実施形態では占有型の物理デバイスとしてＧＰＵ１０５を例示したが、本実施形態のアクセス方法は、ＧＰＵ１０５に限定されず、例えばＧＰＵ１０５を画像処理以外の処理に応用するＧＰＧＰＵ（General-purpose computing on graphics processing units）や画像処理専用のＩＰＵ（Image processing unit）、あるいはベンダー独自のインターフェースを有するようなデバイスへのアクセスにも適用することができる。

各実施形態では、４つの物理ＣＰＵを２つの仮想マシン３００に割り当てた例を示したが、仮想マシン３００の数は、これに限定されない。構築する仮想マシン３００の数をＭとすると、ハードウェア１００が備える物理ＣＰＵの数がＭ以上であれば、各仮想マシン３００に重複無く物理ＣＰＵを割り当てることができる。つまり、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させ、複数の仮想マシン３００に物理ＣＰＵを重複しないように割り当てる構成とすることができる。このとき、各仮想マシン３００には割り当てられた物理ＣＰＵの数と同じ常駐型の仮想ＣＰＵを設け、対象となる占有型の物理デバイスの数と同じ非常駐型の仮想ＣＰＵを設け、上記したアクセス方法を適用することで、仮想化環境１のパフォーマンスが低下することを抑制することができる。

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に含まれるものである。

図面中、１は仮想化環境、１００はハードウェア、１０１～１０４はｐＣＰＵ（物理ＣＰＵ）、１０５はＧＰＵ（占有型の物理デバイス）、２００はハイパーバイザ、２０１はハイパーバイザスケジューラ、３００は仮想マシン、３０１～３０２はｖＣＰＵ（常駐型の仮想ＣＰＵ）、３０３はｖＣＰＵ（非常駐型の仮想ＣＰＵ）、３０５はｖＧＰＵ（仮想デバイス）、３１０はグラフィックドライバ（仮想ドライバ）、３１１はシステムコール部、３１２は込みハンドラ部、４１０はグラフィックドライバ（仮想ドライバ）、Ｔ０～ＴＮはタスク、ＴＳは専用タスクを示す。

Claims (7)

1. 仮想化環境（１）においてデバイスにアクセスするためのアクセス方法であって、
   物理ＣＰＵ（１０１、１０２、１０３、１０４）および物理デバイス（１０５）を備えたハードウェア（１００）と、前記ハードウェア上で動作するハイパーバイザ（２００）と、前記ハイパーバイザ上で動作し、前記物理ＣＰＵを仮想化した仮想ＣＰＵ（３０１、３０２、３０３）および前記物理デバイスを仮想化した仮想デバイス（３０５）を備える仮想マシン（３００）とを含み、
   前記ハードウェアは、アクセスが要求されてからその要求に対する応答を返すまでアクセス元のＣＰＵを占有する占有型の前記物理デバイス（１０５）を備えており、
   前記仮想マシン上には、予め前記物理ＣＰＵが割り当てられている常駐型の前記仮想ＣＰＵ（３０１、３０２）と、処理が必要になった際に前記物理ＣＰＵが割り当てられる非常駐型の前記仮想ＣＰＵ（３０３）とが実装されている仮想化環境において、
   常駐型の前記仮想ＣＰＵで実行されるタスクが占有型の前記物理デバイスに対応する前記仮想デバイスにアクセスする際、
   常駐型の前記仮想ＣＰＵへの前記物理ＣＰＵの割り当てを解除して非常駐型の前記仮想ＣＰＵに前記物理ＣＰＵを割り当てて、前記仮想デバイスへのアクセスを非常駐型の前記仮想ＣＰＵに代行させる処理と、
   前記物理ＣＰＵが割り当てられた非常駐型の前記仮想ＣＰＵがアクセスする処理のために待機状態となっている間、当該非常駐型の前記仮想ＣＰＵに割り当てられている前記物理ＣＰＵを、前記物理ＣＰＵが割り当てられていない常駐型の前記仮想ＣＰＵに割り当てて、アクセスする処理以外の他の処理を当該常駐型の前記仮想ＣＰＵで実行可能にする処理と、を実行することにより占有型の前記物理デバイスにアクセスするアクセス方法。
2. 前記仮想化環境は、前記仮想マシン上に、占有型の前記仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部（３１１）と割り込みハンドラ部（３１２）とを含み、前記システムコール部と前記割り込みハンドラ部とのそれぞれに前記仮想デバイスにアクセスするアクセス部分（ｓ、ｉ）が設けられている仮想ドライバ（３１０）が実装されており、
   非常駐型の前記仮想ＣＰＵにアクセスを代行させる処理では、前記アクセス部分を非常駐型の前記仮想ＣＰＵで実行する請求項１に記載のアクセス方法。
3. 前記仮想化環境は、前記仮想マシン上に、占有型の前記仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部と割り込みハンドラ部とを含み、前記システムコール部から行われる前記仮想デバイスへのアクセスを処理するアクセス部分（ｓ）を、アクセスの要求に対する処理と当該要求に対して応答する処理とを切り離して実行可能な専用タスク（ＴＳ）として呼び出し可能に構成した仮想ドライバ（４１０）が実装されており、
   非常駐型の前記仮想ＣＰＵにアクセスを代行させる処理では、前記専用タスクを非常駐型の前記仮想ＣＰＵで実行する請求項１に記載のアクセス方法。
4. 前記仮想化環境は、前記ハイパーバイザ上のハイパーバイザスケジューラ（２０１）に、前記仮想マシンに加えて、占有型の前記物理デバイスに直接的にアクセス可能に構成したタスクがスケジューリング対象として配置されており、
   非常駐型の前記仮想ＣＰＵにアクセスを代行させる処理では、アクセスの要求に対する処理と当該要求に対して応答する処理とを切り離して実行可能な専用タスクを非常駐型の前記仮想ＣＰＵで実行し、
   前記ハイパーバイザ上に配置されているタスクは、前記専用タスクが実行されている非常駐型の前記仮想ＣＰＵからアクセスの要求があった際、占有型の前記物理デバイスにアクセスする請求項１に記載のアクセス方法。
5. 前記仮想化環境は、占有型の前記物理デバイスへのアクセスに要する最大待ち時間が予め設定されており、
   非常駐型の前記仮想ＣＰＵにアクセスを代行させる処理では、前記最大待ち時間が予め設定した規定時間よりも長い場合にはアクセスする処理を非常駐型の前記仮想ＣＰＵに代行させる一方、前記最大待ち時間が前記規定時間よりも短い場合にはアクセスする処理を常駐型の前記仮想ＣＰＵで実行する請求項１から４のいずれか一項に記載のアクセス方法。
6. 前記仮想化環境は、前記ハイパーバイザ上で２つ以上の前記仮想マシンが動作しており、複数の前記仮想マシンに対して前記物理ＣＰＵが重複しないように割り当てられている請求項１から５のいずれか一項に記載のアクセス方法。
7. 前記仮想化環境は、前記仮想マシンに、前記ハードウェアが備える占有型の前記物理デバイスと同じ数の非常駐型の前記仮想ＣＰＵが実装されている請求項１から６のいずれか一項に記載のアクセス方法。

Images