MMU Virtualisierung. Information System Engineering Seminar Thomas Schaefer,

Transkript

1 MMU Virtualisierung Information System Engineering Seminar 2012 Thomas Schaefer, Abstract. Virtualisierung ist ein wichtiges Thema in der Informationstechnik. Mit ihr werden beispielsweise Mechanismen implementiert, um die Unternehmens-IT kostenreduziert, portierbar und wart-bar zu betreiben. Aber auch im mobilen Segment werden die Vorteile immer größer. Die vorliegende Ausarbeitung gibt einen Überblick über aktuelle Methoden zur Virtualisierung der Memory Management Unit, des Speichermanagements und des Translation Lookaside Buffers (TLB). Nach der Einleitung, die die Funktion einer MMU erklärt, werden die Mechanismen der Hersteller von Virtualisierungssoftware vorgestellt um im Kapitel 6 auf den TLB einzugehen. Keywords: Memory Management Unit, MMU, Virtualisierung, ESX/ESXi, VMWare, TLB Virtualisierung, SMMU, ARM, Xen, Itanium 1 Einleitung Virtualisierung ist ein Thema, welches die Informationstechnik schon seit den 60er Jahren beschäftigt. Damals schon hat man nach Ansätzen gesucht, die zugrundeliegende Hardware möglichst vielen verschiedenen Benutzern zugänglich zu machen und dabei zu gewährleisten, dass jeder sein eigenes, abgeschottetes System hat. Dank immenser Vorteile (z.b. Kostenreduzierung, Portierbarkeit, Wartbarkeit) hat sich die Virtualisierung bereits in vielen Bereichen der IT durchgesetzt (vgl. [4] S. 2-3). Diese Ausarbeitung beschäftigt sich mit verschiedenen Techniken zur Virtualisierung des Speichermanagements, insbesondere der Memory Management Unit, und des Translation Lookaside Buffers. Es wird gezeigt, welche Methoden die Hersteller von Virtualisierungs-Software einsetzen um den physikalischen Speicher in einer virtualisierten Umgebung verfügbar zu machen. 2 Memory Management Unit Um den Aufbau einer Memory Management Unit zu erklären, beginnt man am besten damit ihre Aufgabe zu beschreiben; Das Übersetzen von virtuellen (oder logischen) in physikalische Adressen: Ein normaler 32 Bit PC mit x86 Architektur kann einen maximalen Adressbereich von 2 32 Byte (rund 4 GByte) adressieren. Allerdings verwendet man hierbei ein Verfahren, welches sich Paging nennt. Der Grund dafür ist adfa, p. 1, Springer-Verlag Berlin Heidelberg 2011

2 einfach. Vorrangig wird es benutzt um einem Betriebssystem bzw. seinen Programmen die Möglichkeit zu bieten die vollen 4 GByte Adressraum auszunutzen, auch wenn gar nicht so viel Hauptspeicher vorhanden ist. Hierbei wird ein virtueller Adressraum gebildet der aus 2 20 ( ) Pages zu je 2 12 (4 KByte) besteht (vgl. [1]). Pages (Seiten) sind zusammenhängende Blöcke von Speicheradressen. Sie werden benötigt, weil die Übersetzung von einzelnen Adressen nicht schnell genug von statten gehen würde (vgl. [2], S. 1). Das Pendant auf Seite der physikalischen Adressen sind die Frames (Rahmen). Um zu wissen wo und in welchem physikalischen Speicher sich die virtuelle Adresse befindet, wird für jede Page ein Eintrag im Page Table [(später Virtual Hashed Page Table, VHPT)] gemacht. Durch die MMU (Memory Management Unit) des Prozessors und mit Hilfe der Page Table werden dann die physikalischen Adressen berechnet. (vgl. [1]) Die MMU dient also dazu, zu den virtuellen Adressen, die vom Betriebssystem (OS) benutzt werden, die passenden physikalischen Adressen zu finden. Der physikalische Adressraum kann sich dabei sowohl im Arbeitsspeicher oder auf der Festplatte (beispielsweise wenn Seiten aus dem Arbeitsspeicher ausgelagert werden müssen) des Computers befinden. Fig. 1. Übersetzung von Seiten zu Rahmen Der vorrangige Grund für die Bildung des virtuellen Adressraumes ist der, dass Anwendungen zusammenhängenden Speicher benötigen um korrekt zu funktionieren (beispielsweise um Teile eines Videos zwischen zu speichern). Da dies in der Regel aber nicht möglich ist (Fragmentierung), bildet man den physikalischen Speicher auf einen virtuellen Adressraum ab. Das hat den Vorteil, dass man beliebige Blöcke an zusammenhängenden Speicher erzeugen und sie dem Betriebssystem zur Verfügung stellen kann. 2.1 MMU virtualisiert Bei der Virtualisierung einer MMU wird ein Hypervisor (auch Virtual Machine Manager (VMM) genannt) eingesetzt. Er bildet eine Schnittstelle zwischen den einzelnen

