Hardware-Unterst utzung f ur x86-Virtualisierung

Die Seite wird erstellt Damian Kuhn

Haus und Garten

Deutsch

Like
Teilen
Einbetten
Vollbild
Folien
HTML Herunterladen
PDF Herunterladen
Missbrauch

←

WEITER LESEN

→

Transkription von Seiteninhalten

Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten

Hardware-Unterstützung für x86-Virtualisierung

Benjamin Flach

Fakultät für Informatik,
Technische Universität München
flach@in.tum.de

Zusammenfassung Eine effiziente Virtualisierung ist nur auf Basis ei-
ner geeigneten Hardware realisierbar. Die weit verbreitete x86-Architektur
erfüllt die dafür notwendigen Anforderungen nicht. Erweiterungen sind al-
so nötig, um die Architektur für die sich rasch verbreitende Virtualisierung
zu verbessern. Diese Arbeit stellt die formalen Anforderungen an effizien-
te Virtualisierung vor und erläutert die Funktionsweise einiger Hardware-
Erweiterungen.

1 Einführung
Virtualisierung ganzer Systeme gibt es schon seit einigen Jahrzehnten. Ebenso
vielfältig wie die verschiedenen Umsetzungen im Laufe der Zeit sind auch die Gründe,
warum Virtualisierung verwendet wird, wobei Ziel und Umsetzung immer sehr eng
zusammen arbeiten müssen. Es gibt drei Hauptziele von Virtualisierung, die gleich-
zeitig angestrebt werden können, aber nicht müssen: Effizienz, Ressourcen-Kontrolle
und Äquivalenz mit der virtualisierten Hardware.
System-VMs erhöhen die Sicherheit und können eine vorhandene Hardware
durch mehrfache Belegung mit Gast-Betriebssystemen effizienter ausnutzen, wohin-
gegen Prozess-VMs auf das Schaffen von Kompatibilität über Betriebssystem- und
Architektur-Grenzen hinweg ausgerichtet sind. Näheres dazu findet sich in [SN05].
Virtualisierung basiert auf einer Aufteilung in einen Wirt (host) und Gast (guest).
Im Wirt läuft ein Virtual Machine Monitor (VMM ), der für die Virtualisierung
zuständig ist. Er isoliert die Gäste voneinander, teilt ihnen ihre Ressourcen zu
und ermöglicht deren gleichzeitige Ausführung, wobei jeder Gast scheinbar nativ
ausgeführt wird und meint, über die volle Kontrolle der Hardware zu verfügen.
Außerdem regelt der VMM auch die Emulation, wenn sich Wirt- und Gast-ISA
(Instruction Set Architecture) unterscheiden [SN05].
Warum wird also Hardware-Unterstützung für die Virtualisierung benötigt, wenn
das Kontrollprogramm dafür in Software realisiert wird? Die x86-Prozessorarchi-
tektur weist einige Schwächen auf, die die Virtualisierung deutlich erschwert. Ziel
der Hardware-Unterstützung ist es nun, diese Schwächen zu beseitigen und eine
möglichst effiziente Virtualisierung zu ermöglichen. Grundsätzlich lässt sich auf je-
der Architektur jede andere Prozessorarchitektur durch naive Interpretation, al-
so durch Nachbildung der einzelnen Befehle in Software, virtualisieren. Dies ist
allerdings sehr ineffizient [SN05] und daher für die Praxis untauglich. Hardware-
Unterstützung versucht also, den Anteil der zu interpretierenden Instruktionen zu
verringern und damit die Performanz zu steigern.
Diese Arbeit möchte einige jener Hardware-Unterstützungen vorstellen und ihre
Funktionsweise erläutern. Zu Beginn werden die formalen Anforderungen an eine
effiziente Virtualisierung beschrieben, um anschließend die x86-Architektur ohne
Erweiterungen als Beispiel für eine schlecht zu virtualisierende Rechnerarchitek-
tur vorzustellen. Um diese Unzulänglichkeiten zu beseitigen, wurden bereits eini-
ge Hardware-Erweiterungen für x86 entwickelt. Davon werden im Kapitel 4 CPU-
Erweiterungen, Speicher- und E/A-Virtualisierung vorgestellt.

2   Formale Anforderungen
Gerald Popek und Robert Goldberg haben 1974 in [PG74] durch ihre Forschungen
formale Anforderungen erarbeitet, die eine effizient zu virtualisierende Architektur
erfüllen muss. Davor gab es dazu kein gesichertes Wissen, sondern nur empirische
Erfahrung, welche Rechner-Architekturen sich gut virtualisieren lassen und welche
zu Problemen führen. Dieses Kapitel stellt die Anforderungen aus [PG74] vor.

Als Grundvoraussetzung für die weiteren Überlegungen wird von einer so genann-
ten Rechnerarchitektur der 3. Generation ausgegangen. Diese muss folgende vier
Voraussetzungen erfüllen:
 1. Zwei Betriebsmodi des Prozessors mit unterschiedlich privilegierten Berechti-
    gungen müssen vorhanden sein. Dies sind in der Praxis der System-Modus und
    Benutzer-Modus.

 2. Die Hardware ist verpflichtet, Speicherschutz und Speicherallokation zu un-
    terstützen. In der x86-Architektur wird dies über Seitentabellen realisiert.

 3. Asynchrone Unterbrechungen sind zwingend notwendig, um die Kommunikati-
    on mit E/A-Systemen zu ermöglichen.

 4. Durch Traps werden Übergangsstellen zur Verfügung gestellt, durch die nicht-
    privilegierte Programme (im Benutzer-Modus) kontrolliert über fest definierte
    Schnittstellen höher privilegierte Systemroutinen (im System-Modus) aufrufen
    können.

Im Folgenden wird davon ausgegangen, dass der Virtual Machine Monitor, der als
Kontrollprogramm die Virtualisierung steuert, im System-Modus und sämtliche an-
dere Software (inkl. Gast-Betriebssysteme) im Gast-Modus ausgeführt werden. Die-
se Funktionsweise einer virtuellen Maschine wird als System-VM bezeichnet, da ein
gesamtes Computersystem inklusive Ein- und Ausgabegeräte nachgebildet wird.
Den Aufbau verdeutlicht Abbildung 1.

