Appunti Sistemi operativi - parte 8

Virtualizzazione della CPU

Virtualizzare la CPU vuol dire andare ad emulare la CPU per poter far in modo che dei guest ready system possano essere eseguiti utilizzando le istruzioni della CPU emulata. Il problema come precedentemente anticipato è che i sistemi tradizionali assumono che quando vengono ad essere eseguiti in modalità kernel possano eseguire istruzioni privilegiate come ad esempio istruzioni che permettono di manipolare i registri di controllo del processore come i registri di stato, che permettano di eseguire istruzioni che gestiscono le eccezioni come page fault, gli interrupt, la traduzione degli indirizzi e l'accesso della CPU ai dispositivi di I/O. Tutta la parte delle istruzioni privilegiate che un kernel esegue sono della tipologia descritta.

Il problema è che il VMM espone un'emulazione di questi meccanismi ma se questi meccanismi vengono ad essere evocati in qualche modo nel guest operating system abbiamo che viene ad essere usata.

La seguente tecnica che prende il nome di De-privileging. Questa tecnica è una forma di coesistenza tra i guest ready system e gli hypervisor in cui si assegnano diversi livelli di privilegio; tipicamente abbiamo che l'hypervisor viene ad essere eseguito in kernel mode e la virtual machine intesa come guest ready system e poi la parte applicativa viene ad essere eseguita in user mode. Per poter però distinguere la parte di virtual machine che esegue istruzioni privilegiate e quella che non esegue istruzioni privilegiate si dice che il guest ready system viene ad essere eseguito in virtual kernel mode mentre gli altri processi e la parte applicativa vengono ad essere eseguiti in virtual user mode. Quando il SO guest tenta in qualche modo di usare istruzioni sensibili l'hypervisor intercetta queste istruzioni sensibili, innesca una trap, ad una trap c'è una ISR dentro l'hypervisor e dentro questa ISR l'hypervisor risolve l'istruzione sensibile.

959Se supponiamo ad esempio di avere un clear interrupt del guest operating system deve essere applicato alla CPU virtuale, quello che succede quindi è che il clear interrupt viene intercettato dall'hypervisor, l'hypervisor scatena una trap e dentro l'hypervisor viene ad essere configurato il processore virtuale per esempio facendo il clear dell'interrupt. Questa tecnica prende il nome di trap-and-emulate.

960Il problema sta nel fatto che non tutte le istruzioni privilegiate possono essere intercettate e quindi vengono ad essere attivate con delle trap. Ad esempio nei processori Intel non tutte le istruzioni sensibili generano una trap. Nei processori Intel esistono 4 livelli di protezione che prendono il nome di ring, questi ring servono per proteggere i programmi da altri programmi, per definire dei livelli di privilegi che possono essere più di 2 nel caso in esempio 4.

961In questo caso diventa più difficile gestire la virtualizzazione tramite

trap-and-emulate perché supponiamo di avere il caso in cui abbiamo i 4 ring del processore Intel, ovviamente abbiamo che

Nel ring 0 abbiamo quindi tutto l'hypervisor con l'emulazione e la gestione degli interrupt fisici, nel ring 1 abbiamo istruzioni privilegiate e anche qui abbiamo un vettore delle interruzioni che però non può gestire direttamente gli hardware interrupt. Supponiamo che l'applicazione generi una system call, poiché abbiamo una system call abbiamo che viene ad essere generata una trap che viene ad essere intercettata dal ring 0, il ring 0 capisce che questa applicazione viene da un'applicazione del guest operating system e quindi rilancia la trap al ring 1 il quale gestirà la system call. Un interrupt hardware viene ad essere gestito dal ring 0 che sa in quel vettore che quell'interruzione era destinata ad un SO ospite e quindi richiama il vettore di interruzione relativo al ring 1 e va quindi nel guest.

operating system. Per le istruzioni privilegiate abbiamo che quando nel ring 1 si ha un’istruzione privilegiata si ha che queste causano delle trap che vanno a livello emulativo e poi ritornano nel livello emulativo. Per le eccezioni che non generano delle trap si ha un problema e questo pone dei limiti all’architettura x86, fino a quando tutte le istruzioni privilegiate del guest operating system innescano una trap il percorso è quello indicato sopra, il problema è che non tutte le istruzioni privilegiate del x86 generano una trap. 962L’architettura x86 ovviamente non è facilmente virtualizzabile in quanto una parte delle istruzioni privilegiate non genera una trap e questo causa una difficoltà nel gestire le istruzioni privilegiate. Andiamo a vedere come è possibile e con quale tecnica virtualizzare le CPU ritornando poi nelle CPU Intel. 963L’Intel VT ha dei banchi TLB e quindi mantiene una TLB a livello hardware per ogni macchina.

virtuale e questo ci consente di capire che la TLB è fondamentale per far funzionare in modo efficiente la memoria, abbiamo poi che sono mantenute delle pipeline anche per i sistemi operativi ospiti e questo ci consente di capire che questa è un'architettura molto potente che rende le prestazioni di una macchina virtuale praticamente comparabili con quelle di una macchina fisica.

In questo caso abbiamo un user process al livello 3, quando si facevano delle chiamate e si andava al ring 1 si aveva che tutte le sezioni privilegiate al ring 1 venivano ad essere riscritte al volo e quindi si aveva come un traduttore del codice binario. Sostanzialmente si aveva che l'hypervisor traduceva blocchi di codice provenienti dal guest operating system. Veniva quindi preso un blocco, questo blocco veniva analizzato andando a vedere se su di esso fossero presenti delle istruzioni privilegiate e di questo blocco si decideva cosa fare delle istruzioni privilegiate.

