Multicore-Design: Vor- und Nachteile von Hypervisoren und Multicore-Frameworks

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Früh stehen SoC-Entwickler vor der Entscheidung, welcher Domänen-Manager sich für ihr Multicore-System besser eignet: Ist ein Hypervisor erforderlich, oder ist ein Multicore-Framework eine bessere Lösung?

Die heutige Multicore System-on-Chip-Hardware verspricht, mehr in Ihr Embedded-Systems-Projekt einpacken zu können als je zuvor. Designer müssen Softwaredomänen nicht mehr in separaten Geräten unterbringen. Multicore-Verarbeitungscluster in ein und demselben Gerät können die Stücklistenkosten senken und durch engere Domänenintegration zu kürzeren Entwurfszeiten beitragen. Bei diesen komplexeren Systemen bleibt es jedoch Aufgabe des Systemarchitekten und Softwaredesigners, die Anwendungsdomänen korrekt zu konfigurieren, wichtige Daten getrennt und sicher zu halten und effizient zu steuern, wie das Gesamtsystem kommunizieren soll. Eine wichtige Entscheidung, die frühzeitig getroffen werden muss: Was ist der beste Domänen-Manager für Ihr Multicore-System? Ist ein Hypervisor erforderlich oder ist ein Multicore-Framework eine bessere Lösung

Design von asymmetrischen Multicore-Systemen

In einem Multicore-SoC-System führt die Erleichterung der funktionalen Segmentierung eines Projekts dazu, dass Designs als asymmetrische Multiprocessing-Systeme (AMP-Systeme) konfiguriert werden. Ein AMP-System kann aus einer beliebigen Kombination von CPU-Architekturen aufgebaut werden; alle CPU-Kerne können identisch sein (homogen), oder es kann eine Mischung von verschiedenen Kerntypen geben, die konventionelle Verarbeitungseinheiten sowie spezialisierte Kerne wie z.B. digitale Signalprozessoren umfasst (heterogen). Jeder CPU Kern läuft unabhängig in einer AMP-Architektur, mit oder ohne Betriebssystem. Das OS jedes Kerns kann auf der Grundlage der erforderlichen Funktionalität ausgewählt werden. AMP hat jedoch spezielle Herausforderungen:

• Höchstwahrscheinlich ist eine Einrichtung für die Kommunikation zwischen den Kernen erforderlich;

• Es kann Sicherheitsprobleme geben, die einen Schutz der Kerne gegeneinander erfordern;

• Die Bootreihenfolge – die Reihenfolge, in der die jeweilige Software auf den Kernen startet – kann wichtig sein, um Synchronisierungs- und Sicherheitsprobleme zu vermeiden; und

• Das Debuggen der unterschiedlichen Arbeitslasten, die auf den potenziell heterogenen Kernen laufen, kann ebenfalls eine große Herausforderung darstellen.

Obwohl die Kerne in einem AMP-System unabhängig sind, legen es diese Herausforderungen nahe, dass eine allgemeine Steuerungseinrichtung erforderlich ist.Im Großen und Ganzen gibt es zwei Möglichkeiten: Die Wahl eines Hypervisors , einer Softwarekomponente, die über alle Kerne läuft; oder ein Multicore-Framework , das es ermöglicht, AMP-Systeme zu steuern, die auf jedem CPU Kern laufen.

Es können zwar prinzipiell auch Multicore-Anwendungen mit einem Betriebssystem implementiert werden können, das zu symmetrischem Multiprocessing (SMP) fähig ist. Dieser Ansatz lässt aber nur bedingt unabhängige Arbeitslast auf verschiedenen Kernen zu und unterstützt auch nicht heterogene CPU-Kerne.

Vor- und Nachteile von Hypervisoren

Ein Hypervisor ist eine relativ komplexe, vielseitige Softwarekomponente, die eine Überwachungsfunktion für eine Reihe von Betriebssystemen bietet und CPU-Zugriff, peripheren Zugriff, Inter-OS-Kommunikation und Inter-OS-Sicherheit verwaltet. Ein Hypervisor kann auf verschiedene Weise eingesetzt werden. So können zum Beispiel mehrere Betriebssysteme auf einer einzigen CPU laufen, um eine Investition in ältere Software zu schützen. Mit der zunehmenden Verwendung von Multicore-Prozessoren wird dies jedoch immer seltener.

