Linuxシステムの仮想化モデルと障害

[[436822]]

x86 CPU仮想化

1974 年の論文「仮想化可能な第 3 世代アーキテクチャの正式な要件」で、Gerald J. Popek と Robert P. Goldberg は仮想化の 3 つの条件を提案しました。

（１）同等性、つまり、VMMは、ホストマシン上で、物理マシンと本質的に同一の仮想マシン環境をシミュレートする必要がある。この環境での仮想マシンの実行は、リソースの競合や VMM の介入により仮想環境でのパフォーマンスに若干の違いが生じる可能性があることを除けば、物理マシンでの実行と変わりません。たとえば、ホストマシンの速度制限や複数の仮想マシンによるリソースの共有により、仮想マシンの I/O やネットワークは、専用の物理マシンよりも遅くなる可能性があります。

（２）高効率、つまり、仮想マシン命令実行のパフォーマンスは、物理マシン上で実行する場合と比べて明らかな損失がありません。この標準では、仮想マシン内のほとんどの命令が VMM の介入なしに物理 CPU 上で直接実行されることが要求されます。たとえば、x86 アーキテクチャ上で Qemu を介して実行する ARM システムは、仮想化ではなく、エミュレーション (エミュレーター) です。

（３）リソース制御、つまりVMMはシステムリソースを完全に制御します。 VMM は各仮想マシンに対してホストマシンリソースを制御および調整しますが、仮想マシンはホストマシンリソースを制御することはできません。

モデルのトラッピングとシミュレーション

Gerald J. Popek と Robert P. Goldberg が提案した仮想化の 3 つの条件を満たすための典型的なソリューションは、Trap and Emulate モデルです。

一般的に、プロセッサはシステムモードとユーザーモードの 2 つの動作モードに分類できます。同様に、CPU 命令も特権命令と非特権命令に分けられます。特権命令はシステムモードでのみ実行できます。特権命令がユーザーモードで実行されると、プロセッサ例外がトリガーされます。カーネルはシステムリソースを管理し、特権命令を実行する必要があるため、オペレーティングシステムはカーネルをシステムモードで実行しますが、通常のユーザープログラムはユーザーモードで実行されます。

仮想化されたシナリオでは、仮想マシンのユーザープログラムは引き続きユーザーモードで実行されますが、仮想マシンのカーネルはユーザーモードで実行されます。この方法はリング圧縮と呼ばれます。このように、仮想マシン内の非特権命令はプロセッサ上で直接実行され、Popek と Goldberg によって提案された仮想化標準の高効率要件を満たします。つまり、ほとんどの命令は VMM の介入なしにプロセッサ上で直接実行されます。ただし、仮想マシンが特権命令を実行する場合、特権命令はユーザーモードで実行されるため、プロセッサ例外がトリガーされ、仮想マシンが VMM にトラップされ、VMM が仮想マシンのエージェントとして機能してシステムリソースへのアクセスを完了します。これがいわゆるエミュレーションです。このようにして、Popek と Goldberg が提案した仮想化標準におけるシステムリソースを制御する VMM の要件が満たされます。仮想マシンは特権命令を直接実行できるため、ホストマシンのリソースを変更せず、ホストマシンの環境に損害を与えることはありません。

x86 アーキテクチャにおける仮想化の障壁

Gerald J. Popek 氏と Robert P. Goldberg 氏は、システムリソースを変更したり、モードによって動作が異なったりする命令はセンシティブな命令であると指摘しました。仮想化シナリオでは、VMM はこれらの機密命令を監視する必要があります。仮想化をサポートするアーキテクチャの機密命令はすべて特権命令です。つまり、これらの機密命令が非特権レベルで実行されると、CPU は例外をスローし、VMM の例外処理機能に入り、VM の機密リソースへのアクセスを制御するという目的を達成します。