Nun werden die im weiteren Text verwendeten Begriffe nach [SN05] definiert:

Privilegierte Instruktionen
Instruktionen heißen genau dann privilegiert, wenn bei der Ausführung einer In-
struktion im Benutzer-Modus generell eine Ausnahme erzeugt wird, während dies
bei Ausführung im System-Modus nicht der Fall ist. Es reicht also nicht aus, wenn
das Verhalten einer Instruktion in den zwei Modi verschieden ist!

Sensitive Instruktionen
So heißen Instruktionen, die auf privilegierte Ressourcen zugreifen. Es gibt da-
bei mehrere Arten von privilegierten Ressourcen: Die Kontroll-sensitiven (con-
trol sensitive), welche die Konfiguration des Systems verändern; also insbesondere
die Hauptspeicher-Verwaltung oder den Prozessor-Modus beeinflussen. Die andere
Gruppe heißt Verhaltens-sensitive (behavior sensitive) Instruktionen. Das Ergebnis
ihrer Ausführung hängt von der Konfiguration der Ressourcen ab. Das sind zum
Beispiel Registerzugriffe, deren Ziel vom Prozessor-Modus abhängt. Nicht-sensitive
Instruktionen werden auch innocuous instructions genannt.

Kritische Instruktionen
sind diejenige Instruktionen, die sensitiv aber nicht privilegiert sind.

                                          2

Abbildung 1: Aufbau einer System-VM nach [SN05]

Diese Arten von Instruktionen hängen nicht von der Virtualisierung, sondern allein
von der Prozessorarchitektur ab.

Drei besondere Eigenschaften sollten bei effizienter Virtualisierung erfüllt sein:
 1. Effizienz (efficiency property)
    Es ist das Ziel, dass alle nicht-sensitiven Befehle direkt auf der Hardware des
    Wirts ohne Eingriffe des VMM ausgeführt werden. Also soll insbesondere keine
    Interpretation stattfinden.

 2. Ressourcen-Kontrolle (resource control property)
    Das Gast-Betriebssystem darf die Ressourcenzuteilung des VMM nicht über-
    stimmen oder manipulieren können, da dies die korrekte Funktionsweise der
    Virtualisierung gefährdet.

 3. Äquivalenz (equivalance property)
    Jedes Programm muss genau so ausführbar sein, wie wenn es ohne Einsatz von
    Virtualisierung ausgeführt würde und es volle Kontrolle über sämtliche Hard-
    ware hätte.
    Folgende Ausnahmen sind dabei akzeptabel: Durch die Existenz eines VMM
    steht weniger Hauptspeicher zur Verfügung. Dieses Problem wird meistens da-
    durch gelöst, dass dem Gast weniger Speicher zur Verfügung steht. Außerdem
    dürfen Timing-Unterschiede im Vergleich zu realer Hardware auftreten, denn
    der VMM verbraucht immer einen geringen Anteil Rechenzeit.

Popek und Goldberg definieren einen VMM als ein Programm, das die Virtualisie-
rung kontrolliert und diese Eigenschaften erfüllt.

Satz von Popek und Goldberg: (engl. Original: [PG74, Theorem 1])
    Für jeden gewöhnlichen Computer mit einer Architektur der 3. Generation
    kann ein Virtual Machine Monitor konstruiert werden, wenn die Menge der

                                           3

sensitiven Instruktionen dieses Computers eine Teilmenge der privilegierten
Instruktionen ist.

Das bedeutet zusammengefasst: Es dürfen keine kritischen Instruktionen existieren!
Auf diese Art und Weise darf nur der VMM auf privilegierte Ressourcen zugreifen,
sonst könnten die Gast-Betriebssysteme die Virtualisierung erkennen, manipulieren
oder sogar umgehen. Da die Gast-Betriebssysteme vollständig im Benutzer-Modus
ausgeführt werden, erzeugen sensitive Instruktionen des Gast-Betriebssystems Aus-
nahmen. Diese fängt der VMM ab und führt eine entsprechende Ausnahme-Be-
handlung aus, die die Wirkung der Instruktion für den Gast nachbildet. Der VMM
emuliert also den Befehl. Danach übergibt er wieder die Kontrolle an den Gast,
der nun über das Ergebnis seines Befehls verfügt und nichts von der Mitarbeit des
VMM bemerkt hat.

3 Die x86-Architektur

