Um das Ergebnis zu verstehen, muss man sich die Funktionsweise von Binary Translation ein wenig verdeutlichen. Binary Translation ist ein schöner Begriff für eine unschöne Sache, nämlich Patchen von Kernel-Mode-Code. Ohne jede Hardwarevirtualisierungsunterstützung müsste der Kernel des Gastbetriebssystems im Ring 3 des Prozessors laufen, damit der Hypervisor bestimmte Befehle abfangen kann, etwa direkten Zugriff auf Hardware.
Um den Kernel trotzdem im Ring 0 ablaufen lassen zu können, muss er gepatcht werden. So müssen beispielsweise alle IN- und OUT-Befehle durch Aufrufe an den Hypervisor ersetzt werden. Binary Translation ist eine Technologie, deren Risiko man nicht unterschätzen sollte.
Aktuelle VMware-Versionen können ohne Probleme auch das neueste Windows-7-Build mit Binary Translation ausführen. Vor wenigen Jahren jedoch war das wichtigste Dokument auf der VMware-Website die Betriebssystemkompatibililtätsliste. Spielte man ein Service Pack ein, ohne dass selbiges offiziell unterstützt wurde, war der Absturz so gut wie sicher, weil einerseits keine Hardwareunterstützung in den Prozessoren vorhanden und Binary Translation andererseits noch nicht so ausgereift war wie heute.
Auch wenn VMware und andere Virtualisierungsanbieter die Binary-Translation-Technologie weiter verbessert haben, bleibt ein Restrisiko. Ein Kernel- oder Treiber-Patch per regulärem Update kann eine Gastmaschine unbrauchbar machen.
Dass Binary Translation überhaupt funktionieren kann, ist dem Umstand zu verdanken, dass gängige Betriebssysteme keine Segmentierung verwenden, sondern ausschließlich lineares Paging nutzen. Das ermöglicht dem Hypervisor, Segmentierung einzusetzen, um sich selbst vor dem Kernel zu verbergen. Als AMD seine ersten 64-Bit-Prozessoren vorstellte, verzichtete AMD im Long Mode, wie es die 64-Bit-Betriebssart des Prozessors nannte, auf Segmentierung, da sie von modernen Betriebssystemen ohnehin nicht genutzt wurde. So konnten Page Walks verkürzt werden. Intel machte dasselbe bei EM64T.
AMD führte mit der Revision D seiner 64-Bit-Prozessoren nicht die vollständige Segmentierung wieder ein, jedoch lässt sich beim Hauptspeicher ein Limit einstellen. Kommt man darüber hinaus, generiert der Prozessor eine Exception. Intel verzichtete auf diesen Schritt. Das ist der Grund, warum Binary Translation für Intel-Prozessoren nur mit 32-Bit-Gastmaschinen möglich ist. Intel-64-Bit-Prozessoren ohne jegliche Hardwareunterstützung, etwa späte Pentium-4-Modelle, können überhaupt nicht zur Virtualisierung von 64-Bit-Gastmaschinen eingesetzt werden.
Bei Aufruf von Kernel-Funktionen mittels Syscalls verhält sich Binary Translation nicht besonders performant. Der Syscall landet zunächst im Hypervisor, der ihn mit einem weiterem Context-Switch an den Kernel des Gastbetriebssystems weiterleiten muss. Das bedeutet, dass Binary-Translation immer dann langsam ist, wenn das Anwendungsprogramm einer Gastmaschine mit seinem Kernel interagiert, zum Beispiel beim Zugriff auf das Dateisystem.
- Virtualisierung mit Server-CPUs: Leistungsbremse inklusive
- Intels EPT schlägt AMDs RVI
- Segmentierung und Paging bremsen Speicherzugriff
- Der TLB als Abkürzung
- Hardware- oder Softwarevirtualisierung
- Risikotechnologie Binary Translation: bei Intel nicht mit 64 Bit
- Hardwarevirtualisierung der ersten Generation wenig ausgereift
- Core-2-CPUs nur eingeschränkt virtualisierungstauglich
- Auswahl der richtigen Technologie: meist nicht einfach
- Fazit
- Benchmarkergebnisse in der Übersicht
Neueste Kommentare
1 Kommentar zu Virtualisierung mit Server-CPUs: Leistungsbremse inklusive
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Story comment
A very interesting story