diff --git a/Advanced Operating Systems.md b/Advanced Operating Systems.md index b02e9fa..9aa35aa 100644 --- a/Advanced Operating Systems.md +++ b/Advanced Operating Systems.md @@ -2838,8 +2838,111 @@ Architekturvarianten - drei unterschiedliche Prinzipien: 2. Typ-2 - Hypervisor 3. Paravirtualisierung +### Typ-1 - Hypervisor +- ![](Assets/AdvancedOperatingSystems-virtualisierung-hypervisor-1.png) +- Idee des Typ- 1 - Hypervisors: + - Kategorien traditioneller funktionaler Eigenschaften von BS: + 1. Multiplexing & Schutz der Hardware (ermöglicht Multiprozess-Betrieb) + 2. abstrahierte Maschine** mit ,,angenehmerer'' Schnittstelle als die reine Hardware (z.B. Dateien, Sockets, Prozesse, ...) +- Typ- 1 - Hypervisor trennt beide Kategorien: + - läuft wie ein Betriebssystem unmittelbar über der Hardware + - bewirkt Multiplexing der Hardware, liefert aber keine erweiterte Maschine** an Anwendungsschicht $\rightarrow$ ,,Multi-Betriebssystem-Betrieb'' +- Bietet mehrmals die unmittelbare Hardware-Schnittstelle an, wobei jede Instanz eine virtuelle Maschine jeweils mit den unveränderten Hardware-Eigenschaften darstellt (Kernel u. User Mode, Ein-/Ausgaben usw.). +- Ursprünge: Time-Sharing an Großrechnern + - Standard-BS auf IBM-Großrechner System/360: OS/360 + - reines Stapelverarbeitungs-Betriebssystem (1960er Jahre) + - Nutzer (insbes. Entwickler) strebten interaktive Arbeitsweise an eigenem Terminal an $\rightarrow$ timesharing (MIT, 1962: CTSS) + - IBM zog nach: CP/CMS, später VM/370 $\rightarrow$ z/VM + - CP: Control Program $\rightarrow$ Typ- 1 - Hypervisor + - CMS: ConversationalMonitor System $\rightarrow$ Gast-BS + - CP lief auf ,,blanker'' Hardware (Begriff geprägt: ,,bare metal hypervisor'' ) + - lieferte Menge virtueller Kopiender System/360-Hardware an eigentliches Timesharing-System + - je eines solche Kopie pro Nutzer $\rightarrow$ unterschiedliche BS lauffähig (da jede virtuelle Maschine exakte Kopie der Hardware) + - in der Praxis: sehr leichtgewichtiges, schnelles Einzelnutzer-BS als Gast $\rightarrow$ CMS (heute wäre das wenig mehr als ein Terminal-Emulator...) +- heute: Forderungen nach Virtualisierung von Betriebssystemen + - seit 1980er: universeller Einsatz des PC für Einzelplatz- und Serveranwendungen $\rightarrow$ veränderte Anforderungen an Virtualisierung + - Wartbarkeit: vor allem ökonomische Gründe: + 1. Anwendungsentwicklung und -bereitstellung: verschiedene Anwendungen in Unternehmen, bisher auf verschiedenen Rechnern mit mehreren (oft verschiedenen) BS, auf einem Rechner entwickeln und betreiben (Lizenzkosten!) + 2. Administration: einfache Sicherung, Migration virtueller Maschinen + 3. Legacy-Software + - später: Sicherheit, Robustheit $\rightarrow$ Cloud-Computing-Anwendungen +- ideal hierfür: Typ- 1 - Hypervisor + - ✓ Gast-BS angenehm wartbar + - ✓ Softwarekosten beherrschbar + - ✓ Anwendungen isolierbar + +Hardware-Voraussetzungen +- Voraussetzungen zum Einsatz von Typ- 1 - HV + - Ziel: Nutzung von Virtualisierung auf PC-Hardware + - systematische Untersuchung der Virtualisierbarkeit von Prozessoren bereits 1974 durch Popek & Goldberg [Popek&Goldberg74] + - Ergebnis: + - Gast-BS (welches aus Sicht der CPU im User Mode - also unprivilegiert läuft) muss sicher sein können, dass privilegierte Instruktionen (Maschinencode im Kernel) ausgeführt werden + - dies geht nur, wenn tatsächlich der HV diese Instruktionen ausführt! + - dies geht nur, wenn CPU bei jeder solchen Instruktion im Nutzermodus Kontextwechsel zum HV ausführen, welcher Instruktion emuliert! +- virtualisierbare Prozessoren bis ca. 2006: + - ✓ IBM-Architekturen(bekannt: PowerPC, bis 2006 Apple-Standard) + - ✗ Intel x86-Architekturen (386, Pentium, teilweise Core i) + +Privilegierte Instruktionen **ohne** Hypervisor +- kennen wir schon: Instruktion für Systemaufrufe +1. User Mode: Anwendung bereitet Befehl und Parameter vor +2. User Mode: Privilegierte Instruktion (syscall/Trap - Interrupt) $\rightarrow$ CPU veranlasst Kontext-und Privilegierungswechsel, Ziel: BS-Kernel +3. Kernel Mode: BS-Dispatcher (Einsprungpunkt für Kernel-Kontrollfluss) behandelt Befehl und Parameter, ruft weitere privilegierte Instruktionen auf (z.B. EA-Code) +- ![](Assets/AdvancedOperatingSystems-instruction-ohne-hypervisor.png) +Privilegierte Instruktionen mit Typ- 1 - Hypervisor(1) +- zum Vergleich: Instruktion für Systemaufrufe des Gast-BS +1. User Mode: Anwendung bereitet Befehl und Parameter vor +2. User Mode: Trap $\rightarrow$ Kontext-und Privilegierungswechsel, Ziel: Typ-1-HV +3. Kernel Mode: HV-Dispatcher ruft Dispatcher im Gast-BS auf +4. User Mode: BS-Dispatcher behandelt Befehl und Parameter, ruft weitere privilegierte Instruktionenauf (z.B. EA-Code) $\rightarrow$ Kontext-und Privilegierungswechsel, Ziel: Typ-1-HV +5. Kernel Mode: HV führt privilegierte Instruktionen anstelle des Gast-BS aus +- ![](Assets/AdvancedOperatingSystems-instruction-mit-typ1-hv.png) +Sensible und privilegierte Instruktionen: Beobachtungen an verschiedenen Maschinenbefehlssätzen: [Popek&Goldberg74] +- $\exists$ Menge an Maschinenbefehlen, die nur im Kernel Mode ausgeführt werden dürfen (Befehle zur Realisierung von E/A, Manipulation der MMU, ...) + - $\rightarrow$ sensible Instruktionen +- $\exists$ Menge an Maschinenbefehlen, die Wechsel des Privilegierungsmodus auslösen (x86: Trap ), wenn sie im User Mode ausgeführt werden + - $\rightarrow$ privilegierte Instruktionen +- Prozessor ist virtualisierbarfalls (notw. Bed.): sensible Instruktionen $\subseteq$ privilegierte Instruktionen +- Folge: jeder Maschinenbefehl, der im Nutzermodus nicht erlaubt ist, muss einen Privilegierungswechsel auslösen (z.B. Trap generieren) +- kritische Instruktionen = sensible Instruktionen \ privilegierte Instruktionen + - Befehle, welche diese Bedingung verletzen $\rightarrow$ Existenz im Befehlssatz führt zu nicht-virtualisierbarem Prozessor +- Beispiele für sensible Instruktionen bei Intel x86: + - hlt: Befehlsabarbeitung bis zum nächsten Interrupt stoppen + - invlpg: TLB-Eintrag für Seite invalidieren + - lidt: IDT (interrupt descriptor table) neu laden + - mov auf Steuerregistern + - ... +- Beispiel: Privilegierte Prozessorinstruktionen + - Bsp.: write - Systemaufruf + - Anwendungsprogramm schreibt String in Puffer eines Ausgabegeräts ohne Nutzung der libc Standard-Bibliothek: + `asm ( "int $0x80" ); /* interrupt 80 (trap) */` + - Interrupt-Instruktion veranlasst Prozessor zum Kontextwechsel: Kernelcode im privilegierten Modus ausführen + +Vergleich: Privilegierte vs. sensible Instruktionen +- ![](Assets/AdvancedOperatingSystems-instruction-priv-vs-sensible.png) + +Folgen für Virtualisierung +- privilegierte Instruktionen bei virtualisierbaren Prozessoren +- bei Ausführung einer privilegierten Instruktion in virtueller Maschine: immer Kontrollflussübergabe an im Kernel-Modus laufende Systemsoftware - hier Typ-1-HV +- HV kann (anhand des virtuellen Privilegierungsmodus) feststellen: + 1. ob sensible Anweisung durch Gast-BS + 2. oder durch Nutzerprogramm (Systemaufruf!) ausgelöst +- Folgen: + 1. privilegierte Instruktionen des Gast-Betriebssystems werden ausgeführt $\rightarrow$ ,,trap-and-emulate'' + 2. Einsprung in Betriebssystem, hier also Einsprung in Gast-Betriebssystem $\rightarrow$ Upcall durch HV +- privilegierte Instruktionen bei nicht virtualisierbaren Prozessoren + - solche Instruktionen typischerweise ignoriert! + +Intel-Architektur ab 386 +- dominant im PC-und Universalrechnersegment ab 1980er +- keine Unterstützung für Virtualisierung ... +- kritische Instruktionen im User Mode werden von CPU ignoriert +- außerdem: in Pentium-Familie konnte Kernel-Code explizit feststellen, ob er im Kernel- oder Nutzermodus läuft $\rightarrow$ Gast-BS trifft (implementierungsabhängig) evtl. fatal fehlerhafte Entscheidungen +- Diese Architekturprobleme (bekannt seit 1974) wurden 20 Jahre lang im Sinne von Rückwärtskompatibilität auf Nachfolgeprozessoren übertragen ... + - erste virtualisierungsfähige Intel-Prozessorenfamilie (s. [Adams2006] ): VT, VT-x® (2005) + - dito für AMD: SVM, AMD-V® (auch 2005) # Performanz und Parallelität # Zusammenfassung diff --git a/Assets/AdvancedOperatingSystems-instruction-mit-typ1-hv.png b/Assets/AdvancedOperatingSystems-instruction-mit-typ1-hv.png new file mode 100644 index 0000000..4269f20 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-instruction-mit-typ1-hv.png differ diff --git a/Assets/AdvancedOperatingSystems-instruction-ohne-hypervisor.png b/Assets/AdvancedOperatingSystems-instruction-ohne-hypervisor.png new file mode 100644 index 0000000..aa44d3a Binary files /dev/null and b/Assets/AdvancedOperatingSystems-instruction-ohne-hypervisor.png differ diff --git a/Assets/AdvancedOperatingSystems-instruction-priv-vs-sensible.png b/Assets/AdvancedOperatingSystems-instruction-priv-vs-sensible.png new file mode 100644 index 0000000..6f463e8 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-instruction-priv-vs-sensible.png differ