Hier soll die x86-Architektur ohne die neu entwickelten VT-Erweiterungen, die teil-
weise in Kapitel 4 vorgestellt werden, als Beispiel für eine schlecht zu virtualisierende
Prozessorarchitektur dienen. Bei deren Entwurf wurde es versäumt an Virtualisie-
rung zu denken.
Zwar erfüllen die x86-Prozessoren die vier Anforderungen an eine Architektur
der 3. Generation [RI00], aber das reicht wie in Kapitel 2 gesehen nicht aus. Die x86-
Architektur stellt der Software vier Betriebsmodi zu Verfügung, darunter auch den
von [PG74] geforderten System- und Benutzer-Modus. Für den Speicherschutz wer-
den die notwendigen Schutzmaßnahmen durch Paging und Segmentation implemen-
tiert. Unterbrechungen und Ausnahmen exisiteren und ermöglichen somit einen Da-
tenaustausch zwischen CPU bzw. Hauptspeicher und E/A-Geräten. Durch Call Ga-
tes sind Übergänge zwischen den vier Betriebs-Modi möglich; niedrig-privilegierte
Programme können damit höher-privilegierte Systemroutinen aufrufen und somit
den Betriebsmodus wechseln.
Dass diese Architektur trotzdem so schlecht zu virtualisieren ist, liegt daran,
dass kritische Instruktionen existieren. Es gibt also sensitive Instruktionen, die auf
privilegierte Resourcen zugreifen, dabei im Benutzer-Modus allerdings keine Aus-
nahme auslösen. Als Folge daraus kann der VMM diese Befehle nicht abfangen,
um ihre Wirkung durch Emulation für das Gast-Betriebssystem nachzubilden. So
existieren beim Intel Pentium z.B. 17 kritische Instruktionen [RI00]. Dazu gehören
unter anderem bestimmte Zugriffe auf Register (z.B. die Befehle SGDT, SIDT) oder
Zugriffe, die Schutzmaßnahmen verletzen, wie Direktzugriffe auf Stack, physischen
Speicher oder auch einige Sprünge (z.B. PUSHF, POPF, CALL, JMP).
Es gibt trotz ungeeigneter Architekturen einige Lösungsmöglichkeiten, durch die
diese Unzulänglichkeiten durch den VMM mit Hilfe von Software beseitigt werden.
Ziel dabei ist es immer, die kritischen Instruktionen, die in den ausgeführten Pro-
grammen vorkommen, vor der Ausführung zu entdecken und zu umgehen [RI00].
Eine Möglichkeit ist die im Kapitel 1 angesprochene vollständige Interpretati-
on, die definitionsgemäß jeden Befehl durch Interpretation nachbildet und somit
sämtliche Probleme bei kritischen Instruktionen umgeht. Diese Lösung ist aller-
dings extrem ineffizient und es wird daher versucht, sie in der Praxis so weit wie
möglich zu vermeiden. Oft werden durch Code-Patching kritische Instruktionen vor
ihrer Ausführung durch den VMM erkannt und gegen andere Instruktionen ausge-
tauscht. Diese führen stattdessen einen Sprung in den VMM durch, dieser bildet die
Wirkung des Befehls durch Emulation nach und führt anschließend die Ausführung

des Gast-Programms direkt nach dem kritischen Befehl fort. Dies entspricht al-
so der selben Funktionsweise wie die Nachbildung sensitiver Instruktionen, die im
Benutzer-Modus eine Ausnahme erzeugen. Nur müssen bei Code-Patching die zu
emulierenden Befehle explizit durch den VMM gesucht werden, da sie nicht auto-
matisch durch das Auftreten von Ausnahmen erkannt werden.
    Binärübersetzung bietet die selben Möglichkeiten wie Code-Patching, nur lassen
sich hier noch weitere Optimierungen durch den VMM durchführen, da dabei ganze
Code-Blöcke in die Wirt-ISA übersetzt werden. Es können also nicht nur kritische
Instruktionen erkannt und ersetzt, sondern auch weitere Performanz-steigernde Op-
timierungen durchgeführt werden.
    In den Anfängen der Virtualisierungstechnik der x86-Architektur wurde Para-
virtualisierung eingesetzt. Dort wird der Quell-Code des Gastes so verändert, dass
keine kritischen Instruktionen auftreten, sondern stattdessen direkt Systemroutinen
des VMMs aufgerufen werden. Es sind also Veränderungen der eingesetzten Gast-
Betriebssysteme notwendig. Das bedeutet im Umkehrschluss, dass nur Betriebssys-
teme paravirtualisiert werden können, deren Quell-Code zur Verfügung steht und
verändert werden darf. Ferner können die Gast-Betriebssysteme erkennen, dass sie
nicht nativ, sondern virtualisiert ausgeführt werden.
    Alle diese Lösungen erlauben eine Virtualisierung auf ungeeigneter Hardware,
aber erfordern mehr Aufwand. Sie sind bis auf die Paravirtualisierung nicht so
performant und benötigen im Fall der Paravirtualisierung sogar Änderungen an der
eingesetzten Software.
    Intel und AMD haben inzwischen Virtualisierungserweiterungen für ihre Archi-
tekturen entwickelt und nennen sie VT-x (auch Vanderpool genannt) bzw. AMD-V
(auch Pacifica genannt).

4     Hardware-Unterstützung

Hardwareunterstützung für Virtualisierung versucht, die Hardware so zu verbes-
sern, dass sie möglichst viele Aktionen zur Virtualisierung selbst durchführt und
dem VMM somit Arbeit, Performanz-mindernde Emulation und einige Kontext-
wechsel durch Ausnahmebehandlungen erspart.
Es werden also nicht nur kritische Instruktionen beseitigt, sondern auch andere
Abläufe, wie zum Beispiel der Wechsel zwischen zwei Gast-Betriebssystemen auto-
matisiert.

   Hier werden drei Hauptkategorien von Erweiterungen vorgestellt; zuerst die
wichtigen CPU-Erweiterungen, dann Methoden zur Speichervirtualisierung und an-
schließend Hilfen zur Virtualisierung von E/A-Transaktionen.

4.1   CPU-Erweiterungen

CPU-Erweiterungen dienen vor allem der Beseitigung von kritischen Instruktionen,
schnelleren Wechseln zwischen Gast-Betriebssystemen und beschleunigter Abarbei-
tung von Ausnahmen und Unterbrechungen.

Einführung neuer Modi
Um kritische Instruktionen effizient aus einer immer wieder erweiterten Architektur
zu beseitigen und dabei gleichzeitig die Kompatibilität zu wahren, wurde ein neuer
niedriger-privilegierter Modus, der Gast-Modus (guest mode) eingeführt. In diesem
Modus wird während der Virtualisierung eine direkte Ausführung des Gast-Codes

                                         5

