ハードウェアの仮想化。 プロセッサアーキテクチャの理論、現実、サポート

この投稿では、コンピューターの仮想化にハードウェアサポートを使用する理由と機能について説明します。 まず、仮想化に必要な3つの条件を特定し、その達成のための理論的基礎を策定します。 次に、理論が厳しい現実に見出す反射を説明します。 例として、さまざまなアーキテクチャのプロセッサのさまざまなベンダーが製品に仮想化を実装する方法について簡単に説明します。 最終的に、再帰的な仮想化の問題が提起されます。



まず、いくつかの定義。このトピックに関する記事ではあまり一般的ではないかもしれませんが、この記事で使用されています。

• ホスト（ Eng。Host ）-仮想マシンモニターまたはシミュレーターを実行するハードウェアシステム。
• ゲスト（ Eng。Guest ）-モニターまたはシミュレーターの制御下で実行される仮想またはシミュレートされたシステム。 ターゲットシステムとも呼ばれます。

本文に記載されている残りの用語を決定しようとします。

はじめに

仮想化は、マイクロプロセッサが発明される前から、大規模システム（メインフレーム）の優位性においても関心が寄せられていました。メインフレームのリソースは非常に高価で、その単純さは経済的に受け入れられませんでした。 仮想マシンは、仮想マシンが物理的なマシンと同一であるという観点から、ユーザーやアプリケーションプログラマーがソフトウェアを書き換える必要をなくしつつ、そのようなシステムの利用度を高めることを可能にしました。 この分野のパイオニアは、1960年代および1970年代に作成されたSystem / 360、System / 370メインフレームを備えたIBMでした。

従来の仮想化基準

当然のことながら、効果的な仮想マシンモニターを作成する可能性の基準はほぼ同時に取得されました。 これらは、1974年のジェラルドポペックとロバートゴールドバーグによる「仮想化可能な第3世代アーキテクチャの公式要件」[8]で定式化されています。 その基本的な前提を検討し、その主要な結論を策定します。

システムモデル

将来的には、1つの中央処理装置と線形同種RAMで構成される記事の「標準」コンピューターの簡略化された表現が使用されます。 周辺機器、およびそれらとの相互作用の手段は省略されています。 プロセッサは、オペレーティングシステムで使用されるスーパーバイザーモードと、アプリケーションアプリケーションが実行されるユーザーモードの2つの動作モードをサポートしています。 メモリは、仮想メモリの整理に使用されるセグメンテーションモードをサポートしています。

仮想マシンモニター（VM）の事前要件：

1. 分離-各仮想マシンは、それに割り当てられたリソースにのみアクセスできる必要があります。 モニターと他のVMの両方の操作に影響を与えることはできません。
2. 同等-VMの制御下で実行されるプログラムは、実際のシステムでの実行と完全に同一の動作を示す必要がありますが、2つの状況による影響を除きます：利用可能なリソースの数の違い（たとえば、VMのメモリが少なくなることがあります）および操作の期間（から-実行時間を他のVMと共有する可能性のため）。
3. 効率性-元の作業では、「VMモニターの介入なしに、仮想プロセッサ命令の統計的に支配的なサブセットをホストプロセッサで直接実行する必要があります」という条件が定式化されています。 つまり、命令の大部分は直接実行モードでシミュレートする必要があります。 効率の要件は、リストされている3つの要件の中で最も物議を醸すものであり、ここに戻ります。 命令の解釈に基づいたシミュレーターの場合、効率条件は満たされません。 各ゲスト命令には、シミュレーターによる処理が必要です。

命令クラス

プロセッサの状態には少なくとも3つのレジスタが含まれます：Mはスーパーバイザーモードsまたはユーザーuであるかどうかを決定し、Pは現在の命令へのポインターであり、Rは使用されたメモリセグメントの境界を定義する状態です（最も単純な場合、Rはセグメント、つまりRを定義します=（l、b）、ここでlは範囲の先頭のアドレス、bはその長さです）。

メモリEは、E [t]などの番号tでアクセスできる固定数のセルで構成されています。 この考慮のためのメモリとセルのサイズは重要ではありません。

実行されると、一般的な場合の各命令iは、（M、P、R）とメモリEの両方を変更できます。 それは変換関数です：（M ₁ 、P ₁ 、R ₁ 、E ₁ ）->（M ₂ 、P ₂ 、R ₂ 、E ₂ ）。

