Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Wirtualizacja zagnieżdżona odnosi się do Hyper-V funkcji hypervisor emulujących rozszerzenia wirtualizacji sprzętu. Te emulowane rozszerzenia mogą być używane przez inne oprogramowanie wirtualizacji (np. zagnieżdżone funkcje hypervisor) do uruchamiania na platformie Hyper-V.
Ta funkcja jest dostępna tylko dla partycji gościa. Musi być włączona na maszynę wirtualną. Wirtualizacja zagnieżdżona nie jest obsługiwana w partycji głównej systemu Windows.
Poniższa terminologia służy do definiowania różnych poziomów wirtualizacji zagnieżdżonej:
| Termin | Definition |
|---|---|
| L0 Hypervisor | Funkcja hypervisor Hyper-V uruchomiona na sprzęcie fizycznym. |
| Katalog główny L1 | Główny system operacyjny Windows. |
| Gość L1 | Maszyna wirtualna Hyper-V bez zagnieżdżonej funkcji hypervisor. |
| L1 Hypervisor | Zagnieżdżona funkcja hypervisor uruchomiona na maszynie wirtualnej Hyper-V. |
| Katalog główny L2 | Główny system operacyjny Windows działający w kontekście maszyny wirtualnej Hyper-V. |
| Gość L2 | Zagnieżdżona maszyna wirtualna uruchomiona w kontekście Hyper-V maszyny wirtualnej. |
W porównaniu z bez systemu operacyjnego funkcja hypervisor może spowodować znaczną regresję wydajności podczas uruchamiania na maszynie wirtualnej. Funkcje hypervisor L1 można zoptymalizować pod kątem uruchamiania na maszynie wirtualnej Hyper-V przy użyciu interfejsów obsługujących funkcję hypervisor L0.
Ta funkcja jest obecnie obsługiwana tylko w wersji x64.
Enlightened VMCS (Intel)
Na platformach Intel oprogramowanie wirtualizacji używa struktur danych kontroli maszyn wirtualnych (VMCS) do konfigurowania zachowania procesora związanego z wirtualizacją. Maszyny wirtualne muszą być aktywne przy użyciu instrukcji VMPTRLD i modyfikowane przy użyciu instrukcji VMREAD i VMWRITE. Te instrukcje są często istotnym wąskim gardłem wirtualizacji zagnieżdżonej, ponieważ muszą być emulowane.
Funkcja hypervisor uwidacznia funkcję "oświeconej maszyny wirtualnej VMCS", która może służyć do kontrolowania zachowania procesora związanego z wirtualizacją przy użyciu struktury danych w pamięci fizycznej gościa. Tę strukturę danych można zmodyfikować przy użyciu normalnych instrukcji dostępu do pamięci, dlatego nie ma potrzeby, aby funkcja hypervisor L1 wykonywała instrukcje VMREAD lub VMWRITE lub VMPTRLD.
Funkcja hypervisor L1 może zdecydować się na użycie obsługujących zestawów VMCS przez zapisanie wartości 1 w odpowiednim polu na stronie Asysty procesora wirtualnego. Inne pole na stronie asystenta vp kontroluje aktualnie aktywne maszyny wirtualne VMCS. Każda obsługa maszyny wirtualnej VMCS ma dokładnie jedną stronę (4 KB) i musi być początkowo zerowa. Nie trzeba wykonywać instrukcji VMPTRLD, aby zapewnić aktywną lub bieżącą obsługę maszyn wirtualnych VMCS.
Po wykonaniu przez funkcję hypervisor L1 wpisu maszyny wirtualnej z obsługą maszyny wirtualnej VMCS maszyna wirtualna jest traktowana jako aktywna na procesorze. Obsługa usługi VMCS może być aktywna tylko na jednym procesorze w tym samym czasie. Funkcja hypervisor L1 może wykonać instrukcję VMCLEAR, aby przenieść aktywną maszynę wirtualną z aktywnej do stanu nieaktywnego. Wszystkie instrukcje VMREAD lub VMWRITE, gdy obsługa maszyny wirtualnej jest aktywna, jest nieobsługiwana i może spowodować nieoczekiwane zachowanie.
Struktura HV_VMX_ENLIGHTENED_VMCS definiuje układ obsługujących usługę VMCS. Wszystkie pola inne niż syntetyczne są mapowanie na kodowanie fizyczne VMCS firmy Intel.
Wyczyść pola
Funkcja hypervisor L0 może zdecydować się na buforowanie części obsługujących maszyn wirtualnych. Pouczane pola czyszczenia VMCS kontrolują, które części obsługujących maszyn wirtualnych są ponownie ładowane z pamięci gościa w zagnieżdżonym wpisie maszyny wirtualnej. Funkcja hypervisor L1 musi wyczyścić odpowiednie pola czyszczenia VMCS za każdym razem, gdy modyfikuje on obsługiwaną usługę VMCS, w przeciwnym razie funkcja hypervisor L0 może używać nieaktualnej wersji.
Czyste pola oświecenia są kontrolowane za pośrednictwem syntetycznego pola "CleanFields" oświeconego VMCS. Domyślnie wszystkie bity są ustawione tak, aby funkcja hypervisor L0 musi ponownie załadować odpowiednie pola VMCS dla każdego zagnieżdżonego wpisu maszyny wirtualnej.
Odnajdywanie funkcji
Obsługa obsługiwanego interfejsu VMCS jest zgłaszana przy użyciu 0x40000004 liści CPUID.
Obsługa struktury VMCS jest wersjonowana w celu uwzględnienia przyszłych zmian. Każda obsługiwana struktura VMCS zawiera pole wersji, które jest zgłaszane przez funkcję hypervisor L0.
Jedyną obsługiwaną wersją vmCS jest obecnie 1.
Zagadnienia dotyczące implementacji funkcji Hypervisor
W przypadku większości pól VMCS odpowiednie pole z obsługą usługi VMCS jest obsługiwane dla maszyny wirtualnej, jeśli pole VMCS jest obsługiwane dla maszyny wirtualnej zgodnie z opisem za pomocą mechanizmów odnajdywania funkcji architektury. Wyjątki są zgłaszane w 0x4000000A liścia CPUID.
W przypadkach, gdy mechanizmy odnajdywania funkcji architektury wskazują obsługę pola VMCS, dla którego nie zdefiniowano obsługującego pola VMCS, funkcja hypervisor L1 nie powinna włączać tej funkcji, jeśli zdecyduje się korzystać z obsługującej maszyny wirtualnej.
Funkcja hypervisor Hyper-V L0 nie będzie wskazywać obsługi pola VMCS, dla którego nie zdefiniowano żadnego obsługującego pola VMCS ani wyjątku. Jeśli inna funkcja hypervisor L0 wymaga nowego pola lub wyjątku usługi VMCS, które ma zostać zdefiniowane, skontaktuj się z firmą Microsoft.
Pola enlighened VMCB (AMD)
Firma AMD ma zarezerwowaną przestrzeń w vmCB do użycia funkcji hypervisor, a także skojarzony czysty bit. Zarezerwowane bajty znajdują się w sekcji kontroli, przesunięcia 0x3E0-3FF maszyny wirtualnej VMCB. Czysty bit jest bitem 31 (czysty bit musi zostać unieważniony za każdym razem, gdy funkcja hypervisor modyfikuje obszar "oświecenia" VMCB).
Hyper-V wykorzystuje zarezerwowany obszar VMCB do konfigurowania oświecenia. Struktura HV_SVM_ENLIGHTENED_VMCB_FIELDS dokumentuje format.
Poświecona mapa bitowa MSR
Funkcja hypervisor L0 emuluje kontrolki "MSR-Bitmap" na platformach Intel i AMD, które umożliwiają oprogramowaniu wirtualizacji kontrolowanie, do których msR uzyskuje dostęp do przechwytywania.
Funkcja hypervisor L1 może współpracować z funkcją hypervisor L0 w celu zwiększenia wydajności dostępu do usługi MSR. Może włączyć obsługujące mapy bitowe MSR, ustawiając odpowiednie pole w polach obsługujących maszyn wirtualnych VMCS/VMCB na 1. Po włączeniu funkcji hypervisor L0 nie monitoruje map bitowych MSR pod kątem zmian. Zamiast tego funkcja hypervisor L1 musi unieważnić odpowiednie czyste pole po wprowadzeniu zmian w jednej z map bitowych MSR.
Obsługa oświeconej mapy bitowej MSR jest zgłaszana w 0x4000000A liści CPUID.
Zgodność z migracją na żywo
Hyper-V ma możliwość migracji partycji podrzędnej na żywo z jednego hosta do innego hosta. Migracje na żywo są zwykle niewidoczne dla partycji podrzędnej. Jednak w przypadku wirtualizacji zagnieżdżonej funkcja hypervisor L1 może być świadoma migracji.
Powiadomienie o migracji na żywo
Funkcja hypervisor L1 może zażądać powiadomienia o migracji partycji. Ta funkcja jest wyliczana w identyfikatorze CPUID jako uprawnienie "AccessReenlightenmentControls". Funkcja hypervisor L0 uwidacznia syntetyczne msR (HV_X64_MSR_REENLIGHTENMENT_CONTROL), które mogą być używane przez funkcję hypervisor L1 do konfigurowania wektora przerwania i procesora docelowego. Funkcja hypervisor L0 wstrzykuje przerwanie z określonym wektorem po każdej migracji.
#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;
Określony wektor musi odpowiadać stałemu przerwaniu APIC. TargetVp określa indeks procesora wirtualnego.
Emulacja TSC
Partycja gościa może być migrowana na żywo między dwoma maszynami z różnymi częstotliwościami TSC. W takich przypadkach może być konieczna ponowna kompilacja wartości TscScale ze strony referencyjnej TSC .
Funkcja hypervisor L0 opcjonalnie emuluje wszystkie dostępy TSC po migracji, dopóki funkcja hypervisor L1 nie będzie miała możliwości ponownego skompilowania wartości TscScale. Funkcja hypervisor L1 może zdecydować się na emulację TSC, zapisując w HV_X64_MSR_TSC_EMULATION_CONTROL MSR. Jeśli zostanie wybrana opcja, funkcja hypervisor L0 emuluje dostęp TSC po zakończeniu migracji.
Funkcja hypervisor L1 może wykonywać zapytania, jeśli dostęp TSC jest obecnie emulowany przy użyciu HV_X64_MSR_TSC_EMULATION_STATUS MSR. Na przykład funkcja hypervisor L1 może subskrybować powiadomienia migracji na żywo i wysyłać zapytania dotyczące stanu TSC po odebraniu przerwania migracji. Może również wyłączyć emulację TSC (po zaktualizowaniu wartości TscScale) przy użyciu tego msR.
#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;
Wirtualny moduł równoważenia obciążenia
Wirtualny TLB uwidoczniony przez funkcję hypervisor może zostać rozszerzony na tłumaczenia pamięci podręcznej z L2 gpAs na gpAs. Podobnie jak w przypadku TLB na procesorze logicznym, wirtualny TLB jest niespójnego pamięci podręcznej, a ten brak spójności jest widoczny dla gości. Funkcja hypervisor uwidacznia operacje zarządzania TLB.
Bezpośrednie opróżnianie wirtualne
Funkcja hypervisor uwidacznia hiperwoły (HvCallFlushVirtualAddressSpace, HvCallFlushVirtualAddressSpaceEx, HvCallFlushVirtualAddressList i HvCallFlushVirtualAddressList), które umożliwiają systemom operacyjnym wydajniejsze zarządzanie wirtualnym modułem TLB. Funkcja hypervisor L1 może zezwolić gościowi na korzystanie z tych funkcji hypercall i delegować odpowiedzialność za obsługę funkcji hypervisor L0. Wymaga to użycia strony asysty partycji (i wirtualnej maszyny wirtualnej VMCS na platformach Intel).
W przypadku użycia wirtualne TLB oznacza wszystkie buforowane mapowania z identyfikatorem zagnieżdżonego kontekstu (VMCS lub VMCB), który je utworzył. W odpowiedzi na bezpośrednie wirtualne opróżnianie funkcji hypercall z gościa L2 funkcja hypervisor L0 unieważnia wszystkie buforowane mapowania utworzone przez zagnieżdżone konteksty, w których
- Identyfikator vmId jest taki sam jak identyfikator VMId obiektu wywołującego
- Identyfikator VpId jest zawarty w określonej maski procesora lub określono HV_FLUSH_ALL_PROCESSORS
Obsługa bezpośrednich opróżnień wirtualnych jest zgłaszana w 0x4000000A liści CPUID.
Konfiguracja
Bezpośrednia obsługa funkcji hypercalls opróżniania wirtualnego jest włączona przez:
- Ustawienie pola NestedEnlightenmentsControl.Features.DirectHypercall na stronie pomocy procesora wirtualnego na 1.
- Ustawienie pola OświeceniaControl.NestedFlushVirtualHypercall dla oświeconego vmCS lub VMCB na 1.
Przed jej włączeniem funkcja hypervisor L1 musi skonfigurować następujące dodatkowe pola obsługujących usługę VMCS/VMCB:
- VpId: identyfikator procesora wirtualnego z obsługą kontrolek VMCS/VMCB.
- VmId: identyfikator maszyny wirtualnej, do którego należy obsługa maszyny wirtualnej VMCS/VMCB.
- PartitionAssistPage: adres fizyczny gościa strony pomocy partycji.
Funkcja hypervisor L1 musi również uwidocznić następujące możliwości swoim gościom za pośrednictwem identyfikatora CPUID.
- UseHypercallForLocalFlush
- UseHypercallForRemoteFlush
Strona pomocy partycji
Strona pomocy partycji to wyrównany rozmiar strony obszaru pamięci, który funkcja hypervisor L1 musi przydzielić i zero, zanim można użyć funkcji hypercalls opróżniania bezpośredniego. Jego GPA musi zostać zapisana w odpowiednim polu w obsługującym maszynie wirtualnej VMCS / VMCB.
struct
{
UINT32 TlbLockCount;
} VM_PARTITION_ASSIST_PAGE;
VM-Exit syntetyczne
Jeśli TlbLockCount strony pomocy partycji obiektu wywołującego jest inny niż zero, funkcja hypervisor L0 dostarcza VM-Exit z syntetyczną przyczyną zakończenia funkcji hypervisor L1 po obsłudze funkcji hypervisor bezpośredniego opróżniania wirtualnego.
Na platformach Intel jest dostarczany VM-Exit z przyczyną HV_VMX_SYNTHETIC_EXIT_REASON_TRAP_AFTER_FLUSH zakończenia. Na platformach AMD jest dostarczany VM-Exit z kodem HV_SVM_EXITCODE_ENL zakończenia, a parametr ExitInfo1 ma wartość 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)
Translacja adresów drugiego poziomu
Po włączeniu wirtualizacji zagnieżdżonej dla partycji gościa jednostka zarządzania pamięcią uwidoczniona przez partycję obejmuje obsługę translacji adresów drugiego poziomu. Translacja adresów drugiego poziomu to funkcja, która może być używana przez funkcję hypervisor L1 do wirtualizacji pamięci fizycznej. W przypadku użycia niektóre adresy, które będą traktowane jako adresy fizyczne gościa (GPA) są traktowane jako adresy fizyczne gościa L2 (L2 GPA) i tłumaczone na gpA przez przechodzenie przez zestaw struktur stronicowania.
Funkcja hypervisor L1 może zdecydować, jak i gdzie używać przestrzeni adresowych drugiego poziomu. Każda przestrzeń adresowa drugiego poziomu jest identyfikowana przez wartość identyfikatora 64-bitowego gościa. Na platformach Intel ta wartość jest taka sama jak wskaźnik EPT. Na platformach AMD wartość jest równa polu nCR3 VMCB.
Compatibility
Funkcja tłumaczenia adresów drugiego poziomu uwidoczniona przez funkcję hypervisor jest ogólnie zgodna z obsługą maszyn wirtualnych VMX lub SVM na potrzeby tłumaczenia adresów. Istnieją jednak następujące różnice, które można zaobserwować gościa:
- Wewnętrznie funkcja hypervisor może używać tabel stron w tle, które tłumaczą L2 gpAs na elementy SPA. W takich implementacjach te tabele stron w tle wydają się być oprogramowaniem jako duże TLB. Można jednak zaobserwować kilka różnic. Po pierwsze tabele stron w tle mogą być współdzielone między dwoma procesorami wirtualnymi, natomiast tradycyjne tlB są strukturami procesorów i są niezależne. To udostępnianie może być widoczne, ponieważ dostęp do strony przez jeden procesor wirtualny może wypełnić wpis tabeli w tle, który jest następnie używany przez inny procesor wirtualny.
- Niektóre implementacje funkcji hypervisor mogą używać wewnętrznej ochrony zapisu tabel stron gościa do leniwego opróżniania mapowań mmU z wewnętrznych struktur danych (na przykład tabel stron w tle). Jest to architektonicznie niewidoczne dla gościa, ponieważ zapisy w tych tabelach będą obsługiwane w sposób niewidoczny dla funkcji hypervisor. Jednak zapisy wykonywane na podstawowych stronach gpA przez inne partycje lub urządzenia mogą nie wyzwalać odpowiedniego opróżnienia TLB.
- W niektórych implementacjach funkcji hypervisor błąd strony drugiego poziomu może nie unieważnić buforowanych mapowań.
Opróżnienia drugiego poziomu modułu równoważenia obciążenia
Funkcja hypervisor obsługuje również zestaw ulepszeń, które umożliwiają gościowi wydajniejsze zarządzanie modułem TLB drugiego poziomu. Te rozszerzone operacje mogą być używane zamiennie z starszymi operacjami zarządzania TLB.
Funkcja hypervisor obsługuje następujące hypercalls w celu unieważnienia tlB:
| Funkcja Hypercall | Description |
|---|---|
| HvCallFlushGuestPhysicalAddressSpace | unieważnia buforowane gpA L2 do mapowań GPA w przestrzeni adresowej drugiego poziomu. |
| HvCallFlushGuestPhysicalAddressList | unieważnia buforowane GVA / L2 GPA do mapowań GPA w części drugiej przestrzeni adresowej. |
Na platformach AMD wszystkie wpisy TLB są architektonicznie oznaczone identyfikatorem ASID (identyfikatorem przestrzeni adresowej). Unieważnienie identyfikatora ASID powoduje unieważnienie wszystkich całych modułów TLB skojarzonych z identyfikatorem ASID. Zagnieżdżona funkcja hypervisor może opcjonalnie zdecydować się na "obsługujący TLB", ustawiając wartość "1" na wartość "1" w HV_SVM_ENLIGHTENED_VMCB_FIELDS. Jeśli zagnieżdżona funkcja hypervisor zdecyduje się na oświecenie, unieważnienie ASID po prostu opróżnia całe TLB pochodzące z translacji adresów pierwszego poziomu (tj. wirtualnej przestrzeni adresowej). Aby opróżnić wpisy TLB pochodzące z tabeli zagnieżdżonych stron (NPT) i wymusić funkcję hypervisor L0 w celu ponownego skompilowania tabel stron w tle, należy użyć hiperwołyń HvCallPhysicalAddressSpace lub HvCallCallFlushGuestPhysicalAddressList.
Wyjątki wirtualizacji zagnieżdżonej
Na platformach Intel. Funkcja hypervisor L1 może wyrazić zgodę na łączenie wyjątków wirtualizacji w klasie wyjątków błędów strony. Funkcja hypervisor L0 anonsuje obsługę tego oświetlenia w liściu CPUID funkcji wirtualizacji zagnieżdżonej funkcji funkcji hypervisor.
To oświecenie można włączyć, ustawiając wartość VirtualizationException na wartość "1" w strukturze danych HV_NESTED_ENLIGHTENMENTS_CONTROL na stronie Pomocy procesora wirtualnego.
Zagnieżdżone usługi MSRs wirtualizacji
Zagnieżdżony rejestr indeksu VP
Funkcja hypervisor L1 uwidacznia funkcję MSR, która raportuje bazowy indeks VP bieżącego procesora.
| Adres MSR | Nazwa rejestracji | Description |
|---|---|---|
| 0x40001002 | HV_X64_MSR_NESTED_VP_INDEX | W zagnieżdżonej partycji głównej raportuje bazowy indeks VP procesora bieżącego. |
Zagnieżdżone synic MSRs
W zagnieżdżonej partycji głównej następujące usługi MSR umożliwiają dostęp do odpowiednich rejestrów SynIC podstawowego funkcji hypervisor.
Aby znaleźć indeks procesora bazowego, wywołujące powinny najpierw użyć HV_X64_MSR_NESTED_VP_INDEX.
| Adres MSR | Nazwa rejestracji | Podstawowa usługa MSR |
|---|---|---|
| 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 |