VIRTUELLE MASCHINEN IN EINEM ALLGEMEINEN TIME-SHARING-BETRIEBSSYSTEM

Vortrag auf der Jahrestagung der Gesellschaft für Informatik, Berlin, 12.10.1974

Michael Heinz

Computer Gesellschaft Konstanz mbH

Einführung

Einige wichtige Anwendungen für Rechenanlagen werden von den heutigen Maschinen und konventionellen Betriebssystemen nicht oder nur unzureichend unterstützt:

- Entwicklung und Test von Systemsoftware

- Messungen an Hardware oder Software ohne Eingriff in die Systeme

- SW-Kompatibilitätsprobleme zwischen unterschiedlichen Betriebssystemen

- Übergang von einer alten auf eine neue Betriebssystemversion

- Ausbildung von Systemprogrammierern und Operateuren

- Erweiterung und Test von Systemen für neue HW-Konfigurationen etc.

Diese Anwendungen zeichnen sich dadurch aus, dass sie eigentlich den Einsatz jeweils eigener Rechner erfordern, deren Leistung aber nur zu einem Bruchteil ausgenützt würde.

Eine Lösung bieten Betriebssysteme, die die nackte Hardware-Schnittstelle mehrfach anzubieten in der Lage sind, Systeme, die mehrere "virtuelle Maschinen" (VM) zur Verfügung stellen /1/,/2/,/3/,/4/.

VM-Technik

Unter der Technik der virtuellen Maschinen versteht man das effiziente Zurverfügungstellen der Schnittstelle der nackten Hardware einer (Ziel)-Maschine auf einer Basismaschine /5/,/6/, insbesondere das gleichzeitige Zurverfügungstellen mehrerer solcher virtueller Maschinen. "Effizient" bedeutet, dass der überwiegende Teil der Befehle der "virtuellen" Hardware direkt auf der Basis-Hardware abläuft und unterscheidet die VM-Technik von der Simulation durch Interpretation aller Befehle.

Dies erfordert eine gewisse Verwandtschaft der Hardware der gewünschten virtuellen Zielmaschine mit der Basismaschine und stellt weitere notwendige Bedingungen an die Hardware einer Maschine, die für die VM-Technik geeignet sein soll /7/,/8/.

Es gibt Ansätze für HW-Architekturen, die der VM-Technik besonders entgegenkommen /9/,/1O/,/11/,/12/, doch soll im folgenden von einer normalen HW der "dritten Generation" mit zwei Privilegierungsmodi (Supervisor-/Problem-Status) und virtueller Adressierung (Paging) ausgegangen werden. Das bedeutet, dass alle "sensitiven" Operationen /7/ (z.B. privilegierte Befehle) der virtuellen Hardware simuliert werden müssen.

Schnittstellen

Konventionelles Betriebssystem

Ein konventionelles Betriebssystem (BS) legt über die - nur einmal vorhandene - Schnittstelle der nackten Hardware (HW-SS) mehrfach für seine Prozesse eine von ihm definierte Benutzer-Schnittstelle (SW-SS) (Fig 1: die Darstellungsweise ist von Goldberg /12/,/3/ übernommen).

Ein Betriebssystem, das seinen Prozessen die gleiche Schnittstelle wie die nackte Hardware - virtuelle Maschinen - zur Verfügung stellt (Fig 2), nennt man einen VM-Monitor (VMM). Auf einer solchen virtuellen Hardware-Schnittstelle können jetzt wieder Betriebssysteme - z.B. auch ein VMM - aufsetzen.

VM-Monitor

Ein VMM hat die Aufgabe, die einzelnen Komponenten für seine virtuellen Maschinen zur Verfügung zu stellen:

- der Rechnerkern einer virtuellen Maschine entsteht durch Zuteilung des Rechnerkerns der Basismaschine zum direkten Ausführen von Befehlen bzw. zur Simulation von sensitiven Operationen der virtuellen Maschine durch den VMM.

VM-Monitor

- der Zentralspeicher einer virtuellen Maschine wird auf einen virtuellen Speicher des Basissystems abgebildet.

- ein Peripheriegerät (bzw. dessen Datenträger) einer virtuellen Maschine wird entweder direkt auf ein funktionell ähnliches Gerät der Basiskonfiguration oder auf den Hintergrundspeicher der Basismaschine abgebildet (evtl. für eine zeitlich verschobene Abbildung auf ein verwandtes Gerät: Spooling).

- das Bedienfeld einer virtuellen Maschine wird über spezielle Kommandos und Ausgaben an einem Terminal der Basiskonfiguration simuliert.

Die aufgezählten Funktionen des VMM zur Realisierung von funktionellen Abbildern der Komponenten seiner virtuellen Maschinen entsprechen den normalen Aufgaben eines Betriebssystems, nämlich der Verteilung der realen Betriebsmittel an seine Prozesse.