入力条件によっては、実行の結果としてメモリの内容が変化しない場合、プロセッサの以前の状態が配置されている単一セルE [0]を除いて、命令がトラップ（ eng。Trap ）を発生させると考えられます（M ₁ 、P ₁ 、R ₁ ） プロセッサの新しい状態（M ₂ 、P ₂ 、R ₂ ）がE [1]からコピーされます。 言い換えると、トラップは、通常のスーパーバイザーモードで動作し、システムの状態に追加のアクションを提供するように設計された従来のシステムの場合、最後の命令の実行前の時点でプログラムの完全な状態を保存し、ハンドラーに制御を移してから、制御をプログラムに戻し、状態を復元しますE [0]。

さらに、トラップには2つの属性があります。

1. プロセッサの状態を変更しようとしたために発生しました（制御フロートラップ）。
2. （メモリ保護トラップ）で定義された範囲外のメモリ内容へのアクセス。

これらの記号は相互に排他的ではないことに注意してください。 つまり、実行結果は、制御フローとメモリ保護のトラップになる可能性があります。

問題のプロセッサの機械語命令は、次のように分類できます。

• 特権（ 英語特権）。 M = uで実行される命令は、常に制御フローのトラップを引き起こします。 つまり、このような命令はスーパーバイザーモードでのみ実行できます。そうしないと、例外が必ずスローされます。
• オフィス（ 英語のセンシティブ。この概念の確立されたロシア語の用語は知らない。文献には「センシティブな」指示の翻訳があることがある）。 クラスは2つのサブクラスで構成されます。 1.命令。メモリ保護トラップなしで実行が終了し、Mおよび/またはRが変更されました。プロセッサモードをスーパーバイザーからユーザーに、またはその逆に変更したり、使用可能なメモリセグメントの位置とサイズを変更できます。 2.メモリ保護トラップを引き起こさない場合の動作を持つ命令は、MモードまたはRの値に依存します。
  
  
• 無害（ 英語無害）。 非公式。 命令ポインタPとメモリE以外は何も操作しない最も広いクラスの命令で、その動作はメモリ内のモードまたはアドレスに依存しません。
  
  

VMモニターを構築するための十分な条件

仮想マシンモニターの構築の可能性に関する上記の3つの条件の順守は、次の文に記載されています。 サービス命令のセットは特権命令のサブセットです （図1）。 記事から定理1の正式な証明を省略して、次の状況に注意します。

• モニターをスーパーバイザーモードに配置し、VMをユーザーモードにのみ配置することにより、分離が保証されます。 同時に、後者はシステムリソースを勝手に変更することはできません-試行により、サービス命令で制御フロートラップが発生し、モニター、およびこれを許可しない構成が原因でメモリに移動し、プロセッサがメモリ保護トラップを実行します。
• システムにモニターが存在するかどうかに関係なく、無害な命令が同じ方法で実行され、サービス命令が常に例外をスローして解釈されるという事実によって、同等性が証明されます。 上記の単純なスキームでも、最初の弱体化条件が顕在化することに注意してください。ハイパーバイザーのコードとデータを保存するために必要なメモリを考慮しなくても、VMで利用可能なメモリ量はホストシステムよりも少なくとも2セル少なくなります。
• VM内の無害な命令はすべて、速度を落とすことなく直接実行されるため、効率が保証されます。 それらの多くが「仮想プロセッサの命令の統計的に支配的なサブセット」を含むことが理解される。

図 1：仮想化条件の実現。 多くのサービス指示は特権のサブセットです

仮想化基準の適用性の制限

使用されたモデルの単純さと、そこから導かれた結論にもかかわらず、ゴールドバーグとポペックの研究は依然として関連しています。 ここに記載されている条件への違反は、一部のアーキテクチャで仮想マシンの作成または使用を根本的に不可能にするものではなく、これを確認する実装の実用例があることに注意してください。 ただし、分離、等価性、効率という3つのプロパティ間の最適なバランスを維持することは不可能になります。 ほとんどの場合、ハードウェア自体がこれを提供しないため、特権命令ではなく、サービスの実行を徹底的に検索およびプログラム制御する必要があるため、仮想マシンの速度で支払う必要があります（図2）。 VMによって直接実行されるこのような命令だけでも、モニターの安定した動作を脅かすため、ゲスト命令のストリーム全体をスキャンする必要があります。





図 2：仮想化の条件を満たすことができない。 特権命令ではないサービスでは、モニターに複雑なロジックを実装する必要があります



作業[8]には、実システムの研究された構造（周辺機器と入出力システムの欠如）の明示的に示された簡略化、および実行可能なゲストプログラム（ほぼ完全に無害な命令で構成される）およびホストシステム（ユニプロセッサ）の構造に関する暗黙の仮定の両方が含まれています。

これらの制限をより詳細に検討し、仮想化を必要とする追加リソースへの基準の適用度を拡大し、新しいコンピューティングシステムのアーキテクトにとって実用的な価値を高める方法を提案しましょう。

