デバイスが仮想マシンのワークロードを直接的に実行できるようにする段階と、複数の仮想マシンからのワークロードを切り分けてスケジューリングする段階とを備える方法。複数の仮想マシンからのワークロードを切り分けてスケジューリングすることができるようにデバイスのソフトウェアおよび/またはファームウェアを変更する段階をさらに備える請求項1に記載の方法。高性能な入出力仮想化を提供する段階をさらに備える請求項1または2に記載の方法。複数の仮想マシンによるデバイスの共有を可能にする段階をさらに備える請求項1から3のいずれか1項に記載の方法。デバイス資源を仮想マシンに動的に割り当てる段階をさらに備える請求項1から4のいずれか1項に記載の方法。仮想化されているデバイスに大幅なハードウェア変更をする必要なしに、デバイス資源を仮想マシンに動的に割り当てる段階をさらに備える請求項1から5のいずれか1項に記載の方法。デバイス資源が頻繁にアクセスされる場合、仮想化されているデバイスへの経路に直接的にアクセスする段階をさらに備える請求項1から6のいずれか1項に記載の方法。頻繁にアクセスされないデバイス資源の切り分けおよびスケジューリングを行う段階をさらに備える請求項1から7のいずれか1項に記載の方法。トラップおよびエミュレートを行う段階をさらに備える請求項1から8のいずれか1項に記載の方法。デバイス資源が頻繁にアクセスされない場合、仮想マシンデバイスモデルを使用してデバイス資源にアクセスする段階をさらに備える請求項1から9のいずれか1項に記載の方法。デバイスが仮想マシンのワークロードを直接的に実行できるようにし、複数の仮想マシンからのワークロードを切り分けてスケジューリングする仮想マシンモニタを備える装置。前記仮想マシンモニタは、複数の仮想マシンからのワークロードを切り分けてスケジューリングできるようにデバイスのソフトウェアおよび/またはファームウェアを変更する請求項11に記載の装置。前記仮想マシンモニタは、高性能な入出力仮想化を提供する請求項11また12に記載の装置。前記仮想マシンモニタは、複数の仮想マシンによるデバイスの共有を可能にする請求項11から13のいずれか1項に記載の装置。前記仮想マシンモニタは、デバイス資源を仮想マシンに動的に割り当てる請求項11から14のいずれか1項に記載の装置。前記仮想マシンモニタは、仮想化されているデバイスに大幅なハードウェア変更をする必要なしに、デバイス資源を仮想マシンに動的に割り当てる請求項11から15のいずれか1項に記載の装置。前記仮想マシンモニタは、デバイス資源が頻繁にアクセスされる場合、仮想化されているデバイスへの経路に直接的にアクセスする請求項11から16のいずれか1項に記載の装置。前記仮想マシンモニタは、頻繁にアクセスされないデバイス資源の切り分けおよびスケジューリングを行う請求項11から17のいずれか1項に記載の装置。前記仮想マシンモニタは、トラップおよびエミュレートを行う請求項11から18のいずれか1項に記載の装置。前記仮想マシンモニタは、デバイス資源が頻繁にアクセスされない場合、仮想マシンデバイスモデルを使用してデバイス資源にアクセスする請求項11から19のいずれか1項に記載の装置。本発明のいくつかの実施形態は、仮想化によるスマートデバイスの直接的共有に関する。いくつかの実施形態では、デバイスは、仮想マシンのワークロードを直接的に実行することが可能である。複数の仮想マシンからのワークロードは、切り分けてスケジューリングされる。いくつかの実施形態では、入出力I/Oデバイスを複数の仮想マシンVM間で共有しながら、高性能なI/Oデバイス仮想化を実現する。いくつかの実施形態では、デバイスエミュレーションと直接デバイス割り当てとを組み合わせた技術により、デバイスモデルに基づいた直接的実行を提供する。いくつかの実施形態によると、シングルルートI/O仮想化SR-IOVに基づいた設計の代替となるものを提供するが、それによると、SR-IOVに比べてハードウェアの変更が非常に少ない。いくつかの実施形態によると、最近のデバイスたとえば、汎用グラフィックスプロセシングユニットGPGPU等の最近のデバイスの持つより高度なプログラム可能性を活用し、ネイティブ並みのI/O性能をVMで提供する。図1は、いくつかの実施形態に係るシステム100を示す。いくつかの実施形態では、システム100は、デバイス102および仮想マシンモニタVMM104を備える。いくつかの実施形態では、システム100は、仮想マシンVM1106、仮想マシンVM2108、および、たとえばブート時にVMM104により起動される最初のドメインであるDom0ドメインゼロ110を備える。いくつかの実施形態では、デバイス102は、I/Oデバイス、グラフィックスプロセシングユニットGPU、および/または、たとえば、インテル社のララビーグラフィックスプロセシングユニット等の汎用グラフィックスプロセシングユニットGPGPUである。いくつかの実施形態では、デバイス102は、オペレーティングシステムOS112たとえば、マイクロOSμOSと呼ばれる完全にFreeBSDに基づくOSを有する。いくつかの実施形態では、OS112は、スケジューラ114およびドライバ116たとえば、ホストドライバを含む。いくつかの実施形態では、デバイス102は、ドライバアプリケーション118、ドライバアプリケーション120、デバイスカード122、メモリマップト入出力MMIOレジスタおよびGTTメモリ124、グラフィックスアパーチャ126、ディスプレイインターフェース128、およびディスプレイインターフィース130を有する。いくつかの実施形態では、VMM104は、XenVMMおよび/またはオープンソースVMMである。いくつかの実施形態では、VMM104は、EPTページテーブルおよびVT-d拡張132をセットアップする機能を有する。いくつかの実施形態では、VM106は、アプリケーション134たとえば、DXアプリケーション、ランタイム136たとえば、DXランタイム、デバイスUMD138、およびカーネルモードドライバKMD140および/または、エミュレートされたデバイスを有する。いくつかの実施形態では、VM108は、アプリケーション144たとえば、DXアプリケーション、ランタイム146たとえば、DXランタイム、デバイスUMD148、およびカーネルモードドライバKMD150および/または、エミュレートされたデバイスを有する。いくつかの実施形態では、ドメインゼロDom0110は、仮想ホスト拡張154を含むホストカーネルモードドライバKMD152を有する。いくつかの実施形態では、Dom0110は、ホステッドVMMhostedVMMとして動作し、かつ、デバイスモデル158を含むプロセッサエミュレータQEMUVM1156を有する。いくつかの実施形態では、Dom0110は、ホステッドVMMとして動作し、かつ、デバイスモデル164を含むプロセッサエミュレータQEMUVM2162を有する。いくつかの実施形態によると、I/Oデバイス102の仮想化は、ハードウェアを大幅に変更することなく、高性能と、VM106および108でデバイス102を共有できる機能とが提供されるように行われる。これは、デバイス102がVMM104および一つ以上のVMたとえば、VM106および108を認識できるように、デバイス102のハードウェアおよびソフトウェア/ファームウェアを変更することにより実現する。これにより、デバイス102は、高性能が実現されるような態様で、多くのVM106および108と直接的にやり取りできるようになる。デバイス102は、各VMからのワークロードを切り分けてスケジューリングする役割も有する。しかし、デバイス102のハードウェアへの変更を最小限にするためには、この技術では、VMM104において、物理デバイス102と同一のデバイスをエミュレートした従来のデバイスエミュレーションモデルが必要である。VM106および108からデバイス102への低頻度アクセスたとえば、デバイスセットアップを実行するためのアクセスは、デバイスモデル164によりトラップかつエミュレートされるが、高頻度アクセスたとえば、デバイスとのデータの送受信、割り込み等は、デバイス102に直行し、コストの掛かるVMM104の関与が回避される。いくつかの実施形態では、VMM104におけるデバイスモデルは、実際の物理デバイス102と同一の仮想デバイスとしてVM106または108に現れ、デバイス資源への低頻度アクセスの全てを処理する。いくつかの実施形態では、このモデルは、高頻度デバイス資源への直接的なVMアクセスもセットアップする。いくつかの実施形態では、デバイス102が仮想化を認識して、複数のVM106および108と直接的にやり取りできるように、VMMコンポーネント104がデバイス102上に形成される。このコンポーネントは、全ての高頻度VMアクセスを処理し、デバイスの共有を可能にする。いくつかの実施形態では、シングルルートI/O仮想化SR-IOV設計に比較して、デバイス102のハードウェアへの変更が最小限である。デバイス102上で実行されるソフトウェアコンポーネントは、VMM104コンポーネントを含むよう変更され、これにより、VMMコンポーネントは、高頻度なVMアクセスのVMMによる処理をデバイス自体にオフロードする。いくつかの実施形態によると、デバイス102は、非常にスマートなデバイスであり、高度にプログラム可能いくつかの実施形態では、たとえば、インテル社のララビーGPU等のGPUである。いくつかの実施形態によると、デバイス102は、マイクロ-OSまたはμOSと呼ばれる完全にFreeBSDに基づくOS112を実行する。いくつかの実施形態では、デバイスカードは、いくつかの実施形態ではウィンドウズ登録商標ビスタVMである2つのVM106および108で共有される。VM106および108は、デバイス102に直接的に処理を渡し、ネイティブ並みの性能が達成される。いくつかの実施形態では、VMM104は、XenオープンソースVMMを用いて実装される。いくつかの実施形態では、エミュレートされたデバイスをVM106および108のそれぞれに提供するべく、仮想化デバイスモデルをXenを用いて書き込む。このモデルは、VM106および108に、デバイス102のグラフィックスアパーチャ126へと直接的にアクセスさせ、VM106および/または108がデバイス102に直接的に処理を渡すことができるようにする。デバイスモデル164がデバイス動作のいくつかの点を制御できるようにするべく、ホストドライバへのデバイス拡張も用いる。ドライバ116は、デバイス102上のVMMコンポーネントが、仮想化を自覚して、複数のVMから処理を直接的に受け取れるようにするべく、いくつかの実施形態にしたがって変更される。VM106または108のグラフィックスアプリケーションは、デバイス102側のOS112アプリケーションを開始させる。次に、VMのアプリケーション134または144は、対応するデバイスアプリケーション118または120にワークロードデータを送信して処理たとえば、レンダリングさせる。ドライバ116が変更されているので、OS112は、複数のVM106および108からアプリケーション118および120を、それらが、同一のホストからの複数のアプリケーションであるかのように、実行することができるようなる。異なるVMからのワークロードを異なるOSアプリケーションで実行することにより、これらは切り分けられるようになる。いくつかの実施形態では、OSスケジューラ114は、一つのVMからのアプリケーションによって別のVMからのアプリケーションの資源が枯渇しないように、各VMからのアプリケーションをスケジューリングできるよう変更される。いくつかの実施形態では、グラフィックスデバイスの仮想化がVMM104に実装される。いくつかの実施形態では、2つのVM106および108は、単一のデバイスカードを共有し、グラフィックスアパーチャ126を介した直接的なアクセスにより、各々のワークロードをデバイス102上で直接的に実行させる。OS112のドライバ116およびスケジューラ114は、複数のVM間たとえば、アプリケーション134および144間、および/または、複数のDXアプリケーション間で切り分けてスケジューリングを実行するよういくつかの実施形態にしたがって変更される。いくつかの実施形態によると、以下のように5つの主要な技術を実装してI/Oデバイスの仮想化を実行してよい。1.完全なデバイスエミュレーション完全なデバイスエミュレーションでは、VMMは、デバイスモデルを用いてハードウェアデバイスをエミュレートする。VMは、エミュレートされたデバイスを認識して、それへのアクセスを試みる。これらのアクセスは、デバイスモデルによりトラップされ、処理される。VMの要求を実行するには、これらのアクセスのうちいくつかは、VMMにおける物理デバイスにアクセスする必要がある。モデルによりエミュレートされた仮想デバイスは、システムに存在する物理デバイスから独立していることができる。これは、この技術の大きな利点であり、VMのマイグレーションが簡単になる。しかし、この技術の欠点は、デバイスのエミュレーションには性能のオーバーヘッドが伴い、ネイティブ並みの性能がVMで実現されないことである。2.直接デバイス割り当てこの技術では、デバイスは、直接的にVMに割り当てられ、デバイスのメモリマップトI/OMMIO資源の全てが、VMによって直接的にアクセス可能とされる。これによって、ネイティブのI/O性能がVMで実現される。しかし、デバイスをその他のVMと共有することができないことが欠点である。さらに、VMのマイグレーションがずっと困難である。3.VMにおける準仮想化ドライバこのアプローチでは、VMMドライバとやり取りして共有を可能にする準仮想化ドライバをVM内にロードする。この技術では、仮想デバイスは、物理デバイスから独立していることができ、デバイスモデルに基づくアプローチよりも良好な性能を実現できる。しかし、このアプローチの欠点は、VM内に新たなドライバが必要であり、デバイス割り当てで実現される性能にはやはり及ばないことである。さらに、仮想デバイスのセマンティクスと物理デバイスのセマンティクスとの間の変換を実装するのが困難であり、フィーチャーコンプリートでない場合が多いたとえば、グラフィックス仮想化におけるAPIプロキシ。4.仲介パススルーMeidatedPass-ThroughMPTまたは補助ドライバパススルーAssistedDriverPass-ThroughADPT最近、VMMのベンダは、準仮想化ドライバを改良した、MPTまたはADPTと呼ばれる技術を提案しており、この技術では、エミュレートされた仮想デバイスは、物理デバイスと同一である。これにより、VMは、既存のデバイスドライバをVMがVMMとやり取りできるように多少変更して使用することができるようになる。また、これにより、VMのワークロードを仮想デバイスのフォーマットから物理デバイスのフォーマットに変換するためのオーバーヘッドが回避される両方とも同一であるから。このアプローチの欠点は、VMがデバイスと直接的にやり取りできないので、デバイス割り当てで実現される性能には追いつかないことである。5.ハードウェアアプローチたとえば、SR-IOVこのアプローチでは、デバイスハードウェアを変更して、各VMに一つずつとして、デバイス資源のインスタンスを複数生成する。シングルルートI/O仮想化SR-IOVは、ハードウェアベンダの間で普及している規格であり、これらのデバイスにソフトウェアインターフェースを規定する。デバイス資源物理的機能またはPFの複数のインスタンスと複数の仮想機能またはVFを生成する。このアプローチの利点は、複数のVM間でデバイスを共有することができ、同時に高性能を実現することができることである。欠点は、デバイスのハードウェアを大幅に変更しなければならないことである。さらなる欠点は、特定数のVMをサポートするようデバイス資源が静的に生成されることであるたとえば、4個のVMをサポートするようデバイスが構築されており、現在実行されているVMが2個しかない場合、残り2個のVM用の資源は未使用のままであり、実行中の2個のVMが利用することができない。いくつかの実施形態によると、上記の4および5の技術を組み合わせたアプローチを用いて、高性能かつ共有可能なデバイスを実現する。この組み合わせ方法では、5の技術で要求されるハードウェア変更の大半が不要である。また、5の技術でのように、静的に区画するのではなく、デバイス資源をVMに動的に割り当てることができる。いくつかの実施形態では、ハードウェアおよびデバイス上で実行されるソフトウェアが変更されるので、VMと直接的にやり取りでき、4の技術と異なりネイティブ並みの性能が得られる。4の技術と同じく、いくつかの実施形態では、物理デバイスと同一の仮想デバイスをエミュレートするデバイスモデルを使用する。デバイスモデルを使用し、かつデバイスソフトウェア/ファームウェアに変更を加えることで、5の技術で必要とされるハードウェア変更の大半が不要になる。2の技術と同じく、いくつかの実施形態では、デバイス資源のいくつかをVMに直接的にマッピングして、VMがデバイスと直接的にやり取りできるようにする。しかし、2の技術と異なり、いくつかの実施形態では、デバイスが複数のVM間で共有できるような方法で、デバイス資源をマッピングする。5の技術と同じく、いくつかの実施形態では、高性能を実現するべくデバイスの振る舞いを変更する。しかし、5の技術と異なり、デバイスソフトウェア/ファームウェアを主に変更し、ハードウェアには最低限の変更しかせず、これによりデバイスを低コストに維持し、製品化までに要する時間を短縮する。また、ハードウェアでなくデバイスのソフトウェアに変更を加えることで、デバイス資源がVMにオンデマンドで動的に割り当てられる。いくつかの実施形態によると、デバイスのハードウェアを大幅に変更することなく、デバイス共有およびデバイス資源のVMへの動的割り当てを可能にして、高性能I/O仮想化を実装する。既存の方法では、これらの4つの要素の全てを満たすものはない。いくつかの実施形態では、デバイスソフトウェア/ファームウェアを変更し、ハードウェアも多少変更して、デバイスがVMのワークロードを直接的に実行できるようにし、各VMからのワークロードを切り分けてスケジューリングできるようにする。いくつかの実施形態では、モデルに基づいた直接実行を採用する組み合わせ方法を実装する。いくつかの実施形態では、デバイスのハードウェア資源の複数のインスタンスを形成するのではなく、デバイスソフトウェア/ファームウェアを変更する。これにより、各VMからのワークロードを切り分けてスケジューリングすることができる。図2は、いくつかの実施形態に係るフロー200を示す。いくつかの実施形態では、202で、VMは、デバイス資源たとえば、デバイスのMMIO資源へのアクセスを要求する。204で、MMIO資源が頻繁にアクセスされる資源であるかを判定する。204で頻繁にアクセスされる資源でないと判定されると、206で、要求はVMMデバイスモデルにトラップされ、エミュレートされる。次に、208で、VMMデバイスモデルは、切り分けおよびスケジューリングを行う。210で、VMMデバイスモデルは、デバイス資源212にアクセスする。204で頻繁にアクセスされる資源であると判定されると、214で、VMはデバイスへの直接アクセス経路を使用する。216で、デバイス上のVMMコンポーネントは、VMの直接アクセスを受け入れる。次に、218で、VMMコンポーネントは、これらのアクセスを適切に切り分けてスケジューリングする。220で、VMMコンポーネントは、デバイス資源212にアクセスする。近年のデバイスはプログラム可能性が増大し、デバイス機能のかなりの部分がデバイスで実行されるソフトウェア/ファームウェアにより実装される。いくつかの実施形態では、デバイスハードウェアの変更が最小限であるか、全く必要でない。したがって、いくつかの実施形態によると、I/Oデバイス等のデバイスの変更は、たとえば、SR-IOVを用いるハードウェア的アプローチに比べて、ずっと速い。いくつかの実施形態では、I/Oデバイス等のデバイスは、ほぼ時間をかけずに仮想化することができる。いくつかの実施形態にしたがってデバイスソフトウェア/ファームウェアを変更して、高性能I/O仮想化を提供してよい。いくつかの実施形態では、単一のI/Oメモリ管理ユニットIOMMUテーブルを用いて複数の要求者IDをエミュレートしてよい。図3は、いくつかの実施形態に係るシステム300を示す。いくつかの実施形態では、システム300は、デバイス302たとえば、I/Oデバイスを備える。デバイス302は、デバイス上に、VMMコンポーネントと、第1VMワークロード306および第2VMワークロード308とを有する。システム300は、第1VMIOMMUテーブル312および第2VMIOMMUテーブル314を有する合併IOMMUテーブル310をさらに備える。システム300は、第1VMメモリ322および第2VMメモリ324を有するホストメモリ320をさらに備える。デバイス302上のVMMコンポーネント304は、ゲスト物理アドレスGPAを、ワークロードが使用する前にタグする。ワークロード306は、IOMMUテーブルidにタグされたGPA1を使用してVM1IOMMUテーブル312にアクセスし、ワークロード308は、IOMMUテーブルidにタグされたGPA2を使用してVM2IOMMUテーブル312にアクセスする。図3は、高性能I/Oを実現するべく各VMがデバイス302たとえば、I/Oデバイスに直接アクセスできる場合に、複数のVMで単一のデバイスを共有する課題に関する。VMは、デバイスに直接的にアクセスしているので、ゲスト物理アドレスGPAをデバイスに供給する。デバイス302は、メモリがアドレスを用いてアクセスされる前にVMのGPAをホスト物理アドレスHPAに変換するIOMMUテーブル310を使用することにより、VMメモリ322および/または324にアクセスする。現在、各デバイス機能は、要求者IDと呼ばれる識別子を使用することにより単一のIOMMUテーブルを使用することができる全てのデバイス機能が要求者IDを持つ。しかし、VMごとにそれぞれ異なるIOMMUテーブルが、そのVMの各GPAをHPAにマッピングするべく必要である。したがって、デバイス機能は、一度に一つのIOMMUテーブルにしかアクセスすることができないので、複数のVMで機能を直接的に共有することはできない。図3のシステム300は、一つのデバイス機能に複数の要求者IDをエミュレートして、デバイス機能が同時に複数のIOMMUテーブルにアクセスできるようにすることにより、上記の問題を解決する。複数のIOMMUテーブルにアクセスを有することにより、デバイス機能は、複数のVMのメモリに同時にアクセスでき、これらのVMにより共有されることができる。複数のIOMMUテーブル312および314は、単一のIOMMUテーブル310に合併され、デバイス機能はこの合併IOMMUテーブルを使用する。IOMMUテーブル312および314は、IOMMUテーブルIDがGPAの高位ビットで表されるようにして合併IOMMUテーブル310内で各テーブルのマッピングを異なるオフセットで配置することによって合併される。たとえば、各IOMMUテーブル312および314が39ビットアドレスこれは、ゲストメモリの512GBをマッピングすることができるをマッピングし、合併IOMMUテーブル310が48ビットアドレスをマップすることができる仮定すると、合併IOMMUテーブルを生成し、第1IOMMUテーブルをオフセット0で設け、第2IOMMUテーブルを512GBのオフセットで設け、第3IOMMUテーブルを1TBのオフセットで設け、以下同様となる。効果的に、高位ビット39~47が、合併IOMMUテーブル310での各IOMMUテーブルナンバーの識別子となる。この合併テーブルで動作するには、各IOMMUテーブル宛のGPAを補正する。たとえば、第2IOMMUテーブルのGPA0は、合併IOMMUテーブルではGPA512GBに現れる。したがって、デバイスが使用しているアドレスGPAを修正して、IOMMUのGPAの補正を反映するようにし、合併IOMMUテーブルの正確な部分が用いられるようにすることが必要となる。基本的に、デバイスがGPAにアクセスする前に、GPAの高位ビットをIOMMUテーブルナンバーにタグする。いくつかの実施形態では、デバイスで実行されるソフトウェア/ファームウェアを、このタグを行うように変更する。いくつかの実施形態では、システム300は、2つの重要なコンポーネントを備える。VMMコンポーネント304は合併IOMMUテーブル310を生成し、デバイス機能にこのIOMMUテーブルを使用させる。追加的なデバイスコンポーネントは、VMからGPAを受け取り、GPAの送り元のVMに対応するIOMMUテーブルナンバーにGPAをタグする。これにより、デバイスは、そのVMのIOMMUテーブル今となっては、合併IOMMUテーブルの一部であるのマッピングを正確に使用することができるようになる。デバイスによるGPAのタグと合併IOMMUテーブルの生成とが組み合わさることで、単一の要求者IDを使用して複数の要求者IDがエミュレートされる。システム300は、2つのVMおよびそれらに対応するIOMMUテーブルを備える。これらのIOMMUテーブルは、単一の合併IOMMUテーブルに異なるオフセットで組み入れられており、これらのオフセットは、デバイス上の対応するVMのワークロードによって使用されるGPAにタグされている。これにより、本質的に、単一のIOMMUテーブルを使用して複数のRIDがエミュレートされる。図3では、VMのメモリをホストメモリにおける連続的なブロックとして示しているが、VMのメモリは、実際には、ホストメモリ内で分散された不連続のページであってよい。IOMMUテーブルは、各VMの連続的なGPA範囲から、ホストメモリの不連続の物理ページにマッピングする。いくつかの実施形態では、デバイス302はGPUである。いくつかの実施形態では、デバイス302は、インテル社のララビーGPUである。本明細書で記載するララビーGPU等のGPUは、非常にスマートなデバイスであり、高度にプログラム可能である。いくつかの実施形態では、このデバイスは、本明細書に記載のマイクロOSまたはμOSと呼ばれる完全にFreeBSDに基づいたOSを実行する。このため、このデバイスはこの技術にとって理想的な候補である。いくつかの実施形態では、単一のデバイスカードたとえば、単一のララビーカードを2つのウィンドウズ登録商標ビスタVMで共有する。VMは、デバイスに処理を直接的に渡すので、ネイティブ並みの性能が実現される。いくつかの実施形態では、XenVMM等のオープンソースVMMを使用する。いくつかの実施形態では、合併IOMMUテーブル310を生成するようVMMおよび/またはXenVMMを変更する。いくつかの実施形態では、デバイスOSドライバが、デバイスアプリケーションのページテーブルをセットアップするとき、VMが使用するIOMMUテーブルのナンバーにGPAをタグするように、デバイスOSドライバを変更する。デバイスOSドライバは、ホストメモリとローカルメモリとでDMAを行う必要がある場合も、GPAをタグする。これにより、GPAへの全てのアクセスが、合併IOMMUテーブルを使用して正確なHPAにマッピングされるようになる。既存のデバイスたとえば、SR-IOVデバイスは、デバイス内に複数のデバイス機能を実装しており、複数の要求者IDRIDが生成される。複数のRIDがあることで、デバイスは、同時に複数のIOMMUテーブルを使用することができるようになる。しかし、これには、デバイスハードウェアの大幅な変更が必要であり、デバイスのコストおよび製品化までに要する時間が増大する。いくつかの実施形態では、VMMデバイスモデル内で、アドレス変換を実行する。VMは、ワークバッファをデバイスに渡すとき、VMMにトラップを生成し、VMMは、VMのワークバッファをデバイスに渡す前に、ワークバッファを構文解析してGPAを探し出し、GPAをHPAに変換する。VMMでのトラップ生成およびワークバッファの構文解析が頻繁であるので、この技術には、非常に大きい仮想化オーバーヘッドが伴う。いくつかの実施形態では、デバイスが一つの要求者IDを使用して複数のIOMMUテーブルを使用できるようにするべく、複数のデバイス機能を生成する代わりにデバイスソフトウェア/ファームウェアに必要とされる変更がわずかである。VMM304は、デバイス302を共有する全てのVMのIOMMUテーブルを含む合併IOMMUテーブル310を生成する。デバイスは、各GPAにアクセスする前に、そのGPAを対応するIOMMUテーブルのナンバーにタグする。これにより、デバイスのコストと製品化に要する時間が減少する。既存の方法では、複数のIOMMUテーブルに同時にアクセスするべく、最近のI/Oデバイスたとえば、インテル社のララビーGPUのプログラム可能性を利用していない。その代わりに、ハードウェアを変更することによって、複数のデバイス機能を実装し、同時に複数のIOMMUテーブルにアクセスできるようにしている。いくつかの実施形態では、合併IOMMUテーブル複数のIOMMUテーブルのマッピングを含むを使用し、GPAをIOMMUテーブルナンバーにタグするようデバイスソフトウェア/ファームウェアを変更する。図4は、いくつかの実施形態に係るシステム400を示す。いくつかの実施形態では、システム400は、デバイス402たとえば、I/Oデバイス、VMM404、サービスVM406、およびVM1408を備える。サービスVM406は、デバイスモデル412、ホストデバイスドライバ414、およびメモリページ416MMIOページとしてマッピングによりパススルーされるを有する。VM1408は、デバイスドライバ422を有する。図4は、デバイス仮想化でのVMMにおけるトラップを減らすためのメモリ支援レジスタmemorybackedregisterたとえば、MMIOレジスタの使用を示す。VMM404は、いくつかの実施形態に係るデバイスモデル412を使用してVM1408を実行し、I/Oデバイス402を仮想化する。デバイスモデル412は、メモリページを確保し、このメモリページに、VMのI/OデバイスのMMIOページをマッピングしてパススルーする。デバイスの適格なレジスタeligibleregistersがこのページに属している。デバイスモデル412およびVMのデバイスドライバ422は、両方とも、このページにアクセスすることにより、この適格なレジスタに直接的にアクセスすることができる。不適格なレジスタineligibleregistersへのアクセスは、相変わらずVMM404にトラップされ、デバイスモデル412によりエミュレートされる。完全なデバイスエミュレーションを用いたI/Oデバイスの仮想化では、VMのためにハードウェアデバイスをエミュレートするソフトウェアデバイスモデルがVMMに必要である。エミュレートされるハードウェアデバイスは、市販のオペレーティングシステムに存在するデバイスドライバを活用するべく、既存の物理デバイスに基づいたものであることが多い。VM408は、VMMデバイスモデル412によってエミュレートされたハードウェアデバイスを認識し、それへとアクセスするには、そのPCI、I/O、およびMMIOメモリマップトI/O空間を物理デバイスと見て、そこに読み出し書き込みを行う。これらのアクセスは、VMM404にトラップされ、デバイスモデル412に転送され、デバイスモデルで適切にエミュレートされる。多くの最近のI/Oデバイスのレジスタは、デバイスのPCIMMIOBARsベースアドレスレジスタによって設定される範囲に、メモリマップトI/Oにより現れる。しかし、VMアクセスの全てをデバイスのMMIOレジスタにトラップすることによるオーバーヘッドは大きく、仮想化デバイスの性能を大幅に低下させる。エミュレートされたデバイスのMMIOレジスタのいくつかは、VMによる読み出し/書き込み時に、レジスタの値を返すことおよびレジスタに値を書き込むこと以外には、デバイスモデルによる処理を必要としない。これらのレジスタ以下、適格レジスタeligibleregistersと呼ぶへのアクセスにおいては、実行するべき処理がないので、VMM404は、このアクセスを必ずしもトラップする必要はない。しかし、既存のVMMは、適格レジスタへのアクセスをトラップしており、デバイス仮想化を行うに際しての仮想化オーバーヘッドを不必要に増大させている。VM408が頻繁に適格レジスタにアクセスするのであれば、このオーバーヘッドは、一層重大なものとなる。システム400は、適格レジスタをメモリで支援することにより、MMIOレジスタへのアクセスによって発生するVMMトラップの数を減少させる。VMMのデバイスモデル412は、適格レジスタにメモリページを割り当て、これらのページをRO読み出し専用適格レジスタまたはRW読み出し/書き込み適格レジスタとしてVMにマッピングする。VM408が適格レジスタに適格アクセスを実行するとき、このアクセスは、VMM404にトラップされることなく、メモリに対して実行される。デバイスモデル412は、メモリページを、デバイスのMMIO空間における仮想レジスタの位置として使用する。デバイスモデル412は、メモリに適切な値を入れ、および/または、VM408が書き込んだ値を読み出すことにより、これらのレジスタを非同期的にエミュレートする。VMMとラップの数を減らすことにより、デバイス仮想化性能が向上する。適格レジスタは、レジスタのセマンティクスにしたがって、読み出し専用または読み出し/書き込み用として、通常のメモリ仮想化技術シャドウページテーブルまたは拡張ページテーブルEPTを用いて、VMのアドレス空間にマッピングされてパススルーされる。しかし、MMIOアドレスは、ページサイズの粒度でしか、VMにマッピングすることができないので、これらのレジスタをマッピングしてパススルーすると、そのページのレジスタが一つおきにVM408にマッピングされパススルーされる。したがって、VMM404は、適格デバイスレジスタを、同一ページに不適格レジスタが属していない場合にだけ、VM408にマッピングパススルーすることができる。したがって、いくつかの実施形態では、適格レジスタと同一ページに不適格レジスタが属さないように、デバイスのMMIOレジスタ配置を設計する。さらに、適格レジスタは、読み出し専用パススルーレジスタと読み出し/書き込み用パススルーレジスタとに分類されるが、これら2種類の適格レジスタは、別々のMMIOページに所属させる必要がある。VMが準仮想化ドライバを使用する場合、VMは、ハードウェアデバイスに頼る必要がなくなるように、デバイスにとって仮想化に好都合なMMIO配置を生成することができる。既存のVMMは、適格デバイスレジスタのVMへのマッピングパススルーを行っておらず、これらのレジスタへのアクセスをトラップすることにより不必要な仮想化オーバーヘッドを生じさせている。その理由の一つは、適格レジスタが不適格レジスタと同一のMMIOページに位置していることであるかもしれない。既存のVMMは、VM内で準仮想化ドライバを使用してVMMトラップを減少させている。これらの準仮想化ドライバは、たとえば、レジスタがVMでは意味を成さない値を有する場合これらのレジスタへのアクセスは不要であるとして回避し、または、たとえば、デバイスをプログラムするべく一連なりのレジスタに書き込むべくレジスタへのアクセスを一括処理する。システム400は、I/Oデバイス仮想化におけるVMMトラップの数をさらに減らすべく新しい技術を用い、デバイス仮想化性能を大幅に向上させる。システム400は、VMのデバイスにメモリ支援適格レジスタを使用し、これらのメモリページをVMにマッピングして、仮想デバイスにアクセスする際のVMMトラップの数を減少させる。既存のVMMデバイスモデルは、適格デバイスレジスタのVMへのマッピングパススルーを行っておらず、アクセスをトラップすることにより不必要な仮想化オーバーヘッドを生じさせている。これにより、デバイス仮想化において、必要以上のVMMトラップが発生している。いくつかの実施形態によると、適格MMIOレジスタをメモリで支援して、メモリページをVMにパススルーするべくマッピングし、VMトラップを減少させる。図5は、いくつかの実施形態に係るシステム500を示す。いくつかの実施形態では、システム500は、デバイス502たとえば、I/Oデバイス、VMM504、サービスVM506、およびVM508を備える。サービスVM506は、デバイスモデル512、ホストデバイスドライバ514、および割り込みステータスレジスタを含むメモリページ516を有する。VM508は、デバイスドライバ522を有する。デバイス502では、ワークロード完了532時、デバイス502は、534で、割り込みステータスレジスタたとえば、メモリページ516の割り込みステータスレジスタの位置を受信し、割り込みを生成する前に、これらのレジスタを更新する。システム500は、VM508への直接割り込み注入を示す。VMM504は、デバイスモデル512を用いて、VM508を実行し、そのI/Oデバイス502を仮想化する。デバイスモデルは、割り込みステータスレジスタを含むメモリページ516を割り当て、そのアドレスを物理I/Oデバイスに通知する。デバイスモデル512は、読み出し専用メモリページをVM508にマッピングしてパススルーする。I/Oデバイス502は、VMのワークロードを完了した後、メモリページ516の割り込みステータスレジスタを更新して、割り込みを生成する。デバイス割り込みを受信すると、プロセッサは、割り込みをVM508に直接的に注入する。これにより、VMのデバイスドライバ522は、割り込みステータスレジスタをVMMトラップを生成することなく読み出す。デバイスドライバ522が、割り込みをアクナレッジするべくこれらのレジスタに書き込むときには、VMMトラップを生成し、デバイスモデル512がそれを処理する。本明細書で議論したように、VMMは、I/Oデバイス仮想化を提供して、VMが物理I/Oデバイスを使用できるようにする。多くのVMMは、デバイスモデルを用いて複数のVMが一つの物理デバイスを使用できるようにする。I/O仮想化オーバーヘッドは、全仮想化オーバーヘッドの最も大きい部分を占める。I/O仮想化オーバーヘッドの多くは、VMのデバイス割り込みを処理する際のオーバーヘッドである。物理デバイスは、VMからの要求を処理し終わると、割り込みを生成し、その割り込みは、VMMのデバイスモデルによりトラップされ処理される。デバイスモデルは、仮想割り込みステータスレジスタをセットアップし、割り込みをVMに注入する。VMへの割り込み注入は非常に重い動作であると考えられている。割り込み注入には、VMをスケジューリングし、VMを実行するべく選択されたプロセッサにIPIを送信する必要がある。これにより、仮想化オーバーヘッドが大幅に増大する。VMは、割り込みを受信すると、割り込みステータスレジスタを読み出す。これにより、VMMのデバイスモデルにさらなるトラップが生成され、これによりレジスタの値が返される。割り込み処理の待ち時間を短縮するべく、ハードウェア特性仮想割り込み受け渡しvirtualinterruptdeliveryおよびポステッド割り込みpostedinterruptsと呼ばれるを用いて、VMMを関与させることなく、直接的に割り込みをVMに注入してよい。これらのハードウェア特性によって、デバイスは直接的にVMに割り込むことができる。直接割り込み注入は、直接デバイス割り当ておよびSR-IOVには功を奏するが、デバイスモデルに基づく仮想化方法には有用でない。なぜなら、VMのデバイスの割り込みステータスは、デバイスモデルにより管理され、デバイスモデルには、割り込みを通知して、デバイスモデルが割り込みステータスを更新できるようにしなければならないからである。システム500は、デバイスモデルに基づく仮想化方法において、VMへの直接割り込み注入を可能にする。VMMのデバイスモデルは、直接割り込み注入時に通知を受けないので、デバイス自体が、割り込みを生成する前に、デバイスモデルの割り込みステータスレジスタを更新する。デバイスモデルは、VMのデバイスの割り込みステータスにメモリを割り当て、そのメモリ位置をデバイスに知らせる。デバイスハードウェア、または、デバイスで実行されるソフトウェア/ファームウェアは、割り込みステータスレジスタの位置をデバイスモデルから受信し、割り込みを生成する前に当該位置を適切に更新するように変更される。デバイスモデルは、割り込みステータスレジスタをVMアドレス空間にマッピングして、VMのデバイスドライバがVMMトラップを生成することなく割り込みステータスレジスタにアクセスできるようにする。多くのデバイスの割り込みステータスレジスタは、1を書き込むことによりクリアされる、W1Cというセマンティクスレジスタのビットに1を書き込むと、そのビットはクリアされるを有する。RAMメモリは、W1Cセマンティクスをエミュレートできないので、これらのレジスタは、読み出し/書き込み用にVMにマッピングすることはできない。これらの割り込みステータスレジスタは、読み出し専用にVMにマッピングすることはできるので、VMは、VMMトラップを生成することなく割り込みステータスレジスタを読み出すことができるが、VMがたとえば、割り込みをアクナレッジするべく割り込みステータスレジスタに書き込む際には、VMMがこのアクセスをトラップして、デバイスモデルがW1Cセマンティクスをエミュレートする。したがって、システム500のいくつかの実施形態は、2つの重要なコンポーネントを用いる。いくつかの実施形態に係るシステム500の第一の重要なコンポーネントは、割り込みステータスレジスタにメモリを割り当て、これらのレジスタの位置をデバイスに通知し、当該メモリをVM508のMMIO空間にマッピングするVMMデバイスモデル512である。いくつかの実施形態に係るシステム500の第二の重要なコンポーネントは、デバイスモデル512から割り込みステータスレジスタの位置を受信し、VM508に割り込みを生成する前に、これらのレジスタを適切に更新するデバイス駐在コンポーネントdeviceresidentcomponent532である。いくつかの実施形態によると、直接割り込み注入をサポートするハードウェアたとえば、インテル社のプロセッサ用の仮想割り込み受け渡しおよびポステッド割り込みと呼ばれるAPIC特性を用いる。いくつかの実施形態では、VMMデバイスモデル512は、割り込みステータスレジスタを更新する役割をデバイス自体にオフロードし、VMへの割り込み注入に関与する必要がない。既存の方法では、デバイス割り込みが発生すると、デバイスモデルが割り込みステータスレジスタを更新し、割り込みをVMに注入する。図5のシステム500では、デバイスが、VMの割り込みステータスレジスタこれらのレジスタにデバイスモデルにより前もって割り当てられたメモリを更新し、VMに直接的に注入される割り込みを生成する。さらに、デバイスモデル512が、割り込みステータスレジスタをVMにマッピングし、VMのデバイスドライバがこれらのレジスタにアクセスする際のVMMトラップを回避する。既存の方法では、割り込みステータスレジスタは、デバイス自体に存在する。デバイスは、メモリ内の割り込みステータスレジスタを更新する役割を持たない。また、既存のデバイスモデルも、VMのデバイスドライバがこれらのレジスタにアクセスする際のVMMトラップを回避するためのVMへのこれらのレジスタのマッピングを行わない。いくつかの実施形態によると、物理I/Oデバイスが、メモリ内のデバイスモデルの割り込みステータスレジスタを更新し、割り込みを直接的にVMに注入できるようにする。本明細書では、いくつかの実施形態は、特定の方法で実装されると記載したが、いくつかの実施形態によると、これらの特定の実装例は必須ではない。いくつかの実施形態を特定の実装例を参照して記載したが、いくつかの実施形態によると、その他の実装例が可能である。さらに、図示および/または記載した回路要素またはその他の特性の配置および/または順序は、図示および記載した特定の態様で配置する必要はない。いくつかの実施形態によると、その他多くの配置が可能である。図に示した各システムにおいて、いくつかの場合における各要素は、同じ参照番号または異なる参照番号を有しており、図示された各要素が類似したものであるか、および/または、異なるものであるかを示唆する。しかし、要素は、多様に実装しうる柔軟性を持ち、本明細書に図示または記載したシステムのいくつかまたは全てにおいて動作しうる。図示した多様な要素は、同一または異なってよい。要素のいずれを第1と呼び、いずれを第2とするかは、任意である。記載および特許請求の範囲において、結合されたcoupledおよび接続されたconnectedという用語並びにこれらの活用形を使用する場合がある。これらの用語は、互いに同義語と意図されているのではないことは理解されるべきである。むしろ、特定の実施形態では、2つ以上の要素が互いに直接的に、物理的または電気的に接触していることを示すべく接続されたという用語が使用される。結合されたという用語は、2つ以上の要素が直接的に、物理的または電気的に接触していることを意味する。しかし、結合されたという用語は、2つ以上の要素が互いに直接的に接触していないが、それでも互いに協働またはやり取りする場合のことも意味する。アルゴリズムは、本明細書において、また、一般的に、所望の結果を導出する動作または処理の一貫したシーケンスであると考えられる。これには、物理量の物理的操作が含まれる。通常、必ずではないが、これらの量は、記憶、転送、組み合わせ、比較、またはその他の操作が可能な電気的または磁気的な信号という形態を有する。時として、このような信号を、ビット、値、要素、記号、文字、条件terms、数字等として参照することが、一般的によく使用されているという理由で、便利であることが分かっている。しかし、これらおよび類似の用語の全ては、適切な物理量に対応付けられるのであり、これらの量に適用された便宜的な呼称にすぎないことは理解されるべきである。いくつかの実施形態は、ハードウェア、ファームウェア、およびソフトウェアのいずれかまたは組み合わせで実施してよい。いくつかの実施形態は、本明細書に記載の処理を実行するべくコンピューティングプラットフォームによって読み出されて実行される機械可読媒体に格納された命令として実施してもよい。機械可読媒体は、機械たとえば、コンピュータによって読み出し可能な形態で情報を記憶または送信する任意のメカニズムであってよい。たとえば、機械可読媒体は、読み出し専用メモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電気、光、音、またはその他の形態で伝搬される信号たとえば、搬送波、赤外線信号、デジタル信号、信号を送信および/または受信するインターフェース等、およびその他であってよい。実施形態は、発明の実施例または例である。明細書においてある実施形態、一実施形態、いくつかの実施形態、またはその他の実施形態と言及する場合、その実施形態に関連して記載される特定の特性、構造、または特徴が、本発明の少なくともいくつかの実施形態に含まれるが、必ずしも全ての実施形態に含まれるのではないことを示す。ある実施形態、一実施形態、またはいくつかの実施形態等と多様に表現される場合、必ずしも全てが同一の実施形態を指すのではない。本明細書に記載および図示したコンポーネント、特性、構造、特徴等の全てを特定の実施形態または複数の実施形態に含める必要はない。明細書において、コンポーネント、特性、構造、または特徴を、含めうる、含めてよい、含めることができる等と記載される場合、たとえば、その特定のコンポーネント、特性、構造、または特徴を含める必要はない。明細書または特許請求の範囲において、一つのaまたは一つのan要素と述べる場合、その要素が一つしかないことを意味するのではない。明細書または特許請求の範囲において、さらなる要素と述べる場合、当該さらなる要素が2つ以上ある場合を除外しない。本明細書で実施形態を記載するべくフロー図および/または状態図を使用したが、本発明は、これらの図または本明細書における対応する記載に限定されない。たとえば、フローは、図示された各ボックスまたは状態を通過または遷移する必要がなく、本明細書に図示および記載した順序と全く同じ順序で通過または遷移する必要がない。本発明は、本明細書に挙げた特定の詳細に限定されない。事実、上記の記載および図面の多様な変形が本発明の範囲内で可能であることは、本開示から利益を受ける当業者には理解されよう。したがって、以下の特許請求の範囲、およびそれに対する修正があればそれらによって、本発明の範囲が規定される。