Wie unterscheidet sich die Virtualisierung strukturell von der Emulation?

Ursprünglich konnten Sie nicht zulassen, dass das Gastbetriebssystem echte Hardware verwendet, da Sie es nicht steuern konnten. Wenn Sie versucht haben, es auf der realen CPU auszuführen, hatten Sie keine Garantie dafür, dass es die Kontrolle an das Host-Betriebssystem zurückgibt.

Die Virtualisierung, wie Sie sie beschreiben, wird in der Hardware implementiert, indem bestimmte Regeln und Einschränkungen auf Hardwareebene angewendet werden, die vom Hostbetriebssystem verwaltet werden können. Auf diese Weise kann das Host-Betriebssystem Regeln festlegen, was der Gast tun kann und was nicht führen Sie den Gast tatsächlich auf echter Hardware aus. Wenn der Gast versucht, etwas mit der realen Hardware zu tun, die gegen die Regeln verstößt (z. B. der Versuch, auf ein Festplattengerät zuzugreifen), unterbricht die Hardware den Gast und sendet dem Host einen Interrupt, der es dem Host ermöglicht, eine Antwort bereitzustellen (z. B. Daten von einem emulierten Festplattengerät zurückzugeben) und dann den Gast fortzusetzen.

Hier ist ein vereinfachtes Beispiel für den Prozess:

Host-OS: Hey CPU, ich brauche Sie, um diesen code auszuführen virtualisiert. Rufen Sie mich an, wenn es etwas tun möchte, das nicht nur Anweisungen ausführt.

Host-CPU-Auslastung:, Du hast es!
Die Host-CPU speichert alle Hostregister und den Status und beginnt dann mit der Ausführung des Gastbetriebscode

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

Host-CPU-Auslastung: Uh... sicher. Einen moment.
Host CPU speichert alle gast register und zustand, und dann stellt alle host register und Staat
Host-CPU-Auslastung: Hey Host-Betriebssystem, der Gast wollte diese Datei!

Host OS: Oh, nun geben Sie ihnen diese: Datei von der virtuellen Festplatte

Host-CPU-Auslastung:, Du hast es!
Host-CPU speichert alle Host-Register und Status, stellt Gastregister und Status wieder her und startet dann die Ausführung von Gastbetriebscode
Host CPU: Hier ist diese Datei!

Gast OS: Süß, danke!

Der Hauptunterschied hier befindet sich in einem Emulator, wird das Gastbetriebssystem niemals tatsächlich 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 Netzwerke können auf den neuesten Prozessoren von heute gesteuert werden, sodass sie sicher verbunden werden können, ohne das Host-Betriebssystem jedes Mal stören zu müssen. Solange der Gast nicht versucht, außerhalb des virtualisierten zu gehen andernfalls wird auf dem Host-BETRIEBSSYSTEM möglicherweise kein Code ausgeführt, wenn zu einem bestimmten Zeitpunkt nichts zu tun ist.

Um ein wenig Perspektive hinzuzufügen, ist dies nur ein weiterer Schritt in einer langen Geschichte der Virtualisierung und Kontrolle. (Keine Garantien, dass dies in der richtigen Reihenfolge oder ist erschöpfend, aber sollte Ihnen eine gute Grundlage, übersicht)

Ursprünglich gab es keine Virtualisierung. Prozesse alle gemeinsam den gleichen Speicherplatz, alle hatten vollen Zugriff auf Hardware, und die Fähigkeit, Multi-Task war völlig abhängig von einem Prozess, der sich selbst stoppt und dem nächsten Prozess die Kontrolle gibt. Wenn das Betriebssystem irgendeine Art von Kontrolle über einen Prozess haben wollte, hatte es , um den Prozess in einem Emulator auszuführen (niemand tat es, weil es zu schmerzhaft langsam war).

Zuerst war Privilegierter Speicher: bestimmte Aktionen, die nur von speziellen Speicherbereichen ausgeführt werden können. Diese Regionen werden vom Betriebssystem belegt, sodass es als Gateway zu diesen privilegierten Aktionen fungieren kann. 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 zu bitten, für sie zu lesen/schreiben. Dies bedeutet, dass das Betriebssystem überprüfen kann, ob der Prozess über eine Berechtigung verfügt, bevor die Aktion ausgeführt wird.