unterstützt; es ist also der Betriebsmodus für die Gast-Betriebssysteme [AA06].
Der bisher von der x86-Architektur bekannte höher-privilegierter Modus wird Wirt-
Modus (host mode) genannt. Er ist die Ausführungsgrundlage für den VMM oder
ein Betriebssystem, wenn kein VMM existiert; also für native Ausführung von Be-
triebssystemen ohne Virtualisierung.
Durch die Nutzung des bisherigen Modus als höher-privilegierten Modus müssen
bei nativ ausgeführten Betriebssystemen keine Anpassungen durchgeführt werden,
da die Architektur aus deren Sichtweise unverändert ist. Die alleinige Nutzung des
Wirt-Modus entspricht also einem x86-Prozessor ohne Virtualisierungs-Erweiterun-
gen. Der Gast-Modus hingegen erzeugt bei allen sensitiven Instruktionen Ausnah-
men, über die zurück in den VMM zur Interpretation des Befehls gesprungen werden
kann. Deswegen enthält dieser Modus nur noch privilegierte und keine kritischen
Operationen mehr.
Sowohl Wirt- als auch Gast-Modus unterstützen die von x86-Prozessoren be-
kannten vier Privilegierungsringe. So können Betriebssysteme auch im Gast-Modus
keinen Unterschied zu einer x86-Architektur ohne Virtualisierungs-Erweiterungen
erkennen. Dieser Trick beseitigt ebenfalls die so genannten Ring-Aliasing und Ring
Compression Probleme. Ring Aliasing bezeichnet die Probleme, die auftreten, wenn
Software in einem Privilegierungsring ausgeführt wird, für den sie nicht entwickelt
wurde. Bei Ring Compression befinden sich Betriebssystem und Nicht-Betriebssystem-
Software im selben statt in verschiedenen Privilegierungsringen.

Durch diese zwei neuen Modi exisiteren auch zwei neue Übergänge:

– von Wirt- nach Gast-Modus: VM-Eintritt (VM entry)
Das ist der Übergang von VMM in das Gast-Betriebssystem.

– von Gast- nach Wirt-Modus: VM-Austritt (VM exit)
Das ist der Übergang vom Gast-Betriebssystem in den VMM.

Intel verwendet eine andere Nomenklatur und nennt den Wirt-Modus VMX root
sowie den Gast-Modus VMX non-root [UNR+ 05]. AMD beschränkt sich auf die
allgemeinen Bezeichner Wirt- und Gast-Modus.
Wie bereits angedeutet, unterscheidet sich das Verhalten bei der Ausführung
im Gast-Modus deutlich vom Wirt-Modus [UNR+ 05]. Dort sorgen bestimmte Be-
fehle für einen VM-Austritt, also einem Übergang vom Gast-Betriebssystem in den
VMM. Dies entspricht den Ausnahmen, die bei privilegierten Befehlen die Kontrolle
vom Gast in den VMM transferieren [NSL+ 06]. Das heißt, dass die VM-Austritte
immer bei sensitiven Befehlen, die das Gast-Betriebssystem in Virtualisierung nicht
nativ auf der Hardware abarbeiten kann, stattfinden. Somit sorgt die Hardware-
Architektur automatisch dafür, dass die entsprechende Interpretationsroutine des
VMM zur Nachbildung der Instruktion angesprungen wird.

Über eine spezielle Datenstruktur VMBC, die noch vorgestellt wird, lässt sich für
jeden Gast getrennt konfigurieren, ob bei Instruktionen, Ausnahmen oder Unterbre-
chungen VM-Austritte in den VMM stattfinden sollen. Das bringt den Vorteil, dass
die Überprüfung, ob die Kontrolle dem VMM übertragen werden soll, in Hardware
und nicht wie bisher in Software durch die Ausnahmebehandlung des VMM selbst
durchgeführt werden kann. Auch dies bringt wieder geringere Performanzeinbußen
mit sich, da weniger Kontextwechsel stattfinden müssen.

Exkurs zu CPU-Erweiterungen des Intel Itanium
Dort heißt die Erweiterung VT-i [UNR+ 05] und bietet ähnliche Funktionen. Ein

zweiter Betriebsmodus führt neue, bisher nicht vorhandene Ausnahmen ein und
ermöglicht damit den Übergang in den VMM. Ein PAL Firmware Layer dient als
feste Schnittstelle zwischen VMM und Hardware. So sollen VMMs mit verschiedenen
CPU-Typen immer gleich kommunizieren können, um Weiterentwicklungen bei der
CPU zu ermöglichen und gleichzeitig mit den schon existierenden VMMs kompatibel
zu bleiben.
Genaueres findet sich für Interessierte in [UNR+ 05] und [NSL+ 06].

Einführung neuer Datenstrukturen
Die neue Datenstruktur Virtual Machine Control Block (VMCB ) [AA06] hilft das
Verhalten des Prozessors im Gast-Modus bezüglich VM-Ein- und Austritten zu
regeln. Wiederum hat Intel dafür einen eigenen Namen: Virtual Machine Control
Structure (VMCS)
Der VMCB unterstützt den VMM sowohl – wie gerade erläutert – bei Übergängen
zwischen Gast-Betriebssystemen und VMM als auch bei einem Wechsel des akti-
ven Gastes. Die Datenstruktur enthält Speicher, in dem bei jedem VM-Austritt der
Zustand des Prozessors automatisch gespeichert wird. Bei VM-Eintritten wird der
Zustand des jeweiligen Gastes ebenso durch die Hardware wiederhergestellt [AA06].
Dies beschleunigt den Wechsel zwischen Gästen deutlich.

Der VMCB ist in mehrere Sektionen unterteilt. Die zwei wichtigsten davon sind:
– Die Host-State-Area
Diese speichert den Status des VMM, so dass dieser bei Ausführung eines Gastes
gesichert und bei Bedarf jederzeit von der Virtualisierungs-Hardware automa-
tisch wiederhergestellt wird.

– Die Guest-State-Area
Diese enthält für jeden Gast den entsprechenden Zustand des virtuellen Pro-
zessors, der zu diesem Gast gehört. Das sind zum Einen Register, welche die
Prozessoroperationen steuern, z.B. das Segment-Register CR3 für die Konfigu-
ration des Hauptspeichers, zum Anderen auch Zustand, der nicht über Register
zugänglich ist; wie der aktuelle Zustand über die Unterbrechbarkeit des Pro-
zessors. Dieser nicht-zugängliche Zustand müsste sonst durch den VMM über
langwierige Befehlssequenzen explizit wiederhergestellt werden, was auf diese
Weise unnötig ist.
Der VMCB enthält insbesondere nicht die Register, die der VMM selbst laden
und speichern kann. Das sind u.a. die vier Allzweckregister EAX, EBX, ECX und
EDX.

