Intels Vanderpool virtualisiert CPUs

15.11.2005 von Christian Vilsbeck
Per Virtualisierung laufen mehrere Betriebssysteme gleichzeitig auf einem PC. Reine Software-Lösungen muss die Hardware mit Einschränkungen emulieren. Intels Vanderpool-Technologie soll dieses Problem lösen – jetzt auch beim Pentium 4.

Virtualisierung auf einem PC arbeitet meist nach dem folgenden Prinzip: Eine so genannte Virtual-Machine-Software erzeugt auf einem Host-Rechner emulierte PCs. Diese emulierten PCs verfügen über alle notwendigen Elemente wie Prozessor, Festplatte, Grafikkarte und Tastatur. Innerhalb dieses geschlossenen Systems kann ein Betriebssystem gestartet werden, das auf die virtuelle Hardware zugreift, als sei es ein echter Computer, ohne den Unterschied zu bemerken.

In der Praxis gestaltet sich diese Aufgabe jedoch erheblich schwieriger. Immerhin gilt es, eine Vielzahl von benötigten Komponenten virtuell zu erzeugen. Da das Betriebssystem auf dem Host-Rechner den exklusiven Zugriff auf die Hardware behält, kann eine VM-Software dem Gastbetriebssystem keinen direkten Zugriff auf die reale Hardware gewähren. Deshalb findet das Betriebssystem in der virtuellen Maschine auch eine andere Hardware vor, als tatsächlich im PC eingebaut ist.

Mit Vanderpool löst Intel dieses Problem zumindest beim Prozessor. Ein Gastbetriebssystem darf die CPU durch Vanderpool mit allen Rechten und der vollen Performance nutzen. Trotzdem behält die Virtualisierungssoftware die Oberhand. Mit dem Pentium 4 662 und 672 gibt es bereits erste Vanderpool-CPUs.

Simulierte CPU

Eine VM-Software muss den VMs - den virtuellen Maschinen – ohne Technologien wie Intels Vanderpool virtuelle Prozessoren vorgaukeln. Nur so kann der Host die volle Kontrolle über den Prozessor behalten. Leider bedingt dies, dass den virtuellen Maschinen simulierte CPUs mit eingeschränkter Funktionalität zur Verfügung stehen. Die VM-Software bietet dann den VMs beispielsweise keinen SMP-Support oder Features wie EM64T. Auch steht den VMs durch die "Software-CPUs" weniger Prozessor-Performance als beim Original zur Verfügung. Hätten die VMs aber vollen Zugriff auf die "Original-CPU", so könnten sie sich gegenseitig beeinflussen und Abstürze verursachen.

Mit Vanderpool will Intel dieses Problem bei den eigenen Prozessoren aus der Welt schaffen. IA32-CPUs mit Vanderpool-Technologie VT-x erhalten den so genannten VMX-Befehlssatz. Die neuen Befehle bieten virtuellen Maschinen Prozessor-Level-Support. Vanderpool ermöglicht der VM-Software eine einfachere und sichere Verwaltung der Prozessor-Ressourcen. Im Januar 2005 veröffentlichte Intel vorläufige Spezifikationen des VMX-Befehlssatzes. Auf dem Intel Developer Forum im März 2005 gab der Hersteller Einblick in den Betrieb von CPUs mit Vanderpool-Technologie.

Virtueller Prozessor

Die CPU ist der Hauptbestandteil des echten und des virtuellen PCs. Intels IA32- sowie auch AMDs AMD64-Architektur haben allerdings hinsichtlich der Abbildung virtueller Maschinen gegenüber den Mainframes einige Schwächen. Letztere sind schon architektonisch auf virtuelle Maschinen ausgelegt.

Intels Prozessoren mit IA-32-Architektur bieten vier verschiedene Privilegien an, mit denen dem Betriebssystem sowie den Treibern und Programmen unterschiedliche Rechte zugewiesen werden können. Normalerweise laufen das Betriebssystem und die Treiber im so genannten Ring 0 (Kernel Mode) und Applikationen im Ring 3 (User Mode). Diese "Current Privilege Levels" werden auch mit CPL 0 beziehungsweise CPL 3 bezeichnet. Der Trick beim Erzeugen eines virtuellen Systems besteht darin, dieses mit CPL 3 ablaufen zu lassen.

