入れ子になった仮想化

2023-03-18

入れ子になった仮想化とは、ハードウェア仮想化拡張機能をエミュレートする Hyper-V ハイパーバイザーを指します。これらのエミュレートされた拡張機能は、Hyper-V プラットフォームで実行するために、他の仮想化ソフトウェア (入れ子になったハイパーバイザーなど) で使用できます。

この機能は、ゲストパーティションでのみ使用できます。仮想マシンごとに有効にする必要があります。入れ子になった仮想化は、Windows ルートパーティションではサポートされていません。

入れ子になった仮想化のさまざまなレベルを定義するには、次の用語を使用します。

項目	定義
L0 ハイパーバイザー	物理ハードウェアで実行されている Hyper-V ハイパーバイザー。
L1 ルート	Windows ルートオペレーティングシステム。
L1 ゲスト	入れ子になったハイパーバイザーのない Hyper-V 仮想マシン。
L1 ハイパーバイザー	Hyper-V 仮想マシン内で実行されている入れ子になったハイパーバイザー。
L2 ルート	Hyper-V 仮想マシンのコンテキスト内で実行されるルート Windows オペレーティングシステム。
L2 ゲスト	Hyper-V 仮想マシンのコンテキスト内で実行される入れ子になった仮想マシン。

ベアメタルと比較すると、ハイパーバイザーは VM で実行するとパフォーマンスが大幅に低下する可能性があります。 L1 ハイパーバイザーは、L0 ハイパーバイザーによって提供される対応インターフェイスを使用して、Hyper-V VM で実行するように最適化できます。

対応 VMCS (Intel)

Intel プラットフォームでは、仮想化ソフトウェアは仮想マシン制御データ構造 (VMCS) を使用して、仮想化に関連するプロセッサの動作を構成します。 VMCS は、VMPTRLD 命令を使用してアクティブにし、VMREAD および VMWRITE 命令を使用して変更する必要があります。これらの手順は、多くの場合、エミュレートする必要があるため、入れ子になった仮想化の重要なボトルネックになります。

ハイパーバイザーは、ゲスト物理メモリ内のデータ構造を使用して仮想化関連のプロセッサ動作を制御するために使用できる"対応 VMCS" 機能を公開します。このデータ構造は、通常のメモリアクセス命令を使用して変更できるため、L1 ハイパーバイザーが VMREAD または VMWRITE または VMPTRLD 命令を実行する必要はありません。

L1 ハイパーバイザーは、仮想プロセッサ支援ページの対応するフィールドに 1 を書き込むことで、対応する VMCS を使用することを選択できます。 VP アシストページの別のフィールドは、現在アクティブな対応 VMCS を制御します。各対応 VMCS は、サイズが 1 ページ (4 KB) であり、最初はゼロにする必要があります。対応する VMCS をアクティブまたは最新にするために VMPTRLD 命令を実行する必要はありません。

L1 ハイパーバイザーが対応する VMCS を使用して VM エントリを実行すると、VMCS はプロセッサ上でアクティブと見なされます。対応 VMCS は、同時に 1 つのプロセッサでのみアクティブにすることができます。 L1 ハイパーバイザーは、VMCLEAR 命令を実行して、対応する VMCS をアクティブ状態から非アクティブ状態に移行できます。対応する VMCS がアクティブな間の VMREAD または VMWRITE 命令はサポートされていないため、予期しない動作が発生する可能性があります。

HV_VMX_ENLIGHTENED_VMCS構造体は、対応する VMCS のレイアウトを定義します。すべての非合成フィールドは、Intel 物理 VMCS エンコードにマップされます。

クリーンフィールド

L0 ハイパーバイザーは、対応する VMCS の一部をキャッシュすることを選択できます。エンライトされた VMCS クリーンフィールドは、入れ子になった VM エントリのゲストメモリから、対応する VMCS のどの部分を再読み込みするかを制御します。 L1 ハイパーバイザーは、対応する VMCS クリーンフィールドを、対応する VMCS が対応する VMCS を変更するたびにクリアする必要があります。そうしないと、L0 ハイパーバイザーで古いバージョンが使用される可能性があります。

クリーンフィールドのエンライトメントは、対応する VMCS の合成 "CleanFields" フィールドを介して制御されます。既定では、L0 ハイパーバイザーが入れ子になった VM エントリごとに対応する VMCS フィールドを再読み込みする必要が出されるように、すべてのビットが設定されます。

機能の検出

対応する VMCS インターフェイスのサポートは、 CPUID リーフ 0x40000004で報告されます。