Ein VM-Eintritt lädt den in der Guest-State-Area des VMCB gespeicherten Zu-
stand in den Prozessor. Ein VM-Austritt speichert diesen Zustand dort ab und lädt
daraufhin automatisch die Host-State-Area aus dem VMCB in den Prozessor, so
dass in den VMM gesprungen werden kann und dieser sofort lauffähig ist. Außer-
dem werden dabei im VMCB Daten abgelegt, aus denen der VMM genau erkennen
kann, welches Ereignis der Auslöser für den VM-Austritt war, so dass auch er über
diese Information verfügen kann.
Sowohl VM-Ein- als auch VM-Austritte laden und speichern vollautomatisch
das Register CR3, das die Basis für die Seitentabellen-Hierarchie der Hauptspei-
cherverwaltung darstellt. So wird die Virtualisierung des Speichers auch durch die
Hardware erleichtert.
Deswegen können Code und Daten von VMM und Gast-Betriebssystem in verschie-
denen Adressräumen liegen, was mit der bisherigen Architektur nicht möglich war.

Das löst das sogenannte Address-Space-Compression-Problem. Dies tritt auf, wenn
ein Teil des VMM im Hauptspeicher des Gastes abgelegt werden muss, was ohne
dieser Funktion der Fall wäre. Wird das nicht per Hardware, sondern über Software
gelöst, muss der VMM einen hohen Aufwand treiben, um sich im Hauptspeicher
des Gastes vor diesem zu verbergen. Sonst könnte der Gast u.U. abstürzen, die
Virtualisierung entdecken oder sogar den VMM manipulieren [UNR+ 05].
    Der VMCB enthält zusätzlich VM-Execution Control Fields [UNR+ 05]. Sie er-
möglichen fein-granulare Einstellungen, bei welchen Events, Ausnahmen oder Un-
terbrechungen VM-Austritte ausbleiben oder stattfinden sollen. Dadurch ist die
Hardware so flexibel konfigurierbar, dass der VMM verschiedenste Virtualisierungs-
Strategien umsetzen kann.

Interrupt-Virtualisierung
Hier wurden Hardware-Hilfen eingeführt, die bei einer Änderung der Unterbre-
chungskonfiguration durch ein Gast-Betriebssystem die Kontrolle an den VMM
zurück transferieren, so dass er sowohl diesen Befehl emulieren als auch weitere
notwendige Schritte einleiten kann. Intel integriert diese Funktionalität in VT-x in
mehreren kleineren Funktionen.

   External-Interrupt-Exiting ermöglicht es bei jeder Änderung der Unterbrechungs-
konfiguration einen VM-Austritt und einen Wechsel in den VMM durchzuführen.
Dieser kann dann den Änderungswunsch des Gastes überprüfen, nachvollziehen und
gegebenenfalls verbieten oder emulieren.
   Durch Interrupt-Window-Exiting stellt die Hardware eine Funktion zur Verfü-
gung, die jedes mal einen VM-Austritt herbeiführt, wenn ein Gast-OS angekündigt
hat, nun bereit zu sein, Unterbrechungen zu empfangen. So kann der VMM entschei-
den, ob er den Gast betreffende Unterbrechungen an diesen weiterleitet, ignoriert
oder selbst abarbeitet.

    Diese Erweiterungen helfen, die Rechnerarchitektur so zu verbessern, dass Gast-
Betriebssysteme effizient in ihrer gewünschten Privilegierungsstufe ausgeführt wer-
den können, aber gleichzeitig der VMM die volle Kontrolle über das System und
die Hardware besitzt [UNR+ 05]. Allein diese Hilfen reichen aus, um eine komplet-
te Virtualisierungs-Lösung für die x86-Architektur zur Verfügung zu stellen [AA06].

4.2   Speichervirtualisierungen
Die Erweiterungen für die Speichervirtualisierung sind nach den Forderungen aus
Kapitel 2 nicht notwendig, sondern stellen lediglich eine Hilfe dar. So soll dem VMM
Arbeit abgenommen und direkt in der performanteren Hardware umgesetzt werden.

Virtualisierung der Speichertabellen
Die dafür zusätzlich eingeführte Hardware wird manchmal als MMU-Unterstützung
bezeichnet [AA06]. In Anlehnung an [SN05], werden in diesem Abschnitt folgende
Bezeichner verwendet:

Virtuelle Adressen
Diese bezeichnen die Prozessadressen, mit denen die einzelnen Prozesse im Gast-
Betriebssystem ihren zugewiesenen Speicher ansprechen.

Reale Adressen
In einer Plattform ohne Virtualisierung, in der nur ein Betriebssystem nativ auf

                                          8

der Hardware ausgeführt wird, entsprechen die realen Adressen den physikalischen
Adressen der Hardware. Bei Vorhandensein einer Virtualisierung stellt der reale
Adressbereich den gesamten Speicherbereich eines einzelnen Gastes dar. Daher ist
eine Umsetzung von virtuellen in reale Adressen notwendig. Diese wird bei Virtua-
lisierung genauso wie bei nativer Ausführung vom (Gast-)Betriebssystem verwal-
tet, muss aber durch den VMM für jeden Gast einzeln und getrennt durchgeführt
werden. Allerdings können die Gast-Betriebssysteme ihre Speicherverwaltung nicht
selbst direkt auf der Hardware konfigurieren, sondern der VMM fängt wiederum
diese Befehle ab und emuliert sie.

Physikalische Adressen
Die physikalischen Adressen sind die tatsächlichen Speicheradressen, mit denen die
Hardware angesprochen wird. Sie entsprechen bei nativer Ausführung den realen
Adressen, bei aktivierter Virtualisierung muss jedoch noch eine weitere Umsetzung
von realen in physikalische Adressen durchgeführt werden. Dies geschieht mit Hilfe
des VMM, da die realen Adressen nur innerhalb eines Gast-Betriebssystem eindeu-
tig sind. Deswegen können mehrere Gäste die selben realen Adressen verwenden, die
aber vom VMM auf verschiedene physikalische Adressen abgebildet werden müssen.

Deswegen muss bei Virtualisierung ebenfalls die Speicherarchitektur virtualisiert
werden. Es ist nun die 3-fache Umsetzung

          virtuelle Adresse → reale Adresse → physikalische Adresse

