Normalerweise ist es wünschenswert, dass die CPU-Befehle einer virtuellen Maschine ohne Umwege auf der Wirts-CPU ablaufen. Quicktransit von den Machern des Apple-Plattform-Emulators Rosetta virtualisiert auch die CPU. Mit zwischengelagerter Übersetzung sind Binaries dann architekturübergreifend lauffähig.

Virtuelle Maschinen gleichen der Host-Maschine normalerweise mindestens in der CPU-Architektur. Die meisten Maschinenbefehle aus der virtuellen Maschine verarbeitet die Wirts-CPU dann ohne Umweg. Die Virtualisierungssoftware fängt lediglich Hardware-bezogene Systemcalls ab.

Etwas völlig anderes tut der auf Intel-Macs in OS X integrierte Emulator Rosetta: Er sorgt dafür, dass vorliegende Power-Mac-Binaries auf den Intel-Maschinen arbeiten. Das Binary läuft in der Systemumgebung, für die es konzipiert ist, allerdings nicht auf der richtigen Architektur. Rosetta übersetzt daher die Maschinenbefehle für die Intel-Architektur. Hinter der Apple-Emuationslösung steckt die Firma Transitive [1], die IBM Ende November gekauf hat.

Die Quicktransit-Produktreihe [2] der Firma kombiniert Architektur- und Systememulation: Die Sparc/Solaris-Linux-x86-Emulationssoftware startet Sparc/Solaris-Anwendungen auf Linux-Systemen, die auf einer x86-Maschine laufen. Die Entwickler nennen dies Crossplattform-Virtualisierung. Eine Sparc-x86-Lizenz kostete vor der Übernahme durch IBM pro Prozessor inklusive Support 875 Dollar im Jahr. Aktuelle Preise sollen nach telefonischer Auskunft ab Ende Februar verfügbar sein.

Die GPL-Virtualisierungslösung Qemu kann das auch: Sie führt zum Beispiel PC-Anwendung auf Power Macs aus und umgekehrt. Als Preis für die Architekturabstraktion sinkt die Performance um ein Vielfaches. Die Translation-Engine von Quicktransit versucht die Geschwindigkeitsverluste durch einen Codecache abzumildern (Abbildung 1).

Abbildung 1: Optimierter Übersetzungsvorgang: Die Crossplattform-Virtualisierungslösung Quicktransit beschleunigt das rechenaufwändige Übersetzen von Maschinenbefehlen aus der Wirts- in die Gastarchitektur durch Segmentieren und Puffern.

Übersetzer in Aktion

Abbildung 1 schematisiert den Ablauf beim Starten eines Sparc-Binary auf einer x86-Maschine. Die Schritte 1 bis 5 zeigen die normale, unbeschleunigte Übersetzung. Beim Übersetzen kennt Quicktransit neben dem normalen Interpreter-Modus, der einzelne Instruktionen überträgt, zwei Blockmodi. Der Basic-Blockmode erkennt Codeblöcke, die normalerweise an Codeverzweigungen enden. Der Group-Blockmode geht noch einen Schritt weiter, er kombiniert mehrere Basic-Blocks und optimiert den Zielcode noch stärker. Diese aufwändige Optimierung kommt aber nur bei besonders häufig ausgeführten Codestellen zum Einsatz. Ein Codecache hält außerdem bereits übersetzten Maschinencode vor.

Doppelt abstrahiert

Eine Abstraktion der CPU-Architektur reicht noch nicht aus, um eine Solaris-Anwendung auf einer x-86-Maschine zu starten, auf der Linux läuft. Neben der Übersetzung des Maschinencode ist noch eine Übertragung der Systemcalls der von der Solaris-Anwendung genutzen Bibliotheken in ihre Linux-Entsprechung erforderlich. Auch diese stellt Quicktransit bereit (Abbildung 2). So läuft eine Sparc/Solaris-Anwendung auf einem x86/64-Bit-Linux-System. Modifikationen sind dabei weder am Wirtssystem noch an der Gastanwendung erforderlich.