ゲストプログラムの構造

VM内でプログラムを効果的に動作させるには、それらの命令のほとんどが無害であることが必要です。 これは通常、アプリケーションアプリケーションに当てはまります。 オペレーティングシステムは、システムリソースを管理するように設計されています。これは、特権命令とサービス命令の使用を意味し、モニターはパフォーマンスを低下させてそれらをインターセプトおよび解釈する必要があります。 したがって、理想的には、トラップの発生頻度が最小限になるように、命令のセットにできるだけ少ない権限を設定する必要があります。

周辺機器

周辺機器はコンピューターのサービスリソースであるため、分離条件と同等性を確保するために、それらにアクセスするすべての試みは、コアによってマルチタスクオペレーティングシステムで制御されるのと同じ方法でVMモニターによって制御される必要があることは明らかです。 現在、デバイスへのアクセスはほとんどの場合、システムの物理メモリに反映されるメカニズムを介して行われます（ 英語のメモリマップI / O）。つまり、モニタ内では一部の領域のこの読み取り/書き込みがメモリ保護トラップを引き起こすか、公式ではないことを意味します、つまり トラップを引き起こしたり、制御不能な状態で状態に影響を与えたりしないでください。

アプリケーションと周辺機器間の相互作用の強度は異なる場合があり、それらの機能によって決定され、仮想化中の速度低下に影響します。 さらに、VMモニターは、ホスト上にあるさまざまなクラスの周辺機器を、さまざまな方法で複数のVM内でアクセス可能にすることができます。

• 専用デバイス-1つのゲストシステム内でのみ使用可能なデバイス。 例：キーボード、モニター。
• 共有-複数のゲストによって共有されます。 このようなデバイスには、複数のパーティションがあり、たとえば、いくつかのパーティションを持つハードディスクなど、それぞれのニーズに応じて割り当てられる（パーティションモード）いくつかの部分があるか、順番に接続されます（共有モード）。 例：ネットワークカード。
• 完全仮想-実際のシステムに存在しない（または存在するが、数が限られている）デバイスで、モニター内でプログラムによってモデル化されています。 例：割り込みタイマー-ホストシステムには1つしかないため、各ゲストには独自のタイマーがあり、モニター自体のニーズに使用されます。

中断

割り込みは、オペレーティングシステムの注意を必要とする外部デバイスのイベントについてプロセッサに通知するメカニズムです。 仮想マシンを使用する場合は、割り込みの一部またはすべてをモニター内で正確に処理する必要があるため、モニターは割り込みの配信を制御できる必要があります。 たとえば、タイマー割り込みを使用して、ゲストによるプロセッサ時間の使用を追跡/制限し、同時に実行されている複数のVMを切り替えることができます。 さらに、複数のゲストの場合、どのゲストが割り込みを配信する必要があるかが事前に明確ではないため、モニターが決定する必要があります。

最も単純な分離ソリューションは、すべての割り込みをVMモニターに向けることです。 この場合、等価性は自分で提供されます。必要に応じて、ゲストの状態の変化のシミュレーションを介して、ゲストの内部に割り込みが配信されます。 モニターは、外部イベントではなく、操作のロジックのみによって引き起こされる仮想割り込みを追加で作成できます。 ただし、このようなソリューションの有効性は最適ではありません。 原則として、システムの中断に対する反応は限られた時間内に発生する必要があります。そうしないと、外部デバイスにとって意味を失うか、システム全体に壊滅的な結果をもたらします。 仮想化レイヤーを導入すると、仮想化のないシステムと比較して、イベントが発生してからゲストによって処理されるまでの遅延が増加します。 より効果的なのは、割り込みの配信をハードウェアで制御することです。これにより、割り込みの一部をシステムの状態に無害にでき、毎回監視プログラムの介入を必要としません。

マルチプロセッサシステム

ほとんどすべての最新のコンピューターには、複数のコアまたはプロセッサーが含まれています。 さらに、1つのモニター内で複数のVMを実行できます。各モニターは、複数の仮想プロセッサを自由に使用できます。 これらの状況が仮想化の条件にどのように影響するかを検討してください。

同期と仮想化

いくつかのホストプロセッサとゲストプロセッサの検討の概要では、効果的な仮想化の条件が有効になっています。 ただし、VM内のマルチスレッドアプリケーションの効率の条件が満たされていることに注意する必要があります。 シングルスレッドとは異なり、さまざまな仮想プロセッサで実行されるプログラムパーツの同期プロセスが特徴です。 同時に、すべての参加スレッドは、アルゴリズム内の所定のポイント、いわゆる 障壁。 システム仮想化の場合、1つ以上のゲストスレッドが非アクティブになり、モニターによって混み合ってしまい、残りのスレッドが時間を浪費する可能性があります。

