Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek popisuje paravirtualizaci GPU v WDDM. Tato funkce je dostupná od Windows 10 verze 1803 (WDDM 2.4).
Informace o virtualizaci GPU
Virtualizace GPU je důležitou funkcí pro klienta Systému Windows i Windows Server. Existuje mnoho scénářů, které vyžadují efektivní využití prostředků GPU ve virtuálním počítači.
Mezi scénáře serveru (kde hostitelský operační systém nespouští uživatelské aplikace) patří:
- Virtualizace desktopu
- Výpočet (AI, ML atd.)
Mezi klientské scénáře (kde hostitelský operační systém sdílí GPU mezi virtuálními počítači a uživatelskými aplikacemi) patří:
- Vývoj a testování grafických aplikací (kde se testování spouští na virtuálním počítači)
- Spouštění aplikací na virtuálním počítači pro účely zabezpečení
- Spuštění Linuxu na virtuálním počítači s akcelerací GPU
Paravirtualizace GPU v WDDM
Paravirtualizace (PV) poskytuje rozhraní virtuálním počítačům, které se podobají jejich základnímu hardwaru. V systému PV explicitně portujete hostovaný operační systém před instalací virtuálního stroje, protože neupravený hostovaný operační systém nejde spustit na monitoru virtuálního stroje (VMM).
Výhody:
- Hardwarové prostředky sdílí několik virtuálních počítačů.
- V kódu ovladače je potřeba provést několik změn.
Následující obrázek znázorňuje různé komponenty zapojené do paravirtualizovaného návrhu WDDM.
Moduly D3D runtime v hostovaném virtuálním počítači se nezmění. Rozhraní s uživatelským runtime a s KMT funkcemi jádra zůstávají stejná.
Komponenty ovladačů nevyžadují mnoho změn:
UMD ve virtuálním počítači hosta musí:
- Mějte na paměti, že komunikace s ovladačem režimu jádra hostitele (KMD) probíhá v rámci hranice virtuálního počítače.
- Pro přístup k nastavení registru použijte přidané služby Dxgkrnl.
V hostovi není žádný KMD, jen UMD. Virtuální renderovací zařízení (VRD) nahrazuje KMD. Účelem VRD je usnadnit načítání Dxgkrnl.
V hostovi není žádný správce paměti videa (VidMm) ani plánovač (VidSch).
Dxgkrnl na virtuálním počítači zpracovává volání thunk a zprostředkovává je do oddílu hostitele přes kanály sběrnice virtuálních počítačů. Dxgkrnl v hostu také vytváří místní objekty pro přidělování, procesy, zařízení a další prostředky, což snižuje komunikaci s hostitelem.
Virtuální vykreslovací zařízení (VRD)
Pokud na virtuálním počítači není paravirtualizovaný GPU, správce zařízení virtuálního počítače zobrazí adaptér Microsoft Hyper-V Video. Tento adaptér jen pro zobrazení je ve výchozím nastavení spárovaný s adaptérem BasicRender pro vykreslování.
Když do virtuálního počítače přidáte paravirtualizovaný GPU, správce zařízení virtuálního počítače zobrazí dva adaptéry:
- Microsoft Hyper-V Video Adapter nebo Microsoft Remote Display Adapter
- Ovladač Microsoft Virtual Render (skutečný název je název adaptéru GPU na hostiteli)
Ve výchozím nastavení je VRD spárovaný s adaptérem Hyper-V Video, takže veškeré vykreslování uživatelského rozhraní probíhá přes adaptér VRD.
Pokud narazíte na problémy s vykreslováním, můžete toto párování zakázat pomocí nastavení registru GpuVirtualizationFlags. V tomto případě se adaptér jen pro vykreslování (VRD) používá, když jej aplikace konkrétně vybere. Některé ukázky DirectX například umožňují změnit vykreslovací zařízení. Moduly runtime Direct3D přidají do VRD logický výstup zobrazení, když se aplikace rozhodne ji použít.
Když k virtuálnímu počítači přidáte více virtuálních GPU, může host obsahovat několik adaptérů VRD. S adaptérem Hyper-V Video je však možné spárovat pouze jeden z nich. Neexistuje způsob, jak určit, který z nich; operační systém zvolí.
Kontejnery a virtuální počítače
Virtualizace GPU se podporuje pro virtuální počítače a kontejnery. Kontejnery jsou zjednodušené virtuální počítače, kde se binární soubory hostitelského operačního systému mapují na virtuální počítač kontejneru.
Další informace o Windows a kontejnerech najdete pod a.
Zabezpečení virtuálních počítačů
Pro zabezpečený virtuální počítač existují následující omezení:
- Volání úniků ovladače nejsou povolena, s výjimkou známých úniků, které se používají s příznakem DriverKnownEscape.
- Izolace IoMmu je povolena. Vytvoření virtuálního počítače selže, pokud ovladač nepodporuje izolaci IoMmu.
Pokud je povolený zabezpečený režim:
- DxgkDdiSetVirtualMachineData má nastavený příznak SecureVirtualMachine.
- DxgkDdiQueryAdapterInfo má nastavený příznak SecureVirtualMachine.
Existují nastavení registru k vynucení zabezpečeného režimu nebo zakázání izolace IoMmu během vývoje. Pro více informací viz nastavení registru.
Vzdálený přístup k ploše virtuálního počítače nebo kontejneru
Pomocí dvou metod můžete vzdáleně spravovat obsah plochy na virtuálním počítači z hostitele:
- Hyper-V grafický adaptér
- Vzdálená správa relace terminálu
Při připojení k virtuálnímu počítači pomocí protokolu RDP (vzdálená plocha) se používá vzdálená správa relací terminálu.
Správce Hyper-V používá k zobrazení plochy virtuálního počítače aplikaci VMConnect. VMConnect funguje ve dvou režimech:
- Rozšířený režim, který používá vzdálené ovládání relace terminálu.
- Základní režim, který používá zobrazovací adaptér Hyper-V.
Pracovní proces virtuálního počítače a paměť virtuálního počítače
Při spuštění virtuálního počítače nebo kontejneru vytvoří operační systém na hostiteli následující procesy:
- Pracovní proces virtuálního počítače (vmwp.exe)
- Proces paměti virtuálního počítače (vmmem.exe)
Vmwp obsahuje různé ovladače virtuálních zařízení, včetně vrdumed.dll (knihovna DLL emulátoru virtuálního vykreslovacího zařízení v uživatelském režimu), což je ovladač pro paravirtualizované grafické adaptéry.
Virtuální adresní prostor procesu vmmem slouží jako záloha pro vstupně-výstupní prostor vGPU hosta. Když hostující systém přistupuje k I/O prostoru, výsledná fyzická adresa se stává vstupem pro překlad druhé úrovně, který využívá stránkovací tabulky procesu vmmem.
Ve virtualizovaném prostředí se různá volání KMD DDI, která se obvykle provádějí v kontextu uživatelského procesu na hostiteli, místo toho vykonávají v kontextu procesu vmmem, když je spuštěn virtuální stroj.
Dxgkrnl vytvoří pro tyto procesy jeden objekt procesu DXGPROCESS (a odpovídající objekt procesu KMD), který se nazývá pracovního procesu virtuálního počítače v tomto článku. Proces EPROCESS přidružený k pracovnímu procesu virtuálního počítače DXG je vmmem .
Procesy virtuálních počítačů
Při vytvoření DXGPROCESS na hostovaném virtuálním počítači Dxgkrnl vytvoří odpovídající objekt DXGPROCESS na hostiteli. Tento proces se v tomto článku nazývá VM proces. EPROCESS přidružené k DXGPROCESS je vmmem.
Všechny operace vykreslování z virtuálního počítače nebo alokace virtuálního počítače se provádějí v kontextu virtuálního počítače v DXGPROCESS.
Pro účely ladění Dxgkrnl upozorní KMD, který proces je pracovní proces VM nebo proces VM v DxgkDdiCreateProcess. Pomocí těchto informací může ovladač propojit proces virtuálního počítače s pracovním procesem virtuálního počítače. Tyto informace pomáhají ladění ve scénářích, kdy je spuštěno více než jeden virtuální počítač.
Požadavky na řidiče
kmd, která podporuje paravirtualizaci GPU, musí nastavit DXGK_VIDMMCAPS::ParavirtualizationSupported funkci.
Ovladač uživatelského režimu (UMD) by neměl používat žádná data související s kontextem procesu v datech soukromého ovladače (ukazatele, popisovač atd.). Místo toho Služba správy klíčů získá privátní data v hostiteli v jiném kontextu procesu.
UMD v hostu nemůže sdílet paměť s KMD v hostiteli. Musí používat funkce popsané v části přístup k registru v rámci UMD, aby získal přístup k registru.
Aktuální implementace paravirtualizace používá sběrnici virtuálního počítače ke komunikaci mezi hostem a hostitelem. Maximální velikost zprávy je 128 kB. V současné době Dxgkrnl nerozděluje zprávy na menší části pro jejich postupné odesílání. Ovladač proto musí omezit velikost privátních dat předávaných při vytváření objektu. Pokud se například Pfnd3ddddiAllocatecb používá k vytvoření mnoha přidělení, celková velikost zprávy zahrnuje hlavičku, globální privátní data a velikost privátních dat přidělení vynásobená počtem přidělení. Všechny tyto informace se musí vejít do jedné zprávy.
Spouštění aplikací v emulovaném celoobrazovkovém režimu
Adaptér nepřímého zobrazení by měl být povolený pro vzdálený přístup (ve výchozím nastavení je povolený). Pokud ho chcete zakázat, proveďte následující kroky.
- Spustit úpravu zásad skupiny
- Přejděte do Konfigurace počítače –>Šablony pro správu –>Součásti systému Windows –>Služby vzdálené plochy –>Hostitel relace vzdálené plochy –>Prostředí relace vzdálené plochy
- Otevřete položku Použít ovladač grafického zobrazení WDDM pro připojení ke vzdálené ploše.
- Vyberte Zakázat a vyberte OK.
- Restartovat
Podpora DXGI pro aplikace na celé obrazovce ve virtuálních počítačích je ve výchozím nastavení povolená. Pokud ho chcete zakázat, použijte StagingTool.exe /disable 19316777.
Aplikace na celé obrazovce musí být spuštěné v emulovaném režimu celé obrazovky.
Povolte eFSE pro všechny aplikace DXGI a nastavte minimální verzi WDDM pro přechod efektu přepínání na WDDM 2.0.
D3DEnableFeature.exe /enable DXGI_eFSE_Enablement_PolicyD3DEnableFeature.exe /setvariant DXGI_eFSE_Enablement_Policy 7
eFSE je ve výchozím nastavení povolen pro aplikace D3D9.
DriverStore na virtuálním počítači
Binární soubory ovladačů na hostiteli jsou umístěny v úložišti ovladačů %windir%\system32\drivers\DriverStore\FileRepository<DriverDirectory>.
U paravirtualizace se očekává, že binární soubory UMD ve virtuálním počítači budou v %windir%\system32\drivers\HostDriverStore\FileRepository<DriverDirectory>.
Hostitel KMD hlásí názvy knihoven UMD DLL, které mají úplnou cestu k úložišti ovladačů. Například c:\windows\system32\DriverStore\FileRepository\DriverSpecificDirectory\d3dumd.dll.
Když se virtuální počítač zeptá na název UMD, název se přeloží na <>VmSystemDrive:\windows\system32\HostDriverStore\FileRepository\DriverSpecificDirectory\d3dumd.dll.
Host DriverStore pro kontejnery
Pro kontejnery Hyper-V mapuje úplný adresář úložiště ovladačů z hostitele do <%windir%\HostDriverStore v kontejneru.
Host DriverStore pro plné virtuální stroje
Soubory úložiště ovladačů se zkopírují do virtuálního počítače při spuštění virtuálního adaptéru GPU ve virtuálním počítači. Tato funkce je zakázaná ve vydané verzi operačního systému.
Následující klíč registru a možné hodnoty řídí operaci kopírování. Klíč ve výchozím nastavení neexistuje.
DWORD RTL_REGISTRY_CONTROL\GraphicsDrivers\DriverStoreCopyMode
| Hodnota | Popis |
|---|---|
| 0 | Zakázání kopírování úložiště ovladačů |
| 1 | Normální operace (povolte kopírování souborů úložiště ovladačů a nepřepisujte stávající soubory). |
| 2 | Povolte kopírování úložiště ovladačů a přepsání existujících souborů. |
Přístup k registru z UMD
Klíče registru KMD existují na hostiteli a neodrážejí se do virtuálního počítače. Proto umd nemůže číst takové klíče registru ovladačů přímo. Ve struktuře D3DDDI_ADAPTERCALLBACKS modulu runtime D3D je přidáno zpětné volání pfnQueryAdapterInfoCb2. UMD může volat pfnQueryAdapterInfoCb2, přičemž D3DDDICB_QUERYADAPTERINFO2 je nastaven tímto způsobem pro čtení určitých klíčů registru:
- D3DDDICB_QUERYADAPTERINFO2::QueryType nastavena na D3DDDI_QUERYADAPTERTYPE_QUERYREGISTRY.
-
pPrivateDriverData odkazuje na vyrovnávací paměť obsahující strukturu D3DDDI_QUERYREGISTRY_INFO, která slouží k vrácení informací z registru. UMD obsazuje následující členy:
- D3DDDI_QUERYREGISTRY_INFO::QueryType určuje typ přístupu k registru; Například klíč služby, klíč adaptéru nebo cesta k úložišti ovladačů.
- D3DDDI_QUERYREGISTRY_FLAGS::QueryFlags určuje příznaky dotazu.
- ValueName identifikuje název hodnoty, která se má přečíst.
- ValueType určuje typ hodnoty, která se má přečíst.
-
PrivateDriverDataSize je
sizeof(D3DDDI_QUERYREGISTRY_INFO)plus velikost vyrovnávací paměti pro dynamicky určovanou velikost výstupní hodnoty.
UMD může také přímo zavolat D3DKMTQueryAdapterInfo. Toto volání je užitečné pro UMD na straně hosta, protože je předáváno hostiteli a umožňuje překlad určitých názvů do prostoru názvů hosta.
D3DKMTQueryAdapterInfo se volá s D3DKMT_QUERYADAPTERINFO nastaveným takto pro čtení určitých klíčů registru:
- typ je nastaven na KMTQAITYPE_QUERYREGISTRY
- pPrivateDriverData odkazuje na strukturu D3DKMT_ADAPTERREGISTRYINFO
-
PrivateDriverDataSize je
sizeof(D3DKMT_ADAPTERREGISTRYINFO)plus velikost vyrovnávací paměti pro dynamicky určovanou velikost výstupní hodnoty.
Příklad 1: Čtení hodnoty z klíče služby
WCHAR ValueName = L"EnableDebug";
D3DDDI_QUERYREGISTRY_INFO Args = {};
Args.QueryType = D3DDDI_QUERYREGISTRY_SERVICEKEY;
Args.QueryFlags.TranslatePath = FALSE or TRUE;
Args.ValueType = Supported registry value type;
wcscpy_s(Args.ValueName, ARRAYSIZE(Args.ValueName), ValueName);
D3DKMT_QUERYADAPTERINFO Args1 = {};
Args1.hAdapter = hAdapter;
Args1.Type = KMTQAITYPE_QUERYREGISTRY;
Args1.pPrivateDriverData = &Args;
Args1.PrivateDriverDataSize = sizeof(Args);
NTSTATUS Status = D3DKMTQueryAdapterInfo(&Args1);
if (NT_SUCCESS(Status) &&
Args.Status == D3DDDI_QUERYREGISTRY_STATUS_SUCCESS)
{
if (ValueType == REG_SZ || ValueType == REG_EXPAND_SZ) {
wprintf(L"Value: \"%s\"\n", Args.OutputString);
} else
if (ValueType == REG_MULTI_SZ) {
wprintf(L"Value: ");
for (UINT i = 0; i < Args.OutputValueSize; i++) {
if (Args.OutputString[i] == 0) {
wprintf(L" ");
} else {
wprintf(L"%c", Args.OutputString[i]);
}
}
wprintf(L"\n");
} else
if (ValueType == REG_DWORD) {
wprintf(L"Value: %d\n", Args.OutputDword);
} else
if (ValueType == REG_QWORD) {
wprintf(L"Value: 0x%I64x\n", Args.OutputQword);
} else
if (ValueType == REG_BINARY) {
wprintf(L"Num bytes: %d\n", Args.OutputValueSize);
for (UINT i = 0; i < Args.OutputValueSize; i++) {
wprintf(L"%d ", Args.OutputBinary[i]);
}
wprintf(L"\n");
}
}
Příklad 2: Čtení cesty k úložišti ovladačů
D3DDDI_QUERYREGISTRY_INFO Args = {};
Args.QueryType = D3DDDI_QUERYREGISTRY_DRIVERSTOREPATH;
D3DKMT_QUERYADAPTERINFO Args1 = {};
Args1.hAdapter = hAdapter;
Args1.Type = KMTQAITYPE_QUERYREGISTRY;
Args1.pPrivateDriverData = &Args;
Args1.PrivateDriverDataSize = sizeof(Args);
NTSTATUS Status = D3DKMTQueryAdapterInfo(&Args1);
if (NT_SUCCESS(Status) &&
Args.Status == D3DDDI_QUERYREGISTRY_STATUS_SUCCESS)
{
Args.OutputString holds the output NULL terminated string.
Args.OutputValueSize holds the number of characters in the string
}
Kopírování souborů do %windir%\system32 a %windir%\syswow64 na virtuálním počítači
V některých případech musí být knihovny DLL uživatelského režimu ovladače přítomny v adresářích %windir%\system32 a %windir%\syswow64.
Operační systém poskytuje způsob, jak ovladač může určit soubory, které se mají zkopírovat z úložiště ovladače ve zdrojovém systému do %windir%\system32 nebo %windir%\syswow64 v cílovém systému.
Ve instalačním INF může ovladač definovat více hodnot v následujících podklíčích v klíči registru grafického adaptéru:
- KopírovatDoVmPřepsat
- CopyToVmWhenNewer
- ZkopírovatDoVmPřepsatWow64
- CopyToVmWhenNewerWow64
CopyToVmOverwrite a CopyToVmWhenNewer podklíče se používají ke kopírování souborů do adresáře %windir%\system32.
CopyToVmOverwriteWow64 a CopyToVmWhenNewerWow64 podklíče se používají ke kopírování souborů do adresáře %windir%\syswow64.
Soubory v CopyToVmOverwrite a CopyToVmOverwriteWow64 vždy přepisují soubory v cílovém umístění.
Soubory v části CopyToVmWhenNewer a CopyToVmWhenNewerWow64 přepíšou soubory v cíli pouze v případě, že je datum změny souboru novější. Novější kritéria porovnávají dvě informace:
- FileVersion
- ČasPosledníhoZápisu
Když cílový soubor končí příponou .dll nebo .exe, použije se FileVersion jako nejvýznamnější porovnávací hodnota, kde se největší verze považuje za novější. Pokud cílový soubor nekončí příponou .dll nebo .exe nebo jsou obě verze souboru stejné, použije se LastWriteTime jako nejméně významná porovnávací hodnota, kde pozdější datum a čas se považuje za novější.
Každý typ hodnoty v rámci podklíče musí být REG_MULTI_SZ nebo REG_SZ. Pokud je typ hodnoty REG_MULTI_SZ, měly by být ve hodnotě maximálně dva řetězce. Tento požadavek znamená, že každá hodnota definuje jeden řetězec nebo dvojici řetězců, kde druhý řetězec může být prázdný.
První název v páru je cesta k souboru v úložišti ovladače. Cesta je relativní vzhledem ke kořenovému adresáři úložiště ovladačů a může obsahovat podadresáře.
Druhý název v páru je název souboru, který by se měl objevit v %windir%\system32 nebo %windir%\syswow64 adresáři. Druhý název by měl být jenom název souboru, který neobsahuje cestu.
Pokud je druhý název prázdný, název souboru je stejný jako v úložišti ovladačů (s výjimkou podadresářů).
Tento přístup umožňuje ovladači mít různá jména v úložišti ovladačů hostitele a v systému hosta.
Příklad 1
Následující příklad ukazuje, jak přimět operační systém zkopírovat <DriverStorePath>\CopyToVm\softgpu1.dll do %windir%\system32\softgpu2.dll.
INF [DDInstall] section
HKR,"softgpukmd\CopyToVmOverwrite",SoftGpuFiles,%REG_MULTI_SZ%,"CopyToVm\softgpu1.dll”, “softgpu2.dll”
The directive creates the registry key in the software (adapter) key:
"HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\<number>\CopyToVmOverwrite”, SoftGpuFiles = REG_MULTI_SZ, “CopyToVm\softgpu1.dll”, “softgpu2.dll"
Příklad 2
Následující příklad ukazuje, jak přimět operační systém ke kopírování <DriverStorePath>\softgpu1.dll do %windir%\system32\softgpu.dll a <DriverStorePath>\softgpu2.dll do %windir%\system32\softgpu2.dll.
INF [DDInstall] section:
HKR,"CopyToVmOverwrite",SoftGpuFiles1,%REG_MULTI_SZ%,"softgpu1.dll”,”softgpu.dll"
HKR,"CopyToVmOverwrite",SoftGpuFiles2,%REG_SZ%, “softgpu2.dll"
The directive creates the registry key in the software (adapter) key:
“HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\<number>\CopyToVmOverwrite”, SoftGpuFiles1 = REG_MULTI_SZ, “softgpu1.dll”, “softgpu.dll"
“HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\<number>\CopyToVmOverwrite”, SoftGpuFiles2 = REG_SZ, “softgpu2.dll””
Příklad 3
Následující příklad ukazuje, jak přimět operační systém ke kopírování <DriverStorePath>\Subdir1\Subdir2\softgpu2wow64.dll do %windir%\syswow64\softgpu.dll a <DriverStorePath>\softgpu.dll do %windir%\syswow64\softgpu2wow64.dll.
INF [DDInstall] section:
HKR,"CopyToVmOverwriteWow64",SoftGpuFiles,%REG_MULTI_SZ%,“Subdir1\Subdir2\softgpu2wow64.dll”,”softgpu.dll”.
The directive creates the registry key in the software (adapter) key:
“HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\<number>\CopyToVmOverwriteWow64”, SoftGpuFiles = REG_MULTI_SZ, “Subdir1\Subdir2\softgpu2wow64.dll”,”softgpu.dll
Změny v dxgkDdiCreateProcess
Funkce DxgkDdiCreateProcess služby KMD je potřeba aktualizovat, aby podporovala pracovní procesy virtuálního počítače a procesy virtuálních počítačů. Do struktury DXGKARG_CREATEPROCESS se přidají následující pole:
- hKmdVmWorkerProcess
- DélkaNázvuProcesu
- pProcessName
Do DXGK_CREATEPROCESSFLAGS se přidají následující příznaky pro podporu pracovních procesů VM a samotných procesů VM:
- VirtualMachineProcess
- VirtualMachineWorkerProcess
DxgkDdiSetVirtualMachineData
DxgkDdiSetVirtualMachineData se přidá pro Dxgkrnl k předání informací o virtuálním počítači do KMD.
Asynchronní zprávy sběrnice VM k hostiteli
Některé zprávy z Dxgkrnl v hostovaném operačním systému hostitele jsou asynchronní. Tento přístup zlepšuje výkon vysokofrekvenčních Dxgkrnl volání rozhraní API v hostu. Režie každé synchronní zprávy sběrnice virtuálních počítačů pro hostitele může být vysoká.
Mezi asynchronní zprávy patří:
- D3DKMTSubmitCommand
- D3DKMTSubmitCommandToHardwareQueue
- D3DKMTSignalSynchronizationObjectFromGpu
- D3DKMTWaitForSynchronizationObjectFromGpu
Podpora LDA v GPU-PV
Propojený grafický adaptér (LDA) je podporován v GPU-PV. Aby se zajistila konzistentní implementace a podpora možného zpětného přenosu podpory LDA do starších verzí Windows, musí KMD zkontrolovat podporu LDA v GPU-PV voláním DxgkCbIsFeatureEnabled(DXGK_FEATURE_LDA_GPUPV). Podpora je povolena, pokud je funkce úspěšná a vrátí Enabled. Pokud KMD toto zpětné volání nezavolá, Dxgkrnl předpokládá, že KMD nepodporuje LDA v GPU-PV.
Pokud operační systém tuto funkci podporuje, je na ovladači, který povolí LDA v uživatelském režimu. Pokud ovladač povolí LDA v uživatelském režimu, měl by to provést následujícím způsobem.
| Runtime | Stav LDA |
|---|---|
| Runtime prostředí před D3D12 | Povolte, pokud se podporuje DXGK_FEATURE_LDA_GPUPV a hostovaný operační systém je Windows 11 verze 22H2 (WDDM 3.1) nebo novější. |
| Moduly runtime bez DX (Windows) | Povolte, pokud se podporuje DXGK_FEATURE_LDA_GPUPV a hostovaný operační systém je Windows 11 verze 22H2 (WDDM 3.1) nebo novější. Místo kontroly verze operačního systému může UMD volat D3DKMTQueryAdapterInfo(KMTQAITYPE_PHYSICALADAPTERCOUNT) a povolit LDA, když vrátí počet fyzických adaptérů větší než 1. |
| D3D12 runtime modul (Windows) | Zapnout. Vizte Nastavení stavu LDA pro běhové prostředí D3D12. |
| Linux (modul runtime d3d12 a jiný než DX) | Pokud se podporuje DXGK_FEATURE_LDA_GPUPV, povolte to. |
Ovladače kompilované s verzí rozhraní, která je nižší než DXGKDDI_INTERFACE_VERSION_WDDM3_0, nekontrolují DXGK_FEATURE_LDA_GPUPV. Tyto ovladače stále mohou povolit LDA pro linuxové runtime prostředí.
Nastavení stavu LDA pro běhové prostředí D3D12
Při povolování nebo zakazování LDA pro modul runtime D3D12 musí UMD vrátit správné informace o úrovni a mapování uzlů zpět do modulu runtime. Tok kódu je následující:
D3D12 přijímá D3D12_CROSS_NODE_SHARING_TIER schopnost od UMD.
D3D12 získá počet fyzických adaptérů z Dxgkrnl voláním D3DKMTQueryAdapterInfo(KMTQAITYPE_PHYSICALADAPTERCOUNT).
D3D12 volá pfnQueryNodeMap(PhysicalAdapterCount, &map) pro získání mapování indexů logických uzlů na fyzické uzly. Uzel v tomto případě znamená fyzický adaptér. UMD musí nastavit skutečný index fyzického adaptéru v mapě nebo použít D3D12DDI_NODE_MAP_HIDE_NODE k zakázání uzlu.
Na základě výsledků pfnQueryNodeMap D3D12 vypočítává efektivní počet fyzických adaptérů tím, že nezapočítává skryté uzly.
Pokud se stav úrovně a počet efektivních fyzických adaptérů neshoduje, vytvoření zařízení D3D12 selže. Neshoda nastane, když:
- Úroveň je D3D12DDI_CROSS_NODE_SHARING_TIER_NOT_SUPPORTED a počet adaptérů je větší než 1.
- Úroveň není D3D12DDI_CROSS_NODE_SHARING_TIER_NOT_SUPPORTED a počet adaptérů činí 1.
Aby bylo možné zakázat LDA, musí umD vrátit D3D12DDI_CROSS_NODE_SHARING_TIER_NOT_SUPPORTED vrstvu a ponechat v mapě uzlu povolený jenom jeden fyzický adaptér.
D3DKMTQueryAdapterInfo(KMTQAITYPE_PHYSICALADAPTERCOUNT)
Dotaz KMTQAITYPE_PHYSICALADAPTERCOUNT počtu fyzických adaptérů vždy vrátí správný počet fyzických adaptérů hostu:
- U hostů s verzemi před Windows 11 verze 22H2 se vrátí 1. Tato hodnota je pevně zakódovaná v kódu hosta. V budoucnu se může změnit, pokud se podpora LDA přepošla na starší verze operačního systému.
- Ve Windows 11 verze 22H2 a novějších systémech vrátí:
- Skutečný počet fyzických adaptérů, když je povoleno DXGK_FEATURE_LDA_GPUPV.
- Jinak 1.
Paravirtualizace se vyvolá
Povolte podporu virtualizace v systému BIOS (VT-d nebo podobné). GPU-PV nastavení se liší pro virtuální počítače VMMS a kontejnery.
V PowerShellu (spuštěném jako správce) povolte spouštění skriptů na serveru:
set-executionpolicy unrestricted
Nastavení virtuálního počítače VMMS
Nastavení hostitele a virtuálního počítače
Sestavení operačního systému ve virtuálním počítači může být starší nebo novější než sestavení operačního systému v hostiteli.
Povolte funkci Hyper-V v rolích serveru nebo funkci Hyper-V v klientovi. Při povolování této funkce na serveru vyberte možnost použít síťový adaptér jako externí přepínač.
(volitelné) Povolit podepisování testů (bcdedit -set TESTSIGNING ON)
Restartovat.
Nainstalujte ovladač GPU, který podporuje para-virtualizaci.
(volitelné) Některé ovladače nenastavují kapacitu ParavirtualizationSupported. V takovém případě před instalací ovladače nebo zakázáním nebo povolením zařízení po nastavení příznaku přidejte následující registr.
DWORD HKLM\System\CurrentControlSet\Control\GraphicsDrivers\GpuVirtualizationFlags = 1Pokud chcete zkontrolovat, jestli operační systém rozpozná paravirtualizovaný GPU, spusťte následující příkaz PowerShellu:
Get-VMPartitionableGpu # Example output from running the command Name : \\?\PCI#VEN_10DE&DEV_1C02&SUBSYS_11C210DE&REV_A1#4&275d7527&0&0010#{064092b3-625e-43bf-9eb5-d c845897dd59}\GPUPARAV ValidPartitionCounts : {32} PartitionCount : 32 TotalVRAM : 1,000,000,000 AvailableVRAM : 1,000,000,000 MinPartitionVRAM : 0 MaxPartitionVRAM : 1,000,000,000 OptimalPartitionVRAM : 1,000,000,000 TotalEncode : 18,446,744,073,709,551,615 AvailableEncode : 18,446,744,073,709,551,615 MinPartitionEncode : 0 MaxPartitionEncode : 18,446,744,073,709,551,615 OptimalPartitionEncode : 18446744073709551615 TotalDecode : 1000000000 AvailableDecode : 1000000000 MinPartitionDecode : 0 MaxPartitionDecode : 1000000000 OptimalPartitionDecode : 1000000000 TotalCompute : 1000000000 AvailableCompute : 1000000000 MinPartitionCompute : 0 MaxPartitionCompute : 1000000000 OptimalPartitionCompute : 1000000000 CimSession : CimSession: . ComputerName : MYCOMPUTER-TEST2 IsDeleted : FalseSpuštěním následujících příkazů v PowerShellu vytvořte virtuální počítač s GPU. Vytvoří se virtuální počítač s názvem TEST.
$vm = “TEST“ New-VM -VMName $vm -Generation 2 Set-VM -GuestControlledCacheTypes $true -VMName $vmNastavte pro virtuální počítač vstupně-výstupní prostor. GPU-PV využívá IO prostor ke zpracování alokací viditelných pro CPU. Je potřeba alespoň 8 GB prostoru pro IO operace.
Set-VM -LowMemoryMappedIoSpace 1GB -VMName $vm Set-VM -HighMemoryMappedIoSpace 16GB -VMName $vm[volitelné] Ve výchozím nastavení je základní adresa pro velký prostor vstupně-výstupních operací paměti nastavená na (64 GB – 512 MB). Na čipových sadách Haswell s 36bitovým adresováním fyzické paměti musí být koncová adresa oblasti prostoru vstupně-výstupních operací nižší než 64 GB, takže počáteční adresu je potřeba nastavit odpovídajícím způsobem. Následující skript s názvem SetHighMmioBase.ps1nastaví počáteční adresu na 47 GB při spuštění s následujícími parametry:
SetHightMmioBase.ps1 “TEST” 48128 # SetHighMmioBase.ps1 param( [string]$VmName, $BaseInMB) function Get-WMIVM { [CmdletBinding()] param( [parameter(Mandatory=$true)] [ValidateNotNullOrEmpty()] [string]$VmName = "" ) gwmi -namespace root\virtualization\v2 -query "select * from Msvm_ComputerSystem where ElementName = '$VmName'" } function Get-WMIVmSettingData { [CmdletBinding()] param( [parameter(Mandatory=$true)] [ValidateNotNullOrEmpty()] [string]$VmName = "" ) $vm = Get-WMIVM $VmName return $vm.GetRelated ("Msvm_VirtualSystemSettingData","Msvm_SettingsDefineState",$null,$null, "SettingData", "ManagedElement", $false, $null) } Write-Host "Setting HighMmioGapBase to $BaseInMB for VmName $VmName" $vssd = Get-WMIVmSettingData $VmName $vmms = Get-WmiObject -Namespace "root\virtualization\v2" -Class Msvm_VirtualSystemManagementService $vssd.HighMmioGapBase = $BaseInMB $settingsText = $vssd.PSBase.GetText("CimDtd20") $ret=$vmms.ModifySystemSettings($settingsText).ReturnValue if ($ret -eq 0) { Write-Host "Successfully set" $vssd.HighMmioGapBase } else { Write-Host "Error $ret" }Přidejte do virtuálního počítače virtuální GPU a zakažte kontrolní body.
Add-VMGpuPartitionAdapter -VMName $vm Set-VM -CheckpointType Disabled -VMName $vmPokud chcete zkontrolovat, jestli má virtuální počítač paravirtualizovaný GPU, spusťte následující příkaz:
Get-VMGpuPartitionAdapter -VMName $vm in PowerShell. The output should show the adapter. # Example output from running the command MinPartitionVRAM : MaxPartitionVRAM : OptimalPartitionVRAM : MinPartitionEncode : MaxPartitionEncode : OptimalPartitionEncode : MinPartitionDecode : MaxPartitionDecode : OptimalPartitionDecode : MinPartitionCompute : MaxPartitionCompute : OptimalPartitionCompute : Name : GPU Partition Settings Id : Microsoft:9ABB95E2-D12D-43C3-B840-6F4A9CFB217B\929890BC-BB33-4687-BC1A-F72A4F1B3B3F VMId : 9abb95e2-d12d-43c3-b840-6f4a9cfb217b VMName : TEST VMSnapshotId : 00000000-0000-0000-0000-000000000000 VMSnapshotName : CimSession : CimSession: . ComputerName : MYCOMPUTER-TEST2 IsDeleted : False VMCheckpointId : 00000000-0000-0000-0000-000000000000 VMCheckpointName :Zkopírujte soubor VHDX stejného sestavení klienta, který používáte ve virtuálním počítači, do hostitelského adresáře. Například
d:\VM\os.vhdx.Otevřete správce Hyper-V a upravte parametry virtuálního počítače (vyberte virtuální počítač a vyberte Nastavení):
- Zabezpečení – zrušte zaškrtnutí políčka Povolit zabezpečené spouštění.
- Paměť – kontrola povolit dynamickou paměť. Nastavte velikost paměti na 1 024 MB nebo více.
- Procesor – nastavte počet virtuálních procesorů na 2 nebo 4.
- Síťový adaptér – V rozevíracím seznamu vyberte síťový adaptér, který chcete použít s virtuálním počítačem. Pokud je povolené ladění sítě, nezapomeňte vybrat adaptér Microsoft Debugging NET.
- Řadič SCSI – Pevný disk – Přidat – Virtuální pevný disk – Procházet – Vybrat
d:\VM\os.vhdx
Operační systém zkopíruje soubory z úložiště ovladačů hostitele do adresáře HostDriverStore v hostu, když se adaptér inicializuje v hostu.
- Připojte VHDX virtuálního počítače. Například na disk f:.
- Na připojeném virtuálním počítači vytvořte adresář s názvem f:\%windir%\system32\HostDriverStore\FileRepository.
- Replikujte soubory ovladačů z %windir%\system32\DriverStore v hostiteli na virtuální počítač. Na virtuálním počítači by měly být f:\%windir%\system32\HostDriverStore\FileRepository\YourDriverDirectory\*.
Pokud ovladač potřebuje přístup k souborům z
%windir%\system32nebo%windir%\syswow64, zkopírujte soubory do virtuálního počítače ručně.Pokud ovladače nejsou podepsané Microsoftem, povolte na virtuálním počítači testovací přihlašování. V okně správce CMD spusťte následující příkaz:
bcdedit /store <VM drive>:\EFI\Microsoft\Boot\BCD -set {bootmgr} testsigning onOdpojte virtuální pevný disk (VHDX) z virtuálního počítače.
Spusťte virtuální počítač.
Připojte se k virtuálnímu počítači pomocí možnosti připojení správce Hyper-V.
UVNITŘ VIRTUÁLNÍHO POČÍTAČE
Zkontrolujte, že ve Správci zařízení virtuálního počítače je zařízení virtuálního vykreslení. Veškeré vykreslování uvnitř virtuálního počítače prochází virtuálním GPU.
Skript PowerShellu pro nastavení virtuálního počítače
Následující skript PowerShellu je příkladem toho, jak nastavit virtuální počítač úplně od začátku. Upravte ho tak, aby vyhovoval vašim potřebám.
Param(
[string]$VMName,
[string]$VHDPath,
[string]$SwitchName,
[switch]$CreateVm,
[switch]$InitDebug,
[switch]$CopyRegistry,
[switch]$CopyDriverStore,
[switch]$CreateSwitch,
[switch]$AddGpu,
[switch]$All
)
if($All)
{
$CreateVm = $True
$CreateInitDebug = $True
$CopyRegistry = $True
$CopyDriverStore = $True
$CreateSwitch = $True
$AddGpu = $True
$InitDebug = $True
}
$vm = $VMName
#
# Validate parameters
#
if ($CreateSwitch -or $CreateVM)
{
if ($SwitchName -eq "")
{
write "SwitchName is not set"
exit
}
}
if ($AddGpu -or $CreateVM)
{
if ($VMName -eq "")
{
write "VMName is not set"
exit
}
}
if ($InitDebug -or $CreateVM -or $CopyDriverStore -or $CopyRegistry)
{
if ($VHDPath -eq "")
{
write "VHDPath is not set"
exit
}
}
enable-windowsoptionalfeature -FeatureName Microsoft-Hyper-V-All -online
#
# Create a network switch for the VM
#
if ($CreateSwitch)
{
New-VMSwitch $SwitchName -NetAdapterName "Ethernet (Kernel Debugger)"
}
#
# Create a VM and assign VHD to it
#
if ($CreateVm)
{
New-VM -VMName $vm -Generation 2
Set-VM -GuestControlledCacheTypes $true -VMName $vm
Set-VM -LowMemoryMappedIoSpace 1Gb -VMName $vm
Set-VM -HighMemoryMappedIoSpace 32GB -VMName $vm
Set-VMProcessor -VMname $vm -count 4
Set-VMMemory -VMName $vm -DynamicMemoryEnabled $true -MinimumBytes 1024MB -MaximumBytes 4096MB -StartupBytes 1024MB -Buffer 20
Add-VMHardDiskDrive -VMName $vm -Path $VHDPath
Connect-VMNetworkAdapter -VMName $vm -Name "Network Adapter" -SwitchName $SwitchName
Set-VMFirmware -VMName $vm -EnableSecureBoot off
Set-VMFirmware -VMName $vm -FirstBootDevice (Get-VMHardDiskDrive -VMName $vm)
}
#
# Enable debugger and testsiging
#
if ($InitDebug)
```powershell
{
Mount-vhd $VHDPath
Add-PartitionAccessPath -DiskNumber (Get-DiskImage -ImagePath $VHDPath | Get-Disk).Number -PartitionNumber 1 -AssignDriveLetter
$efidrive = (Get-DiskImage -ImagePath $VHDPath | Get-Disk | Get-Partition -PartitionNumber 1).DriveLetter
bcdedit /store ${efidrive}:\EFI\Microsoft\Boot\BCD -set '{bootmgr}' testsigning on
bcdedit /store ${efidrive}:\EFI\Microsoft\Boot\BCD -set '{default}' debug on
bcdedit /store ${efidrive}:\EFI\Microsoft\Boot\BCD /dbgsettings net port:50052 key:a.b.c.d hostip:10.131.18.133
Dismount-VHD $VHDPath
}
#
# Now boot the VM without vGPU to verify that it's initialized correctly
# If everything is OK, turn off the VM
#
if ($CreateVm)
{
Write-Output "Boot the VM and turn it OFF after it's initialized"
pause
}
#
# Add virtual GPU
#
if($AddGpu)
{
Add-VMGpuPartitionAdapter -VMName $vm
Get-VMGpuPartitionAdapter -VMName $vm
}
#
# Copy the driver store to the VM
#
if ($CopyDriverStore)
{
Write "Copying driver store"
Mount-vhd $VHDPath
$drive = (Get-DiskImage -ImagePath $VHDPath | Get-Disk | Get-Partition -PartitionNumber 3).DriveLetter
xcopy /s $Env:windir\system32\driverstore\* ${drive}:\windows\system32\hostdriverstore\
Dismount-VHD $VHDPath
}
#
# Export driver registry settings
#
if ($CopyRegistry)
{
Write "Copying registry"
Mount-vhd $VHDPath
$drive = (Get-DiskImage -ImagePath $VHDPath | Get-Disk | Get-Partition -PartitionNumber 3).DriveLetter
reg load HKLM\VMSettings ${drive}:\Windows\System32\config\SYSTEM
reg copy "HKLM\System\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000" "HKLM\VmSettings\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000" /s /f
reg unload "HKLM\VmSettings"
Dismount-VHD $VHDPath
}
Ladění virtuálního počítače
Ladicí program virtuálního počítače nakonfigurujte stejným způsobem jako ladění sítě na běžném klientském počítači.
Pokud se virtuální počítač nespustí nebo se zobrazí černá obrazovka:
Pomocí následujících příkazů virtuální počítač vypněte a odeberte z něj virtuální GPU:
$vm = “TEST“ remove-VMGpuPartitionAdapter -VMName $vm -AdapterId “<Id from Get-VMGpuPartitionAdapter>”Například:
remove-VMGpuPartitionAdapter -VMName $vm -AdapterId “Microsoft:9ABB95E2-D12D-43C3-B840-6F4A9CFB217B\929890BC-BB33-4687-BC1A-F72A4F1B3B3F”Spusťte virtuální počítač. Pokud se soubor úspěšně spustí, ujistěte se, že se soubory ovladačů správně zkopírují na hostDriverStore na virtuálním počítači.
Přidejte do virtuálního počítače vGPU pomocí příkazu
Add-VMGpuPartitionAdapter.Spusťte virtuální počítač znovu.
Další informace najdete v tématu řešení potíží.
Nastavení kontejneru
Rozdíl mezi kontejnery (označovanými také jako Host Compute System (HCS) virtuálními počítači) a úplným virtuálním počítačem je v tom, že binární soubory operačního systému a soubory úložiště ovladačů jsou mapovány na kontejner. Proto není nutné kopírovat soubory ovladačů do kontejneru, pokud nejsou potřeba v adresáři windows\system32.
Pro zabezpečené kontejnery:
- Escape sekvence ovladače jsou zakázány.
- Ovladač musí podporovat izolaci IOMMU, aby byla povolena uvnitř zabezpečeného kontejneru.
Když aktualizujete ovladač na hostiteli a spustíte nebo zastavíte GPU hostitele, změny se projeví v kontejneru.
Windows Sandbox
Tento typ kontejneru slouží k vyzkoušení rizikových aplikací. Celý obraz plochy je vzdáleně přenášen na hostitele. Nepřímý ovladač zobrazení se používá pro vzdálený přístup. Grafika VAIL se nepoužívá, takže přenesení obrazu plochy k hostiteli je pomalé.
Virtuální GPU je ve výchozím nastavení ve Windows Sandboxu zakázané. Pokud ho chcete povolit, vytvořte konfigurační soubor WSB (například config.wsb) a nastavte možnost virtuálního GPU. Spusťte sandbox kliknutím na konfigurační soubor.
Příklad konfiguračního souboru:
<Configuration>
<VGpu>Enable</VGpu>
</Configuration>
Ve výchozím nastavení má vGPU v kontejneru zakázané úniky ovladače. Je k dispozici možnost konfigurace pro povolení únikových posloupností pro ovladače. Následující příklad souboru WSB umožňuje vGPU v Sandboxu a úniky ovladače:
<Configuration>
<VGpu>EnableVendorExtensions</VGpu>
</Configuration>
Windows Sandbox podporuje adaptér GPU s "hot plug" funkcí.
Kontejner VAIL (Virtuální aplikace integrovaná místně)
Tento typ kontejneru použijte ke spouštění aplikací Win32 v hostiteli založeném na systému WCOS (Windows Core Operated System). Obraz každé aplikace v kontejneru je přesměrován na hostitele. Grafika VAIL umožňuje vzdálené připojení každého swapchainu aplikace. Úniky ovladače jsou povoleny.
Běžné požadavky na kontejnery
Požadavky na počítač jsou:
- V systému BIOS musí být povoleny Vtx i Vtd (nebo jejich ekvivalenty: AMD-V, AMD-IOMMU).
- Minimálně 8 GB paměti RAM.
- Více než 5 GB místa na systémovém disku.
Nastavení ladicího programu jádra pro Windows Sandbox
Použití CMDIAG
Služba Container Manager (cmservice) řídí Hyper-V izolované kontejnery. CMDIAG.EXE je aplikace, která je dostupná při instalaci funkcí Hyper-V a Kontejnerů. Umožňuje ladění v režimu jádra pro kontejnery, umožňuje podepisování testů a další.
Správce kontejnerů podporuje ladění serial a NET.
Spuštěním cmdiag.exe Debug zobrazte možnosti.
CMDIAG upraví nastavení ladicího programu v základním obrazu kontejneru. Při povolení ladicího programu jádra by měla běžet jen jedna instance kontejneru.
Před změnou nastavení ladicího programu zastavte službu HVSICS.
# Example 1:
C:\Windows\system32>sc stop hvsics
SERVICE_NAME: HVSICS
TYPE : 30 WIN32
STATE : 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x1
WAIT_HINT : 0xbb8
C:\Windows\system32>cmdiag debug -on -Serial -Force
Debugging successfully enabled. Connection string: -k com:pipe,port=\\.\pipe\debugpipe,reconnect -v
# Example 2:
C:\Windows\system32>cmdiag debug -on -net -port 51000 -key a.b.c.d -hostip 10.131.18.34
Spuštění ladicího programu na jiném počítači
Pokud používáte sériový ladicí program, můžete ho chtít spustit na jiném počítači. Pomocí kdsrv.exe spusťte ladicí program na jiném počítači. Další informace naleznete v tématu servery připojení KD.
Pokud chcete během ladění jádra zakázat vypršení časového limitu, nastavte následující klíče registru:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\UtilityVm" /v BridgeTransactionTimeout /t REG_DWORD /d 0xffffffff /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\UtilityVm" /v BridgeServerConnectTimeout /t REG_DWORD /d 0xffffffff /f
reg add "HKLM\SOFTWARE\Microsoft\HVSI" /f /v DisableResetContainer /t REG_DWORD /d 1
reg add "HKLM\SOFTWARE\Microsoft\HVSI" /f /v AppLaunchTimeoutInSeconds /t REG_DWORD /d 0x7fffffff
reg add "HKLM\Software\Microsoft\Terminal Server Client" /f /v ConnectionHealthMonitoringSupported /t REG_DWORD /d 0
reg add "HKLM\Software\Microsoft\Terminal Server Client" /f /v DisableUDPTransport /t REG_DWORD /d 1
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /f /v ConnectionHealthMonitoringSupported /t REG_DWORD /d 0
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /f /v DisableUDPTransport /t REG_DWORD /d 1
Nastavení debuggeru jádra pro kontejner VAIL
- Připojte se k hostiteli pomocí telnetu. IP adresu hostitele můžete získat z nastavení sítě v hostitelském operačním systému.
- Použijte
cmdiag.exeke konfiguraci ladicího programu.
Nastavení ladicího programu hypervisoru
bcdedit /hypervisorsettings NET port:50000 key:a.b.c.d hostip:1.1.1.1
bcdedit /set {hypervisorsettings} hypervisorbusparams 0.0.0 (if needed)
bcdedit /set hypervisordebug on
reboot host
Řešení problémů
Tato část obsahuje informace o řešení potíží s GPU-PV.
Get-VMHostPartitionableGpu
Zavolejte Get-VMHostPartitionableGpu, abyste zjistili, jestli existuje virtualizovaná GPU. Pokud je výstup prázdný, někde dojde k chybě (ovladač nenastavil limit virtualizace, virtualizace není povolená atd.).
Get-VMHostPartitionableGpu
# Example output from running the command
Name : \\?\PCI#VEN_10DE&DEV_1188&SUBSYS_095B10DE&REV_A1#6&cfd27c8&0&00400008#{064092b3-625e-43bf-9eb5-dc845897dd59}\PARAV
ValidPartitionCounts : {32, 4}
PartitionCount : 32
TotalVRAM : 2,000,000
AvailableVRAM : 1,800,000
MinPartitionVRAM : 100,000
MaxPartitionVRAM : 1,000,000
OptimalPartitionVRAM : 1,000,000
TotalEncode : 20
AvailableEncode : 20
MinPartitionEncode : 1
MaxPartitionEncode : 5
OptimalPartitionEncode : 4
TotalDecode : 40
AvailableDecode : 30
MinPartitionDecode : 2
MaxPartitionDecode : 20
OptimalPartitionDecode : 15
TotalCompute : 100
AvailableCompute : 100
MinPartitionCompute : 1
MaxPartitionCompute : 50
OptimalPartitionCompute : 30
CimSession : CimSession: .
ComputerName : WIN-T3H0LVHJJ59
IsDeleted : False
Použití událostí ETW
dxgkrnl má kanály Admin a Operational pro ETW události. Události se zobrazují v Prohlížeči událostí systému Windows: Protokol aplikací a služeb - Microsoft - Windows - Dxgkrnl.
Prohlížeč událostí obsahuje události z jiných komponent, které se účastní vytváření virtuálního počítače s GPU-PV (Hyper-V-Compute, Hyper-V-Worker, Hyper-V-VID atd.).
Použití Add-VMGpuPartitionAdapter
Při použití Add-VMGpuPartitionAdapternezadávejte funkci (například dekódování), pokud není potřeba. Pro tuto funkci nepoužívejte 0.
Použití Remove-VMGpuPartitionAdapter
Pokud se virtuálnímu počítači nepodaří spustit nebo má problémy s vykreslováním, zkuste virtuální GPU z virtuálního počítače odebrat pomocí Remove-VMGpuPartitionAdapter.
remove-VMGpuPartitionAdapter -VMName $vm -AdapterId "Microsoft:9ABB95E2-D12D-43C3-B840-6F4A9CFB217B\929890BC-BB33-4687-BC1A-F72A4F1B3B3F"
Zabránění spuštění virtuálního počítače během spouštění
set-vm -AutomaticStartAction Nothing -VmName TEST
Události v prohlížeči událostí
Přidejte události do kanálu prohlížeče událostí, které pomáhají identifikovat problémy se spuštěním vGPU. Události najdete v části "Protokoly aplikací a služeb\Microsoft\Windows\Dxgkrnl". Kanály událostí jsou Admin a Operational.
Události se vydávají v případech, kdy:
- Vytvoří se vGPU.
- VGPU je zničeno.
- Host otevře virtuální adaptér.
Soubory událostí jsou v:
- c:\Windows\System32\winevt\Logs\Microsoft-Windows-DxgKrnl-Admin.evtx
- c:\Windows\System32\winevt\Logs\Microsoft-Windows-DxgKrnl-Operational.evtx
Zkontrolujte, jestli se vytvořila vGPU, a případné chyby.
Nastavení registru
GpuVirtualizationFlags
Klíč registru GpuVirtualizationFlags slouží k nastavení chování paravirtualizovaných GPU. Klíč se nachází v:
DWORD HKLM\System\CurrentControlSet\Control\GraphicsDrivers\GpuVirtualizationFlags
Jsou definovány následující bity:
| Bit | Popis |
|---|---|
| 0x1 | Přinutit kapacitu ParavirtualizationSupported pro všechny hardwarové adaptéry. Tento bit použijte v hostiteli. |
| 0x2 | Vynuťte limit ParavirtualizationSupported pro BasicRender. Tento bit použijte v hostiteli. |
| 0x4 | Vynutit zabezpečený režim virtuálního počítače, ve kterém budou všechny virtuální počítače považovány za zabezpečené. V tomto režimu existují omezení ovladače uživatelského režimu. Ovladač například nemůže použít Escape volání, takže selžou. Tento bit použijte v hostiteli. |
| 0x8 | Povolte párování paravirtualizovaných adaptérů s adaptérem jen pro zobrazení. Tento bit použijte na hostovaném virtuálním počítači. Spárování je ve výchozím nastavení povolené. |
GuestIoSpaceSizeInMb
Klíč registru GuestIoSpaceSizeInMb slouží k nastavení velikosti prostoru vstupně-výstupních operací hosta pro virtuální gpu v megabajtech. Výchozí hodnota je 1 000 MB (1 GB). Klíč se nachází na adrese:
DWORD HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Paravirtualization\GuestIoSpaceSizeInMb
Hostovaný vstupně-výstupní prostor v současné době implementuje přidělení viditelné procesorem. Úložiště pro přidělení viditelné procesorem v hostiteli je připnuté v paměti a namapováno na prostor vstupně-výstupních operací hosta. V hostu se virtuální adresa v uživatelském režimu přidělení otočí do oblasti prostoru vstupně-výstupních operací. V některých systémech Haswell má procesor 36bitové fyzické adresy. Hyper-V v těchto systémech má omezenou velikost I/O prostoru.
Zakázání izolace IOMMU pro zabezpečené virtuální počítače
Pokud ovladač nepodporuje izolaci IoMmu, pomocí následujícího nastavení registru během vývoje zakažte izolaci IoMmu.
`DWORD HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\IoMmuFlags = 8`
Omezení počtu virtuálních funkcí
Ve výchozím nastavení je počet virtuálních funkcí vystavených adaptérem, který podporuje paravirtualizaci GPU, 32. Toto číslo znamená, že adaptér lze přidat do 32 virtuálních počítačů za předpokladu, že každý virtuální počítač má jeden adaptér.
Pomocí následujícího nastavení registru můžete omezit počet vystavených virtuálních funkcí.
DWORD HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\NumVirtualFunctions
Pokud například nastavíte NumVirtualFunctions na hodnotu 1, můžete adaptér přidat pouze do jednoho GPU jednou. Toto nastavení je užitečné, když má počítač více adaptérů GPU, které podporují GPU-PV a chcete přiřadit každý adaptér virtuálnímu počítači.
Add-VMGpuPartitionAdapter neumožňuje určit, který adaptér se má přidat. Pokud se tedy do virtuálního počítače přidají dva adaptéry, oba můžou získat stejný GPU-PV adaptér z hostitele.
Aktualizace WDDM 2.4 DDI
Následující aktualizace DDI podporují paravirtualizaci GPU v WDDM 2.4.
Přidání funkce DXGK_VIDMMCAPS
Funkce ParavirtualizationSupported se přidá do struktury DXGK_VIDMMCAPS. Hostitelský KMD nastaví tento strop, pokud implementuje všechny DDI popsané v této části.
Privátní data ovladače předávaná prostřednictvím DDI
UMD používá různé DDI k výměně soukromých informací s odpovídající KMD. Když se UMD spustí na hostovaném virtuálním počítači, dojde v oddílu hostitele k odpovídajícímu volání DDI KMD. Proto UMD:
- Nelze předat žádné ukazatele v privátních datech.
- V privátních datech nelze předat žádné popisovače.
- Nemělo by se instruovat KMD, aby prováděl globální změny stavu GPU, protože tato změna by mohla ovlivnit jiné spuštěné virtuální počítače.
Přidání příznaku VirtualMachineProcess pro DxgkDdiCreateProcess
Operační systém vytvoří pracovní proces virtuálního počítače pro každý spuštěný virtuální počítač. Dxgkrnl vytvoří odpovídající DXGPROCESS a zavolá DxgkDdiCreateProcess s nastaveným příznakem VirtualMachineWorkerProcess. V tomto kontextu procesu nedochází k vytváření zdrojů pro vykreslování ani ovladačů. Ovladač tedy může vynechat přidělování určitých prostředků.
Operační systém vytvoří v hostiteli DXGPROCESS pro každý proces na virtuálním počítači hosta, který používá GPU. Dxgkrnl volá DxgkDdiCreateProcess s příznakem VirtualMachineProcess nastaveným. Každý proces DXG virtuálního počítače patří do stejného procesu EPROCESS jako pracovní proces virtuálního počítače.
Aktualizace DxgkDdiQueryAdapterInfo
Struktura DXGKARG_QUERYADAPTERINFO se aktualizuje tak, aby zahrnovala následující pole pro podporu paravirtualizace:
Přidá se příznak člen, který umožňuje Dxgkrnl označit následující:
- Nastaví VirtualMachineData, aby bylo indikováno, že volání pochází z virtuálního počítače.
- Nastaví SecureVirtualMachine označující, že virtuální počítač běží v zabezpečeném režimu.
hKmdProcessHandle se přidá, což ovladači umožňuje identifikovat a používat správný kontext procesu na straně hostitele při zpracování dotazů pocházejících z hostovaného virtuálního počítače.
Aktualizace DxgkDdiEscape
hKmdProcessHandle člen je přidán do struktury DXGKARG_ESCAPE, aby mohl ovladač identifikovat a používat příslušný procesní kontext na straně hostitele při zpracování úniků pocházejících z virtuálního počítače.
Příznak VirtualMachineData je přidán do struktury D3DDDI_ESCAPEFLAGS, aby označoval, že je volána funkce DxgkDdiEscape z virtuálního počítače.
Fyzický přístup k přidělení GPU
V současné době ovladač neimplementuje fyzický přístup k přidělením. Ovladač musí podporovat GpuMmu.
Aktualizace WDDM 2.5 DDI
U WDDM 2.5 jsou pro podporu paravirtualizace vyžadovány také následující změny DDI.
Signalizace událostí hosta hostitelským kmD
Existují scénáře bez virtualizace, když služba KMD potřebuje signalizovat událost vytvořenou službou UMD. Aby bylo možné takové scénáře zpracovat při použití paravirtualizace, musí KMD na hostiteli signalizovat událost vytvořenou v hostu. Pro tento účel bylo přidáno zpětné volání DxgkCbSignalEvent. KMD může také použít toto zpětné volání k signalizování událostí hostitelských procesů.
Podpora popisovačů poskytovaných službou UMD na virtuálním počítači
Některé zpětná volání ovladačů přijímají Dxgkrnl přidělení nebo zpracování prostředků, které předá UMD, například:
Volání na hostiteli musí být v kontextu stejného vlákna, které zavolalo funkci DxgkDdiXxx.
Uvažujme například, že bez virtualizace KMD volá DxgkCbAcquireHandleData v kontextu uživatelského vlákna, které volá D3DKMTEscapekterý volá DxgkDdiEscape.
Když služba UMD běží na virtuálním počítači, zná pouze popisovače přidělení hosta a nemůže předávat tyto popisovače službě KMD, protože služba KMD běží v hostiteli. UMD v hostovaném volá D3DKMTEscape a KMD v hostiteli obdrží odpovídající volání DxgkDdiEscape. KmD musí volat DxgkCbAcquireHandleData v kontextu tohoto vlákna.
Aby bylo možné přeložit přidělení hosta nebo popisovač prostředku na odpovídající popisovač hostitele, přidá se D3DDDI_ESCAPEFLAGS::D riverKnownEscape řídicí příznak ovladače.
Když zavoláte D3DKMTEscape s příznakem DriverKnownEscape:
Nastavte D3DKMT_ESCAPE::Type na D3DKMT_ESCAPE_DRIVERPRIVATE.
Nastavte D3DKMT_ESCAPE::pPrivateDriverData tak, aby odkazoval na známou strukturu únikového mechanismu ovladače definovanou v následující části. Každá struktura začíná D3DDDI_DRIVERESCAPETYPE hodnotou.
Pokud se nepoužívá virtualizace, přeložený popisovač je stejný jako vstupní popisovač.
Jsou definovány následující známé únikové sekvence pro ovladače.
Následující fragment kódu ukazuje, jak použít příznak DriverKnownEscape.
D3DDDI_DRIVERESCAPE_TRANSLATEALLOCATIONEHANDLE Command = {};
Command.EscapeType = D3DDDI_DRIVERESCAPETYPE_TRANSLATEALLOCATIONHANDLE;
Command.hAllocation = hAlloc;
D3DKMT_ESCAPE Args = {};
Args.hAdapter = hAdapter;
Args.Flags.DriverKnownEscape = TRUE;
Args.Type = D3DKMT_ESCAPE_DRIVERPRIVATE;
Args.pPrivateDriverData = &Command;
Args.PrivateDriverDataSize = sizeof(Command);
Status = D3DKMTEscape(&Args);
Aktualizace WDDM 2.6 DDI
Od WDDM 2.6 (Windows 10 verze 1903) byly provedeny následující aktualizace pro podporu paravirtualizace:
Ovladač může použít příznak DXGK_ALLOCATIONINFOFLAGS::ACCESSEDPHYSICKY ve virtuálním počítači. Před WDDM 2.6 nemohl ovladač použít tento příznak ve virtuálním počítači a vytvoření přidělení s tímto příznakem selhalo.
UmD může ve virtuálním počítači používat Pfnd3dkmtUpdateallocationproperty. Před WDDM 2.6 by toto volání selhalo.