JP5746770B2 - 仮想化によるスマートデバイスの直接的共有 - Google Patents

Description

本発明は、全体的に、仮想化によるスマートデバイスの直接的共有に関する。

入出力（Ｉ／Ｏ）デバイスの仮想化は、従来、完全なデバイスエミュレーションを実行するデバイスモデルを用いて実装されてきた。これにより、デバイスの共有が可能になるが、性能的に大幅なオーバーヘッドが発生する。デバイスを仮想マシン（ＶＭ）に直接デバイス割り当てすると、ネイティブ並みの性能が可能になるが、デバイスをＶＭ間で共有することはできない。シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）等の最近のハードウェアに基づいた設計では、デバイスは、共有されつつネイティブ並みの性能を発揮することもできるが、ハードウェアに大幅な変更が必要となる。

本発明は、以下に提示する詳細な記載および本発明のいくつかの実施形態を示す添付の図面からより完全に理解されるが、添付の図面は、本発明を特定の実施形態に限定するものと解されるべきでなく、説明および理解を促すためだけのものである。
本発明のいくつかの実施形態に係るシステムを示す。 本発明のいくつかの実施形態に係るフローを示す。 本発明のいくつかの実施形態に係るシステムを示す。 本発明のいくつかの実施形態に係るシステムを示す。 本発明のいくつかの実施形態に係るシステムを示す。

本発明のいくつかの実施形態は、仮想化によるスマートデバイスの直接的共有に関する。

いくつかの実施形態では、デバイスは、仮想マシンのワークロードを直接的に実行することが可能である。複数の仮想マシンからのワークロードは、切り分けてスケジューリングされる。

いくつかの実施形態では、入出力（Ｉ／Ｏ）デバイスを複数の仮想マシン（ＶＭ）間で共有しながら、高性能なＩ／Ｏデバイス仮想化を実現する。いくつかの実施形態では、デバイスエミュレーションと直接デバイス割り当てとを組み合わせた技術により、デバイスモデルに基づいた直接的実行を提供する。いくつかの実施形態によると、シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）に基づいた設計の代替となるものを提供するが、それによると、ＳＲ−ＩＯＶに比べてハードウェアの変更が非常に少ない。いくつかの実施形態によると、最近のデバイス（たとえば、汎用グラフィックスプロセシングユニット（ＧＰＧＰＵ）等の最近のデバイス）の持つより高度なプログラム可能性を活用し、ネイティブ並みのＩ／Ｏ性能をＶＭで提供する。

図１は、いくつかの実施形態に係るシステム１００を示す。いくつかの実施形態では、システム１００は、デバイス１０２および仮想マシンモニタ（ＶＭＭ）１０４を備える。いくつかの実施形態では、システム１００は、仮想マシンＶＭ１ １０６、仮想マシンＶＭ２ １０８、および、たとえばブート時にＶＭＭ１０４により起動される最初のドメインであるＤｏｍ０（ドメインゼロ）１１０を備える。いくつかの実施形態では、デバイス１０２は、Ｉ／Ｏデバイス、グラフィックスプロセシングユニット（ＧＰＵ）、および／または、たとえば、インテル社のララビーグラフィックスプロセシングユニット等の汎用グラフィックスプロセシングユニット（ＧＰＧＰＵ）である。

いくつかの実施形態では、デバイス１０２は、オペレーティングシステム（ＯＳ）１１２（たとえば、マイクロＯＳ（μＯＳ）と呼ばれる完全にＦｒｅｅＢＳＤに基づくＯＳ）を有する。いくつかの実施形態では、ＯＳ１１２は、スケジューラ１１４およびドライバ１１６（たとえば、ホストドライバ）を含む。いくつかの実施形態では、デバイス１０２は、ドライバアプリケーション１１８、ドライバアプリケーション１２０、デバイスカード１２２、メモリマップト入出力（ＭＭＩＯ）レジスタおよびＧＴＴメモリ１２４、グラフィックスアパーチャ１２６、ディスプレイインターフェース１２８、およびディスプレイインターフィース１３０を有する。いくつかの実施形態では、ＶＭＭ１０４は、ＸｅｎＶＭＭおよび／またはオープンソースＶＭＭである。いくつかの実施形態では、ＶＭＭ１０４は、ＥＰＴページテーブルおよびＶＴ−ｄ拡張１３２をセットアップする機能を有する。いくつかの実施形態では、ＶＭ１０６は、アプリケーション１３４（たとえば、ＤＸアプリケーション）、ランタイム１３６（たとえば、ＤＸランタイム）、デバイスＵＭＤ１３８、およびカーネルモードドライバ（ＫＭＤ）１４０（および／または、エミュレートされたデバイス）を有する。いくつかの実施形態では、ＶＭ１０８は、アプリケーション１４４（たとえば、ＤＸアプリケーション）、ランタイム１４６（たとえば、ＤＸランタイム）、デバイスＵＭＤ１４８、およびカーネルモードドライバ（ＫＭＤ）１５０（および／または、エミュレートされたデバイス）を有する。いくつかの実施形態では、ドメインゼロ（Ｄｏｍ０）１１０は、仮想ホスト拡張１５４を含むホストカーネルモードドライバ（ＫＭＤ）１５２を有する。いくつかの実施形態では、Ｄｏｍ０ １１０は、ホステッドＶＭＭ（ｈｏｓｔｅｄ ＶＭＭ）として動作し、かつ、デバイスモデル１５８を含むプロセッサエミュレータＱＥＭＵ ＶＭ１ １５６を有する。いくつかの実施形態では、Ｄｏｍ０ １１０は、ホステッドＶＭＭとして動作し、かつ、デバイスモデル１６４を含むプロセッサエミュレータＱＥＭＵ ＶＭ２ １６２を有する。

いくつかの実施形態によると、Ｉ／Ｏデバイス１０２の仮想化は、ハードウェアを大幅に変更することなく、高性能と、ＶＭ１０６および１０８でデバイス１０２を共有できる機能とが提供されるように行われる。これは、デバイス１０２がＶＭＭ１０４および一つ以上のＶＭ（たとえば、ＶＭ１０６および１０８）を認識できるように、デバイス１０２のハードウェアおよびソフトウェア／ファームウェアを変更することにより実現する。これにより、デバイス１０２は、高性能が実現されるような態様で、多くのＶＭ（１０６および１０８）と直接的にやり取りできるようになる。デバイス１０２は、各ＶＭからのワークロードを切り分けてスケジューリングする役割も有する。しかし、デバイス１０２のハードウェアへの変更を最小限にするためには、この技術では、ＶＭＭ１０４において、物理デバイス１０２と同一のデバイスをエミュレートした従来のデバイスエミュレーションモデルが必要である。ＶＭ１０６および１０８からデバイス１０２への低頻度アクセス（たとえば、デバイスセットアップを実行するためのアクセス）は、デバイスモデル１６４によりトラップかつエミュレートされるが、高頻度アクセス（たとえば、デバイスとのデータの送受信、割り込み等）は、デバイス１０２に直行し、コストの掛かるＶＭＭ１０４の関与が回避される。

