Livemigration auf GPU-P-Geräten

In diesem Artikel wird das funktionale Design der Livemigration von heterogenen Computegeräten (GPUs, NPUs usw.) beschrieben, die über die SR-IOV-Partitionierung (Single Root I/O Virtualization) virtualisiert werden. Geräte, die die Partitionierung über die WDDM- und MCDM-Treibermodelle unterstützen, sind jetzt ein integraler Bestandteil unserer Virtualisierungsangebote. Daher ist es wichtig, die Livemigration zu unterstützen und unsere Virtualisierungsabstraktionen so zuverlässig wie möglich zu machen, um die Auswirkungen auf die Kunden zu minimieren, wenn sich die Ressourcenzuweisungen ändern müssen. In diesem Artikel wird auch die schnelle Migration dieser Geräte beschrieben.

Die Livemigration wird ab Windows 11, Version 24H2 (WDDM 3.2) unterstützt. Im Allgemeinen handelt es sich um eine Erweiterung der GPU-Paravirtualisierungs-(GPU-P-)DDIs für Treiber, die die Funktion verfügbar machen. MCDM-Treiber, die die GPU-P-Virtualisierungsschnittstellen implementieren, können optional auch diese Livemigrationsschnittstellen implementieren, einschließlich ihrer Erweiterung mit Triageereignissen.

In diesem Artikel bezieht sich „GPU“ auf Geräte, die das GPU-P-Virtualisierungsframework implementieren, ganz gleich, ob es sich um WDDM oder MCDM und GPU, NPU oder ein anderes heterogenes Computegerät handelt.

Arten und Zweck der Ressourcenmigration

Die Ressourcenmigration stellt eine Möglichkeit dar, eine Virtualisierung auf neue physische Ressourcen zu verschieben. Es gibt verschiedene Möglichkeiten, wie die Virtualisierung verschoben werden kann, darunter:

• Komplettes Herunterfahren. Die virtuelle Hauptplatine kann direkt heruntergefahren und die Ausführung der virtuellen Ressourcen beendet werden. Alle Anwendungen, die nicht powerhit-tolerant sind, verlieren die Daten, mit denen sie arbeiten, und der gesamte Gerätezustand wird zurückgesetzt. Die virtuelle Festplatte (Virtual Hard Disk, VHD) kann dann auf einem anderen Hostcomputer virtualisiert werden, was zu einem Kaltstart führt.

• „Weiches“ Herunterfahren. Diese Art des Herunterfahrens unterscheidet sich von dem kompletten Herunterfahren dadurch, dass sie lediglich die Anfrage an das Gastbetriebssystem sendet. Das Gastbetriebssystem verteilt dann den Power-Down-Mechanismus an Anwendungen, um ein sauberes Herunterzufahren zu ermöglichen. Anwendungen können diese Benachrichtigung verwenden, um alle Daten sicher zu speichern und beim Start neu zu registrieren, obgleich dies von der Programmierung jeder Anwendung abhängig ist. Beim weichen Herunterfahren muss ein Gastbetriebssystem diesen Mechanismus des sauberen Herunterfahrens unterstützen und die entsprechenden Dienste müssen den aktuellen Zustand speichern und beim Neustart neustarten.

• Ruhezustand. Diese andere vom Gast entwickelte Technologie ermöglicht es dem Gast, in einen schnellen Ruhezustand überzugehen, in dem alle Anwendungsprozesse eingefroren werden, der Gerätestatus in den CPU-Speicher geleert wird und der gesamte Speicher in den Speicher gesendet wird, damit die Hardware heruntergefahren werden kann. Anschließend kann die VM-Speicher-VHD auf einem anderen Computer neu gestartet werden, der Speicher wird geladen, der Gerätezustand wird wiederhergestellt und die Prozesse werden erneut aktiviert. Der Ruhezustand ist nur für Gastbetriebssysteme verfügbar, die ihn unterstützen. Es ist ein ziemlich invasiver Prozess, der von der Stabilität des Gastes abhängt, aber er bietet einen Mechanismus zur Wiederherstellung von Anwendungsprozessen mit einem Status, den die Abschaltmechanismen nicht bieten.