notwendig.
    Eine solche 2-fache Indirektion mit Einsprung in den VMM bei jedem Haupt-
speicherzugriff würde natürlich die Performanz empfindlich stören. Deshalb wird
das Verfahren bisher abgekürzt, indem die Seitentabellen der Hardware den Inhalt
sogenannter Schattentabellen (Shadow-Page-Tables) enthalten. Diese beinhalten di-
rekt die Umsetzung von virtuellen zu physikalischen Adressen.
Dabei ist bei jeder Änderung der Seitentabellen durch das Gast-Betriebssystem
auch Administrationsaufwand durch den VMM notwendig. Der VMM muss die
Schattentabellen austauschen, wenn bei der Virtualisierung ein Wechsel des Gast-
Betriebssystems oder ein Prozesswechsel innerhalb eines Gast-Betriebssystems auf-
tritt. Der Grund dafür ist, dass gleichzeitig in einem Betriebssystem ausgeführte
Prozesse die selben virtuellen Adressen verwenden können, diese aber auf unter-
schiedliche physikalische Adressen abgebildet werden müssen.
    AMDs Umsetzung der Speichervirtualisierung nennt sich Nested Paging [AMD05].
Intel führte eine ähnliche Technik Extended Page Tables (EPT ) [Int09] mit der
Nehalem-Architektur ein.
    Wenn die EPTs aktiviert sind, führt die Adressumsetzung in Hardware keine
Umsetzung von virtuellen in reale Adressen durch, sondern bedient sich zu den
Seitentabellen noch zusätzlicher EPT-Tabellen und kann Adressen direkt von vir-
tuellen in physikalische umrechnen. In Abbildung 2 sieht man im Überblick, wie mit
Hilfe der konventionellen Seitentabellen, auf deren Basis der Inhalt des Registers
CR3 verweist, die virtuelle in eine reale Adresse umgewandelt wird. Anschließend
kann diese durch die EPT-Tabellen auf die entsprechende physikalische Adresse
abgebildet werden.
    Die EPT-Tabellen beinhalten dabei die Informationen, durch die reale auf phy-
sikalische Adressen abgebildet werden können, und berücksichtigen auch, welches
Gast-Betriebssystem gerade aktiv ist. Als Folge müssen nur noch die Gast-Betriebs-
systeme ihre Seitentabellen verwalten wie im nicht-virtualisierten Fall und der VMM
muss nicht mehr eingreifen. Er muss also insbesondere keine Hauptspeicheraufrufe
mehr über Ausnahmen abfangen und keine Schattentabellen mehr verwalten. Dies

                                        9

Abbildung 2: Adressumsetzung mit Hilfe von EPT-Seitentabellen

übernehmen die Hardware-Erweiterungen für ihn [NSL+ 06]. In Abbildung 3 wird
die interne Funktionsweise des vier-stufigen Verfahrens dargestellt. Mit Hilfe des
Registers CR3 und dem ersten Teil der virtuellen Adresse wird der entsprechende
Eintrag in der ersten Stufe der Umsetzung gefunden. Die dadurch ermittelte Spei-
cheradresse weist zusammen mit dem zweiten Teil der virtuellen Adresse auf einen
weiteren Tabellen-Eintrag (einer anderen Tabelle). Dieser Eintrag verknüpft mit
dem dritten Teil der virtuellen Adresse repräsentiert die reale Adresse. Bis hierhin
entspricht der Ablauf dem der konventionellen Seitentabellen. Erst jetzt wird die
reale Adresse über die vierte Tabelle in ihre zugehörige physikalische Adresse um-
gewandelt.

Abbildung 3: Adressumsetzung (detailiert) mit Hilfe von EPT-Seitentabellen

Virtual Processor Identifiers (VPIDs)
Auch die Virtual Processor Identifiers (VPIDs) wurden mit der Nehalem-Archi-
tektur eingeführt [Int09] und weisen jedem virtuellen Prozessor eine eindeutige ID
größer 0 zu. Die ID 0 referenziert den VMM. Die VPIDs erweitern die Einträge
des Hardware-TLBs (Translation Lookaside Buffer ) (und entsprechen den aus den
RISC-Architekturen bekannten ASIDs1 ) [SN05].
Durch das zusätzliche Vorhandensein eines eindeutigen Identifiers lassen sich die
TLB-Einträge ihrem zugehörigen Gast-Betriebssystem zuordnen. Dadurch können
1
Adress space identifiers (ASIDs) werden in RISC-Architekturen verwendet, um Einträge
des TLBs eindeutig einem Prozess zuordnen zu können.

sich die TLB-Einträge mehrerer Gäste gleichzeitig im TLB befinden, da die Hard-
ware sie unterscheiden und automatisch den richtigen Eintrag verwenden kann.
Als Folge kann der bisher notwendige TLB-Flush, also das vollständige Leeren
des TLBs, bei einem Wechsel des aktiven Gastes entfallen. Das spart einerseits
Zeit, die der Flush benötigt, und ermöglicht es den Gästen in ihrem nächsten
Ausführungsintervall einige ihrer alten TLB-Einträge vorzufinden. Die Zeitersparnis
entsteht, da eine Abfrage des TLB deutlich schneller möglich ist, als der relative
komplexe Umweg über die Seiten- und EPT-Tabellen bei einem TLB-Miss. Wie
groß dieser Vorteil ausfällt, hängt natürlich davon ab, wie viele der TLB-Einträge
bei Ausführung der anderen Gäste verdrängt werden und bei Rückkehr in den Gast
noch zur Verfügung stehen.

4.3 E/A-Virtualisierungen

