Die Ausgangsbasis für das folgende Beispiel bildet ein Legacy-System aus 64-Bit-Code, kombiniert mit einigen 32-Bit-Anwendungen und Treibern. Aufgrund vorliegender Tests ist davon auszugehen, dass ein System mit zwei vCPUs die Leistungsanforderungen auf der neuen Hardware erfüllen würde. Zudem ist eine PCI-Schnittstelle für den Treiber eines speziellen PCI-Hardwaregeräts nötig. Darüber hinaus wird eine Reihe zusammenhängender Blöcke für das blockbasierte proprietäre Dateisystem benötigt.
Wechsel zu neuer Hardware, ohne die bestehenden Verbindungen zu unterbrechen
Hypervision auf neuer Hardware heißt das Motto: Empfehlenswert ist es, einem RTOS-Gast zwei vCPUs zur Verfügung zu stellen. Der spezielle Treiber soll nur das PCI-Gerät sehen, das für den Gast konfiguriert wurde. Nach Initialisierung und Einrichtung über SMMU erfolgt der Treiberzugriff direkt auf die Hardware. Während ein serieller Treiber als pass-through konfiguriert ist, könnte das Dateisystem entweder pass-through oder virtualisiert sein. Da im konkreten Fall ein blockbasiertes Dateisystem vorliegt, kann ihm eine Raw-Partition auf einer gemeinsamen Festplatte zugeordnet werden.
Kostenreduzierung durch gemeinsame Nutzung von Peripheriegeräten in verschiedenen Einsatzumgebungen
So lassen sich Geräte in der Hypervisor-Hostdomäne freigeben: Neue Dienste könnten bei einem neuen Gast platziert werden, aber der Einfachheit halber ist es empfehlenswert, alles kritische bezüglich Echtzeit und Boot-Zeit in der Host-Domäne zu verorten. Netzwerk und USB sollten zum Host hinzugefügt werden, ebenso wie Anwendungen in der Host-Domäne, die dessen Fähigkeiten erweitern, zum Beispiel in Form von Echtzeitverarbeitung, Backups, Netzwerk-Updates. Eine Voraussetzung für reibungslose Prozesse liefert die gemeinsame Nutzung von Dateisystem-Hardware zwischen Gast und Host.
Schnelle Bootzeiten, Echtzeitreaktionen und deterministisches Verhalten auch in neuen Betriebssystemumgebungen aufrechterhalten
Ratsam ist es, Dienste im Gast hinzuzufügen, um die neuen Backend-Dienste im Host zu nutzen. Beispiel: Ein neuer TCP-Stack im Gast lässt sich ohne Weiteres hinzufügen, wenngleich kein Legacy-Hardware-Treiber vorhanden ist. Daher empfiehlt es sich, einen VirtIO-Treiber im Gast hinzuzufügen und über den Host-Stack eine Brücke zur Außenwelt einzurichten. Außerdem könnte ein benutzerdefiniertes ‚Emulated Device‘ (memory-mapped und interruptgesteuert) erstellt werden, um mit einem neuen Backend-Dienst im Host zu kommunizieren. Erforderlich ist dann eine neue Dienstanwendung im Gast, die das emulierte Gerät verwendet.
Innovation mit fortschrittlichen Funktionen von Android und Linux
Eine schnellere Unterstützung neuer Android/Linux-Versionen ist heutzutage besonders relevant. Um den Funktionsumfang zu optimieren, empfiehlt es sich, Grafik-, Audio- und Touch-Treiber zum Host ebenso wie einen Linux- bzw. Android-Gast hinzuzufügen. Daran knüpft auch eine VirtIO-basierte Freigabe des Gasts an, die in der Standard-Android/Linux-Distribution bereitgestellt wird. Den Gastanwendungen fehlt jegliche Kenntnis von der Freigabe, die unterhalb stattfindet. Außerdem sollte sichergestellt sein, dass das System Multiple Display Sharing (Layer) sowie Surface Sharing auf Layern unterstützt. Der Linux/Android-Gast selbst muss keinen Direktkontakt zur Hardware haben.
Unterstützung aller obengenannten Punkte bei gleichzeitiger Wahrung von funktionaler Sicherheit und Cybersecurity
Funktionale Sicherheit, sprich Safety und Cybersecurity sind heutzutage von hoher Wichtigkeit. Ein stabiles und sicheres Fundament ist das A und O: Der QNX Hypervisor for Safety ist sicherheitszertifiziert nach IEC 61508 SIL 3 und ISO 262626 ASIL D. Die Lösung umfasst libc, libm (mathematische Funktionen), SMMU-Unterstützung, den Hypervisor selbst und virtuelle Geräteschnittstellen. Zudem ist eine Reihe von Sicherheitsvorkehrungen im QNX Hypervisor integriert, darunter Zugriffskontrolllisten, obligatorische Zugriffskontrolle, Isolierung und Separierung von Gästen. Außerdem fehlt ein ‚Root‘-Modus, der kompromittiert werden könnte.
Autor: Jörg Zimmer, Vice President EMEA Sales
BlackBerry Deutschland GmbH
Ratinger Strasse 9
40213 Düsseldorf
Telefon: +49 (211) 97199600
Telefax: +49 (211) 97199666
http://www.blackberry.com