対応した VMCS 構造は、将来の変更を考慮してバージョン管理されます。各対応 VMCS 構造体には、L0 ハイパーバイザーによって報告されるバージョンフィールドが含まれています。

現在サポートされている VMCS バージョンは 1 のみです。

ハイパーバイザーの実装に関する考慮事項

ほとんどの VMCS フィールドでは、VMCS フィールドが VM でサポートされている場合、アーキテクチャ機能検出メカニズムによって決定される VM に対応する VMCS フィールドがサポートされます。例外は、CPUID リーフ 0x4000000Aで報告されます。

アーキテクチャ機能検出メカニズムが、対応する VMCS フィールドが定義されていない VMCS フィールドのサポートを示している場合、L1 ハイパーバイザーは、対応された VMCS を使用することを選択した場合、この機能を有効にしないでください。

Hyper-V L0 ハイパーバイザーでは、対応する VMCS フィールドまたは例外が定義されていない VMCS フィールドのサポートは示されません。別の L0 ハイパーバイザーで新しい対応 VMCS フィールドまたは例外を定義する必要がある場合は、Microsoft にお問い合わせください。

Enlighened VMCB フィールド (AMD)

AMD には、ハイパーバイザー用の VMCB 内の予約済み領域と、関連するクリーンビットがあります。予約済みバイトは、VMCB の制御セクション (オフセット 0x3E0-3FF) にあります。クリーンビットはビット 31 です (ハイパーバイザーが VMCB の "エンライトメント" 領域を変更するたびに、クリーンビットを無効にする必要があります)。

Hyper-V では、予約済みの VMCB 領域を利用して、エンライトメントを構成します。 HV_SVM_ENLIGHTENED_VMCB_FIELDS構造では、形式が文書化されます。

対応する MSR ビットマップ

L0 ハイパーバイザーは、Intel プラットフォームと AMD プラットフォームの両方で "MSR-Bitmap" コントロールをエミュレートします。これにより、仮想化ソフトウェアは、どの MSR アクセスがインターセプトを生成するかを制御できます。

L1 ハイパーバイザーは、L0 ハイパーバイザーと連携して、MSR アクセスをより効率的にすることができます。対応する VMCS/VMCB フィールドの対応するフィールドを 1 に設定することで、対応する MSR ビットマップを有効にすることができます。有効にすると、L0 ハイパーバイザーは MSR ビットマップの変更を監視しません。代わりに、L1 ハイパーバイザーは、MSR ビットマップのいずれかに変更を加えた後、対応するクリーンフィールドを無効にする必要があります。

対応する MSR ビットマップのサポートは、 CPUID リーフ 0x4000000Aで報告されます。

ライブマイグレーションとの互換性

Hyper-V には、あるホストから別のホストに子パーティションをライブマイグレーションする機能があります。ライブマイグレーションは通常、子パーティションに対して透過的です。ただし、入れ子になった仮想化の場合は、L1 ハイパーバイザーで移行を認識する必要がある場合があります。

ライブマイグレーション通知

L1 ハイパーバイザーは、パーティションの移行時に通知を要求できます。この機能は、CPUID で "AccessReenlightenmentControls" 特権として列挙されます。 L0 ハイパーバイザーは、L1 ハイパーバイザーが割り込みベクトルとターゲットプロセッサを構成するために使用できる合成 MSR (HV_X64_MSR_REENLIGHTENMENT_CONTROL) を公開します。 L0 ハイパーバイザーは、各移行後に、指定されたベクターで割り込みを挿入します。

#define HV_X64_MSR_REENLIGHTENMENT_CONTROL (0x40000106)

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 Vector :8;
        UINT64 RsvdZ1 :8;
        UINT64 Enabled :1;
        UINT64 RsvdZ2 :15;
        UINT64 TargetVp :32;
    };
} HV_REENLIGHTENMENT_CONTROL;

指定されたベクトルは、固定 APIC 割り込みに対応している必要があります。 TargetVp は、仮想プロセッサインデックスを指定します。

TSC エミュレーション

ゲストパーティションは、TSC 周波数が異なる 2 台のマシン間でライブマイグレーションされる場合があります。このような場合は、参照 TSC ページの TscScale 値を再計算する必要がある場合があります。

L0 ハイパーバイザーは、移行後、L1 ハイパーバイザーが TscScale 値を再計算できるようになるまで、必要に応じてすべての TSC アクセスをエミュレートします。 L1 ハイパーバイザーは、HV_X64_MSR_TSC_EMULATION_CONTROL MSR に書き込むことで TSC エミュレーションをオプトインできます。オプトインすると、L0 ハイパーバイザーは、移行が行われた後に TSC アクセスをエミュレートします。