Alternativ können Hypervisoren in eingebetteten Anwendungen in AMP-Designs eingesetzt werden, bei denen eine Überwachung der Inter-Core-Kommunikation und die Zuweisung von Peripheriegeräten zu bestimmten Kernen erforderlich ist. Ein Hypervisor kann zusätzlich die Bootsequenz übernehmen und den gemeinsamen peripheren Zugriff verwalten. Einer der Hauptvorteile eines Hypervisors besteht darin, dass ein Absturz eines Betriebssystems die Ausführung von Workloads auf anderen Kernen nicht beeinträchtigt und dass der Hypervisor in einigen Fällen sogar das Betriebssystem neu starten kann, ohne dass ein Neustart des Geräts erforderlich ist. Natürlich ist es sehr empfehlenswert, einen Hypervisor zu verwenden, der speziell für den Einsatz in eingebetteten Anwendungen entwickelt wurde, um eine bessere Leistung zu erzielen.

Obwohl es möglich ist, einen Hypervisor zu entwickeln, der alle erforderlichen Separations- und Virtualisierungsfunktionen in der Software ermöglicht, ist dies heutzutage recht schwierig und ungewöhnlich. Heutzutage sind Hypervisoren vielmehr so konzipiert, dass sie die zugrundeliegenden Virtualisierungsfunktionen der meisten Multicore-Prozessoren nutzen.

Zu den Vorteilen zählen eine hohe Flexibilität ermöglicht effizienten Ressourcenaustausch, dynamische Ressourcennutzung, geringe Latenz und hohe Bandbreite zwischen VMs und eine starke Kerntrennung. Ein Hypervisor-Einsatz ermöglicht zudem die Virtualisierung und Freigabe von Geräten. Schließlich bietet er die Fähigkeit, bestimmten CPU Kernen die exklusive Kontrolle von Peripheriegeräten zuzuordnen

Allerdings birgt der Einsatz auch einige Nachteile. Ein Hypervisor funktioniert nur bei einem homogenen Multicore-Gerät gut (das heißt, wenn alle Kerne identisch sind). Hypervisor-Code besitzt zudem einen signifikanten Umfang des Codes und verursacht merklichen Overhead bei der Ausführung. Zudem wird eine Hardware-Virtualisierung im Prozessor erforderlich.

Hypervisoren haben aufgrund ihrer Trenn-, Management- und Sharing-Fähigkeiten viel mehr Funktionen als viele eingebettete Designs verlangen – sie können zu viel des Guten sein. Daher haben einige Anbieter von eingebetteten Runtime-Systemen eine Alternative entwickelt, die speziell für AMP-Multicore-Systeme entwickelt wurde: das Multicore-Framework.

Vor- und Nachteile von Multicore-Frameworks

Frameworks wurden speziell für die Multicore-Anwendung entwickelt und bieten nur die wichtigsten Funktionen: Steuerung der Boot-Reihenfolge und Inter-Core-Kommunikation. Dies hat zur Folge, dass ein Framework ein System mit viel geringerem Overhead lädt und auf wesentlich einfacheren Systemen betrieben werden kann. Obwohl jeder Kern in einem AMP-Design wahrscheinlich ein Betriebssystem betreibt, können ein oder mehrere Kerne „bare Metall“ sein – d. h. betreiben überhaupt kein Betriebssystem. Ein Multicore-Framework kann dieser Möglichkeit gerecht werden.

Sobald das Remote-Prozessor-Betriebssystem und der Anwendungsstapel in Betrieb sind, erfordern viele Anwendungsfälle die Kommunikation mit anderen Teilen des Systems. Das Mentor Embedded Multicore Framework bietet eine Reinraum-Implementierung des von Linux bekannten rpmsg-Pakets zur Einrichtung eines Kommunikationskanals zwischen dem Master-Betriebssystem und den Remote-Betriebssystemen. So können Daten in einem prozessor-übergreifenden Kommunikationskanal zwischen beiden hin und her übertragen werden.

Die Transportschicht, die sowohl Remote Processor Lifecycle Management als auch Inter-Prozessor-Kommunikation ermöglicht, ist VirtIO. VirtIO ist ein Virtualisierungsstandard für Treiber von Hochleistungs-Eingabe-/Ausgabegeräten, der in virtuellen Linux-Umgebungen weit verbreitet ist.

Die Kontrolle über einen Remote-Prozessor anzunehmen und dann ein OS und/oder einen Anwendungsstapel innerhalb dieses Remote-Prozessors zu starten oder zu stoppen, wird als Remote-Prozessor-Lifecycle-Management (RemoteProc) bezeichnet. Die Linux-Community hat ein Remote Processor-Framework zur Verwaltung dieses Falles eingeführt. Remoteproc ermöglicht einem Master-Betriebssystem, andere Betriebssysteme auf anderen Kernen aufzurufen.