3 virtuellen Maschinen (VM) und der physikalischen Hardware des Hosts. Da das Betriebssystem einer VM normalerweise nicht weiß, dass es virtualisiert wird, erwartet es, wie ein normales Betriebssystem, einen physikalischen Adressraum der bei 0 beginnt. Weil in einer Virtualisierungsumgebung üblicherweise mehrere VMs existieren, müssen also auch mehrere, null-beginnende Adressräume, vom Hypervisor bereitgestellt werden. Damit das funktioniert wird zwischen der Übersetzung von virtuellen in physikalische Adressen eine weitere Adress-Art eingeschoben. Diese Adressart nennen wir im Folgenden Intermediate Physical Address (IPA) (vgl. [3], S. 2). Das Mapping übernimmt hierbei ebenfalls der Hypervisor. Er stellt also jeder VM einen IPA- Adressraum zur Verfügung und übersetzt diese Adressen in physikalische Adressen (vgl. [4], S. 7). Fig. 2. Herkömmliche Architektur und Architektur Hypervisor (Quelle: [4], S. 7) Zusammengefasst bedeutet das, dass in herkömmlichen Systemen die virtuellen Adressen von den Anwendungen zum Betriebssystem geschickt werden, welches sie an den MMU der CPU weiterleitet um sie in physikalische Adressen zu übersetzen. In einer virtualisierten Umgebung müssen mehrere Betriebssysteme (VMs) ihre virtuellen Adressen der Anwendungen übersetzen lassen. Also schicken sie ihre Adressen an den Hypervisor, der sie in physikalische Adressen umwandelt. Hinweis: Da alle Hersteller unterschiedliche Bezeichnungen für die verschiedenen Adress-Arten benutzen, werden im Folgenden ausschließlich die oben erwähnten Bezeichnungen von ARM verwendet (vgl. Fig. 1.): VA - virtuelle Adresse IPA - Intermediate Physical Address, Adressart zwischen der virtuellen Maschine und dem Hypervisor PA - physikalische Adresse vom Host-System 3 System Memory Management Unit Bei der in 2.1 beschriebenen Architektur, muss der Hypervisor für jedes Gast-Betriebssystem eine eigene Seitentabelle (Page-Table) verwalten. Dies kann einen hohen Overhead und somit zu Performance-Einbußen zur Folge haben - denn die Einführung

4 einer dritten Adressart (IPA) hat unter Umständen enorme Konsequenzen darauf, wie andere Komponenten in einem System arbeiten. Es ist nämlich durchaus möglich, dass neben der CPU auch andere Systembestandteile eine MMU verbaut haben bzw. die Funktionen einer MMU benötigen: So besteht zum Beispiel eine typische Plattform wie NVIDIAs Tegra 2, Texas Instruments OMAP4 oder ST-Ericssons U8500 aus einem Multi-Core ARM Prozessor mit je einer MMU pro Kern, einer OpenGL ES 2 Grafikeinheit (GPU) mit eigener MMU, einen Prozessor für digitale Signale, einem Image Signal Prozessor (ISP), einem Energie-Manager (PM) Controller und einen Direct Memory Access Controller (DMAC) (vgl. [4] S. 8). Neben dem Overhead bei der Übersetzung gibt es keinen Weg, sodass alle Komponenten sicher auf den physikalischen Adressraum zugreifen, ohne sich dabei in die Quere zu kommen (Speicher-Korrumpierung). (vgl. [4], S.8) Um diese Probleme zu beheben hat ARM die System-MMU entwickelt. Sie dient dazu die Vorteile eines virtuellen Adressraumes auch auf andere Komponenten zu übertragen (vgl. [4], S. 7) und kann als Hardware-Baustein vor jede Komponente verbaut werden, welche direkten Speicherzugriff benötigt. (vgl. [4], S.9) Fig. 3. Orte an denen die SMMU platziert werden kann (Quelle: [4], S.9) Die SMMU kann sowohl für VA-zu-IPA-Übersetzungen (Phase 1) als auch für IPAzu-PA-Übersetzungen (Phase 2) eingesetzt werden. Es ist dem System-Designer überlassen, ob er die Phase 1 oder die Phase 2 implementiert. Beispielsweise kann eine SMMU vor eine Komponente verbaut werden, die noch keine eigene MMU besitzt um

