Virtualisierungsforderungen von Popek und Goldberg

Die Virtualisierungsforderungen von Popek und Goldberg sind eine Menge von Bedingungen an eine Prozessorarchitektur, deren Erfüllung die effiziente Virtualisierung basierend auf dieser Architektur ermöglicht. Sie wurden durch Gerald J. Popek und Robert P. Goldberg in ihrem 1974 erschienenen Artikel Formal Requirements for Virtualizable Third Generation Architectures formuliert.^[1] Obwohl die Anforderungen unter vereinfachenden Annahmen abgeleitet wurden, stellen sie dennoch eine ausgezeichnete Grundlage dar, um festzustellen, ob eine Prozessorarchitektur effiziente Virtualisierung unterstützen kann und bietet Ansätze für den Entwurf solcher Architekturen.

Eine virtuelle Maschine nach Popek und Goldberg stellt ein effizientes Duplikat eines realen Prozessors dar, d. h. alles, was auf dem realen Prozessor möglich ist, soll in gleicher und effizienter Weise auch auf der virtuellen Maschine möglich sein – insbesondere Zugriffe auf den Prozessor, Speicher aber auch Peripheriegeräte.

Ein Virtual Machine Monitor (VMM, auch als Hypervisor bezeichnet) ist die Implementierung der Abstraktionsschicht zwischen realem Prozessor und der virtuellen Maschine. Drei Faktoren spielen bei der Analyse der durch die VMM bereitgestellten virtuellen Umgebung eine besondere Rolle:^[2]

Äquivalenz / Treue

Ein Programm, das in der virtuellen Umgebung ausgeführt wird, sollte identisches Verhalten zeigen, wie wenn es auf der äquivalenten realen Maschine ausgeführt würde.

Ressourcenkontrolle / Sicherheit

Die VMM muss die vollständige Kontrolle über die virtuellen Ressourcen besitzen.

Effizienz / Leistung

Ein statistisch relevanter Anteil von Prozessorinstruktionen muss ohne Intervention der VMM ausgeführt werden.

In der Terminologie von Popek und Goldberg muss ein VMM alle drei Eigenschaften aufweisen um als solcher zu gelten. In der Terminologie des Buchs von Smith und Nair (2005) werden VMMs als solche definiert, die die ersten beiden Kriterien (Äquivalenz und Ressourcenkontrolle) erfüllen. Diejenigen VMMs, die auch das Effizienz-Kriterium erfüllen, werden dort als effiziente VMMs bezeichnet.^[3]

Popek und Goldberg beschreiben die Eigenschaften, die die Befehlssatzarchitektur eines physikalischen Prozessors aufweisen muss, um VMMs mit den oben genannten Eigenschaften unterstützen zu können. Ihre Analyse leitet die Eigenschaften aus einem „Prozessorarchitektur der dritten Generation“ genannten Modell ab, das an die damals aktuellen Systeme (z. B. IBM System/360, Honeywell 6000, DEC PDP-10) angelehnt ist, aber trotzdem generisch genug ist, um auf moderne Prozessorarchitekturen ausgedehnt zu werden.

Das Modell beschreibt unter anderem einen Prozessor, der zwei Modi besitzt (privilegierter Modus und User Modus) und Zugriff auf linearen und einheitlich adressierbaren Speicher hat. Es wird angenommen, dass ein Teil des Prozessorbefehlssatzes nur im privilegierten Modus ausgeführt werden kann und Speicher relativ zu einem Relocation Register genannten Basisregister adressiert wird. I/O-Operationen und Interrupts wurden im beschriebenen Modell nicht modelliert.^[4]

Um ihre Virtualisierungstheoreme abzuleiten, die hinreichende (aber nicht notwendige) Bedingungen für die Virtualisierung formulieren, führten Popek und Goldberg eine Klassifikation der Befehlssatzarchitektur in drei nicht disjunkte Klassen ein:

Privilegierte Instruktionen

Diejenigen Instruktionen, die gefangen werden, wenn der Prozessor sich bei der Ausführung im User Modus befindet, und nicht gefangen werden, wenn er sich bei der Ausführung im privilegierten Modus befindet.

Kontrollkritische Instruktionen