Die Remote Proc-Funktion im Mentor Embedded Multicore Framework ermöglicht die Remote-Prozessor-Interoperabilität zwischen Mentor Embedded Linux, Nucleus RTOS und Bare Metal Environments (BME) sowie Linux- und RTOS-Produkten anderer Anbieter. Ein wesentlicher Vorteil des Remote Processor Lifecycle Managements ist der geringere Stromverbrauch. Der Remote-Kern bleibt bei Nichtgebrauch im Niedrigverbrauchszustand. Erst wenn remoteproc verwendet wird, um den Remote-Kern aufzurufen und die erforderliche Firmware bereitzustellen, verbraucht der Remote-Core in nennenswertem Umfang Strom.

Ein Multicore-Framework bietet die minimal erforderliche Funktionalität für einige Anwendungen, was einen signifikanten Vorzug darstellt. Weiter Vorteile sind ein (gerade im Vergleich zu Hypervisoren) feringerer Speicherverbrauch und ein minimaler Durchlaufzeit-Overhead. Zudem kann ein Multicore-Framework auch mit heterogenen Multicore-Geräten arbeiten (d. h. nicht alle Kerne müssen identisch sein) und bietet eine Unterstützung von Anwendungen mit „bare metal“.

Dem gegenüber steht als Nachteil, dass die Arbeitslasten der Kerne sind nicht voneinander isoliert sind. Es kann außerdem schwieriger sein, die Boot-Reihenfolge zu steuern und zu debuggen.

Gemischte sicherheitskritische Systeme

Ein gemischtes sicherheitskritisches System ist ein System, das die Ausführung mehrerer Anwendungen mit unterschiedlichen Sicherheitsintegritätsstufen (SIL) oder unterschiedlichen Kritikalitäten, wie z. B. sicherheitskritisch und nicht sicherheitskritisch, auf einem einzigen MPSoC erfordert. Sowohl ein Hypervisor als auch ein Multicore-Framework können diese Art von Konfiguration unterstützen.

Dazu zertifiziert ein Hypervisor den Hypervisor selbst. Die virtuellen Maschinen können dann mit dem zertifizierten Hypervisor unterschiedliche Kritikalitätsstufen aufweisen. Die Trennung erfolgt durch den zertifizierten Hypervisor, der in der Regel zugrunde liegende Hardware-Virtualisierungs- und Separationsfunktionen auf dem SoC verwendet.

Ein Multicore-Framework nutzt andere hardwaregestützte Trennungsfunktionen, die von einigen SoC-Architekturen bereitgestellt werden, um die erforderliche Trennung zwischen der sicheren Domäne und der nicht sicheren Domäne zu erreichen. Dies umfasst die Trennung von Verarbeitungsblöcken, Speicherblöcken, Peripheriegeräten und Systemfunktionen. Das Multicore Framework bietet erweiterte gebundene Überprüfungen, um die Integrität von Datenstrukturen mit gemeinsamem Speicher sicherzustellen. Es bietet auch Interrupt-Drosseln und Polling-Modus, um Interrupt-Flooding zu verhindern. Es ist sogar möglich, einen nicht sicherheitszertifizierten Hypervisor zusammen mit einem gemischten kritikalitätsaktivierten Multicore-Rahmen zu verwenden, wie in Bild 2 zu sehen ist.

Hypervisoren in Embedded-Systemen sicher und fehlerfrei einsetzen

OpenAMP – Ein Open Source Framework für asymmetrisches Multiprocessing

Multicore-Determinismus für sicherheitskritische Anwendungen

Schlussfolgerungen

Die Wahl zwischen einen Hypervisor oder ein Multicore-Framework für die Steuerung und Verwaltung eines Multicore-Systems ist eine kritische Architekturentscheidung. Die endgültige Wahl hängt von den spezifischen Anwendungsanforderungen und dem Anwendungsfall des Geräts ab. Die Optionen sollten als ergänzende Lösungen betrachtet werden, die die Macht eines Multi-Core-SoC freisetzen können, die Verwaltung der verschiedenen Projektdomänen ermöglichen und es dem Konstrukteur letztendlich ermöglichen, sich auf die einzigartigen Stärken des Projekts zu konzentrieren.

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 19/2020 (Download PDF)

* Jeff Hancock ist Senior Product Manager, Embedded Platform Solutions, bei Mentor, a Siemens business.

(ID:46883323)