Bei genauer Betrachtung enthält ein VMM ein komfortables Time-Sharing-Betriebssystem (TSBS), das über die gegebene Hardware-Schnittstelle (Rechnerkern, Speicher, EA, Unterbrechungen) eine "höhere" Software-Schnittstelle (Prozesse, virtuelle Speicher, Data Management, Wartezustände) legt, die aber nur intern, jedoch nicht an den externen Schnittstellen des VMM erscheint; d.h. die virtuellen Maschinen sind Prozesse, die die Dienstleistungen eines Time-Sharing-Systems über das Format der Hardware-Schnittstelle ansprechen.

In der Vergangenheit wurde diese Eigenschaft - VMM als Time-Sharing-Betriebssystem - ausgenutzt, indem für jeden Time-Sharing-Benutzer des VMM eine virtuelle Maschine mit einem sehr einfachen Monoprogramming-Betriebssystem (MBS) /13/ vorgesehen wurde (Fig 3; die Analogie zu Fig 1 ist evident).

VM-Monitor und Monoprogramming-BS als Timesharing-BS

VM-Monitor-Prozess

Nun ist es nicht einsichtig, warum ein normaler Terminalbenutzer eine Hardware-Schnittstelle zur Verfügung gestellt bekommen soll, die er erst durch ein Betriebssystem (z.B. ein MBS) auf eine für ihn verwendbare Benutzer-Schnittstelle abbilden muss, insbesondere, wenn bereits intern eine brauchbare Software-Schnittstelle vorliegt (s. Fig 3).

Man kann anders vorgehen, von einem Time-Sharing-System ausgehen und dieses so erweitern, dass für einen Prozess wahlweise anstelle der normalen SW-Benutzer-Schnittstelle die Hardware-Schnittstelle geboten werden kann: VM-Prozess (VMP). Die Abbildung der Hardware-Schnittstelle - die der VM-Prozess sieht - auf die Software-Schnittstelle des Time-Sharing-Betriebssystems - die einzige Möglichkeit innerhalb des TSBS an Betriebsmittel heranzukommen - wird durch einen VM-Monitor-Prozess (VMMP) - einen normalen Prozess des TSBS - vorgenommen (Fig 4; vgl. mit Fig 3).

VM im Timesharing-BS

Diese Abbildung der HW-Schnittstelle einer virtuellen Maschine auf eine explizite SW-Schnittstelle eines Betriebssystems entspricht einer Typ II-selbstvirtualisierenden virtuellen Maschine nach Goldberg /5/,/4/. Es sind einige virtuelle Maschinen vom Typ II bekannt /14/,/l5/,/16/, die jedoch nicht selbstvirtualisierend sind.

SW-Anforderungen

Die Einbettung virtueller Maschinen durch VM-Prozesse (VMP) und VM-Monitor-Prozesse (VMMP) stellt zusätzliche Anforderungen an die Software-Schnittstelle des zugrundeliegenden Time-Sharing-Betriebssystems:

(1) Umleitung von synchronen Unterbrechungen des VMP - das sind die durch Befehlswirkungen direkt erzeugten Unterbrechungen wie z.B. SVC, privilegierter Befehl im nichtprivilegierten Zustand, Fehlseitenbedingung... - an den VMMP:
Diese Umleitung ist notwendig, damit der VMMP über sensitive Operationen des VMP informiert wird und ihre Wirkung simulieren kann.

(2) Lesender und schreibender Zugriff des VMMP auf den "Programmkontext" des VMP (Unterbrechungs- bzw. Fortsetzungsinformation, Register eines Prozesses):
Der Registerzugriff wird benötigt zur Simulation von Befehls- wirkungen.

(3) Lesender und schreibender Zugriff des VMMP auf den (virtuellen realen und den virtuellen virtuellen) Adressenraum des VMP:
Dieser Speicherzugriff ist erforderlich zur Simulation von sensitiven Befehlen mit Speicherzugriff entsprechend dem jeweils eingestellten Adressierungsmodus.

(4) Mehrere virtuelle Adressenräume und insbesondere "leere" virtuelle Adressenräume:
einer virtuellen Maschine mit virtueller Adressierung oder mit einem Speichervollausbau entsprechend der Adressbreite können keinerlei Einschränkungen in der Belegung des Adressenraumes auferlegt werden, d.h. für einen VMP müssen Adressenräume ermöglicht werden, die "leer" - nicht von Objekten des Time-Sharing-Betriebssystems belegt - sind; hieraus folgt unmittelbar, dass eine Unterbrechungsroutine, die einen solchen VMP unterbricht, in einem anderen - weil die HW oft keine andere Wahl bietet: im realen - Adressenraum ablaufen muss.