• Schnelle Migration (auch als VM Speichern und Wiederherstellen bezeichnet). Bei dieser Technologie wird der virtuelle Computer angehalten (die vCPUs stoppen die Planung) und alle Zustände, die für die Wiederherstellung des Zustands auf den neuen physischen Ressourcen benötigt werden, werden innerhalb des Host-Betriebssystems gesammelt – einschließlich des Speichers des virtuellen Computers und des Zustands aller Geräte. Dieser Zustand wird dann an den neuen Host übertragen, der einen virtuellen Computer mit allen geladenen vCPU-Kontexten erstellt, den Speicher dem Speicherplatz des virtuellen Computers zuordnet und die Gerätezustände wiederherstellt. Ein PowerOnRestore startet dann die Ausführung der vCPUs neu. Diese Technologie ist unabhängig vom Gastbetriebssystem und hängt nicht von der Ausführung in der Gastumgebung ab, so dass sie eine zuverlässigere Methode zur Aufrechterhaltung des Prozess- und Gerätestatus ist als der Ruhezustand (Hibernation). Der Virtualisierungsbenutzer kann eine erhebliche Downzeit feststellen, da der Speicher des virtuellen Computers viele GBs groß sein und Übertragungszeiten spürbar sein können.

• Livemigration. Wenn wir die Option haben, Inhalte zu übertragen, während die virtualisierten Ressourcen noch aktiv sind und wir Inhalte nachverfolgen können, die verunreinigt werden, können wir wichtige Inhalte übertragen, während die Virtualisierung aktiv bleibt. Wenn der virtuelle Computer angehalten wird, müssen viel weniger Inhalte übertragen werden, und wir können die Zeit minimieren, in der die Virtualisierung nicht ausgeführt wird. Das Ergebnis ist eine Minimierung der Auswirkungen auf die Endnutzer, da alle Vorgänge während der Migration ungehindert weiterlaufen und die Auswirkungen auf den Ressourcenverbrauch so weit wie möglich reduziert werden. Insbesondere können Ausfallfristen (externe Zeitbeschränkungen für den Virtualisierungsausfall, z. B. TCP und andere Protokolltimeouts mit externen Endpunkten), minimiert oder beseitigt werden.

Mit jedem Fortschritt wird ein Teil (oft der größte Teil) des Bewusstseins des Kunden über die Änderung der physischen Zuordnung einer Virtualisierung reduziert oder beseitigt, wodurch die Virtualisierung für den Benutzer immer vollständiger und transparenter wird. Zusammen mit anderen Technologien (wie der Host-Crash-Isolation), die die Abhängigkeiten des Kunden von der Infrastruktur aufheben, bringt sie unsere Virtualisierungslösung dem Ideal der Auftragsunabhängigkeit und des echten ephemeren Compute näher.

Design im großen Maßstab

Livemigration überträgt Virtualisierungsinhalte von einem Quellhost zu einem Zielhost. Die Virtualisierung besteht aus verschiedenen zustandsbehafteten Geräten, die Arbeitsspeicher, Compute und Speicher enthalten können, wobei jeweils Daten von den Geräten der Quelle an die Geräte am Ziel übertragen werden müssen. Ausführende Agents, die Virtualisierungen über Cluster hinweg verwalten, kommunizieren mit Hosts, um sie über die Einrichtung der Orchestrierung für die Quellmigration eines vorhandenen virtuellen Computers (wenn der Inhalt den Host verlässt) oder für die Zielmigration auf einen neuen virtuellen Computer (um den Inhalt zu empfangen) zu informieren. Die wichtigsten Akteure dieser Interaktion sind im folgenden Diagramm zu sehen.

:

Epochen des Quellhosts

Das folgende Diagramm veranschaulicht quellseitige Migrationsstatus.

:

Quellseitiges Hochfahren

Wenn ein Host im Allgemeinen startet, meldet die KMD Gerätefunktionen über verschiedene Initialisierungsaufrufe an den Kernel.

Wenn die KMD denDxgkDdiQueryAdapterInfo-Aufruf für DXGKQAITYPE_GPUPCAPS-Daten empfängt, kann sie die festlegen, dass das Bit der LiveMigration-Fähigkeit DXGK_GPUPCAPS hinzugefügt wird. Wenn KMD dieses Bit festlegt, gibt sie an, dass der Treiber die Livemigration unterstützt.