いくつかの実施形態では、ＶＭＭ１０４におけるデバイスモデルは、実際の物理デバイス１０２と同一の仮想デバイスとしてＶＭ１０６または１０８に現れ、デバイス資源への低頻度アクセスの全てを処理する。いくつかの実施形態では、このモデルは、高頻度デバイス資源への直接的なＶＭアクセスもセットアップする。いくつかの実施形態では、デバイス１０２が仮想化を認識して、複数のＶＭ１０６および１０８と直接的にやり取りできるように、ＶＭＭコンポーネント１０４がデバイス１０２上に形成される。このコンポーネントは、全ての高頻度ＶＭアクセスを処理し、デバイスの共有を可能にする。

いくつかの実施形態では、シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）設計に比較して、デバイス１０２のハードウェアへの変更が最小限である。デバイス１０２上で実行されるソフトウェアコンポーネントは、ＶＭＭ１０４コンポーネントを含むよう変更され、これにより、ＶＭＭコンポーネントは、高頻度なＶＭアクセスのＶＭＭによる処理をデバイス自体にオフロードする。

いくつかの実施形態によると、デバイス１０２は、非常にスマートなデバイスであり、高度にプログラム可能（いくつかの実施形態では、たとえば、インテル社のララビーＧＰＵ等のＧＰＵ）である。いくつかの実施形態によると、デバイス１０２は、マイクロ−ＯＳまたはμＯＳと呼ばれる完全にＦｒｅｅＢＳＤに基づくＯＳ１１２を実行する。いくつかの実施形態では、デバイスカードは、いくつかの実施形態ではウィンドウズ（登録商標）ビスタＶＭである２つのＶＭ１０６および１０８で共有される。ＶＭ１０６および１０８は、デバイス１０２に直接的に処理を渡し、ネイティブ並みの性能が達成される。

いくつかの実施形態では、ＶＭＭ１０４は、Ｘｅｎ（オープンソースＶＭＭ）を用いて実装される。いくつかの実施形態では、エミュレートされたデバイスをＶＭ１０６および１０８のそれぞれに提供するべく、仮想化デバイスモデルをＸｅｎを用いて書き込む。このモデルは、ＶＭ１０６および１０８に、デバイス１０２のグラフィックスアパーチャ１２６へと直接的にアクセスさせ、ＶＭ１０６および／または１０８がデバイス１０２に直接的に処理を渡すことができるようにする。デバイスモデル１６４がデバイス動作のいくつかの点を制御できるようにするべく、ホストドライバへのデバイス拡張も用いる。ドライバ１１６は、デバイス１０２上のＶＭＭコンポーネントが、仮想化を自覚して、複数のＶＭから処理を直接的に受け取れるようにするべく、いくつかの実施形態にしたがって変更される。ＶＭ１０６または１０８のグラフィックスアプリケーションは、デバイス１０２側のＯＳ１１２アプリケーションを開始させる。次に、ＶＭのアプリケーション１３４または１４４は、対応するデバイスアプリケーション１１８または１２０にワークロードデータを送信して処理（たとえば、レンダリング）させる。ドライバ１１６が変更されているので、ＯＳ１１２は、複数のＶＭ１０６および１０８からアプリケーション１１８および１２０を、それらが、同一のホストからの複数のアプリケーションであるかのように、実行することができるようなる。異なるＶＭからのワークロードを異なるＯＳアプリケーションで実行することにより、これらは切り分けられるようになる。いくつかの実施形態では、ＯＳスケジューラ１１４は、一つのＶＭからのアプリケーションによって別のＶＭからのアプリケーションの資源が枯渇しないように、各ＶＭからのアプリケーションをスケジューリングできるよう変更される。

いくつかの実施形態では、グラフィックスデバイスの仮想化がＶＭＭ１０４に実装される。いくつかの実施形態では、２つのＶＭ１０６および１０８は、単一のデバイスカードを共有し、グラフィックスアパーチャ１２６を介した直接的なアクセスにより、各々のワークロードをデバイス１０２上で直接的に実行させる。ＯＳ１１２のドライバ１１６およびスケジューラ１１４は、複数のＶＭ間（たとえば、アプリケーション１３４および１４４間、および／または、複数のＤＸアプリケーション間）で切り分けてスケジューリングを実行するよういくつかの実施形態にしたがって変更される。

いくつかの実施形態によると、以下のように５つの主要な技術を実装してＩ／Ｏデバイスの仮想化を実行してよい。

１．完全なデバイスエミュレーション 完全なデバイスエミュレーションでは、ＶＭＭは、デバイスモデルを用いてハードウェアデバイスをエミュレートする。ＶＭは、エミュレートされたデバイスを認識して、それへのアクセスを試みる。これらのアクセスは、デバイスモデルによりトラップされ、処理される。ＶＭの要求を実行するには、これらのアクセスのうちいくつかは、ＶＭＭにおける物理デバイスにアクセスする必要がある。モデルによりエミュレートされた仮想デバイスは、システムに存在する物理デバイスから独立していることができる。これは、この技術の大きな利点であり、ＶＭのマイグレーションが簡単になる。しかし、この技術の欠点は、デバイスのエミュレーションには性能のオーバーヘッドが伴い、ネイティブ並みの性能がＶＭで実現されないことである。

２．直接デバイス割り当て この技術では、デバイスは、直接的にＶＭに割り当てられ、デバイスのメモリマップトＩ／Ｏ（ＭＭＩＯ）資源の全てが、ＶＭによって直接的にアクセス可能とされる。これによって、ネイティブのＩ／Ｏ性能がＶＭで実現される。しかし、デバイスをその他のＶＭと共有することができないことが欠点である。さらに、ＶＭのマイグレーションがずっと困難である。

３．ＶＭにおける準仮想化ドライバ このアプローチでは、ＶＭＭドライバとやり取りして共有を可能にする準仮想化ドライバをＶＭ内にロードする。この技術では、仮想デバイスは、物理デバイスから独立していることができ、デバイスモデルに基づくアプローチよりも良好な性能を実現できる。しかし、このアプローチの欠点は、ＶＭ内に新たなドライバが必要であり、デバイス割り当てで実現される性能にはやはり及ばないことである。さらに、仮想デバイスのセマンティクスと物理デバイスのセマンティクスとの間の変換を実装するのが困難であり、フィーチャーコンプリートでない場合が多い（たとえば、グラフィックス仮想化におけるＡＰＩプロキシ）。

４．仲介パススルー（Ｍｅｉｄａｔｅｄ Ｐａｓｓ−Ｔｈｒｏｕｇｈ（ＭＰＴ））または補助ドライバパススルー（Ａｓｓｉｓｔｅｄ Ｄｒｉｖｅｒ Ｐａｓｓ−Ｔｈｒｏｕｇｈ（ＡＤＰＴ）） 最近、ＶＭＭのベンダは、準仮想化ドライバを改良した、ＭＰＴまたはＡＤＰＴと呼ばれる技術を提案しており、この技術では、エミュレートされた仮想デバイスは、物理デバイスと同一である。これにより、ＶＭは、既存のデバイスドライバを（ＶＭがＶＭＭとやり取りできるように多少変更して）使用することができるようになる。また、これにより、ＶＭのワークロードを仮想デバイスのフォーマットから物理デバイスのフォーマットに変換するためのオーバーヘッドが回避される（両方とも同一であるから）。このアプローチの欠点は、ＶＭがデバイスと直接的にやり取りできないので、デバイス割り当てで実現される性能には追いつかないことである。