ゲストシステムのこのような非効率的な動作の例は、VM内の循環ロック（ eng。Spin lock）を使用した同期です[9]。 非効率的であるため、シングルプロセッサシステムでは使用されません。複数のプロセッサの場合、並列アルゴリズムの重要なセクションに入るために使用される他のより重いロック（ 英語ロック）の軽量な代替手段です。 ほとんどの場合、ユーザープログラムではなくオペレーティングシステム内で使用されます。これは、循環ロックを使用して効果的に保護できるシステムリソースを正確に判断できるのはOSだけだからです。 ただし、仮想マシンの場合、リソースプランニングは実際にはOSによって行われるのではなく、VMモニターによって行われます。VMモニターは一般にそれらを認識せず、リソースを解放できるスレッドを押し出しますが、2番目のスレッドは循環ロックを実行し、CPU時間を浪費します。 最適な解決策は、必要なリソースが解放されるまで、ブロックされたストリームを非アクティブ化することです。



この問題に対する既存の解​​決策を以下に説明します。

1. VMモニターは、ゲストOSによる循環ロックの使用を検出しようとする場合があります。 これには、実行前にコードを分析し、ロックのアドレスにブレークポイントを設定する必要があります。 この方法は、検出の普遍性と信頼性に違いはありません。
2. ゲストシステムは、特別な命令を使用して、サイクリックロックを使用するつもりであることをモニターに通知できます。 この方法はより信頼性が高いですが、ゲストOSコードの変更が必要です。

マルチプロセッサ割り込み

最後に、複数のプロセッサを備えたシステムでの配信および割り込み処理スキームもより複雑であり、そのようなシステムのVMモニターを作成する際には、これを考慮する必要がありますが、その効率はユニプロセッサの同等のものよりも低い場合があります。

アドレス変換

効率的な仮想化に関するステートメントを作成するために以前に使用された機械命令モデルは、前世紀の70年代に普及した単純な線形セグメンテーションベースのアドレス変換スキームを使用していました。 計算は単純で、VMモニターの導入によって変化しないため、効率に対するアドレス変換メカニズムの影響の分析は実行されていません。

現在、ページ仮想メモリメカニズムは、ユーザーアプリケーションの仮想アドレスを機器が使用する物理アドレスに非線形変換することも使用しています。 これに関係するシステムリソースは、変換テーブルのアドレスのレジスタポインターです（実際には、多くの場合、共通のルートを持つ階層を形成する複数のテーブルが使用されます）。 VM操作の場合、各ゲストシステムには独自のレジスタコンテンツとテーブルの位置/コンテンツがあるため、このポインタを仮想化する必要があります。 モニター内のこのメカニズムのソフトウェア実装のコストは高いため、メモリを積極的に使用するアプリケーションは仮想化の有効性を失う可能性があります。

この問題を解決するために、2レベルのハードウェアアドレス変換が使用されます（図3）。 ゲストOSには最初のレベルのみが表示されますが、ゲストOS用に生成された物理アドレスは、その後、2番目のレベルによって実際のアドレスに変換されます。





図 3：2レベルのアドレス変換。 最初のレベルはゲストOSによって制御され、2番目は仮想マシンモニターによって制御されます

TLB

アドレス変換を担当する別のコンピューターリソースは、複数のエントリで構成される変換ルックアサイドバッファー（TLB）です。 各ゲストシステムには独自のTLBコンテンツがあるため、アクティブなVMを変更したり、モニターに移動した場合は、リセットする必要があります。 これはシステムのパフォーマンスに悪影響を及ぼします。その内容を復元するには時間が必要であり、その間にメモリ内にあるアドレス変換テーブルへの効率の悪いアクセスを使用する必要があるためです。

解決策は、すべてのシステム間でTLBリソースを共有することです[10]。 バッファの各行は、各VMに固有のタグである識別子に関連付けられています。 その中の機器を検索する場合、現在のVMに対応するタグを持つ行のみが考慮されます。

周辺機器のアドレス変換

プロセッサに加えて、周辺機器はDMAテクノロジー（ダイレクトメモリアクセス）を使用してRAMに直接アクセスすることもできます。 この場合、仮想化のない従来のシステムでの呼び出しは物理アドレスに送られます。 明らかに、そのようなアドレスを仮想マシン内で変換する必要があり、これはオーバーヘッドになり、モニターの有効性を低下させます。

解決策は、IOMMUデバイス（ 英語の入出力メモリ管理ユニット）を使用することです。これにより、ホストデバイスから物理メモリへのアクセスを制御できます。

原則の拡張

