Hardware-Virtualisierung für Embedded-Systeme
Bringt ARM die Revolution in Auto und Industrie?
Fortsetzung des Artikels von Teil 1
Virtualisierung + Echtzeitfähigkeit
Der Ansatz der Virtualisierung ist ja nicht neu. Primäres Ziel ist, eine Abstraktionsschicht zwischen Anwender (etwa einem Betriebssystem) und Ressource (etwa die Hardware, über die ein Betriebssystem üblicherweise exklusive Kontrolle hat) bereitzustellen. Diese erlaubt, andere physische Gegebenheiten vorzugeben, als tatsächlich vorhanden: Etwa kann einem Betriebssystem die Alleinnutzung einer Hardware (CPU, Peripherie, Speicher und I/O) vorgegaukelt werden, wobei es tatsächlich innerhalb eines anderen Betriebssystems als reguläres Anwendungsprogramm läuft, auf durch die Abstraktionsschicht emulierter Hardware. ARM hat bereits 2011 in einem White Paper seine Ideen zur Virtualisierung präsentiert und hat die sogenannten “Virtualization Extensions” für die ARMv7-Architektur vorgestellt.
Das Problem war bislang, dass die Virtualisierung mit einer Speicherübersetzung von virtuellen in physikalische Adressen verbunden ist, welche z.B. über TLBs (Übersetzungspuffer, Translation Lookaside Buffer) und Page-Tabellen im RAM vorgenommen werden. Dieser Mechanismus ist deswegen nicht echtzeitfähig, weil man beispielsweise nicht vorhersagen kann, ob ein TLB-Miss auftritt.
ARM implementierte daher in seiner neuen Architektur eine MPU-basierte zweistufige Umsetzung ähnlich zu dem in seinen Cortex-R-Cores implementierten MPU-Schema: Statt Page-Tabellen im RAM handelt es sich um eine registerbasierte Übersetzung, die natürlich zeitinvariant funktioniert und Determinismus sicherstellt. Die systemweit agierende MPU isoliert auch den Hypervisor und die Gast-Betriebssysteme voneinander (Bild 2, oben). Auf die erste Stufe, die als MMU wirkt und die virtuellen Adressen in sogenannte physikalische Zwischenadressen (IPA) umsetzt, haben noch jedes Gast-Betriebssystem und dessen Anwendungen Zugriff, auf Stufe 2 nur noch der Hypervisor und Gast-Betriebssysteme, denen die Stufe 1 den Durchgriff erlaubt hat (Bild 2, unten). Diese 2. Stufe setzt dann die IPAs in physikalische Adressen um. Somit ist ein physikalischer Speicherzugriff ohne “Absegnung” des Hypervisors unmöglich.
Jobangebote+ passend zum Thema
Wenn man sich den Registersatz anschaut (Bild 3), stellt man fest, dass ARM von seiner 64-bit-Architektur ARMv8 “nur” einen der beiden Modi (AArch32 für 32-bit-Kompatibilität und AArch 64 für 64-bit-Instruktionen) übernommen hat, nämlich AArch32. Dies bedeutet, dass alle 13 Allzweck-Register 32 bit breit sind, womit man Kompatibilität zu schon existierender ARMv7-R-Software sicherstellt. Dazu kommen der Stapelzeiger, der Programmzähler und das Link-Register.
Neu sind drei Register für den Hypervisor-Modus, von dene nein sogenanntes ELR-Register (Exeption Link Register) den Eintritt in den Hypervisor-Modus über Interrupts und/oder System-Fehler ermöglicht.
Auch die PMSA (Protected Memory System Architecture) der 8. Version wurde gegenüber der 7. Version, die man bei den Cortex-R-MPUs findet, verbessert. Während letztere mit 8, 12 oder 16 Regionen arbeitet, deren Größe jeweils eine Potenz von 2 sein musste und die auch nur an solchen Adressen beginnen und enden können, kann eine Speicherregion unter PMSAv8 an jeder Adresse, die ein Vielfaches von 64 Byte darstellt, beginnen und enden. Um die Kontextwechsel zu beschleunigen, besteht jetzt auch neuerdings direkter Zugriff auf die Konfigurationsregister.
- Bringt ARM die Revolution in Auto und Industrie?
- Virtualisierung + Echtzeitfähigkeit
- Von virtuellen zu realen Interrupts
- Fazit
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Quartalszahlen
ARM legt im Embedded-Bereich deutlich zu
Call for Papers
Konferenz für ARM-Systementwicklung 2014
ARM
Wachstum bei hoher Profitabiliät
