Kernelmodustests von WDDM-Features
In diesem Artikel wird der Entwurf der Kernelmodustestinfrastruktur in WDDM beschrieben, die in Windows 11, Version 24H2 (WDDM 3.2) hinzugefügt wurde. Diese Infrastruktur ermöglicht das Testen und Überprüfen von Treibern, die keine D3D-Laufzeiten unterstützen, z. B. Treiber für einige NPU-Geräte. Es kann auch verwendet werden, um Treiber zu überprüfen, die D3D-Laufzeiten unterstützen, ohne die D3D-Laufzeit einzubeziehen.
Übersicht
Es gibt Szenarien, in denen neue Computegeräte, die auf WDDM oder MCDM basieren, eingeführt werden und Treiber für diese Geräte keine D3D-Laufzeiten unterstützen. Um diese Treiber zu überprüfen, wird dxgkrnl funktionen hinzugefügt, um die Validierung nur mit Kernelmodus-Thunks durchzuführen. Das heißt, ohne dass der D3D-Laufzeit- und Benutzermodustreiber (UMD) einbezogen wird.
Diese Infrastruktur ermöglicht auch das Testen des WDDM-Features mithilfe präziser Einstellungen, ohne eine D3D-Laufzeit oder eine UMD durchlaufen zu müssen, die Dinge komplizieren kann.
DDIs werden eingeführt, um einen Befehlspuffer im Kernelmodus für einen bestimmten Satz von Befehlen zu erstellen. Die Befehle sind einfach, sodass fast jeder Ausführungsknoten sie mit vorkompilierten Shadern oder anderen Mitteln ausführen kann.
Um diese Funktionalität zu unterstützen, muss der Kernelmodustreiber (KERNEL-Mode Driver, KMD) die folgende Unterstützung bereitstellen:
- Melden Sie, dass das feature DXGK_FEATURE_KERNEL_MODE_TESTING aktiviert ist.
- Implementieren Sie die DXGKDDI_KERNELMODETESTINGINTERFACE Featureschnittstelle.
- Geben Sie Informationen dazu an, welcher Ausführungsknoten das Erstellen und Ausführen der Testbefehlspuffer unterstützt.
- Unterstützen Sie die Erstellung einer Kontext-/Hardwarewarteschlange ohne private Treiberdaten. In der Regel ist das Format privater Treiberbefehle erforderlich, um eine Workload an ein Gerät zu übermitteln. Die Testschnittstelle ermöglicht die Workload-Übermittlung ohne private Treiberdaten.
- Unterstützen Sie die Ausführung von Befehlspuffern, die von pfnBuildTestCommandBuffer auf einem beliebigen Knoten des Geräts erstellt wurden, der das Feature unterstützt.
- Unterstützung eines NULL-Zuordnungshandles in Paging-DDIs (TRANSFER, FILL usw.).
Dieses Feature wird nur verwendet, wenn die Testsignierung auf dem Computer aktiviert ist.
HLK-Tests, die dieses Feature verwenden, werden entwickelt.
DDI-Änderungen
Die folgenden Strukturen und Enumerationen wurden aktualisiert, um Kernelmodustests zu unterstützen:
DXGK_FEATURE_KERNEL_MODE_TESTING wird der DXGK_FEATURE_ID-Aufzählung hinzugefügt.
SupportBuildTestCommandBuffer wird der DXGK_NODEMETADATA_FLAGS-Struktur hinzugefügt.
TestContext wird der DXGK_CREATECONTEXTFLAGS Struktur hinzugefügt.
TestQueue wird der D3DDDI_CREATEHWQUEUEFLAGS Struktur hinzugefügt.
Die folgenden DDIs, Strukturen und Enumerationen werden hinzugefügt, um Kernelmodustests zu unterstützen:
Die DXGKDDI_KERNELMODETESTINGINTERFACE Featureschnittstelle wird hinzugefügt, wobei DXGKDDI_BUILDTESTCOMMANDBUFFER::p fnBuildTestCommandBuffer als einziges Schnittstellenelement verwendet wird.
Berichterstellungsunterstützung für das Kernelmodus-Testfeature
Das Betriebssystem ruft die DxgkDdiQueryFeatureSupport-Funktion von KMD mit der hinzugefügten DXGK_FEATURE_KERNEL_MODE_TESTING Feature-ID auf, um zu überprüfen, ob der Treiber Kernelmodustests unterstützt. Der KMD muss melden, dass das Feature unterstützt wird.
Das System ruft dann DxgkDdiQueryFeatureInterface mit derselben Feature-ID auf, um den Schnittstellenfunktionspunkt für pfnBuildTestCommandBuffer abzurufen. KMD muss diese Funktion implementieren und ihren Zeiger für die DXGKDDI_KERNELMODETESTINGINTERFACE-Schnittstelle bereitstellen.
Melden von Ausführungsknoten, die Kernelmodustests unterstützen
SupportBuildTestCommandBuffer wird der DXGK_NODEMETADATA_FLAGS-Struktur hinzugefügt. KMD muss dieses Flag festlegen, um anzugeben, dass der Knoten Befehlspuffer ausführen kann, die von pfnBuildTestCommandBuffer erstellt wurden. Es wird empfohlen, so viele Knoten wie möglich das Feature zu unterstützen.
Erstellen eines Kontexts ohne private Daten
TestContext wird DXGK_CREATECONTEXTFLAGS hinzugefügt, um anzugeben, dass ein Kontext ein Testkontext ist. Dieses Kennzeichen hat nur auswirkungen, wenn die Testsignierung aktiviert ist.
Die DxgkDdiCreateContext von KMD sollte die Erstellung eines Kontexts ohne private Daten für jeden Knoten unterstützen, der die Ausführung von Befehlspuffern unterstützt, die von pfnBuildTestCommandBuffer erstellt werden. Um diese Unterstützung anzugeben, legen Sie das TestContext-Flag in Flags während der Kontexterstellung fest.
Erstellen einer Hardwarewarteschlange ohne private Treiberdaten
TestQueue wird D3DDDI_CREATEHWQUEUEFLAGS hinzugefügt, um anzugeben, dass es sich bei einer Hardwarewarteschlange um eine Testwarteschlange handelt. Dieses Kennzeichen hat nur auswirkungen, wenn die Testsignierung aktiviert ist.
Die DxgkDdiCreateHwQueue von KMD sollte die Erstellung einer Hardwarewarteschlange ohne private Treiberdaten unterstützen.
Erstellen eines Befehlspuffers
Der pfnBuildTestCommandBuffer von KMD erstellt einen Befehlspuffer mit gerätespezifischen Anweisungen für eine Reihe einfacher Befehle. KMD gibt einen Zeiger auf diese Funktion von DxgkDdiQueryFeatureInterface(DXGK_FEATURE_KERNEL_MODE_TESTING) zurück.
Ein einzelner Testbefehl wird an pfnBuildTestCommandBuffer übermittelt. Die folgenden Befehle werden derzeit unterstützt:
| Befehl | Beschreibung |
|---|---|
| D3DDDI_TESTCOMMAND_COPY | Kopiert Bytes mit virtuellen Quell- und Ziel-GPU-Adressen. |
| D3DDDI_TESTCOMMANDBUFFER_FILL | Füllt einen Speicherort mit einem Muster aus. |
Testbefehle basieren auf der Verwendung virtueller GPU-Adressen. Das Betriebssystem garantiert, dass die GPU-VAs Zuordnungen zugeordnet werden, die mit einem Standardzuordnungstyp von D3DKMT_STANDARDALLOCATIONTYPE_EXISTINGHEAP oder D3DKMT_STANDARDALLOCATIONTYPE_INTERNALBACKINGSTORE erstellt wurden.
Der generierte Befehlspuffer und private Daten werden zurück in den Benutzermodus zurückgegeben. Wenn der Befehlspuffer zur Ausführung übermittelt wird, wird der Aufruf aus dem Benutzermodus gesendet. Eine schädliche Anwendung könnte den Inhalt des Puffers und der privaten Daten ändern. Es liegt in der Verantwortung von KMD, sowohl den Befehlspuffer als auch die privaten Treiberdaten zu überprüfen, um Fehlerüberprüfungen zu vermeiden.
Der generierte Befehlspuffer sollte keine privilegierten Anweisungen enthalten.
Ein Clienttreiber für den Benutzermodus (z. B. Cuda) sendet den generierten Befehlspuffer für die Ausführung mit D3DKMTSubmitCommand oder D3DKMTSubmitCommandToHwQueue. In Zukunft wird der Pufferinhalt als Teil der Benutzermodusübermittlung übermittelt.
Wenn ein generierter Befehlspuffer zur Ausführung übermittelt wird, wird sichergestellt, dass der Befehlspuffer Geräteanweisungen für einen einzelnen Testbefehl enthält.
Der generierte Befehlspuffer wird an den Knoten übermittelt, der dem an pfnBuildTestCommandBuffer übergebenen hContext entspricht.
Die Größe des DMA-Puffers (pDmaBuffer) ist auf 4 KB begrenzt, und die Größe der DMA-Privaten Treiberdaten (pDmaBufferPrivateData) ist auf 1 KB beschränkt.