仮想化の条件を拡張するには、「命令」という言葉を「操作」に置き換えます。サービス操作のセットは特権的な操作のサブセットです。 この場合、操作とは、命令、割り込み、デバイスへのアクセス、アドレス変換など、システムの状態を読み取りまたは変更するためのアーキテクチャ固有のアクティビティを意味します。

同時に、仮想化の効率を高めるための条件は次のとおりです。 サービスオペレーションの最小数がシステムアーキテクチャに存在する必要があります 。 それを実現するには、2つの方法があります。サービス指示を無害な指示に変換するか、特権のある指示の数を減らすことです。 これを行うために、ほとんどのアーキテクチャでは、状態レジスタMに新しいrモード、つまりVMモニターモード（ルートモード）を追加しました。 s-to uのように、モードsに対応します。 言い換えると、特権命令の更新されたクラスにより、プロセッサをsからrに転送する制御フロートラップが発生するようになりました。

最新のアーキテクチャでのサポート状況

上記の理論的原理の実際的な実装の観点から、サーバー、ワークステーション、および組み込みシステムで使用されるコンピューティングシステムの主要な最新アーキテクチャを検討してください。 一連の記事[5,6,7]も参照してください。

IBM Power

IBMは、2001年にPOWER4シリーズのサーバーマイクロプロセッサ市場にハードウェアベースの仮想化サポートを備えたアーキテクチャを導入した最初の企業の1つです。 分離された論理パーティション（ 英語の論理パーティション、LPAR）を作成することを目的としており、それぞれに1つ以上のプロセッサとI / Oリソースが関連付けられています。 これを行うために、既存のスーパーバイザーモードとユーザーモードに加えて、プロセッサーに新しいハイパーバイザーモードが追加されました。 メモリを保護するために、各LPARはアドレス変換が無効なモードで制限され、小さなプライベートメモリ領域のみにアクセスできます。 残りのメモリを使用するには、ゲストOSがVMモニターによって制御されるブロードキャストを有効にする必要があります。

2004年、POWER5と呼ばれるこのアーキテクチャの開発により、仮想化メカニズムが大幅に改善されました。 そのため、VMモニターでのみ使用可能な新しいタイマーデバイスが追加されました。これにより、ゲストシステムをより正確に制御し、プロセッサーの100分の1の精度でプロセッサーリソースを割り当てることができました。 また、VMモニターは、LPARまたはハイパーバイザーの割り込み配信アドレスを制御できました。 最も重要な革新は、ハイパーバイザーの存在が必須であるという事実でした。システムに単一のLPARパーティションがあったとしても、システムリソースをロードおよび管理しました。 サポートされているOS（AIX、Linux、IBM i）は、一種の準仮想化スキームをサポートするために、これを念頭に置いて変更されました。 I / Oデバイスを管理するために、LPARから1つ（または2つ、ロードバランシング用）が特別なオペレーティングシステム-仮想I / Oサーバー（VIOS）をロードし、残りのパーティションにこれらのリソースを提供します。

SPARC

UltraSPARCとSolarisを開発したSunは、2004年からOSレベルの仮想化（いわゆるコンテナまたはゾーン）を提供しています。2005年に、ハードウェアベースの仮想化がNiagara 1マルチスレッドプロセッサに導入されました。 さらに、仮想化の粒度は1スレッドに相当しました（合計で、チップには8コア、各4スレッド）。

OSとハイパーバイザーの相互作用のために、特権アプリケーション用のパブリックで安定したインターフェイス[3]が導入されました。これにより、アーキテクチャレジスタのほとんどがOSから隠されます。

アドレス変換では、仮想アドレス、実アドレス、物理アドレスを使用した上記の2レベルのスキームが使用されます。 ただし、TLBは中間変換アドレスを保存しません。

Intel IA-32およびAMD AMD64

POWERやSPARCとは異なり、IA-32アーキテクチャ（およびそのAMD64拡張）は、ハードウェアとOSの間に仮想化機能（ペア）を追加できる既存のオペレーティングシステムとの後方互換性に違反する企業によって制御されることはありません。 さらに、効果的な仮想化の条件に明らかに違反しています。約17のサービス命令には特権がなく、ハードウェアでサポートされるVMモニターを作成できませんでした。 ただし、IntelはVT-xテクノロジーを導入し、AMDは類似しているが互換性のないAMD-Vテクノロジーを導入した2006年までソフトウェアモニターが存在していました。

新しいプロセッサモードが導入されました-VMXルートモードと非ルートモード、および既存の0〜3の特権モードを両方で使用できます。 モード間の移行は、新しいvmxonおよびvmxoff命令を使用して実行できます。