5 Speicherfragmentierung zu umgehen, oder sie kann vor eine schon existierende MMU verbaut werden, damit diese Komponente vom Hypervisor überwacht wird (vgl. ebd.). Phase 1: VA zu IPA. Die erste Phase dient dazu das (Gast-)Betriebssystem zu unterstützen es können Funktionen in Hardware abgebildet werden, die normalerweise einen Software-Workaround erfordern würden. Benötigen die oben erwähnten Komponenten beispielsweise einen zusammenhängenden Speicher, um große Datenmengen direkt hintereinander abzulegen, käme man wieder zum Problem der Speicherfragmentierung. Für gewöhnlich würde man die benötigte Menge dann einfach von Beginn an (Systemstart) für die Komponenten reservieren. Da der Speicher aber nur zur Laufzeit benötigt wird, würde man ihn für die restliche Zeit brach liegen lassen. Deswegen bildet die SMMU einen quasi-virtuellen Adressraum ab, in dem große Blöcke direkt hintereinander adressiert werden können. Die SMMU übernimmt dann die Aufgabe des Mappings (vgl. [4], S. 10). Fig. 4. SMMU Phase 1 (Quelle: vgl. [4], S. 10) Phase 2: IPA zu VA. Bei der Phase 2 wird der Hypervisor unterstützt. Sie macht es überflüssig, dass der Hypervisor alle Seiten-Tabellen der VMs in Software abbilden muss. Die Verwaltung der Adress-Beziehungen wird hierbei quasi vom Hypervisor an eine SMMU ausgelagert. Ferner bietet das den Vorteil, dass die VMs jetzt direkten Zugriff (über die SMMU) auf die Hardware-Komponenten haben und der Hypervisor entlastet wird. Gleichzeitig kann verhindert werden, dass verschiedene VMs parallel einen Speicherbereich verändern und ihn somit korrumpieren (vgl. [4], S. 11).

6 Fig. 5. SMMU Phase 2 (Quelle: vgl. [4], S. 11) 4 Speichervirtualisierung beim VMWare ESX-Server Dadurch, dass in einer virtualisierten Umgebung potenziell mehr virtueller Speicher an die VMs verteilt wird, als Physikalischer vorhanden ist, kann es vorkommen, dass der Hypervisor Speicher von VMs zurückfordern muss, um andere, wichtigere VMs wieder mit Speicher versorgen zu können (vgl. [3], S. 2). Zu diesem Zweck hat VMWare für ihrem ESX-Server das Ballooning entwickelt. Eine weitere Möglichkeit Speicher optimal auszunutzen stellt das Memory Sharing dar. Beide Verfahren werden im Folgenden näher beleuchtet. 4.1 Ballooning Beim Ballooning handelt es sich um die Ausnutzung der (Gast-)Betriebssysteminternen Algorithmen zur Speicherverwaltung. Dazu wird [...] wird ein Pseudo- Balloon-Treiber in das OS installiert, welcher über einen privaten Kanal mit dem Hypervisor kommuniziert (vgl. [3], S. 3). Bei diesem Verfahren wird die Arbeitsspeicherbelastung auf dem Gastbetriebssystem erhöht oder verringert, wodurch der Gast zur Verwendung seiner eigenen, nativen Arbeitsspeicherverwaltungs-Algorithmen veranlasst wird. Wenn der Arbeitsspeicher knapp ist, wird durch das Gastbetriebssystem festgelegt, welche Seiten abgerufen werden sollen, und die Seiten werden ggf. auf der eigenen virtuellen Festplatte ausgelagert (vgl. [5], S. 35). Dabei entscheidet das Gastbetriebssystem selbstständig welche Seiten wieder freigegeben werden können (z.b. diejenige mit der niedrigsten Priorität). Der Balloon-Treiber teilt dem Hypervisor jede physikalische Adresse (IPA) mit, die vom Gastbetriebssystem freigeben wurde, damit dieser die entsprechende physikalische Seite (PA) ebenfalls freigeben kann.

