Wie unterscheidet sich Virtualisierung von Emulation in Bezug auf die Struktur?

Jemand sagte mir, dass ein Virtualisierungsprogramm wie VirtualBox nicht wie ein Emulator funktioniert, in dem Sinne, dass es keine Register emuliert und die tatsächlichen für die virtualisierten Daten verwendet, die sich auf der CPU befinden. Emulatoren müssen die Register emulieren, da sie hauptsächlich Software ausführen, die von einer fremden Umgebung abhängt (z. B. benötigt ein Genesis-Emulator die Register und Speicheradressen von Motorola 68000, sodass der Entwickler diese Ressourcen als emulierte Register zur Verfügung stellen muss).

Meine Hauptfrage ist, wie die Virtualisierung entwickelt wird. Wie kann ein gesamtes Betriebssystem als Prozess in einer virtuellen Maschine ausgeführt werden, ohne dass die eigentliche CPU ausgenutzt wird? Ich kenne nur die Emulation, nicht die Virtualisierung. Wenn also jemand helfen könnte, wäre das nett!

PS: Ich frage nicht nur, was der Unterschied ist, sondern auch, wie sie Software ausführen.

Ursprünglich konnte das Gastbetriebssystem keine echte Hardware verwenden, da Sie keine Möglichkeit hatten, diese zu steuern. Wenn Sie versuchten, es auf der realen CPU auszuführen, hatten Sie keine Garantie, dass es die Steuerung an das Host-Betriebssystem zurückgeben würde.

Die beschriebene Virtualisierung wird in der Hardware implementiert, indem bestimmte Regeln und Einschränkungen auf Hardwareebene angewendet werden, die vom Host-Betriebssystem verwaltet werden können. Auf diese Weise kann das Host-Betriebssystem Regeln festlegen, was der Gast tun kann und was nicht, und den Gast dann tatsächlich auf echter Hardware ausführen. Wenn der Gast versucht, mit der realen Hardware etwas zu tun, das gegen die Regeln verstößt (z. B. den Versuch, auf ein Festplattengerät zuzugreifen), hält die Hardware den Gast an und sendet dem Host einen Interrupt, der es dem Host ermöglicht, eine Antwort (z. B. Rückgabe von Daten von einem emulierten Plattengerät) und setzen Sie dann den Gast fort.

Hier ist ein vereinfachtes Beispiel des Prozesses:

Host-Betriebssystem: Hallo CPU, Sie müssen diesen Code virtualisiert ausführen. Rufen Sie mich an, wenn es etwas tun möchte, das nicht nur Anweisungen ausführt.

Host-CPU: Du hast es verstanden!
Die Host-CPU speichert alle Host-Register und -Status und startet dann die Ausführung des Gastbetriebssystem-Codes

Gastbetriebssystem: Ich lebe! Hey CPU, kannst du mir diese Datei besorgen?

Host-CPU: Äh ... sicher. Einen Moment.
Host-CPU speichert alle Gastregister und -zustände und stellt dann alle Hostregister und -zustände wieder her.
Host-CPU: Hey, Host-Betriebssystem, der Gast wollte diese Datei!

Host-Betriebssystem: Geben Sie ihnen Folgendes: Datei von der virtuellen Festplatte

Host-CPU: Du hast es verstanden!
Die Host-CPU speichert alle Host-Register und den Status, stellt die Guest-Register und den Status wieder her und startet dann die Ausführung des Guest-OS-Codes.
Host-CPU: Hier ist die Datei!

Gastbetriebssystem: Süß, danke!

Der Hauptunterschied liegt in einem Emulator, das Gastbetriebssystem wird niemals auf der Hardware ausgeführt. Bei der Virtualisierung konfiguriert das Host-Betriebssystem Einschränkungen in der CPU und führt dann den Gastcode tatsächlich auf der physischen CPU aus. Das obige Beispiel ist extrem vereinfacht, aber Speicher, Festplatten-E / A und sogar das Netzwerk können auf den neuesten Prozessoren von heute gesteuert werden, so dass sie sicher miteinander verbunden werden können, ohne das Host-Betriebssystem jedes Mal stören zu müssen. Solange der Gast nicht versucht, die virtualisierten Grenzen zu überschreiten, wird auf dem Host-Betriebssystem möglicherweise kein Code ausgeführt, wenn er zu einem bestimmten Zeitpunkt nichts zu tun hat.

