AMD und Intel versprechen umfangreiche Virtualisierungsunterstützung durch ihre Prozessoren. In Wirklichkeit steht die Technik erst am Anfang. ZDNet erläutert die Architekturen.
Virtualisierung bedeutet immer Kompromisse. Bei einer Vollvirtualisierung muss man erhebliche Performancenachteile in Kauf nehmen. Für eine Paravirtualisierung, die große Teile dieser Nachteile ausgleicht, ist es erforderlich, dass das Gastbetriebssystem zu erheblichen Teilen abgeändert wird, und die ressourcensparende Containervirtualisierung[1] kann gar nur identische Betriebssysteme in mehreren virtuellen Instanzen ausführen.
Ziel einer Prozessorunterstützung für Virtualisierung muss es sein , den Komfort einer Vollvirtualisierung für den Anwender zu erreichen und gleichzeitig deren Performancenachteile zu eliminieren.
Bei Vollvirtualisierung laufen auch die Kernel-Mode-Teile der Gastbetriebssysteme nicht im Ring Null des Prozessors, sondern je nach Virtualisierungslösung im Ring eins oder drei. In diesen Ringen sind nicht alle Befehle möglich.
 |
| Unterschiedliche Virtualisierungstechniken im Überblick |
Die Virtualisierungssoftware fängt nun Befehle, die in Ring 0 nicht möglich sind, in Form einer Exception ab, so dass sie für das Gastbetriebssystem als privilegierte Befehle erscheinen. Im Falle von Speicherverwaltung bedeutet dies, dass die Virtualisierungssoftware aus der physikalischen Speichertabelle Speicher allokiert und in den Adressraum der Gastumgebung legt.
Bei der Intel-Architektur wird Speicher in einer Tabelle in Blöcken zu 4 KByte verwaltet. Die Gastumgebung hat eine gleich strukturierte Tabelle, jedoch wird der Zugriff darauf abgefangen und die Tabelle in Wahrheit von der Virtualisierungssoftware mit verwaltet.
Hier liegt ein großes Performancehindernis für vollvirtualisierte Umgebungen. Der eigentliche Hauptspeicher eines Computers ist relativ langsam. Eine Beschleunigung ergibt sich durch den Cache. Der Cachespeicher hängt jedoch immer komplett zusammen und wird aus Performancegründen nicht in Blöcken verwaltet.
Bei jedem Abfangen von Speicherverwaltung muss daher der Cache komplett in den Hauptspeicher geschrieben werden, was zusätzlich zu der emulierten Speicherverwaltung viel Zeit kostet.
Nachteile beim I/O-Zugriff
Ähnlich sieht es beim I/O-Zugriff aus. Hier liest und schreibt das Gastbetriebssystem in die I/O-Ports, was allerdings von der Virtualisierungssoftware abgefangen wird und in entsprechende Aktionen transformiert wird. Während einfache Bausteine, etwa ein serielles oder ein paralleles Interface, mit wenigen I/O-Ports auskommen, müssen Devices, bei denen es auf Geschwindigkeit ankommt, in den Speicheradressraum des Prozessors gelegt werden.
Ein Standard-Ethernet-Paket beispielsweise kann bis zu 1500 Bytes groß sein. Neuere Ethernetkarten unterstützen auch Jumbo-Pakete mit bis zu 9000 Bytes. Da immer ein ganzes Paket übertragen werden muss, benötigt eine Ethernetkarte immer mindestens den Speicheradressraum für ein Paket. Moderne Ethernetkarten bieten jedoch Speicheradressraum für mehrere Pakete. Der Prozessor legt dabei mindestens ein Paket in den gemeinsamen Adressraum. Danach geschieht die Übertragung über den DMA-Baustein des Motherboards, damit der Prozessor weiterarbeiten kann und die Übertragung über I/O-Ports nicht selbst übernehmen muss.
Hier liegt das größte Performanceproblem der Vollvirtualisierung. Die echten DMA-Bausteine können nur im Kernel-Mode verwaltet werden. Daher muss bei jeder Verwendung eines Peripheriegerätes, etwa Netzwerk, Festplatte oder Bildschirm, ein Taskswitch in die Virtualisierungssoftware durchgeführt werden, der dazu führt, dass der Cache invalidiert wird und der langsame Hauptspeicher bemüht werden muss.
Um diese Performancenachteile einer virtualisierten Umgebung auszugleichen, gibt es verschiedene Ansätze. Ein softwareseitiger Ansatz ist der Austausch von Treibern nach der Installation des Gastbetriebssystems. Diese neuen Treiber versuchen nicht mehr, die Hardware zu programmieren, sondern übergeben Pakete, die an Netzwerkkarte, Festplattencontroller oder Videokarte gesendet werden sollen, an die Virtualisierungssoftware.
Allerdings ist auch diese Übergabe nicht ohne Performanceverlust. Da das Gastbetriebssystem grundsätzlich davon ausgeht, den gesamten Adressraums eines Computers alleine nutzen zu können, müssen die Treiber absichtlich einen privilegierten Befehl ausführen, um eine Exception zu provozieren.
Dies hat natürlich wieder eine Invalidierung des Caches zur Folge. Erst dann kann die Virtualisierungssoftware die Pakete abholen. Lediglich die Emulation der Devices und der DMA-Bausteine fällt in diesem Fall weg.Um Abhilfe zu schaffen, bieten die Prozessorhersteller mittlerweile hardwareseitig Unterstützung an. AMD und Intel gehen hier unterschiedliche Wege - damit sind ihre Lösungen inkompatibel. Virtualisierungssoftware muss sowohl für AMD-V (Codename Pacifica) und Intels VT-x (Codename: Vanderpool) Unterstützung bieten.
Dabei kann man die hardwareseitige Unterstützung in drei Bereiche unterteilen: Als erstes sind neue privilegierte Prozessorbefehle zu nennen. Grundsätzlich wird dabei eine neue, super-privilegierte Umgebung implementiert, die Intel "Ring minus eins" nennt.
 |