7 Wird der Balloon vom Hypervisor wieder verkleinert, sinkt die Arbeitsspeicherbelastung und das Gastbetriebssystem kann die ausgelagerten Seiten wieder in den Arbeitsspeicher einlagern (vgl. [3], S. 3). Fig. 6. Ballooning: Auslagern und Einlagern von Seiten (Quelle: [3], S.3) 4.2 Memory Sharing Durch die Konsolidierung von Servern bei der Virtualisierung, entstehen viele Möglichkeiten um redundante Inhalte auf nur eine Instanz zu reduzieren. Beispielsweise kann es sein, dass mehrere VMs das gleiche Betriebssystem oder die gleichen Anwendungen ausführen (vgl. [3], S. 4). Es wäre Ressourcenverschwendung, wenn diese mehrmals redundant im Speicher abgelegt würden. Beim ESX-Server sind Mechanismen implementiert, die die Arbeitsspeicherbelastung durch Memory-Sharing (insb. Transparent Page Sharing und Content-based Page Sharing ) reduzieren sollen. Transparent Page Sharing. Das Transparent Page Sharing (TPS) sucht nach redundant genutzten Seiten in VMs. Wenn eine doppelte Seite gefunden wurde, sorgt der Hypervisor dafür, dass alle Adressen der VM (IPA), auf ein einzelne Instanz im physikalischen Adressraum des Hosts (PA) verweisen. Diese einzelne Seite wird dann mit einem Copy-on-write -Flag (COW-Flag) belegt, was bedeutet, dass beim Schreiben in die Seite eine private Kopie angelegt wird um Seitenfehler zu vermeiden. Bei diesem Verfahren braucht der Hypervisor Informationen vom Gast-OS um redundante Seiten zu finden. Das führt dazu, dass Modifikationen am Betriebssystem der VM durchgeführt werden müssen (vgl. [3], S. 4-5).

8 Content-Based Page Sharing. Da Änderungen am Gast-OS nicht immer durchführbar sind, wurde das "Content-Based Page Sharing" entwickelt. Hierbei betrachtet der Hypervisor den Inhalt jeder Seite im Speicher und identifiziert darüber doppeltes Vorkommen. Inhaltlich redundante Seiten können problemlos mit anderen VMs geteilt werden, weil es egal ist, auf welche Art und Weise sie genutzt werden bzw. welche VM sie erstellt hat. Da ein naives Inhaltsvergleichen einen hohen Aufwand (Aufwand von O(n 2 )) bedeuten würde, wird mit einem Ansatz auf Basis einer Hash-Tabelle gearbeitet: Es wird eine Tabelle mit Hash-Werten, die den Inhalt einer Seite repräsentieren, angelegt. Dort werden alle Seiten hinterlegt. Wird nun eine neue Seite angelegt, erstellt der Hypervisor einen Hash-Wert für sie und vergleicht ihn mit den Einträgen aus der Tabelle. Wird keine Übereinstimmung gefunden, wird der Hash in die Tabelle geschrieben. Sollte die Seite allerdings schon vorhanden sein, wird eine vollständige Inhaltsprüfung des Seiteninhalts durchgeführt um eine 100%-ige Übereinstimmung zu sicher zu stellen (vgl. [3], S. 5). Dieses Vorgehen hat den Vorteil, dass beim Eintragen in die Tabelle nur ein einzelner Eintrag mit den anderen verglichen werden muss. Auch das Content-Based Page Sharing setzt das COW-Flag für neu eingelagerte Seiten. Was allerdings normalerweise dazu führt, dass jede Seite in der Tabelle dieses Flag gesetzt hat. Das bedeutet, dass bei jedem Schreibvorgang in die Seite automatisch eine private Kopie angelegt wird, obwohl dies unter Umständen gar nicht nötig ist. Deshalb wird für Seiten, die noch nicht mit anderen VMs geteilt worden sind, ein spezielles Hint-Flag vergeben. Dieses zeigt an, dass der Eintrag vor dem Hash-Vergleich erneut ge-hasht werden muss, um sicher zu sein, dass sich die Seite in der Zwischenzeit nicht geändert hat. Sollte sich der Eintrag geändert haben, wird der Inhalt neu in die Tabelle eingetragen. Ansonsten wird Page-Sharing durchgeführt und erst dann das COW-Flag gesetzt (vgl. ebd.). 5 Leerlaufbelastung für Arbeitsspeicher virtueller Maschinen Es kann sein, dass eine virtuelle Maschine viel Arbeitsspeicher im Leerlauf (Idle- Speicher) hortet, obwohl sie in gar nicht aktiv braucht. Das kann darin resultieren, dass die eine VM zu viel Speicher besitzt, während eine andere VM diesen Speicher dringend gebrauchen könnte. Deswegen wird beim ESX-Server der Idle-Speicher mit Kosten belegt: Wenn eine virtuelle Maschine nicht den gesamten ihr derzeit zugeteilten Arbeitsspeicher aktiv nutzt, belastet ESX/ESXi den im Leerlauf befindlichen Arbeitsspeicher mehr als den genutzten. Dadurch wird verhindert, dass Arbeitsspeicher im Leerlauf durch die virtuellen Maschinen angehäuft wird (vgl. [5], S. 35). Die Idee dahinter ist also die VM dafür zu bestrafen, dass sie unnötig viel Idle-Speicher besitzt. Das funktioniert darüber, dass das Gast-OS die Speicherbelastung niedrig halten möchte (siehe Ballooning) und somit automatisch weniger Idle-Speicher veranschlagt. Für die Berechnung der aktuell veranschlagten Belastung wird das shares-per-page - Verhältnis errechnet. Dazu betrachtet man das Verhältnis der geteilten Seiten zu den