Eine Voraussetzung für die Unterstützung der Livemigration ist die Unterstützung der Nachverfolgung geänderter VRAM-Seiten in allen GPU-lokalen Speichersegmenten, wie unter Dirty-Bit-Nachverfolgung beschrieben. Diese Unterstützung wird über andere DxgkDdiQueryAdapterInfo-Aufrufe für andere angegebene Informationstypen gemeldet. Ein Treiber, der die Unterstützung für die Livemigration meldet, muss auch die Unterstützung für die Dirty-Bit-Nachverfolgung melden. Wenn die Livemigration unterstützt wird, die Dirty-Bit-Nachverfolgung jedoch nicht, so ist dies eine ungültige Konfiguration, und Dxgkrnl kann den Adapter nicht starten.

Virtuelle Computer online

Sobald der Host hochgefahren ist und die Management-Stacks online sind, wird die Aktivität des virtuellen Computrs online geschaltet. Anforderungen für das Starten und Beenden von VMs treffen ein, und es werden GPU-P vGPUs angezeigt, die in diese Virtualisierungen projiziert wurden.

Unter der Annahme , dass die Funktion auf Dirty-Bit-Ebene Dxgkrnl die DxgkDdiStartDirtyTracking nach dem Reservieren der VRAM-Ressourcen für eine VF (virtuelle Funktion) aufruft, sodass das System die VRAM-Reinheit in dem Fall nachverfolgen kann, wenn die VF später an einem Migrationsszenario teilnimmt.

Beim Start der VM wird der Zugriff auf die Interrupt-Tabelle abgefangen, um die Interrupt-Unterstützung zu virtualisieren, und zwar für die gesamte Lebensdauer der VM.

Senden der Livemigration vorbereiten

Der Management-Stack sendet das Ereignis für den Beginn der Live-Migration, wenn es von seinen Steuerungen angezeigt wird, und das Management der Migrationszustandsmaschine sammelt alle Zustände des virtuellen Geräts, die während der gesamten Lebensdauer der Virtualisierung unveränderlich sind (Konfigurationsmetriken der vGPU-Partition), um die vGPU auf dem Ziel zu rekonstruieren. Sobald sie fertig sind, wird der Prozess der Vorbereitung der Transportpuffer und die Initialisierung des Transport-Stacks gestartet.

Diese Epoche generiert einen Aufruf an die eingeführte DxgkDdiPrepareLiveMigration-DDI. KMD sollte die PF/VF-Zeitplanungsrichtlinien festlegen, die dafür sorgen, dass die Livemigration Dirty-Inhalte aus dem VRAM des Hosts streamen kann und gleichzeitig eine gute Leistung für die VF beibehält. Wenn die Dirty-Nachverfolgung als nicht performant gemeldet wird, wird an diesem Punkt die Dirty-Nachverfolgung gestartet.

Senden der Livemigration

:

Anschließend beginnt die aktive Phase der modifizierten VRAM-Übertragung. In dieser Phase werden Aufrufe über die Dirty-Bitplane-DDI getätigt, um Momentaufnahmen des VF-Framebuffers abzurufen und diese Seiten dann von der GPU in die zuvor vorbereiteten CPU-Puffer auszulagern.

In dieser Übertragung folgt eine Phase, in der der virtuelle Computer und alle seine virtuellen Geräte angehalten werden. Der VF kann nicht mehr für den Gast geplant werden, und zu diesem Zeitpunkt sollten alle zusätzlichen Zeitintervalle, die der PF zur Fertigstellung der Auslagerung von Inhalten übergeben werden können, erfolgen. Da sowohl der VF als auch die vCPU auf dem virtuellen Computer angehalten werden, sollten nach diesem Punkt keine weiteren Änderungen an Inhalten, die migriert werden (CPU oder gerätelokaler Arbeitsspeicher), vorgenommen werden.

Senden der angehaltenen Migration

