Virtual 8086 Mode
Der Betriebsmodus Virtual 8086 Mode – kurz VM86 – wurde mit dem 80386-Prozessor von Intel im Jahr 1985 eingeführt. Da sich zu dieser Zeit Protected-Mode-Betriebssysteme noch nicht am Markt gegen das Real-Mode-Betriebssystem DOS durchgesetzt hatten, wurde mit dem Virtual 8086 Mode die Möglichkeit geschaffen, innerhalb eines Protected-Mode-Betriebssystems Real-Mode-Programme (also vor allem DOS-Programme) auszuführen, ohne die Protected-Mode-Umgebung zu verlassen.
Bekanntestes Beispiel hierfür ist die so genannte MS-DOS-Eingabeaufforderung, die ab Windows 3.0 existierte.
Nutzung
[Bearbeiten | Quelltext bearbeiten]Im Protected Mode können mehrere Programme – so genannte Tasks – quasi parallel ablaufen. Für jeden dieser Tasks kann über ein bestimmtes Bit im Statusregister festgelegt werden, ob er ein VM86-Task sein soll.
Im Virtual-8086-Modus verhält sich der Prozessor aus Programmsicht wie ein Prozessor im Real Mode. Es ist für ein Programm aber leicht feststellbar, ob es im Real Mode oder im VM86 Mode läuft. Jedem VM86-Task stehen maximal ein Mebibyte Arbeitsspeicher zur Verfügung. Dies muss jedoch – im Gegensatz zum Real Mode – nicht das erste Mebibyte im physischen Speicher sein, da die Protected-Mode-Umgebung im Hintergrund automatisch eine Umsetzung der virtuellen Adressen in physische Adressen vornimmt.
Da ein VM86-Task in der Regel unprivilegiert läuft, hat er nur eingeschränkte Zugriffsrechte auf die Hardware oder bestimmte CPU-Register. Dies ist notwendig, da sonst ein Programm im VM86-Modus das Protected-Mode-Betriebssystem und somit den Speicherschutz umgehen könnte. Jeder Hardwarezugriff, den ein VM86-Task tätigt, wird daher vom Prozessor abgefangen und als Ausnahmesituation (englisch Exception) an das Protected-Mode-Betriebssystem gemeldet, welches dann entweder das Verhalten der Hardware nachbilden (simulieren) muss, oder bei unerlaubtem Zugriff den VM86-Task und das in ihm laufende Programm beendet. Da unter DOS solche direkten Hardwarezugriffe recht häufig vorkommen, stellt dies an das Betriebssystem große Anforderungen, da eine Vielzahl an Hardwareverhalten nachgebildet werden muss. Da das Abfangen und Simulieren der Hardwarezugriffe außerdem meist langsamer ist als der direkte Hardwarezugriff, laufen viele DOS-Programme im VM86-Modus spürbar langsamer als im „echten“ Real Mode.
Der VM86-Modus wurde jedoch nicht nur für diverse DOS-Fenster z. B. unter Windows („Eingabeaufforderung“), OS/2 („DOS-Modus“), Linux (über das Programm DOSEMU) benutzt, sondern auch von DOS selbst. Der Speichertreiber EMM386.EXE von MS-DOS schaltete – vom Benutzer meist unbemerkt – in den Protected Mode, um Zugriff auf den Speicher jenseits der 1-Mebibyte-Grenze zu bekommen. Anschließend startete er einen VM86-Task, in den das bereits laufende DOS dann verlegt wurde. EMM386.EXE benutzte die ebenfalls ab dem 80386er verfügbare Paging-Technik, um den DOS-Programmen mehr Speicher zur Verfügung zu stellen, indem es Speicher von jenseits der 1-Mebibyte-Grenze in den DOS-Adressraum einblendete (Expanded Memory, EMS). Solche Speichermanager existieren auch für die anderen MS-DOS-kompatiblen Betriebssysteme. Sie heißen dort anders, aber ihre prinzipielle Arbeitsweise ist identisch.
Verbesserter Virtual 8086 Mode
[Bearbeiten | Quelltext bearbeiten]Als Virtual 8086 mode enhancements,[1] kurz VME (Virtual Mode Extensions), kamen bei späteren 80486-Modellen und beim Pentium weitere Features für den VM86-Modus hinzu, die es erlauben, dass bestimmte Interrupt-Serviceroutinen komplett im VM86-Modus abgearbeitet werden können, ohne dass aufwändige Taskwechsel in das Protected-Mode-Betriebssystem erfolgen müssen. Dies ermöglicht eine Ausführungsgeschwindigkeit, die dem echten Real Mode sehr nahekommt, vor allem, da unter DOS Software-Interrupts sehr häufig sind, wo sie als Aufruf ins Betriebssystem und von BIOS-Routinen benutzt werden.
Mit dem in x86-Prozessoren ab späteren 80486 CPUs verfügbaren CPUID-Funktionsaufruf lässt sich auslesen, ob ein Prozessor die verbesserten Virtual Mode Extensions bietet. Dazu muss in Register EAX der Wert 1H stehen, wenn die CPUID-Funktion ausgeführt wird. In Register EDX findet sich anschließend im zweiten Bit (Bit 1) die Information über die Verfügbarkeit von VME.[1]
Bei vielen Betriebssystemen lassen sich die CPUID-Informationen relativ einfach auslesen. Unter Linux z. B. reicht es, sich den Inhalt von /proc/cpuinfo anzeigen zu lassen. In der Zeile „flags“ findet sich vme, wenn der verbesserte VM86-Modus vorhanden ist. Beispiel (Prozessor: Pentium II):
$ cat /proc/cpuinfo | grep -m 1 -e "flags" flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr up
Auf einigen BSD-Systemen werden die Flags als „Features“ bei den Textmeldungen beim Systemstart ausgegeben, die auch mit dmesg auf einem laufenden System angezeigt werden können. Auch das Programm dmidecode kann bei geeigneten Systemen (DMI steht für Desktop Management Interface) die CPU-Flags ausgeben.
AMD Ryzen
[Bearbeiten | Quelltext bearbeiten]Beim AMD-Ryzen-Prozessor (Mitte 2017) ist die Implementierung der Virtual Mode Extensions (VME) fehlerhaft, so dass Software, die diese Erweiterung benutzt, nicht stabil lief. Da der Virtual-8086-Modus nur im 32-Bit-Betriebsmodus verfügbar ist, betraf der Fehler nur 32-Bit-Betriebssysteme – allerdings auch dann, wenn diese virtualisiert ausgeführt wurden. Der Hardwarefehler kann meist in Virtuellen Maschinen, etwa VirtualBox, umgangen werden, indem die Unterstützung für VME per CPUID für das Gastsystem deaktiviert wird. Mit der Aktualisierung auf AGESA-Version 1.0.0.6 von Ende 2017 wurde der VME-Bug von AMD per Microcode-Update behoben.[2]
Bedeutung auf 64-Bit-x86-Systemen „x64“
[Bearbeiten | Quelltext bearbeiten]Mit der schwindenden Bedeutung des Betriebssystems DOS ist auch der VM86-Modus nunmehr eher als historisch anzusehen und wird daher kaum noch verwendet, auch wenn er in jedem aktuellen x86-kompatiblen Prozessor noch im 32-Bit-Modus (ab „Intel Architekture 32-Bit“, kurz IA-32) verfügbar ist. Auf einem 64-Bit-x86-System „x64“ (eine Erweiterung der IA-32) gibt es zwar einen „Compatibility Mode“, der verwendet wird, um 16-Bit-Protected-Mode- oder 32-Bit-Programme auf einem 64-Bit-Betriebssystem auszuführen, jedoch fehlt darin der Virtual86 Mode. Abhilfe schaffen Emulatoren wie z. B. DOSBox, die ein 8086-kompatibles System mit PC-typischer Hardwareumgebung komplett in Software nachbilden.
Jeder 64-Bit-x86-Prozessor „x64“ bietet mit dem „Legacy Mode“ vollwertiges 32-Bit-x86, oder anders ausgedrückt: Jeder x64-Prozessor ist auch ein vollwertiger 32-Bit-x86-Prozessor („IA-32“). Läuft darauf ein 32-Bit-Betriebssystem, so ist normalerweise auch der verbesserte VM86-Modus „VME“ weiterhin verfügbar. Auch unter einem 64-Bit-Betriebssystem kann in einer virtuellen Maschine der 32-Bit-Legacy-Mode, inklusive VME, verwendet werden. Beispielsweise kann ein auf einem 64-Bit-Betriebssystem, das im 64-Bit-Modus läuft, virtualisiert ausgeführtes 32-Bit-Betriebssystem alle im Legacy Mode vorhandenen Funktionen nutzen, und damit auch VME, wenn dieses per CPUID angezeigt ist.
In 64-Bit-Umgebungen spielt der Real Mode, und damit auch der Virtual 8086 Mode bzw. VME, keine Rolle mehr.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Virtual Mode Extensions on the Pentium Processor, Robert Collins, Jim Brooks (englisch)
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ a b Julio Sanchez, Maria P. Canton: Software Solutions for Engineers and Scientists. CRC Press, 2018, ISBN 978-1-4200-4303-7, S. 75 (englisch, Volltext in der Google-Buchsuche): “EDX = feature information: Bit 1: Virtual 8086 mode enhancements”
- ↑ Christof Windeck: AMD Ryzen: Kommende BIOS-Updates patchen auch „VME-Bug“. In: Heise online. 1. Juni 2017. Abgerufen am 7. Juli 2017.