５．ハードウェアアプローチ（たとえば、ＳＲ−ＩＯＶ） このアプローチでは、デバイスハードウェアを変更して、各ＶＭに一つずつとして、デバイス資源のインスタンスを複数生成する。シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）は、ハードウェアベンダの間で普及している規格であり、これらのデバイスにソフトウェアインターフェースを規定する。デバイス資源（物理的機能またはＰＦ）の複数のインスタンスと複数の仮想機能（またはＶＦ）を生成する。このアプローチの利点は、複数のＶＭ間でデバイスを共有することができ、同時に高性能を実現することができることである。欠点は、デバイスのハードウェアを大幅に変更しなければならないことである。さらなる欠点は、特定数のＶＭをサポートするようデバイス資源が静的に生成されることである（たとえば、４個のＶＭをサポートするようデバイスが構築されており、現在実行されているＶＭが２個しかない場合、残り２個のＶＭ用の資源は未使用のままであり、実行中の２個のＶＭが利用することができない）。

いくつかの実施形態によると、上記の４および５の技術を組み合わせたアプローチを用いて、高性能かつ共有可能なデバイスを実現する。この組み合わせ方法では、５の技術で要求されるハードウェア変更の大半が不要である。また、（５の技術でのように、静的に区画するのではなく、）デバイス資源をＶＭに動的に割り当てることができる。いくつかの実施形態では、ハードウェアおよびデバイス上で実行されるソフトウェアが変更されるので、ＶＭと直接的にやり取りでき、（４の技術と異なり）ネイティブ並みの性能が得られる。４の技術と同じく、いくつかの実施形態では、物理デバイスと同一の仮想デバイスをエミュレートするデバイスモデルを使用する。デバイスモデルを使用し、かつデバイスソフトウェア／ファームウェアに変更を加えることで、５の技術で必要とされるハードウェア変更の大半が不要になる。２の技術と同じく、いくつかの実施形態では、デバイス資源のいくつかをＶＭに直接的にマッピングして、ＶＭがデバイスと直接的にやり取りできるようにする。しかし、２の技術と異なり、いくつかの実施形態では、デバイスが複数のＶＭ間で共有できるような方法で、デバイス資源をマッピングする。５の技術と同じく、いくつかの実施形態では、高性能を実現するべくデバイスの振る舞いを変更する。しかし、５の技術と異なり、デバイスソフトウェア／ファームウェアを主に変更し、ハードウェアには最低限の変更しかせず、これによりデバイスを低コストに維持し、製品化までに要する時間を短縮する。また、（ハードウェアでなく）デバイスのソフトウェアに変更を加えることで、デバイス資源がＶＭにオンデマンドで動的に割り当てられる。

いくつかの実施形態によると、デバイスのハードウェアを大幅に変更することなく、デバイス共有およびデバイス資源のＶＭへの動的割り当てを可能にして、高性能Ｉ／Ｏ仮想化を実装する。既存の方法では、これらの４つの要素の全てを満たすものはない。いくつかの実施形態では、デバイスソフトウェア／ファームウェアを変更し、ハードウェアも多少変更して、デバイスがＶＭのワークロードを直接的に実行できるようにし、各ＶＭからのワークロードを切り分けてスケジューリングできるようにする。

いくつかの実施形態では、モデルに基づいた直接実行を採用する組み合わせ方法を実装する。いくつかの実施形態では、デバイスのハードウェア資源の複数のインスタンスを形成するのではなく、デバイスソフトウェア／ファームウェアを変更する。これにより、各ＶＭからのワークロードを切り分けてスケジューリングすることができる。

図２は、いくつかの実施形態に係るフロー２００を示す。いくつかの実施形態では、２０２で、ＶＭは、デバイス資源（たとえば、デバイスのＭＭＩＯ資源）へのアクセスを要求する。２０４で、ＭＭＩＯ資源が頻繁にアクセスされる資源であるかを判定する。２０４で頻繁にアクセスされる資源でないと判定されると、２０６で、要求はＶＭＭデバイスモデルにトラップされ、エミュレートされる。次に、２０８で、ＶＭＭデバイスモデルは、切り分けおよびスケジューリングを行う。２１０で、ＶＭＭデバイスモデルは、デバイス資源２１２にアクセスする。２０４で頻繁にアクセスされる資源であると判定されると、２１４で、ＶＭはデバイスへの直接アクセス経路を使用する。２１６で、デバイス上のＶＭＭコンポーネントは、ＶＭの直接アクセスを受け入れる。次に、２１８で、ＶＭＭコンポーネントは、これらのアクセスを適切に切り分けてスケジューリングする。２２０で、ＶＭＭコンポーネントは、デバイス資源２１２にアクセスする。

近年のデバイスはプログラム可能性が増大し、デバイス機能のかなりの部分がデバイスで実行されるソフトウェア／ファームウェアにより実装される。いくつかの実施形態では、デバイスハードウェアの変更が最小限であるか、全く必要でない。したがって、いくつかの実施形態によると、Ｉ／Ｏデバイス等のデバイスの変更は、（たとえば、ＳＲ−ＩＯＶを用いるハードウェア的アプローチに比べて）、ずっと速い。いくつかの実施形態では、Ｉ／Ｏデバイス等のデバイスは、ほぼ時間をかけずに仮想化することができる。いくつかの実施形態にしたがってデバイスソフトウェア／ファームウェアを変更して、高性能Ｉ／Ｏ仮想化を提供してよい。

いくつかの実施形態では、単一のＩ／Ｏメモリ管理ユニット（ＩＯＭＭＵ）テーブルを用いて複数の要求者ＩＤをエミュレートしてよい。

図３は、いくつかの実施形態に係るシステム３００を示す。いくつかの実施形態では、システム３００は、デバイス３０２（たとえば、Ｉ／Ｏデバイス）を備える。デバイス３０２は、デバイス上に、ＶＭＭコンポーネントと、第１ＶＭワークロード３０６および第２ＶＭワークロード３０８とを有する。システム３００は、第１ＶＭ ＩＯＭＭＵテーブル３１２および第２ＶＭ ＩＯＭＭＵテーブル３１４を有する合併ＩＯＭＭＵテーブル３１０をさらに備える。システム３００は、第１ＶＭメモリ３２２および第２ＶＭメモリ３２４を有するホストメモリ３２０をさらに備える。

デバイス３０２上のＶＭＭコンポーネント３０４は、ゲスト物理アドレス（ＧＰＡ）を、ワークロードが使用する前にタグする。ワークロード３０６は、ＩＯＭＭＵテーブルｉｄにタグされたＧＰＡ１を使用してＶＭ１ ＩＯＭＭＵテーブル３１２にアクセスし、ワークロード３０８は、ＩＯＭＭＵテーブルｉｄにタグされたＧＰＡ２を使用してＶＭ２ ＩＯＭＭＵテーブル３１２にアクセスする。

