Blockseminar. Moderne Hardware und Betriebssysteme Virtuelle Maschinen in Hard- und Software. Sommersemester 2006

Transkript

1 Blockseminar Moderne Hardware und Betriebssysteme Virtuelle Maschinen in Hard- und Software Sommersemester 2006 U N S A R I V E R S A V I E I T A S N I S S Universitat Saarbrucken Fachbereich 6.2, Informatik Lehrstuhl fur Betriebssysteme Prof. Dr. Helge Scheidig Saarbrucken, 22. September 2006

2 Inhaltsverzeichnis 1 Einleitung 2 2 Schlusselkonzepte Erscheinungsbild Zustande Kontrolle der Betriebsmittel Native und moderierte virtuelle Maschinen Virtualisierung der Betriebsmittel Prozessor Instruktionstypen Bedingungen zur Virtualisierung der ISA Problematische Instruktionen und deren Behandlung Speicher Seitentabellen und Seitenfehler Translation Look-aside Buer Eingabe & Ausgabe Gerate Aktivitaten Moderierte virtuelle Maschinen Leistungsprobleme Grunde der Leistungsverminderung Verbesserung der Leistung

3 Virtuelle Maschinen fur vollstandige Computersysteme J. Marc Roth 22. September 2006 Zusammenfassung In dieser Ausarbeitung zum Blockseminar Virtuelle Maschinen in Hardund Software stellen wir virtuelle Maschinen (VM) fur vollstandige Computersysteme vor. Das Seminar beruht auf dem Buch von Smith und Nair [SN05], wobei diese Ausarbeitung, die in Kapitel 8 des Buches vorgestellten Konzepte, erlautert. Wir befassen uns mit dem Erscheinungsbild solcher Systeme, mit den Zustanden der unterliegenden Hard- und Software, und vor allem mit der Virtualisierung der Betriebsmittel. Dabei gehen wir auf die verschiedenen Typen von virtuellen Maschinen fur vollstandige Computersysteme ein. Unter anderem beschaftigen wir uns mit den Leistungseinbuen in solchen Systemen und wie man diese verringern kann. 1 Einleitung Ein Analogon zu virtuellen Maschinen fur vollstandige Computersysteme bildet ein Betriebssystem wie Linux oder Microsoft Windows, wie man es aus dem Alltag kennt. In diesen Betriebssystemen benutzt man scheinbar mehrere Programme gleichzeitig, was nicht der Fall ist. In Wirklichkeit werden jedem dieser scheinbar simultan laufenden Prozesse jeweils sehr kleine Zeitscheiben zugeteilt, in denen diese Prozesse abwechselnd ausgefuhrt werden, wie man es z.b. in [BC02] nachlesen kann. Ob dabei mehrere oder nur ein Benutzer an dem System arbeiten ist unerheblich, beides wird durch das Verfahren ermoglicht. Diesen Zeitmultiplexbetrieb konnte man also mit virtuellen Maschinen fur Prozesse vergleichen, eine fur jedes Programm der Benutzerebene. Eine virtuelle Maschine (VM) fur vollstandige Computersysteme fuhrt nicht nur mehrere Prozesse quasiparallel aus, sondern ganze Systeme. Dabei mussen fur jedes laufende Betriebssystem virtuelle Betriebsmittel (Ressourcen) zur Verfugung gestellt werden. Diese bestehen, wie man in den folgenden Kapiteln detaillierter sehen wird, aus: 2

4 Prozessor(en) Speicher Eingabe/Ausgabe-Geraten Die physikalisch vorhandenen Gerate mussen geteilt bzw. gemeinsam benutzt werden. Dazu wird ein Monitor Virtueller Maschinen (Virtual Machine Monitor, VMM) eingesetzt. Der Monitor Virtueller Maschinen ist eine Softwareschicht, die zwischen Hardware und dem virtualisierten (Betriebs-)system agiert. 1 Zunachst werden wir jedoch einige Begrie klaren: Wirt (host) das System, auf dem der VMM aufsetzt Gast (guest) das System, das in der virtuellen Maschine lauft virtuelle Ressourcen die Betriebsmittel, die das Gastsystem benutzt reale Ressourcen die tatsachlichen Betriebsmittel des Wirtes physikalische Ressourcen hier: analog zu den realen Ressourcen 2 Der Monitor Virtueller Maschinen verwaltet dabei die realen Betriebsmittel. In den nachsten Kapiteln folgt Genaueres uber die Stellen im Gesamtsystem, wo sich diese Softwareschicht einklinken kann. Der Monitor Virtueller Maschinen kann die virtuellen Betriebsmittel mit Hilfe mehrerer Methoden zur Verfugung stellen. Eine Gruppe der Methoden umfasst die Partitionierung und den Zeitmultiplexbetrieb, wobei der Monitor Virtueller Maschinen daruber entscheidet, welches physikalische Betriebsmittel den virtuellen Maschinen zugeteilt wird. Eine andere Gruppe umfasst die Emulation (exakte Nachbildung), die zur Anwendung kommt wenn es die physikalische Ressource nicht gibt. In diesem Dokument konzentrieren wir uns auf eine spezische Instruction Set Architecture (ISA), also die Schnittstelle zur Hardware, z.b. Intel IA-32 (x86) in Gast und Wirt. Wir beschranken uns auf Einprozessorsysteme und berucksichtigen keine Probleme des Mehrprozessorbetriebes, dazu siehe [Ste06]. 2 Schlusselkonzepte In diesem Kapitel wollen wir uns nun vor allem damit befassen, wie die unterliegende Hardware sich verhalt, wenn auf ihr virtuelle Maschinen ausgefuhrt werden. 1 Es gibt mehrere Typen von VMM, die einen benotigen ein zwischengelagertes Betriebssystem, die anderen nicht. Im Folgenden wird darauf noch eingegangen. 2 Achtung: hier sind reale und physikalische Betriebsmittel identisch, was aber nicht fur eine sogenannte gehostete/moderierte virtuelle Maschine gilt, in der der Wirt eine virtuelle Speicherverwaltung benutzt. (siehe Kapitel 3.2) 3