Wenn das Betriebssystem des virtuellen Rechners nun einen Befehl ausführen will, der nur im Ring 0 (CPL 0) gestattet ist, löst der Prozessor eine Exception aus. Routinen zur Behandlung dieser Ausnahmen können dann den privilegierten Befehl emulieren. Dabei behält das Wirtsystem die volle Kontrolle über das System. Die wichtigste Voraussetzung für das Funktionieren dieses Ansatzes ist, dass der Prozessor bei jeder unberechtigt durchgeführten privilegierten Anweisung eine Exception auslöst.

Leider sind die x86-Prozessoren nicht ganz so gründlich bei den Exceptions. Beispielsweise werden Speicherzugriffe beim x86 über eine GDT (Global Descriptor Table) abgewickelt. Diese GDT ist eine globale Ressource und wird vom Betriebssystem verwaltet. Eigentlich müsste jeder direkte Zugriff auf diese Ressource als privilegierte Handlung angesehen werden und dementsprechend im User Mode nicht erlaubt sein. Der x86 behandelt die LGDT-Anweisung (Load Global Descriptor Table) auch als privilegiert. Allerdings führt SGDT (Store Global Descriptor Table) nicht zu einer Schutzverletzung. Allein diese Inkonsistenz verhindert es, die GDT zu "virtualisieren".

Intels Vanderpool-Technologie greift hier ein und erleichtert unter anderem auch das Exceptions-Handling. VM-Software mit Vanderpool-Support lässt sich somit einfacher programmieren - bei gleichzeitig höherer Betriebssicherheit.

VMX-Operationen

Intel unterstützt die Virtualisierung auf Prozessorebene durch eine neue Form von CPU-Operationen mit der Bezeichnung VMX (Virtual Machine Extensions). Dabei gibt es mit "Root" und "Non-Root" zwei Arten von VMX-Operationen. So agiert beispielsweise VM-Software im VMX-Root-Modus. Intel bezeichnet diesen Host auch als Virtual Machine Monitor VMM. Der VMM besitzt die volle Kontrolle über den Prozessor und die übrige Hardware des PCs. Die virtuellen Maschinen beziehungsweise die Gast-Software arbeiten somit im VMX-Non-Root-Modus.

Ein VMM kann den Prozessor durch "VM Entries" genannte Sequenzen veranlassen, im VMX-Non-Root-Modus zu arbeiten. Der Übergang zurück in den VMX-Root-Modus erfolgt mit "VM Exits"-Befehlen. Die Funktionalität eines Prozessors im VMX-Root-Modus entspricht dabei einer CPU ohne VMX-Unterstützung. Der Unterschied einer Vanderpool-CPU liegt in den zusätzlich verfügbaren VMX-Befehlen. Außerdem sind die in bestimmten Control-Registern speicherbaren Werte durch VMX limitiert. Das Verhalten des Prozessors im Non-Root-Modus lässt sich durch VMX kontrollieren. So verursachen bestimmte Befehle oder Situationen VM Exits.

Dabei ist es für Gast-Software nicht möglich, seinen Betrieb im VMX-Non-Root-Modus zu erkennen. Durch VMX behält der VMM auch die Kontrolle über VM-Software, die mit CPL 0 arbeitet. Mit VMX besitzt der VMM einfach ausgedrückt einen höheren "Privilege Level" als CPL 0. Diese Fähigkeit erleichtert die Programmierung eines VMM, weil die Gast-Software stets in dem "Privilege Level" arbeiten kann, für die sie entwickelt wurde.

Initialisierung

Ob ein Prozessor VMX unterstützt, kann die Host-Software über die CPUID abfragen. Beim Ausführen von CPUID mit dem Wert 1 im EAX-Register zeigt das Bit 5 des in das ECX-Register übergebenen Wertes den VMX-Support. Eine "1" kennzeichnet VMX-Unterstützung.

