In che modo la virtualizzazione differisce dall'emulazione, in termini di struttura?

Qualcuno mi ha detto che un programma di virtualizzazione come VirtualBox non funziona come un emulatore, nel senso che non emula i registri e utilizza quelli effettivi per i dati virtualizzati che si trovano sulla CPU. Gli emulatori devono emulare i registri poiché devono principalmente eseguire software che dipendono da un ambiente estraneo (ad es. Un emulatore Genesis necessita dei registri e degli indirizzi di memoria di Motorola 68000, quindi lo sviluppatore deve rendere disponibili queste risorse come registri emulati).

La mia domanda principale è: come viene sviluppata la virtualizzazione? Come possiamo consentire a un intero sistema operativo di essere eseguito come processo in una macchina virtuale, ma farlo funzionare in modo indipendente pur facendo uso della CPU effettiva? Conosco solo l'emulazione, non la virtualizzazione, quindi se qualcuno potesse aiutare sarebbe bello!

PS: Non sto chiedendo solo quale sia la differenza, ma differenze nel modo in cui eseguono il software.

Inizialmente, non potevi permettere al SO guest di usare hardware reale perché non avevi modo di controllarlo. Se hai provato a eseguirlo sulla CPU reale, non avevi alcuna garanzia che avrebbe restituito il controllo al sistema operativo host.

La virtualizzazione così come descritta è implementata nell'hardware consentendo l'applicazione di determinate regole e restrizioni a livello hardware, che può essere gestito dal sistema operativo host. Ciò consente al sistema operativo host di impostare regole su ciò che il guest può e non può fare, e quindi effettivamente eseguire il guest su hardware reale. Se l'ospite tenta di fare qualcosa con l'hardware reale che viola le regole (come tentare di accedere a un dispositivo disco), l'hardware sospenderà l'ospite e invierà all'host un interrupt, che consente all'host di fornire una risposta (come restituzione dei dati da un dispositivo a disco emulato), quindi riprendere il guest.

Ecco un esempio semplificato del processo:

Sistema operativo host: Hey CPU, ho bisogno che tu esegua questo codice virtualizzato. Chiamami se vuole fare qualcosa che non è solo l'esecuzione di istruzioni.

CPU host: ce l'hai!
La CPU host salva tutti i registri e lo stato dell'host, quindi avvia l'esecuzione del codice del sistema operativo guest

Sistema operativo guest: sono vivo! Ehi CPU, puoi farmi questo file?

CPU host: Uh ... certo. Un momento.
La CPU host salva tutti i registri e lo stato del guest, quindi ripristina tutti i registri host e lo stato della
CPU host: Hey sistema operativo host, il guest ha voluto questo file!

Sistema operativo host: Oh, dai loro questo: File dal disco rigido virtuale

CPU host: ce l'hai!
La CPU dell'host salva tutti i registri e lo stato dell'host, ripristina i registri e lo stato del guest, quindi avvia l'esecuzione del codice del sistema operativo guest
CPU dell'host: Ecco quel file!

Sistema operativo guest: dolce grazie!

La differenza chiave qui sta in un emulatore, il SO guest non è mai effettivamente in esecuzione sull'hardware. Con la virtualizzazione, il sistema operativo host configura le limitazioni nella CPU, quindi esegue effettivamente il codice guest sulla CPU fisica. L'esempio sopra è estremamente semplificato, ma memoria, I / O su disco e persino rete possono essere controllati sugli ultimi processori di oggi, consentendo loro di interfacciarsi in sicurezza senza dover disturbare il sistema operativo host ogni volta. Finché l'ospite non tenta di uscire dai confini virtualizzati, il sistema operativo host potrebbe non avere alcun codice in esecuzione se non ha nulla da fare in un determinato momento.

Per aggiungere un po 'di prospettiva, questo è solo un altro passo in una lunga storia di virtualizzazione e controllo. (Nessuna garanzia che questo sia nell'ordine corretto o sia esaustivo, ma dovrebbe fornire una buona panoramica di partenza)

Inizialmente, non c'era virtualizzazione. Tutti i processi condividevano lo stesso spazio di memoria, tutti avevano pieno accesso all'hardware e la capacità di multi-task dipendeva interamente dal fatto che un processo si arrestasse e dava il controllo al processo successivo. Se il sistema operativo voleva avere qualsiasi tipo di controllo su un processo, doveva eseguire il processo in un emulatore (nessuno lo faceva, perché era troppo dolorosamente lento).

Il primo era la memoria privilegiata : alcune azioni che possono essere eseguite solo da regioni speciali di memoria. Queste regioni sono occupate dal sistema operativo, consentendogli di fungere da gateway per queste azioni privilegiate. Un esempio è la capacità di leggere / scrivere dati sull'hardware. Ciò impedisce ai processi di leggere / scrivere direttamente sul disco rigido e li costringe invece a chiedere al sistema operativo di leggere / scrivere per loro. Ciò significa che il sistema operativo può verificare se il processo dispone dell'autorizzazione prima di eseguire l'azione.