5 2.1 Erscheinungsbild Die physikalisch vorhandene Hardware eines Rechnersystems muss zwischen den einzelnen Gastsystemen aufgeteilt werden. Dies kann man entweder durch Software oder durch Replikation der Hardwareressourcen erreichen. Bei der Replikation unterscheidet man zwischen einem System mit N Benutzern und N Systemen fur 1 Benutzer. Bei ersterem kann man z.b. mittels eines Terminal-Controllers umschalten. Auf letzteres Szenario wollen wir uns o.b.d.a. konzentrieren. Man kann z.b. mittels einer speziellen Tastenkombination, auf der einzig vorhandenen Tastatur, zwischen den einzelnen Systemen umschalten. Meistens ist auch der Einsatz eines bestimmten Betriebssystems wichtiger als des anderen. So will der Linux-Administrator nicht standig zwischen Linux und Microsoft Windows umschalten. Wurde Microsoft Windows in einem Fenster laufen, ware das Ziel erreicht. 2.2 Zustande Fur eine Rechnerarchitektur ist sowohl der Maschinenzustand als auch die Art und Weise der Realisierung des Maschinenzustandes deniert. Der Maschinenzustand umfasst eine Denition aller Register, wie Datenregister, Adressregister, Stackregister, etc. Die Art und Weise der Realisierung wird in der Literatur als " architected state\ bezeichnet. Nicht alle Hardware- Ressourcen sind aquivalent. Es gibt eine Hierarchie, die sich von den Prozessorregistern zum sekundaren Speicher erstreckt. Es kann nicht jedes Betriebsmittel, das ein Gastsystem sieht, 1-zu-1 auf die eigentliche Hardware des Wirtsystems abgebildet werden. Nun existieren zwei Moglichkeiten: Als erste Moglichkeit kann man alle Betriebsmittel, z.b. die CPU- Register des Gastes in einem festen Hauptspeicherbereich des Wirtes ablegen. Als zweite Option bietet sich die native Ausfuhrung des Gaste-Kodes an. Betrachtet man ein Beispiel in dem ein CPU-Register in ein anderes kopiert werden soll, sieht man schnell, dass die native Ausfuhrung wesentlich ezienter ist. Bei der statischen Abbildung musste man erst einen Wert aus dem Speicher, in dem die Register des Gastes untergebracht sind, in ein " echtes\ Register kopieren und von dort wieder zuruck an eine andere Stelle des Hauptspeichers, also in ein anderes Register der virtuellen Maschine. Bei der nativen Ausfuhrung wird lediglich das durchgefuhrt, was auch auf einer realen Maschine passieren wurde: Ein Register wird in das andere kopiert, und man ist fertig. Abgesehen vom Herstellen/Speichern des Gesamtzustandes der virtuellen Maschine in die entsprechenden Hierarchieebenen des Wirtes ist diese Methode also wesentlich ezienter. Ob man schlussendlich diese Indirektion oder das Kopieren benutzt, hangt von der Haugkeit ab, in der der Fall eintritt, und ob der Gastezustand tatsachlich auf einer anderen Ebene im Wirt vorliegt oder nicht. 4