Will ein VMM den VMX-Modus des Prozessors verwenden, muss er ihn erst aktivieren. Dies erfolgt über das Setzen des Bit 13 im CR4 (CR4.VMXE). Danach lassen sich durch den Befehl VMXON die Virtual Machine Extensions verwenden. Das Kontrollbit CR4.VMXE kann jetzt nicht mehr gelöscht werden. Soll der Prozessor den VMX-Modus verlassen, muss der Befehl VMXOFF von der System-Software verwendet werden.

Vor dem Ausführen des VMXON-Befehls muss die Host-Software einen 4 KByte großen Speicherbereich für VMX-Operationen reservieren. Die Adresse dieser Speicherregion wird in einem Operanten des VMXON-Befehls übergeben. Zwischen VMXON und VMXOFF sollte dieser Speicherbereich von der Host-Software unangetastet bleiben (siehe VMX-Kontrolle). In diesem 4-KByte-Bereich sind alle relevanten Informationen des Prozessors und des Betriebssystems einer VM gespeichert.

VMX-Operationen setzen den Page-protected Mode voraus. Dies ist durch die bei VMX notwendigen Einschränkungen bei den Registerbits CRO.PE und CRO.PG notwendig. Der Betrieb von Gast-Software im Unpaged-protected Mode oder im Real-Address Mode sind somit nicht möglich. Soll ein VMM entsprechende Gast-Software trotzdem unterstützen, muss vom VMM eine Emulation dieser Modi erfolgen. Hierzu kann ein VMM die "Identify Page Tables" für die Emulation verwenden.

VMX-Kontrolle

Die Kontrolle über die VMX-Non-Root-Workloads übernimmt eine neue Datenstruktur mit der Bezeichnung "Virtual-Machine Control Structur" VMCS. Das VMCS zeichnet für die Übergänge in und aus den Non-Root-Modi ebenso verantwortlich wie für den Prozessor im "Gastmodus" selbst. Über die neuen VMX-Befehle VMCLEAR, VMPTRLD, VMREAD und VMWRITE lässt sich das VMCS einstellen (siehe auch VMX-Befehle im Überblick).

Der Prozessor verknüpft jedes VMCS-Register mit einer 64 Bit breiten physikalischen Adresse - und dem bereits erwähnten 4 KByte großen Block. Die Aktivierung einer VMCS - und somit einer virtuellen Maschine - erfolgt über den VMX-Befehl VMPTLRD mit zugehöriger Adresse. Diese VMCS bleibt dann für die Kontrolle des Prozessorverhaltens in einer Gast-Software so lange aktiv, bis der VMX-Befehl VMCLEAR mit der gleichen Adresse erfolgt. Von der Host-Software können dabei je nach Bedarf an virtuellen Maschinen mehrere VMCS - pro logischer CPU aber nur eine - angelegt werden.

Ein VMCS ist dabei in sechs logische Gruppen unterteilt: die Guest-State Area, Host-State Area, die VM-Execution Control Fields, VM-Exit Control Fields, VM-Entry Control Fields und VM-Exit Information Fields. Die letztgenannte Gruppe enthält beispielsweise Informationen über die Ursachen und Art eines VM Exits, wenn also eine virtuelle Maschine beendet wird.

Um einen sicheren VMX-Betrieb des Prozessors zu ermöglichen, sollten auf das VMCS keine Zugriffe über allgemeine Speicheroperationen erfolgen. Dies kann laut Intel zu einem unvorhersehbaren Verhalten der CPU führen. Stattdessen sind zum Auslesen und Schreiben der VMCS-Datenfelder die Befehle VMREAD und VMWRITE zu verwenden. Deren Operanten enthalten die entsprechenden Enkodierinformationen der Daten.

VMX-Befehle im Überblick

Intels Vanderpool-Technologie mit den Virtual Machine Extensions VMX verfügt über zehn neue Befehle. Dabei dienen fünf Instruktionen dem Verwalten der Virtual Machine Control Structure VMCS. Die übrigen fünf Befehle führen VMX-Operationen durch.

Folgende fünf VMX-Befehle dienen der VMCS-Verwaltung:

Diese fünf Befehle ermöglichen VMX-Operationen:

Vanderpool im Einsatz

