Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Virtualisasi berlapis mengacu pada Hyper-V hypervisor yang meniru ekstensi virtualisasi perangkat keras. Ekstensi yang ditimulasi ini dapat digunakan oleh perangkat lunak virtualisasi lainnya (misalnya hypervisor berlapis) untuk dijalankan pada platform Hyper-V.
Kemampuan ini hanya tersedia untuk partisi tamu. Ini harus diaktifkan per komputer virtual. Virtualisasi berlapis tidak didukung dalam partisi akar Windows.
Terminologi berikut digunakan untuk menentukan berbagai tingkat virtualisasi berlapis:
| Istilah | Definition |
|---|---|
| L0 Hypervisor | Hypervisor Hyper-V berjalan pada perangkat keras fisik. |
| L1 Root | Sistem operasi root Windows. |
| L1 Tamu | Komputer virtual Hyper-V tanpa hypervisor berlapis. |
| L1 Hypervisor | Hypervisor berlapis yang berjalan dalam komputer virtual Hyper-V. |
| L2 Root | Sistem operasi Windows root, berjalan dalam konteks komputer virtual Hyper-V. |
| L2 Tamu | Komputer virtual berlapis, berjalan dalam konteks komputer virtual Hyper-V. |
Dibandingkan dengan bare-metal, hypervisor dapat menimbulkan regresi performa yang signifikan saat berjalan di VM. Hypervisor L1 dapat dioptimalkan untuk dijalankan dalam VM Hyper-V dengan menggunakan antarmuka tercerahkan yang disediakan oleh hypervisor L0.
Kemampuan ini saat ini hanya didukung pada x64.
Enlightened VMCS (Intel)
Pada platform Intel, perangkat lunak virtualisasi menggunakan struktur data kontrol komputer virtual (VMCS) untuk mengonfigurasi perilaku prosesor yang terkait dengan virtualisasi. VMCS harus dibuat aktif menggunakan instruksi VMPTRLD dan dimodifikasi menggunakan instruksi VMREAD dan VMWRITE. Instruksi ini sering menjadi hambatan yang signifikan untuk virtualisasi berlapis karena harus ditiru.
Hypervisor mengekspos fitur "VMCS tercerahkan" yang dapat digunakan untuk mengontrol perilaku prosesor terkait virtualisasi menggunakan struktur data dalam memori fisik tamu. Struktur data ini dapat dimodifikasi menggunakan instruksi akses memori normal, sehingga tidak perlu hypervisor L1 untuk menjalankan instruksi VMREAD atau VMWRITE atau VMPTRLD.
Hypervisor L1 dapat memilih untuk menggunakan VMCS tercerahkan dengan menulis 1 ke bidang yang sesuai di Halaman Bantuan Prosesor Virtual. Bidang lain di halaman bantuan VP mengontrol VMCS yang saat ini aktif tercerahkan. Setiap VMCS yang dicerahkan berukuran persis satu halaman (4 KB) dan awalnya harus di-zero. Tidak ada instruksi VMPTRLD yang harus dijalankan untuk membuat VMCS yang tercerahkan aktif atau saat ini.
Setelah hypervisor L1 melakukan entri VM dengan VMCS yang tercerahkan, VMCS dianggap aktif pada prosesor. VMCS yang tercerahkan hanya dapat aktif pada satu prosesor secara bersamaan. Hypervisor L1 dapat menjalankan instruksi VMCLEAR untuk transisi VMCS yang tercerahkan dari status aktif ke non-aktif. Setiap instruksi VMREAD atau VMWRITE saat VMCS yang dicerahkan aktif tidak didukung dan dapat mengakibatkan perilaku yang tidak terduga.
Struktur HV_VMX_ENLIGHTENED_VMCS mendefinisikan tata letak VMCS yang dicerahkan. Semua bidang non-sintetis memetakan ke pengodean VMCS fisik Intel.
Bersihkan Bidang
Hypervisor L0 dapat memilih untuk menyimpan bagian dari VMCS yang tercerahkan. Bidang bersih VMCS yang tercerahkan mengontrol bagian mana dari VMCS tercerahkan yang dimuat ulang dari memori tamu pada entri VM berlapis. Hypervisor L1 harus menghapus bidang bersih VMCS yang sesuai setiap kali memodifikasi VMCS yang tercerahkan, jika tidak, hypervisor L0 mungkin menggunakan versi basi.
Pencerahan bidang bersih dikendalikan melalui bidang "CleanFields" sintetis dari VMCS yang tercerahkan. Secara default, semua bit diatur sedih sehingga hypervisor L0 harus memuat ulang bidang VMCS yang sesuai untuk setiap entri VM berlapis.
Penemuan Fitur
Dukungan untuk antarmuka VMCS yang tercerahkan dilaporkan dengan 0x40000004 daun CPUID.
Struktur VMCS yang dicerahkan diberi versi untuk memperhitungkan perubahan di masa mendatang. Setiap struktur VMCS yang dicerahkan berisi bidang versi, yang dilaporkan oleh hypervisor L0.
Satu-satunya versi VMCS yang saat ini didukung adalah 1.
Pertimbangan Implementasi Hypervisor
Untuk sebagian besar bidang VMCS, bidang VMCS tercerahkan yang sesuai didukung untuk VM jika bidang VMCS didukung untuk VM, seperti yang ditentukan melalui mekanisme penemuan fitur arsitektur. Pengecualian dilaporkan dalam 0x4000000A daun CPUID.
Dalam kasus di mana mekanisme penemuan fitur arsitektur menunjukkan dukungan untuk bidang VMCS yang tidak ada bidang VMCS yang tercerahkan didefinisikan, hypervisor L1 tidak boleh mengaktifkan fitur jika memilih untuk menggunakan VMCS yang tercerahkan.
Hypervisor Hyper-V L0 tidak akan menunjukkan dukungan untuk bidang VMCS yang tidak ada bidang atau pengecualian VMCS yang tercerahkan didefinisikan. Jika hypervisor L0 lain memerlukan bidang atau pengecualian VMCS baru yang tercerahkan untuk ditentukan, silakan hubungi Microsoft.
Bidang VMCB enlighened (AMD)
AMD memiliki ruang cadangan di VMCB untuk penggunaan hypervisor, serta bit bersih terkait. Byte yang dipesan berada di bagian kontrol, offset 0x3E0-3FF, dari VMCB. Bit bersih adalah bit 31 (bit bersih harus dibatalkan setiap kali hypervisor memodifikasi area "pencerahan" dari VMCB).
Hyper-V menggunakan area VMCB yang dipesan untuk mengonfigurasi pencerahan. HV_SVM_ENLIGHTENED_VMCB_FIELDS menyusun dokumen format.
Bitmap MSR Tercerahkan
Hypervisor L0 menimulasi kontrol "MSR-Bitmap" pada platform Intel dan AMD yang memungkinkan perangkat lunak virtualisasi mengontrol akses MSR mana yang menghasilkan intersepsi.
Hypervisor L1 dapat berkolaborasi dengan hypervisor L0 untuk membuat akses MSR lebih efisien. Ini dapat mengaktifkan bitmap MSR tercerahkan dengan mengatur bidang yang sesuai di bidang VMCS / VMCB tercerahkan ke 1. Saat diaktifkan, hypervisor L0 tidak memantau bitmap MSR untuk perubahan. Sebaliknya, hypervisor L1 harus membatalkan bidang bersih yang sesuai setelah membuat perubahan pada salah satu bitmap MSR.
Dukungan untuk bitmap MSR tercerahkan dilaporkan dalam 0x4000000A daun CPUID.
Kompatibilitas dengan Migrasi Langsung
Hyper-V memiliki kemampuan untuk hidup memigrasikan partisi anak dari satu host ke host lain. Migrasi langsung biasanya transparan untuk partisi anak. Namun, dalam kasus virtualisasi berlapis, hypervisor L1 mungkin perlu menyadari migrasi.
Pemberitahuan Migrasi Langsung
Hypervisor L1 dapat meminta untuk diberi tahu ketika partisinya dimigrasikan. Kemampuan ini dijumlahkan dalam CPUID sebagai hak istimewa "AccessReenlightenmentControls". Hypervisor L0 mengekspos MSR sintetis (HV_X64_MSR_REENLIGHTENMENT_CONTROL) yang dapat digunakan oleh hypervisor L1 untuk mengonfigurasi vektor interupsi dan prosesor target. Hypervisor L0 akan menyuntikkan gangguan dengan vektor yang ditentukan setelah setiap migrasi.
#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;
Vektor yang ditentukan harus sesuai dengan gangguan APIC tetap. TargetVp menentukan indeks prosesor virtual.
Emulasi TSC
Partisi tamu dapat dimigrasikan secara langsung antara dua mesin dengan frekuensi TSC yang berbeda. Dalam kasus tersebut, nilai TscScale dari halaman TSC referensi mungkin perlu dikomputasi ulang.
Hypervisor L0 secara opsional meniru semua akses TSC setelah migrasi hingga hypervisor L1 memiliki kesempatan untuk mengolah ulang nilai TscScale. Hypervisor L1 dapat memilih Emulasi TSC dengan menulis ke HV_X64_MSR_TSC_EMULATION_CONTROL MSR. Jika ikut serta, hypervisor L0 meniru akses TSC setelah migrasi berlangsung.
Hypervisor L1 dapat mengkueri jika akses TSC saat ini sedang ditiru menggunakan HV_X64_MSR_TSC_EMULATION_STATUS MSR. Misalnya, hypervisor L1 dapat berlangganan pemberitahuan Migrasi Langsung dan mengkueri status TSC setelah menerima gangguan migrasi. Ini juga dapat menonaktifkan emulasi TSC (setelah memperbarui nilai TscScale) menggunakan MSR ini.
#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;
Virtual TLB
TLB virtual yang diekspos oleh hypervisor dapat diperluas ke terjemahan cache dari GPU L2 ke GPU. Seperti halnya TLB pada prosesor logis, TLB virtual adalah cache yang tidak koheren, dan non-koherensi ini terlihat oleh tamu. Hypervisor mengekspos operasi untuk mengelola TLB.
Flush Virtual Langsung
Hypervisor mengekspos hypercalls (HvCallFlushVirtualAddressSpace, HvCallFlushVirtualAddressSpaceEx, HvCallFlushVirtualAddressList, dan HvCallFlushVirtualAddressListEx) yang memungkinkan sistem operasi mengelola TLB virtual secara lebih efisien. Hypervisor L1 dapat memilih untuk memungkinkan tamunya menggunakan hypercalls tersebut dan mendelegasikan tanggung jawab menanganinya ke hypervisor L0. Ini memerlukan penggunaan halaman bantuan partisi (dan VMCS virtual pada platform Intel).
Saat digunakan, TLB virtual menandai semua pemetaan cache dengan pengidentifikasi konteks berlapis (VMCS atau VMCB) yang membuatnya. Sebagai respons terhadap hypercall flush virtual langsung dari tamu L2, hypervisor L0 membatalkan semua pemetaan cache yang dibuat oleh konteks berlapis di mana
- VmId sama dengan VmId penelepon
- VpId terkandung dalam ProcessorMask atau HV_FLUSH_ALL_PROCESSORS yang ditentukan
Dukungan untuk flush virtual langsung dilaporkan dalam 0x4000000A daun CPUID.
Konfigurasi
Penanganan langsung hypercalls flush virtual diaktifkan oleh:
- Mengatur bidang NestedEnlightenmentsControl.Features.DirectHypercall dari Halaman Bantuan Prosesor Virtual ke 1.
- Mengatur bidang EnlightenmentsControl.NestedFlushVirtualHypercall dari VMCS atau VMCB yang tercerahkan ke 1.
Sebelum mengaktifkannya, hypervisor L1 harus mengonfigurasi bidang tambahan berikut dari VMCS / VMCB yang tercerahkan:
- VpId: ID prosesor virtual yang dicerahkan kontrol VMCS / VMCB.
- VmId: ID komputer virtual tempat VMCS / VMCB tercerahkan berada.
- PartitionAssistPage: Alamat fisik tamu halaman bantuan partisi.
Hypervisor L1 juga harus mengekspos kemampuan berikut kepada tamunya melalui CPUID.
- GunakanHypercallForLocalFlush
- GunakanHypercallForRemoteFlush
Halaman Bantuan Partisi
Halaman bantuan partisi adalah wilayah ukuran halaman yang selaras dengan ukuran halaman memori yang harus dialokasikan oleh hypervisor L1 dan nol sebelum hypercall flush langsung dapat digunakan. GPA-nya harus ditulis ke bidang yang sesuai di VMCS / VMCB yang tercerahkan.
struct
{
UINT32 TlbLockCount;
} VM_PARTITION_ASSIST_PAGE;
VM-Exit sintetis
Jika TlbLockCount dari halaman bantuan partisi pemanggil bukan nol, hypervisor L0 memberikan VM-Exit dengan alasan keluar sintetis ke hypervisor L1 setelah menangani hypercall flush virtual langsung.
Pada platform Intel, VM-Exit dengan alasan HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH keluar dikirimkan. Pada platform AMD, VM-Exit dengan kode HV_SVM_EXITCODE_ENL keluar dikirimkan dan ExitInfo1 diatur ke 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)
Terjemahan Alamat Tingkat Kedua
Ketika virtualisasi berlapis diaktifkan untuk partisi tamu, unit manajemen memori (MMU) yang diekspos oleh partisi menyertakan dukungan untuk terjemahan alamat tingkat kedua. Terjemahan alamat tingkat kedua adalah kemampuan yang dapat digunakan oleh hypervisor L1 untuk memvirtualisasikan memori fisik. Saat digunakan, alamat tertentu yang akan diperlakukan sebagai alamat fisik tamu (GPA) diperlakukan sebagai alamat fisik tamu L2 (GPU L2) dan diterjemahkan ke GPU dengan melintasi serangkaian struktur penomoran halaman.
Hypervisor L1 dapat memutuskan bagaimana dan di mana menggunakan ruang alamat tingkat kedua. Setiap ruang alamat tingkat kedua diidentifikasi oleh nilai ID 64-bit yang ditentukan tamu. Pada platform Intel, nilai ini sama dengan penunjuk EPT. Pada platform AMD, nilainya sama dengan bidang VMCB nCR3.
Compatibility
Kemampuan terjemahan alamat tingkat kedua yang diekspos oleh hypervisor umumnya kompatibel dengan dukungan VMX atau SVM untuk terjemahan alamat. Namun, perbedaan yang dapat diamati tamu berikut ada:
- Secara internal, hypervisor dapat menggunakan tabel halaman bayangan yang menerjemahkan GPU L2 ke SPAs. Dalam implementasi seperti itu, tabel halaman bayangan ini tampaknya perangkat lunak sebagai TLB besar. Namun, beberapa perbedaan mungkin dapat diamati. Pertama, tabel halaman bayangan dapat dibagikan antara dua prosesor virtual, sedangkan TLB tradisional adalah struktur per prosesor dan independen. Berbagi ini mungkin terlihat karena akses halaman oleh satu prosesor virtual dapat mengisi entri tabel halaman bayangan yang kemudian digunakan oleh prosesor virtual lain.
- Beberapa implementasi hypervisor dapat menggunakan perlindungan tulis internal tabel halaman tamu untuk membersihkan pemetaan MMU dengan malas dari struktur data internal (misalnya, tabel halaman bayangan). Ini secara arsitektur tidak terlihat oleh tamu karena penulisan ke tabel ini akan ditangani secara transparan oleh hypervisor. Namun, penulisan yang dilakukan ke halaman GPA yang mendasar oleh partisi lain atau oleh perangkat mungkin tidak memicu flush TLB yang sesuai.
- Pada beberapa implementasi hypervisor, kesalahan halaman tingkat kedua mungkin tidak membatalkan pemetaan cache.
Flush TLB Tingkat Kedua yang Tercerahkan
Hypervisor juga mendukung serangkaian peningkatan yang memungkinkan tamu mengelola TLB tingkat kedua dengan lebih efisien. Operasi yang ditingkatkan ini dapat digunakan secara bergantian dengan operasi manajemen TLB warisan.
Hypervisor mendukung hypercalls berikut untuk membatalkan TLB:
| Hypercall | Description |
|---|---|
| HvCallFlushGuestPhysicalAddressSpace | membatalkan cache IPK L2 ke pemetaan IPK dalam ruang alamat tingkat kedua. |
| HvCallFlushGuestPhysicalAddressList | membatalkan pemetaan GVA/L2 GVA/L2 yang di-cache ke PEMETAAN IPK dalam sebagian ruang alamat tingkat kedua. |
Pada platform AMD, semua entri TLB secara arsitektur ditandai dengan ASID (pengidentifikasi ruang alamat). Pembatalan ASID menyebabkan semua seluruh TLB yang terkait dengan ASID tidak valid. Hypervisor berlapis secara opsional dapat memilih "TLB yang tercerahkan" dengan mengatur EnlightenedNptTlb ke "1" di HV_SVM_ENLIGHTENED_VMCB_FIELDS. Jika hypervisor berlapis memilih pencerahan, invalidasi ASID hanya membersihkan seluruh TLB yang berasal dari terjemahan alamat tingkat pertama (yaitu ruang alamat virtual). Untuk membersihkan entri TLB yang berasal dari tabel halaman berlapis (NPT) dan memaksa hypervisor L0 untuk membangun kembali tabel halaman bayangan, hypercalls HvCallFlushGuestPhysicalAddressSpace atau HvCallFlushGuestPhysicalAddressList harus digunakan.
Pengecualian Virtualisasi Berlapis
Pada platform Intel. hypervisor L1 dapat memilih untuk menggabungkan pengecualian virtualisasi di kelas pengecualian kesalahan halaman. Hypervisor L0 mengiklankan dukungan untuk pencerahan ini dalam daun CPUID Fitur Virtualisasi Berlapis Hypervisor.
Pencerahan ini dapat diaktifkan dengan mengatur VirtualizationException ke "1" dalam struktur data HV_NESTED_ENLIGHTENMENTS_CONTROL di Halaman Bantuan Prosesor Virtual.
MSR Virtualisasi Berlapis
Daftar Indeks VP Berlapis
Hypervisor L1 mengekspos MSR yang melaporkan indeks VP yang mendasar prosesor saat ini.
| Alamat MSR | Daftarkan Nama | Description |
|---|---|---|
| 0x40001002 | HV_X64_MSR_NESTED_VP_INDEX | Dalam partisi akar berlapis, melaporkan indeks VP prosesor yang mendasar saat ini. |
MSR SynIC Berlapis
Dalam partisi akar berlapis, MSR berikut memungkinkan akses ke daftar SynIC yang sesuai dari hypervisor dasar.
Untuk menemukan indeks prosesor yang mendasar, penelepon harus terlebih dahulu menggunakan HV_X64_MSR_NESTED_VP_INDEX.
| Alamat MSR | Daftarkan Nama | MSR yang mendasar |
|---|---|---|
| 0x40001080 | HV_X64_MSR_NESTED_SCONTROL | HV_X64_MSR_SCONTROL |
| 0x40001081 | HV_X64_MSR_NESTED_SVERSION | HV_X64_MSR_SVERSION |
| 0x40001082 | HV_X64_MSR_NESTED_SIEFP | HV_X64_MSR_SIEFP |
| 0x40001083 | HV_X64_MSR_NESTED_SIMP | HV_X64_MSR_SIMP |
| 0x40001084 | HV_X64_MSR_NESTED_EOM | HV_X64_MSR_EOM |
| 0x40001090 | HV_X64_MSR_NESTED_SINT0 | HV_X64_MSR_SINT0 |
| 0x40001091 | HV_X64_MSR_NESTED_SINT1 | HV_X64_MSR_SINT1 |
| 0x40001092 | HV_X64_MSR_NESTED_SINT2 | HV_X64_MSR_SINT2 |
| 0x40001093 | HV_X64_MSR_NESTED_SINT3 | HV_X64_MSR_SINT3 |
| 0x40001094 | HV_X64_MSR_NESTED_SINT4 | HV_X64_MSR_SINT4 |
| 0x40001095 | HV_X64_MSR_NESTED_SINT5 | HV_X64_MSR_SINT5 |
| 0x40001096 | HV_X64_MSR_NESTED_SINT6 | HV_X64_MSR_SINT6 |
| 0x40001097 | HV_X64_MSR_NESTED_SINT7 | HV_X64_MSR_SINT7 |
| 0x40001098 | HV_X64_MSR_NESTED_SINT8 | HV_X64_MSR_SINT8 |
| 0x40001099 | HV_X64_MSR_NESTED_SINT9 | HV_X64_MSR_SINT9 |
| 0x4000109A | HV_X64_MSR_NESTED_SINT10 | HV_X64_MSR_SINT10 |
| 0x4000109B | HV_X64_MSR_NESTED_SINT11 | HV_X64_MSR_SINT11 |
| 0x4000109C | HV_X64_MSR_NESTED_SINT12 | HV_X64_MSR_SINT12 |
| 0x4000109D | HV_X64_MSR_NESTED_SINT13 | HV_X64_MSR_SINT13 |
| 0x4000109E | HV_X64_MSR_NESTED_SINT14 | HV_X64_MSR_SINT14 |
| 0x4000109F | HV_X64_MSR_NESTED_SINT15 | HV_X64_MSR_SINT15 |