9 zugewiesenen Seiten, den Anteil der aktiven Seiten und die erwähnten Idle-Speicher- Kosten ( memory-taxes ) (vgl. [3], S. 8-9). Wobei sich die Kosten über den Wert T ermitteln, welcher eine Benutzereinstellung des ESX-Servers repräsentiert. Standardmäßig ist T mit 0.75 initialisiert (vgl. [3] S. 9). Das folgende Diagramm zeigt das Verhalten zweier VMs bei einer Einstellung von T = 0 und der Standardeinstellung T = Während sich VM1 im Idle befindet, führt VM2 einen arbeitsintensiven Prozess aus. Bis 31s haben beide jeweils knapp 180 MB RAM zugewiesen. Nachdem T dann auf den Wert 0.75 wechselt (>31s) sieht man deutlich, wie Arbeitsspeicher von VM1 an VM2 übertragen wird (vgl. ebd.). Fig. 7. Arbeitsspeicherbelastung von zwei virtuellen Maschinen (Quelle: [3], S. 9) Durch diese Belastung werden die virtuellen Maschinen auf wirksame Weise höher für Arbeitsspeicher im Leerlauf als für aktiv genutzten Arbeitsspeicher belastet. Eine Belastungs-Rate von 0 Prozent definiert eine Zuteilungsrichtlinie, die Working Sets [(teilbare Seiten)] ignoriert und Arbeitsspeicher strikt nach Anteilen zuteilt. Über die Zuteilungsrichtlinie bei einer hohen Belastungsrate lässt sich Arbeitsspeicher im Leerlauf, der unproduktiverweise durch virtuelle Maschinen angesammelt wird, an anderer Stelle neu zuteilen (vgl. [5], S. 110). Mit dieser Methode ist wirksam sichergestellt, dass nie zu viel Idle-Speicher angehäuft wird.