図３は、高性能Ｉ／Ｏを実現するべく各ＶＭがデバイス３０２（たとえば、Ｉ／Ｏデバイス）に直接アクセスできる場合に、複数のＶＭで単一のデバイスを共有する課題に関する。ＶＭは、デバイスに直接的にアクセスしているので、ゲスト物理アドレス（ＧＰＡ）をデバイスに供給する。デバイス３０２は、メモリがアドレスを用いてアクセスされる前にＶＭのＧＰＡをホスト物理アドレス（ＨＰＡ）に変換するＩＯＭＭＵテーブル３１０を使用することにより、ＶＭメモリ３２２および／または３２４にアクセスする。現在、各デバイス機能は、要求者ＩＤと呼ばれる識別子を使用することにより単一のＩＯＭＭＵテーブルを使用することができる（全てのデバイス機能が要求者ＩＤを持つ）。しかし、ＶＭごとにそれぞれ異なるＩＯＭＭＵテーブルが、そのＶＭの各ＧＰＡをＨＰＡにマッピングするべく必要である。したがって、デバイス機能は、一度に一つのＩＯＭＭＵテーブルにしかアクセスすることができないので、複数のＶＭで機能を直接的に共有することはできない。

図３のシステム３００は、一つのデバイス機能に複数の要求者ＩＤをエミュレートして、デバイス機能が同時に複数のＩＯＭＭＵテーブルにアクセスできるようにすることにより、上記の問題を解決する。複数のＩＯＭＭＵテーブルにアクセスを有することにより、デバイス機能は、複数のＶＭのメモリに同時にアクセスでき、これらのＶＭにより共有されることができる。

複数のＩＯＭＭＵテーブル３１２および３１４は、単一のＩＯＭＭＵテーブル３１０に合併され、デバイス機能はこの合併ＩＯＭＭＵテーブルを使用する。ＩＯＭＭＵテーブル３１２および３１４は、ＩＯＭＭＵテーブルＩＤがＧＰＡの高位ビットで表されるようにして合併ＩＯＭＭＵテーブル３１０内で各テーブルのマッピングを異なるオフセットで配置することによって合併される。たとえば、各ＩＯＭＭＵテーブル３１２および３１４が３９ビットアドレス（これは、ゲストメモリの５１２ＧＢをマッピングすることができる）をマッピングし、合併ＩＯＭＭＵテーブル３１０が４８ビットアドレスをマップすることができる仮定すると、合併ＩＯＭＭＵテーブルを生成し、第１ＩＯＭＭＵテーブルをオフセット０で設け、第２ＩＯＭＭＵテーブルを５１２ＧＢのオフセットで設け、第３ＩＯＭＭＵテーブルを１ＴＢのオフセットで設け、以下同様となる。効果的に、高位ビット３９〜４７が、合併ＩＯＭＭＵテーブル３１０での各ＩＯＭＭＵテーブルナンバーの識別子となる。

この合併テーブルで動作するには、各ＩＯＭＭＵテーブル宛のＧＰＡを補正する。たとえば、第２ＩＯＭＭＵテーブルのＧＰＡ ０は、合併ＩＯＭＭＵテーブルではＧＰＡ ５１２ＧＢに現れる。したがって、デバイスが使用しているアドレス（ＧＰＡ）を修正して、ＩＯＭＭＵのＧＰＡの補正を反映するようにし、合併ＩＯＭＭＵテーブルの正確な部分が用いられるようにすることが必要となる。基本的に、デバイスがＧＰＡにアクセスする前に、ＧＰＡの高位ビットをＩＯＭＭＵテーブルナンバーにタグする。いくつかの実施形態では、デバイスで実行されるソフトウェア／ファームウェアを、このタグを行うように変更する。

いくつかの実施形態では、システム３００は、２つの重要なコンポーネントを備える。ＶＭＭコンポーネント３０４は合併ＩＯＭＭＵテーブル３１０を生成し、デバイス機能にこのＩＯＭＭＵテーブルを使用させる。追加的なデバイスコンポーネントは、ＶＭからＧＰＡを受け取り、ＧＰＡの送り元のＶＭに対応するＩＯＭＭＵテーブルナンバーにＧＰＡをタグする。これにより、デバイスは、そのＶＭのＩＯＭＭＵテーブル（今となっては、合併ＩＯＭＭＵテーブルの一部である）のマッピングを正確に使用することができるようになる。デバイスによるＧＰＡのタグと合併ＩＯＭＭＵテーブルの生成とが組み合わさることで、単一の要求者ＩＤを使用して複数の要求者ＩＤがエミュレートされる。

システム３００は、２つのＶＭおよびそれらに対応するＩＯＭＭＵテーブルを備える。これらのＩＯＭＭＵテーブルは、単一の合併ＩＯＭＭＵテーブルに異なるオフセットで組み入れられており、これらのオフセットは、デバイス上の対応するＶＭのワークロードによって使用されるＧＰＡにタグされている。これにより、本質的に、単一のＩＯＭＭＵテーブルを使用して複数のＲＩＤがエミュレートされる。図３では、ＶＭのメモリをホストメモリにおける連続的なブロックとして示しているが、ＶＭのメモリは、実際には、ホストメモリ内で分散された不連続のページであってよい。ＩＯＭＭＵテーブルは、各ＶＭの連続的なＧＰＡ範囲から、ホストメモリの不連続の物理ページにマッピングする。

いくつかの実施形態では、デバイス３０２はＧＰＵである。いくつかの実施形態では、デバイス３０２は、インテル社のララビーＧＰＵである。本明細書で記載するララビーＧＰＵ等のＧＰＵは、非常にスマートなデバイスであり、高度にプログラム可能である。いくつかの実施形態では、このデバイスは、本明細書に記載のマイクロＯＳまたはμＯＳと呼ばれる完全にＦｒｅｅＢＳＤに基づいたＯＳを実行する。このため、このデバイスはこの技術にとって理想的な候補である。いくつかの実施形態では、単一のデバイスカード（たとえば、単一のララビーカード）を２つのウィンドウズ（登録商標）ビスタＶＭで共有する。ＶＭは、デバイスに処理を直接的に渡すので、ネイティブ並みの性能が実現される。いくつかの実施形態では、ＸｅｎＶＭＭ等のオープンソースＶＭＭを使用する。いくつかの実施形態では、合併ＩＯＭＭＵテーブル３１０を生成するようＶＭＭ（および／またはＸｅｎＶＭＭ）を変更する。いくつかの実施形態では、デバイスＯＳドライバが、デバイスアプリケーションのページテーブルをセットアップするとき、ＶＭが使用するＩＯＭＭＵテーブルのナンバーにＧＰＡをタグするように、デバイスＯＳドライバを変更する。デバイスＯＳドライバは、ホストメモリとローカルメモリとでＤＭＡを行う必要がある場合も、ＧＰＡをタグする。これにより、ＧＰＡへの全てのアクセスが、合併ＩＯＭＭＵテーブルを使用して正確なＨＰＡにマッピングされるようになる。