Dies ist nur ein weiterer Schritt in der langen Geschichte der Virtualisierung und Steuerung. (Keine Garantie, dass dies in der richtigen Reihenfolge oder vollständig ist, sollte aber einen guten Startüberblick geben.)

Ursprünglich gab es keine Virtualisierung. Alle Prozesse teilten sich den gleichen Speicherplatz, hatten vollen Zugriff auf die Hardware und die Fähigkeit, mehrere Aufgaben gleichzeitig auszuführen, hing vollständig davon ab, dass ein Prozess anhielt und die Steuerung für den nächsten Prozess übernahm. Wenn das Betriebssystem die Kontrolle über einen Prozess haben wollte, musste es den Prozess in einem Emulator ausführen (das tat niemand, weil er zu langsam war).

Der erste Punkt war Privilegierter Speicher : bestimmte Aktionen, die nur von bestimmten Speicherbereichen ausgeführt werden können. Diese Regionen werden vom Betriebssystem belegt, sodass es als Gateway zu diesen privilegierten Aktionen fungieren kann. Ein Beispiel ist die Fähigkeit, Daten auf Hardware zu lesen / schreiben. Dies verhindert, dass Prozesse direkt auf die Festplatte lesen / schreiben und zwingt sie stattdessen, das Betriebssystem zum Lesen / Schreiben aufzufordern. Dies bedeutet, dass das Betriebssystem überprüfen kann, ob der Prozess über die Berechtigung verfügt, bevor die Aktion ausgeführt wird.

Als nächstes kam sozusagen die virtualisierte "Zeit". Das Betriebssystem kann die CPU so konfigurieren, dass der aktive Prozess in festgelegten Intervallen unterbrochen wird, sodass die Steuerung der Planung und der Wechsel zwischen den Prozessen übernommen werden kann. Das Betriebssystem kann jetzt Prozesse direkt auf der Hardware ausführen und trotzdem verhindern, dass sie die CPU-Zeit missbrauchen. Dies wurde durch einen Hardware-Timer bereitgestellt .

Als nächstes kam der virtualisierte Speicher : Das Problem mit dem gemeinsam genutzten Speicher besteht darin, dass jeder Prozess den Speicher eines anderen Prozesses lesen kann. Was passiert, wenn Marys Programm Bobs Passwort von seinem Webbrowser liest? Mit dem virtuellen Speicher kann das Betriebssystem den Speicher, den ein Prozess sieht, verschiedenen Teilen des physischen Speichers zuordnen oder sie sogar vollständig aus dem physischen Speicher verschieben (in die Auslagerungsdatei). Jedes Mal, wenn ein Prozess versucht, in den Speicher zu lesen oder zu schreiben, sucht die VMMU (Virtual Memory Management Unit) der CPU dort, wo sie im physischen Speicher zugeordnet ist, und führt die Aktion dort aus. Wenn nicht genügend Arbeitsspeicher vorhanden ist, ruft die CPU das Betriebssystem auf, um die Seite aus der Auslagerungsdatei in den Arbeitsspeicher abzurufen.

Okay, an diesem Punkt sind wir also bei den Anfängen des X86-Prozessors angelangt, wo wir Prozesse sicher ausführen und aktiv verhindern können, dass sie das System übernehmen, sofern das Betriebssystem dies nicht ausdrücklich zulässt. Zu diesem Zeitpunkt werden Prozesse effektiv "virtualisiert". Diese Unterstützung gibt es schon seit langer Zeit, sodass Sie nicht wirklich von virtualisierten Prozessen sprechen hören, da davon ausgegangen wird, dass jetzt alle Prozesse virtualisiert sind.