6 2.3 Kontrolle der Betriebsmittel Der Monitor Virtueller Maschinen muss stets die Kontrolle uber das System (die unterliegende Hardware und alle virtuellen Maschinen) behalten. Vor allem muss es einen Weg geben, wie der Monitor Virtueller Maschinen jederzeit die Betriebsmittel von einer virtuellen Maschine zuruckbekommen kann. Dies gewahrleistet, dass die Betriebsmittel anderen virtuellen Maschinen zur Verfugung gestellt werden konnen. Dieses Prinzip funktioniert, wie anfangs schon erwahnt, analog zum Zeitmultiplexbetrieb moderner Betriebssysteme. Dabei wechselt der Monitor Virtueller Maschinen zwischen den virtuellen Maschinen genauso wie ein Betriebssystem zwischen seinen Benutzerprozessen die Zeitslots verteilt. Fuhrt der Monitor Virtueller Maschinen eine virtuelle Maschine aus, initialisiert er den Intervall-Timer auf einen positiven Wert und lasst diesen gegen Null laufen. Hat dieser dann Null erreicht, erhalt die virtuelle Maschine einen Interrupt, der dann vom Monitor Virtueller Maschinen behandelt wird, und die Maschine wird schlafen gelegt. Somit wird eine ef- ziente und faire Ausfuhrung der virtuellen Maschinen garantiert. Die virtuellen Maschinen sehen hierbei nur einen virtuellen Timer, der ihnen vom Monitor Virtueller Maschinen zur Verfugung gestellt wird, und konnen den realen Timer weder schreiben noch lesen. Letzteres bedeutet, dass sich das System virtualisiert genauso verhalt, wie wenn es nativ ausgefuhrt wurde. Bei dem oben schon erwahnten Timer (Interrupt) handelt es sich um ein sogenanntes privilegiertes Betriebsmittel, das nicht fur Benutzerprozesse zuganglich ist. Aus der Sicht des gesamten Systems ist die virtuelle Maschine lediglich eine Benutzeranwendung. Privilegierte Betriebsmittel werden vom Monitor Virtueller Maschinen behandelt, und den virtuellen Maschinen wird ein virtualisiertes (emuliertes) privilegiertes Betriebsmittel angeboten, um die Kontrolle uber das System zu behalten. 2.4 Native und moderierte virtuelle Maschinen Der Monitor Virtueller Maschinen ist der zentrale Knotenpunkt fur die geteilten bzw. gemeinsam benutzten physikalischen Betriebsmittel. Dafur muss der Monitor Virtueller Maschinen mehr Privilegien haben als das Gastsystem. Der privilegierte Modus heisst auch Systemmodus und der unprivilegierte Modus wird Benutzermodus genannt. Wie man in der Abbildung 1 erkennen kann, gibt es drei Kategorien, in die man virtuelle Maschinen fur vollstandige Computersysteme unterteilen kann. Der grosste Unterschied ist zwischen nativen Systemen und den moderiert/gehosteten Systemen. Bei ersterem setzt der Monitor Virtueller Maschinen direkt auf der Hardware auf und lauft somit komplett im Systemmodus des Wirtes. Bei den moderierten Systemen liegt zwischen dem Monitor Virtueller Maschinen und der Hardware noch ein Wirt- Betriebssystem. Darunter gibt es Betriebssysteme in denen der Monitor Virtueller Maschinen ganzlich im Benutzermodus lauft (z.b. Usermode- 5

7 Linux), oft ndet man auch so genannte Dual-Modus-Systeme, bei denen der Monitor Virtueller Maschinen sich uber beide Modi erstreckt (z.b. VMware). Abbildung 1: Typen von virtuellen Maschinen fur vollstandige Computersysteme. Zu verinnerlichen gilt, dass (bei den moderierten Systemen) das virtualisierte Betriebssystem naturlich wieder einen Benutzer- und System- Modus enthalt. Aus Sicht des Gastbetriebssystems hat es den Anschein, als hatte es einen Benutzer- und einen Systemteil, aber das gehort zu der Illusion, die dem Gastsystem durch den Monitor Virtueller Maschinen gegeben wird. Zur Vollstandigkeit sei gesagt, dass es die moderierten (und Dual- Modus-) Systeme aus zwei Hauptgrunden gibt: Bequemlichkeit Vermutlich wurden die wenigsten Benutzer ihr System komplett loschen um den Monitor Virtueller Maschinen direkt auf die Hardware zu installieren. Implementierung Man kann die Geratetreiber des unterliegenden Wirt- Betriebssystems nutzen und muss nicht alle moglichen Treiber im Moni tor Virtueller Maschinen zur Verfugung stellen. Der Systemmodus des Monitors Virtueller Maschinen wird bei den Dual- Modus-Systemen meistens durch Kernerweiterungen (wie Geratetreiber) realisiert. 3 Virtualisierung der Betriebsmittel In den folgenden Unterkapiteln beschaftigen wir uns mit der Virtualisierung der Betriebsmittel: Prozessor, Speicher, Ein- und Ausgabe. Dabei wird jeweils auf die Probleme die sich bei der Virtualisierung ergeben und deren Losung eingegangen. 6

8 3.1 Prozessor Fur die Ausfuhrung der Instruktionen der Gastsoftware gibt es zwei grundlegend unterschiedliche Varianten: die Emulation und die direkte native Ausfuhrung. Zur Emulation gehort die Interpretation des Gastkodes und die Binarubersetzung. Beide Themen wurden in anderen Vortragen und Ausarbeitungen dieses Seminars behandelt [Erm06] [Gog06]. Die direkte native Ausfuhrung funktioniert nur, wenn die ISA des Gastsystems mit der ISA des Wirtsystems ubereinstimmt, ansonsten muss man Emulation betreiben. Ein zweites Kriterium ist, dass " gute\ ISAs einen Trap 3 auslosen wenn ein Befehl vorkommt, der emuliert werden muss, da das gesamte Gastsystem, aus der Sicht des Wirtes, im Benutzermodus lauft Instruktionstypen Die verschiedenen Instruktionstypen sind: privilegierte Instruktion Die privilegierte Instruktion ist so deniert, dass sie im Benutzermodus einen Trap auslost und im Systemmodus nicht. Ein Beispiel hierfur ist das Manipulieren des CPU-Timers. empndliche Instruktion Die empndlichen Instruktionen teilen sich auf in zwei Untertypen: die kontrollempndlichen und die verhaltensempndlichen Instruktionen. kontrollempndlich Eine kontrollempndliche Instruktion ist dadurch charakterisiert, dass die Konguration des Systems verandert wird, wenn sie zur Anwendung kommt, wie z.b. in IBM's System/370 die Manipulation des CPU-Timers durch den SPT-Befehl. verhaltensempndlich Eine verhaltensempndliche Instruktion zeichnet sich dadurch aus, dass ihr Verhalten im Systemmodus ein anderes ist als im Usermodus. Ein Beispiel hierfur ist der POPF- Befehl (IA-32). harmlose Instruktion Eine Instruktion die nicht empndlich ist, bezeichnet man als harmlose (innocuous) Instruktion. kritische Instruktion Empndliche, aber nicht privilegierte Instruktionen sind wichtig, und tragen daher einen eigenen Namen: kritische Instruktionen. Eine Ubersicht ndet man in der Abbildung Bedingungen zur Virtualisierung der ISA Popek und Goldberg haben Bedingungen zur Virtualisierung einer ISA aufgestellt. [PG74] Nach Popek und Goldberg gibt es drei Eigenschaften, die ein Monitor Virtueller Maschinen erfullen soll: 3 trap: synchrone Unterbrechung, Ruckkehr in den Systemmodus, Ubergabe der Kontrolle ans Betriebssystem/den Monitor Virtueller Maschinen 7