In IT-Umgebungen wird häufig Virtualisierung eingesetzt, um damit mehrere Ser-
ver auf einer Hardware zusammen zu fassen. Viele Server-Applikationen sind jedoch
sehr E/A-intensiv [AJM+ 06], was in Verbindung mit Virtualisierung zu Performanz-
Problemen führen kann. Dies schadet dem möglichen Ziel, die meist recht teuere
Hardware besser auszunutzen. Das generelle Problem bei E/A-Operationen durch
virtualisierte Gäste ist, dass sie hauptsächlich aus Unterbrechungen und direkten
DMA-Zugriffen auf den Hauptspeicher bestehen. Das sind beides Operationen, die
bei Virtualisierung die Mithilfe des VMM benötigen, da es sich dabei um privilegier-
te Instruktionen handelt und bei jeder Unterbrechung beziehungsweise bei jedem
DMA-Zugriff ein Kontextwechsel zwischen Gast und VMM vollzogen werden muss.
E/A-Transaktionen mussten also bisher entweder langsam emuliert oder durch Pa-
ravirtualisierung beschleunigt werden.
Ziel der Hardware-Erweiterungen ist es, diese Operationen so durch Hardware
zu unterstützen, dass diese viele Aufgaben des VMM übernimmt und ihn damit
deutlich entlastet.

DMA-Remapping
Bereits heute existieren Input/Output Memory Management Units (IOMMUs), um
Geräte mit beschränkten DMA-Fähigkeiten effizient zu adressieren. Dieses Verfah-
ren wird zum Beispiel beim Zugriff auf den AGP-Bus durch die Graphics Aperture
Protection Table (GART ) angewandt. Dabei lässt sich über die IOMMU konfi-
gurieren, dass alle Zugriffe auf einen bestimmten Hauptspeicherbereich direkt an
das jeweilige Gerät unabhängig von der Quelle des Zugriffs weitergeleitet werden.
Und genau dadurch wird dieses Verfahren für eine effiziente Virtualisierung un-
brauchbar, denn für diese müsste auch die Quelle der Zugriffs, also das jeweilige
Gast-Betriebssystem, berücksichtigt werden. Außerdem stellt das DMA-Verfahren
ein Problem für die Virtualisierung dar, da auf diesen Weg direkte Hauptspeicher-
zugriffe unter Umgehung der CPU möglich sind. In virtualisierten Systemen würden
diese auch die Kontrollen des VMMs umgehen.
Deswegen wird für Virtualisierung die IOMMU so erweitert, dass sie sich allge-
meiner einsetzen lässt. So können durch den VMM mehrere gleichzeitig existierende
DMA Protection Domains erstellt werden, die Intel laut [Int08] als abstrakte, iso-
”
lierte Umgebungen innerhalb der Plattform, der eine Untermenge des Physikalischen
Hauptspeicher zugeordnet sind“, definiert sind. Das heißt, dass durch Konfigurati-
on zugehöriger E/A-Seitentabellen (I/O-Page-Tables) die Geräte des Systems den
Domänen zugewiesen werden können. Wird nun auf einen Hauptspeicherbereich zu-
gegriffen, der die Daten an ein E/A-Gerät weiterleitet, wird nun auch die Quelle

des Zugriffs für die Umsetzung dieser Umleitung benutzt und mit Hilfe der E/A-
Seitentabellen die effektiven Zugriffsrechte und das Ziel für den Zugriff bestimmt
[AJM+ 06].
    In Abbildung 4 wird DMA-Remapping in einer Umgebung mit zwei voneinan-
der getrennten Protection Domains dargestellt [AJM+ 06]. Darin bezeichnet rA die
realen Adressen, welche die Gast-Betriebssysteme verwenden, und pA die physika-
lischen Hauptspeicheradressen. Die Geräte Gerät 1 und Gerät 2 sind den beiden
Protection Domains zugeordnet und haben über die realen Adressen jeweils ihre
eigene – voneinander unabhängige – Sicht auf den Hauptspeicher. Die realen Adres-
sen der Protection Domains und der Geräte werden durch die erweiterte IOMMU
jeweils auf unterschiedliche physikalische Adressen abgebildet.

                          Abbildung 4: DMA-Remapping

   Häufig benutzte E/A-Seitentabellen werden durch die Hardware automatisch
gecached. Sie verfügen über Berechtigungen abhängig vom Ursprung des Zugriffs
und unterstützen mehrere Ebenen von Indirektionen und verschiedene Blockgrößen.
   Dadurch virtualisiert direkt die Hardware die DMA-Zugriffe auf den Hauptspei-
cher bei E/A-Operationen und der VMM steht nur noch in der Pflicht, die IOMMU
nach seinen Wünschen zu konfigurieren. Er wird bei normalen E/A-Transaktionen
nicht mehr aktiviert, sondern nur bei Konfigurationsänderungen durch die Gast-
Betriebssysteme.

Interrupt-Remapping
Wie bereits angesprochen stellen Unterbrechungen, vor allem durch E/A-Transak-
tionen ausgelöste, für die Virtualisierung ein Problem dar, das bisher nur durch
zeitaufwändige Sprünge in den VMM und Interpretation gelöst werden konnte.
    Neben den älteren Legacy Interrupts existieren auch Message Signaled Interrupts
(MSIs), die DMA-Schreib-Aktionen auf einer voreingestellten, festen Hauptspei-
cheradresse sind. Die zu übergebenden Attribute der Unterbrechung stehen dabei
in den Daten des Schreib-Befehls.
    Durch Hardware-Erweiterungen lassen sich nun MSIs virtualisieren und wieder-
um der Verantwortung des VMMs entziehen. Bei Einsatz des Interrupt-Remapping
enthalten die Daten eines MSI nicht mehr die Attribute einer Unterbrechung, son-

                                        12

dern nur eine eindeutige Unterbrechungs-ID. DMA-Anfragen, die als MSIs erkannt
werden, werden nun gesondert bearbeitet.
    Die in den Daten der Schreibinstruktion angegebene Unterbrechungs-ID wird
in einer Interrupt-Remapping Tabelle nachgeschlagen. Diese wird vom VMM ver-
waltet und enthält als Einträge Paare von IDs und deren entsprechenden Zielen.
Dadurch kann direkt in Hardware zu einer MSI deren Ziel, das entsprechende Gast-
Betriebssystem, ermittelt und die Unterbrechung dorthin weitergeleitet werden.