Die letzten Iterationen der Dirty-Seiten werden während der Pause übertragen. An diesem Punkt wird ein Aufruf gemacht, um alle letzten Teile des Geräte- und Treiberstatus zu sammeln, die während der aktiven Phase veränderbar waren und bei der früheren Vorbereitung nicht übertragen werden konnten. Dieser Zustand kann jede Zustandsrekonstruktion sein, die auf der anderen Seite benötigt wird, jede Verfolgungsstruktur oder generell alle Informationen, die notwendig sind, um die Wiederherstellung des VF-Zustands auf der Zielseite abzuschließen.

Nachbereitung der Livemigration

Sobald die VM und alle ihre virtuellen Geräte ihren Status auf ihre neuen physischen Realisierungen übertragen haben, kann die Quellseite die Reste der VM aufräumen. Die Puffer und andere Migrationszustände werden gelöscht, und die vGPU wird zerstört.

Epochen des Zielhosts

Das folgende Diagramm veranschaulicht zielseitige Migrationsstatus.

:

Zielseitiges Hochfahren

Der Start auf dem Ziel sieht wie in der Quelle aus. Das Hochfahren erfolgt für das gesamte System, das eine Quelle und ein Ziel für verschiedene VFs während des gesamten Lebenszyklus sein kann. Der Treiber muss lediglich die Unterstützung der Livemigration angeben, um teilzunehmen.

Empfangen der Livemigration vorbereiten

Auf der Zielseite wird der virtuelle Computer so konstruiert, als ob es sich um einen neuen virtuellen Computer handelt. Der virtuelle Computer und die virtuellen Geräte werden erstellt. Dieser Erstellungsprozess umfasst die virtuelle GPU, die mit denselben Parametern erstellt wurde, mit der sie auf der Quellseite erstellt wurde. Nach der Erstellung werden die Validierungsdaten empfangen und an den Treiber übergeben, um zu überprüfen, ob die Zielseite mit der Quelle kompatibel ist, um die VM wiederherzustellen. Zu diesem Zeitpunkt sollte sichergestellt werden, dass alles, was sich auf diese Kompatibilität auswirken könnte, einschließlich Treiberversion, Firmwareversion(n) und sonstige Umgebungsstatus des Zielsystems und Treibers. Der Treiber wird so konfiguriert, dass der PF-Zugriff auf alle Zeitintervalle der Auslagerung zulässt, die normalerweise dem VF zugewiesen würden, während dieser VF noch nicht aktiv ist.

Empfangen einer Livemigration

:

Das Empfangen modifizierter Seitendaten ähnelt der Phase für die Quelle, mit der Ausnahme, dass die Auslagerungsrichtung von CPU-Puffern zu VRAM erfolgt. Alle Übertragungen erfolgen, während der VF angehalten wird, sodass die gesamte Übertragung innerhalb des VF-Budgets ausgeführt werden kann.

Starten und Bereinigen des virtuellen Computers

Sobald die gesamte VRAM-Migration abgeschlossen ist, erhält die vGPU die Möglichkeit, einen zusätzlichen zu übertragenden Zustand einzurichten (die endgültigen änderbaren Speicherdaten). Anschließend starten wir den virtuellen Computer auf dem Ziel und bereinigen den Migrationsstatus, einschließlich der Puffer, die für die Übertragung verwendet werden.

Leistungsziele

Ein wichtiger Bestandteil der Livemigration ist die Reaktionsfähigkeit. Insbesondere wird die Ausfallzeit der Virtualisierung reduziert, wenn sie nicht nach außen reagiert (entweder auf den Nutzer der Virtualisierung oder auf Endpunkte, mit denen sie weiter verbunden ist). Viele Netzwerkstapelprotokolle verfügen über Timeouts auf Remotecomputern, die recht kurz sind, bevor ein Wiederholungs-/Wiederherstellungsversuch fehlschlägt, sodass es für den Nutzer störend sein kann, wenn er unterbrochen wird. Als gemeinsames festes Ziel sollte die gesamte Pausenzeit für die Übertragung und den Start unter drei Viertel einer Sekunde (750 ms) betragen, wodurch das Timeout des Kontakts unter vielen der am häufigsten verwendeten Stapeltimeouts verschoben wird.