ただし、x86 アーキテクチャは、Gerald J. Popek と Robert P. Goldberg によって定義された基準を満たしておらず、すべての機密命令が特権命令であるわけではありません。一部の機密命令は、非特権モードで実行された場合に例外をスローしません。この場合、VMM は VM の動作を傍受したり処理したりすることはできません。 FLAGS レジスタの IF (割り込みフラグ) を変更する場合を例にとると、まず pushfd 命令を使用して FLAGS レジスタの内容をスタックにプッシュし、次にスタックの先頭の IF を 0 にクリアし、最後に popf 命令を使用してスタックから FLAGS レジスタを復元します。仮想マシンカーネルがリング 1 で実行されている場合、x86 CPU は例外をスローせず、単に popfd 命令を無視するため、仮想マシンが IF をオフにする目的は達成されません。

ゲストコードを変更する準仮想化アプローチを提案する人もいますが、これは仮想化の透明性の基準を満たしていません。その後、静的翻訳や動的翻訳などのバイナリ翻訳方式が提案されました。静的変換とは、実行前に実行可能ファイル全体をスキャンし、機密命令を変換して、新しいファイルを再形成することです。静的翻訳には制限があり、事前に処理する必要があります。さらに、一部の命令には、実行時にのみ発生し、静的に処理できない副作用があります。そこで、実行時にコードブロック単位でバイナリコードを動的に変更する動的変換が生まれました。動的変換は多くの VMM で使用されており、最適化の効果は非常に良好です。

VMX 拡張機能

プログラマーは、x86 アーキテクチャの仮想化問題を解決するためにソフトウェアレベルのさまざまなソリューションを採用してきましたが、ソフトウェアレベルのソリューションは追加のオーバーヘッドが発生するだけでなく、VMM の実装に大きな複雑さをもたらします。そこで、Intel はハードウェアレベルからこの問題を解決しようとしました。すべての特権命令がトラップとエミュレートを必要とするわけではないため、Intel はこれらの非特権センシティブ命令を特権命令に変更しませんでした。典型的な例を見てみましょう。オペレーティングシステムカーネルがプロセスを切り替えるたびに、cr3 レジスタが現在実行中のプロセスのページテーブルを指すように切り替えられます。シャドウページテーブルを使用して GVA を HPA にマップする場合、ゲストによる cr3 レジスタの設定の各操作をキャプチャする必要があり、VMM モジュールはそれをシャドウページテーブルにポイントします。ハードウェアレベルの EPT サポートが有効になっている場合、cr3 は引き続きゲストのプロセスページテーブルを指し、cr3 レジスタを設定するゲストの操作をキャプチャする必要はありません。つまり、cr3 レジスタへの書き込みは特権命令ですが、VMM に該当する必要はありません。

Intel は仮想化をサポートするために VT テクノロジーを開発し、VMX と呼ばれる仮想マシン拡張機能を CPU に追加しました。 CPU の VMX サポートが有効になると、CPU は VMX ルートモードと VMX 非ルートモードの 2 つの動作モードを提供します。各モードはring0～ring3をサポートします。 VMM は VMX ルートモードで実行されます。 VMX をサポートすることに加えて、VMX ルートモードと通常モードの間に本質的な違いはありません。 VM は VMX 非ルートモードで実行されます。ゲストはリング圧縮を使用する必要がなくなりました。図 1 に示すように、ゲストカーネルは VMX 非ルートモードの ring0 で直接実行できます。

図1 VMX動作モード

VMX ルートモードの VMM は、CPU によって提供される仮想化命令 VMLaunch を実行することで、VMX 非ルートモードに切り替えることができます。このプロセスはゲスト[3]に入ることと同等であるため、VMエントリと呼ばれることが多い。特定の I/O 操作などの機密命令がゲスト内で実行されると、CPU がトリガーされてトラップされ、VMX 非ルートモードから VMX ルートモードに戻ります。このプロセスは VM を終了することと同じなので、VM 終了とも呼ばれます。 VMM はゲストの操作をシミュレートします。ゲストカーネルをユーザーモード（リング1からリング3）で実行するリング圧縮方式と比較して、VMX拡張機能をサポートするCPU[4]は次のようになります。