(5) Manipulationen an den Adressraumbeschreibungen für den VMP durch den VMMP (koordiniert mit dem Seiten-Supervisor des Time-Sharing-Systems):
aus Effizienzgründen müssen möglichst viele Befehle der virtuellen HW auf der realen HW ablaufen; es muss somit auch bei virtuellen Maschinen mit virtueller Adressierung die Adressumsetzung von der HW der Basismaschine vorgenommen werden: das setzt voraus, dass der VM-Monitor-Prozess für die HW die Doppelabbildung "virtuelle virtuelle Adresse : reale Adresse" vorgibt. Diese Doppelabbildung darf auch bei Manipulationen des Seiten-Supervisors an dem virtuellen Adressenraum, der den Realspeicher der virtuellen Maschine darstellt, nicht zu Fehlern führen.

(6) parallele Aktivitäten innerhalb eines Benutzerauftrages:
es werden Dienste zur Unterstützung der Simulation von asynchronen Vorgängen einer virtuellen Maschine (z.B. E/A) benötigt.
Entweder
- VMP und VMMP als eigenständige Prozesse des TSBS, da es sinnvoll ist, voneinander unabhängige Vorgänge als voneinander unabhängige Prozesse zu organisieren.
Zumindest aber
- VMP und VMMP innerhalb eines Prozesses des TSBS und Systemdienste (z.B. E/A, Weckdienste), die parallel zum auftraggebenden Prozess ablaufen und ihre Rückmeldungen dem Auftraggeber unterbrechungsartig zustellen. Wird durch eine solche Rückmeldung der Prozess im "VMP-Zustand" unterbrochen, so muss - analog zu Forderung (1) - in den "VMMP-Zustand" umgeschaltet werden.

Schluss

Die beschriebenen System-Erweiterungen ermöglichen es
- falls das Betriebssystem in der genannten Art modifizierbar ist und
- falls die Hardware der zugrundeliegenden Maschine prinzipiell für die VM-Technik geeignet ist,
durch Hinzufügen von VM-Monitor-Prozessen die Technik der virtuellen Maschinen in ein Time-Sharing-Betriebssystem einzubetten.

Literatur

/1/ Parmelee R.P., Petersen T.I., Tillman C.C., Hatfield D.J.
"Virtual Storage and Virtual Machine Concepts"
IBM Systems Journal, Vol 11, Nr 2, 1972, S. 99-102

/2/ Goldberg R.P.
"Architecture of Virtual Machines"
AFIPS Conf. Proc., Vol 42, NCC 1973, S. 309-318

/3/ Goldberg R.P.
"Survey of Virtual Machine Research"
Computer, Vol 7, Nr 6, Juni 1974. S. 34-45

/4/ Buzen J.P., Gagliardi U.O.
"The Evolution of Virtual Machine Architecture"
AFIPS Conf. Proc., Vol 42, NCC 1973, S. 291-299

/5/ Goldberg R.P.
"Virtual Machines: Semantics and Examples"
IEEE Computer Science Conference, Boston MA, 1971, S. 141-142

/6/ Mallach E.G.
"On the Relationship between Virtual Nachines and Emulators"
Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems, Cambridge MA, 1973, S. 117-126

/7/ Goldberg R.P.
"Hardware Requirements for Virtual Machine Systems"
Proc. 4th Hawaii International Conference on Systems Sciences, Honululu, 1971, S. 449-451

/8/ Popek G.J., Goldberg R.P.
"Formal Requirements for Virtualizable Third Generation Architectures"
Comm. of the ACM, Vol 17, Nr 7, Juli 1974, S. 412-421

/9/ Lauer H .C., Wyeth D.
"A Recursive Virtual Machine Architecture"
Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems, Cambridge MA, 1973, S. 113-116

/10/ Lauer H.C., Snow C.R.
"Is Supervisor-State Necessary?"
Proc. ACM AICA International Computing Symposium, Venedig, 1972, S. 293-301

/11/ Gagliardi U.Q., Goldberg R.P.
"Virtualizable Architectures"
Proc. ACM AICA International Computing Symposium, Venedig, 1972, S. 527-539

/12/ Goldberg R.P. (Herausgeber)
Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems,
Cambridge MA, 1973

/13/ Klemenc H., Lochner H., Schönherr H-J.
"VM/370 = CP + CMS"
IBM Deutschland, 1972

/14/ Fuchi K., Hozuni T., Yuriko H., Toshitsugu Y.
"A Program Simulator by Partial Interpretation"
2nd ACM Symposium on Operating System Principles, Princeton University, 1969, S. 97-104

/15/ Srodawa R.J., Bates L.A.
"An Effizient Virtual Machine Implementation"
AFIPS Conf. Proc., Vol 42, NCC 1973, S. 301-308

/16/ Galley S.W.
"PDP-10 Virtual Machines"
Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems, Cambridge MA, 1973, S. 30-34

zurück zurück