ゲストシステムとモニターの状態を保存するために、新しいVMCS（ 英語の仮想マシン制御構造）構造が使用されます。その構造のコピーは物理メモリーにあり、VMモニターで使用できます。

興味深い解決策は、ゲスト内のどのイベントがトラップイベントをトリガーしてハイパーバイザーに移行するか、およびOSによる処理のために残される構成可能性です。 たとえば、ゲストごとに、外部割り込みをゲストとモニターのどちらで処理するかを選択できます。 制御レジスタCR0およびCR4のどのビットがインターセプトされるかを書き込む。 ゲストが処理する例外、モニターが処理する例外など。 このソリューションにより、各VMの制御の程度と仮想化の有効性の間の妥協が可能になります。 したがって、信頼できるゲストの場合、モニターの制御が弱められる可能性がありますが、同時に実行されるサードパーティOSは依然として厳格な監視下に置かれます。 TLBの動作を最適化するために、ASID（ 英語アドレス空間識別子）を使用してエントリにタグ付けする上記の手法が使用されます。 アドレス変換のプロセスを高速化するために、2レベルの変換スキームはIntel EPT（ 英語の拡張ページウォーク）と名付けられました。

Intel IA-64（Itanium）

Intelは、2006年にIA-32と同時にハードウェア仮想化をItaniumに追加しました（VT-iテクノロジー[4]）。 ステータスレジスタPRS.vmの新しいビットを使用して、特殊モードがアクティブ化されました。 ビットをオンにすると、以前はオーバーヘッドでしたが、特権命令ではないため、トラップが発生し、モニターに終了します。 ゲストOSモードに戻るには、vmsw命令が使用されます。 命令の一部（サービス命令）は、仮想化モードがオンになっている場合、カスタムハンドラーが割り当てられる新しいタイプの同期例外を生成します。

オペレーティングシステムは特別なPALインターフェイス（プロセッサ抽象化レベル）を介してハードウェアにアクセスするため、後者はゲスト環境の作成と破棄、状態の保存と読み込み、仮想リソースの構成などの操作をサポートするように拡張されています。 IA-64にハードウェア仮想化を追加する場合、IA-32よりも少ない労力で済みます。

腕

ARMアーキテクチャは、もともと組み込みおよびモバイルシステム用に設計されたものであり、サーバーシステムと比較して、その効果的な仮想化は、商業的および技術的成功の重要な要因ではありませんでした。 ただし、近年では、モバイルデバイスでVMを使用して、システムコードの重要な部分（商業取引の処理に使用される暗号キーなど）を保護する傾向があります。 さらに、ARMプロセッサがサーバーシステム市場に進出し始めたため、アーキテクチャを拡張し、大量のメモリへの対応や仮想化のサポートなどの機能を追加する必要がありました。

両方の側面は、そのアーキテクチャの開発に対するARMのアプローチに反映されていました。 図 図4は、Cortex A15アーキテクチャの更新で2010年に提示された2つのレベルの仮想化のネストを意味する図を示しています[1]。





図 4：ARM仮想化。 TrustZoneモニターは、信頼できる「世界」の分離と暗号化認証を提供します。 通常の「世界」では独自のモニターVMを使用します



重要なコンポーネントの分離を確保するために、TrustZoneと呼ばれる最初の仮想化レイヤーが使用されます。 その助けにより、実行中のすべてのソフトウェアコンポーネントは、信頼できるものと通常の2つの「世界」に分けられます。 最初の環境では、通常のコードの外部の影響を受けないようにする必要があるシステムの部分が実行されます。 2番目の環境では、ユーザーアプリケーションとオペレーティングシステムが実行され、理論的には侵害される可能性があります。 ただし、通常の「世界」は信頼できるものにはアクセスできません。 TrustZoneモニターは反対方向へのアクセスを提供し、信頼できるコードが機器の状態を監視できるようにします。

2番目の仮想化層は、信頼できないモニターの制御下で実行され、複数のユーザーOSの動作を多重化する可能性を提供します。 新しいHVCおよびERET命令を追加して、ハイパーバイザーモードを開始および終了します（a）。 トラップイベントでは、以前に予約された0x14割り込みベクターが使用され、新しいレジスタが追加されました。SPSRスタックポインター、HCR仮想リソースのステータス、HSR「シンドローム」レジスタ。ゲスト状態の過剰な読み取り。

前に検討したアーキテクチャで行われたように、2レベルのスキームを使用してアドレス変換メカニズムを高速化します。このメカニズムでは、ゲストOSの物理アドレスは中間です。 外部割り込みは、仮想割り込みメカニズムを使用してゲストにリダイレクトするモニターへの配信と、ゲストシステムへの直接送信の両方のために構成できます。

MIPS