L1 ハイパーバイザーは、HV_X64_MSR_TSC_EMULATION_STATUS MSR を使用して TSC アクセスが現在エミュレートされているかどうかを照会できます。たとえば、L1 ハイパーバイザーは Live Migration 通知をサブスクライブし、移行割り込みを受信した後に TSC の状態を照会できます。また、この MSR を使用して (TscScale 値を更新した後に) TSC エミュレーションをオフにすることもできます。

#define HV_X64_MSR_TSC_EMULATION_CONTROL (0x40000107)
#define HV_X64_MSR_TSC_EMULATION_STATUS (0x40000108)

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 Enabled :1;
        UINT64 RsvdZ :63;
    };
 } HV_TSC_EMULATION_CONTROL;

typedef union
{
    UINT64 AsUINT64;
    struct
    {
        UINT64 InProgress : 1;
        UINT64 RsvdP1 : 63;
    };
} HV_TSC_EMULATION_STATUS;

仮想 TLB

ハイパーバイザーによって公開される仮想 TLB は、L2 GPO から GPO への変換をキャッシュするように拡張できます。論理プロセッサ上の TLB と同様に、仮想 TLB は非コヒーレントキャッシュであり、この非コヒーレンスはゲストに表示されます。ハイパーバイザーは、TLB を管理する操作を公開します。

直接仮想フラッシュ

ハイパーバイザーはハイパーコール (HvCallFlushVirtualAddressSpace、 HvCallFlushVirtualAddressSpaceEx、 HvCallFlushVirtualAddressList、 HvCallFlushVirtualAddressListEx) を公開し、オペレーティングシステムが仮想 TLB をより効率的に管理できるようにします。 L1 ハイパーバイザーは、ゲストがこれらのハイパーコールを使用できるようにし、L0 ハイパーバイザーに処理する責任を委任することを選択できます。これには、パーティション支援ページ (および Intel プラットフォーム上の仮想 VMCS) を使用する必要があります。

仮想 TLB を使用すると、キャッシュされたすべてのマッピングに、それらを作成した入れ子になったコンテキスト (VMCS または VMCB) の識別子がタグ付けされます。 L2 ゲストからの直接仮想フラッシュハイパーコールに応答して、L0 ハイパーバイザーは入れ子になったコンテキストによって作成されたすべてのキャッシュされたマッピングを無効にします。

VmId は、呼び出し元の VmId と同じです
VpId が指定された ProcessorMask に含まれているか、HV_FLUSH_ALL_PROCESSORSが指定されています

直接仮想フラッシュのサポートは、 CPUID リーフ 0x4000000Aで報告されます。

構成

仮想フラッシュハイパーコールの直接処理は、次の方法で有効になります。

仮想プロセッサアシストページの NestedEnlightenmentsControl.Features.DirectHypercall フィールドを 1 に設定します。
対応する VMCS または VMCB の EnlightenmentsControl.NestedFlushVirtualHypercall フィールドを 1 に設定します。

L1 ハイパーバイザーを有効にする前に、対応する VMCS/VMCB の次の追加フィールドを構成する必要があります。

VpId: 対応する VMCS/VMCB が制御する仮想プロセッサの ID。
VmId: 対応する VMCS/VMCB が属する仮想マシンの ID。
PartitionAssistPage: パーティション支援ページのゲスト物理アドレス。

L1 ハイパーバイザーでは、CPUID を介して次の機能もゲストに公開する必要があります。

UseHypercallForLocalFlush
UseHypercallForRemoteFlush

[パーティションアシスト] ページ

パーティション支援ページは、直接フラッシュハイパーコールを使用する前に L1 ハイパーバイザーが割り当て、ゼロを割り当てる必要があるページサイズのページサイズ領域です。その GPA は、対応する VMCS/VMCB 内の対応するフィールドに書き込む必要があります。

struct
{
    UINT32 TlbLockCount;
} VM_PARTITION_ASSIST_PAGE;

合成VM-Exit

呼び出し元のパーティション支援ページの TlbLockCount が 0 以外の場合、L0 ハイパーバイザーは、直接仮想フラッシュハイパーコールを処理した後、合成終了理由を持つVM-Exitを L1 ハイパーバイザーに配信します。