9 Abbildung 2: Typen von Prozessorinstruktionen. Aquivalenz Kontrolle der Betriebsmittel Ezienz Die Aquivalenz impliziert, dass jedes Programm/System, welches in einer virtuellen Maschine ausgefuhrt wird, sich genauso verhalt, als wurde es nativ ausgefuhrt. Weiterhin impliziert die Kontrolle der Betriebsmittel, dass keine Software, die in der virtuellen Umgebung ausgefuhrt wird, direkt etwas an den Betriebsmitteln des unterliegenden Systems verandern darf, sondern dafur den Monitor Virtueller Maschinen benutzt (wenn auch indirekt). Bei der dritten Bedingung, der Ezienz, handelt es sich nach allgemeinerer Auassung nur um eine optionale Eigenschaft. Ist diese auch noch erfullt, so spricht man von einem ezienten Monitor Virtueller Maschinen. Im Endeekt besagt ein Theorem von Popek und Goldberg, dass ein Monitor Virtueller Maschinen konstruiert werden kann, wenn die Menge der empndlichen Instruktionen eine Teilmenge der privilegierten Instruktionen sind, es also keine kritischen Instruktionen gibt, siehe die Abbildung Problematische Instruktionen und deren Behandlung Es existieren nur wenige ISAs, die ezient virtualisierbar sind. IA-32 zum Beispiel ist es nicht, weil es kritische Instruktionen enthalt. Allerdings konnen dann die schon erwahnten Methoden Interpretation und Binarubersetzung eingesetzt werden. [Erm06] Den Instruktionsstrom absuchen und die kritischen Instruktionen " icken\ nennt man Scanning-and-Patching. Scanning-and-Patching kann man einfach (inezient) oder komplizierter (ezienter) gestalten. Ein erster Ansatz besteht darin, dass vor kritischen Instruktionen ein Trap in den Monitor Virtueller Maschinen eingefugt wird, dieser seine Emulationstatigkei- 8

10 Abbildung 3: Inezient und ezient virtualisierbare ISA. ten wahrnimmt, und der originale Programmablauf nach der kritischen Instruktion wieder fortgesetzt wird. Normalerweise wird dies in Kodeblocken vorgenommen. Kommen in mehreren hintereinander folgenden Kodeblocken kritische Instruktionen vor, ist es sinnlos, jedes Mal aus dem Monitor Virtueller Maschinen zuruck in den Kode zu springen, um unmittelbar danach einen weiteren Trap zu generieren und dann wieder in den Monitor Virtueller Maschinen zuruckzukehren, zur Veranschaulichung siehe auch die Abbildung 4. Zur Verbesserung der Performance werden ganze Bereiche direkt im Monitor Virtueller Maschinen abgearbeitet, bis zu dem Punkt an dem eine Instruktion auftaucht, die man im Voraus nicht ersetzen kann, wie z.b. eine indirekte Verzweigung (Zieladresse in einem Register). Diese optimierte Vorgehensweise nennt man auch Code-Caching, dazu siehe auch die Abbildung Speicher Der Speicher einer virtuellen Maschine ist eine Illusion, die vom Monitor Virtueller Maschinen aufrecht erhalten wird. In dieser Hinsicht ist die virtuelle Maschine eine Verallgemeinerung einer virtuellen Speicherverwaltung, wie man sie auch aus modernen Betriebssystemen kennt. Diese virtuelle Speicherverwaltung wird dazu gebraucht, dem System mehr Speicher zur Verfugung stellen zu konnen als tatsachlich vorhanden ist, wobei der zusatzliche Speicher sich dann z.b. auf Hintergrundspeicher (Festplatte) bendet. Wird der Speicherhierarchie eine weitere logische Ebene hinzugefugt, erhalt man den Speicher der virtuellen Maschinen. Zu unterscheiden sind also folgende Speichertypen: virtueller Speicher des Gastes 9