既存のデバイス（たとえば、ＳＲ−ＩＯＶデバイス）は、デバイス内に複数のデバイス機能を実装しており、複数の要求者ＩＤ（ＲＩＤ）が生成される。複数のＲＩＤがあることで、デバイスは、同時に複数のＩＯＭＭＵテーブルを使用することができるようになる。しかし、これには、デバイスハードウェアの大幅な変更が必要であり、デバイスのコストおよび製品化までに要する時間が増大する。

いくつかの実施形態では、ＶＭＭデバイスモデル内で、アドレス変換を実行する。ＶＭは、ワークバッファをデバイスに渡すとき、ＶＭＭにトラップを生成し、ＶＭＭは、ＶＭのワークバッファをデバイスに渡す前に、ワークバッファを構文解析してＧＰＡを探し出し、ＧＰＡをＨＰＡに変換する。ＶＭＭでのトラップ生成およびワークバッファの構文解析が頻繁であるので、この技術には、非常に大きい仮想化オーバーヘッドが伴う。

いくつかの実施形態では、デバイスが一つの要求者ＩＤを使用して複数のＩＯＭＭＵテーブルを使用できるようにするべく、（複数のデバイス機能を生成する代わりに）デバイスソフトウェア／ファームウェアに必要とされる変更がわずかである。ＶＭＭ３０４は、デバイス３０２を共有する全てのＶＭのＩＯＭＭＵテーブルを含む合併ＩＯＭＭＵテーブル３１０を生成する。デバイスは、各ＧＰＡにアクセスする前に、そのＧＰＡを対応するＩＯＭＭＵテーブルのナンバーにタグする。これにより、デバイスのコストと製品化に要する時間が減少する。

既存の方法では、複数のＩＯＭＭＵテーブルに同時にアクセスするべく、最近のＩ／Ｏデバイス（たとえば、インテル社のララビーＧＰＵ）のプログラム可能性を利用していない。その代わりに、ハードウェアを変更することによって、複数のデバイス機能を実装し、同時に複数のＩＯＭＭＵテーブルにアクセスできるようにしている。

いくつかの実施形態では、合併ＩＯＭＭＵテーブル（複数のＩＯＭＭＵテーブルのマッピングを含む）を使用し、ＧＰＡをＩＯＭＭＵテーブルナンバーにタグするようデバイスソフトウェア／ファームウェアを変更する。

図４は、いくつかの実施形態に係るシステム４００を示す。いくつかの実施形態では、システム４００は、デバイス４０２（たとえば、Ｉ／Ｏデバイス）、ＶＭＭ４０４、サービスＶＭ４０６、およびＶＭ１ ４０８を備える。サービスＶＭ４０６は、デバイスモデル４１２、ホストデバイスドライバ４１４、およびメモリページ４１６（ＭＭＩＯページとしてマッピングによりパススルーされる）を有する。ＶＭ１ ４０８は、デバイスドライバ４２２を有する。

図４は、デバイス仮想化でのＶＭＭにおけるトラップを減らすためのメモリ支援レジスタ（ｍｅｍｏｒｙ ｂａｃｋｅｄ ｒｅｇｉｓｔｅｒ）（たとえば、ＭＭＩＯレジスタ）の使用を示す。ＶＭＭ４０４は、いくつかの実施形態に係るデバイスモデル４１２を使用してＶＭ１ ４０８を実行し、Ｉ／Ｏデバイス４０２を仮想化する。デバイスモデル４１２は、メモリページを確保し、このメモリページに、ＶＭのＩ／ＯデバイスのＭＭＩＯページをマッピングしてパススルーする。デバイスの適格なレジスタ（ｅｌｉｇｉｂｌｅ ｒｅｇｉｓｔｅｒｓ）がこのページに属している。デバイスモデル４１２およびＶＭのデバイスドライバ４２２は、両方とも、このページにアクセスすることにより、この適格なレジスタに直接的にアクセスすることができる。不適格なレジスタ（ｉｎｅｌｉｇｉｂｌｅ ｒｅｇｉｓｔｅｒｓ）へのアクセスは、相変わらずＶＭＭ４０４にトラップされ、デバイスモデル４１２によりエミュレートされる。

完全なデバイスエミュレーションを用いたＩ／Ｏデバイスの仮想化では、ＶＭのためにハードウェアデバイスをエミュレートするソフトウェアデバイスモデルがＶＭＭに必要である。エミュレートされるハードウェアデバイスは、市販のオペレーティングシステムに存在するデバイスドライバを活用するべく、既存の物理デバイスに基づいたものであることが多い。ＶＭ４０８は、ＶＭＭデバイスモデル４１２によってエミュレートされたハードウェアデバイスを認識し、それへとアクセスするには、そのＰＣＩ、Ｉ／Ｏ、およびＭＭＩＯ（メモリマップトＩ／Ｏ）空間を物理デバイスと見て、そこに読み出し・書き込みを行う。これらのアクセスは、ＶＭＭ４０４にトラップされ、デバイスモデル４１２に転送され、デバイスモデルで適切にエミュレートされる。多くの最近のＩ／Ｏデバイスのレジスタは、デバイスのＰＣＩ ＭＭＩＯ ＢＡＲｓ（ベースアドレスレジスタ）によって設定される範囲に、メモリマップトＩ／Ｏにより現れる。しかし、ＶＭアクセスの全てをデバイスのＭＭＩＯレジスタにトラップすることによるオーバーヘッドは大きく、仮想化デバイスの性能を大幅に低下させる。エミュレートされたデバイスのＭＭＩＯレジスタのいくつかは、ＶＭによる読み出し／書き込み時に、レジスタの値を返すことおよびレジスタに値を書き込むこと以外には、デバイスモデルによる処理を必要としない。これらのレジスタ（以下、適格レジスタ（ｅｌｉｇｉｂｌｅ ｒｅｇｉｓｔｅｒｓ）と呼ぶ）へのアクセスにおいては、実行するべき処理がないので、ＶＭＭ４０４は、このアクセスを必ずしもトラップする必要はない。しかし、既存のＶＭＭは、適格レジスタへのアクセスをトラップしており、デバイス仮想化を行うに際しての仮想化オーバーヘッドを不必要に増大させている。ＶＭ４０８が頻繁に適格レジスタにアクセスするのであれば、このオーバーヘッドは、一層重大なものとなる。

システム４００は、適格レジスタをメモリで支援することにより、ＭＭＩＯレジスタへのアクセスによって発生するＶＭＭトラップの数を減少させる。ＶＭＭのデバイスモデル４１２は、適格レジスタにメモリページを割り当て、これらのページをＲＯ（読み出し専用適格レジスタ）またはＲＷ（読み出し／書き込み適格レジスタ）としてＶＭにマッピングする。ＶＭ４０８が適格レジスタに適格アクセスを実行するとき、このアクセスは、ＶＭＭ４０４にトラップされることなく、メモリに対して実行される。デバイスモデル４１２は、メモリページを、デバイスのＭＭＩＯ空間における仮想レジスタの位置として使用する。デバイスモデル４１２は、メモリに適切な値を入れ、および／または、ＶＭ４０８が書き込んだ値を読み出すことにより、これらのレジスタを非同期的にエミュレートする。ＶＭＭとラップの数を減らすことにより、デバイス仮想化性能が向上する。