Hardware Caching und Invalidierung
Um die Effizienz noch weiter zu steigern, werden für die DMA- und Interrupt-
Remapping-Tabellen Caches angelegt, die häufig benutzte Zugriffe beschleunigen.

Dabei spezifiziert Intel in [Int08] vier verschiedene Caches:
 1. Interrupt Entry Caches
    Diese speichern häufig benutzte Einträge der Interrupt-Remapping-Tabelle.

 2. Context Caches
    Durch die Context Caches steht eine schnelle Umsetzung zur Verfügung, welche
    Hardware im System welcher Protection Domain zugeordnet ist.

 3. I/O Translation Look-aside Buffers (IOTLB )
    In den IOTLBs werden die häufigsten Ergebnisse der Übersetzung von virtuellen
    DMA-Adressen in ihre echten Ziel-Adressen nach erfolgreichem Nachschlagen
    in den Tabellen des DMA-Remappings gechached. Zusätzlich werden auch die
    effektiven Zugriffsrechte gespeichert.

 4. Page Directory Entries (PDE )
    Die am meisten benutzten Einträge der DMA-Remapping-Tabelle werden in
    den PDEs vorgehalten.

Da wie bei allen Caches deren Größe beschränkt ist, muss bei Speichermangel Platz
für neue Einträge geschaffen werden. Es stehen folgende zwei Invalidierungsstrate-
gien zur Verfügung [Int08]:
 1. Synchrone Invalidierung
    Die Hardware stellt Register zur Verfügung, die direkt auf Hauptspeicherzellen
    abgebildet werden. Dort hinein können die Invalidierungsbefehle geschrieben
    werden. Diese werden von der Hardware erkannt und sofort ausgeführt.

 2. Queued Invalidation
    Hier existiert eine Warteschlange im Hauptspeicher, in welche die Software neue
    Invalidierungsbefehle einfügen kann. Diese werden im Unterschied zur synchro-
    nen Invalidierung nicht sofort, sondern erst später zu einem passenden Zeitpunkt
    ausgeführt.
    Durch einen Invalidation-Wait-Befehl lässt sich eine sofortige Ausführung aller
    Befehle in der Warteschlange erzwingen.

5   Schlussbetrachtung
Virtualisierung begann sich in den letzten Jahren immer weiter zu verbreiten und
ist nun nicht mehr nur wie in den 70er Jahren des 20. Jahrhunderts auf Mainframes,

                                         13

sondern auch auf kleineren Servern oder gar Workstations zu finden. Im Gegensatz
zu den CPU-Architekturen der Mainframes sind die heutzutage am verbreitetsten
x86-Prozessoren jedoch nicht für Virtualisierung entwickelt worden und stellen eine
dafür ineffiziente Architektur dar. Erst durch die Anpassungen der jüngsten Zeit
wird die x86-Architektur für Virtualisierung effizient nutzbar und es gibt immer
neue Erweiterungen, die versuchen, die Performanz bei Virtualisierungslösungen
noch zusätzlich zu erhöhen.

Die bis heute vorherrschenden Software-Lösungen, die die entstandenen Proble-
me aufwändig in Software umgehen, sind eben aus diesem Missstand entstanden.
Durch ihren inzwischen großen Entwicklungsvorsprung ist ihre Effizienz beeindru-
ckend und sie beherrschen Optimierungsmöglichkeiten, die in reiner Hardware nie-
mals nutzbar sein werden, wie zum Beispiel optimierte Binärübersetzung ganzer
Codeblöcke.

Deswegen gibt es bisher auch noch Anwendungsgebiete, in denen reine Soft-
warelösungen noch deutlich performanter sind als VMMs, die auf den Hardware-
Erweiterungen basieren [AA06]. Es ist aber davon auszugehen, dass auch der An-
satz durch verbesserte Hardware in seiner weiteren Entwicklung noch an Effizi-
enz zunehmen wird. Vor allem Mischlösungen, die Hardware-Erweiterungen mit
Software-Optimierungen verbinden, werden wohl die Performanz noch einmal deut-
lich erhöhen können.

Literatur
AA06. Keith Adams and Ole Agesen. A comparison of software and hardware techni-
ques for x86 virtualization. In Proceedings of ASPLOS’06, San Jose, California,
USA, October 2006. ACM Press.
AJM+ 06. Darren Abramson, Jeff Jackson, Sridhar Muthrasanallur, Gil Neiger, Greg
Regnier, Rajesh Sankaran, Ioannis Schoinas, Rich Uhlig, Balaji Vembu, and
John Wiegert. Intel virtualization technology for directed i/o. Intel Technology
Journal, Vol. 10 Issue 3, August 2006.
AMD05. AMD. Secure virtual machine architecture reference manual. Technical report,
Advanced Micro Devices, May 2005.
Int08. Intel. Intel virtualization technology for directed i/o architecture specification.
Technical report, Intel, September 2008.
Int09. Intel. Intel core i7 processor extreme edition series and intel core i7 processor
specification update. Technical report, Intel, March 2009.
NSL+ 06. Gil Neiger, Amy Santoni, Felix Leung, Dion Rodgers, and Rich Uhlig. Intel vir-
tualization technology: Hardware support for efficient processor virtualization.
Intel Technology Journal, Vol. 10 Issue 3, August 2006.
PG74. Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable
third generation architectures. Commun. ACM, 17(7):412–421, 1974.
RI00. J. Robin and C. Irvine. Analysis of the intel pentium’s ability to support a
secure virtual machine monitor. In Proceedings of the 9th USENIX Security
Symposium, Denver, CO, August 2000.
SN05. Jim Smith and Ravi Nair. Virtual Machines: Versatile Platforms for Systems
and Processes (The Morgan Kaufmann Series in Computer Architecture and
Design). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2005.
UNR+ 05. Rich Uhlig, Gil Neiger, Dion Rodgers, Amy L. Santoni, Fernando Martins, An-
drew Anderson, Steven Bennett, Alain Kaegi, Felix Leung, and Larry Smith.
Intel virtualization technology. IEEE Computer Society, 5:48–56, July 2005.

Sie können auch lesen