Migrazione in tempo reale nei dispositivi GPU-P

Questo articolo descrive la progettazione funzionale della migrazione in tempo reale di dispositivi di calcolo eterogenei (GPU, NPU e così via) virtualizzati tramite il partizionamento SR-IOV (virtualizzazione I/O radice singola). I dispositivi che supportano il partizionamento tramite i modelli di driver WDDM e MCDM sono ora parte integrante delle offerte di virtualizzazione. È quindi importante supportare la migrazione in tempo reale e aiutare le astrazioni di virtualizzazione a diventare al massimo affidabili per l'impatto sui clienti quando le assegnazioni di risorse devono cambiare. Questo articolo descrive anche la migrazione rapida di questi dispositivi.

La migrazione in tempo reale è supportata a partire da Windows 11 versione 24H2 (WDDM 3.2). In genere è un'estensione delle DDI della gpu paravirtualization (GPU-P) per i driver che espongono la funzionalità. I driver MCDM che implementano le interfacce di virtualizzazione GPU-P possono anche implementare queste interfacce di migrazione in tempo reale, inclusa l'estensione con eventi di valutazione.

In questo articolo la "GPU" si riferisce semplicemente ai dispositivi che implementano il framework di virtualizzazione GPU-P, sia WDDM che MCDM e se una GPU, una NPU o un altro dispositivo di calcolo eterogeneo.

Tipi e scopo della migrazione delle risorse

La migrazione delle risorse è la possibilità di spostare una virtualizzazione in nuove risorse fisiche. Esistono diversi modi in cui è possibile spostare l'esecuzione virtualizzata, tra cui:

• Potenza dura. La scheda madre virtuale può essere spenta direttamente, interrompendo l'esecuzione delle risorse virtuali. Tutte le applicazioni che non sono a tolleranza di alimentazione perdono i dati su cui operano e tutto lo stato del dispositivo viene cancellato. Il disco rigido virtuale (VHD) può quindi essere virtualizzato in un computer host diverso, che comporta un avvio a freddo.

• Risparmio di energia. Questo risparmio di energia differisce dal risparmio di energia in quanto invia semplicemente la richiesta di alimentazione al sistema operativo guest. Il sistema operativo guest distribuisce quindi il meccanismo di risparmio di energia alle applicazioni per arrestare correttamente. Le applicazioni possono usare questa notifica per archiviare in modo sicuro tutti i dati e registrarsi per il riavvio all'avvio, anche se dipende dalla programmazione di ogni applicazione. Un'alimentazione temporanea richiede un sistema operativo guest che supporta questo meccanismo di arresto pulito e i servizi appropriati per archiviare lo stato corrente e riavviare al riavvio.

• Sospensione. Questa altra tecnologia di origine guest consente al guest di passare a uno stato di alimentazione in sospensione rapida in cui tutti i processi dell'applicazione sono bloccati, lo stato del dispositivo viene eliminato alla memoria della CPU e tutta la memoria viene quindi inviata all'archiviazione per consentire l'alimentazione dell'hardware. Il disco rigido virtuale di archiviazione della macchina virtuale può quindi essere riavviato in un computer diverso e la memoria caricata, lo stato del dispositivo ripristinato e i processi non ripristinati. L'ibernazione è disponibile solo nei sistemi operativi guest che lo supportano. Si tratta di un processo abbastanza invasivo che dipende dalla stabilità guest, ma fornisce un meccanismo per ripristinare i processi dell'applicazione con stato che i meccanismi di spegnimento non forniscono.