10 5.1 Vorhersage von Arbeitsspeicherbelastung Damit das in 5 vorgestellte Verfahren effizient ist, muss man den Anteil an nicht gebrauchten Speicher in einer VM vorhersagen können um schnell auf Änderungen in der Speicherbelasung reagieren zu können. Denn ganz ohne Idle-Speicher kommt ein Gast-OS auch nicht aus. Dazu wird beim ESX-Server ein statistisches Verfahren eingesetzt. Der Hypervisor selektiert zufällig eine Anzahl von Seiten. Anhand verschiedener Indikatoren werden die Zugriffe auf diese Seiten über einen gewissen Zeitraum überwacht. D.h. es wird überprüft wie oft die Seiten, in einer gewissen Periode, vom Gastbetriebssystem in Gebrauch war. Am Ende jeder Periode kann man Aussagen darüber treffen, wie viel Speicher aktiv von der VM gebraucht wird (Aktiver Speicher = Anzahl der Seitenzugriffe / Anzahl der zu überwachenden Seiten). Als Kompromiss zwischen Genauigkeit und Effizienz überwacht der ESX-Server standardmäßig 100 zufällige Seiten für eine 30-sekündige Periode. Man kann diese beiden Parameter justieren um entweder eine höhere Genauigkeit oder eine höhere Effizienz zu erhalten. Damit lassen sich unterschiedliche Auswertungen erzeugen: Zum einen kann man eine mit wenigen Seiten und einem großen Zeitraum (hier Kurve 1: genauer) und zum anderen eine mit vielen Seiten über einen kurzen Zeitraum (hier Kurve 2: effizienter) erzeugen. Das führt dazu, dass man einerseits eine Bahnkurve erhält, die sich langsam ändert und andererseits eine, die sich schnell ändert. Diese beiden Kurven werden bei der Berechnung des aktuellen Speicherverbrauchs genutzt. Zusätzlich zu diesen Berechnungskurven überwacht der ESX-Server, über Funktionen des Gastbetriebssystems, noch den aktuell tatsächlichen Speicherverbrauch (vgl. [3], S. 9). Aus diesen drei Werten - 1. Kurve (langsam ändernd), 2. Kurve (schnell ändernd), tatsächlicher Wert - wird anschließend für ein Intervall das Maximum ausgewählt um eine Vorhersage zu treffen (das Maximum, damit auf jeden Fall immer genug Speicher reserviert). Das hat zur Folge, dass die Vorhersage bei ansteigendem Speicherverbrauch ebenfalls rasch ansteigt (2. Kurve, steigt schnell, ist deswegen schnell der Maximalwert), aber bei nachlassendem Verbrauch nur langsam zurück geht (1. Kurve, reagiert langsamer auf Änderungen, bleibt deswegen länger der Maximalwert) (vgl. [3], S. 9).

11 Fig. 8. Sampling von Speicherbelastung (Quelle: [3] S.9) Das oben dargestellte Diagramm zeigt die Vorhersage von Arbeitsspeicherbelastung. Man sieht deutlich, dass sich die Vorhersage zunächst auf die schnell ändernde Kurve stützt (8s-18s) und dann, bei einem Abfall, zur Langsameren wechselt (18s-22s). Mit dieser Methode kann man also sehr schnell Arbeitsspeicher verfügbar machen (z.b. für den Start von Anwendungen) und muss ihn, bei Rückgang der Belastung, nur langsam wieder frei geben. 6 Virtualisierung des Translation Lookaside Buffers Ein wichtiger Helfer der MMU ist der Translation Lookaside Buffer (TLB). Er dient als schneller Zwischenspeicher bei der Übersetzung von Adressen. Um diesen zeitintensiven Prozess (üblicherweise drei Arbeitsschritte) zu beschleunigen, werden oft gebrauchte Adressen im TLB gepuffert um sie bei erneutem Aufruf direkt von dort auszulesen (nur ein Arbeitsschritt nötig). Der TLB-Speicher ist durch seinen Aufbau (Assoziativspeicher) sehr teuer, und kann deswegen normalerweise nicht mehr als 1024 Einträge aufnehmen (vgl. [6], [10]). Weil der TLB direkten Einfluss auf die Leistung der MMU hat, ist er auch bei der Virtualisierung ein wichtiges Thema, weswegen er im folgenden Kapitel gesondert betrachtet wird.