Diejenigen Instruktionen, die versuchen die Konfiguration von Ressourcen des Systems zu verändern.

Verhaltenskritische Instruktionen

Diejenigen Instruktionen, deren Resultat von der Konfiguration der Ressourcen des Systems abhängt.

Die wesentlichen Resultate von Popek und Goldbergs Analyse können dann so zusammengefasst werden:

Theorem 1. Für beliebige Prozessorarchitekturen der dritten Generation kann eine effektive VMM aufgebaut werden, wenn der Satz der kontrollkritischen Instruktionen für eine Prozessorarchitektur eine Untermenge des Satzes der privilegierten Instruktionen darstellt.

Im Prinzip besagt das Theorem, dass es, um einen VMM zu bauen, genügt, wenn alle Instruktionen, die das korrekte Funktionieren der VMM beeinflussen können (kontrollkritische Instruktionen), immer gefangen werden und zur Kontrolle an die VMM weitergegeben und verarbeitet (emuliert) werden. Dies sorgt für die Erfüllung der Eigenschaft Ressourcenkontrolle/Sicherheit des VMM. Nicht-privilegierte Instruktionen müssen hingegen nativ auf dem Prozessor ausgeführt werden, um die Effizienzeigenschaft des VMM zu erfüllen. Die Erfüllung der Äquivalenzeigenschaft folgt aus dem eben Beschriebenen.

Das Theorem gibt auch einen Hinweis für eine einfache Technik zur Implementierung eines VMM, die sogenannte trap-and-emulate-Virtualisierung manchmal auch klassische Virtualisierung genannt: Da alle kontrollkritischen Instruktionen gefangen werden können, ist alles was der VMM nun tun muss, die Emulierung jeder einzelnen gefangenen Instruktion.^{[5]:Seite 2 und 3[6]}

Ein verwandtes Problem ist es, hinreichende Bedingungen für rekursive Virtualisierung (auch geschachtelte Virtualisierung genannt) abzuleiten, d. h. Bedingungen, unter denen VMMs eine Kopie ihrer selbst ausführen können. Popek und Goldberg stellen die folgenden (hinreichenden) Bedingungen dar:

Theorem 2. Eine beliebige Prozessorarchitektur der dritten Generation ist rekursiv virtualisierbar, wenn

1. sie selbst virtualisierbar ist
2. für sie ein VMM ohne Zeitabhängigkeiten konstruiert werden kann.

Einige Architekturen, wie zum Beispiel die x86-Architektur ohne hardwaregestütze Virtualisierungsfunktionen, erfüllen diese Bedingungen nicht, weswegen sie nicht auf dem klassischen Weg virtualisierbar sind.

Trotzdem können solche Architekturen unter Verwendung anderer Techniken, wie zum Beispiel der Binärtranslation, voll virtualisiert werden. Der zusätzliche Aufwand zur Umsetzung dieser Techniken (auf Software- statt auf Hardwarebasis) macht solche VMMs theoretisch weniger effizient,^[6] aber auch die Implementierung von Hardware-Traps impliziert natürlich einen gewissen Performanceverlust. Ein gut optimierter, auf Binärtranslation basierender VMM kann durchaus vergleichbare Performance erreichen und tut dies im Falle der x86-Binärtranslation im Vergleich zur VMMs, basierend auf der x86-hardwaregestützten Virtualisierung der ersten Generation.^{[5]:Seite 1 und 5} Tatsächlich folgt aus dieser Tatsache ein Theorem mit anderen hinreichenden Bedingungen.

Als kritische Instruktionen werden solche bezeichnet die im Sinne der drei Kategorien von Instruktionen kontrollkritische und nicht privilegierte Instruktionen sind, d. h. diese Instruktionen können nicht gefangen werden, ändern aber relevante Strukturen zur Prozessorkontrolle. Prozessoren, die solche kritischen Instruktionen im Befehlssatz haben, sind nach Popek und Goldbergs Kriterien nicht virtualisierbar, da sie Theorem 1 verletzen.