MIPSプロセッサは、ARMで見られる反対の方向、つまり高性能システムから組み込みおよびモバイルへと進化しています。 それにもかかわらず、比較的最近になってハードウェア仮想化が登場し、2012年にMIPS R5アーキテクチャがMIPS VZ仮想化モードをもたらしました[2]。 32ビットバージョンと64ビットバージョンの両方のアーキテクチャで使用できます。

追加されたアーキテクチャの状態により、VMのコンテキストを保存し、個別に監視できます。 たとえば、ハイパーバイザーのニーズに応じて、ゲストコピーとは別にCOP0システムレジストリのコピーが導入されます。 これにより、ゲスト間の切り替え時間を最適化できますが、複数のゲストOS間の切り替えには、メモリからCOP0コンテンツを更新する必要があり、効率が低下します。 さらに、現在のアーキテクチャオプションの機能セットを記述するゲストレジスタビットの一部であり、したがって以前は読み取り専用で使用されていた部分は、モニターモードからの記録に使用できます。これにより、ホストに実際に存在する機能とは異なる機能を宣言できます。

ハイパーバイザー、オペレーティングシステム、およびユーザーの権限は、いわゆる タマネギ（ 英語タマネギ）モデル。 その中で、割り込み処理は外部から内部へ、つまり 最初に、それらのそれぞれがモニターの規則、OSの順守について検査されます。 反対に、同期例外（トラップ）は、最初にOSによって処理され、次にモニターによって処理されます。

前に検討したアーキテクチャで行われていたように、アドレス変換のメカニズムを高速化するために、TLBではタグを使用し、MMUでは2レベルの変換を使用します。 準仮想化ゲストの開発をサポートするために、新しいハイパーコール命令が追加されました。これにより、トラップが発生し、モニターモードに入ります。

追加のトピック

, .

- . , ( . 1), , .

		,
Prescott	3 . 2005	3963
Merom	2 . 2006	1579
Penryn	1 . 2008年	1266
Nehalem	3 . 2009	1009
Westmere	1 . 2010	761
Sandy Bridge	1 . 2011	784

表1異なる世代のインテルIA-32プロセッサのマイクロアーキテクチャのためのモードのハードウェア仮想化の間の遷移の時間（データが[11]から取得され）



、バイナリ解釈又は翻訳などの仮想化を使用して直接実行が無効である場合、それは別の作業回路に切り替えることは理にかなって、 （IDZ :.上の記事の私のシリーズを参照1、2、3）。

実際には、OSの実行は、制御フロートラップを引き起こす命令がクラスターを形成し、それらのクラスターの2つ以上が互いに近接し、クラスター間の距離が大きいという状況によって特徴付けられます。IA-32の次のコードブロックは、このようなクラスターの例を示しています。アスタリスクは、モニターを終了させるすべての命令を示します。

* in %al,%dx * out $0x80,%al mov %al,%cl mov %dl,$0xc0 * out %al,%dx * out $0x80,%al * out %al,%dx * out $0x80,%al
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シナリオの繰り返しを避けるために：VMをモニターに出て、命令を解釈し、次の命令でモニターに再入するためだけにVMに戻ると、命令のプレビューが使用されます[11]。 トラップの処理後、モニターが制御をVMに戻す前に、特権フローを検索するために、命令フローがいくつかの命令を順方向にスキャンします。 それらが検出された場合、シミュレーションはしばらくの間バイナリ変換モードに切り替わります。 これにより、特権命令のクラスタリングによる悪影響を回避できます。

再帰的な仮想化

ハードウェア上で直接実行される別のモニターの制御下で仮想マシンモニターが起動される状況は、再帰的仮想化と呼ばれます。 理論的には、2つのレベルのみに限定されない場合があります。各VMモニター内で以下が実行され、ハイパーバイザーの階層が形成されます。

VMモニター（または同等のシミュレーター）の制御下で1つのハイパーバイザーを実行する機能は実用的な価値があります。 VMモニターはかなり複雑なプログラムであり、アプリケーションやOSをデバッグする通常の方法は適用できません。 デバッガーの接続が困難なシステムのプロセスの非常に早い段階でロードされます。 シミュレーターの制御下で実行すると、最初の命令からその動作を検査および制御できます。

GoldbergとPopekは、以前の研究で、再帰的な仮想化を含む効果的なサポートの問題に対処しました。 ただし、残念ながら、それらの結論は、現代のシステムの上記の機能の多くを考慮していません。

VMモニターの組み込み起動の詳細に関連する困難の1つである、トラップと割り込みの処理を検討してください。 最も単純なケースでは、最も外部のモニターが常にすべてのタイプの例外的な状況の処理を担当します。そのタスクは、イベントを自分で処理し、他のレベルから「隠す」か、次のレベルに渡すことです。