Darüber hinaus sollten die Leistungsänderungen am aktiven System ggf. keine anderen Endbenutzerunterbrechungen auslösen. Bei Geräten, die diese DDIs verwenden, sollte das System die Rate der TDRs nicht erheblich erhöhen, indem das geplante Zeitintervall verlangsamt wird. Jetzt erwarten wir, dass die meisten TDRs keinen langen Pakete sondern langsam reagierende Geräte sind und das Verdoppeln oder Verdreifachen der Zeit zum Ausführen eines Pakets die meisten Pakete nicht über die großen Timeouts von Sekunden hinaus verschieben dürfte. Wir sollten uns jedoch bewusst sein, dass unsere Timeouts nicht im allgemeinen Leistungsbild ausgelöst werden.

Gerätetreiber-Schnittstellen

Im Allgemeinen beziehen sich die DDIs für die Livemigration auf die allgemeinen Konzepte von WDDM und MCDM DDIs und insbesondere auf die GPU-P-Virtualisierungs-DDIs.

• hAdapter bezieht sich im Allgemeinen auf das Handletoken, das ein bestimmtes Gerät darstellt, das von diesem Treiber verwaltet wird. Systeme mit mehreren physischen Geräten, die vom System aufgezählt werden, verfügen möglicherweise über einen Treiber, der mehrere hAdapter verwaltet, sodass hAdapter für das jeweilige Gerät lokalisiert wird.

• vfIndex identifiziert, auf welche virtuelle Funktion/vDEV verwiesen wird. Es wird auf das bestimmte virtuelle Gerät lokalisiert. Es wird manchmal auch als Partitions-ID bezeichnet.

• DeviceLuid lokalisiert auch das bestimmte virtuelle Gerät, aber in der Sprache der UMED-Schnittstelle mit der Verwaltung virtueller Geräte.

• SegmentId identifiziert bestimmte VidMm-Segmentexposition, wenn auf Inhalte verwiesen wird, die auf dem Gerät gespeichert sind, z. B. VRAM-Reserve.

Hinweis zu Schnittstellendefinitionen

Dieser Artikel bezieht sich auf dynamisch angepasste Strukturen. Diese Strukturen werden über dynamisch angepasste Arrays implementiert, die von den Referenzseiten wie folgt beschrieben werden:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

wenn die Schnittstelle eine Arraygröße weiter oben in der Struktur übergibt und die Analyse des Schnittstellenobjekts dann die vielen Elemente durchläuft, wenn das Array bereitgestellt wird. Diese Deklarationen sind keine gültige C/C++, da diese Sprachen Fragmente mit statischer Größe ausdrücken. Lesen Sie zuerst die statische Struktur, und analysieren Sie sie dann dynamisch im Code.

Gerätestart- und Caps-Berichte

Die folgenden Funktionen werden DXGK_GPUPCAPS hinzugefügt:

• LiveMigration-Cap gibt die Treiberunterstützung für das Livemigrationsfeature an (im Allgemeinen die in diesem Artikel erwähnten hinzugefügten DDIs mit Ausnahme von DxgkDdiSetVirtualGpuResources2).
• ScatterMapReserve-Cap gibt die Treiberunterstützung für DxgkDdiSetVirtualGpuResources2 an, die in einer zukünftigen Version hinzugefügt wird.

KMD muss diese Caps ausfüllen, wenn das Betriebssystem DxgkDdiQueryAdapterInfo mit einer DXGKQAITYPE_GPUPCAPS-Anforderung aufruft. Das Betriebssystem fragt Caps während der Geräteinitialisierung ab, nachdem DxgkDdiStartDevice aufgerufen wurde und falls der Adapter die GPU-Partitionierung unterstützt.

Wenn der Treiber die ScatterMapReserve-Cap aufruft, muss er den hinzugefügten DXGKQAITYPE_SCATTER_RESERVE-Typ mit den folgenden zugeordneten Strukturen offenlegen, damit das Betriebssystem die Scatter-Reserve-Fähigkeiten des Treibers abfragen kann:

• DXGK_QUERYSCATTERRESERVEIN für pInputData
• DXGK_QUERYSCATTERRESERVEOUT für pOutputData

Unterstützung für Scatter-Paging