| Unterschiedliche Implementierung bei den CPUs |
So können mehrere Gastbetriebssysteme jeweils einen eigenen Ring Null nutzen, mit den dazu gehörigen privilegierten Befehlen, ohne dass eine gegenseitige Beeinflussung möglich ist.
Damit laufen die Kernel-Mode-Teile eines Betriebssystems nicht mehr im Ring eins oder drei, bei dem jeder privilegierte Befehl per Exception abgefangen werden muss. Die Anzahl der Taskswitches wird dadurch deutlich reduziert, was generell eine höhere Performance bedeutet.
Diese Technologie steht heute bei den modernen Prozessoren von AMD und Intel zur Verfügung. Alle namhaften Virtualisierungslösungsanbieter unterstützen heute beide Architekturen. Die zweite Hilfestellung seitens der Prozessorhersteller könnte Speichervirtualisierung sein. Sie ist heute bei Intel gar nicht und bei AMD zum Teil implementiert. Die Grundidee besteht darin, dass einer virtuellen Maschine einmalig Speicher zugeteilt werden kann, der dann von der virtuellen Maschine in gewohnter Weise über Speichertabellen verwaltet wird, ohne dass die Virtualisierungssoftware eingreifen muss.
AMD bietet mit AMD-V heute "Tagged-Translation-Look-Aside-Buffer". Hinter diesem Begriff verbirgt sich eine Tabelle, die sich merkt, welche Speicherbereiche vom Hypervisor der Virtualisierungssoftware und dem Adressraum der virtuellen Maschinen gleichzeitig genutzt werden.
Damit ist es möglich, dass Taskswitches durchgeführt werden können, ohne dass der Cache invalidiert werden muss. Dies bietet zwar deutlichen Performancegewinn, muss aber als Zwischenlösung betrachtet werden, da Taskswitches erst gar nicht nötig sein sollen.
Ziel von AMD und Intel ist es, "Nested Page Tables" zu implementieren. Damit kann die Virtualisierungssoftware eine Master-Table verwalten und den Gastbetriebssystemen davon abhängige Tabellen zur Verfügung stellen, so dass jede virtuelle Maschine hardwareseitig eine eigene Speicherverwaltung besitzt.
AMDs Quad-Core-Opteron mit Nested Page Tables
AMD hat Nested Page Tables für dieses Jahr angekündigt und will diese Technologie in allen zukünftigen Opteron-Prozessoren standardmäßig anbieten. AMD und Vmware haben bereits eine "Experimentalversion" eines Quad-Core-Opteron mit Nested Page Tables demonstriert. Intel ist inzwischen verdächtig ruhig und verweist auf seine bestehende VT-x-Technologie.
Dies hat sicherlich den Grund, dass Intel einen externen Memory-Controller verwendet, den so genannten Frontsidebus, während dieser bei AMD auf dem Prozessor integriert ist. Will Intel hardwareseitige Unterstützung für Memory-Virtualisierung anbieten, so muss der Memory-Controller grundlegend modifiziert werden.
AMD bietet heute sogar explizite Speichermodellunterstützung für Nostalgiker: den Paged-Real-Mode, bei dem virtuelle Real-Mode-Adressierung mittels Speichertabellen möglich ist. Allerdings muss man sich fragen, was AMD hiermit erreichen möchte. Diesen Mode gibt es schließlich bereits seit dem Intel 80386, wenngleich nicht im virtuellen Ring-0-Modus.
Zu Zeiten von DOS waren damit mittels Tools wie EMM386 oder QEMM386 wahre Wunder möglich. Auch DOS-Multitasker wie Desqview wurden damit realisiert. Der praktische Einsatz beschränkt sich heute schlussendlich darauf, dass in den 32- und 64-Bit-Gastbetriebssystemen hardwareunterstützte DOS-Boxen möglich sind. Die dritte Unterstützungsnöglichkeit seitens der Prozessorhersteller ist I/O-Virtualisierung. Sowohl AMD mit IOMMU[2] als auch Intel mit VT-d haben für 2008 Serienreife angekündigt.
In dieser Hinsicht können die Prozessorhersteller jedoch noch nur einen Teil beitragen. Intel und AMD können DMA-Buffer so legen, dass diese von allen virtuellen Maschinen genutzt werden können, ohne dass ein Taskswitch oder eine Cache-Invalidierung erforderlich ist. Ein anderer Teil muss von den Herstellern der PCI-Karten selbst kommen. Stand heute ist es nicht möglich, dass verschiedene Prozesse unabhängig voneinander I/O-Ports programmieren.
Dies könnte in einer Weise geändert werden, dass eine PCI-Karte mehrere I/O-Port-Ranges mit demselben Zweck anbietet, die unabhängig von verschiedenen Prozessen oder virtuellen Maschinen genutzt werden und dann in der PCI-Karte selbst serialisiert werden. Erst dann können I/O-Operationen in virtualisierten Umgebungen mit vergleichbaren Geschwindigkeiten wie in nativen Betriebssystemen ausgeführt werden.
Selbst wenn die Prozessorhersteller ihren Teil bis 2008 liefern, dürften die PCI-Kartenhersteller deutlich länger brauchen. Die verschiedenen Hersteller müssen sich schließlich erst einmal absprechen, was sich erfahrungsgemäß in die Länge ziehen kann. Um die Performancenachteile einer Virtualisierung auszugleichen, beginnen die Prozessorhersteller heute mit hardwareseitiger Unterstützung. Sie ist aber alles andere als ausreichend.
Bezüglich privilegierter Instruktionen im Ring 0 haben sowohl Intel als auch AMD ihre Hausaufgaben bereits gemacht. Hinsichtlich Speichervirtualisierung bietet AMD heute eine Teil-Unterstützung, hat aber die volle Unterstützung mit Nested Page Tables bereits auf der Vmworld 2006[3] der Öffentlichkeit eindrucksvoll demonstriert.
Intel hinkt hier eindeutig hinterher. Dies hängt vor allem damit zusammen, dass Intel-Prozessoren auf einen externen Memory-Controller zurückgreifen müssen. Deshalb wird es noch einige Zeit dauern, bis Intel bei Speichervirtualisierung nachzieht. Hardwareseitige I/O-Virtualisierung wird heute weder von Intel noch von AMD unterstützt und ist erst für 2008 angekündigt.
Neben vollvirtualisierten System können auch paravirtualisierte Systeme von der Prozessorunterstützung, insbesondere der Speicherverwaltungsunterstützung, Gebrauch machen. Durch die Einblendung von Schnittstellen der Virtualisierungslösung in den Adressraum der Gastbetriebssysteme können APIs realisiert werden, die zum Beispiel Ressourcen wie Hauptspeicher und Plattenplatz dynamisch zwischen den einzelnen Gastmaschinen verteilen.
Dies würde eine Containervirtualisierung, die pro Computer nur ein Betriebssystem unterstützt, weitgehend überflüssig machen. Nötig dafür sind allerdings Schnittstellenabsprachen zwischen den Herstellern von Betriebssystemen und Virtualisierungslösungen. Die neuerliche Kooperation von Microsoft und Novell in Sachen Virtualisierung lässt Hoffnungen für die Zukunft aufkommen.
Weitere Informationen:
- Keith Adams und Ole Agesen (Vmware): A Comparison of Software and Hardware Techniques for x86 Virtualization[4]
- Randy Allen (AMD): Moving Virtualization Forward: How emerging data center architectures are enabling virtualization adoption
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/