Poi venne il "tempo" virtualizzato, per così dire. Il sistema operativo potrebbe configurare la CPU per interrompere il processo attivo a intervalli prestabiliti, consentendogli di assumere il controllo della pianificazione e passare da un processo all'altro. Il sistema operativo potrebbe ora eseguire i processi direttamente sull'hardware e comunque impedire loro di abusare del tempo della CPU. Questo è stato fornito da un timer hardware .

Successivamente è arrivata la memoria virtualizzata : il problema con la memoria condivisa è che qualsiasi processo potrebbe leggere la memoria di qualsiasi altro processo. Cosa succede quando il programma di Mary legge la password di Bob dal suo browser? La memoria virtuale consente al sistema operativo di mappare la memoria che un processo vede su diverse parti della memoria fisica o addirittura di spostarli completamente dalla memoria fisica (nel file di paging). Ogni volta che un processo tenta di leggere o scrivere in memoria, la VMMU (unità di gestione della memoria virtuale) della CPU cerca dove è mappata nella memoria fisica ed esegue l'azione lì. Se la mappa è esaurita, la CPU chiama il sistema operativo per recuperare la pagina dalla memoria del file di paging.

Bene, quindi a questo punto abbiamo raggiunto gli inizi del processore X86, dove possiamo eseguire in modo sicuro i processi e possiamo impedire attivamente loro di assumere il controllo del sistema a meno che il sistema operativo non glielo permetta in modo specifico. A questo punto, i processi vengono effettivamente "virtualizzati". Questo supporto esiste da molto tempo, quindi non si sente davvero la gente parlare di processi virtualizzati, dal momento che si presume che tutti i processi siano virtualizzati ora.

Perché sono speciali i sistemi operativi virtualizzati? Perché non possiamo semplicemente avviarne uno come processo e lasciarlo fare da solo? Bene, il problema è che come sistema operativo, il sistema guest si aspetta di essere in grado di accedere e utilizzare gli stessi controlli che l'host utilizza per controllare i processi - in sostanza, il sistema operativo prevede di essere il sovrano supremo del computer e semplicemente non non funziona se non è così. Le estensioni "Virtualizzazione hardware" (AMD-V per AMD e VT-x per Intel) consentono al sistema operativo host di fornire un set virtualizzato di controlli di processo virtuali (memoria con privilegi virtuali, timer hardware virtuali, memoria virtuale virtuale).

Come possiamo consentire a un intero sistema operativo di essere eseguito come processo in una macchina virtuale, ma farlo funzionare in modo indipendente pur facendo uso della CPU effettiva?

(Quanto segue è molto semplificato.)

Sfruttando lo stesso o simile meccanismo utilizzato dal sistema operativo per mantenere in linea i processi in modalità utente.

I processi in modalità utente causeranno eccezioni CPU quando tentano di fare qualcosa che non sono autorizzati a fare.

Quindi, se abbiamo un kernel OS eseguito in modalità utente, ogni volta che tenta di fare qualcosa come accedere direttamente all'hardware, causerà un'eccezione. Un hypervisor può rilevare quell'eccezione e rispondere con comportamento emulato o virtualizzato, invece di causare un crash del sistema come farebbe un normale kernel.

Può eseguire l'accesso hardware per conto di questo kernel, eseguire un accesso hardware modificato (ovvero accedere a una parte di un file invece di un accesso diretto al settore del disco) o qualsiasi altra cosa si possa immaginare.

Le estensioni della macchina virtuale della CPU in pratica estendono l'intera modalità "supervisore" o "protetta" della CPU di un altro livello per fare esattamente questo, e forniscono anche un ulteriore "livello di nidificazione" della memoria virtuale in modo che il paging sia più facile da virtualizzare.

La virtualizzazione implica la simulazione di parti dell'hardware di un computer - abbastanza per far funzionare un sistema operativo guest non modificato - ma la maggior parte delle operazioni si verificano ancora sull'hardware reale per motivi di efficienza. La virtualizzazione quindi è normalmente più veloce dell'emulazione ma il sistema reale deve avere un'architettura identica al sistema guest. Ad esempio, VMWare può fornire un ambiente virtuale per l'esecuzione di una macchina virtuale Windows XP "all'interno" di una vera e propria. Tuttavia VMWare non può funzionare su hardware reale diverso da un vero PC x86.

In emulazione macchina virtuale simula l'hardware completo nel software. Ciò consente di eseguire un sistema operativo per un'architettura di computer sull'architettura per cui è stato scritto l'emulatore. Sine tutte le operazioni vengono eseguite nel software, l'emulazione tende a essere più lenta, tuttavia può supportare più piattaforme poiché è indipendente dall'hardware.

Solo per completezza, c'è anche la simulazione , in cui le azioni della macchina sono duplicate, ma usando un codice i cui interni possono essere radicalmente diversi dalla macchina "reale". (Pensa al "simulatore di volo"). Spesso i simulatori compilano il codice sorgente della macchina "reale" ma prendono di mira un'architettura CPU completamente diversa, con sistemi operativi e I / O completamente diversi.