Um die Übertragung von nicht zusammenhängenden modifizierten Seiten zum und vom Framebuffer zu unterstützen, ist diese Funktion eine der ersten, die GPU-VA-Zuordnungen ausführt, die nicht durch zusammenhängende physische Adressen unterstützt werden. Die aktuellen Auslagerungsschnittstellen müssen für diese Unterstützung nicht aktualisiert werden, da es immer eine allgemeine Option war, die von den Seitentabellen unterstützt wird. Aber alle latenten Implementierungsdetails, die Annahmen über die Kontiguität machten, werden durch diese Änderung wahrscheinlich aufgedeckt. Daher ist es wichtig, zu verstehen, wie dieser Betriebssystemmechanismus die virtuellen Pagingschnittstellen ausführt, und sicherstellen, dass die Auslagerung robust für diese Änderung ist.

Insbesondere übergibt die TransferVirtual-Schnittstelle jetzt VA-Bereiche, die nicht zusammenhängend auf dem Framebuffer zugeordnet sind.

Starten der Live-Migration auf der Sende-Seite

Wenn das System die Livekomponente der Migration startet, muss die hinzugefügte DxgkDdiPrepareLiveMigration-DDI aufgerufen werden. Dieser Aufruf benachrichtigt den Treiber, dass diese Epoche begonnen hat, und ermöglicht ihm die Konfiguration der VF-Planungsrichtlinie für die Migration, die einen Teil des freien und migrierenden VF-Budgets für PF-Paging aufteilen sollte.

Dxgkrnl ruft dann die DxgkDdiSaveImmutableMigrationData-DDI von KMD auf, um Informationen über das Gerät zu sammeln, die auf der Zielseite wiederhergestellt werden sollen.

Nachdem das System die unveränderlichen Daten und Validierungsdaten erfasst und gesendet hat, beginnt die iterative Hauptschleife für das modifizierte Senden.

Iteratives Speichern/Senden

Wie im Abschnitt „Übersicht“ beschrieben, verwendet der iterierte Speichervorgang DxgkDdiQueryDirtyBitData, um eine Momentaufnahme der aktuellen Dirty-Bitplane für den VF zu Beginn jeder Iteration zu machen und verwendet den standardmäßigen DXGK_OPERATION_VIRTUAL_TRANSFER-Vorgang, um die gemeldeten modifizierten Seiten auszulagern. Wenn dieser Vorgang auf einem Gerät stattfindet, das in seinen Dirty-Tracking-Fähigkeiten gemeldet hat, dass es keine vernachlässigbare Leistungsbeeinträchtigung darstellt, aktiviert die Iterationssteuerung des Systems zunächst das Dirty-Tracking und überträgt dann den gesamten Framebuffer vor dem ersten Aufruf zur Abfrage der Dirty-Bitplane.

Bei der virtuellen Übertragung ist die wichtigste Neuerung, dass die Zuordnung nicht von zusammenhängendem VA zu zusammenhängendem PA erfolgt. Stattdessen gibt es möglicherweise getrennte Seiten von PA unter der Zuordnung. Andernfalls ist das Verhalten wie in der ursprünglichen Dokumentation zur Paging- und Dirty-Bitplane-Nachverfolgung beschrieben, und dieses Feature trägt nicht dazu bei.

Enden der Livemigration auf der Senden-Seite

Am Ende der Migration muss das System alle Geräte- und Treiberzustände erfassen, die erforderlich sind, um den Neuerstellungszustand und die Nachverfolgung abzuschließen, die noch nicht übertragen wurden. Diese Daten konnten nicht übertragen werden, da sie nicht den Unveränderlichkeitsanforderungen der früheren Migrationsdaten entsprechen und kein modifizierter VRM-Inhalt sind. Dxgkrnl ruft die hinzugefügte DxgkDdiSaveMutableMigrationData DDI auf, um dies zu tun. Die Verwendung dieser DDI ähnelt DxgkDdiSaveImmutableMigrationData.

Wenn für diesen VF keine Migrationskonfiguration mehr erforderlich ist, wird DxgkDdiEndLiveMigration aufgerufen. Alle Planungen und Zustände sollten zu einer nicht migrierenden Konfiguration zurückkehren.

Start der Livemigration auf der Empfangen-Seite

Wenn die unveränderlichen Daten auf der empfangenden Seite eingehen, übergibt das System sie direkt über einen Aufruf von DxgkDdiRestoreImmutableMigrationData an KMD.