Prozessoren mit VMX-Befehlssatz erleichtern die Virtualisierung und bieten mehr Betriebssicherheit. Auch die Performance steigt durch Vanderpool, weil sich die Anzahl der von einer VM-Software abzufangenden VM-Events stark reduziert.

Erste Prozessoren mit Intels Vanderpool gibt es seit 14. November 2005 mit den Pentium-4-Modellen 662 und 672. Im ersten Quartal 2006 folgen die Pentium-D-Modelle „Presler“ sowie die Mobil-Prozessoren Pentium M „Yonah“.

Bei den Xeon-7000-Modellen für Systeme mit vier und mehr Prozessoren ist Vanderpool bereits integriert. Allerdings lässt sich die Virtualisierungstechnologie laut Intel erst Anfang 2006 nutzen, dann will der Hersteller in Zusammenarbeit mit den Board-Herstellern entsprechend erforderliche BIOS-Versionen anbieten.

Im Laufe des ersten Quartals 2006 erhalten die Xeon-Modelle „Dempsey“ für 2-Sockel-Systeme zusammen mit der dann ebenfalls neuen Bensley-Plattform Vanderpool. Nach der Verschiebung der Markteinführung des Dual-Core-Itaniums „Montecito“ auf Mitte 2006 dauert das Debüt von Vanderpool bei IA64-Systemen allerdings noch etwas.

Um für die Vanderpool-Prozessoren möglichst schnell entsprechend angepasste Software bereit zu stellen, arbeitet Intel unter anderem mit Microsoft, Xen community und VMware zusammen. VMware bietet aktuell das Paket Workstation 5.5 in einer Beta-Version zum Download an. Darin ist bereits eine „experimentelle“ Unterstützung von Vanderpool enthalten. Auch Xen integriert in der „unstable“ Version 3.0 Support für Intels Vanderpool-Technologie. Hitachi arbeitet an einer Virtualisierungslösung für die eigenen Itanium-2-Syteme. Dabei läuft die VM-Software als EFI-kompatibles Programm im EFI-BIOS - das Host-Betriebssystem entfällt.

Ausblick

Intel selbst klassifiziert Vanderpool nur als ersten Schritt in Richtung Virtualisierung. Noch wird für die Virtualisierung die entsprechende Software, in diesem Fall ein Host-Betriebssystem plus der VM-Software, benötigt. Die Idealvorstellung wird zukünftig sein, dass die Hardware die Virtualisierung gleich selbst erledigt. So lässt Intel in den Vanderpool-Spezifikationen bereits jetzt Spielraum für Erweiterungen.

Als nächste Schritte sollen die Virtualisierung des Speichers, des Netzwerk-Controllers und des Storage-Subsystems folgen. Selbst vor der Grafikkarte wird künftig nicht Halt gemacht. Langfristiges Ziel ist somit die Virtualisierung der kompletten Plattform.

Sowohl im Business- als auch im Consumer-Segment existieren zahlreiche Anwendungsszenarien für Virtualisierung - beispielsweise für die Migration von einem Betriebssystem zu einem anderen.

In einer VM lassen sich die verwendeten Programme ohne Gefahr mit dem neuen OS testen. Anwendungen, die auf dem neu einzusetzenden Betriebssystem nicht laufen, arbeiten einfach in einer eigenen VM mit dem bisherigen OS weiter. Bei Desktop-PCs im Consumer-Segment wären eigene hoch abgesicherte Installationen für den Internet-Zugriff möglich.

AMD besitzt mit Pacifica ebenfalls eine Virtualisierungstechnologie. Die Pacifica-Erweiterung ist mit Intels VMX-Befehlssatz nicht kompatibel. AMD virtualisiert mit Pacifica zusätzlich den integrierten Speicher-Controller. Außerdem beherrscht die AMD-Technologie neue Security-Features. Erste AMD64-Prozessoren mit Pacifica soll es im Laufe der ersten Jahreshälfte 2006 geben.

Einzelheiten über AMDs Virtualisierungsverfahren Pacifica finden Sie im Artikel AMDs Pacifica: Virtualisierung von CPU & Speicher. (cvi)