Xen-Hypervisor auf den ARM-Cores der Xilinx-MPSoC-Bausteine nutzen

Bei einem Hypervisor handelt es sich um eine Software-Schicht, die unterhalb des Betriebssystem angesiedelt ist und die Hardware virtualisiert (VMM, Virtual Machine Monitor). Ähnlich wie ein Betriebssystem (OS, Operating System) simultan laufende Applikationen verwaltet, von denen jede in einem Prozess mit Zugriff auf die Maschinen-Ressourcen enthalten ist, verwaltet der Hypervisor simultan laufende Betriebssysteme auf einer virtuellen Maschine, mit Zugriff auf deren Ressourcen.

Anders als ein OS implementiert ein Hypervisor keine Services wie Dateisysteme, graphische Benutzer-Schnittstellen oder Netzwerk-Protokoll-Stacks, diese delegiert er an die höheren Layer, etwa ein Gast-OS auf einer der vom Hypervisor gehosteten virtualisierten Maschinen. Der Hypervisor fokussiert auf die grundlegenden Management-Aufgaben. Läuft er selbst auf nativer Hardware, wie oben beschrieben, dann handelt es sich um einen Typ-1-Hypervisor. Im Unterschied dazu läuft ein Typ-2-Hypervisor selbst als Applikation innerhalb eines Betriebssystems.

Embedded-Hypervisor

Virtualisierung und Hypervisor sind in der IT seit den 1960er Jahren bekannt. Dank der immer weiter gestiegenen Leistung von Embedded-Prozessoren und Mikrocontrollern verbreiten sich inzwischen auch eingebettete Hypervisor-Systeme: mit ihnen lassen sich komplexe Funktionen in eine einzige Rechnerplattform konsolidieren, wobei die einzelnen OS-Instanzen eine gewisse Separierung erhalten.

In Aerospace-Applikationen dient ein Hypervisor oft zur Konsolidierung integrierter Avionik-Module in einer einzigen Plattform – wie Flight Control, Navigation, Flight Management, Collision Avoidance und mehr. Im Gesundheitswesen erwägt man den Hypervisor-Einsatz in der High-End-Medizin, etwa der roboterassistierten Chirurgie, und in MRI- und CT-Scannern mit mehreren Prozessorsystemen. Auch in automotiven Applikationen kann ein Hypervisor Dutzende eingebettete Mikrocontroller zusammenfassen – Infotainment, Fahrerassistenzsysteme (ADAS), Instrumenten-Cluster, Navigationssysteme, Internet-Konnektivität und künftige autonome Steuerungen.

Beim Abwägen von Virtualisierungslösungen ist es wichtig, die VMM-Charakteristik zu evaluieren, denn der Hypervisor kontrolliert alle Hardware-Ressourcen (CPU, Speicher, I/O) und kann deshalb deren Performance beeinflussen.

Echtzeitfragen

Entwickler von Echtzeitsystemen sind besonders an den minimalen Zeitintervallen (time-slice) interessiert, denn diese begrenzen das Scheduling der CPU-Frequenz und damit die maximal mögliche Zahl virtueller Maschinen. In Bezug auf den Speicher setzt sich der Footprint des Hypervisor-Kernels aus einem konstanten und einem inkrementellen Teil für jeden hinzugefügten Gast (virtuelle Maschine) zusammen. Dieser kumulative Footprint begrenzt ebenfalls die Zahl der virtuellen Maschinen. I/O, Bandbreite und Latenz sind die Schlüsselparameter für jede betrachtete Komponente. Zudem sind Abschätzungen auf der Basis generischer Metriken, etwa der gesamten Interrupt-Latenz oder der nominalen Kommunikationsbandbreite, denkbar.

Viele Hypervisoren unterstützen zwei Vorgehensweisen in Bezug auf I/O: exklusiv oder geteilt. Die exklusive Methode führt zu geringerem Overhead. Dabei bietet der Hypervisor eine virtuelle Maschine mit direktem und exklusivem Zugriff auf eine bestimmte, oft als Passthrough bezeichnete I/O-Komponente. Geteiltes I/O bedingt einen etwas größeren Overhead, denn der Hypervisor muss die Teilung aufrechterhalten.

Xen-Mapping für Zynq

Das Ultrascale+-MPSoC Zynq von Xilinx ist eine sehr leistungsfähige Plattform für den Xen-Hypervisor. Der Baustein enthält einen Quad-Core-Cortex-A53 mit einer Erweiterung zur Hardware-Virtualisierung. Dieser CPU-Kern ist 64-Bit-fähig und versteht den ARMv8-Befehlssatz. Xilinx hat den Open-Source-Hypervisor Xen gewählt und das Unternehmen Dornerworks mit dem Support für Xen Zynq beauftragt.