11 Abbildung 4: Scanning-and-Patching in einem Virtuellen-Maschinen-System. realer Speicher des Gastes / virtueller Speicher des Wirtes physikalischer Speicher Wie man hier sieht, sind " real\ und " physikalisch\ keine aquivalenten Begrie mehr (anders als in den vorigen Kapiteln). Jede virtuelle Maschine besitzt eine virtuelle Speichertabelle. Die Speicherverwaltung des Gastes ubersetzt die virtuellen Speicheradressen in reale Adressen des Gastes, welches wiederum virtuelle Adressen im Wirtsystem sind. Diese werden danach vom Monitor Virtueller Maschinen in physikalische Adressen des Wirtsystems abbildet. Diese Abbildung der virtuellen auf reale Adressen geschieht mit Hilfe einer Seitentabelle und des Translation Look-aside Buer (TLB). Der TLB ist ein assoziativer Zwischenspeicher und dient grundsatzlich der Beschleunigung von Suchen in den Seitentabellen. Auf einigen Rechnerarchitekturen ist die Seitentabelle von der Hardware vorgegeben (englisch: " architected\), dann wird der TLB intern von der Hardware verwaltet und sein Verhalten kann nicht vom Benutzer beeinusst werden. Auf anderen Plattformen ist der TLB mittels ISA ansprechbar, die Seitentabellen mussen dort komplett in Software (Betriebssystem) implementiert werden. Im Folgenden gehen wir auf die Art und Weisen ein, wie man diese beiden Typen von Architekturen virtualisiert Seitentabellen und Seitenfehler Besitzt eine virtuelle Maschine eine eigene Seitentabelle, dann enthalt diese die Abbildung von physikalischem zu realem Speicher. Da man jedoch die vorher schon erwahnte zweistuge Speicheradressubersetzung vermeiden 10

12 Abbildung 5: Code-Caching und Emulation ganzer Bereiche. will, enthalt der Monitor Virtueller Maschinen eine Schattenseitentabelle (shadow page table). Diese Schattentabelle enthalt die direkte Abbildung zwischen virtuellem Speicher des Gastes und physikalischem Speicher des Wirtsystems. Die virtuellen Maschinen haben keinen Zugri auf den echten Zeiger auf die Seitentabelle (page table pointer) des Systems, sondern eine vom Monitor Virtueller Maschinen zur Verfugung gestellte virtualisierte Version. Der virtualisierte Zeiger zeigt auf die passende Schattentabelle des aktiven Gastsystems. Will das Gastsystem seine Seitentabelle (also in Wirklichkeit die Schattenseitentabelle) verandern, muss der Monitor Virtueller Maschinen nachtraglich die reale Seitentabelle des Wirtsystems in einen korrekten Zustand versetzen. Dabei muss man auf die Behandlung der eventuell auftretenden Seitenfehler achten. Der Speicher, wie er in der Seitentabelle des Gastes erscheint, muss schlielich nicht zwangslaug auf Wirtebene eingelagert sein. Um die vorher erwahnte Aquivalenzeigenschaft nicht zu verletzen, muss auf jeden Fall die folgende Regel gelten: Wenn es keine Abbildung einer Seite im Gastsystem gibt, darf es auch keine Abbildung in der Schattenseitentabelle geben. Verletzte man diese Regel, wurde es also Falle geben, in denen es im Gastsystem zum Seitenfehler kommt, aber nicht im Wirtsystem, was nicht erlaubt ist. Betrachtet man die drei ubrig gebliebenen Falle: Zur Veranschaulichung kann man die Wahrheitstabelle in der Tabelle 1 zu Rate ziehen, wobei G 11

13 fur Gast und W fur Wirt, 0 fur eine nicht vorhandene und 1 fur eine vorhandene Abbildung einer Speicherseite in Gast bzw. Wirt stehen. G W G ) W Tabelle 1: Wahrheitstabelle zur Aquivalenz bei Seitenfehlern. Wichtig sind also lediglich noch Zeilen 1 und 3 aus der Tabelle 1, in denen das Wirtsystem keine Zuordnung enthalt und somit ein Seitenfehler auftreten wird. Tritt dieser nun auf und ist die Seite in der Seitentabelle des Gastsystems vorhanden (Zeile 3), muss der Seitenfehler vor dem Gastsystem verborgen bleiben. Die Speicherseite wird in dem Fall vom Wirtsystem eingelagert und die Operationen des Gastsystems werden fortgesetzt. Anders sieht es bei dem Fall aus Zeile 1 der Tabelle aus: die Seite ist weder in Wirt noch in Gast eingelagert, also muss hier der Seitenfehler, der vom Monitor Virtueller Maschinen behandelt wird, an den Gast weitergereicht werden, welcher dann die notigen Schritte zur Einlagerung der Seite tun wird. Somit wird die Seite spater automatisch auf der Wirtseite zur Verfugung stehen Translation Look-aside Buer Der Monitor Virtueller Maschinen unterhalt auch bei virtualisierten TLBs den eigentlichen TLB und stellt den Gastsystemen virtuelle Versionen zur Verfugung. Es gibt eine einfache (ineziente) und komplexere (ezientere) Methode, den TLB zu verwalten. Die einfache Losung besteht darin, wahrend der Aktivierungsphase (Kontextwechsel) einer virtuellen Maschine, den TLB komplett neu zu schreiben. Somit hat jede virtuelle Maschine stets einen aktuellen und korrekten TLB vorliegen. Dieses Verfahren ist aber mit entsprechend viel Aufwand verbunden. Die elegantere Losung ist, sich die Address Space Identier (ASID)s zu Nutze zu machen. Die ASIDs sind dafur gedacht, auf einem System auf dem mehrere Prozesse laufen, jedem Prozess einen Teil des TLBs zuweisen zu konnen. Da eine virtuelle Maschine nichts anderes ist als ein Prozess fur das Wirtsystem, bietet sich das Ausnutzen dieser Funktionalitat des TLB an. Es muss beachtet werden, dass eine bestimmte ASID, die das Gastsystem benutzen will, schon in dem realen TLB vergeben sein kann, oder zwei verschiedene virtuelle Maschinen die gleichen ASIDs verwenden wollen. Der Monitor Virtueller Maschinen unterhalt eine ASID Abbildungstabelle 12

14 welche jeder virtuellen Maschine und deren ASIDs reale, eindeutige ASIDs zuweist, wie man auch in der Abbildung 6 sehen kann. Abbildung 6: Ausnutzen der Address Space Identiers eines TLBs. 3.3 Eingabe & Ausgabe Die Virtualisierung der Eingabe/Ausgabe gehort zu den anspruchsvolleren Teilen einer virtuellen Maschine fur vollstandige Systeme. Es existiert eine Vielzahl an Geraten unterschiedlicher Typen. Da es sich bei Virtualisierung um ein ahnliches Konzept wie Time-Sharing handelt, und das Problem des Time-Sharings in Kombination mit Eingabe/Ausgabe schon in vielen Betriebssystemen behandelt wurde, kann darauf aufgebaut werden. Betriebssysteme benutzen eine Abstraktionsschicht um mit der Vielzahl an Geraten umzugehen. Diese Abstraktionstechniken kann man an die Virtualisierung anpassen. Virtualisierung eines Gerates beinhaltet das Bereitstellen eines virtuellen Gerates und die Konvertierung der Befehle/Aktivitat an das eigentliche physikalische Gerat. Diese Konvertierungsaufgabe ubernimmt der Monitor Virtueller Maschinen Gerate Man kann Gerate grob in funf Kategorien, nach kleiner werdender Granularitat einteilen: dedizierte Gerate Ein dediziertes Gerat zeichnet sich dadurch aus, dass es jeweils fur einen langeren Zeitraum nur einer bestimmten virtuellen 13