Trotzdem wurden VMMs implementiert, die auf derartigen Prozessorarchitekturen praktisch sehr gut funktionieren. Die Virtualisierung solcher Architekturen erfordert allerdings Mechanismen zum Umgang mit den oben beschriebenen kritischen Instruktionen. Ein Ansatz, als Patching oder Binärtranslation bekannt, verwendet Elemente der dynamischen Rekompilierung: kritische Instruktionen werden zur Laufzeit erkannt und ersetzt mit einem Trap in den VMM. Verschiedene Mechanismen, z. B. Caching wurden vorgeschlagen, um das Patching effizienter zu machen. Einen anderen Ansatz wählt die Paravirtualisierung, bei der die Gastbetriebssysteme so angepasst (portiert) werden, dass kritische Instruktionen ersetzt werden durch Traps in den VMM.

In diesem Abschnitt wird für einige Prozessorarchitekturen dargestellt, was die Untersuchung hinsichtlich der oben formulierten Bedingungen ergibt.

Die PDP-10 Architektur hat einige Instruktionen, die kontrollkritische aber nicht-privilegiert sind.^[7] Diese Instruktionen speichern oder stellen Conditions Codes für USER- oder IOT-Bits wieder her:

• JSR: jump to subroutine
• JSP: jump and save program counter
• PUSHJ: push down and jump
• JRST: jump and restore

Alle kontrollkritischen Instruktionen des System/370 sind auch privilegierte Instruktionen: Die Architektur erfüllt die o. g. Bedingungen zur Virtualisierung.^[8]

Der Motorola MC68000 hat eine kontrollkritische, nicht-privilegierte Anweisung:

• MOVE from SR

Diese Instruktion ist kontrollkritisch, da sie (lesenden) Zugriff auf das gesamte Statusregister erlaubt, welches auch das Steuerungsbit für privilegierten und Usermodus, Interruptlevels und Trace-Kontrolle beinhaltet. Bei den meisten späteren Modellen der Motorola-68000-Familie, beginnend mit dem MC68010, war diese Instruktion zur privilegierten Instruktion geworden, und eine weitere Instruktion wurde bereitgestellt, um den unkritischen Teil des Statusregisters im Usermodus auslesen zu können.^[9][10]

Der IA-32 Befehlssatz des Intel Pentium Prozessors enthält 17 kontrollkritische, unprivilegierte Instruktionen.^[11] Sie können in folgende Gruppen eingeteilt werden:

• Kontrollkritische Register-Instruktionen: Lesen oder Ändern von kontrollkritischen Registern ober Speicherbereichen, z. B. Taktregister oder Interruptregister:
  • SGDT, SIDT, SLDT
  • SMSW
  • PUSHF, POPF
• Schutzsystem-Instruktionen: Sie sprechen das Speicherschutzsystem oder das Adress Relocation System an:
  • LAR, LSL, VERR, VERW
  • POP
  • PUSH
  • CALL, JMP, INT n, RET
  • STR
  • MOV

Die Einführung der Befehlssatzerweiterung AMD-V und Intel VT-x führt dazu, dass x86-Prozessoren mit diesen Erweiterungen den Virtualisierungsforderungen von Popek und Goldberg entsprechen.

Der Aufwand, um Virtualisierung auf der Itanium-Architektur zu implementieren ist im Aufsatz von Magenheimer und Christian aus dem Jahr 2000 beschrieben.^[12]

Die Effizienzforderung in Popek und Goldbergs Definition des VMM betrifft nur die Ausführung nicht-privilegierter Instruktionen, die nativ auf dem Prozessor ausgeführt werden sollen. Dies unterscheidet einen VMM von der allgemeineren Klasse der Hardware-Emulatorensoftware. Unglücklicherweise stellte sich heraus, dass sogar „effiziente“ VMMs die auf Prozessorarchitekturen beruhten, die Theorem 1 voll erfüllten, deutlich geringere Performance zeigten als das gleiche nicht-virtualisiertes System. Experimente, die auf der System/370 Architektur durchgeführt wurden, zeigten, dass die virtuellen Maschine nur 21 % der Leistung des nicht-virtualisierten Systems erreichte. Dies wurde zurückgeführt auf den Aufwand, um das trap-and-emulate-Verfahren in Hardware umzusetzen. Daraufhin führte IBM eine Reihe hardwareunterstützter Virtualisierungsfunktionen für die System/370-Architektur ein, womit die Leistung des VMM verdoppelt werden konnte.^[13]