Intel プラットフォームでは、終了理由 HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH を含むVM-Exitが配信されます。 AMD プラットフォームでは、終了コード HV_SVM_EXITCODE_ENL を含むVM-Exitが配信され、ExitInfo1 がに HV_SVM_ENL_EXITCODE_TRAP_AFTER_FLUSH設定されます。

#define HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH 0x10000031

#define HV_SVM_EXITCODE_ENL 0xF0000000
#define HV_SVM_ENL_EXITCODE_TRAP_AFTER_FLUSH   (1)

Second Level Address Translation

ゲストパーティションに対して入れ子になった仮想化が有効になっている場合、パーティションによって公開されるメモリ管理ユニット (MMU) には、第 2 レベルのアドレス変換のサポートが含まれます。第 2 レベルのアドレス変換は、L1 ハイパーバイザーが物理メモリを仮想化するために使用できる機能です。使用中の場合、ゲスト物理アドレス (GPO) として扱われる特定のアドレスは、L2 ゲスト物理アドレス (L2 GPO) として扱われ、一連のページング構造を走査することによって GPO に変換されます。

L1 ハイパーバイザーは、第 2 レベルのアドレス空間を使用する方法と場所を決定できます。各第 2 レベルのアドレス空間は、ゲスト定義の 64 ビット ID 値によって識別されます。 Intel プラットフォームでは、この値は EPT ポインターと同じです。 AMD プラットフォームでは、値は nCR3 VMCB フィールドと等しくなります。

互換性

ハイパーバイザーによって公開される 2 番目のレベルのアドレス変換機能は、一般に、アドレス変換の VMX または SVM のサポートと互換性があります。ただし、次のゲスト監視可能な違いがあります。

内部的には、ハイパーバイザーは、L2 GPO を SPA に変換するシャドウページテーブルを使用する場合があります。このような実装では、これらのシャドウページテーブルはソフトウェアに大きな TLV として表示されます。ただし、いくつかの違いが観察可能な場合があります。最初に、シャドウページテーブルは 2 つの仮想プロセッサ間で共有できますが、従来の TLV はプロセッサごとの構造であり、独立しています。この共有は、ある仮想プロセッサによるページアクセスが、その後別の仮想プロセッサによって使用されるシャドウページテーブルエントリを埋めることができるため、表示される場合があります。
一部のハイパーバイザー実装では、ゲストページテーブルの内部書き込み保護を使用して、内部データ構造 (シャドウページテーブルなど) から MMU マッピングを遅延フラッシュする場合があります。これらのテーブルへの書き込みはハイパーバイザーによって透過的に処理されるため、これはゲストにはアーキテクチャ上は見えません。ただし、他のパーティションまたはデバイスによって基になる GPA ページに対して実行された書き込みによって、適切な TLB フラッシュがトリガーされない場合があります。
一部のハイパーバイザー実装では、2 番目のレベルのページ障害によってキャッシュされたマッピングが無効にならない場合があります。

対応する第 2 レベルの TLB フラッシュ

ハイパーバイザーでは、ゲストが第 2 レベルの TLB をより効率的に管理できるようにする一連の拡張機能もサポートされています。これらの強化された操作は、従来の TLB 管理操作と同じ意味で使用できます。

ハイパーバイザーでは、TLV を無効にするために、次のハイパーコールがサポートされています。

Hypercall	説明
HvCallFlushGuestPhysicalAddressSpace	は、キャッシュされた L2 GPA から GPA へのマッピングを、2 番目のレベルのアドレス空間内で無効にします。
HvCallFlushGuestPhysicalAddressList	は、キャッシュされた GVA/L2 GPA を、第 2 レベルのアドレス空間の一部内の GPA マッピングに無効にします。

AMD プラットフォームでは、すべての TLB エントリに ASID (アドレス空間識別子) がアーキテクチャ的にタグ付けされます。 ASID を無効にすると、ASID に関連付けられているすべての TLB 全体が無効になります。入れ子になったハイパーバイザーは、必要に応じて、 HV_SVM_ENLIGHTENED_VMCB_FIELDSで EnlightenedNptTlb を "1" に設定することで、"対応 TLB" をオプトインできます。入れ子になったハイパーバイザーがエンライトメントをオプトインした場合、ASID の無効化は、第 1 レベルのアドレス変換 (つまり仮想アドレス空間) から派生した TLB 全体をフラッシュするだけです。入れ子になったページテーブル (NPT) から派生した TLB エントリをフラッシュし、L0 ハイパーバイザーにシャドウページテーブルの再構築を強制するには、HvCallFlushGuestPhysicalAddressSpace または HvCallFlushGuestPhysicalAddressList ハイパーコールを使用する必要があります。