Warum sind virtualisierte Betriebssysteme so besonders? Warum können wir nicht einfach einen Prozess starten und ihn sein eigenes Ding machen lassen? Nun, das Problem ist, dass das Gastsystem als Betriebssystem erwartet, auf dieselben Steuerelemente zugreifen und diese verwenden zu können, die der Host zur Steuerung von Prozessen verwendet. funktioniert nicht, wenn das nicht der Fall ist. Mit den Erweiterungen "Hardware Virtualization" (AMD-V für AMD und VT-x für Intel) kann das Host-Betriebssystem einen virtualisierten Satz virtueller Prozesssteuerungen (virtueller privilegierter Speicher, virtuelle Hardware-Timer, virtueller virtueller Speicher) bereitstellen .

Wie kann ein gesamtes Betriebssystem als Prozess in einer virtuellen Maschine ausgeführt werden, ohne dass die eigentliche CPU ausgenutzt wird?

(Das Folgende ist sehr vereinfacht.)

Durch die Nutzung des gleichen oder eines ähnlichen Mechanismus, den das Betriebssystem verwendet, um die Prozesse im Benutzermodus größtenteils im Einklang zu halten.

Prozesse im Benutzermodus verursachen CPU-Ausnahmen, wenn sie versuchen, etwas zu tun, was sie nicht tun dürfen.

Wenn also ein Betriebssystemkernel im Benutzermodus ausgeführt wird, wird jedes Mal, wenn er versucht, direkt auf Hardware zuzugreifen, eine Ausnahme ausgelöst. Ein Hypervisor kann diese Ausnahme aufgreifen und mit emuliertem oder virtualisiertem Verhalten reagieren, anstatt wie ein normaler Kernel einen Systemabsturz zu verursachen.

Es kann den Hardwarezugriff für diesen Kernel ausführen, einen modifizierten Hardwarezugriff (dh Zugriff auf einen Teil einer Datei anstelle eines direkten Zugriffs auf den Festplattensektor) oder was auch immer Sie sich sonst wünschen.

Erweiterungen virtueller CPU-Maschinen erweitern im Grunde genommen den gesamten "Supervisor" - oder "Protected" -Modus der CPU um eine weitere Ebene, um genau dies zu tun, und bieten außerdem eine zusätzliche "Verschachtelungsebene" für den virtuellen Speicher, damit das Paging einfacher virtualisiert werden kann.

Bei der Virtualisierung werden Teile der Hardware eines Computers simuliert - genug, damit ein Gastbetriebssystem unverändert ausgeführt werden kann. Die meisten Vorgänge werden jedoch aus Effizienzgründen immer noch auf der realen Hardware ausgeführt. Die Virtualisierung ist daher normalerweise schneller als die Emulation, aber das reale System muss eine Architektur haben, die mit dem Gastsystem identisch ist. Beispielsweise kann VMWare eine virtuelle Umgebung zum Ausführen einer virtuellen Windows XP-Maschine "in" einer realen bereitstellen. VMWare kann jedoch nur auf einem echten x86-PC mit echter Hardware ausgeführt werden.

Bei der Emulation simuliert die virtuelle Maschine die gesamte Hardware in der Software. Auf diese Weise kann ein Betriebssystem für eine Computerarchitektur auf der Architektur ausgeführt werden, für die der Emulator geschrieben wurde. Da alle Vorgänge in Software ausgeführt werden, ist die Emulation in der Regel langsamer, kann jedoch mehr Plattformen unterstützen, da sie hardwareunabhängig ist.

Der Vollständigkeit halber gibt es auch eine Simulation , bei der die Aktionen der Maschine dupliziert werden, jedoch unter Verwendung von Code, dessen Interna sich möglicherweise grundlegend von der "realen" Maschine unterscheiden. (Denken Sie an "Flugsimulator".) Oft kompilieren Simulatoren den Quellcode der "echten" Maschine, zielen jedoch auf eine völlig andere CPU-Architektur mit völlig unterschiedlichen Betriebssystem- und E / A-Funktionen.