（1）ゲストモードで実行している場合、ゲストユーザー空間のシステムコールは、ホストモードカーネル空間ではなく、ゲストモードカーネル空間に直接送られます。

（２）外部割り込みについては、VMMがシステムリソースを制御する必要があるため、ゲストモードのCPUが外部割り込みを受信すると、CPUがゲストモードからホストモードに移行するようにトリガーされ、外部割り込みはホストカーネルによって処理されます。割り込みを処理した後、ゲストモードに戻ります。 I/O 効率を向上させるために、Intel は周辺機器透過モードをサポートしています。このモードでは、ゲストは VM 終了を生成する必要はありません。この特別な方法については、「デバイスの仮想化」の章で説明します。

（3）すべての特権命令がゲストモードCPUでVM終了を引き起こすことはなくなりました。一部の特権命令は VMM の介入を必要としないため、機密命令が実行された場合にのみ、CPU はゲストモードからホストモードに移行します。

CPU が時間内に複数のタスクを実行できるのと同様に、各タスクには独自のコンテキストがあり、スケジューラはスケジュール中にコンテキストを切り替えるため、同じ CPU が複数のタスクを同時に実行できます。 VMX 拡張機能では、同じ物理 CPU が複数の役割を果たし、ホストとゲストをタイムシェアリングモードで実行し、必要に応じて異なるモードを切り替えます。したがって、異なるモードでも独自のコンテキストを保存する必要があります。この目的のために、VMX はコンテキストを保存するためのデータ構造 VMCS を設計しました。各ゲストには VMCS インスタンスがあります。物理 CPU が異なる VMCS をロードすると、図 2 に示すように、異なるゲストが実行されます。

図2 複数のゲストの切り替え

VMCS は主に 2 種類のデータを保存します。1 つはホストとゲストを含むステータスであり、もう 1 つは実行時にゲストを制御する動作です。

（１）ゲスト状態領域：仮想マシンの状態を保存する領域。 VM 終了が発生すると、ゲストの状態がこの領域に保存されます。 VM エントリが発生すると、これらの状態が CPU にロードされます。これらはすべてハードウェアレベルでの自動動作であり、VMM ではコーディングの介入は必要ありません。

（２）ホスト状態領域：ホスト状態を格納する領域。 VM 終了が発生すると、CPU はこれらの状態を VMCS から物理 CPU に自動的にロードします。 VM エントリが発生すると、CPU は自動的に状態をこの領域に保存します。

（３）VM終了情報フィールド仮想マシンで VM 終了が発生した場合、VMM は VM 終了の原因を認識して、適切な解決策を指示し、対応するシミュレーション操作を実行する必要があります。このため、CPU は VMM が使用できるように、ゲスト終了の理由をこの領域に自動的に保存します。

（４）VM実行制御フィールドこの領域のさまざまなフィールドは、ゲストランタイムが cr3 にアクセスしたときに VM 終了をトリガーするかどうかの設定など、仮想マシンランタイムのいくつかの動作を制御します。 VM のエントリと終了の動作を制御する VM エントリ制御フィールドと VM 終了制御フィールド。詳細を一つ一つ列挙することはしません。必要に応じて、読者は Intel のマニュアルを参照できます。

VCPU を作成すると、KVM モジュールは各 VCPU の VMCS を申請します。 CPU がゲストモードに切り替える準備ができるたびに、その VMCS ポインターは、切り替えるゲストに対応する VMCS インスタンスを指すように設定されます。

コミット6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
 [PATCH] kvm: ユーザー空間インターフェース
linux.git/drivers/kvm/vmx.c
静的構造体 kvm_vcpu *vmx_vcpu_load(構造体 kvm_vcpu *vcpu)
 {
    u64phys_addr = __pa(vcpu->vmcs);
 CPUの整数; 
  
    CPU を get_cpu() で取得します。
    …
    if(per_cpu(current_vmcs, cpu) != vcpu->vmcs) {
        …
       per_cpu(current_vmcs, cpu) = vcpu->vmcs;
        asmvolatile (ASM_VMX_VMPTRLD_RAX "; %0 を設定"  
                 : "=g" (エラー) : "a" (&phys_addr)、 "m" (phys_addr)
                 : "cc" );
        …
    }
    …
 }