適格レジスタは、（レジスタのセマンティクスにしたがって、読み出し専用または読み出し／書き込み用として、）通常のメモリ仮想化技術（シャドウページテーブルまたは拡張ページテーブル（ＥＰＴ））を用いて、ＶＭのアドレス空間にマッピングされてパススルーされる。しかし、ＭＭＩＯアドレスは、ページサイズの粒度でしか、ＶＭにマッピングすることができないので、これらのレジスタをマッピングしてパススルーすると、そのページのレジスタが一つおきにＶＭ４０８にマッピングされパススルーされる。したがって、ＶＭＭ４０４は、適格デバイスレジスタを、同一ページに不適格レジスタが属していない場合にだけ、ＶＭ４０８にマッピングパススルーすることができる。したがって、いくつかの実施形態では、適格レジスタと同一ページに不適格レジスタが属さないように、デバイスのＭＭＩＯレジスタ配置を設計する。さらに、適格レジスタは、読み出し専用パススルーレジスタと読み出し／書き込み用パススルーレジスタとに分類されるが、これら２種類の適格レジスタは、別々のＭＭＩＯページに所属させる必要がある。ＶＭが準仮想化ドライバを使用する場合、ＶＭは、ハードウェアデバイスに頼る必要がなくなるように、デバイスにとって仮想化に好都合なＭＭＩＯ配置を生成することができる。

既存のＶＭＭは、適格デバイスレジスタのＶＭへのマッピングパススルーを行っておらず、これらのレジスタへのアクセスをトラップすることにより不必要な仮想化オーバーヘッドを生じさせている。その理由の一つは、適格レジスタが不適格レジスタと同一のＭＭＩＯページに位置していることであるかもしれない。既存のＶＭＭは、ＶＭ内で準仮想化ドライバを使用してＶＭＭトラップを減少させている。これらの準仮想化ドライバは、（たとえば、レジスタがＶＭでは意味を成さない値を有する場合）これらのレジスタへのアクセスは不要であるとして回避し、または、（たとえば、デバイスをプログラムするべく一連なりのレジスタに書き込むべく）レジスタへのアクセスを一括処理する。

システム４００は、Ｉ／Ｏデバイス仮想化におけるＶＭＭトラップの数をさらに減らすべく新しい技術を用い、デバイス仮想化性能を大幅に向上させる。システム４００は、ＶＭのデバイスにメモリ支援適格レジスタを使用し、これらのメモリページをＶＭにマッピングして、仮想デバイスにアクセスする際のＶＭＭトラップの数を減少させる。

既存のＶＭＭデバイスモデルは、適格デバイスレジスタのＶＭへのマッピングパススルーを行っておらず、アクセスをトラップすることにより不必要な仮想化オーバーヘッドを生じさせている。これにより、デバイス仮想化において、必要以上のＶＭＭトラップが発生している。

いくつかの実施形態によると、適格ＭＭＩＯレジスタをメモリで支援して、メモリページをＶＭにパススルーするべくマッピングし、ＶＭトラップを減少させる。

図５は、いくつかの実施形態に係るシステム５００を示す。いくつかの実施形態では、システム５００は、デバイス５０２（たとえば、Ｉ／Ｏデバイス）、ＶＭＭ５０４、サービスＶＭ５０６、およびＶＭ５０８を備える。サービスＶＭ５０６は、デバイスモデル５１２、ホストデバイスドライバ５１４、および割り込みステータスレジスタを含むメモリページ５１６を有する。ＶＭ５０８は、デバイスドライバ５２２を有する。デバイス５０２では、ワークロード完了５３２時、デバイス５０２は、５３４で、割り込みステータスレジスタ（たとえば、メモリページ５１６の割り込みステータスレジスタ）の位置を受信し、割り込みを生成する前に、これらのレジスタを更新する。

システム５００は、ＶＭ５０８への直接割り込み注入を示す。ＶＭＭ５０４は、デバイスモデル５１２を用いて、ＶＭ５０８を実行し、そのＩ／Ｏデバイス５０２を仮想化する。デバイスモデルは、割り込みステータスレジスタを含むメモリページ５１６を割り当て、そのアドレスを物理Ｉ／Ｏデバイスに通知する。デバイスモデル５１２は、読み出し専用メモリページをＶＭ５０８にマッピングしてパススルーする。Ｉ／Ｏデバイス５０２は、ＶＭのワークロードを完了した後、メモリページ５１６の割り込みステータスレジスタを更新して、割り込みを生成する。デバイス割り込みを受信すると、プロセッサは、割り込みをＶＭ５０８に直接的に注入する。これにより、ＶＭのデバイスドライバ５２２は、割り込みステータスレジスタを（ＶＭＭトラップを生成することなく）読み出す。デバイスドライバ５２２が、（割り込みをアクナレッジするべく）これらのレジスタに書き込むときには、ＶＭＭトラップを生成し、デバイスモデル５１２がそれを処理する。

本明細書で議論したように、ＶＭＭは、Ｉ／Ｏデバイス仮想化を提供して、ＶＭが物理Ｉ／Ｏデバイスを使用できるようにする。多くのＶＭＭは、デバイスモデルを用いて複数のＶＭが一つの物理デバイスを使用できるようにする。Ｉ／Ｏ仮想化オーバーヘッドは、全仮想化オーバーヘッドの最も大きい部分を占める。Ｉ／Ｏ仮想化オーバーヘッドの多くは、ＶＭのデバイス割り込みを処理する際のオーバーヘッドである。物理デバイスは、ＶＭからの要求を処理し終わると、割り込みを生成し、その割り込みは、ＶＭＭのデバイスモデルによりトラップされ処理される。デバイスモデルは、仮想割り込みステータスレジスタをセットアップし、割り込みをＶＭに注入する。ＶＭへの割り込み注入は非常に重い動作であると考えられている。割り込み注入には、ＶＭをスケジューリングし、ＶＭを実行するべく選択されたプロセッサにＩＰＩを送信する必要がある。これにより、仮想化オーバーヘッドが大幅に増大する。ＶＭは、割り込みを受信すると、割り込みステータスレジスタを読み出す。これにより、ＶＭＭのデバイスモデルにさらなるトラップが生成され、これによりレジスタの値が返される。