Diese DDI sollte immer nur für VFs aufgerufen werden, die derzeit angehalten sind.

Iterative Wiederherstellung/Empfang

Auch hier funktioniert das Scatter-Paging iterativ, iterativ, aber diesmal ohne die Aufrufe zur Inspektion der Dirty-Bitplane, die mit dem von der VF reservierten Framebuffer verbunden ist, da die Dirty-Bitplane auf dem Ziel durch das Paging aufgebaut wird. Die Paging-Richtung wird umgekehrt. Inhalte in den empfangenen Puffern werden an das VRAM übertragen, wobei die Platzierung der Seiten vorgegeben wird.

Beenden der Livemigration auf der Empfangen-Seite

Sobald die Migration beendet ist, ruft das empfangende System die DxgkDdiRestoreMutableMigrationData-Funktion mit dem endgültigen Paket des wiederherzustellenden Zustands auf. Dieses Paket sollte alle Inhalte enthalten, die der Treiber zur Wiederherstellung seines Zustands und zur Nachverfolgung sowie zur restlichen Wiederherstellung des VF-Zustands übertragen musste.

Diese DDI sollte immer nur für VFs aufgerufen werden, die derzeit angehalten sind.

Nach diesem Aufruf ruft das System die DxgkDdiEndLiveMigration-Funktion des KMD auf,um der Zielseite mitzuteilen, dass sie alle Zustände rund um die Livemigration bereinigen soll, einschließlich der Wiederherstellung der normalen VF-Planung.

Kommunikation mit der UMED

Die User-Mode Emulation DLL-(UMED-)Schnittstelle wird mit der IGPUPMigration-Schnittstelle erweitert, um die Möglichkeit zum Speichern und Überprüfen von Inhalten während einer Livemigration verfügbar zu machen.

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

Während der Vorbereitungsmaßnahmen für die Livemigration, bei denen die KMD ebenfalls aufgerufen wird, hat die UMED die Möglichkeit, alle Informationen zu übermitteln, die für die Vorbereitung der UMED auf die Migration oder die Validierung, dass die Umgebung die Migration auf UMED-Ebene unterstützt, nützlich sein könnten. Es handelt sich um eine optionale Schnittstelle für UMEDs mit den Standardschnittstellenverträgen für UMED (Threading und Prozesskontext, eingeschränkte Belichtung des Betriebssystems usw.). Das Aufrufmuster imitiert die KMD-DDIs mit der zweistufigen Speicherung. Bei diesen Aufrufen gibt es keine Statusflags, wie andere Speicher-/Wiederherstellungs-UMED-Schnittstellen, da diese während der gesamten Lebensdauer des Geräts und seiner LUID gültig und konstant sein sollten.

Der veränderbare Zustand der UMED wird in der vorhandenen Speichern/Wiederherstellen-Schnittstelle übertragen. In der Vergangenheit war die Ausführung dieser Schnittstelle mit GPU-P-Treibern blockiert, dies wird jedoch aufgehoben, wenn die KMD-Unterstützung für LiveMigration meldet. Diese Verknüpfung der UMED-Legendenfunktion und der KMD-Funktion ist beabsichtigt. Die Livemigration implementiert eine schnelle Migration für die Virtualisierung dieser Geräte. Die gleiche Abfolge von Aufgaben wird ausgeführt, und Sie können die schnelle Migration (Speichern/Wiederherstellen) als den Sonderfall der Livemigration vorstellen, bei der keine aktive Übertragung vorhanden ist. Ein UMED, das Speichern/Wiederherstellen unterstützt, muss dennoch über einen KMD verfügen, der die DDIs für die Livemigration unterstützt. Ebenso muss die UMED-Schnittstelle über die IGPUPMigration-Schnittstelle informiert sein und bewerten, ob sie in ihrem Entwurf erforderlich ist, bevor die KMD eine Migration durchführen kann.

Virtualisierung von Unterbrechungen