12 6.1 TLB-Aufbau in der Itanium Architektur Um den TLB zu virtualisieren, muss man zunächst auf seinen Aufbau eingehen. Dazu betrachten wir die Intel Itanium Architektur. Dort teilt sich der TLB in einen Data-TLB (DTLB) und einen Instruction-TLB (ITLB), welche sicher wiederrum in Translation-Register (TR) und Translation-Cache (TC) teilen. Die TR werden ausschließlich für kritische Aufgaben genutzt (z.b. Zugriff von Kernel), die auf keinen Fall einen Page-Fault verursachen dürfen. Die TCs wiederrum können für alle Arten von Adressen genutzt werden (vgl. [7], S. 2). Fig. 9. MMU mit TLB Da der TLB normalerweise nur sehr begrenzt ist, wird ihm in der Itanium Architektur eine Virtual Hashed Page Table (VHPT) zur Seite gestellt um weitere Einträge zwischen zu speichern. Falls die MMU die gesuchte Adresse nicht im TLB findet, kann sie einen Hardware-Walker damit beauftragen die Adresse in der VHPT zu suchen. Sollte sie dort auffindbar sein, wird sie für zukünftige Zugriffe im TLB abgelegt (vgl. [7], S. 4-5). Da der Walker in Hardware abgebildet ist, ist die Suche sehr performant: Eine Messung hat ergeben, dass die Füllung des TLBs ohne Walker 160 CPU-Zyklen benötigt mit ihm sind es gerade mal 45 (vgl. ebd.). 6.2 TLB Virtualisierung mit Xen IA-64 und VT-i Xen kennt sowohl die Paravirtualisierung (Xen/IA-64) als auch die Full-Virtualisierung (Xen/VT-i). Bei der Paravirtualisierung verfolgt Xen einen single-tlb -Ansatz. Das bedeutet, dass der Hypervisor für eine virtuelle Maschine die kleinste mögliche Anzahl an TLBs zu Verfügung stellt. Für die Itanium-Architektur ist das ein einzelner TLB mit je einem ITLB und einem DTLB, welche jeweils acht TRs und je einen TC haben. Das hat den Vorteil, dass die Implementierung dieses Ansatzes recht einfach ist. Ferner kann es in manchen Fällen vorkommen, dass das OS den ptc.e -Befehl aus-

13 führt um den gesamten TLB zu leeren. Das bedeutet auch, dass alle TCs gelöscht werden müssen. Wenn man sicher stellt, dass es nur je einen (für ITLB und DTLB) gibt, verkürzt sich die Ausführzeit des Befehls enorm. Da es aber nicht immer möglich ist eine Paravirtualisierung durchzuführen (nicht alle Hersteller erlauben die Modifizierung ihres OS) muss auch die Full-Virtualisierung berücksichtigt werden. Aus diversen Gründen (Page-Faults durch fehlende Kommunikation mit dem Hypervisor etc.), muss hier ein anderer Ansatz gewählt werden um den TLB zu virtualisieren (vgl. [7], S. 2-5). Bei der Full-Virtualsierung wird für jede virtuelle Maschine ein virtueller TLB erstellt, welcher in einer VHPT (VM-VHPT) abgespeichert wird und vom Hypervisor überwacht wird. Dabei unterscheidet Xen vier verschiedene Verfahren: 1. eine VHPT für die gesamte Virtualisierungsumgebung 2. Je eine VHPT für jeden logischen Prozessor 3. Je eine VHPT für jede virtuelle CPU (VCPU) 4. Je eine VHPT für jede virtuelle Maschine (vgl. ebd.) Am geeignetsten hat sich jedoch der dritte Ansatz erwiesen, da man bei ihm die VHPT(s) nicht für die anderen VMs sperren muss und sich somit den erzeugten Overhead, der durch Zwischenspeichern etc. entsteht, erspart (vgl. [7], S. 3). Wie sein Vorbild unterteilt sich auch der virtuelle TLB in ITLB, DTLB und je acht TRs. Eine Besonderheit beim VT-i ist, dass er x TCs (x > 1) implementiert. Der zusätzliche Cache dient dazu noch mehr Einträge im schnellen TLB unterbringen zu können. Als Speicherstruktur kommt eine weitere Hashtabelle in der VM-VHPT zum Einsatz. Die Hersteller von Xen kennen zwei Vorgehensweisen bei der Suche von Adressen im virtuellen TLB: Partial track. Sollte eine Adresse nicht im TLB gefunden werden, wird der Hardwarewalker beauftragt die Adresse in der VHPT zu suchen. Ist sie dort ebenfalls nicht auffindbar muss sie in der VM-VHPT des Hypervisors gesucht werden. Es sei angemerkt, dass wir es von nun an mit der Übersetzung von virtuellen Adressen zu Intermediate Physical Addresses zu tun haben (zusätzlicher Übersetzungsschritt). Hier können zwei Dinge passieren: Zum einen kann es sein, dass die Adresse auch hier nicht gefunden wird dann muss der Hypervisor einen Page-Fault erzeugen und an die VM senden. Bei Erfolg allerdings, wird die VA zunächst in eine IPA übersetzt. In einer weiteren Datenstruktur ( hash TLB ) wird nun diese Adresse endgültig in die korrekte physikalische Adresse übersetzt (vgl. [9] Folie 14, [7], S. 3). Dieses Verfahren wird bei Xen partial track genannt. Wie man sehen kann ist der große Nachteil, dass sich eine gesuchte Information an drei verschiedenen Stellen befinden kann, was dieses Verfahren sehr aufwändig macht. Eine weitere Methode ist das full track -Verfahren (vgl. [7], S. 4). Full track. Erstellt die VM einen neuen Eintrag im TLB, wird dieser automatisch in alle Datenstrukturen übernommen (TLB, VHPT, hash-tlb). Das hat den Vorteil, dass