• Migrazione rapida (nota anche come salvataggio e ripristino della macchina virtuale). Con questa tecnologia, la macchina virtuale viene sospesa (vCPU arresta la pianificazione) e tutto lo stato necessario per ripristinare lo stato nelle nuove risorse fisiche viene raccolto all'interno del sistema operativo host, inclusa la memoria della macchina virtuale e lo stato di tutti i dispositivi. Questo stato viene quindi trasferito al nuovo host che crea una macchina virtuale con tutti i contesti vCPU caricati, esegue il mapping della memoria allo spazio della macchina virtuale e ripristina gli stati del dispositivo. PowerOnRestore riavvia quindi l'esecuzione delle vCPU. Questa tecnologia è indipendente dal sistema operativo guest e non dipende dall'esecuzione nell'ambiente guest, quindi è un modo più affidabile per mantenere lo stato del processo e del dispositivo rispetto all'ibernazione. L'utente di virtualizzazione potrebbe notare un tempo di inattività significativo perché la memoria della macchina virtuale può essere molti GB e i tempi di trasferimento possono essere evidenti.

• Live Migration. Se si ha la possibilità di trasferire contenuto mentre le risorse virtualizzate sono ancora attive e è possibile tenere traccia del contenuto che viene deviato, è possibile trasferire contenuti significativi lasciando attiva la virtualizzazione. Quindi, quando la macchina virtuale viene sospesa, è necessario trasferire molto meno contenuto ed è possibile ridurre al minimo il tempo in cui la virtualizzazione non è in esecuzione. Il risultato è ridotto al minimo l'impatto dell'utente finale, poiché tutte le operazioni che si verificano durante la migrazione continuano a non essere implementate e l'impatto sul consumo delle risorse è ridotto per quanto possibile. In particolare, le scadenze di interruzione (vincoli di tempo esterni per l'interruzione della virtualizzazione, ad esempio TCP e altri timeout del protocollo con endpoint esterni) possono essere ridotte o eliminate.

