X86-Virtualisierung: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(31 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
=Was ist x86-Virtualisierung?=
 
=Was ist x86-Virtualisierung?=
−
*hardware- und softwarebasierte Mechanismen zur Unterstützung der Virtualisierung für Prozessoren, die auf der x86-Architektur basieren.
+
*Techniken, um mehrere Betriebssysteme gleichzeitig auf einem x86-Prozessor auszuführen.
−
*Unter Verwendung eines Hypervisors kann man mehrere Betriebssysteme parallel auf einem x86-Prozessor auszuführen
+
*Ein Hypervisor verteilt die physischen Ressourcen effizient und isoliert an die VMs.
−
*Man kann die Ressourcen isoliert und effizient zwischen den parallel ausgeführten Betriebssystemen aufteilen.
+
*Ziel: Das Gastbetriebssystem merkt keinen Unterschied zwischen virtueller und physischer Hardware.
−
*Die (Gast-)Betriebssysteme sollten keinen Unterschied zwischen virtualisiertem und den Betrieb direkt auf der Hardware erkennen können.
 
−
=Ring Model=
 
−
{{#drawio:ring-model}}
 
  
−
=Softwarebasierte Virtualisierung=
+
=Das Problem: Schutzringe=
−
*Es darf nur dem Hypervisor direkter Zugriff auf die Prozessor-Hardware gewährt werden
+
*x86-Prozessoren kennen vier Schutzringe (Ring 0–3).
−
*Gastsysteme wie alle anderen Applikationen dürfen nur eingeschränkte Zugriffsrechte auf die Hardware haben.
+
**Das Betriebssystem läuft in Ring 0 und darf alles.
−
*Gastsysteme dürfen keine Speicherbereiche sehen bzw. ändern können, die der Hypervisor zur Verwaltung benötigt.
+
**Anwendungen laufen in Ring 3 und dürfen wenig.
 +
**Ring 1 und 2 werden praktisch nicht genutzt.
 +
*Ein Gast-Kernel erwartet ebenfalls Ring 0. Den belegt aber schon der Host bzw. der Hypervisor.
  
−
=Protected Mode=
+
==Früher: Software-Virtualisierung (vor ca. 2006)==
−
*Es gibt vier verschiedene als Ringe bezeichnete Schutzebenen bzw. Befugnisstufen
+
*Keine Unterstützung durch den Prozessor.
−
*Ablaufenden Codesegmenten wird unterschiedliche Rechte gewährt.
+
*Der Gast-Kernel läuft deprivilegiert, z. B. in Ring 1.
−
*Im Protected Mode läuft der Betriebssystem-Kernel in einem höher privilegierten Modus, der als Ring 0 bezeichnet wird
+
*Der Hypervisor muss kritische Befehle abfangen und per Software nachbilden (Binary Translation, z. B. frühes VMware) oder der Gast-Kernel wird angepasst (Paravirtualisierung, z. B. frühes Xen).
−
*Applikationen in einem weniger privilegierten Modus, in der Regel entweder Ring 1 oder Ring 3.
+
*Nachteil: hoher Overhead durch häufiges Abfangen.
−
*Hypervisor bzw. das Hostbetriebssystem werden aufgrund ihrer privilegierten Stellung bei der Ressourcenverwaltung mit Ring-0-Berechtigung ausgeführt.
+
*Nicht verwechseln mit Emulation: Gast und Host haben hier dieselbe Plattform, die CPU wird nicht nachgebaut.
−
*Gastsysteme müssen, um den Schutz der Hypervisor-Ressourcen zu gewährleisten, folglich entweder auf Berechtigungslevel Ring 1 oder Ring 3 ausgeführt werden.
 
−
Deprivilegierung
 
−
Da Betriebssysteme für die x86-Architektur (die als Gastsystem keinen Unterschied zwischen virtualisiertem Betrieb und Betrieb direkt auf der Hardware sehen dürfen) so implementiert sind, dass sie von der Ring-0-Berechtigung ausgehen und auch nur dann korrekt funktionieren, muss die Virtualisierungslösung zwei Features implementieren, nämlich Ring-Deprivilegierung und Ring Aliasing:
 
  
−
Die Ring-Deprivilegierung sorgt dafür, dass das Gastsystem alle Befehle so ausführen kann, als hätte es Ring-0-Berechtigungen auf der Hardware, obwohl es durch die Virtualisierung weniger privilegierte Berechtigungen hat.
+
=Heute: Hardware-Virtualisierung mit VT-x / AMD-V=
−
Das Ring Aliasing sorgt dafür, dass das Gastsystem, wenn es eine Aktion ausführt, immer die Antwort erhält, die es erhalten würde, wenn der Befehl mit Ring-0-Berechtigungen ausgeführt worden wäre. Beispielsweise existiert ein Befehl zur Abfrage des Privilegierungslevels, der mit allen Berechtigungsleveln aufgerufen werden darf. Würde ein Gastsystem diesen Befehl ohne Ring Aliasing aufrufen, würde es Ring 1 oder 3 als Antwort erhalten, mit Ring Aliasing erhält es Ring 0.[2]
+
*Der Prozessor bekommt zwei Betriebsmodi:
 +
**'''VMX Root Mode''' („Ring -1“): Hier läuft der Hypervisor mit voller Kontrolle über die Hardware.
 +
**'''VMX Non-Root Mode''': Hier laufen die VMs. Das ist der „Gastmodus“.
 +
*Innerhalb jedes Modus gibt es wieder die Ringe 0–3:
 +
**Das Gastbetriebssystem läuft in seinem eigenen Ring 0, die Anwendungen in Ring 3.
 +
**Der Gast muss dafür nicht angepasst werden.
 +
*Kritische Operationen im Non-Root Mode lösen automatisch einen Wechsel zum Hypervisor aus.
 +
{{#drawio:vt-ring}}
 +
 
 +
==Ablauf: VM-Entry und VM-Exit==
 +
*'''VM-Entry:''' Der Hypervisor wechselt in die VM (Root → Non-Root). Ab jetzt rechnet der Gast direkt auf der CPU.
 +
*'''VM-Exit:''' Bei privilegierten Befehlen oder Gerätezugriffen springt die CPU automatisch zurück zum Hypervisor (Non-Root → Root).
 +
*Der Hypervisor erledigt die Aufgabe und startet die VM mit dem nächsten VM-Entry wieder.
 +
*'''VMCS''' (Virtual Machine Control Structure): Pro VM speichert die CPU deren Zustand (Register, Speicherverwaltung) und den Zustand des Hypervisors. Dadurch geht der Wechsel schnell.
 +
*'''Speicher und I/O:''' Der Hypervisor trennt den Speicher der VMs voneinander. Mit '''EPT''' (Intel) bzw. '''NPT''' (AMD) übersetzt die CPU auch die Speicheradressen der VM selbst. Gerätezugriffe werden emuliert (z. B. durch QEMU) oder an echte Geräte weitergereicht.
 +
{{#drawio:Ausführungsebenen}}
 +
 
 +
;Am Beispiel KVM
 +
*KVM ist der Hypervisor im VMX Root Mode, die VM läuft im Non-Root Mode.
 +
*QEMU emuliert die Geräte der VM. Gerätezugriffe landen per VM-Exit bei KVM und werden an QEMU weitergegeben.
 +
 
 +
=Hardwareerweiterungen=
 +
*'''Intel VT-x''': CPU-Flag <code>vmx</code>
 +
*'''AMD-V''' (auch SVM): CPU-Flag <code>svm</code>
 +
*Beide arbeiten nach demselben Prinzip.
 +
grep -m1 -owE 'vmx|svm' /proc/cpuinfo
 +
*Keine Ausgabe = im BIOS/UEFI abgeschaltet oder nicht vorhanden.
 +
 
 +
=Praxis-Beispiele=
 +
*[[KVM]] (Kernel-based Virtual Machine, Linux)
 +
*VMware vSphere (ESXi)
 +
*Microsoft Hyper-V
 +
*Citrix XenServer
 +
 
 +
=Weiterführende Informationen=
 +
*[https://tuxthink.blogspot.com/2011/12/kvm-introduction.html Einführung in KVM (tuxthink)]
 +
*[https://wiki.archlinux.org/title/KVM Arch Linux KVM Wiki]
 +
*[[Einordnung der Virtualisierungssysteme]]
 +
*Animation: https://labs.xinux.net/hypervisor-schichten.html#swhw-3
 +
 
 +
=Präsentation=
 +
*https://hedgedoc.xinux.net/p/sC9T6-hrS#/
 +
[[Kategorie:Virtualisierung]]

Aktuelle Version vom 11. Oktober 2026, 12:00 Uhr

Was ist x86-Virtualisierung?

  • Techniken, um mehrere Betriebssysteme gleichzeitig auf einem x86-Prozessor auszuführen.
  • Ein Hypervisor verteilt die physischen Ressourcen effizient und isoliert an die VMs.
  • Ziel: Das Gastbetriebssystem merkt keinen Unterschied zwischen virtueller und physischer Hardware.

Das Problem: Schutzringe

  • x86-Prozessoren kennen vier Schutzringe (Ring 0–3).
    • Das Betriebssystem läuft in Ring 0 und darf alles.
    • Anwendungen laufen in Ring 3 und dürfen wenig.
    • Ring 1 und 2 werden praktisch nicht genutzt.
  • Ein Gast-Kernel erwartet ebenfalls Ring 0. Den belegt aber schon der Host bzw. der Hypervisor.

Früher: Software-Virtualisierung (vor ca. 2006)

  • Keine Unterstützung durch den Prozessor.
  • Der Gast-Kernel läuft deprivilegiert, z. B. in Ring 1.
  • Der Hypervisor muss kritische Befehle abfangen und per Software nachbilden (Binary Translation, z. B. frühes VMware) oder der Gast-Kernel wird angepasst (Paravirtualisierung, z. B. frühes Xen).
  • Nachteil: hoher Overhead durch häufiges Abfangen.
  • Nicht verwechseln mit Emulation: Gast und Host haben hier dieselbe Plattform, die CPU wird nicht nachgebaut.

Heute: Hardware-Virtualisierung mit VT-x / AMD-V

  • Der Prozessor bekommt zwei Betriebsmodi:
    • VMX Root Mode („Ring -1“): Hier läuft der Hypervisor mit voller Kontrolle über die Hardware.
    • VMX Non-Root Mode: Hier laufen die VMs. Das ist der „Gastmodus“.
  • Innerhalb jedes Modus gibt es wieder die Ringe 0–3:
    • Das Gastbetriebssystem läuft in seinem eigenen Ring 0, die Anwendungen in Ring 3.
    • Der Gast muss dafür nicht angepasst werden.
  • Kritische Operationen im Non-Root Mode lösen automatisch einen Wechsel zum Hypervisor aus.

Ablauf: VM-Entry und VM-Exit

  • VM-Entry: Der Hypervisor wechselt in die VM (Root → Non-Root). Ab jetzt rechnet der Gast direkt auf der CPU.
  • VM-Exit: Bei privilegierten Befehlen oder Gerätezugriffen springt die CPU automatisch zurück zum Hypervisor (Non-Root → Root).
  • Der Hypervisor erledigt die Aufgabe und startet die VM mit dem nächsten VM-Entry wieder.
  • VMCS (Virtual Machine Control Structure): Pro VM speichert die CPU deren Zustand (Register, Speicherverwaltung) und den Zustand des Hypervisors. Dadurch geht der Wechsel schnell.
  • Speicher und I/O: Der Hypervisor trennt den Speicher der VMs voneinander. Mit EPT (Intel) bzw. NPT (AMD) übersetzt die CPU auch die Speicheradressen der VM selbst. Gerätezugriffe werden emuliert (z. B. durch QEMU) oder an echte Geräte weitergereicht.
Am Beispiel KVM
  • KVM ist der Hypervisor im VMX Root Mode, die VM läuft im Non-Root Mode.
  • QEMU emuliert die Geräte der VM. Gerätezugriffe landen per VM-Exit bei KVM und werden an QEMU weitergegeben.

Hardwareerweiterungen

  • Intel VT-x: CPU-Flag vmx
  • AMD-V (auch SVM): CPU-Flag svm
  • Beide arbeiten nach demselben Prinzip.
grep -m1 -owE 'vmx|svm' /proc/cpuinfo
  • Keine Ausgabe = im BIOS/UEFI abgeschaltet oder nicht vorhanden.

Praxis-Beispiele

  • KVM (Kernel-based Virtual Machine, Linux)
  • VMware vSphere (ESXi)
  • Microsoft Hyper-V
  • Citrix XenServer

Weiterführende Informationen

Präsentation

Abgerufen von „https://xinux.net/index.php?title=X86-Virtualisierung&oldid=73608“