割り込みおよびトラップの場合、これは多くの場合最適ではありません。イベントは階層の複数のレベルを通過する必要があり、各レベルでは処理が遅延します。 図 図5は、外部機器で発生した割り込みと、アプリケーション内で発生した制御フロートラップの2種類のメッセージの処理を示しています。





図 5：再帰的な仮想化。 すべてのイベントは外部モニターによって処理される必要があります。これにより、イベントが階層を下げられ、遅延が生成されます



さまざまなタイプのトラップおよび割り込みの最適な処理のために、VMモニターの階層レベルをそれらのそれぞれに対して選択する必要があります。イベントが発生した場合、制御はこのレベルに直接転送される必要があります。

既存のソリューションでの再帰的な仮想化のサポート

プロセッサメーカーは、第1レベルよりも第2レベル以上の仮想化ネストのハードウェアサポートのタスクにあまり注意を払っていません。 それにもかかわらず、そのような作品は存在します。 したがって、20世紀のIBM / 370システム[13]では、ハードウェアで既に実行されているオペレーティングシステム内でシステムソフトウェアのコピーを実行することができました。 このタスクのために、SIE命令（ 英語の開始解釈実行）が導入されました[14]。 ネストされた仮想化レベル[12]間のインターフェースに関する提案があります。これにより、複数のVMモニターのネストとIA-32 [15]の再帰的仮想化の実装を効果的にサポートできます。 ただし、最新のプロセッサアーキテクチャは、依然として最大1レベルの仮想化のハードウェアサポートに限定されています。

文学

1. Goodacre John。 ARM Cortexプロセッサのハードウェアアクセラレーションによる仮想化。 2011. xen.org/files/xensummit_oul11/nov2/2_XSAsia11_JGoodacre_HW_accelerated_virtualization_in_the_ARM_Cortex_processors.pdf
2. MIPS Virtualization Moduleによるハードウェア支援の仮想化。 2012. www.mips.com/application/login/login.dot?product_name=/auth/MD00994-2B-VZMIPS-WHT-01.00.pdf
3. ハイパーバイザー/ Sun4vの参考資料。 2012. kenai.com/projects/hypervisor/pages/ReferenceMaterials
4. Intel Virtualization Technology / F. Leung、G。Neiger、D。Rodgers et al。 // Intel Technology Journal。 2006. Vol。 10. www.intel.com/technology/itj/2006/v10i3
5. マクガン・ハーラン。 マシンのgHost：パート1 //マイクロプロセッサレポート。 2007. mpronline.com
6. マクガン・ハーラン。 マシンのgHost：パート2 //マイクロプロセッサレポート。 2007. mpronline.com
7. マクガン・ハーラン。 マシンのgHost：パート3 //マイクロプロセッサレポート。 2007. mpronline.com
8. Popek Gerald J.、Goldberg Robert P.仮想化可能な第3世代アーキテクチャの正式な要件// ACMの通信。 巻 17.1974。
9. 南ガブリエル。 SMP VM CPUスケジューリングの分析。 2008. cs.gmu.edu/~hfoxwell/cs671projects/south_v12n.pdf
10. ヤン・ロンジェン。 仮想変換ルックアサイドバッファ。 2008. www.patentlens.net/patentlens/patent/US_2008_0282055_A1/en
11. ハードウェア仮想化の出口を回避するためのソフトウェア技術/ Ole Agesen、Jim Mattson、Radu Rugina、Jeffrey Sheldon //年次技術会議に関する2012 USENIX会議の議事録。 USENIX ATC'12。 米国カリフォルニア州バークレー：USENIX Association、2012。P.35-35。 www.usenix.org/system/files/conference/atc12/atc12-final158.pdf
12. Poon Wing-Chi、Mok AK x86アーキテクチャの再帰的仮想化におけるVM出口転送の遅延の改善//システムサイエンス（HICSS）、2012年第45回ハワイ国際会議。 2012. P. 5604-5612。
13. Osisek DL、Jackson KM、Gum PH ESA / 390解釈実行アーキテクチャ、VM / ESAの基盤// IBM Syst。 J.-1991— V. 30、No. 1 .-- Pp。 34-51。 -ISSN：0018-8670。 —DOI：10.1147 / sj.301.0034。
14. アンディ・グロー。 ほら -semipublic.comp-arch.net/wiki/SIE
15. Turtlesプロジェクト：ネストされた仮想化の設計と実装/ Muli Ben-Yehuda [et al。] //。 -2010。-P. 423–436。 www.usenix.org/event/osdi10/tech/full_papers/Ben-Yehuda.pdf