15 Maschine zur Verfugung steht. Beispiele hierfur sind Tastatur und Bildschirm. partitionierte Gerate Bei einem partitionierten Gerat kann man typischerweise verschiedene Teile des Gerates den verschiedenen virtuellen Maschinen zur Verfugung stellen. Ein Beispiel hierfur ist eine Festplatte, deren erste Halfte der virtuellen Maschine 1 und deren zweiten Halfte Maschine 2 zur Verfugung gestellt wird. Dabei muss der Monitor Virtueller Maschinen Spur- und Sektorinformationen bei Eingabe/Ausgabe-Anfragen entsprechend umrechnen. gespulte Gerate Gespulte Gerate (spooled devices) sind typischerweise Drucker. Ein solches Gerat ist, vom Gastsystem aus gesehen, standig unter der Kontrolle des Prozesses, bis zur Beendigung seiner Aktivitat auf diesem Gerat. Die Puer, die hierzu notig sind (da z.b. ein Dokument in einem Zeitslot nicht fertig gedruckt werden muss oder kann), werden vom Monitor Virtueller Maschinen in einer zweistugen Konstruktion verwaltet, siehe auch die Abbildung 7. Man druckt in den Monitor Virtueller Maschinen, welcher dann tatsachlich auf den Drucker druckt, nach Strategien wie z.b. die Dokumente sortiert nach dem Zeitpunkt der Beendigung des Druckjobs. Abbildung 7: Die zweistuge Handhabung von gespulten Geraten. geteilte Gerate Gerate konnen auch mit kleiner Granularitat von verschiedenen virtuellen Maschinen quasiparallel benutzt werden, wobei 14