14 man von jedem Punkt aus direkt die Adresse finden kann. Ferner kann man die Aktivitäten jeder VM überwachen. Auf der anderen Seite erzeugt das redundante Speichern einen enormen Overhead. Im Moment setzt Xen auf das partial track-verfahren. Ein kommender Vergleich beider Ansätze soll zeigen, welches effizienter arbeitet. (vgl. ebd.) 7 Zusammenfassung Diese Arbeit hat die verschiedenen Aspekte der Speichervirtualisierung beleuchtet. Es wurde gezeigt, wie die MMU virtualisiert wird (siehe 2), welche Architekturen die Hersteller nutzen um die Vorteile einer MMU auch auf andere Komponenten zu übertragen (siehe 3) und nicht zuletzt welche verschiedenen Mechanismen zur Speicherverwaltung genutzt werden. Dazu zählen unter anderem das Ballooning (siehe 4.1), welches sich dazu eignet Speicher aus einer VM wieder zurück zu gewinnen, das Memory-Sharing (siehe 4.2) um redundante Inhalte zu reduzieren und die Benutzung von Kosten um die Leerlaufbelastung zu minimieren (siehe 5). Zum Schluss wurde der Translation Lookaside Buffer genauer betrachtet (siehe 6). Es wurde beschrieben wie er in der Itanium Architektur aufgebaut ist und wie der Hersteller von Xen diese Architektur mit verschiedenen Mitteln virtualisiert. Zusammenfassend lässt sich sagen, dass die Virtualisierung in der heutigen Zeit, insbesondere durch die Verwendung verteilter Systeme, immer wichtiger wird. So sind Vorteile wie Kosten- und Aufwandsreduzierung, Portierbarkeit und eine leichte Wartbarkeit von immenser Bedeutung für eine moderne IT. Die aufgezeigten Mechanismen unterstützen diese Entwicklung dahingehend, dass sie die Virtualisierung performanter, sicherer und effizienter machen. Um Synergie-Effekte zu erhalten, sollten die Hersteller, für zukünftige Lösungen, zusammenarbeiten und ihre Verfahren zumindest teilweise untereinander kombinieren. 8 Quellen 1. Pascal Heller, Theorie: Intel EM64T, SpeedStep und XD-Bit, Hardware-Mag.de, Andres Krapf, Virtual Memory and MMU Concepts, 30. Oktober Carl A. Waldspurger, Memory Resource Management in VMware ESX Server, Dezember Roberto Mijat, Andy Nightingale, Virtualization is Coming to a Platform Near You 5. Handbuch zur vsphere Ressourcenverwaltung, VMware, Wikipedia, Translation Lookaside Buffer

15 7. Xiantao Zhang, Qi Li, David K. Y., A Hash-TLB Approach for MMU Virtualization in Xen/IA64, IEEE 8. Matthew Chapman, Ian Wienand, Gernot Heiser, Itanium Page Tables and TLB, Mai Scott Devine, E6998 Virtual Machines Lecture 3 Memory Virtualization, VMWare 10. Christoph H. Hochstätter, Virtualisierung mit Server-CPUs: Leistungsbremse inklusive, ZDNet, 17. Dezember 2008