Der Xen-Hypervisor hostet Gast-Betriebssysteme innerhalb virtueller Maschinen, mit virtualisierter Perspektive der grundlegenden Maschine. Gast-OS und deren Applikationen nutzen die virtualisierte CPU, Speicher und I/O, während Xen das Mapping der virtualisierten Ressourcen auf die physikalischen Ressourcen übernimmt. Xen bezeichnet jede virtuelle Maschine als Domain. Um den Hypervisor-Kernel so klein wie möglich zu halten, weist Xen den Domains spezielle Privilegien zu. Die System-Domain heißt „dom0“. Sie startet die Gast-Domains „domU“, konfiguriert das Scheduling und das Speicher-Mapping, das der Kernel durchführt, und verwaltet den I/O-Zugriff.

Zum Hypervisor-Environment gehören Bootsequenz, ARM Exception-Level, Running-Schedule und Ressource-Management. Nach dem Einschalten lässt sich die Bootsequenz des Zynq MPSoC unterschiedlich konfigurieren, einschließlich der Vorgabe, welcher Prozessor (Cortex-A53 oder Cortex-R5) zuerst starten soll. In den meisten Anwendungen dürften beide Prozessoren relativ unabhängig arbeiten. Deshalb läuft die Xen Zynq Hypervisor Distribution nur auf dem Cortex-A53.

Bild 1: Typische Xen-Bootsequenz auf Zynq-MPSoC mit stufenweisem Anlauf des Gast-OS. Xilinx

Bootsequenz

Bild 1 zeigt eine typische Bootsequenz. Wird der Cortex-R5 als Host eines unabhängigen, nicht virtualisierten, sicheren OS eingesetzt, würde dieser als erster CPU-Kern booten, und zwar von einem einfachen First-Stage-Boot-Loader (FSBL). Danach initiiert er den A53 mit dessen eigenem FSBL.

An diesem Punkt tritt der Xen-Hypervisor-Kernel in Aktion. Beim Initialisieren des Kernels prüft er auch auf eine gültige Dom0. Anschließend checkt Dom0 auf valide Images für die Gastdomänen und initiiert sie auf einem oder mehreren Kernen. In den meisten Fällen läuft Dom0 als Systemmonitor weiter, um das Management geteilter Ressourcen zu ermöglichen und Systemausfälle zu verarbeiten. Der Hypervisor-Kernel kümmert sich um die Domain-Kontext-Switches und ist auch in Hypercalls involviert.

Hypercalls entsprechen den Syscalls in gewöhnlichen Betriebssystemen, mit denen eine Applikation einen OS-Service aufruft. Bei Xen geht es aber um Hypervisor-Services. Im Normalbetrieb kann Dom0 jeden Hypercall ausführen, während DomU auf bestimmte Calls beschränkt ist. Allerdings kann man mit dem Xen-Modul XSM-FLASK auch eine feinere Abstufung des Hypercall-Zugriffs implementieren.

Bild 2: Diagramm der ARM-Exception-Levels mit Hypervisor-Mapping auf Exception-Level 2. Xilinx

Privilegien

Die Prozessorhardware legt die Privilegien innerhalb der laut ARM-Exception-Level definierten Kategorien fest. Der Cortex-A53 verwendet die ARMv8-Architektur mit vier Exception-Levels. In Bild 2 sind die höchsten Privilegien dem unteren Level zugeordnet. Vollständige Zugriffsprivilegien gelten für den Exception-Level EL3 im ARM Trustzone-Monitor. Die Hypervisors befinden sich auf EL2, um die Virtualisierung der Gast-Domains zu ermöglichen.

Das gehostete Betriebssystem jeder gehosteten virtuellen Maschine läuft auf EL1, die Anwendersysteme mit dem niedrigsten Privileg auf EL0. Beim Übergang auf einen Exception-Level mit niedrigerem Privileg müssen die virtualisierten Register der Maschine dieselbe Breite haben oder enger sein. Man kann also einen 64-Bit-Hypervisor mit 32-Bit-Gast betreiben, aber nicht umgekehrt. Xen Zynq verwendet den AArch64 Execution-Mode der ARMv8-Architektur, somit unterstützt er 64-Bit- und 32-Bit-Gäste.

Bild 3: Multicore Scheduling mit Gast 1 in exklusivem Time Slot und Mischung von Gast 2 und 3. Xilinx