すべての状態が CPU によって自動的に保存および復元されるわけではないので、効率性も考慮する必要があります。 cr2 レジスタを例にとると、ほとんどの場合、ホストはゲストが退出する時点からホストがゲストに再び入る時点まで cr2 レジスタの値を変更せず、cr2 の書き込みのオーバーヘッドは小さくありません。 cr2 が VM エントリごとに 1 回更新されると、CPU 命令サイクルが無駄になる以外は意味がありません。したがって、これらの状態を VMM に渡してソフトウェアで制御する方が適切です。

VCPU ライフサイクル

VMM は、各仮想プロセッサ (VCPU) に対して、スレッドを使用して VCPU エンティティを表します。ゲストの動作中、各 VCPU は基本的に図 1-3 に示す状態間を継続的に切り替わります。

図3 VCPUライフサイクル

ユーザー空間の準備ができたら、VCPU が配置されているスレッドはカーネル内の KVM モジュールに対して ioctl 要求 KVM_RUN を開始し、ユーザー空間の操作が完了し、ゲストモードに切り替えてゲストを実行できることをカーネル内の KVM モジュールに通知します。

カーネル状態に入った後、KVM モジュールは CPU によって提供される仮想化命令を呼び出してゲストモードに切り替えます。ゲストを初めて実行する場合は VMLaunch コマンドを使用し、それ以外の場合は VMResume コマンドを使用します。この切り替え処理では、まず、CPU ステータス、つまりホストステータスが、VMCS 内のホストステータスを格納する領域に保存されます。 CPU によって自動的に保存されないステータスは、KVM 自体によって保存されます。そして、VMCS に保存されたゲストの状態を物理 CPU にロードし、CPU によって自動的に復元されない状態を KVM 自体によって復元します。

物理 CPU はゲストモードに切り替わり、ゲスト命令を実行します。ゲスト命令の実行中に機密命令に遭遇すると、CPU はゲストモードからホストモードのリング 0 に戻り、ホストカーネルの KVM モジュールに入ります。この切り替え処理では、まず CPU の状態、つまりゲスト状態が VMCS 内のゲスト状態を格納する領域に保存され、次に VMCS に格納されているホスト状態が物理 CPU にロードされます。同様に、CPU によって自動的に保存されない状態は、KVM モジュール自体によって保存されます。

カーネル状態の KVM モジュールは、VMCS から仮想マシンの終了理由を読み取り、カーネル内で処理しようとします。カーネルが処理できる場合、仮想マシンはホストモードのユーザーモードに切り替える必要はありません。処理後は、ゲストモードに直接すばやく切り替えることができます。このタイプの終了は、軽量仮想マシン終了とも呼ばれます。

カーネル状態の KVM モジュールが仮想マシンの終了を処理できない場合、VCPU はホストのカーネル状態からホストのユーザー状態への別のコンテキストスイッチを実行し、これは VMM のユーザー空間部分によって処理されます。 VMM ユーザー空間は処理を完了すると、再度ゲストモードに切り替える指示を発行します。このプロセスは、仮想マシンの操作全体を通じて繰り返されます。

以下は、カーネル空間からゲストに入る、またはゲストから出るコードです。

コミット6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
 [PATCH] kvm: ユーザー空間インターフェース
