Historisch kennt die x86-Familie seit dem 80386 vier Privilege-Level und eine virtuelle MMU. Von den vier Privilege Leveln werden heute nur zwei benötigt. Level 0 als sicherster Level, in dem das Betriebssystem läuft und Level 3 als nicht-privilegierter Level für die Anwenderprogramme. Die Umschaltung zwischen den beiden Ebenen geschieht ausschließlich im Betriebssystem. Dieser Aufbau gilt im Prinzip für alle modernen x86-Betriebssysteme, wie Windows seit NT und Linux, die freien BSD-Derivate und kommerzielle UNIXe.

Für die Virtualisierung ist das jedoch problematisch. Im höchsten Level 0 darf ein Betriebssystem alles. Eine Möglichkeit, den Level 0 so aufzuteilen, dass sich mehrere Betriebssysteme nicht gegenseitig beeinflussen können, ist nicht vorgesehen. Für den Einsatz von nur einem Betriebssystem auf einem System ist diese Funktionalität natürlich ausreichend – ein Grund dafür, warum sich seit dem 80386 nichts Grundlegendes an Privilege Level und MMU geändert hat. Beim Wunsch, mehrere Betriebssysteme auf einem System zu betreiben, stehen Sie jedoch unversehens vor dem alten Problem: Diese können in Ring 0 nicht voneinander isoliert werden. Und sie können sich bei MMU-Zugriffen gegenseitig in die Quere kommen.

Die bislang verwendeten Lösungen des Problems bestanden entweder in der Modifikation der virtualisierten Betriebssysteme oder dem dynamischen Umschreiben kritischer Betriebssystemroutinen im Kontext des Hypervisors. Beide Ansätze bringen jedoch Performance-Einbußen mit sich, zudem sind Modifikationen bei kommerziellen Closed Sourced-Systemen, wie beispielsweise Windows, vom Wohlwollen der Hersteller abhängig. Ungefähr zwanzig Jahre später haben die großen x86-Hersteller das Problem angegangen und Virtualisierungserweiterungen in ihre Prozessoren eingebaut.

AMD Pacifica und Intel Vanderpool
Die Lösung des Problems seitens der Prozessorhersteller bestand aus einem weiteren Privilege-Ring, der umgangssprachlich als "Ring-1" bezeichnet wird. Er erlaubt quasi das Einrichten mehrerer Ring-0- Instanzen und regelt den Zugriff auf bestimmte Funktionen der MMU. Damit können normale Betriebssysteme ohne Modifikationen in Ring 0 laufen, während sie aus Ring -1 heraus koordiniert werden. Die Lösungen von AMD und Intel unterscheiden sich in ihrer Implementierung, sodass sie inkompatibel zueinander sind, obwohl sie weitgehend die gleiche Funktionalität bieten. Moderne Virtualisierungslösungen unterstützen allerdings beide Ansätze, sodass dem Anwender keine Nachteile entstehen. Sowohl AMDs Pacifica (mittlerweile als Secure Virtual Machine bezeichnet, kurz SVM), als auch Intels Vanderpool (heute VT genannt) ermöglichen Virtualisierung in der heutigen Form überhaupt erst.

Microsofts Hyper-V sowie KVM benötigen zwingend Pacifica oder Vanderpool. Nahezu alle aktuellen x86-Prozessoren von AMD und Intel bieten Virtualisierungserweiterungen, bis auf einige Modelle im Low-Cost oder Mobile-Marktsegment. Wie bereits erwähnt, betreffen Vanderpool und Pacifica lediglich die Verwaltung virtueller Maschinen, Privilegien und die Speicherverwaltung. Zudem zeigen beide Lösungen in bestimmten, wichtigen Fällen Performanceschwächen. Und sie lösen nur einen Teil des eigentlichen Problems – wie virtuelle Maschinen etwa auf Devices zugreifen sollen, beantworten beide nicht.

Optimierungen: AMD NPT und Intel EPT
Im zweiten Entwicklungsschritt ging es beiden Herstellern hauptsächlich darum, die bestehenden Performanceengpässe zu beseitigen. Ein gravierendes Problem verursacht dabei wieder einmal die Speicherverwaltung. Bei der Übersetzung von virtuellen in physikalische Adressen benutzt die MMU Tabellen, deren Einträge aus Performancegründen teilweise in einem schnellen Cache liegen, dem "Translation Lookaside Buffer" (TLB). Ähnlich den bekannten Caches für Instruktionen und Daten hält der TLB Teile der Übersetzungstabellen bereit, damit die MMU-Operationen möglichst schnell abgearbeitet werden können. Rufen virtuelle Maschinen jedoch den Hypervisor auf, etwa um mit Geräten zu kommunizieren oder um Speicher anzufordern, ist ein sogenannter VM-Kontextwechsel nötig. Dabei wird im Prinzip zwischen Gastsystem- Speicherschicht zu Hypervisor-Speicherschicht gewechselt. Das Problem dabei: beide haben eigene Übersetzungstabellen.

Nach einem Wechsel enthält der TLB im neuen Kontext damit nur noch nutzlose Informationen, nämlich die falschen Tabellen. Um Fehler zu vermeiden, muss der TLB bei jedem VM-Kontextwechsel komplett gelöscht werden. Finden Device- Zugriffe häufiger statt oder laufen mehr virtuelle Maschinen, als Prozessorkerne im System verfügbar sind, bricht die Performance teilweise nicht unerheblich ein. Der beschleunigende Effekt des TLB-Caches wird zunichte gemacht. Beide Hersteller lösten das Problem auf nahezu gleiche Weise und führten für die Einträge im TLB Flags ein, die darüber informierten, zu welchem VM-Kontext – also zu welcher Tabelle – die Einträge gehören. Damit können VMs den TLB gemeinsam benutzen, ohne den jeweils anderen Datensatz komplett zu löschen. Bei AMD nennt man diese Technologie "Nested Page Tables", bei Intel heißt die Lösung "Extended Page Tables". NPT verbaut Intel in allen Sockel-F ab der Barcelona- Generation, während Intel EPT ausschließlich in der allerneuesten Xeon 55xx Core i7 Generation anbietet.

 

  <<Vorherige Seite                Seite 2 von 3                     Nächste Seite>>

Thomas Weyergraf/dr/ln