Nell'esempio sopra abbiamo che il guest operating system elabora un blocco, la VMM ha questo blocco, la VMM guarda il blocco che deve tradurre, si accorge che questo blocco contiene delle istruzioni privilegiate, sostituisce al volo le istruzioni privilegiate con delle istruzioni di emulazione e le riscrive sul SO.

In questo caso in esempio abbiamo che il SO guest chiede l'esecuzione del blocco rosso e quindi del blocco già modificato dall'hypervisor, non trova istruzioni privilegiate, trova direttamente istruzioni di emulazione e quindi tranquillamente le esegue senza alcun tipo di problema.

Questa tecnica era una tecnica molto potente che rallentava i sistemi per effettuare questa analisi sulle istruzioni privilegiate ma ovviamente risultava molto efficiente in quanto permetteva l'esecuzione di sistemi ospiti così come questi si trovavano per sistemi fisici e non si necessitava di nessun tipo di riscrittura del SO.

La para virtualizzazione anche se

negli effetti è simile alla tecnica vista sopra abbiamo che richiede una riscrittura del codice nel senso che quando il codice della macchina ospite ha delle istruzioni sensibili privilegiate, queste istruzioni vengono sostituite con delle istruzioni di emulazione e quindi con delle chiamate ad hypervisor; questo ad esempio è l'approccio di Xen che ad esempio per eseguire Linux ha bisogno di fare una patch del kernel Linux per sostituire una parte di codice che è proprio quella delle istruzioni privilegiate e questa serve proprio a permettere la sostituzione delle chiamate privilegiate con le chiamate ad hypervisor e che prendono il nome di hypervisor call. Dal punto di vista del confronto abbiamo che non c'è molta differenza tra le due tecniche del Binary translation o dell'hypercall. Nella Para-Virtualizzation abbiamo una situazione statica della chiamata all'emulazione mentre nella Binary Translation abbiamo che le istruzioni diemulazioni vengono ad essere tradotte dinamicamente. 967Intel aveva un problema come visto sopra con l'utilizzo di questi ring di privilegi che erano stati sostanzialmente coniati per avere una grossa efficienza delle chiamate al kernel. Abbiamo visto che le system call sottintendono una trap, nella trap abbiamo un handler che prende il nome della system call fauna chiamata a quell'indirizzo corrispondente alla routine che deve gestire quell'handler poi se quel handler ha una wait bloccante questa sospende il processo ecc. Per ogni system call fare una trap e fare un passaggio user mode kernel mode e viceversa a livello di prestazione risulta essere pesante. I ring servivano a non sparare una trap per ogni system call, avendo questi 4 ring, questi 4 gradi di protezione ed il passaggio da un ring all'altro lo si poteva fare con delle istruzioni privilegiate che non innescavano una trap questo voleva dire risparmiare una gran parte delle trap ed avere quindi un aumento.dell'efficienza di questi processori. Con il proliferare delle tecnologie di virtualizzazione i processori Intel non risultarono più essere processori efficienti dal punto di vista della virtualizzazione. Subito allora Intel si mosse proponendo una nuova architettura hardware per la virtualizzazione che prende il nome di Intel VT. Con questa architettura venne introdotto prima di tutto dei nuovi stati di funzionamento che prendono il nome di VMX root e non root mode, simili ai tipi di esecuzione kernel mode e user mode. Questa nuova architettura permette poi di avere una nuova struttura dati abbastanza complessa che prende il nome di VM Control Structure, che rende più flessibile il meccanismo della trap e da cui possiamo anche configurare il comportamento a valle di una trap. Questo vuol dire che possono esserci trap che possono richiamare VMM e altre che possono non richiamarlo e quindi.abbiamo una configurazione molto potente e molto flessibile. Per quanto riguarda gli stati di funzionamento abbiamo che entrambe le modalità di funzionamento VMXroot e non root mode posseggono dei ring, dei privilegi e quindi dei domini di protezione, nel VMX root mode e nel VMX non root mode abbiamo 4 ring ovviamente per quanto riguarda il non root mode nel ring 0 abbiamo il SO ospite, nel root mode nel ring 0 abbiamo l'hypervisor. Questo ovviamente ci consente di capire il vantaggio che sta nel fatto che tutte le istruzioni privilegiate del guest operating system vengono ad essere gestite qui dentro e l'hypervisor non ne è a conoscenza. Abbiamo in più una Virtual Machine Control Structure che tiene traccia di tutte le trap che sono chiamate, del comportamento relativo alle trap, dello stato dei SO ospiti e lo stato di entrata di quando si entra nel VMX root mode e lo stato di uscita di quando si esce. La cosa interessante è che il passaggio trauo la possibilità di controllare il flusso di esecuzione tra la macchina virtuale e l'host. Il VM-exit viene eseguito quando la macchina virtuale deve uscire dalla modalità di esecuzione e passare il controllo all'host. Questo può accadere ad esempio quando si verifica un'eccezione o quando la macchina virtuale richiede l'accesso a risorse esterne. Il VM-enter, invece, viene eseguito quando la macchina virtuale deve entrare nella modalità di esecuzione e riprendere il controllo. Questo avviene ad esempio quando l'host ha completato una determinata operazione e la macchina virtuale può riprendere la sua esecuzione. La Virtual Machine Control Structure (VMCS) è una struttura dati utilizzata per configurare il comportamento delle istruzioni VM-exit e VM-enter. Essa contiene informazioni come i registri di stato della macchina virtuale, le impostazioni di controllo e le informazioni sulle risorse esterne. In conclusione, le istruzioni VM-exit e VM-enter, insieme alla VMCS, consentono di gestire il flusso di esecuzione tra la macchina virtuale e l'host, fornendo un controllo più preciso e flessibile sull'interazione tra i due.