linux.git/drivers/kvm/vmx.c
静的  int vmx_vcpu_run(構造体 kvm_vcpu *vcpu, …)
 {
 u8 失敗;
    u16fs_sel、gs_sel、ldt_sel;
    intfs_gs_ldt_reload_needed; 
  
また：
    …
 /*ゲストモードに入る*/
 "jne が起動しました \n\t"  
       ASM_VMX_VMLAUNCH "\n\t"  
 "jmp kvm_vmx_return \n\t"  
 "起動しました: " ASM_VMX_VMRESUME "\n\t"  
 ".globl kvm_vmx_return \n\t"  
 「kvm_vmx_return:」  
        /*ゲストレジスタを保存し、ホストレジスタをロードし、フラグを保持します */
    …
 if(kvm_handle_exit(kvm_run, vcpu)) {
            …
もう一度行きます。
        }
    }
 0を返します。
 }

ゲストを終了するとき、KVM モジュールは最初に関数 kvm_handle_exit を呼び出して、カーネル空間でゲストの終了を処理しようとします。関数 kvm_handle_exit には、仮想マシンの終了がカーネル空間で正常に処理できる場合、または外部割り込みなどの他の干渉により仮想マシンが終了し、ホストユーザー空間に切り替える必要がない場合は 1 を返すという規則があります。それ以外の場合は 0 を返し、KVM ユーザー空間のシミュレートされたデバイスに周辺機器の要求を処理するように要求するなど、KVM のユーザー空間部分に仮想マシンの終了を処理するように要求する必要があることを示します。

カーネル空間が仮想マシンの終了を正常に処理すると、関数 kvm_handle_exit は 1 を返します。上記のコードは再びラベルに直接ジャンプし、その後プログラムフローが再びゲストに切り替わることがわかります。このタイプの VM 終了は、軽量 VM 終了と呼ばれます。関数 kvm_handle_exit が 0 を返す場合、関数 vmx_vcpu_run は実行を終了し、CPU はカーネル空間からユーザー空間に戻ります。 kvmtool を例にとると、関連するコードスニペットは次のようになります。

コミット8d20223edc81c6b199842b36fcd5b0aa1b8d3456
 KVM_EXIT_IOの詳細をダンプする
kvmtool.git/kvm.c
 int main( int argc, char *argv[])
 {
    …
のために（;;）{
       kvm__run() メソッドは、次のコードで実行されます。 
  
 スイッチ (kvm->kvm_run->exit_reason) {
        ケースKVM_EXIT_IO:
        …
    }
    …
 }

コードによると、kvmtool がゲストに入るために開始するコードは、無限の for ループになっています。 KVM カーネル空間からユーザー空間に戻った後、kvmtool はシミュレートされたデバイスを呼び出して I/O 要求を処理するなど、ユーザー空間でゲストの要求を処理します。ゲストの要求を処理した後、次の for ループに再度入り、kvmtool は KVM モジュールにゲストへの接続を再度要求します。

王百生氏は、中国科学院ソフトウェア研究所、Hongqi Linux、Baidu で勤務した上級技術専門家です。彼は現在、Baiduのチーフアーキテクトを務めている。長年にわたり、オペレーティングシステム、仮想化技術、分散システム、クラウドコンピューティング、自動運転などの関連分野に携わり、豊富な実務経験を持っています。彼はベストセラー書籍『Deep Exploration of Linux Operating System』（2013 年出版）の著者です。

Xie Guangjun は博士です。南開大学コンピュータサイエンス学部を卒業し、コンピュータサイエンスの博士号を取得しました。 IT 業界で長年の経験を持つ上級技術専門家。現在、Baidu Smart Cloudの副ゼネラルマネージャーを務め、クラウドコンピューティング関連製品の研究開発を担当しています。長年にわたり、オペレーティングシステム、仮想化技術、分散システム、ビッグデータ、クラウドコンピューティングなどの関連分野の研究開発に従事し、豊富な実務経験を持っています。

この記事の内容は「Linux 仮想化技術の徹底調査」から抜粋したもので、華張機械工業出版社の許可を受けています。

この記事はWeChatの公開アカウント「Linux Reading Field」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Linux Reading Field 公式アカウントまでご連絡ください。

<<: Javaロックから分散ロックへ

>>: クラウドネイティブ CI/CD フレームワーク Tekton を中国で導入する方法