割り込み処理の待ち時間を短縮するべく、ハードウェア特性（仮想割り込み受け渡し（ｖｉｒｔｕａｌ ｉｎｔｅｒｒｕｐｔ ｄｅｌｉｖｅｒｙ）およびポステッド割り込み（ｐｏｓｔｅｄ ｉｎｔｅｒｒｕｐｔｓ）と呼ばれる）を用いて、ＶＭＭを関与させることなく、直接的に割り込みをＶＭに注入してよい。これらのハードウェア特性によって、デバイスは直接的にＶＭに割り込むことができる。直接割り込み注入は、直接デバイス割り当ておよびＳＲ−ＩＯＶには功を奏するが、デバイスモデルに基づく仮想化方法には有用でない。なぜなら、ＶＭのデバイスの割り込みステータスは、デバイスモデルにより管理され、デバイスモデルには、割り込みを通知して、デバイスモデルが割り込みステータスを更新できるようにしなければならないからである。

システム５００は、デバイスモデルに基づく仮想化方法において、ＶＭへの直接割り込み注入を可能にする。ＶＭＭのデバイスモデルは、直接割り込み注入時に通知を受けないので、デバイス自体が、割り込みを生成する前に、デバイスモデルの割り込みステータスレジスタを更新する。デバイスモデルは、ＶＭのデバイスの割り込みステータスにメモリを割り当て、そのメモリ位置をデバイスに知らせる。デバイス（ハードウェア、または、デバイスで実行されるソフトウェア／ファームウェア）は、割り込みステータスレジスタの位置をデバイスモデルから受信し、割り込みを生成する前に当該位置を適切に更新するように変更される。デバイスモデルは、割り込みステータスレジスタをＶＭアドレス空間にマッピングして、ＶＭのデバイスドライバがＶＭＭトラップを生成することなく割り込みステータスレジスタにアクセスできるようにする。多くのデバイスの割り込みステータスレジスタは、１を書き込むことによりクリアされる、Ｗ１Ｃというセマンティクス（レジスタのビットに１を書き込むと、そのビットはクリアされる）を有する。ＲＡＭメモリは、Ｗ１Ｃセマンティクスをエミュレートできないので、これらのレジスタは、読み出し／書き込み用にＶＭにマッピングすることはできない。これらの割り込みステータスレジスタは、読み出し専用にＶＭにマッピングすることはできるので、ＶＭは、ＶＭＭトラップを生成することなく割り込みステータスレジスタを読み出すことができるが、ＶＭが（たとえば、割り込みをアクナレッジするべく）割り込みステータスレジスタに書き込む際には、ＶＭＭがこのアクセスをトラップして、デバイスモデルがＷ１Ｃセマンティクスをエミュレートする。したがって、システム５００のいくつかの実施形態は、２つの重要なコンポーネントを用いる。

いくつかの実施形態に係るシステム５００の第一の重要なコンポーネントは、割り込みステータスレジスタにメモリを割り当て、これらのレジスタの位置をデバイスに通知し、当該メモリをＶＭ５０８のＭＭＩＯ空間にマッピングするＶＭＭデバイスモデル５１２である。

いくつかの実施形態に係るシステム５００の第二の重要なコンポーネントは、デバイスモデル５１２から割り込みステータスレジスタの位置を受信し、ＶＭ５０８に割り込みを生成する前に、これらのレジスタを適切に更新するデバイス駐在コンポーネント（ｄｅｖｉｃｅ ｒｅｓｉｄｅｎｔ ｃｏｍｐｏｎｅｎｔ）５３２である。

いくつかの実施形態によると、直接割り込み注入をサポートするハードウェア（たとえば、インテル社のプロセッサ用の仮想割り込み受け渡しおよびポステッド割り込みと呼ばれるＡＰＩＣ特性）を用いる。

いくつかの実施形態では、ＶＭＭデバイスモデル５１２は、割り込みステータスレジスタを更新する役割をデバイス自体にオフロードし、ＶＭへの割り込み注入に関与する必要がない。既存の方法では、デバイス割り込みが発生すると、デバイスモデルが割り込みステータスレジスタを更新し、割り込みをＶＭに注入する。図５のシステム５００では、デバイスが、ＶＭの割り込みステータスレジスタ（これらのレジスタにデバイスモデルにより前もって割り当てられたメモリ）を更新し、ＶＭに直接的に注入される割り込みを生成する。さらに、デバイスモデル５１２が、割り込みステータスレジスタをＶＭにマッピングし、ＶＭのデバイスドライバがこれらのレジスタにアクセスする際のＶＭＭトラップを回避する。

既存の方法では、割り込みステータスレジスタは、デバイス自体に存在する。デバイスは、メモリ内の割り込みステータスレジスタを更新する役割を持たない。また、既存のデバイスモデルも、ＶＭのデバイスドライバがこれらのレジスタにアクセスする際のＶＭＭトラップを回避するためのＶＭへのこれらのレジスタのマッピングを行わない。

いくつかの実施形態によると、物理Ｉ／Ｏデバイスが、メモリ内のデバイスモデルの割り込みステータスレジスタを更新し、割り込みを直接的にＶＭに注入できるようにする。

本明細書では、いくつかの実施形態は、特定の方法で実装されると記載したが、いくつかの実施形態によると、これらの特定の実装例は必須ではない。

いくつかの実施形態を特定の実装例を参照して記載したが、いくつかの実施形態によると、その他の実装例が可能である。さらに、図示および／または記載した回路要素またはその他の特性の配置および／または順序は、図示および記載した特定の態様で配置する必要はない。いくつかの実施形態によると、その他多くの配置が可能である。

図に示した各システムにおいて、いくつかの場合における各要素は、同じ参照番号または異なる参照番号を有しており、図示された各要素が類似したものであるか、および／または、異なるものであるかを示唆する。しかし、要素は、多様に実装しうる柔軟性を持ち、本明細書に図示または記載したシステムのいくつかまたは全てにおいて動作しうる。図示した多様な要素は、同一または異なってよい。要素のいずれを第１と呼び、いずれを第２とするかは、任意である。

記載および特許請求の範囲において、「結合された（ｃｏｕｐｌｅｄ）」および「接続された（ｃｏｎｎｅｃｔｅｄ）」という用語並びにこれらの活用形を使用する場合がある。これらの用語は、互いに同義語と意図されているのではないことは理解されるべきである。むしろ、特定の実施形態では、２つ以上の要素が互いに直接的に、物理的または電気的に接触していることを示すべく「接続された」という用語が使用される。「結合された」という用語は、２つ以上の要素が直接的に、物理的または電気的に接触していることを意味する。しかし、「結合された」という用語は、２つ以上の要素が互いに直接的に接触していないが、それでも互いに協働またはやり取りする場合のことも意味する。

アルゴリズムは、本明細書において、また、一般的に、所望の結果を導出する動作または処理の一貫したシーケンスであると考えられる。これには、物理量の物理的操作が含まれる。通常、必ずではないが、これらの量は、記憶、転送、組み合わせ、比較、またはその他の操作が可能な電気的または磁気的な信号という形態を有する。時として、このような信号を、ビット、値、要素、記号、文字、条件（ｔｅｒｍｓ）、数字等として参照することが、一般的によく使用されているという理由で、便利であることが分かっている。しかし、これらおよび類似の用語の全ては、適切な物理量に対応付けられるのであり、これらの量に適用された便宜的な呼称にすぎないことは理解されるべきである。