Als nächstes kam virtualisierte "Zeit" sozusagen. Das Betriebssystem kann die CPU so konfigurieren, dass sie den aktiven Prozess in festgelegten Intervallen unterbricht, sodass sie die Planung steuern und zwischen Prozessen wechseln kann. Das Betriebssystem könnte jetzt laufen prozesse direkt auf der Hardware und immer noch verhindern, dass sie die CPU-Zeit missbrauchen. Dies wurde durch einen Hardware-Timer bereitgestellt.

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

In Ordnung, an diesem Punkt haben wir also die Anfänge des X86-Prozessors erreicht, wo wir Prozesse sicher ausführen und aktiv verhindern können von der Übernahme des Systems, wenn das Betriebssystem dies nicht ausdrücklich zulässt. An diesem Punkt werden Prozesse effektiv "virtualisiert". Diese Unterstützung gibt es schon lange , daher hört man nicht wirklich Leute über virtualisierte Prozesse sprechen, da nur angenommen wird, dass alle Prozesse jetzt virtualisiert sind.

Warum sind virtualisierte Betriebssysteme jedoch besonders? Warum können wir nicht einfach einen als Prozess starten und es sein eigenes Ding machen lassen? Nun, das Problem ist, dass als Betriebssystem der Gast das System erwartet, dass es auf dieselben Steuerelemente zugreifen und diese verwenden kann, mit denen der Host Prozesse steuert - im Grunde erwartet das Betriebssystem, dass es der Herrscher des Computers ist, und sie funktionieren einfach nicht, wenn dies nicht der Fall ist. "Hardware Virtualization" Erweiterungen (AMD-V für AMD und VT-x für Intel) ermöglichen es dem Host-Betriebssystem, einen virtualisierten Satz virtueller Prozesssteuerungen bereitzustellen (virtueller privilegierter Speicher, virtuelle Hardware-Timer, virtueller virtueller Speicher).

Wie ermöglichen wir es einem gesamten Betriebssystem, als Prozess in einer virtuellen Maschine auszuführen, aber es unabhängig auszuführen, während es immer noch die tatsächliche CPU verwendet?

(Das Folgende ist sehr vereinfacht.)

Durch Nutzung des gleichen oder ähnlichen Mechanismus, den das Betriebssystem verwendet, um Benutzermodus-Prozesse in Linie zu halten, meist.

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

Also, wenn wir einen Betriebssystemkern haben benutzermodus, jedes Mal, wenn es versucht, etwas wie Access Hardware direkt zu tun, wird es eine Ausnahme verursachen. Ein Hypervisor kann diese Ausnahme aufgreifen und mit emuliertem oder virtualisiertem Verhalten reagieren, anstatt einen Systemabsturz wie bei einem normalen Kernel zu verursachen.

Es kann den Hardwarezugriff im Namen dieses Kernels durchführen, einen modifizierten Hardwarezugriff durchführen(dh auf einen Teil einer Datei zugreifen, anstatt auf einen direkten Zugriff auf den Plattensektor) oder was auch immer Sie sich wünschen.

Virtuelle CPU Maschinenerweiterungen erweitern grundsätzlich den gesamten "Supervisor" - oder" Protected "- Modus der CPU um eine weitere Ebene, um genau dies zu tun, und bieten auch eine zusätzliche" Nesting-Ebene " des virtuellen Speichers, sodass Paging einfacher zu virtualisieren ist.

Virtualisierung beinhaltet die Simulation von Teilen der Hardware eines Computers-genug, damit ein Gastbetriebssystem unverändert ausgeführt werden kann -, aber die meisten Vorgänge werden 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 "innerhalb" einer echten bereitstellen. VMware kann jedoch nicht funktionieren auf jeder echten Hardware außer einem echten x86-PC.

In Emulation simuliert die virtuelle Maschine die komplette Hardware in Software. Auf diese Weise kann ein Betriebssystem für eine Computerarchitektur auf der Architektur ausgeführt werden, für die der Emulator geschrieben ist. Sine Alle Operationen werden in Software ausgeführt, die Emulation ist tendenziell langsamer, kann jedoch mehr Plattformen unterstützen, da sie hardwareunabhängig ist.

Nur der Vollständigkeit halber gibt es auch simulation, wobei die Aktionen der Maschine dupliziert werden, jedoch durch Verwendung von Code, dessen Interna sich radikal von der "echten" Maschine unterscheiden können. (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 Betriebssystemen und E/A-Einrichtungen ab.