16 jede Maschine einen eigenen Zustand fur das (virtualisierte) Gerat mittels des Monitors Virtueller Maschinen besitzt. physikalisch inexistente Gerate Man kann den Gastsystemen Gerate, die es physikalisch gar nicht geben muss, zur Verfugung stellen. So kann es beispielsweise einen virtuellen Netzwerkadapter geben, der zur Kommunikation per Netzwerk (z.b. Ethernet + TCP/IP) zwischen den einzelnen virtuellen Maschinen benutzt werden kann, ohne dass das Wirtsystem einen Netzwerkadapter besitzt. Ein anderes Beispiel ware ein virtuelles CD-ROM, dessen Inhalt sich in Wirklichkeit in einer Datei (Image) auf dem Wirtsystem bendet. Aber auch Emulation hat ihre Grenzen. Besitzt das Wirtsystem beispielsweise keine Festplatte, wird es schwierig, den Gasten eine solche anzubieten, es sei denn man verfuge uber sehr viel Speicher Aktivitaten Die tatsachliche Virtualisierungsebene kann man an mehreren Stellen unterbringen. Im Folgenden betrachten wir die Vor- und Nachteile dieser Moglichkeiten. E/A Operations-Ebene Hierbei handelt es sich um fein granulierte Operationen, wie z.b. das Lesen eines Sektors einer Platte. Virtualisiert man auf dieser Ebene, wird es sehr inezient, da man vor allem bei den vielen kleinen Aktionen das Problem hat, zu erkennen was gerade wirklich passiert (z.b. " lese /tmp/xxx\). Geratetreiber-Ebene Virtualisierung auf dieser Ebene erscheint als naturlicher Ansatz. Das kommt daher, dass sie sich zwischen Betriebssystem und Geraten bendet. Somit wird ersichtlicher, was die ubergeordnete Aktion bewirken soll, und die entsprechenden Befehle konnen ezient auf die unterliegende Hardware ubertragen werden. Schwierig wird es, wenn man Virtualisierung fur beliebige Betriebssysteme vornehmen will, oder die Virtualisierungssoftware nativ betreiben will. Im ersten Fall brauchte man Treiber fur alle zu unterstutzenden Betriebssysteme. Im zweiten Falle auch noch Treiber fur alle zu unterstutzenden Gerate. Ausserdem muss man uber ausreichendes Wissen uber das Betriebssystem und seine Geratetreiberschnittstellen besitzen, aber genau zu dem hier gewunschten Zweck sind diese ja da. System-Call-Ebene Ein Abfangen der Befehle auf System-Call- oder auch Application Binary Interface (ABI)-Ebene ware zwar sehr ef- zient, hatte aber zur Folge, dass fur jedes Betriebssystem das man unterstutzen will jeder System Call von der Virtualisierungssoftware ersetzt werden musste. Zusatzlich musste man uber noch viel mehr Wissen uber die Interna der unterstutzten Betriebssysteme verfugen, 15

17 als bei der Virtualisierung auf Geratetreiber-Ebene (siehe oben). Auf System-Call-Ebene zu virtualisieren sollte man also vermeiden. Die Geratetreiber-Ebene hat somit die Praferenz uber die anderen Ebenen Moderierte virtuelle Maschinen Da wir bisher native virtuelle Maschinen betrachtet haben, wollen wir uns nun in einen kleinen Exkurs begeben und rausnden inwiefern moderiert/gehostete virtuelle Maschinen einfacher zu implementieren sind, insbesondere was die E/A und Dual-Modus-Systeme angeht, zu diesem Thema siehe auch das Kapitel 2.4. Zusatzlich zum Wirtbetriebssystem besteht ein moderiertes virtuelles Maschinensystem im dualen Modus aus: VMM-n (native) Dieser Teil des Monitors Virtueller Maschinen lauft direkt auf der unterliegenden Hardware. Von ihm werden Traps bearbeitet und wichtige Treiber, die nicht notwendigerweise im Wirtbetriebssystem enthalten sind, zur Verfugung gestellt. VMM-u (user) Dieser Teil des VMM lauft als Benutzerprozess im Wirtbetriebssystem. Er fuhrt in Vertretung des VMM-n Systemaufrufe durch, die, wie schon fruher erwahnt, von den (schon vorhandenen) Geratetreibern des Wirtbetriebssystems bearbeitet werden konnen. VMM-d (driver) Dieser Teil des VMM dient lediglich zur Kommunikation zwischen VMM-n und VMM-u. Der Dual-Modus-Typ von hat aber auch Nachteile. Erstens lauft der native Teil des Monitors Virtueller Maschinen (VMM-n) neben dem Wirtbetriebssystem im nativen Modus. Beide konnen sich also gegenseitig beeinussen und die Konsequenzen sind schwer vorhersehbar. Zweitens ist in diesem Fall die Betriebsmittelverwaltung komplett in der Kontrolle des Wirtbetriebssystems, der Monitor Virtueller Maschinen muss sich also mit diesem einigen und kann nicht immer alles so zuteilen wie er es gerade fur notig halt. 4 Leistungsprobleme Es gibt virtuelle Maschinen, um Benutzern eines einzigen Systems die Illusion zu geben, jeder sei im Vollbesitz aller Resourcen des Systems. Im Jahre 1979 zeigte MacKinnon, dass man in manchen Fallen nicht uber 21% der Leistung einer echten Maschine hinauskommt [Mac79]. Im Folgenden will man nun untersuchen wieso, und es werden Hardwareerweiterungen (Assists) vorgestellt, welche leistungssteigernd wirken. 16

18 4.1 Grunde der Leistungsverminderung Kontextwechsel Bevor eine virtuelle Maschine tatsachlich laufen darf, muss ihr Zustand initialisiert werden, d.h. der Program Counter angepasst, Register restauriert, Timer gesetzt werden etc. Zustandssicherung Kommt es zu einem Trap, geht die Kontrolle also an den Monitor Virtueller Maschinen uber, muss der Zustand der virtuellen Maschine gesichert werden. Emulation Wie schon in Kapitel 3.1 ausreichend behandelt, gibt es Instruktionen, die emuliert werden mussen. Ausserdem bietet es sich an, gleich ganze Bereiche zu emulieren, um Sprunge in den Monitor Virtueller Maschinen zu vermeiden. Das Leistungsverhalten der Emulation ganzer Bereiche bendet sich also zwischen einer (theoretischen) kompletten nativen Ausfuhrung und der Emulation jedes einzelnen Blocks. Interruptbehandlung Alle Interrupts mussen vom Monitor Virtueller Maschinen bearbeitet werden, auch wenn dieser diese womoglich schlussendlich nur an das Gastbetriebssystem weiterreicht. Ein Beispiel hatten wir bei der Seitenfehlerbehandlung in Kapitel Buchfuhrung Prozessorzeit lasst sich nicht mehr einfach entweder Benutzer oder System zuordnen, falls man diese zu Geschaftszwecken abrechnen wollte. Hier lauft ein komplettes Gastsystem im Benutzermodus und es kann keine pauschale Buchfuhrung der einzelnen laufenden virtuellen Maschinen im Systemmodus (Monitor Virtueller Maschinen) durchgefuhrt werden. Zeitdehnung Zeitabhangigkeiten sind generell ein Problem. Ginge ein Gastsystem davon aus, dass eine gewisse Aktion eine exakte Zeit in Anspruch nimmt, so muss diese Annahme in einer virtualisierten Umgebung nicht mehr zutreen. Beispielweise kann ein Speicherzugri einen (fur den Gast unsichtbaren) Seitenfehler produzieren, woraufhin Seiten eingelagert werden mussen, lokale und Schattenseitentabellen konsultiert werden mussen, etc. Einige Instruktionen dauern im virtualisierten Modus einfach langer als wenn eine native Ausfuhrung stattnden wurde. 4.2 Verbesserung der Leistung Eine Hardwareerweiterung zur Leistungssteigerung einer virtuellen Maschine heisst Assistent Virtueller Maschinen (VM assist). Ein Eekt einer solchen Erweiterung ist die Reduktion der Anzahl der Wechsel zwischen Gastsystem und dem Monitor Virtueller Maschinen. Assistenten zur Instruktionsemulation In dieser Kategorie handelt es sich um Erweiterungen der Hardware, die verhindern sollen, dass die virtuelle Maschine zu oft einen Trap auslost, also in den Monitor 17

19 Virtueller Maschinen wechseln muss, um einen Emulationsvorgang durchzufuhren. Diese Art von Assistent muss Wissen uber das virtuelle Maschinensystem besitzen. Assistenten des Monitors Virtueller Maschinen Hier geht es darum, die Leistung des Monitors Virtueller Maschinen zu erhohen. Dieses kann dadurch geschehen, dass im Falle eines Kontextwechsels zum Monitor Virtueller Maschinen Hardware eingesetzt wird, welche die Register und andere Zustandsinformationen sichert und spater wiederherstellt. Weiterhin kann man das Dekodieren der privilegierten Instruktionen von Software in Hardware verlagern. Ausserdem kann der virtuelle Intervall-Timer (siehe auch Kapitel 2.3) hardwaremassig verwaltet werden. In Software kann der Timer nur abgeschatzt werden, in Hardware kann man den virtuellen Timer genau dann dekrementieren wenn auch der echte Timer dekrementiert wird. Schlussendlich kann man dem Instruktionssatz neue Instruktionen hinzufugen, die das Leben in einer virtualisierten Welt einfacher machen. Leistungssteigerung des Gastsystems Das klassische Konzept der Virtualisierung geht davon aus, dass das Gastsystem nicht weiss, dass es gerade in einer virtualisierten Umgebung ausgefuhrt wird. Weiss der Gast nun allerdings, dass er virtualisiert wird, konnte er beispielsweise weniger privilegierte Instruktionen ausfuhren und somit die standigen Kontextwechsel vermeiden. Weiterhin konnte der Gast dem Monitor Virtueller Maschinen direkt mehr Informationen uber die auszufuhrende privilegierte Instruktion zukommen lassen, und somit die Verweildauer im Systemmodus verkurzen. Diese Vorgehensweise nennt sich Handeschutteln (handshaking). spezialisierte Systeme Weitergehend kann ein virtuelles Maschinen-System optimiert werden, wenn der Monitor Virtueller Maschinen Informationen uber das zu virtualisierende Gastsystem besitzt. Die folgenden Beispiele entstammen der IBM System/370 Architektur. [Gum83] Als erstes Beispiel kann der Speicher der virtuellen Maschine unter gewissen Voraussetzungen eins zu eins in den physikalischen Speicher abgebildet werden. Zweitens sind Schattentabellen eine nette Erndung, aber auch diese kann man umgehen, indem man der Hardware erlaubt die Seitentabellen des Gastsystems direkt zu manipulieren. Somit entsteht die Abbildung von virtuellen zu physikalischen Seiten direkt im Gastsystem. Die Idee Gastsysteme im Systemmodus laufen zu lassen wurde viele Wechsel in den Monitor Virtueller Maschinen und den dadurch entstehenden Overhead ersparen. Allerdings muss das System dann anderweitig gegen Missbrauch geschutzt werden. Fur den Fall, dass mehrere gleiche Gastbetriebssysteme auf einem Wirt gleichzeitig betrieben werden, konnten die Kodesegmente einmal 18

20 fur alle Gastsysteme zur Verfugung gestellt werden. Die beiden letzten Punkte enthalten oensichtlich ein Entgegenkommen zwischen beiden Welten. Einmal hat der Gast Informationen uber die unterliegende (virtualisierte) Architektur, das andere Mal hat das System spezische Informationen uber den Gast. Es handelt sich also um das alt bewahrte trade-o, je mehr Informationen man hat, desto mehr Ezienz kann man erzielen, aber mit hoherem Implementierungsaufwand. Literatur [BC02] Daniel P. Bovet and Marco Cesati. Understanding the LINUX KERNEL. O'Reilly & Associates, Inc, 1 edition, ISBN [Erm06] Evran Ermis. Moderne Hardware und Betriebssysteme: Virtuelle Maschinen in Hard- und Software, Seminarausarbeitung, Emulation und Binarubersetzung (Kap. 2), [Gog06] Robert Gogolok. Moderne Hardware und Betriebssysteme: Virtuelle Maschinen in Hard- und Software, Seminarausarbeitung, Virtuelle Maschinen fur Prozesse (Kap. 3), [Gum83] Peter H. Gum. System/370 extended architecture: Facilities for virtual machines. IBM Journal of Research and Development, 27(6):530{544, [Mac79] Richard A. MacKinnon. The changing virtual machine environment: Interfaces to real hardware, virtual hardware, and other virtual machines. IBM Systems Journal, 18(1):18{46, [PG74] Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable third generation architectures. 17(7):412{421, July [SN05] James E. Smith and Ravi Nair. Virtual Machines { Versatile Platforms for Systems and Processes. Morgan Kaufmann Publishers, 1 edition, June ISBN [Ste06] Andreas Steinel. Moderne Hardware und Betriebssysteme: Virtuelle Maschinen in Hard- und Software, Seminarausarbeitung, Virtuelle Maschinen und Multiprozessorsysteme (Kap. 9), Abbildungsverzeichnis 1 Typen von virtuellen Maschinen fur vollstandige Computersysteme Typen von Prozessorinstruktionen Inezient und ezient virtualisierbare ISA

21 4 Scanning-and-Patching in einem Virtuellen-Maschinen-System Code-Caching und Emulation ganzer Bereiche Ausnutzen der Address Space Identiers eines TLBs Die zweistuge Handhabung von gespulten Geraten Tabellenverzeichnis 1 Wahrheitstabelle zur Aquivalenz bei Seitenfehlern Listings 20

22 Index Aquivalenz, 8 partitionierte Gerate, 14 Partitionierung, 3 Address Space Identier (ASID), 12 physikalisch inexistente Gerate, 15 Application Binary Interface (ABI), 15 privilegierte Instruktion, 7 ASID Abbildungstabelle, 12 privilegierte Modus, 5 Assistent Virtueller Maschinen (VM assist), 17privilegiertes Betriebsmittel, 5 Benutzermodus, 5 Betriebsmittel (Ressourcen), 2 Betriebsmittelverwaltung, 16 Betriebssystem, 2 Binarubersetzung, 8 Buchfuhrung, 17 Code-Caching, 9 dedizierte Gerate, 13 Dual-Modus, 6, 16 Ezienz, 8 empndliche Instruktion, 7 Emulation, 3, 7, 17 Geratetreiberschnittstellen, 15 gespulte Gerate, 14 geteilte Gerate, 14 Granularitat, 14 Handeschutteln (handshaking), 18 harmlose Instruktion, 7 Instruction Set Architecture (ISA), 3 Interpretation, 8 Interruptbehandlung, 17 Intervall-Timer, 5 Kontextwechsel, 12, 17 Kontrolle der Betriebsmittel, 8 kontrollempndlich, 7 kritische Instruktion, 7 moderiert/gehostet, 5, 16 Monitor Virtueller Maschinen (Virtual Machine Monitor, VMM), 3 nativ, 5 native Ausfuhrung, 4, 7 21 Scanning-and-Patching, 8 Schattenseitentabelle (shadow page table), 11 Seitentabelle, 10 System Call, 15 Systemmodus, 5 Translation Look-aside Buer (TLB), 10 Trap, 7, 8, 16, 17 unprivilegierte Modus, 5 verhaltensempndlich, 7 virtuelle Maschine (VM), 2 virtuelle Speichertabelle, 10 VMM-d, 16 VMM-n, 16 VMM-u, 16 Zeiger auf die Seitentabelle (page table pointer), 11 Zeitdehnung, 17 Zeitmultiplexbetrieb, 2, 3, 5 Zustandssicherung, 17