Ogni progressione riduce o rimuove alcuni (spesso importanti) consapevolezza dei clienti del cambiamento nell'assegnazione fisica di una virtualizzazione, rendendo la virtualizzazione sempre più completa e trasparente all'utente. Oltre ad altre tecnologie (come l'isolamento dell'arresto anomalo dell'host) che separano le dipendenze dei clienti dall'infrastruttura, la soluzione di virtualizzazione viene spostata verso l'ideale di indipendenza dell'assegnazione e il vero calcolo temporaneo.

Progettazione su larga scala

La migrazione in tempo reale trasferisce il contenuto della virtualizzazione da un host di origine a un host di destinazione. La virtualizzazione è costituita da vari dispositivi con stato, che possono includere memoria, calcolo e archiviazione, ognuno con dati che devono essere trasferiti dai dispositivi nell'origine ai dispositivi nella destinazione. Gli agenti esecutivi che gestiscono le virtualizzazione tra cluster comunicano agli host per comunicare loro di configurare l'orchestrazione per la migrazione di origine di una macchina virtuale esistente (quando il contenuto lascia l'host) o per la migrazione di destinazione a una nuova macchina virtuale (per ricevere il contenuto). I principali attori di questa interazione sono visti nel diagramma seguente.

:

Periodi dell'host di origine

Il diagramma seguente illustra gli stati di migrazione lato origine.

:

Avvio sul lato sorgente

Quando un host viene avviato in genere, il KmD segnala le funzionalità del dispositivo al kernel tramite varie chiamate di inizializzazione.

Quando il KMD riceve la chiamata DxgkDdiQueryAdapterInfo per DXGKQAITYPE_GPUPC piattaforma di strumenti analitici dati, può impostare il bit della funzionalità LiveMigration aggiunto a DXGK_GPUPC piattaforma di strumenti analitici. Quando kmD imposta questo bit, indica che il driver supporta la migrazione in tempo reale.

Un prerequisito per il supporto della migrazione in tempo reale consiste nel supportare il monitoraggio delle pagine VRAM modificate in tutti i segmenti di memoria locale gpu, come descritto in Rilevamento dei bit dirty. Tale supporto viene segnalato tramite altre chiamate DxgkDdiQueryAdapterInfo per altri tipi di informazioni specificati. Un driver che segnala il supporto per la migrazione in tempo reale deve anche segnalare il supporto per il rilevamento dei bit dirty. Il supporto per la migrazione in tempo reale ma non il rilevamento dei bit dirty è una configurazione non valida e Dxgkrnl non riesce ad avviare l'adattatore.

Macchine virtuali online

Quando l'host viene avviato e gli stack di gestione sono online, l'attività della macchina virtuale inizia a essere online. Le richieste di avvio e arresto delle macchine virtuali iniziano ad arrivare e iniziamo a vedere le VGP GPU-P proiettate in queste virtualizzazione.

Supponendo una capacità di piano a bit dirty efficiente, Dxgkrnl chiama DxgkDdiStartDirtyTracking dopo aver prenotato le risorse VRAM per una funzione virtuale (VF), che consente al sistema di tenere traccia della pulizia VRAM nel caso in cui VF partecipi successivamente a uno scenario di migrazione.

L'avvio della macchina virtuale inizia a intercettare l'accesso alla tabella di interrupt per virtualizzare il supporto, che procede per la durata della macchina virtuale.

Preparazione dell'invio della migrazione in tempo reale

Lo stack di gestione invia l'evento per avviare la migrazione in tempo reale quando indicato dai relativi controlli e la gestione della macchina a stati di migrazione raccoglie tutto lo stato dal dispositivo virtuale non modificabile per la durata della virtualizzazione (metriche di configurazione della partizione vGPU) per ricostruire la vGPU nella destinazione. Una volta pronti, viene avviato il processo di preparazione dei buffer di trasporto e dell'inizializzazione dello stack di trasporto.

Questo periodo genera una chiamata all'introdotto DDI DxgkDdiPrepareLiveMigration . Il KmD deve stabilire i criteri di pianificazione PF/VF che forniscono la possibilità di trasmettere il contenuto dirty dalla VRAM nell'host mantenendo prestazioni corrette per il VF. Se il rilevamento dirty viene segnalato come non valido, questo punto è anche dove viene avviato il rilevamento dirty.

Invio della migrazione in tempo reale

:

Si entra quindi nella fase attiva del trasferimento VRAM dirty. Questa fase implica l'esecuzione di chiamate tramite l'DDI bitplane dirty per ottenere snapshot del framebuffer VF e quindi eseguire il paging di tali pagine dalla GPU ai buffer della CPU preparati in precedenza.

In questo trasferimento viene fornita una fase in cui la macchina virtuale e tutti i relativi dispositivi virtuali vengono sospesi. Il VF può smettere di essere pianificato per il guest, e in questo momento, qualsiasi timelice extra che può essere assegnato al pf per completare il paging del contenuto deve essere. Poiché sia il VF che la vCPU vengono sospesi nella macchina virtuale, non devono essere apportate altre modifiche al contenuto di cui viene eseguita la migrazione (CPU o memoria locale del dispositivo) dopo questo punto.

Invio della migrazione sospesa

Le ultime iterazioni delle pagine dirty vengono trasferite durante la pausa. A questo punto, viene effettuata una chiamata per raccogliere tutti gli ultimi componenti dello stato del dispositivo e del driver modificabili mentre sono attivi e non possono essere trasferiti nella preparazione precedente. Questo stato può essere qualsiasi ricostruzione di stato necessaria dall'altra parte, qualsiasi struttura di rilevamento o in genere tutte le informazioni necessarie per finalizzare il ripristino dello stato VF sul lato di destinazione.

Disinstallazione della migrazione in tempo reale

Infine, dopo che la macchina virtuale e tutti i relativi dispositivi virtuali hanno trasferito il proprio stato alla nuova realizzazione fisica, il lato di origine può pulire i resti della macchina virtuale. I buffer e altri stati di migrazione vengono cancellati e la vGPU viene eliminata definitivamente.

Periodi dell'host di destinazione

Il diagramma seguente illustra gli stati di migrazione lato destinazione.

:

Avvio sul lato di destinazione

L'avvio nella destinazione ha lo stesso aspetto dell'origine. L'avvio è per l'intero sistema, che può essere un'origine e una destinazione su diverse macchine virtuali nel corso del ciclo di vita. Il driver deve solo specificare il supporto della migrazione in tempo reale per partecipare.

Preparazione della migrazione in tempo reale

Sul lato di destinazione, la macchina virtuale viene costruita a partire come se fosse una nuova macchina virtuale. Vengono create la macchina virtuale e i dispositivi virtuali. Questo processo di creazione include la GPU virtuale, creata usando gli stessi parametri con cui è stata creata sul lato di origine. Dopo la creazione, i dati di convalida vengono ricevuti e passati al driver per verificare che il lato di destinazione sia compatibile con l'origine per ripristinare la macchina virtuale. A questo punto, deve garantire qualsiasi elemento che possa influire su tale compatibilità, tra cui la versione del driver, le versioni del firmware e altri stati di ambiente del sistema e del driver di destinazione. Il driver configurerà in modo da consentire l'accesso PF a tutti i tempi di paging che normalmente verrebbero assegnati al VF mentre tale VF non è ancora attivo.

Ricezione della migrazione in tempo reale

:

La ricezione di dati di pagina dirty è simile alla fase dell'origine, ad eccezione della direzione del paging, dai buffer della CPU alla VRAM. Tutti i trasferimenti vengono effettuati mentre la VF è sospesa, quindi l'intero trasferimento può essere eseguito entro il budget VF.

Avvio e disinstallazione della macchina virtuale

Una volta completata la migrazione della VRAM, la vGPU ha la possibilità di configurare qualsiasi stato aggiuntivo da trasferire (il salvataggio modificabile finale dei dati). Avviare quindi la macchina virtuale nella destinazione e rimuovere lo stato di migrazione, inclusi i buffer usati per il trasferimento.

Obiettivi di prestazioni

Una parte importante della migrazione in tempo reale è la velocità di risposta. In particolare, riduce al minimo il tempo di inattività della virtualizzazione a cui non risponde esternamente (sia all'utente della virtualizzazione che a qualsiasi endpoint a cui potrebbe essere connesso ulteriormente). Molti protocolli dello stack di rete hanno timeout tra computer remoti che sono abbastanza brevi prima che si verifichi un errore di ripetizione/ripristino e quindi può comportare interruzioni per l'utente quando viene eliminato. Come obiettivo fisso comune, il tempo totale di pausa per il trasferimento e l'avvio deve essere inferiore a tre quarti di secondo (750 ms), che spinge il timeout del contatto a con molti dei timeout dello stack più comuni.

Inoltre, le modifiche alle prestazioni apportate al sistema attivo non dovrebbero attivare altre interruzioni dell'utente finale, se possibile. Nei dispositivi che usano queste DDI, il sistema non dovrebbe aumentare significativamente la frequenza delle richieste pull rallentando il timelice pianificato. Ora, ci aspettiamo che la maggior parte delle richieste pull non siano pacchetti lunghi, ma dispositivi bloccati, e raddoppiare o triplicare il tempo per eseguire un pacchetto non dovrebbe eseguire il push della maggior parte dei pacchetti nei timeout di grandi dimensioni di secondi. Ma dobbiamo essere consapevoli di non attivare i timeout nell'immagine generale delle prestazioni.

Interfacce del driver di dispositivo

In genere, le DDI della migrazione in tempo reale fanno riferimento ai concetti generali delle DDI WDDM e MCDM e alle DDI della virtualizzazione GPU-P in particolare.

• hAdapter si riferisce in genere al token di handle che rappresenta un dispositivo specifico gestito da questo driver. I sistemi con più dispositivi fisici enumerati dal sistema potrebbero avere un driver che gestisce più hAdapter, quindi hAdapter localizzare il dispositivo specifico.

• vfIndex identifica la funzione virtuale/vDEV a cui viene fatto riferimento. Si localizza con il dispositivo virtuale specifico. A volte viene chiamato anche ID partizione.

• DeviceLuid localizza anche il dispositivo virtuale specifico, ma in basso nella lingua dell'interfaccia UMED con la gestione dei dispositivi virtuali.

• SegmentId identifica l'esposizione specifica del segmento VidMm quando si fa riferimento al contenuto archiviato nel dispositivo, ad esempio la riserva VRAM.

Nota sulle definizioni di interfaccia

Questo articolo si riferisce a strutture con dimensioni dinamiche. Queste strutture vengono implementate tramite matrici con dimensioni dinamiche, che le pagine di riferimento descrivono come segue:

    size_t       ArraySize;
    ElementType  Array[ArraySize];

dove l'interfaccia passa una dimensione di matrice in precedenza nella struttura e l'analisi dell'oggetto di interfaccia quindi esegue l'iterazione su tale numero di elementi quando viene fornita la matrice. Queste dichiarazioni non sono valide per C/C++ perché tali linguaggi esprimono frammenti con dimensioni statiche. Leggere prima nella struttura con dimensioni statiche e quindi analizzare in modo dinamico nel codice.

Creazione di report di avvio e limite del dispositivo

Per DXGK_GPUPC piattaforma di strumenti analitici vengono aggiunte le funzionalità seguenti:

• Il limite LiveMigration indica il supporto del driver per la funzionalità di migrazione in tempo reale (in genere, le DDI aggiunte menzionate in questo articolo, ad eccezione di DxgkDdiSetVirtualGpuResources2).
• Il limite ScatterMapReserve indica il supporto dei driver per DxgkDdiSetVirtualGpuResources2, che verrà aggiunto in una versione futura.

Il KMD deve compilare questi limiti quando il sistema operativo chiama DxgkDdiQueryAdapterInfo con una richiesta di DXGKQAITYPE_GPUPC piattaforma di strumenti analitici. Il sistema operativo esegue query sui limiti durante l'inizializzazione del dispositivo dopo la chiamata di DxgkDdiStartDevice e quando l'adattatore supporta il partizionamento GPU.

Se il driver restituisce il limite ScatterMapReserve, deve esporre il tipo aggiunto DXGKQAITYPE_SCATTER_RE edizione Standard RVE con le strutture associate seguenti in modo che il sistema operativo possa eseguire una query sulle funzionalità di riserva a dispersione del driver:

• DXGK_QUERYSCATTERRE edizione Standard RVEIN per pInputData
• DXGK_QUERYSCATTERRE edizione Standard RVEOUT per pOutputData

Supporto del paging a dispersione

Per supportare il trasferimento di pagine dirty non contigue da e verso il framebuffer, questa funzionalità è una delle prime ad eseguire mapping GPU-VA non supportati da indirizzi fisici contigui. Le interfacce di paging correnti non devono essere aggiornate per questo supporto perché è sempre stata una possibilità generale supportata dalle tabelle di pagina. Tuttavia, qualsiasi dettaglio di implementazione latente che ha fatto ipotesi sulla contiguità è probabilmente esposto da questa modifica. È quindi importante comprendere questo meccanismo del sistema operativo, come esegue le interfacce di paging virtuale e assicurarsi che il paging sia affidabile per questa modifica.

In particolare, l'interfaccia TransferVirtual passa ora intervalli va non mappati contiguamente nel framebuffer.

Avvio della migrazione in tempo reale sul lato invio

Quando il sistema avvia il componente attivo della migrazione, deve chiamare la DDI DxgkDdiPrepareLiveMigration aggiunta. Questa chiamata notifica al driver che questo periodo è stato avviato e consente di configurare i criteri di pianificazione VF per la migrazione, che devono ripartire alcuni dei budget gratuiti e di migrazione VF per il paging PF.

Dxgkrnl chiama quindi dxgkDdiSaveImmutableMigrationData DDI di KMD per raccogliere informazioni sul dispositivo da ripristinare sul lato di destinazione.

Dopo che il sistema raccoglie e invia i dati non modificabili e di convalida, inizia il ciclo iterativo principale dell'invio dirty.

Salvataggio/invio iterativo

Come descritto nella sezione panoramica, l'operazione di salvataggio iterato usa DxgkDdiQueryDirtyBitData per creare uno snapshot del bitplano dirty corrente per VF all'inizio di ogni iterazione e usa l'operazione di DXGK_OPERATION_VIRTUAL_TRANSFER standard per eseguire la pagina delle pagine dirty segnalate. Se questa operazione si verifica su un dispositivo che ha segnalato nelle sue funzionalità di rilevamento dirty che non è un impatto trascurabile sulle prestazioni, il controllo di iterazione del sistema abilita innanzitutto il rilevamento dirty e quindi trasferisce l'intero framebuffer prima della prima chiamata per eseguire una query sul bitplano dirty.

Per il trasferimento virtuale, il comportamento aggiornato principale consiste nel fatto che il mapping non è contiguo da VA a PA contiguo.For the virtual transfer, the primary updated behavior is that the mapping is't contiguous VA to contiguous PA. Potrebbero essere invece presenti pagine disconnesse di PA nel mapping. In caso contrario, il comportamento è come descritto nella documentazione originale di paging e di rilevamento bitplane dirty e questa funzionalità non viene aggiunta.

Lato invio end della migrazione in tempo reale

Alla fine della migrazione, il sistema deve raccogliere tutti gli stati del dispositivo e del driver necessari per completare la ricompilazione dello stato e il rilevamento che non sono ancora stati trasferiti. Non è stato possibile trasferire questi dati perché non soddisfano i requisiti di immutabilità dei dati di migrazione precedenti e non erano contenuti dirty VRAM. Dxgkrnl chiama l'DDI DDI DxgkDdiSaveMutableMigrationData . L'utilizzo di DDI è simile a DxgkDdiSaveImmutableMigrationData.

Infine, quando non è più necessaria la configurazione della migrazione in questo VF, viene chiamato DxgkDdiEndLiveMigration. Tutte le pianificazioni e lo stato devono tornare a una configurazione non di tipomigrato.

Avvio ricezione della migrazione in tempo reale

Quando i dati non modificabili arrivano sul lato ricevente, il sistema lo passa direttamente al KMD tramite una chiamata a DxgkDdiRestoreImmutableMigrationData.

Questa DDI deve essere chiamata solo per le macchine virtuali attualmente sospese.

Ripristino/ricezione iterativi

Anche in questo caso, il paging a dispersione opera in modo iterativo, ma questa volta senza le chiamate per controllare il bitplano dirty associato al framebuffer riservato dal VF, perché il bitplane dirty sulla destinazione viene costruito dal paging. La direzione del paging viene invertita. Il contenuto nei buffer ricevuti viene trasferito alla VRAM, con la posizione delle pagine dettate.

Lato ricezione end della migrazione in tempo reale

Una volta completata la migrazione, il sistema di ricezione chiama la funzione DxgkDdiRestoreMutableMigrationData del driver con il pacchetto finale di stato da ripristinare. Questo pacchetto deve fornire tutto il contenuto che è stato lasciato per il trasferimento del driver per il ripristino dello stato e del rilevamento e per il ripristino rimanente dello stato VF.

Questa DDI deve essere chiamata solo per le macchine virtuali attualmente sospese.

Dopo questa chiamata, il sistema chiama la funzione DxgkDdiEndLiveMigration di KMD per informare il lato di destinazione di pulire qualsiasi stato intorno alla migrazione in tempo reale, incluso il ripristino della normale pianificazione VF.

Comunicazioni con UMED

L'interfaccia DELLA DLL di emulazione in modalità utente (UMED) viene estesa con l'interfaccia IGPUPMigration per esporre la possibilità di salvare e convalidare il contenuto durante una migrazione in tempo reale.

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

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

Durante le azioni di preparazione della migrazione in tempo reale in cui viene chiamato il KMD, l'UMED ha la possibilità di inviare su tutte le informazioni che potrebbero essere utili per la preparazione dell'UMED per la migrazione o la convalida che il supporto ambientale la migrazione a livello di UMED. Si tratta di un'interfaccia facoltativa per UMED con i contratti di interfaccia standard per UMED (threading e contesto del processo, esposizione limitata del sistema operativo e così via). Il modello chiamante simula le DDD kmd, con il salvataggio in due fasi. In queste chiamate non sono presenti flag di stato, come altre interfacce UMED di salvataggio/ripristino, perché devono essere valide e costanti per tutta la durata del dispositivo e del relativo LUID.

Lo stato modificabile dell'UMED viene trasferito nell'interfaccia di salvataggio/ripristino esistente. In passato, questa interfaccia è stata bloccata dall'esecuzione con driver GPU-P, ma viene sbloccata quando il kmD segnala il supporto per LiveMigration. Questa legazione della funzione callout UMED e della funzionalità kmD è intenzionale. La migrazione in tempo reale è il modo in cui il sistema implementa una migrazione rapida per la virtualizzazione di questi dispositivi. Viene eseguita la stessa sequenza di attività ed è possibile concepire la migrazione rapida (Salva/Ripristino) come caso speciale della migrazione in tempo reale in cui non è presente alcun trasferimento attivo. Un UMED che supporta il salvataggio/ripristino deve comunque avere un KMD che supporta le DDI della migrazione in tempo reale. Analogamente, l'UMED deve essere a conoscenza dell'interfaccia IGPUPMigration e valutare se è necessario nella progettazione prima che il KMD possa eseguire la migrazione in tempo reale.

Virtualizzazione degli interrupt

L'indirizzamento fisico della gestione degli interrupt guest deve essere virtualizzato per poter gestire correttamente l'accesso alla tabella MSI-X quando l'hardware sottostante cambia durante la migrazione. UMED deve intercettare la tabella interrupt MSI-X per tutti i driver che supportano la migrazione in tempo reale. Eventuali letture o scritture nei campi Indirizzo superiore messaggio e Indirizzo messaggio devono essere mappati ai valori hardware effettivi. Dxgkrnl mantiene il mapping dell'indirizzo virtualizzato (o guest) ed esegue la sostituzione, se necessario nello stack di chiamate.

Il sistema operativo gestisce la virtualizzazione/mapping degli indirizzi fisici guest che le tabelle leggono o scrive possono fare riferimento al lato guest con gli indirizzi fisici host necessari per la manutenzione effettiva degli interrupt. Questo percorso comune non richiede implementazione UMED separata o inoltro del kernel e il sistema operativo non invia una notifica all'UMED quando il sistema operativo intercetta la tabella. L'unico requisito per UMED è che le mitigazioni per il dispositivo devono essere impostate per le pagine BAR della tabella.

Tuttavia, nel kernel Dxgkrnl vuole che il KMD funzioni le scritture effettive. KmD esegue questa operazione implementando la funzione di callback DxgkDdiWriteVirtualizedInterrupt aggiunta.

Non dovrebbe mai essere necessaria una lettura perché il UMD tiene traccia in locale delle scritture (in formato virtualizzato/convertito guest) in modo che non richiedano il passaggio costoso del kernel. Questo rilevamento esegue la migrazione con il dispositivo virtuale.

Contesti di sincronizzazione DDI e IRQL

Considerazioni importanti per la pianificazione VF

L'efficienza del trasferimento è fortemente determinata dalla pianificazione dei trasferimenti di paging sul PF. Maggiore è l'accesso ai motori di paging del dispositivo che il pf può usare per saturare il bus e ottenere una velocità effettiva ottimale, maggiore è l'prestazioni del trasferimento in generale e il trasferimento sospeso in modo specifico. Maggiore è il contenuto che può essere acquisito e inviato in un determinato momento, meglio; almeno fino alla saturazione della rete.

È preferibile modificare la pianificazione solo sul motore di paging e su nessun'altra risorsa del dispositivo, ma non tutte le progettazioni di pianificazione VF potrebbero consentire questo problema. Come minimo, si vuole che la pianificazione:

• Prendere il budget solo dalla migrazione di VF o dalla pianificazione VF non assegnata.
• Non degradare le prestazioni per altre virtualizzazione nel computer.

Si noti che, sul lato di destinazione, queste condizioni possono essere soddisfatte molto più facilmente perché la VF viene sospesa l'intero trasferimento e che tutto il budget è disponibile. Sul lato di origine, richiede un bilanciamento delle esigenze di migrazione e delle esigenze della macchina virtuale, con la necessità finale di soddisfare gli obiettivi di trasferimento in pausa.