いくつかの実施形態は、ハードウェア、ファームウェア、およびソフトウェアのいずれかまたは組み合わせで実施してよい。いくつかの実施形態は、本明細書に記載の処理を実行するべくコンピューティングプラットフォームによって読み出されて実行される機械可読媒体に格納された命令として実施してもよい。機械可読媒体は、機械（たとえば、コンピュータ）によって読み出し可能な形態で情報を記憶または送信する任意のメカニズムであってよい。たとえば、機械可読媒体は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電気、光、音、またはその他の形態で伝搬される信号（たとえば、搬送波、赤外線信号、デジタル信号、信号を送信および／または受信するインターフェース等）、およびその他であってよい。

実施形態は、発明の実施例または例である。明細書において「ある実施形態」、「一実施形態」、「いくつかの実施形態」、または「その他の実施形態」と言及する場合、その実施形態に関連して記載される特定の特性、構造、または特徴が、本発明の少なくともいくつかの実施形態に含まれるが、必ずしも全ての実施形態に含まれるのではないことを示す。「ある実施形態」、「一実施形態」、または「いくつかの実施形態」等と多様に表現される場合、必ずしも全てが同一の実施形態を指すのではない。

本明細書に記載および図示したコンポーネント、特性、構造、特徴等の全てを特定の実施形態または複数の実施形態に含める必要はない。明細書において、コンポーネント、特性、構造、または特徴を、含めうる、含めてよい、含めることができる等と記載される場合、たとえば、その特定のコンポーネント、特性、構造、または特徴を含める必要はない。明細書または特許請求の範囲において、「一つの（ａ）」または「一つの（ａｎ）」要素と述べる場合、その要素が一つしかないことを意味するのではない。明細書または特許請求の範囲において、「さらなる」要素と述べる場合、当該さらなる要素が２つ以上ある場合を除外しない。

本明細書で実施形態を記載するべくフロー図および／または状態図を使用したが、本発明は、これらの図または本明細書における対応する記載に限定されない。たとえば、フローは、図示された各ボックスまたは状態を通過または遷移する必要がなく、本明細書に図示および記載した順序と全く同じ順序で通過または遷移する必要がない。

本発明は、本明細書に挙げた特定の詳細に限定されない。事実、上記の記載および図面の多様な変形が本発明の範囲内で可能であることは、本開示から利益を受ける当業者には理解されよう。したがって、以下の特許請求の範囲、およびそれに対する修正があればそれらによって、本発明の範囲が規定される。

Claims (18)

1. 仮想マシンモニタを実行する装置で行われる方法であって、
   前記装置が、仮想マシンのワークロードをデバイスが直接的に実行できるようにする段階と、
   前記装置が、複数の異なる仮想マシンからのワークロードを切り分けてスケジューリングする段階と、
   前記装置が、前記装置に形成される割り込みステータスレジスタの位置を、デバイスに通知するとともに仮想マシンのメモリマップト入出力空間にマッピングする段階と、
   デバイスが、仮想マシンへの割り込みを生成する前に、前記割り込みステータスレジスタを更新する段階と
   を備える方法。
2. 前記装置が、複数の異なる仮想マシンからのワークロードを切り分けてスケジューリングすることができるようにデバイスのソフトウェアおよび／またはファームウェアを変更することで、前記実行できるようにする段階を行う請求項１に記載の方法。
3. 前記装置が、入出力仮想化を提供することで、前記実行できるようにする段階を行う請求項１または２に記載の方法。
4. 前記装置が、複数の仮想マシンによるデバイスの共有を可能にすることで、前記実行できるようにする段階を行う請求項１から３のいずれか１項に記載の方法。
5. 前記装置が、デバイス資源を仮想マシンに動的に割り当てることで、前記実行できるようにする段階を行う請求項１から４のいずれか１項に記載の方法。
6. 前記装置が、予め定められた頻度よりも高い頻度でデバイス資源がアクセスされる場合、前記実行できるようにする段階の後に、前記スケジューリングする段階を行う代わりに、このデバイス資源に関して仮想化されているデバイスへの経路に仮想マシンを直接的にアクセスさせる段階をさらに備える請求項１から５のいずれか１項に記載の方法。
7. 前記装置が、予め定められた頻度よりも高い頻度でデバイス資源がアクセスされない場合、このデバイス資源に対するワークロードの切り分けおよびスケジューリングを行うことで、前記スケジューリングする段階を行う請求項１から６のいずれか１項に記載の方法。
8. 前記装置が、前記実行できるようにする段階と、前記スケジューリングする段階との間に、複数の異なる仮想マシンからのアクセス要求をトラップおよびエミュレートする段階をさらに備える請求項１から７のいずれか１項に記載の方法。
9. 前記装置が、予め定められた頻度よりも高い頻度でデバイス資源がアクセスされない場合、前記スケジューリングする段階と前記通知する段階との間に、このデバイス資源に関する仮想マシンデバイスモデルを使用してデバイス資源にアクセスする段階をさらに備える請求項１から８のいずれか１項に記載の方法。
10. 仮想マシンモニタを実行する装置であって、
    デバイスが仮想マシンのワークロードを直接的に実行できるようにする手段と、
    複数の異なる仮想マシンからのワークロードを切り分けてスケジューリングする手段と、
    前記装置に形成される割り込みステータスレジスタの位置を、デバイスに通知するとともに仮想マシンのメモリマップト入出力空間にマッピングする手段と
    を備え、
    前記割り込みステータスレジスタは、デバイスが仮想マシンへの割り込みを生成する前に、このデバイスによって更新される装置。
11. 複数の異なる仮想マシンからのワークロードを切り分けてスケジューリングできるようにデバイスのソフトウェアおよび／またはファームウェアを変更する手段を備える請求項１０に記載の装置。
12. 入出力仮想化を提供する手段を備える請求項１０または１１に記載の装置。
13. 複数の仮想マシンによるデバイスの共有を可能にする手段を備える請求項１０から１２のいずれか１項に記載の装置。
14. デバイス資源を仮想マシンに動的に割り当てる手段を備える請求項１０から１３のいずれか１項に記載の装置。
15. 予め定められた頻度よりも高い頻度でデバイス資源がアクセスされる場合、前記スケジューリングする手段が切り分けおよびスケジューリングを行う代わりに、このデバイス資源に関して仮想化されているデバイスへの経路に仮想マシンを直接的にアクセスさせる手段を備える請求項１０から１４のいずれか１項に記載の装置。
16. 前記スケジューリングする手段は、予め定められた頻度よりも高い頻度でデバイス資源がアクセスされない場合、このデバイス資源に対するワークロードの切り分けおよびスケジューリングを行う請求項１０から１５のいずれか１項に記載の装置。
17. 複数の異なる仮想マシンからのアクセス要求を、トラップおよびエミュレートする手段を備える請求項１０から１６のいずれか１項に記載の装置。
18. 予め定められた頻度よりも高い頻度でデバイス資源がアクセスされない場合、このデバイス資源に関する仮想マシンデバイスモデルを使用してデバイス資源にアクセスする手段を備える請求項１０から１７のいずれか１項に記載の装置。

Images