Die physische Adressierung der Gast-Interrupt-Verwaltung muss virtualisiert werden, damit der Zugriff auf die MSI-X-Tabelle ordnungsgemäß erfolgen kann, wenn sich die zugrunde liegende Hardware während der Migration ändert. Die UMED muss die MSI-X-Interrupttabelle für alle Treiber abfangen, die die Livemigration unterstützen. Alle Lese- oder Schreibvorgänge in den Feldern „Nachricht – Obere Adresse“ und "Nachrichtenadresse“ müssen den tatsächlichen Hardwarewerten zugeordnet werden. Dxgkrnl behält die Zuordnung der virtualisierten (oder Gast-)Adresse bei und führt die Ersetzung im Aufruf-Stack bei Bedarf durch.

Das Betriebssystem verwaltet die Virtualisierung/Zuordnung der physischen Gastadressen, auf die sich die Lese- oder Schreibvorgänge der Tabelle auf der Gastseite beziehen können, zu den physischen Hostadressen, die für die tatsächliche Interrupt-Bearbeitung benötigt werden. Dieser allgemeine Pfad benötigt keine separate UMED-Implementierung oder Kernelweiterleitung, und das Betriebssystem benachrichtigt die UMED nicht, wenn das Betriebssystem die Tabelle abfangen wird. Die einzige Voraussetzung für UMED ist, dass die Gegenmaßnahmen für das Gerät für die BAR-Seiten der Tabelle festgelegt werden müssen.

Im Kernel möchte Dxgkrnl jedoch, dass die KMD die tatsächlichen Schreibvorgänge bedient. KMD implementiert dazu die hinzugefügte DxgkDdiWriteVirtualizedInterrupt-Aufruffunktion.

Ein Lesevorgang sollte nie erforderlich sein, da die UMD Schreibvorgänge lokal verfolgt (in virtualisierter / gastübersetzter Form), so dass sie keinen teuren Kernel-Sprung erfordern. Diese Nachverfolgung migriert mit dem virtuellen Gerät.

DDI-Synchronisierungs- und IRQL-Kontexte

DDI	Synchronisierungsebene	IRQL
DxgkDdiPrepareLiveMigration	0	PASSIVE
DxgkDdiEndLiveMigration	0	PASSIVE
DxgkDdiSaveImmutableMigrationData	0	PASSIVE
DxgkDdiSaveMutableMigrationData	0	PASSIVE
DxgkDdiRestoreImmutableMigrationData	0	PASSIVE
DxgkDdiRestoreMutableMigrationData	0	PASSIVE
DxgkDdiWriteVirtualizedInterrupt	0	PASSIVE
DxgkDdiSetVirtualGpuResources2	0	PASSIVE
DxgkDdiSetVirtualFunctionPauseState	0	PASSIVE
IGPUPMigration::SaveImmutableGpup	0	PASSIVE
IGPUPMigration::RestoreImmutableGpup	0	PASSIVE

Wichtige Überlegungen für die VF-Planung

Die Effizienz der Übertragung wird stark durch die Planung der Auslagerungsübertragungen auf der PF bestimmt. Je mehr Zugriff auf die Paging-Engines des Geräts der PF nutzen kann, um den Bus zu sättigen und den besten Durchsatz zu erzielen, desto leistungsfähiger ist die Übertragung im Allgemeinen und die angehaltene Übertragung im Besonderen. Je mehr Inhalte erfasst und in einer bestimmten Zeit gesendet werden können, desto besser; mindestens bis zur Netzwerksättigung.

Vorzugsweise sollte sich die Änderung der Planung nur auf die Paging-Engine und keine andere Geräteressource auswirken, jedoch lassen dies möglicherweise nicht alle VF-Planungsdesigns zu. Es ist mindestens gewünscht, dass bei der Planung:

• Nur das vom VF migrierte Budget bzw. das Budget aus dem nicht zugewiesenen VF-Zeitplan übernommen wird.
• Die Leistung für andere Virtualisierungen auf dem Computer wird nicht beeinträchtigt.

Beachten Sie, dass diese Bedingungen auf der Zielseite viel leichter erfüllt werden können, da die VF den gesamten Transfer pausiert und das gesamte Budget verfügbar ist. Auf der Quellseite erfordert es einen Ausgleich der Migrationsanforderungen und der VM-Anforderungen, wobei die ultimative Notwendigkeit besteht, die Pausenübertragungsziele zu erfüllen.