Abbildung 2: Zweifach fremdgegangen: Ein Sparc/Solaris-Binary läuft mit Hilfe von Quicktransit auf einem x86-Linux-System. Die Emulator-Lösung übersetzt sowohl die Sparc-Maschinenbefehle als auch die Solaris-Systemcalls.

Statt – ähnlich wie Wine – einer Übersetzungssicht für einzelne Anwendungen stellt Quicktransit alternativ eine vollständige virtuelle Maschine bereit (Abbildung 3). Dann läuft nicht mehr bloß eine einzelne Anwendung, sondern ein komplettes System auf einer fremdem Architektur. Der Systemcall-Mapper ist durch virtualisierte Hardware ersetzt, die Sparc/Solaris-Anwendung läuft nun unter einem Solaris-Kernel.

Abbildung 3: Komplett umgezogen: Quicktransit überträgt nicht nur einzelne Anwendungen, sondern alternativ auch komplette Betriebssysteme auf eine fremde Architektur.

Als besonders Performance-kritisch bei der Übersetzung des architekturspezifischen Code gilt die MMU-Emulation. Ohne Hardware-Unterstützung fallen die Kosten dafür besonders hoch aus. Daher nutzt Quicktransit unter Linux KVM, um den Gast- vom Übersetzungs-Adressenraum zu trennen. So kann es Hardware-Unterstützung für das Adressmapping in Anspruch nehmen. Quicktransit ersetzt dabei Qemu, das die Kernelentwickler als Standard-Virtualisierungssoftware für die KVM-Schnittstelle vorgesehen haben: Es stellt die virtualisierte Hardware zur Verfügung und läuft dabei dank KVM-Schnittstelle im Userspace.

Virtuelles Gegenstück

Die virtuelle Maschine von Quicktransit fällt komplexer aus als Qemu. Damit die virtuelle Maschine unter Linux die Sparc-CPU bereitstellen kann, muss innerhalb des Solaris-Systems ein minimales Runtime-Modul laufen. Nötig ist dies, weil innerhalb der über die Architekturgrenzen hinweg virtualisierten Maschine auch Zustände wie der Registerstatus der emulierten CPU oder die Page-Tabelle zu verwalten sind. Die CPU in der virtuellen Maschine ist eben nicht mit der Wirts-CPU identisch, sondern unterscheidet sich hinsichtlich der Register und des Memory-Mapping. Quicktransit muss also die Semantik der Sparc-MMU auf Page-Tables des Intel-Prozessors abbilden.

Zur Verbesserung der Performance kann die emulierte Maschine auch Paravirtualisierung einsetzen. Quicktransit fängt dann die Hypervisor-Traps auf. Dabei handelt es sich um spezielle Anpassungen im Kernel des Gastsystems für die Paravirtualisierung.

Nutzwert

Wer sich an die Zeit erinnert, als bei der freien Virtualisierungslösung Qemu das Kernelmodul »kqemu« noch nicht existierte, hat einen groben Eindruck von den Geschwindigkeitseinbußen bei nicht direkt an die Wirts-CPU weitergereichten Maschinenbefehlen. Quicktransit ist daher keine Breitenlösung für gewöhnliche Virtualisierungs-Szenarien, sondern nur in speziellen Anwendungsfällen nützlich. Die Transitive-Webseite nennt hier den schnellen Umzug noch gebrauchter Solaris-Anwendungen von veralteter Risc-Hardware auf x86-Linux-Server. Oft sind Performance-Einbußen hier sekundär.

Big Blue

Ähnlich gilt dies für Power VM Lx68, das erste IBM-Produkt auf der Grundlage der Transitive-Technologie [3]. Auf leistungsstarken IBM-Power-Servern einige unverzichtbare x86-Linux-Anwendungen bereitzustellen – und sei es nur übergangsweise -, kann sich im Sinne einer Hardwarekonsolidierung lohnen. Weitere Einsatzszenarien nannte der Transitive-Mitarbeiter Paul Knowles in seinem im November 2008 auf der UKUUG (UK\’s Unix and Open Systems User Group) gehaltenen Vortrag: plattformübergreifende Softwartests oder das Starten von Nicht-x86-Anwendungen auf gewöhnlichen Notebooks, um sie unterwegs vorstellen zu können.