Ein weiterer wesentlicher Grund für die Entwicklung hardwareunterstützter Virtualisierungsfunktionen für die System/370-Architektur war außerdem die Speicherverwaltung. Wenn das Gastsystem selbst virtuellen Speicher implementierte, wurde die Performance des Gesamtsystems durch die mehrfache Adressumsetzung (erst in der virtuellen Maschine, dann nochmals durch die Memory Management Unit des Prozessors) stark beeinträchtigt. Es wurde im System/370 ein dem Second Level Address Translation moderner Architekturen vergleichbarer Mechanismus hardwareseitig implementiert, um diese Zugriffe zu beschleunigen.^[14]

• James Smith, Ravi Nair: Virtual Machines. Morgan Kaufmann, 2005, ISBN 1-55860-910-5 (englisch). 
• Keith Adams, Ole Agesen: A Comparison of Software and Hardware Techniques for x86 Virtualization. In: Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose CA, 2006, ACM 1-59593-451-0/06/0010. 21. Oktober 2006 (englisch, https://www.vmware.com/pdf/asplos235_adams.pdf https://www.vmware.com/pdf/asplos235_adams.pdf [abgerufen am 22. Dezember 2006]). 
• P. H. Gum: System/370 Extended Architecture: Facilities for Virtual Machines. In: IBM J. Res. Develop. Vol. 27, Nr. 6, November 1983, S. 530–544 (englisch, wisc.edu [PDF]). 

1. ↑ Gerald J. Popek, Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures. In: Communications of the ACM. 17. Jahrgang, Nr. 7, 1974, S. 414–417, doi:10.1145/361011.361073. 
2. ↑ Gerald J. Popek, Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures. In: Communications of the ACM. 17. Jahrgang, Nr. 7, 1974, S. 417, doi:10.1145/361011.361073. 
3. ↑ J. Smith and R. Nair. Virtual Machines: Versatile Platforms for Systems and Processes (The Morgan Kaufmann Series in Computer Architecture and Design). Morgan Kaufmann Publishers Inc., 2005, Seite 205.
4. ↑ Gerald J. Popek, Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures. In: Communications of the ACM. 17. Jahrgang, Nr. 7, 1974, S. 414, doi:10.1145/361011.361073. 
5. ↑ ^{a b} A Comparison of Software and Hardware Techniques for x86 Virtualization. (PDF) VMware, abgerufen am 8. September 2010. 
6. ↑ ^{a b} J. Smith, R. Nair: Virtual Machines: Versatile Platforms for Systems and Processes. The Morgan Kaufmann Series in Computer Architecture and Design. Morgan Kaufmann Publishers, 2005, Seite 391.
7. ↑ S. W. Galley: PDP-10 Virtual machines. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. In: Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. 1969, S. 30–34 (englisch). 
8. ↑ J. Smith, R. Nair: Virtual Machines: Versatile Platforms for Systems and Processes. The Morgan Kaufmann Series in Computer Architecture and Design. Morgan Kaufmann Publishers, 2005, S. 395.
9. ↑ M68000 8-/16-32-Bit Microprocessor User's Manual, Ninth Edition. Motorola, Inc., Phoenix AZ 1993. 
10. ↑ Motorola M68000 Family Programmer's Reference Manual. Motorola, Inc., Phoenix AZ 1992. 
11. ↑ John Scott Robin, Cynthia E. Irvine: Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor. 9th USENIX Security Symposium. In: Proc. 9th USENIX Security Symposium. 2000 (englisch, usenix.org). 
12. ↑ Daniel J. Magenheimer, Thomas W. Christian: vBlades: Optimized Paravirtualization for the Itanium Processor Family. 3rd Virtual Machine Research & Technology Symposium. In: Proc. 3rd Virtual Machine Research & Technology Symposium. USENIX, 2000, S. 73–82 (englisch, usenix.org). 
13. ↑ Smith and Nair, S. 415–416 and 426
14. ↑ P. H. Gum: System/370 Extended Architecture: Facilities for Virtual Machines. (PDF; 1,4 MB) In: IBM J. Res. Develop., Vol. 27, No. 6, Nov. 1983, S. 533