Die privilegierte Domäne Dom0 bestimmt das Scheduling, also auch, wann die Domains auf welchem Kern (oder welchen Kernen) laufen. Der Hypervisor-Kernel führt dann das konfigurierte Scheduling aus. Für bestimmte deterministische Betriebsarten kann man ein Scheduling konfigurieren, in dem eine Gast-Domain in ihrem Zeitschlitz alleinigen Zugriff auf die Maschine hat. Bild 3 zeigt ein Beispiel, in dem Gast 1 auf mehreren Kernen (zusammen mit Dom0) in nur einem Zeitschlitz läuft. Die Gäste 2 und 3 benötigen diese Einschränkung nicht, sodass sie in einem gemischten Load-Balancing-Schema auch in anderen Timeslots angelegt werden können.

I/O verwalten

Der Hypervisor verwaltet alle Ressourcen der Maschine. Der Speicherplatz wird nicht zeitlich geteilt, sondern durch gesonderte Bereiche für jede Gast-Domain. Für einige I/O-Komponenten gilt direktes Mapping auf den Cortex-A53, während andere per FPGA-Programmierung konfiguriert werden.

Gast-Zugriff auf I/O-Komponenten wird durch Dom0 konfiguriert und verwaltet, mit den passenden Hypercalls zum Xen-Kernel, um das Memory-Mapping der Komponenten zu erstellen. Dom0 kann einer Gastdomäne bei Bedarf Zugriff auf spezifische I/O-Komponenten erlauben oder den geteilten I/O-Zugriff selbst verwalten. Sie agiert also als Gateway, um einen Teilungsmechanismus zu gewährleisten. Die Inter-Domain-Kommunikation in Xen (einschließlich I/O) nutzt dabei meist die Event-Kanäle für Benachrichtigungen und geteilte Speicher für die durchlaufenden Daten.

Device-Treiber für geteilte I/O-Ressourcen in Xen verwenden ein Split-Driver-Modell. Dabei liefert die obere Hälfte der Gast-Domains die API an das Gast-OS, sowie die Funktionalität zur Datenweiterleitung von und zur Dom0. Die untere Hälfte des Treibers in Dom0 führt die anstehenden I/O-Operationen der Komponente aus.

Support

Anwender-Feedback über das angekündigte Zynq-SoC hat Xilinx zu ausführlichem Support für den Hypervisor veranlasst, einschließlich der Open-Source-Option. Der Support umfasst auch die Unterstützung beim Design eingebetteter Systeme, einschließlich der Anforderungen an hohe Bandbreite, geringe Latenz, geringe Leistungsaufnahme und hohe Zuverlässigkeit, außerdem die Konnektivität mit einer Vielzahl von Systembausteinen.

Dornerworks hat bei der Gestaltung des Xen-Ports für das Zynq-MPSoC eng mit Xilinx zusammengearbeitet und die Lösung verifiziert und evaluiert. Der Test betraf nicht nur den Hypervisor-Kernel, sondern auch die privilegierten Dom0-Domain (unter Linux) und die Gast-Domains mit einer Vielzahl von Betriebssystemen. Die Xen-Zynq-Distribution steht online zum Download bereit.

Bild 4: Typische Cross-Entwicklungsumgebung für Xen-basierte Embedded-Systeme auf Xilinx MPSoC. Xilinx

Beim Test nutzte Dornerworks die Open-Source-Emulatorsoftware QEMU auf einem x86-Entwicklungssystem. Außerdem haben die Spezialisten das Emulation-Board Remus entwickelt – nicht zu verwechseln mit dem gleichnamigen Xen-Migration-Tool mit sechs Xilinx Virtex-7 FPGAs zur Zynq-Emulation. Dornerworks bietet eine Infrastruktur mit umfassendem Support des Xen-Hypervisor auf dem Zynq-MPSoC. Hinzu kommt die Unterstützung der Open-Source-Community.

Experimentieren mit Xen

Zum ersten Experimentieren mit Xen benötigt man eine emulierte oder reale ARM-Hardware, also einen ARM-Prozessor mit Virtualization-Extensions, idealerweise einen Cortex-A53. Doch auch andere Typen wie Cortex-A15 bieten eine angemessene Umgebung. Bild 4 zeigt den Workflow für ein Hypervisor-basiertes System mit Embedded-Target. Weitere Hinweise finden sich unter www.xenproject.org, mit Angaben zum Aufbau eines Linux-Image für Dom0 und einer Vielzahl von Gast-OS-Images.

(lei)