DE2426435C2 - Rechenanlage - Google Patents

Description

Die Erfindung bezieht sich auf eine Rechenanlage, welche mittels eines Gastrechners mit realen Betriebsmitteln eine oder mehrere andere Rechenanlagen als virtuelle Maschinen mit deren virtuellen Betriebsmitteln simuliert und dabei die virtuellejiMaschinen in mehreren Betriebsebenen zur Ausführung bringt

Das Auftauchen von Eingabe/Ausgabe-Verarbeitungseinrichtungen in den Mhen sechziger Jahren und die Anwendung der Multiprogrammierung zwecks Steigerung der Betriebsmittelausnutzung und der Gesamtleistung hat den Beginn von Mehrprozessor-Multiprogrammierungs-Konfigurationen dargestellt, bei denen ein Hauptspeicher für nicht übereinstimmende Prozessoren bzw. Verarbeitungseinheiten verteilt zur Verfugung stand und be'i denen eine einzige Verarbeitungseinrichtung an verschiedenen Prozessoren teilnahm, die im Wettbewerb um gemeinsame Betriebsmittel standen.

Um die mit der Systemintegrität zusammenhängenden Probleme zu vermeiden, wurde eine Doppelzustands-Bauweise übernommen. Griindsäizlich wurde der Systembetrieb in zwei unterschiedliche Betriebsarten aufgeteilt — in eine privilegierte Betriebsart und in eine nicht privilegierte Betriebsart. Die privilegierten/nicht privilegierten Betriebsarten (auch als Master/Slave oder System/Anwender-Betriebsarten bekannt) haben jedoch die Leistung von kritischen Operationen auf die privilegierte Betriebsart beschränkt, während der Großlcil von Operationen, die nicht kritisch waren, in der nicht privilegierten Betriebsart ausgeführt wurden.

In Fig. la ist der herkömmliche Doppelzustandsaufbau gezeigt Die Grundmaschin? 101 weist eine Grund-Maschinentrennstelle 103 auf, welche einen privilegierten Softwarekern 102 enthält. (Eine Grund-Maschincntrennstelle bzw. -Maschinenschnittstelle ist die Anlage für sämtliche sichtbaren Software-Objekte und -Befehle, die direkt durch die Hardware und Firmware eines bestimmten Systems getragen werden.) Diese Kombination stützt sich auf verschiedene erweiterte Maschinen 104,105, etc., obwohl der Klarheit wegen lediglich zwei dieser Maschinen dargestellt sind. Die erweiterten Maschinen können ihrerseits verschiedene Anwenderprogramme,

z. B. Programme 106 und 107 tragen. Es sei jedoch darauf hingewiesen, daß mit Rücksicht darauf, daß herkömmliche Systeme dieses Typs lediglich eine Grund-Maschinenschnittstelle 103 enthalten, diese Systeme imstande sind, lediglich zu irgendeinem gegebenen Zeitpunkt einen privilegierten Softwarekern bzw. Softwarezentrum 102 entsprechend zu laufen. Da die einzige Software, die vollständigen Zugriff zu sämtlichen Funktionscigenschaften der Hardware hat und diese Eigenschaften steuert, das privilegierte Softwarezentrum ist, entstehen

so demgemäß verschiedene Probleme. Das Hauptproblem liegt dabei im Bereich der Programmtransportierbarkeit, weil nämlich nicht privilegierte Programme tatsächlich für die erweiterte Maschine geschrieben werden, die durch das privilegierte Softwarezentrum zuzüglich der nicht privilegierten Funktionen der Hardware gebildet ist. Während die Grundhardwaremaschine relativ leicht zu standardisieren ist, sind die erweiterten Maschinen sehr schwer zu standardisieren, und zwar wegen der relativen Leichtigkeit, mit der ein System einschließlich des privilegierten Softwarezentrums modifiziert werden kann, da die Stammwörter d. h. Pseudobefehle eines derartigen Systems zum Teil in Software ausgeführt sind. Das Ergebnis ist eine Vielzahl unterschiedlich erweiterter Maschinen, die auf der Basis einer Grundstandardmaschine laufen. Deshalb muß ein Anwender, welcher wünscht, Programme laufen zu lassen, die für eine fremde erweiterte Maschine geschrieben worden sind, entweder eine gewisse Zeit auf seiner erweiterten Maschine bereitstellen, um das fremde Softwarezentrum durchlaufen zu lassen, oder er muß die für die fremde erweiterte Maschine geschriebenen Programme für seine erweiterte Maschine umsetzen — eine Wahl, die die meisten Anwender nicht begrüßen.

Ein weiteres Problem entsieht dadurch, daß lediglich ein privilegiertes Softwarezentrum vorhanden ist und daß es deshalb unmöglich ist. zwei Versionen des privilegierten Softwarezentrums zur selben Zeit laufen zu lassen. Die fortwährende Entwicklung und Modifizierung des Zentrums ist daher sehr schwierig, weil es notwcndig wird, über Systemprogrammierer zu ungewöhnlichen Stunden zu verfügen, um das zur Verfügung gestellte System zu ihrer Verwendung zu haben. Wenn die Systemprogrammierer jedoch das vorhandene System zwecks Programmstruktur oder zur Modifizierung zur Verfügung haben, ist dasselbe einer sehr schwachen Belastung ausgesetzt, die zu einer unwirtschaftlichen Ausnutzung der Betriebsmittel führt.

Schließlich ist der Test- und Diagnoseumfang, der ohne Störung der normalen Produktionspläne ausgeführt werden kann, begrenzt, weil die Diagnose-Software einen Zugriff zu sämtlichen Funktionseigenschaften der Hardware haben muß und diese steuern muß und somit nicht gleichzeitig mit dem privilegierten Softwarezentruiii laufen kann.

Um diese Probleme zu vermeiden, ist es notwendig, ein privilegiertes Softwarezentrum zu bilden, welches mehrere Nachbildungen der Grund-Maschinenschnittstelle versorgen kann, und zwar anstelle der erweiterten Maschinenschnittstelle. Sodann könnte ein unterschiedliches privilegiertes Softwarezentrum an jeder der zusätzlichen Grund-Maschinenschnittstelien laufen, wodurch die zuvor erwähnten Probleme sich vermeiden ließen.

Eine Grund-Maschinenschnittstelle, die nicht direkt von der Grundmaschine, sondern vielmehr in ähnlicher Weise wie eine erweiterte Maschinenschnittstelle versorgt wird, ist als »virtuelle Maschine« bekannt und in Fig. Ib mit 110 und 111 bezeichnet. In Fig. Ib ist dieselbe Grundmaschine 101 wie in Fig. 1a dargestellt: die nunmehr an der Grund-Maschinenschnittstelle 103 laufende privilegierte Software ist jedoch ein virtueller Maschinenmonitor 122. Der virtuelle Maschinenmonitor 122 versorgt mehrere Nachbildungen der Grund-Maschinenschnittstelle 124. Demgemäß kann ein unterschiedlicher privilegierter Softwarekern 112, 113 bei jeder Nachbildung der zusätzlichen Grund-Maschinenschnittstelle 124 laufen. Jeder privilegierte Softwarekern bzw. jedes privilegierte Softwarezentrum 112,113 kann somit seine eigene Reihe von erweiterten Maschinenschnittstellen 125 und 126 und demgemäß seine eigenen Anwenderprogramme 118,119 bzw. 120,121 versorgen bzw. unterstützen.

Da eine Grund-Maschinenschnittstelle, die von einer virtuellen Maschinenüberwachungseinrichtung bzw. einem virtuellen Machinenmonitor versorgt wird, funktionell mit der Grund-MaschinenschnittsteiJc der entsprechenden realen Maschine übereinstimmt, läuft jeder privilegierte Softwarekern, der auf der bloßen G-, und- bzw. Gastmaschine läuft, ebenso gut auch auf der virtuellen Maschine. Darüber hinaus hat der privilegierte Softwarekern bzw. das privilegierte Softwarezentrum keine Möglichkeit zu bestimmen, ob das betreffende Zentrum auf einer Gastmaschine oder einer virtuellen Maschine läuft. Demgemäß ist eine virtuelle Maschine im wesentlichen seinem realen Gegenstück äquivalent und funktionsmäßig von diesem nicht unterscheidbar. Die virtuelle Maschinenüberwachungsanordnung führt keine Befehls-Befehls-lnterpretation dieser Programme aus, sondern ermöglicht vielmehr diesen, direkt auf einer Gastmaschine für einen größeren Teil der Zeit zu laufen. Gelegentlich stellt die virtuelle Maschinenüberwachungsanordnung jedoch gewisse Befehle fest und führt sie interpretierend aus, um die Integrität des Systems als Ganzes zu gewährleisten. Nachdem die Interpretierungsphase abgeschlossen ist, kehrt die Steuerung dann zum Ausführungsprogramm zurück. Somit ist eine Programmausführung auf einer virtuellen Maschine ziemlich ähnlich einer Programmausführung auf einer erweiterten Maschine, wobei der Hauptteil der Befehle direkt ausgeführt wird, ohne daß ein Software-Eingriff erfolgt; gelegentlich erfolgt jedoch ein Eingriff durch die steuernde Software, urn eine notwendige interpretierende Operation auszuführen.

Es sei bemerkt, daß die virtuelle Maschinenüberwachungsanordnung VMM 122 gemäß Fig. Ib auf einer Gastmaschine läuft. Systeme dieses Typs sind als virtuelle Maschinen des Typs 1 bezeichnet worden. Dabei können jedoch virtuelle Maschinenüberwachungen bzw. Überwachungsprogramme vorgesehen sein, die auf erweiterten Maschinen laufen. Dieser Typ von virtueller Maschine ist schematisch in F i g. 1 c dargestellt und ais virtuelle Maschine des Typs II bezeichnet. In F i g. Ic ist die Gastmaschine 101 gezeigt, die eine Grund-Maschincnschnittstelle 103 mit dem privilegierten Softwarekern bzw. Softwarezentrum 151 aufweist. Das privilegierte Sofiwarezcntrum 151 seinerseits versorgt die erweiterten Maschinen 153, 154 welche erweiterte Maschinenschnittstellen 157a bzw. 1576 aufweisen. Die erweiterte Maschine 153 ihrerseits versorgt das Anwendungsprogramm 155, während die erweiterte Maschine 154 die virtuelle Maschine 158 versorgt, die ihrerseits die erweiterte Maschine 161 versorgen kann, weiche ihrerseits ein Anwenderprogramm 162 ablaufen läßt.

Im folgenden seien einige bekannie Maschinen näher betrachtet. Es gibt jedoch beim Stand der Technik relativ wenige Beispiele für virtuelle Maschinen. Einige typische Maschinen sind dabei folgende:

a) IBM M44 des Typs I FV.

Die Maschine IBM ii*<»4, welche eine stark modifizierte zweite Generation der IBM 7044 darstellt, wurde erweitert, um eine Seitenbildung und eine Anzahl von Operationsbetriebsarten, wie die Betriebsarten Problem/Überwachung, Lagetest/kein Lagetest und Abbildung/keine Abbildung, zu umfassen. Durch die Anwendung eines modularen Operationssystems wird eine Reihe von virtuellen Maschinen erzeugt, die mit 44X bezeichnet sind. Diese Maschinen 44X sind dabei keiiie virtuelle Maschinen im engsten Sinne, weil sie sich geringfügig von der realen Maschine IBM 7044 unterscheiden. Ein 44X-Operationssystem läuft auf jeder 44X-Maschine und liefert die in den meisten Opertionssystemen zu findenden üblichen Dienste.

b) IBM wissenschaftiches Zentrum Cambridge CP-40 des Typs I FV.

Das Zentrum CP-40, Vorläufer des CP-67, wurde auf einer Maschine IBM 360/40 aufgebaut, die durch die Hinzufügung eines Assoziativspeicher-Seitenbehälters speziell modifiziert worden ist. Dieses System war ein System auf Zeitteilbasis und versorgte vierzehn virtuelle Maschinen des Typs IBM 360. Diese Maschinen 360 sind Standardmaschinen IBM 360 und enthalten keine speziellen Modifikationen des Reihenrnödels 40. Die virtuellen Maschinen IBM 360 sind hingegen imstande, zahlreiche IBM-360-Operationssystcrr.e laufen zu lassen, einschließlich der normalen Systeme OS/360 und CMS, wobei letztere ein Umsetzsystem darstellt, das im wissenschaftlichen Cambridge-Zentrum speziell für die Anwendung mit der Maschine CP-40 entwikkclt worden is'. Das System litt jedoch an vielfältigen Beschränkungen wie geringer Verarbeitungsgeschwindigkeit des Systems IBM 360/40, ferner dem mäßigen Umfang eines vorhandenen Kernspeichers und dem relativ langsairrn Plattenspeicher. Die Maschine CP-40 dieme jedoch dazu, gewissermaßen die Lebensfähigkeit des virtuellen Maschinenkonzeots zu demonstrieren. Darüber hinaus lieferte die Maschine ein

VMTSS-Sysiem und mit dem CMS-System ein geeignetes Umsetzsystem für das System 360 zu einem Zeitpunkt, zu dem kein anderes All/.weck-System auf Zeitteilbasis für die Reihe von Maschinen arbeitete. Der Erfolg mit diesem Projekt führte tatsächlich direkt zu dem größeren System CP-67.

c) IBM wissenschaftliches Zentrum Cambridge CP-67 des Typs I FV.

Das Zentrum bzw. System CP-67 wurde als experimentielles System in Verbindung mit dem M IT-Lincoln-Laboratory im Januar 1967 begonnen. Anfänglich wurde das System CP-40ein wenig modifiziert, um das im System IBM 360/67 zu findende unterschiedliche Speicher-Verschiebungssystem zu versorgen. Danach wurde das gesamte System CP-67 neu geschrieben. Das System CP-67 ist ein VMTSS-System. welches auf der Maschine IBM 360/67 läuft und zwischen 30 und 40 Anwender versorgt. Es ist somit das am weitesten bekannte virtuelle Maschinensystem. Die virtuellen Maschinen IBM 360, die unter der Bezeichnung CP-67 erzeugt worden sind, sind somit hinsichtlich des Laufenlassens einer Anzahl von unterschiedlichen IBM-360-Operationssystemen sehr erfolgreich gewesen. Diese Operationssysteme umfassen unter anderem die Systeme OS/360 in mehreren Versionen, sowie die Systeme DOS. DOS-APL, CMS und LLMPS. Die virtuellen Maschinen sind jedoch nicht in den die Fernmeldetechnik betreffenden Anwendungsfällen bcnutzt worden. Die Universität von Grenoble hat jedoch das System IBM OS/ASP entwickelt, indem eine Gast-Maschine IBM 360/40 mit einer virtuellen Maschine 360 verbunden wurde. Die Hauptbeschränkungen der durch das System CP-67 gebildeten virtuellen Maschinen liegen darin, daß ein gewisser Satz von Programmen unter Umständen nicht richtig arbeit?! Es h?.n<i·*'· ^s'^rh dahei um fehlende Programme:
1) Programme, die von genauen Ausführungszeiten abhängen.

2) Programme, die von der Beziehung zwischen der Verarbeitungszeit und der Eingabe/Ausgabe-Zeit abhängen.

3) Programme, die von der genauen Echtzeit abhängen, und

4) Programme, die Selbsmodifizierungs-Kanalprogramme enthalten.

Die ersten beiden Beschränkungen sind dabei mit jenen Beschränkungen gleichzusetzen, welche sich durch die Kompatibilität zwischen zwei verschiedenen Prozessen der IBM 360-Familie ergaben.

d) Erweiterung des Systems CP-67 zur Versorgung bzw. Unterstützung des virtuellen Systems 360/67 des Typs ISV.

Im Mai 1969 entwickelte R. Goldberg eine geringfügige Erweiterung zum System CP-67, um eine relativ wirksame Softwareausführung eines virtuellen Systems 360/67 mit virtueller Verschiebung zu versorgen bzw. zu unterstützen. Mit geringfügigen Modifikationen wurde dieser Entwurf eines virtuellen Systems IBM 360/67 im Herbst 1969 von F. Furtek ausgeführt. Unabhängig von dieser Arbeit entwickelte auch A. Auroux im IBM-Wissenschaftlichen Zentrum. Cambridge eine Erweiterung eines virtuellen Systems IBM 360/67 zum System CP-67. Die beiden Entwicklungen sind sehr ähnlich, wobei die Auroux-Ausführung Teil des IBM-Standardsystems CP-67 geworden ist.

Das virtuelle System IBM 360/67 ist dabei auf eine 24-Bit-Adressierungsbetrieb-Einzelprozessor-Maschinc beschränkt. Mit dieser Fähigkeit sind verschiedene IBM 360/67-Operationssysteme, einschließlich der Systeme CP-67 und TSS/360 gelaufen. Dies bedeutet, daß das System CP-67 unter sich selbst gelaufen ist. In der Tat ist diese Kette bis zu einer Tiefe von zumindest vier überprüft worden. Die prinzipielle zusätzliche Beschränkung bezüglich der Operation des virtuellen Systems IBM 360/67 gegenüber einem normalen

virtuellen System IBM 360 (unter der Bezeichnung CP-67) liegt dabei darin, daß Programme, die dynamisch den Inhalt des Segments oder der Seitentabellen ändern, nicht wie beabsichtigt ausgeführt werden können. Die Ergebnisse können gegebenenfalls gleich sein mit einer Gastmaschine IBM 360/67. Bei einer Gastmaschine kann dabei der Inhalt der assoziativen Register das Ergebnis beeinflussen, weshalb die Ergebnisse unter Umständen nicht voraussagbar sein können.

e) Virtuelles System IBM 360, mit der Bezeichnung UMMPS des Typs II FV.

Das virtuelle System IBM 360 unter der Bezeichnung UMMPS ist ein virtuelles Maschinensystem des Typs II. Das System UMMFS ist ein herkömmliches Mehrprogrammierungssystem, welches in der Universität von Michigan geschrieben worden ist, um auf einer Doppelprozessoraniage IBM 360/67 zu laufen. Die Universität von British Columbia hat einige Modifikationen bezüglich des Systems UMMPS vorgenommen, um ein vi;-uelles System IBM 360 zu versorgen bzw. zu unterstützen. Diese Modifikationen sind in i\>rm von einigen zusätzlichen Überwachungsanforderungseigenschaften erfolgt, um gewisse entscheidende bzw. kritische Operationen in der Abfertigung der virtuellen Maschine auszuführen. Offensichtliche Ausnahmebedingungen, die in der virtuellen Maschine auftreten, werden durch das UMMPS-Überwachungsprosramm auf ein Anwenderprogramm reflektiert, welches z. B. diese Simulation von privilegierten Befehlen ausführt. Virtuelle Standard-Systeme IBM 360 und virtuelle Systeme 360/67 werden dabei von diesem

System versorgt bzw. unterstützt, obwohl andere Anwenderschnittstellen neben den virtuellen Maschinenschnittstellen vorgesehen sind,
f) Das System HITAC-8400 der japanischen elektrotechnischen Laboratorien des Typs Il FV.

Das System HITAC-8⁴00 ist die japanische Ausführungsform des RCA-Systems Spectra 70/45. Es ist ein herkömmlicher Rechner der dritten Generation ohne ein Speicher-Abbildungssystem, und zwar ähnlich dem IBM System/360. Ais Hilfe für die Fehlerbeseitigung bzw. Programmkorrektur im System ETSS wurde ein neues System auf Zeitteilbasis für das System HITAC-8400, eine virtuelle Maschine des Typs II, auf dem vorhandenen. Verkäufer-Abgabeoperationssystem TOS/TDOS aufgebaut. Das virtuelle Maschinensystem ist dabei sehr ähnlich dem virtuellen System IBM 360. das auf dem System UMMPS aufgebaut wurde. Ein interessierender Aspekt dieser Leistung war der Versuch, verschiedene virtuelle Eingabe/Ausgabe-Einrichtungen zu simulieren, die keine exakten physikalischen Gegenstücke (wie eine Sichtanzeige) haben. Dies wurde selbstverständlich vorgenommen, weil die virtuelle Maschine vollständig dazu herangezogen wurde, den Oberwachungsprogrammcode für das System ETSS zu korrigieren, und nicht dazu, unter der Steuerung

durch die betreffende Maschine laufende Produktionsvorgänge zu korrigieren.

g) I lardware-modifiziertes System IBM 360/30 des Typs I FV.

Es ist ein virtuelles Maschinensystem auf einem experimentiellen System 360/30 aufgebaut worden, und

zwar durch Kombination von Software und von sogenannter ad hoc-Hardware, d. h. durch Mikroprogram- ■

mierungs-Modifikationen. Diese Modifikationen, welche eingeführt worden sind, um den Aufbau einer 5 ■■';' virtuellen Maschine zu vereinfachen, wurden dazu herangezogen, einen speziellen »Monitor«-Betrieb

auszuführen und den Unterbrechungssteuerbereich von einem regulären Steuerprogrammbereich auf der iß

physikalischen Seite »0« neu zu adressieren bzw. bereitzustellen. Das System ist dabei nicht ein VMTSS : '

Sysicm; indem es lediglich eine virtuelle Maschine unterstützt. Überdies ist das System nicht ein selbst-vir- ·ί

tualisierendes System, und unterstützt keine virtuellen Maschinen, die dieser modifizierten Maschine IBM ίο £j

360/30 äquivalent sind. Ihre Hauptarwendung der betreffenden Maschine liegt in der Bestimmung bzw. I

Abschätzung der Leistungsfähigkeit existierender Operationssysteme, wie des Operationssystems IBM/ 1

360/(OS/360), und der Grund-, Plattenspeicher- und Band-Operationssysteme BOS, DOS und TOS/360. |

h) MIT-Projekt MAC PDP-10 ITSdesTyps II SV HVM. §

Da es nicht möglich ist, virtuelle Maschinen auf dem System DEC PDP-10 unter Verwendung herkömmli- 15 ;

eher Softwaretechniken der dritten Generation aufzubauen, haben R. P. Goldberg und S. W. Galley kürzlich :■

die Vorstellung einer hybriden virtuellen Maschine für das System PDP-10 eingeführt. Mit dieser Technik }

werden sämtliche Ausführungsbetriebs-Befehle interpretiert, während sämtliche Anwendungsbetriebs-Be- []

fehle direkt ausgeführt werden. Das MIT-Projekt MAC — dynamisch«?·; Modeüierungs-Rechnergraphiksy- jij

stern PDP-10 — hat dabei für diese Ausführung eine ideale Umgebung geschaffen. Das System ITS 20 |

(inkompatibles System auf Zeitteilbasis) liefert die benötigten Eigenschaften zur Stützung bzw. Versorgung I

eines VCS-Systems des Typs Ii mit erweitertem Maschinenumfang. Darüber hinaus ist die Hardware-Konfi- j¹

guration mit genügend Kernspeicherplätzen und zuweilen auch mit genügend Zentraleinheits-Zyklen aus- ■: gestattet, um das Laufendes HVM-Systemszu ermöglichen.

i) IBMVM/370. 25 -i<

Im Juli 1972 hat die Firma IBM die Möglichkeit einer virtuellen Maschine für verschiedene Modelle des ?

Systems 370 angekündigt. Dieses System ist ein direkter Nachkomme des Systems CP-67; es unterstützt j

virtuelle Maschinen unter Verwendung konventioneller Softwaretechniken. Das System VM/370 ist dabei c

das erste formal unterstützte, kommerziell angebotene virtuelle Maschinensystem, das von irgendeinem ''

Hersteller verfügbar ist. 30 ;

Ältere bekannte virtuelle Maschinen wurden in der Weise charakterisiert, daß die virtuellen Maschinenmoni- : ^: tore bzw. -Überwachungsprogramme (VMM) den Zustand des Prozessors, und Hauptspeicher- und Eingabe/ i Ausgabe-Operationen der virtuellen Maschine steuerten. Die frühen virtuellen Maschinenüberwachungspro- 'A gramme bzw. -monitore ließen dabei sämtliche Programme in der nicht privilegierten Betriebsart laufen, so daß 35 _rj kein privilegiertes Softwarezentrum, das auf einer virtuellen Maschine ausgeführt wurde, in die privilegierte ;_;j Betriebsart gelangen und einen unbeschränkten Zugriff zu dem gesamten System erhalten konnte. Daher ist die ii Möglichkeit gegeben, daß sich das virtuelle Maschinenüberwachungsprogramm selbst oder irgendeine andere, <i] in dem System vorhandene virtuelle Maschine stört. Darüber hinaus bildeten diese frühen virtuellen Maschinen- p Monitorprogramme bzw. -Überwachungsprogramme gewöhnlich den Hauptspeicher durch Seitenbildungsver- 40 |i fahren bzw. sogenannte Paging-Verfahren ab, wobei sämtliche Eingabe/Ausgabe-Operationen interpretierend i; ausgeführt wurden. Deshalb konnten diese frühen virtuellen Maschinen lediglich auf Rechnersystemen ausge- ;| führt werden, die eine gewisse Form eines Verschiebungssystems aufwiesen, welches die Fähigkeit besitzt, Jj, sämtliche Befehle festzuhalten, die den Prozessorzustand ändern oder abfragen oder Eingabe/Ausgabe-Opera- h tionen einleiten konnten. Obwohl einige dieser frühen virtuellen Maschinenüberwachungsprogramme VMM. 45 ?jj z. B. das Programm CP-67, auf Rechnersystemen mit einer Zeitbildung ausgeführt worden sind, konnten diese H Überwachungsprogramme jedoch nicht selbst die virtuellen Maschinen mit Seitenbildung unterstützen; deshalb ^ konnten die betreffenden Programme nicht auf jenen virtuellen Maschinen laufen, die sie hervorriefen. Auf |i Grund dieses Mangels an rekursiver Fähigkeit mußte die Überprüfung und Entwicklung des virtuellen Maschi- s/j nenüberwachungsprogramms VMM auf einem zur Verfügung gestellten Prozessor ausgeführt werden. Um 50 |ij diese Schwierigkeit zu überwinden und einen zufriedenstellenderen Grad an Verknüpfungs-Vollständigkeit zu A erzielen, wurde das System CP-67 derart modifiziert, daß es rekursiv laufen konnte. Dies erforderte die wirksa- SJ me Ausführung einer Doppel-Ausbildungsoperation, um die zusätzliche Seitenbildungsoperation vorzunehmen, igi die in dem virtuellen Maschinenüberwachungsprogramm VMM selbst stattfindet. Um einen Prozeß auf einer §| virtuellen Maschine mit Seitenbildung ablaufen zu lassen, mußte zunächst eine durch den Prozeß erzeugte 55 S Adresse A in eine virtuelle Speicheradresse A' umgeformt werden, und zwar mittels der Bildungstabelle der §« virtuellen Maschine, und sodann muß die virtuelle Speicheradresse Λ'in eine reale Adresse A " abgebildet bzw. überführt werden, und zwar durch die Seitenbildungstabelle des virtuellen Maschinenüberwachungsprogramms VMM. Um diese Doppelabbildung wirksam auszuführen, bildet die Software des virtuellen Maschinenüberwachungsprogramms eine zusammengesetzte Seitentabelle (in der die virtuelle Prozeßadresse A in die reale 60 Adresse A"abgebildet bzw. überführt ist). Außerdem wird durch die betreffende Software mit dieser Abbildung die Steuerung der Adressen-Umrechnungshardware ausgeführt. Wenn das virtuelle Maschinenüberwachungsprogramm VMM eine Transferierung einer Seite aus dem Speicher vornimmt, muß es zunächst dessen eigene Seitentabelle ändern und dann die gebildete Karte bzw. Abbildung neu berechnen.

Wenn das privilegierte Softwarezentrum die Seitentabelle der virtuellen Maschine ändert, muß das virtuelle 65 Maschinen-Überwachungsprogramm VMM in entsprechender Weise darüber informiert werden, so daß das zusammengesetzte Bild bzw. Abbild neu berechnet werden kann. Da die Seitentabelle der virtuellen Maschine in gewöhnlichen Speicherplätzen gespeichert ist, werden Befehle, die auf die Tabelle Bezug nehmen, nicht notwen-

digerweise durch das virtuelle Maschinenüberwachungsprogramm VMM festgehalten. Daher bestand die Gefahr, daß gewisse Änderungen von dem virtuellen Maschinenüberwachi..igsprogramm VMM nicht ermittelt wurden, so daß eine richtige Betriebsweise nicht garantiert werden konnte.

Die virtuellen Maschinen des Typs II, die mit erweiterten Schnittstellen laufen, sind im allgemeinen leichter 5 aufzubauen als virtuelle Maschinenmonitore VMM, die auf einer Gastmaschine direkt laufen, weil nämlich der virtuelle Masrhinenmonitor das Befehlsrepertoir der erweiterten Maschine benutzen kann, wenn komplexe Operationen, wie Eingabe/Ausgabe-Operationen, ausgeführt werden. Darüber hinaus kann das virtuelle Maschinenüberwac.iungsprogramm bzw. der virtuelle Maschinenmonitor VMM die Speicher-Managementeigenschaften der erweiterten Maschine und deren Dateisystem ausnutzen.

ίο Die virtuellen Maschinen des Typs II sind für die erweiterte Maschinenschnittstelle ausgelegt, die durch das UMMPS-Operationssystem hervorgebracht wird. Wie oben ausgeführt, läuft das System UMMPS auf einer IBM Maschine des Modells 67. Der virtuelle Maschinenmotor, der unter dem System UMMPS läuft, ist somit imstande, dieselbe Prozessor-Zustandsabbildung zu benutzen, die das System CP-67 benutzt.

Der Befehl in dem virtuellen Maschinenmonitor VMM, der die Operation einer virtuellen Maschine auslöst, 15 muß jedoch das System UMMPS darüber informieren, daß nachfolgend privilegierte Befehlssprüngc, die von .■'.·: der virtuellen Maschine erzeugt werden, nicht direkt behandelt werden sollten, sondern vielmehr dem virtuellen

i^! Maschinenmonitor VMM für eine geeignete Interpretation zugeführt werden sollten. Darüber hinaus wird

■"; durch den Befehl, der die Operation einer virtuellen Maschine einleitet, außerdem das System UMMPS veran-

ί!τ !aßt, seine Seitentabeüen zu ändern, um der Tatsache Ausdruck zu geben, daß ein neuer Adressenplalz aktiviert

-;■■·■ 20 worden ist. Wird bei der gebildeten virtuellen Maschine eine Seitenbildung vorgenommen, so ist es notwendig,

'r,- die resultierende Tabelle mit der Seitentabelle zusammenzustellen, die in dem Speicher der virtuellen Maschine

';■: erscheint. Diese zuletzt genannte Operation ist vollständig analog der Bildung von virtuellen Maschinen mit

^l;f Seitenbildung unter dem System CP-67.

"j. Eingabe/Ausgabe-Operationen wurden in der virtuellen Maschine des ursprünglichen UMMPS-Systems des

I? 25 Typs Il dadurch verarbeitet, daß eine UMMPS-System-Transfersteuerung auf den virtuellen Maschinenmonitor

|f VMM erfolgte, und zwar nach Erfassen des Befehls, der die Kanalprogrammausführung einleitete. Der virtuelle

jij Maschinenmonitor VMM setzt dabei das Kanalprogramm in dessen Adressenplatz um, und zwar durch gegcbc-

-$ nenfalls erfolgendes Abgeben des Seitenplanes der virtuellen Maschine und durch sodann erfolgendes Addieren

_vi eines konstanten Verschiebungsfaktors zu jeder Adresse. Nach Ausführung dieser Umsetzung forderte der

;?i 30 virtuelle Maschinenmonitor VMM das System UMMPS an, um das Kanalprogramm auszuführen. Das UMMPS-

ί'.ί System absolutierte sodann das Kanalprogramm und leitete dessen Ausführung ein.

■?ί Zusätzlich zu den obigen Vorgängen, die dieser Abbildungsvorgang nach sich zog, hat es dieser Abbildungs-

i| Vorgang für die virtuelle Maschine unmöglich gemacht, ein selbst-modifizierendes Kanalprogramm auszuführen.

•t Eine kürzlich erfolgte Modifizierung der Monitor-Software der virtuellen Maschine des UMMPS-Systems hat es

fl 35 ermöglicht, diese Situation zu mildern. Diese Modifikation umfaßt die Überführung des Speichers der virtuellen

t| Maschine in den realen Speicher, so daß die virtuelle und die reale Adresse des jeweiligen Speicherplatzes

'ύ identisch sind. Dies vermeidet die Notwendigkeit nach Absolutisierung des Kanalprogramms und steigert somit

£ die Wirksamkeit, während gleichzeitig eine Selbstmodifizierung der Kanalprogramme möglich gemacht ist.

fEine der Schwierigkeiten, die zu überwinden waren, als diese Änderung bezüglich des virtuellen Maschincn_v. 40 monitors vorgenommen wurde, lag darin, daß die realen Gegenstücke zu bestimmten virtuellen Maschinenspci-

|S cherplätzen bereits von dem System UMMPS benutzt waren. Die Lösung, die übernommen wurde, bestand

I darin, einfach das priv^:|.?gierte Softwarenzentrum der virtuellen Maschine zurück- bzw. neu zu schreiben, so dal!

jj die meisten dieser Speicherplätze niemals benutzt wurden.

j| Eine der gebräuchlicheren vorgeschlagenen Lösungen des Problems der Erstellung von virtuellen Maschincn-

% 45 aufbauten basiert auf der Idee, den privilegierten Zustand vollständig zu vermeiden. Die Anhänger dieser

j* Lösung argumentieren, daß die hauptsächliche — und tatsächlich einzig notwendige — Funktion des privilegier-

$ ten Zustands darin besteht, den Adressenabbildungsmechanismus des Prozessors zu schützen.

Ü Wenn der Adressenabbildungsmechanismus aus der Gastrechnerschnittstelle entfernt und dadurch vollstän-

ΐ:< dig unsichtbar für die Software wird, bestünde nämlich keine Notwendigkeit danach, den Mechanismus zu

fi 50 schützen und damit keine Notwendigkeit für einen privilegierten Zustand.

Ij Der zuvor erläuterte Einzelzustands-Aufbau bringt eine wirksame Umgebung für die Erstellung von rekursi-

ffl ven virtuellen Maschinensystems mit sich. Der diesem Aufbau zugehörigen Grundmaschinenschnittstelle erman-

Kt gelt es aber an einigen nützlichen Merkmalen, wenn ein privilegierter Softwarekern geschrieben wird. Diese

& Merkmale, die im beschränkten Umfang bei einigen Rechnersystemen der dritten Generation bereits vorhanden

ff! 55 sind, und die sicherlich bei Systemen der vierten Generation vorhanden sein werden, umfassen die Speicher-

ia adressierung auf der Deskriptorbasis, mehrschichtige Schutzringe und Prozeßsynchronisations-Stammwörter.

|j Eine kürzlich durchgeführte Untersuchung der virtuellen Maschinenaufbauten für diese komplizierten Syste-

ψ me basierte auf einer wichtigen Unterscheidung zwischen zwei verschiedenen Fehlertypen. (Siehe U. O. Gagliar-

■f di und R. P. Goldberg — Virtualizable Architectures — in »Proceedings ACM AICA International Computing

i| 60 Symposium«, Venedig, Italien.) Der erste Fehlertyp ist mit den sichtbaren Merkmalen der Software einer

M Grundmaschinenschnittstelle, wie einem privilegierten/nicht privilegierten Zustand, mit den Adressenabbil-

f| dungstabellen, etc, verknüpft. Diese Fehler werden von dem privilegierten Softwarekern bzw. -Zentrum verar-

?! bettet, der die betreffende Schnittstelle laufen läßt. Der zweite Fehlertyp tritt lediglich bei virtuellen Maschinen-

|| systemen auf und wird dann erzeugt, wenn bei einem Prozeß versucht wird, einen Betriebsmittelplan zu ändern,

^r% b5 den der virtuelle Maschinenmonitor festhält, oder wenn 'ersucht wird, auf Betriebsmittel Bezug zu nehmen, die

H bei einer virtuellen Maschine verfügbar sind, nicht jedoch in dem realen System (z. B. ein virtueller Maschincn-

₍I Speicherplatz, der im realen Speicher nicht vorhanden ist). Diese Fehler werden lediglich durch den virtuellen

s| Maschinenmonitor bzw. das virtuelle Maschinenübcrwachungsprogramm VMM verarbeitet; wobei sie jedoch

für die virtuelle Maschine vollständig unsichtbar sind. Fehler, welche durch Bezugnahme auf nicht verfügbare reale Betriebsmittel hervorgerufen werden, wurden dabei jedoch nicht klar identifiziert. Die hier gezogene Unterscheidung basiert auf einer späteren Untersuchung von Goldberg. (Siehe »Architectural Principles for Virtual Computer Systems« — Phd. Thesis Division of Engineering and applied Physics — der Harvard Universität, Cambridge, Massachusetts, USA.)

Da herkömmliche Aufbauten lediglich den früheren Fehlertyp unterstützen, werden herkörr..nliche virtuelle Maschinenmonitore dazu gebracht, beide Fehlertypen auf einen einzigen Mechanismus darzustellen. Wie bereits erwähnt, geschieht dies dadurch, daß man sämtliche Prozesse der virtuellen Maschine in der nicht privilegierten Betriebsart laufen läßt, daß unmittelbar sämtliche Fehler zu dem virtuellen Maschinenmonitor VMM hingelangen und daß der virtuelle Maschinenmonitor VMM sämtliche Fehler des ersten Typs zu dem privilegierten Softwarekern der virtuellen Maschine »zurückreflektiert«. Eine offensichtliche Verbesserung dieser Situation kann jedoch durch Schaffung eines Aufbaus erreicht werden, der beide Fehlertypen erkennt und aushält.

Obwohl relativ wenige Maschinenysteme auf modernen Rechnersystemen aufgebaut worden sind, stützt sich die Mehrzahl der heutigen Rechnersysteme nicht auf virtuelle Maschinen und kann sich demzufolge auf derartige Maschinen auch nicht stützen. Die wenigen, gegewärtig laufenden virtuellen Maschinen, z. B. das System CP-67, benutzen unpraktische und unangemessene Verfahren mit Rücksicht auf ihren ungeeigneten Aufbau. In jenen Fällen, in denen Rechneraufbauten bzw. -architekturen speziell für virtuelle Maschinen ausgelegt vorgeschlagen worden sind, haben diese Aufbauten an zwei Schwächen gelitten: Entweder sind die betreffenden Aufbauten nicht imstande gewesen, moderne komplexe Operations- bzw. Betriebssysteme direkt auf den virtuellen Maschinen zu unterstützen, oder sie sind nicht imstande gewesen, die gesamte herkömmliche Unannehmlichkeit und dit Betriebskosten eines bedeutsamen Software-Eingreifens zu vermeiden, die mit der Unterstützung einer virtuellen Maschine verknüpft sind.

Ef besteht somit ein Bedarf an eine virtuelle Maschinenanlage, die in einem existierenden herkömmlichen Rechnersystem oder in Rechnersystemen der vierten Generation ausgeführt werden kann, wobei eine Speicheradressierung auf Deskriptionsbasis. mehrschichtiger Schutzringe und Prozeßsynchronisations-Stammwörter, wie Semaphoren, etc. vorgesehen sind. Darüber hinaus sollte ein derartiger virtueller Maschinenaufbau dadurch ausgeführt sein,daß lediglich eine relativ kleine Anzahl von Hardware/Firmware-Modifikationen vorgenommen werden müssen.

Unter Zugrundelegung des dem Anmeldungsgegenstand am nächsten kommenden Standes der Technik jntsprechend dem erwähnten IBM-System (s. IBM System Journal, No. 2. 1972, S. 99—149) ist es Aufgabe der vorliegenden Erfindung, eine Rechenanlage der im Oberbegriff des Patentanspruchs 1 genannten Art anzugeben, die eine direkte Verarbeitung sämtlicher Prozeßausnahmen zu einer jeweils in Ausführung befindlichen virtuellen Maschine ohne besondere Softwaremaßnahmen in effizienter Weise ermöglicht.

Erfindungsgemäß wird dies dadurch erreicht, daß der Gastrechner mit einer Hardware-Virtualisierungsanordnung versehen ist, welche interne Register aufweist, die über entsprechende Leitungspfade mit einem ersten Register, das die gerade in Ausführung befindliche virtuelle Maschine identifiziert, und mit einem zweiten Register, das die Betriebsebene der gerade in Ausführung befindlichen virtuellen Maschine anzeigi, verbunden sind und für diese Zwischeninformationen speichern, und daß die Hardware-Virtualisierungsanordnung derart ausgebildet ist, daß sie in Abhängigkeit von einem Prozeßnamen, den sie von einei.i Prozeßnamensregister empfängt, und von Steuersignalen, die eine Zuordnung zwischen Prozeßnamen und Betriebsmitteln und Zuordniingen zwischen Betriebsmitteln in mehreren Betriebsebenen angegeben, jeweils einen Namen eines realen Bctricbsrnittels erzeugt und diesen über einen Leitungspfad in ein weiteres Register abgibt.

Eine vorteilhafte Weiterbildung der Erfindung ist weiterhin dadurch gekennzeichnet, daß die Hardware- ^virlualisierungsanordnung zusätzlich mit Zwischenspeicherregistern sowie assoziativen Registern versehen ist, wobei letztere der Einspeicherung der zuletzt benutzten Zuordnung dienen.

Gemäß der Erfindung weist eine virtuelle Maschine, die in einem existierenden Rechnersystem, wie dem Rechnersystem Honeywell der Serie 6000, ausführbar ist, eine Hardware-Virtualisierungsanordnung auf, welche den Ablauf von Prozessen in der virtuellen Maschine unter einem zusammengesetzten /- und Φ-Pten durchführt. Der Φ-Phn, der den sichtbaren Plan für die Bedienungssystemsoftware darstellt, die in der virtuellen Maschine läuft, wandelt die Prozeßnamen in Betriebsmittelnamen um. Der /-Plan, der den für die gesamte Software der virtuellen Maschine unsichtbaren Plan darstellt, formt hingegen die virtuellen Betriebsmittelnamen in reale Betriebsmittelnamen oder in andere virtuelle Betriebsmittelnamen um; der betreffende Plan kann dabei mehrere Rekursionsebenen aufweisen. Der S^-Plan ist somit ein Intra-Ebenenplan, der eine Beziehung innerhalb einer einzigen Ebene ausdrückt, während der /-Plan ein Inter-Ebenen-Plan ist, der eine Beziehung zwischen den Betriebsmitteln zweier benachbarter Ebenen von virtuellen Maschinen darstellt.

Im Rahmen der Erfindung wird der <?-PIan mit dem rekursiven /-Plan kombiniert, um einen generellen zusammengesetzten Plan zu erhalten. Die Hardware-Virtualisierungsanordnung benutzt dabei eine Datenbasis, mit welcher der /-Plan darstellbar ist, wobei sie einen Befehl bereitstellt, um den jeweiligen /-Plan anzusteuern. Die Virtualisierungsanordnung stellt ferner eine Einrichtung zur Identifizierung der gerade laufenden virtuellen Maschine bereit und liefert einen Mechanismus zur Verarbeitung bzw. Behandlung von Fehlern innerhalb der virtuellen Maschinen.

Die Hardware-Virtualisierungsanordnung ermöglicht die direkte Verarbeitung bzw. Behandlung sämtlicher Prozeßausnahmen innerhalb der ausführenden virtuellen Maschine ohne einen Softwareeingriff des virtuellen Maschir.enmonitors zu benötigen. Sämtliche Hilfsquellenfehler (virtuelle Maschinen-Fehler bzw. VM-Fehler), die durch eine virtuelle Maschine erzeugt worden sind, werden dabei dem in Frage kommenden virtuellen Maschinenmonitor (VMM) zugeführt, ohne daß eine Kenntnis der in der virtuellen Maschine ablaufenden Prozesse existiert, wobei dies unabhängig von der Rekursionsebene erfolgt.

An Hand von Zeichnungen soll die Erfindung nachstehend beispielsweise näher erläutert werden. Es zeigt

F i g. 1 a bis lc zum Stand der Technik gehörende Anordnungen in Blockdiagrammen, die zur Erläuterung der Erfindung von Nutzen sind und die den zum besseren Verständnis der Erfindung dienenden Stand der Technik darstellen;

Fi g. Id und 2a bis d schematische Blockdiagramme eines rekursiven /-Plan-Prozeßes so wie er im Rahmen der Erfindung verwendet wird:

F i g. 3a und b schematische Blockdiagramme der Prozeßausnahme und Fehlererzeugung bei einer virtuellen Maschine gemäß der Erfindung;

Fi g. 4 ein schematisches Blockdiagramm eines /-Planes unter Veranschaulichung einer virtueller Maschinentabelle (VMTAB), eines virtuellen Maschinensteuerblocks (VMCB) und von virtuellen Maschinenseitenteilen;
F i g. 5 ein Flußdiagramm eines in Firmware ausgebildeten Befehls zur Änderung des Identifizierungsregisters einer virtuellen Maschine;

Fi g. 6a ein Flußdiagramm eines in Firmware und Hardware ausführbaren /-Plan- und 0-Plan-Aufbaus;
F i g. 6b ein Blockdiagramm der Hardware-Virtualisierungsanordnung gemäß der Erfindung;
Fig.7 ein Diagramm einer Ausführungsform einer Hardware-Virtualisierungsanordnung von Fig.6b mit bestimmten /- und ^-Plänen und

F i g. Ca und b Blockdiagramme einer weiteren Ausführungsform einer Hardware-Virtualisierungsanordnung von F i g. 6b mit abgeänderten /- und ^-Plänen.

Da virtuelle Rechenmaschinen gerade erst entwickelt worden oind, wird zum besseren Verständnis der

vorliegenden Erfindung das Prinzip derartiger Anlagen nochmals erläutert. Zur Erzielung eines vollständigen Verständnisses der Lehren asr vorliegenden Erfindung wird es jedoch als helfend erachtet, eine bevorzugte Ausführungsform zu beschreiben, und zwar durch Entwicklung eines Modells der Erfindung, welches die Abbildung bzw. Darstellung und Adressierung von Betriebsmitteln durch einen in einer virtuellen Maschine ablaufenden bzw. ausgeführten Prozeß darstellt Um die zu Grunde liegenden Aufbauprinzipien von virtuellen Maschinen abzuleiten, ist darüber hinaus ein Modell erwünscht, welches die Darstellung der Ausführungsform eines Prozesses in bzw. auf einer virtuellen Maschine darstellt Da es erwünscht ist, daß diese Prinzipien auf den gesamten Bereich herkömmlicher Rechensysteme anwendbar sind — von Minirechnern über die gegenwärtigen Allzwecksysteme der dritten Generation, einschließlich gewisser zukünftiger Maschinen (möglicherweise der vierten Generation) -«- ist es erforderlich, ein Modell zu entwickeln, welches die gemeinsamen Punkte aller dieser Systeme wiedergibt. Das Modell sollte dabei nicht von den besonderen Planstrukturen abhängen, die für die Software der erläuterten Maschine sichtbar sind. Eigenschaften, wie eine Speicherverschiebung oder ein

Überwachungszustand, sind Charakteristiken des existierenden Systems und treten auf, ob die erläuterten Maschinen nun virtuelle Maschinen sind oder nicht

Um virtuelle Maschinen einzuführen, wird eine unterschiedliche, unabhängige Ausbildung- bzw. Planstruktur festgelegt, die die Begriffe festhält, die für sämtliche virtuellen Rechnersysteme gemeinsam sind. Das Vereinheit- !ichungsthema ist dabei das Konzept einer virtuellen Maschinenkonfiguration und einer Reihe von virtuellen Betriebsmitteln. Diese Hilfsquellen bzw. Mittel, wie z. B. der Umfang des Hauptspeichers in der virtuellen Maschine, sind ein Merkmal sämtlicher virtuellen Maschinen, und zwar unabhängig von der besonderen Form der Speicher-Verschiebung, etc. des virtuellen Prozessors. Somit ist die Schlüsselstellung die Beziehung zwischen den Betriebsmitteln in der Konfiguration der virtuellen Maschine und jenen Betriebsmitteln in der Konfiguration der realen Gastmaschine. Lediglich nach vollständigem Verhältnis dieser Beziehung brauchen durch das Vorhandensein irgendeiner zusätzlichen Abbildungs- bzw. Planstruktur eingeführte Kompliziertheiten behandelt zu werden.

Im folgenden wird ein Betriebsmittelplan erläutert. Ein Modell für eine Betriebsmittelabbildung einer virtuellen Maschine wird entwickelt, und zwar durch Festlegen des Satzes von Betriebsmitteln V= (vq, "ι · · - ^m), die bei 4* der virtuellen Maschinenkonfiguration vorhanden sind, und des Satzes von Betriebsmitteln R=(ro, η ... r„), die bei der realen Gastkonfiguration vorhanden sind. (Betriebsmittelplätze, und zwar sowohl reale als auch virtuelle, sind stets als Rechtecke in den Figuren dargestellt.) Die Sätze Vund R enthalten sämtliche Hauptspeichernamen, adressierbare Prozessorregister, Eingabe/Ausgabe-Einrichtungen, etc. Im Zuge der folgenden Erläuterung werden jedoch der Einfachheit halber sämtliche Betriebsmittelnamen so behandelt, als seien sie Speichernamen, d. h. so Adressen. Da Speicherplätze dazu herangezogen werden können, auf andere Betriebsmittelnamen Bezug zu nehmen, wie auf Prozessorregister, z. B. DEC PDP-IO, oder auf Eingabe/Ausgabe-Einrichtungen, z. B. DFiC PDP-11, geht keine Allgemeingültigkeit dadurch verloren, daß sämtliche Betriebsmittelnamen als Speichernamen behandelt werden.

Da von vornherein keine entsprechende Beziehung zwischen virtuellen und realen Betriebsmittelnamen angenommen ist, muß eine Möglichkeit einbezogen werden, virtuelle Namen den realen Namen während des Auslaufs der virtuellen Maschine zuzuordnen. Zu diesem Zweck wird für den jeweiligen Augenblick eine Fuktion definiert:

f_:V—RU\t\

Hierin bedeutet /die Betriebsmitteldarstellung des Satzes V von virtuellen Betriebsmitteln in den Satz R, in Vereinigung mit /, wobei R der Satz von realen Betriebsmitteln des Systems und / das Ergebnis bedeuten, welches das Auftreten eines nicht programmierten Sprungs oder Fehlers anzeigt. Dies gilt dann, wenn y G V und ζ G Äsind.

si .ι Θ Vzcigt an. daß.ν ein Element des Satzes Vist. und ζ G R zeigt an, daß /ein Element des Satzes R ist (dies bedeutet, daß/ein virtuelles Betriebsmittel ist und daß ζ ein reales Betriebsmittel ist. Um die Elemente des einen Satzes den Elementen des anderen Satzes zuzuordnen gilt dann:

f(y) - {

ζ, wenn ζ der reale Name für den virtuellen Namen y ist, U wenn y nicht einen entsprechenden realen Namen besitzt.

Dies bedeutet, daß /(^gleich ζ ist, wenn ζ das reale Betriebsmittel ist, die dem virtuellen Betriebsmittel y entspricht. Im übrigen ist Zugleich f, wenn y nicht ein entsprechendes reales Betriebsmittel zu dem betreffenden Zeitpunkt zugeteilt ist

Der Wert f (y)= t ruft einen nicht programmierten Sprung oder Fehler zur Ausführung einer gewissen Fehlerbehandlungsprozedur in der Maschine hervor, deren Betriebsmittelsatz R ist, was bedeutet, daß es sich um die Maschine R handelt Der Klarheit wegen wird dieser Vorgang hier als VM-Fehler bezeichnet, was keine Ausnahme bedeuten solL !O

Die Funktion /wird als Betriebsmittelplan oder -darstellung, bzw. als virtueller Maschinenplan oder /-Plan bezeichnet Die Software bei einer realen Maschine R, die den /-Plan einstellt und (normalerweise) eine Steuerung auf einen VM-Fehler hin erhält, wird als »virtueller Maschinenmonitor VMM« oder als »virtuelles Maschinenüberwachungsprogramm« bezeichnet

Das Modell legt dabei nicht fest, ob der /-Plan ein Seitenplan, ein Verschiebungs-Grenzen-Plan (R-S-Plan) oder ein Plan irgendeiner anderen Form ist Wenn jedoch von virtuellen Maschinen gesprochen wird, \ü iie Aufmerksamkeit normalerweise auf solche Fälle beschränkt in denen die virtuelle Maschine eine zuverlässige Nachbildung der realen Maschine ist und in denen das Leistungsvermögen des virtuellen Systems mit dem des realen Systems vergleichbar ist

im folgenden sei die Rekursion näher betrachtet: Das oben entwickelte Rekursionspianmodei erstreckt sich direkt auf die Rekursion, und zwar durch Interpretierung von V und R als zwei benachbarte Ebenen virtueller Betriebsmittel. Somii befindet sich die reale physikalische Maschine in der Ebene 0, während der /-Plan die Ebene η +1 als Ebene π darstellt

Die Rekursion für virtuelle Systeme ist eine Eigenschaft von beachtlichem praktischen Interesse. In ihrer einfachsten Form liegt die Motivation für eine virtuelle Maschinenrekursion darin, einerseits herkömmliche Bedienungs- bzw. Betriebssysteme auf der virtuellen Maschine laufen zu lassen, um eine Überprüfung der virtuellen Maschinenmonitorsoftware auf einer virtuellen Maschine durchführen zu können, wobei jedoch andererseits auch der Wunsch besteht, zumindest in manchen Fällen eine virtuelle Maschine in zweifacher Verechachtelung laufen zu lassen.

Wenn die Virtualisierung nicht rekursiv ist, kann man lediglich eine einfache Vorschaltung von virtuellen Maschinen erzeugen; deshalb ist es unmöglich, die Software zu korrigieren, die die virtuellen Betriebsartausnahmen behandelt (virtueller Maschinenmonitor VMM), während der reguläre Betrieb in dem System aufrechterhalten wird. Um eine Korrektur des virtuellen Maschinenmonitors VMM gleichzeitig mit anderen Aktivitäten vorzunehmen, ist es in der Tat erforderlich, daß es einer der virtuellen Maschinen ermöglicht wird, ihrerseits einen virtuellen Maschinenmonitor bzw. ein virtuelles Maschinenüberwachungsprogramrn laufen zu lassen und somit eine zweite Ebene von virtuellen Maschinen zu bilden. Unter einem praktischen Gesichtspunkt heraus ist somit eine begrenzte Rekursionsfähigkeit mit zwei Ebenen der Verschachtelung für die virtuellen Maschinen ausreichend. Auf Grund dieser Minimalforderung kann die virtuelle Maschinenmonitorsoftware, gleichzeitig mit anderen Aktivitäten des Systems korrigiert werden.

In der folgenden Erläuterung soll eine Übereinkunft entsprechend einer PL/I-Ausdruckweise benutzt werden, bei der eine virtuelle Maschine mit η Ebenen in ihrem Namen π Silben aufweist.

In F i g. Id ist in einer schematischen Darstellung die virtuelle Maschine gemäß der Erfindung gezeigt, die eine Rekursionsfähigkeit besitzt. Bei der Gastmaschine befindet sich in der Ebene 0 in virtueller Maschinenmonitor VMM, während in der Ebene 1 zwei virtuelle Maschinen VMi und VM 2 vorhanden sind. Die virtuelle Maschine VM1 besitzt dabei einen Baumnamen 1, während die virtuelle Maschine VMI einen Baumnamen 2 aufweist. In der Ebene 2 sind zwei virtuelle Maschinen VM3 und VM4 vorhanden, wobei die virtuelle Maschine VM3 einen Baumnamen 2.1, und die virtuelle Maschine VM4 einen Baumnamen 2.2, besitzt. (In Fig. Id ist der Ablauf bzw. die Ausführung der virtuellen Maschine mit 2.1, d. h. drei Ebenen unterhalb der Ebene 0 und einschließlich der Ebene 0 angegeben.) Es dürfte ersichtlich sein, daß η Silben im Namen der virtuellen Maschine in der Ebene η vorhanden sind und daß demgemäß ein Hinweis dafür vorhanden irt, daß η Pläne bzw. Abbildungen zusammenzusetzen sind, um tatsächlich die Betriebsmittel aus der Ebene η der virtuellen Maschine in die reale Gastmaschinc zu übernehmen. Diese Namensgebungsübereinkunft benennt eindeutig die Vorfahren der ausführenden virtuellen Maschine und insbesondere deren Eltern. Wenn die ausführende virtuelle Maschine somit einen virtuellen Maschinenfehler erzeugt, kann die Hardware/Firmware zu dem Schluß kommen, daß die Steuerung auf den virtuellen Maschinenmonitor VMM übertragen werden muß, der in bzw. auf der virtuellen Maschine 2.1 läuft, die der Ursprung für die ausführende bzw. laufende virtuelle Maschine 2.1.1 ist.

Dieser Baumname wird als Index sowohl für den virtuellen Betriebsmittelsatz, z. B. Vu, als auch für den entsprechenden /-Plan, z. B. /u, benutzt.

Wenn somit folgende Voraussetzungen gegeben sind:

fr. V₁... R

(Ebene 1, Betriebsmittelplan für die Darstellung V, in R)

tu: Vu... V₁

(Ebene 2, Betriebsmittelplan für die Darstellung bzw. Abbildung V,., in Vi).

Sodann wird der virtuelle Betriebsmitteliiamen y der Ebene 2 in f₂ (fu (y)) oder f, ο /,, (y) dargestellt bzw. abgebildet. Die Bezeichnung »o« ist dabei der aus der Mathematik bekannte herkömmliche Funktionszusnmmensetzungsoperator.

Der obige Plan bzw. die obige Darstellung gemäß F i g. 2a veranschaulicht, wie zwei virtuelle Maschinenpläne f\ und fu zusammengesetzt werden können, um eine Darstellung bzw. Abbildung von der Ebene 2 in die Ebene 1 und von dort in die Ebene 0. d. h. bis zu der realen Gastmaschine zu erreichen. Wenn zuvor ein /-Plan bestimmt worden ist können die virtuellen Betriebsmittel in reale Betriebsmittel oder in virtuelle Betriebsmittel einer anderen Ebene überführt werden oder es kann ein Fehler hervorgerufen werden. In F i g. 2a zeigt die erfolgreiche fehlerfreie Überführung bzw. Abbildung der virtuellen Maschinenbetriebsmittel der virtuellen Maschine V_1-1 in die der virtuellen Maschine Vi bzw. der realen Gastmaschine R, d. h. f\ (fu (z)).

In der obigen Funktion Λ bzw. /u sind zwei mögliche Fehler erkennbar:

1) Übertragungsfehler der Ebene-2-Betriebsmittel (virtuelle Maschine) auf dem virtuellen Maschinenmonitor der Ebene 1, d. h. /,., (v)= t. (Siehe F i g. 2b.)

2) Übertragungsfehler der Ebene-1-Betriebsmittel (virtuelle Maschine) zu dem virtuellen Maschinenmonitor der Ebene 0 (der realen Gastmaschine), d. h. /ι ο f_u (_v)= ι (Siehe F i g. 2c.)

In F i g. 2b ist ein Fehler veranschaulicht, der deshalb auftritt, weil die Betriebsmittel des virtuellen Betriebsmittelraumes Vu. bei der Abbildung, in dem virtuellen Betriebsmittelraum V₁ in Vj nicht vorhanden sind, so daß die in V_u existierende Seite V_x fehlt. Demgemäß resultiert daraus ein Fehler f. Dies ist ein Fehler des Typs 1 (d. h. ein Ebene-2-Fehier) oberhalb von /_u (y)= L In F ig. 2c zeigt hingegen ein Fehler des Typs 2 (Ebene-1 -Fehler) bei welchem Betisbsmittel des virtuellen Raumes Vu, erfolgreich in dem virtuellen Hilfsquellenraum Vi abgebildet werden, worauf jedoch die Abbildung in dem realen Betriebsmittelraum R ausfällt

Bei dem Fehler des Typs 1 kann im Rahmen der Erfindung dieser Fehler direkt zu dem virtuellen Maschinenmonitor VMMm der Ebene V_x gelangen, und zwar ohne die Kenntnis des virtuellen Maschinenmonitors, der auf der realen Gastmaschine R läuft — was eine erhebliche Verbesserung darstellt In dem Fall jedoch, daß der Plan fu erfolgreich in der Abbildung von V, ist und demzufolge in V₁ entsprechende Betriebsmittel findet der Plan /i

bei der Abbildung in R jedoch ausfällt und demzufolge entsprechende Betriebsmittel in R nicht findet, bewirkt der Fehler t eine Steuerung in Richtung des virtuellen Maschinenmonitors, der realen Gastmaschine, und zwar ohne Kenntnis des virtuellen Maschinenmonitors der Ebene Vi.

Bei bisher bekannten virtuellen Maschinen, wie dem System CP-67, bei denen eine Realisierung der Rekursion versucht wurde, wenn z. B ein Fehler in der Ebene 1 auftrat, würde der Fehler dadurch verarbeitet, in dem auf die

Ebene 0 Bezug genommen wird. Da dort jedoch kein realer Fehlerbehandlungsmechanismus vorhanden ist, wird dieser Fehler durch Software zur Ebene 1 zurückreflektiert, was einen wesentlichen Softwareüberhang nach sich zieht.

Im allgemeinen kann ein zusammengesetzter /-Plan irgendeinen Fehler hervorrufen. Es existiert jedoch eine Klasse von Plänen, die sogenannten inklusiven Pläne, die lediglich den ersten Fehler (Ebene-2-Fehler) hervorru-

fen können. Der Verschiebungs-Grenzen-Plan (R- B-Plan) ist dabei ein inklusiver Plan, was jedoch nicht für den Seiten-Plan zutrifft. Die Inklusiv-Eigenschaft impliziert die Möglichkeit einer einfachen Rekursionsausführung.
Für den generellen Fall der Ebene-n-Rekursion wird der virtuelle Nameyder Ebene η wie folgt dargestellt

f_tof_uo...of_h...i(y).
(Siehe F i g. 2d.)

Das vorliegende Modell kann dabei dazu herangezogen werden, die rekursiven virtuellen Einzelzustands-Maschinen zu beschreiben (Siehe Tabelle I).
Im folgenden sei der Prozeßplan Φ näher betrachtet. Das betreffende Modell, gibt lediglich die Darstellung

von Betriebsmitteln in einem Rechnersystem wieder. Diese Maschinenausführung genügt jedoch um die Virlualisierung bei bestimmten Minirechnern, wie dem System DEC PDP-8, zu erläutern, wobei derartige Rechner seine örtliche Darstellungs- bzw. Planstruktur zeigen. Die meisten gegenwärtigen Allzwecksysteme der dritten Generation weisen jedoch zusätzliche Software-sichtbare Hardware-Pläne auf. Diese zusätzliche Struktur kann einfach als Überwachungs/Problem-Zustände (IBM System/360) und als Verschiebungs-Grenzen-Regisier

(DEC PDP-10 und Honeywell 6000) oder als Komplex, in Form von Einteilungs-Seitenbildungs-Ringe (Multics-

Honeywell Informations Systems Inc. 6180) vorliegen. In zukünftigen Systemen der vierten Generation werden

diese Pläne wahrscheinlich sogar noch komplizierter; wobei sie eine formale Ausführung des Prozeßmodclls in Hardware/Firmware hervorbringen können.

Der entscheidende Punkt bezüglich jeder dieser Hardware unterstützten Pläne liegt jedoch darin, daß sie

gewissermaßen software-sichtbar sind. In bestimmten Systemen erstreckt sich die Sichtbarkeit auf die nicht privilegierte Software, in allen Fällen sind jedoch die Pläne für die privilegierte Software sichtbar.

Im allgemeinen wird ein Betriebssystem auf einer dieser Maschinen die Planinformation ändern, bevor die Ausführung eines Anwenderprozesses erfolgt. Die Planmodifikation könnte einfach dadurch erfolgen, daß die Prozessorbetriebsart in den Problemzustand gebracht wird, wobei sie jedoch so kompliziert sein kann, daß der

bo Prozeß-Adressenplatz, und zwar durch Umschalten seiner Segmenttabelle geändert wird, in jedem Fall werden die anschließende Ausführung des Prozesses und der Zugriff zu den Betriebsmitteln durch den gegenwärtigen örtlichen Plan beeinflußt.

Um den Ablauf von Prozessen auf einer virtuellen Maschine zuverlässig nachzubilden, muß daher die örtliche Planabbildungsstruktur in das Modell eingeführt werden.

Ein Modell des software-sichtbaren Hardware-Plans kann dadurch entwickelt werden, in dem der Salz von Prozeßnamen

P= (P₀. P,... P)

als Satz von Namen bestimmt werden wird, die durch einen in dem Rechensystem ablaufenden Prozeß adressierbar sind. In den F i g. 3a und 3b sind Prozeßräume bzw. -Plätze als Kreise dargestellt.

R = (r_u,n ■--/■„)

ist wie zuvor als Satz von (realen) Betriebsmitteinamen angenommen.

Für den aktiven Prozeß ist sodann eine Möglichkeit vorgesehen, um die Prozeßnamen den Betriebsmittelnamen während der Prozeßausführung zuzuordnen. Zu diesem Zweck ist mittels der gesamten software-sichtbaren Hardware-Darstellungsstruktur, z. B. des Überwachungs/Problemzustands, die Segmenttabelle, etc., eine Funktion für jeden Augenblick wie folgt bestimmt:

Φ: P-* R U\e\

Hierin bedeutet Φ die sichtbare Software-Tabelle des Betriebssystems für den Satz P von Prozeßnamen, und zwar zur Darstellung des ,Satzes R in Vereinigung mit e, wobei R der Satz von realen Betriebsmitteln des Systems bedeutet und wobei e das Ereignis bedeutet, durch welches angezeigt ist, daß eine Ausnahme aufgetreten ist. Wenn χ C P,y G R vorliegen, wobei χ C /"anzeigt, daß χ ein Element des Satzes P von Prozessen ist, und wobei y 0 R anzeigt, daß y ein Element des Satzes R (d. h. der Betriebsmittel) ist, dann gilt zur Zuordnung der Elemente eines Satzes zu den Elementen eines anderen Satzes die folgende Beziehung:

y.wennyder Betriebsmittelramen für den Prozeßnamen.ν ist,
e, wenn χ keine entsprechenden Betriebsmittel besitzt

Dies bedeutet, Φ (χ) ist gleich y, wenn y die realen Betriebsmittel sind, die dem Prozeßnamen χ entsprechen. Ansonsten ist Φ (χ) gleich e, wenn Ar zu einem bestimmten Zeitpunkt entsprechende reale Betriebsmittel nicht zugeteilt sind.

Der Wert Φ (χ)= e bewirkt das Auftreten einer Ausnahme bei einem gewissen Ausnahmebehandlungsvorgang, und zwar vermutlich bei einem privilegierten Vorgang des Betriebssystems dieser Maschine. Um eine Verwirrung mit VM-Fehlern zu vermeiden, sind die nicht programmierten Prozeßsprünge stets als Ausnahmen bezeichnet.

Die Funktion Φ wird als Prozeßplan oder 0-Plan bezeichnet. Der Ausdruck Prozeßplan wird unabhängig davon angewandt, welche Form der 0-Plan besitzt. In zukünftigen Systemen (der vierten Generation) kann Φ tatsächlich die Firmwarerealisierung von Prozessen darstellen, obwohl dies nicht notwendig ist. Ein bedeutender Punkt bezüglich Φ liegt noch darin, daß im Unterschied zu dem /"-Plan, der ein Interebenen- bzw. Zwischenebenen-Plan ist, der i^-Plan ein örtlicher oder Intraebenen-Plan ist und eine Ebene der Betriebsmitteldarstellung nicht kreuzt.

Im folgenden sei der Betrieb einer virtuellen Maschine näher betrachtet, nämlich /ο φ. Der Ablauf eines Prozesses auf einer virtuellen Maschine bedeutet den Ablauf eines Prozesses in einer Konfiguration mit virtueflen Belriebs-nitteln. Wenn ein Prozeß

P=(p».p\ ...p,)
auf der virtuellen Maschine

V=(Vi_n V_{... V_1n)

läuft, dann gilt wie zuvor:

wobei die virtuellen Betriebsmittelnamen ^anstelle der realen Namen in dem Betriebsmittelbereich des Planes ersetzt sind.

Die virtuellen Betriebsmittel werden ihrerseits in ihre realem Äquivalente durch den Plan f: V—R,dargestellt. Somit entspricht ein Prozeßname χ der realen Betriebsmittel ί(Φ(χ)). Im allgemeinen werden die ProzeOnamen in reale Betriebsmittelnamen unter der Wirkung des zusammengesetzten Planes

(ο φ; p^ RU\t)U\e\

dargestellt, wobei die betreffenden Symbole die obigen Bedeutungen haben.

Dieser /lisiiinniengcücl/lc I¹Iuπ reicht jedoch nicht aus. um einen Pro/cßnamcn in einen realen Betriebsmittel- fao numcn in einem von zwei Wegen zu überführen. Im Falle einer Prozeßnamenausnahme (Fig. 3a) wird die Steuerung ohne Kenntnis oder Eingreifen des virtuellen Maschinenmonitors auf die privilegierte Software des in derselben Ebene arbeilenden Systems übertragen. Ein Fehler eines virtuellen Namens bewirkt jedoch, daß die Steuerung auf einen Prozeß — eine Maschine in einer unteren Ebene übergeht., und zwar ohne Wissen oder Eingreifen des arbeitenden Systems (Fig. 3b). Obwohl diese Fehlerbehandlungssoftware in dem virtuellen Masehinenmoriitor VMV nicht Gegenstand eines /-Planes ist, da sie auf der realen Gastmaschine läuft, ist sie jedoch Gegenstand ihres 4^-Planes, und zwar gerade so, wie bei irgendeinem anderen Prozeß der Maschine.

In den F i g. 3a und 3b sind Prozeßräume Pdurch Kreise dargestellt, während virtuelle und reale Betriebsmit-

tel V bzw. R durch Quadrate dargestellt sind. Damit eine gültige Darstellung auftritt, wird ein Prozeßname P., in dem Prozeßraum Pm eine Stelle V₁, in dem virtuellen Betriebsmittelraurn V. und dann an eine Stelle b/.w. an einen Punkt R_d in dem realen Betriebsmittelraurn R übernommen. Fig. 3a zeigt dabei das Auftreten einer Ausnahme e in dem virtuellen Raum V, wobei die Steuerung in der virtuellen Maschine verbleibt, die in dem virtuellen Raum ^arbeitet. Diese Ausnahme e gelangt auf die privilegierte Software der virtuellen Maschine V. um von der privilegierten Software der virtuellen Maschine verarbeitet zu werden.

In Fig. 3b ist die ^-Darstellung bezüglich einer Stelle V₃ gültig, bei der Überführung V-, mit virtuellen Betriebsmitteln in reale Betriebsmittel ist jedoch ein Fehler t aufgetreten, welcher von dem virtuellen Maschinenmonitor behandelt bzw. verarbeitet wird, der auf der realen Maschine R läuft. In typischer Weise liegt dann ein Fail wie ihn F i g. 3a zeigt, vor, wenn das GCOS-Betriebssystem auf einer virtuellen Maschine V läuft und wenn ein im nicht privilegierten Betrieb laufendes bzw. betriebenes Anwenderprogramm unter dem GCOS-Betriebssystem versucht, einen privilegierten Befehl des Betriebssystems zu benutzen. In diesem Fall wird eine Ausnahme durch das GCOS-Betriebssystem verarbeitet bzw. behandelt.

Ein typischer Fall, wie ihn jedoch Fig.3b zeigt, liegt dann vor, wenn ein Programm in demselben oben erwähnten GCOS-Betriebssystem versucht, auf irgendeinen Teil des Hauptspeichers innerhalb des virtuellen Speichers Bezug zu nehmen, der durch das GCOS-Betriebssystem zugeteilt ist, dabei aber ermittelt, daß der bestimmte Teil des virtuellen Speichers nicht im Hauptspeicher zu dem betreffenden Zeitpunkt ist. Daraus resultiert ein Fehler' für" den viriueüen Maschincrirnoriitor der realen Gasmaschine R. Der Fehler wird dem virtuellen Maschinenmonitor VMM von R zugeführt, um verarbeitet zu werden.

Der Φ-Ρ\αη wird mit dem rekursiven /-Plan-Ergebnis zusammengefaßt, um den »allgemeinen« zusammengesetzten Plan

zu bilden.

Bei virtuellen Maschinen besteht somit unabhängig von der Ebene der Rekursion lediglich eine Anwendung des 0-Planes. welche von π Anwendungen eines /-Planes gefolgt t.'.d. Dies stellt ein bedeutendes Ergebnis dar, welches sich aus dem Formalismus der Unterscheidung der /- und ^-Pläne ergibt. In einem System mit einem komplizierten Φ-Plan, jedoch mit einem einfachen /-Plan kann somit eine n-Ebenen-Rekursion einfach und billig durchgeführt werden.

In dem dargestellten Modell sind in den APlänen die Betriebsmittel der Ebene n+\ ir. Betriebsmittel der Ebene η dargestellt. In gleicher Weise ist es jedoch auch möglich, einen /-Plan festzulegen, bei welchem die Betriebsmittel der Ebene /7+1 in Prozeßnamen der Ebene π dargestellt werden, wobei dieselben dann in Betriebsmittelnamen der Ebene η abgebildet werden. Dieser neue /"-Plan wird als /-Plan des Typs Il bezeichnet.

um ihn von dem hier erläuterten /-Plan des Typs I zu unterscheiden.

Nunmehr sei eine !nterpretalion des Modells gegeben. Das Modell ist zur Darstellung des Vorhandenseins zweier sehr unterschiedlicher grundsätzlicher Pläne in virtuellen Maschinen sehr wichtig. Frühere Konzepte haben dabei diesen Unterschied hervorgehoben bzw. die Pläne nicht angemessen voneinander getrennt. Der wesentliche Punkt besteht darin, daß die Pläne /und Φ zwei gänzlich verschiedene Pläne sind und untcrschicdlichen Funktionen dienen. A Priori besteht dabei keine Forderung, daß die Pläne /oder Φ eine besondere Form aufweisen und daß zwischen diesen Plänen eine feste Beziehung vorhanden ist. Der «P-Plan ist dabei die von dem Ausführungsprogramm her betrachtete Schnittstelle, während der /-Plan der von den Betriebsmitteln aus betrachtete Schnittsteile ist. Um bei einem vorhandenen Rechensystem die Fähigkeit des Aufbaus einer virtuellen Maschine zu schaffen muß lediglich / hinzugefügt werden während Φ bereits vorhanden ist. Die Wahl bezüglich des /-Plans, ob dieser vom Verschiebungs-Grenz-Typ (R-B-) Typ, vom Seitenbildungstyp, etc. ist. hängt davon ab, wie die Betriebsmittel der virtuellen Maschinen benutzt werden können. In jedem Falle ist der /-Plan rekursiv, während der ^-Plan es nicht zu sein braucht.

Wenn eine neue Maschine konstruiert wird, dann sind weder Φ noch /bereits bestimmt. Φ kann somit derart gewählt werden, um die vom Programmierer ausgesehenen Strukturen zu optimieren, während /so gewählt werden kann. dai3 die Ausnutzung der Betriebsmittel in dem System optimal erfolgt.

Eine weitere wesentliche Unterscheidung zwischen den beiden Plänen besteht darin, daß der /-Plan die Ebenen der Betriebsmittelzuteilung zwischen den virtuellen Maschinen trägt, während der 0-Plan Privilegierungsschichten (Ringe, Master/Slave-Betriebsart) innerhalb einer einzigen virtuellen Maschine festlegt.

In der nachstehenden Tabelle I ist ein Vergleich der Eigenschaften von virtuellen Rechensystemen angegeben, wobei die Anwendung des oben entwickelten Modells versucht bzw. vorgenommen wird. Aus der Tabelle I kann ersehen werden, daß keines der existierenden oder früheren vorgeschlagenen Systeme eine direkte Unterstützung von im allgemeinen vollständig virtuellen Maschinen bewirkt. Das System CP-67 weist dabei einen nicht-trivialen 0-Plan jsdoch keine direkte Hardwareunterstützung des /-Plan auf. Die Lösung von Lauer und Snow (3) bringt zwar eine direkte Hardwareunterstützung des /-Plans mit sich, weist jedoch einen trivialen 0-Plan auf. in dem Φ- Φ ist. Deshalb muß das System CP-67 Software zuzüglich der Schichtbeziehung des <?-PIans heranziehen, um einzelne Ebenen zu simulieren, während Lauer und Snow Software zuzüglich der Ebenenbeziehung des /-Plans benutzen müssen um Schichten zu simulieren. Das System ist sonst nicht allgemein verwendbar und bewirkt keine Unterstützung moderner Betriebssysteme, die direkt auf individuellen virtuellen Maschinen ablaufen.

Die sogenannten »Venedig-Vorschläge« von Gagliardi-Goldberg tragen zwar sowohl die Schicht- als auch die Ebenenbeziehung. Da die betreffenden Vorschläge jedoch nicht direkt zu einer Hardwareunterstützung für / führen, ist dabei ein Software-Eingriff erforderlich.

Tabelle I

Vergleich von Systemen, die ein virtuelles Maschinenmodell benutzen

System

Ά Pia η

Λ Pia η

Φ, = fo Φ

IBMCP-67

Gagliardi-Goldbcrg (Venedig-Vorschlag) 2 3

I.auer-Snow

Lauer-Wvcth

Goldberg HV
(dies isl die
vorl. Anmeldung)
5

Hardware (dritte Generation)	Hardware (kom plexe vierte Generation)	Hardware (Verschiebung- Grenzen)	Hardware (Untertei lung. Seitenbildung)	Hardware (vollständig beliebig)
Software	Software			Hardware (vollständig beliebig)
Software- Unterstützung für in Speicher umgesetztes Φ	Hardware Unterstützung für in Speicher umgesetztes Φ	—	—	Dynamisch ausgewertet
Software	Hardware		direkte Hard ware-dynamische Bildung

Direkter Zugriff /ti Φ Zugelassen?

l.'~ sen Schreiben

Rekursion und rekursiver Composer

nein	ja	—	—	ja
nein	nein	—	—	ja
Software-	Hardware	direkte	direkte	direkte
Zusammen	unterstützte	Hardware,	Hardware,	Hardware,
setzung	Zusammen	statische	dynamische	dynamische
	setzung	Zusammen	Zusammen	Zusammen
		setzung	setzung	setzung

Baum

Stapel

Stapel

Baum

Rekursive —

virtuelle Maschinen-Struktur, durch Hardware unterstützt

Zu den zuvor angegebenen Systemen wird auf folgende Veröffentlichungen hingewiesen:

Zu I: R. A. Meyer, L H. Seawright — »A Virtual Maschine Time-Sharing System« IBM Syst. Journal, Vol. 9,

No. 3,1970;
Zu 2: U. O. Gagliardi, R. P. Goldberg — »Virtualizable Architecture«, Proc. ACM AICA International

Computing Symposium, Venedig, Italien 1972;
Zu 3: H. C. Lauer, C. R. Snow — »Is Supervisor State Necessary«, Proc. ACM AICA Int. Comp. Symp.,

Venedig, Italien 1972;
Zu 4: H. C. Lauer, D. Wyeth — » A Recursive Virtual Machine Architecture« Preceedings ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. Cambridge, Mass« 1973.

Im folgenden werden Ausführungsformen der Erfindung näher erläutert. Zunächst sei die Hardware-Virtualisierungsanordnung (HV) näher betrachtet. Das obige virtuelle Maschinenmodeil bringt einen Einblick in existierende und vorgeschlagene Systeme mit sich und zeigt eine natürliche Einrichtung zur Realisierung virtueller Maschinen in sämtlichen herkömmlichen Rechensystemen. Da der /-Plan und der 0-Plan verschieden und bei virtuellen Rechnersystemen möglicherweise unterschiedlich sind, sollten sie durch unabhängige Strukturen dargestellt sein. Wenn ein auf einer virtuellen Maschine laufender Prozeß über einen Pozeßnamen auf Betriebsmittel Bezug nimmt, dann kann der erforderliche reale Betriebsmittelnamen durch eine dynamische Zusammensetzung des /"-Plan und des 0-Plans zu der Ausführungszeit erhalten werden. Darüber hinaus kann das Ergebnis unabhängig von einer Rekursion oder der besonderen Form von /und Φ festgehalten werden.

Die erste Ausführungsform ist dabei die verallgemeinerte Ausführungsform; welche die in den F i g. 5.6a und 6b dargestellten Strukturen umfaßt Die zweite Ausführungsform ist eine spezielle Ausführungsform, welche gemäß Fig.7 einen Plan <?=/?—B und einen /=Seitenbildungs-Plan im Hauptspeicherbereich einschließt.

13

wobei diese Ausführungsform kaum dem Rechner Honeywell 6000 hinzugefügt werden kann. Die in den F i g. 8a und 8h dargestellte dritte Ausführungsform welche dem Rechner Honeywell 6180 hinzugefügt werden kann, umfaßt einen ^-Aufteilungs- bzw. Segmentierungsplan und f- R— B im Hauptspeicherbereich. Die Hardware-Virtualisierungsanordnung HV, die nachstehend zu beschreiben ist, führt das obige Konzept der Erfindung aus. Die Hardware-Virtualisierungsanordnung kann dabei ein Teil einer Erweiterung eines vorhandenen Systems oder ein integraler Bestandteil der Konstruktion eines neuen Systems sein.

Im folgenden werden der Aufbau der Hardware-Virtualisierungsanordnung und deren Anforderung erläutert. Beim Aufbau einer Hardware-Virtualisierungsanordnung werden folgende Punkte berücksichtigt:

a) Die Datembank zur Speicherung von /;

b) ein Mechanismus zum Aufrufen von /;

c) die Mechanismen der Plan-Zusammenstellung, und

d) die Wirkung eines Fehlers in einer virtuellen Maschine.

In der folgenden Beschreibung wird eine Hardware-Virtualisierungsanordung beschrieben, die eine Planzusammenstellungsfunktion ausführt. Die folgende Beschreibung umfaßt die Beschreibung der Virtualisierungsanordnung, der unterstützenden Steuermechanismen, typischer Befehle, die für die Bildung einer rekursiven virtuellen Maschine benutzt werden, und verschiedener Fehierverarbeitungsmechanismen für verschiedene Fehlertypen.

Da vorhandene Rechnersysteme, wie die Rechnersysteme Honeywell Information Systems Inc., Serie 6000, DEC PDP-10 und das IBM-System/360, eine gewisse Form eines 0-Plans enthalten, wird lediglich die dem /-Plan zugeordnete zusätzliche Struktur erläutert. Im Rahmen der vorliegenden Erfindung werden dabei Einzelheiten dadurch erläutert, indem die vier oben aufgeführten Punkte im Hinblick auf die verallgemeinerte Ausführungsform beschrieben werden, worauf in der Folge dann die Struktur und Arbeitsweise der Hardware-Virtualisie- rungsanordnung der beiden besonderen Ausführungsformen besonders beschrieben werden.

In dem folgenden sei die Datenbank zur Darstellung von /'betrachtet. Ein virtueller Maschinenmonitor VMM in der Ebene η erzeugt bzw. bildet eine Datenbank und hält diese fest. Diese Datenbank stellt die /"-Plan-Beziehung zwischen zwei benachbarten Ebenen von virtuellen Maschinen-Betriebsmitteln dar, nämlich der Ebene η + 1 zu der Ebene n. Diese Datenbank wird derart gespeichert, daß sie für die virtuelle Maschine, d. h. die Ebene n+ 1, die die meiste privilegierte Software enthält, unsichtbar ist. In diesem Zusammenhang sei angenommen, daß aus wirtschaftlichen Gründen die Datenbank in dem Hauptspeicher gespeichert wird. Demzufolge kann / nicht in dem (virtuellen) Speicher der Ebene n+ 1 sein, sondern muß in dem (virtuellen) Speicher der Ebene η angeordnet werden.

Die einzige Forderung dahingehend, wo der /-Plan in einem Speicher der Ebene η gespeichert wird, besteht darin, daß es für die Hardware-Virtualisierungsanordnung HV möglich sein muß, den betreffenden Plan durch Abgabe eines bestimmten Algorithmus vom Anfang des Speichers der Ebene π zu lokalisieren. Die den unterschiedlichen virtuellen Maschinen in derselben Ebene entsprechenden /-Pläne können dabei entweder implizit oder explizit indentifiziert werden. In Fig.4 ist ein Blockdiagramm zur expliziten Identifizierung der /-Pläne gezeigt. F i g. 4 zeigt dabei in einem Block einen Hauptspeicher 400 in einer Ebene η einer virtuellen Maschine, und zwar in einem typischen Rechnersystem, wie dem Rechner Honeywell 6000. Die Wurzel bzw. BaJs 401 ist eine feste bekannte Adresse in dem Speicherblock 400; sie enthält neben anderer Information einen VMTAB-Zeiger 407, der seinerseits auf die Stelle in dem Speicherblock der virtuellen Maschinentabelle 402 hinzeigt, die mit VMTAB bezeichnet ist. Die VMTAB-Tabelle 402 enthält ihrerseits k Einträge von VMCB-Zeigern VM₁ bis VMk. Jeder VMCB-Zeiger zeigt auf einen entsprechenden virtuellen Maschinensteuerblock. So zeigt z. B. der VMCB-Zeiger VM1 auf den virtuellen Maschinensteuerblock VMCB-I 403, während der Zeiger VM 2 auf den virtuellen Maschinensteuerblock VMCB-2 404 zeigt, etc. Da der virtuelle Maschinensteuerblock VMCB eine Information zur Darstellung der Betriebsmittel der virtuellen Maschine bereitstellt, enthält er in typischer Weise solche Daten-Hardwarestrukturen, wie einen Speicherplan, einen Prozessorplan, Eingabe/Ausgabe-Plan und eine Zustandsinformation für die virtuelle Maschine. Der virtuelle Maschinensteuerblock VMCB ist daher im wesentlichen der /-Plan für eine bestimmte virtuelle Maschine. So ist z. B. der virtuelle Maschinensteuerblock VMCB-I der /-Plan für die virtuelle Maschine 1, während der virtuelle Maschinensteuerblock VMCB-2 der /-Plan für die virtuelle Maschine 2 ist, etc. Die spezielle Form des virtuellen Maschinensteuerblocks hängt dabei von dem tatsächlich benutzten /-Plan, z.B. von der R— ß-Seitenbildung, etc. ab. Wenn eine Seitenbildung benutzt wird, enthält der Speicherplan des virtuellen Maschinensteuerblocks im allgemeinen eine Seitentabelle 405 und 406.

Die in dem virtuellen Maschinensteuerblock festgehaltene zusätzliche Information, umfaßt eine Leistungsfähigkeitsinformation für den virtuellen Pozessor. Diese Information zeigt die vorhandenen oder fehlenden besonderen Merkmale und Befehle an. Diese Leistungsfähigkeits-Bits umfassen z. B. einen wissenschaftlichen Befehlssatz oder einen virtuellen Maschinenbefehlssatz (Rekursion). Wenn die Rekursion unterstützt wird, enthält der virtuelle Maschinensteuerblock genügend Information, um automatisch auf einen virtuellen Maschinenfehler einer niederen Ebene hin zu einer virtuellen Maschine in höherer Ebene zu starten (siehe F i g. 2c und F i g. 5, mit den Blöcken 506,512).

Die hier angegebenen Datensirukturen sind als Firmware bekannt, so daß sie im Zuge der Plan-Zusammensteiiung automatisch angewandt werden können; sie liefern Datenstrukturen, die sich zwischen der Ebene n+ 1 und der Ebene π beziehen.

Nunmehr sei der Mechanismus zum Aufruf von /erläutert. Um den /-Plan aufzurufen, erfordert die Hardware-Virtualisierungsanordnung ein zusätzliches Register und einen Befehl zur Manipulierung dieses Registers. Dieses Register ist gemäß F i g. 6 das virtuelle Maschinenidentifizierungsregister 653 (VMID) bzw. das virtuelle

enthält. Das virtuelle Maschinenidentifizierungsregister ist ein mehrsilbiges Register, dessen Silben sämtliche A-Pläne identifizieren, wobei letztere zusammengesetzt werden müssen, um einen realen Betriebsmittelnamen zu erhalten. Wenn es erwünscht ist, eine virtuelle Maschine in der Ebene 2 zu betreiben, dann enthält das virtuelle Miischinenidentifizierungsregister zwei Silben, die den Baumnamen der betreffenden virtuellen Maschine in dcr betreffenden Ebene darstellen. Ein Befehl LVMID (Lade das virtuelle Maschinenidentifizierungsregister) gemäß Fig. 5 hängt eine neue Silbe an das virtuelle Maschinenidentifizierungsregister an. Wenn demzufolge die vorhandene Silbenzahl in dem virtuellen Maschinenidentifizierungsregister 1 ist und wenn der virtuelle Maschinenmonitor wünscht, die virtuelle Maschine 3 zu betreiben, dann benutzt er einen LVMID-Befehl, um an die gegenwärtige Nummer »I« in dem virtuellen Maschinenidentifizierungsregister eine »3« anzufügen, wodurch eine Verbundzahl von »1.3« gebildet wird.

Das virtuelle Maschinenidentifizierungsregister (und der LVMID-Befehl) weisen dabei vier entscheidende Eigenschaften auf:

a) Der absolute Inhalt des virtuellen Maschinenidentifizierungsregisters VMID kann durch Software weder gelesen noch geschrieben werden;

b) das virtuelle Maschinenidentifizierungsregister der realen Gastmaschine ist die Null-Identifizierungsanordnung, d. h. sie enthält Null;

i^A'i^U^U A at- I \/ \Λ I Γν RofoM (i'tfrt Silken on /Iqr ,ilrdiollo ΚιΙ'ΐΡΛΚίηοη^οηΐίΐ^ίο'Μηη

li.UI£,ll<-IIUWI L. » t»l If UVIVIIIIUg«^lil/t.llUll UMO ΠΙ (UWlIV 1ItUJkIIIIIVIlIUWIIIIUbIbI UIIgJ

WI I IfIIL^ Uli UIIU

d) lediglich ein virtueller Maschinenfehler (oder ein Befehl, der die Operation einer virtuellen Maschine beende./beseitigt Silben aus dem virtuellen Maschinenidentifizierungsregister VMID.

In Fig.5 ist das Flußdiagramm des LVMID-Befehls gezeigt. Dieses Flußdiagramm veranschaulicht die Operation des LVMID-Befehls, während Realisierungseinzelheiten bezüglich einer speziellen Wahl des Planes weggelassen sind. Gemäß Fig.5 wird der LVMID-Befehl 501 aufgerufen, und außerdem erfolgt eine Bestimmung, ob eine virtuelle Maschinenfähigkeit (VM-Fähigkeit) 502 existiert oder nicht. Dies bedeutet, daß festgestellt wird, ob diese Maschine die Bildung virtueller Maschinen zuläßt. Wenn keine virtuelle Maschinenfähigkeit vorhanden ist, dann tritt eine VM-Fähigkeits-Ausnahme 503 auf, während ansonsten eine VMID-Silbe 504 abgeholt wird. Sodann erfolgt d^;e Feststellung, ob eine gerade arbeitende bzw. laufende virtuelle Maschine sich ■n einer höheren Ebene als der Ebene Null befindet; dies ist in dem Block S05 veranschaulicht. Ist die Ebene größer als »Null«, so wird die abgeholte Silbe (d.h. der Operand des LVMID-Befehls) in dem Feld »nachstc _ Silbe« in dem virtuellen Maschinensteuerblock VMCB 506 gespeichert (in dem Kästchen 506 von F i g. 5 wird das Mehrsilbenregister VMID als Index benutzt, um dem gegenwärtigen Steuerbiock VMCB VMID anzuzeigen; somit ist die Silbe des Operanden des LVMID-Befehls in dem Feld »nächste Silbe« des gegenwärtigen virtuellen Steuerblocks VMCB gespeichert). Die Silbe wird dabei dem Mehrsilbenregister VMID angehängt, worauf die Ebene erhöht wird (Kästchen 507, 508 und 509). Diese auf diese Weise festgelegte virtuelle Maschine wird nunmehr aktiviert indem ihr Prozesscrregisten ihr Speicherplan, etc. von ihrem virtuellen Maschinensteurblock VMCB 510 geladen worden. Das Feld »nächste Silbe« des aktivierten virtuellen

Maschinensteuerblocks VMCB 511 wird dann abgeholt. Wenn dieses Feld »Null« ist, vie dies im Kästchen 512

angegeben ist, dann ist im Kästchen 513 der Befehlsabschluß erreicht. Wenn das Feld »nächste Silbe« nicht

»Null« beträgt, dann gelangt man im Flußdiagramm vom Block 508 zu dem Block 513 und liefert das Verfahren 4η für den Beginn eines Unterbaums einer virtuellen Maschine, falls ein Fehler zumindest zwei Ebenen der virtuellen Maschinen übersprungen hat und dennoch eine virtuelle Maschinenstruktur unter der Ebene exist-'srt, in die der Sprung erfolgte.

Nunmehr sei die Plan-Zusammenstellung näher betrachtet: Die Plan-Zusammenstellungsanordnung bzw. -Zusammensetzungsanordnung gemäß Fig.6a und 6b liefert die dynamische Zusammensetzung des 0-Plans (möglicherweise Identität) und der aktiven APläne auf jeden Zugriff zu Betriebsmitteln hin. Der Φ-Plan ist dabei bekannt, während die aktiven APläne, d. h. die virtuellen Maschinensteuerblöcke, mit Hilfe des Mehrsilbenregistcrs VMID bestimmt werden. Das Flußdiagramm gemäß Fig.6a veranschaulicht den Plan-Zusammenstellungsmechanismus, während Realisierungseinzelheiten bezüglich der speziellen Wahl von Plänen weggelassen sind. Wie ersichtlich, nimmt die Zusammenstellungsanordnung einen Prozeßnamen Pan bzw. auf und entwickelt einen realen Betriebsmittelnamen R oder ruft einen virtuellen Maschinenfehler (VM-Fehler) hervor.

Gemäß Fig.6a wird die Plan-Zusammensetzungsanordnung 601 aufgerufen, worauf ein Prozeßname P gemäß dem Kästchen 602 abgeholt wird. Der Φ-Plan wird dann dem Prozeß P zugeführt, um Φ von P gemäß dem Kästchen 603 zu erhalten; ferner wird eine Bestimmung dahingehend getroffen, ob eine gültige Darstellung vorhanden ist oder nicht, wie dies im Kästchen 604 angegeben ist. Wenn eine ungültige Darstellung vorliegt, z. B. dann, wenn ein Versuch unternommen worden ist, außerhalb der Speichergrenzen Bezug zu nehmen, dann tritt eine Prozeßausnahme auf, die eine örtliche Ausnahme darstellt und die in der zuvor aufgerufenen virtuellen Maschine verarbeitet wird. Demgemäß ist diese Ausnahme für die privilegierte Software sichtbar, so daß die betreffende Ausnahme von dieser Software verarbeitet werden kann, wobei das VMID-Register nicht beeinflußt wird. Wenn auf der anderen Seite die Prozeß-0-Darstellung bzw. -Abbildung güllig ist, d. h. der Wert Φ von P erfolgreich berechnet worden ist, dann wird der Wert Φ von P kurzzeitig in dem Internregister-Betriebsmittelnamen R gemäß dem Kästchen 0O6 abgespeichert. Das VMID-Register wird dann überprüft, um festzustellen, ob es »Null« ist. Ist das betreffende Register »Null«, so ist die Zusammenstellung beendet, wobei der berechnete Betriebsmittelname R der reale Betriebsmittelname ist. Dies wird wirksam dadurch vorgenommen, indem der VMID-Wert 607 (nachgebildet im Internregister V) aufgenommen wird und indem der Ebenenwert 608 (abgebildet im Zwischenspeicherregister L) aufgenommen wird, worauf schließlich festgestellt wird, ob der Ebenenwert L »Null« ist, wie dies im Kästchen 609 angedeutet ist. Ist der betreffende Ebenenwert »Null« vorhanden, indem VMID »Null« beträgt, so sind R in der Tat die realen Betriebsmittel 610, worauf die Zusammenstellung gemäß

dem Kästchen 61t beendet wird |§

Wenn andererseits eine Ebene »Null« nicht vorhanden ist wie dies aus dem Kästchen 609 folgt dann sind R M

nicht die realen Betriebsmittel, worauf der /-Plan, der durch die nächste Silbe in dem VMID-Register bezeichnet ff

ist abgegeben werden muß. Der /-Plan wird jedoch nur aus dem virtuellen Maschinensteuerblock VMCB Jf

erhalten, der durch den laufenden Inhalt des VMID-Registers 612 bestimmt ist Dabei wird eine Feststellung getroffen, ob eine gültige Darstellung erfolgt ist oder nicht was durch das Kästchen 613 veranschaulicht wird. Wenn eine gültige Darstellung bzw. Planbildung erfolgt ist indem der Wert F(R), für die realen Betriebsmittel berechnet wird, so wie dies durch das Kästchen 613 angegeben ist dann muß bestimmt werden, ob Γ(R) die realen Betriebsmittel sind. Dies erfolgt durch Abgabe der Größen in den Blöcken 614, 615, 616 und 609.

Demgemäß wird der dargestellte Wert /, nämlich [(R), vervielfältigt als wären es die realen Betriebsmittel R, wie dies im Kästchen 614 veranschaulicht ist (dies bedeutet daß R durch [(R) ersetzt wird). Sodann wird die L-te Silbe von V, der Internregister-Nachbildung von VMID, zu »Null« gemacht was im Kästchen 615 angegeben ist und L, die interne Ebenenzahl wird auf »1« reduziert, wie dies im Kästchen 616 veranschaulicht ist Die Ebene L wird dann geprüft um zu bestimmen, ob sie »Null« ist wie dies im Kästchen 609 angegeben ist (dies bedeutet

is daß die Maschine nunmehr in der realen Maschinenebene ist). Ist die betreffende Ebene jedoch nicht »0«, so werden die Vorgänge gemäß den Blöcken 612 bis 616 wiederholt bis L=O ist, woraufhin bestimmt wird, daß R die realen Betriebsmittel 610 sind und daß die Zusammenstellung beendet ist. Um die Verarbeitung der Blöcke 612 bis 616 zu veranschaulichen, sei angenommen, daß der Baumname 1.2.4 in dem VMID-Register enthalten ist Das ViviiD-Register ist in "/nachgebildet worden (siehe Block 607), und R ist durch f(R) ersetzt worden (siehe Block 614). Die L-te Silbe von V ist dabei »4«: sie ist nicht »0«, wie dies im Block 615 veranschaulicht ist Demgemäß wird die Ebene L. die als interne Register festgehalten ist, um »1« reduziert, und der Baumname in V ist nunmehr 1.2, da die letzte Ebene »4« entfernt worden ist Nunmehr sind zwei Ebenen vorhanden, worauf die Ebene L gernäß dem Block 609 geprüft wird, wobei der Wert »0« festgestellt wird- Deshalb werden die Vorgänge gemäß den Blöcken 612 bis 616 wieder wiederholt Nunmehr besitzt das interne Identifizierungsregister V zwei Ebenen 1.2, und die L-te Silbe »2« liegt in der zweiten Ebene. Demgemäß wird gemäß dem Block 616 eine weitere Ebene entfernt, und der Name steht nunmehr als »1« dar. Die Ebene wird überprüft um festzustellen, ob sie »0« ist, wie dies durch den Block 609 veranschaulicht ist Da die betreffende Ebene nicht »0« ist, würde der Vorgang einmal wiederholt werden. Wenn L zu diesem Zeitpunkt gemäß dem Block 609 überprüft wird. L »Null« sein, und der Prozeß verzweigt sich zum Block 610. Die Zusammenstellung wird gemäß dem Block 611 beendet.

Zurückkommend auf den Entscheidungsblock 613 gemäß F i g. 6a sei bemerkt, daß in dem Fall, daß eine ungültige Darstellung vorgelegen hat. was bedeutet, daß die Betriebsmittel nicht lokalisiert werden konnten, ein virtueller Maschinenfehler gemäß dem Block 617 aufgetreten ist. Die in dem internen Identifizierungsregister V benutzte Silbe wird dann aus dem Block 618 entfernt worauf das interne Ebenen-Register L gemäß dem Block

619 hinsichtlich seines Inhalts verkleinert wird. Durch eine Überprüfung wird dann festgestellt ob die neue Ebene die Ebene »Null« ist. wie dies der Block 620 erkennen läßt. Wenn L nicht »Null« ist, muß das Feld

»nächste Silbe« in dem gegenwärtigen virtuellen Maschinensteuerblock VMCB auf »Null« gesetzt werden,

wie dies der Block 621 erkennen läßt In jedem Fall erfolgt eine Nachbildung des Inhalts des internen Ebenen-Registers L in dem Ebenen-Register gemäß dem Block 622, wobei das interne Identifizierungsregister V bezüglich seines Inhalts in dem VMID-Register gemäß dem Block 623 nachgebildet wird. Ein virtueller Maschinenfehler (VM-Fehler) wird der gerade aktivierten virtuellen Maschine gemäß dem Block 624 signalisiert.

F i g. 6b zeigt in Form eines Blockdiagramms einen Teil der verallgemeinerten Ausführungsform der Erfindung: die betreffende Figur bezieht sich dabei unmittelbar auf die F i g. 5 und 6a und die obige Beschreibung. Mit dem Bezugszeichen 650 ist die Hardware-Virtualisierungsanordnung bezeichnet; sie enthält die Hardware-Firmware und die internen Register 657,658,659 und 660, welche von der verallgemeinerten Hardware-Virtualisicrungsanordnung 650 benutzt weiden. Zwischenspeicher-Register 651 und assoziative Register 652 können aus Leistungsgründen in bestimmten speziellen Ausführungsformen hinzugefügt werden (siehe hierzu die weitere Erläuterung mit Fig. 8b). Unter der Steuerung der bestimmten Identifizierungsanordnung in dem VMID-Register 653 nimmt die Hardware-Virtualisierungsanordnung 650 einen vorgegebenen Prozeßnamen Pgemäß dem

so Block 654 auf, wobei sie einen Φ-Ρ\αη 661 und eine Sammlung von /-Plänen 662 benutzt, und erzeugt dabei einen realen Betriebsmittelnamen im Register 655. Mit dem VMID-Register 653 ist ein Ebenen-Register 656 verknüpft welches die gegenwärtige Ebene der aktiven virtuellen Maschine, d. h. die Anzahl der gültigen Silben in dem VMID-Register 653 anzeigt. Das VMID-Register 653 und das Ebenen-Register 656 sind jeweils so ausgebildet, daß sie eine vorgegebene maximale Größe aufweisen.

Die allgemeine Ausführungsform verwendet dabei folgende interne HV-Register: Das V-Register 657, in welchem das VMID-Register 663 nachgebildet wird (F i g. 6a, Bezugszeichen 607), welches dazu herangezogen wird, /-Plan-Werte bei der Algorithmuszusammenstellung zu erhalten (F i g. 6a, Bezugszeichen 612); wobei der betreffende Registerinhalt beim Auftreten eines Fehlers wieder in dem VMID-Register 663 nachgebildet wird, wie dies mit 664 angedeutet ist (F i g. 6a. Bezugszeichen 623); das L-RegiEter 659, in welchem das Ebenen-Reglster 666 nachgebildet wird (Fig. 6a. 608), welches bei der Algorithmuszusammenstellung herangezogen wird (Fig. 6a, 609, 616) und welches beim Auftreten eines Fehlers wieder in dem Ebenen-Register abgebildet wird, wie dies mit 667 angedeutet ist (Fig. 6a. 622): das R-Register 660. welches die besonders zusammengestellten Ergebnisse (Fig.6a.606, 614) festhält, bis die Zusammenstellung beendet ist, wobei R aus dem Register 660 an das reale Betricbsmittelregister 655 übermittelt wird (Fig. 6a. 610): das I-Register 658, welches dazu hcrangc/o-

h5 gen wird, an das VMID-Register 665 Silben während des LVMID-Befehls anzufügen (siehe F i g. 5, mit dem Blöcken 507,509,511,5!2).

Der obige Plan-Composer und der für den Aufruf von /dienende l.VMID-Befehl sind in l'inn- und I lardwiirv unter Heranziehung von bekannten Rechnersteuereinheiten realisiert (siehe Mikroprognininiierung: Principles

and Practices von Samir S. Husson, veröffentlicht von Prentice Hall, Inc Englewood Cliffs, New Jersey, 1970). Darüber hinaus wird ein assoziativer Speicher zur Steigerung des Leistungsvermögens verwendet, wie er an anderer Stelle bereits beschrieben wird (siehe US-Patentanmeldung, Serial No. 283 617 vom 24.8.1972).

Es gibt grundsätzliche Gründe, weshalb Prozesse auf der virtuellen Maschine mit einem Wirkungsgrad ablaufen können, der sich dem der realen Maschine nähert. Die meisten derzeitigen Rechen- bzw. Rechnersysteme, die eine Speicherabbildung (in dem ^-Plan) verwenden, gehen hinsichtlich des Programmverhaltens von Planungsannahmen aus. Diese Annahmen sind dabei auch auf virtuelle Maschinen anwendbar. Einige dieser Annahmen, welche die Rechnersystemleistung beeinflussen, sind dabei temporal, wobei spezielle Stellen von Bezugnamen durch laufende Programme bzw. Ausführungsprogramme vorgenommen werden. Bei Mehrprogrammsystemen wird der Prozeß-Plan, d. h. die Prozeßlage, nicht sehr häufig geändert, während bei virtuellen Maschinensystemen das VMID-Register, d. h. die Lage der virtuellen Maschine ebenfalls sehr häufig geändert wird.

Durch Kombination all dieser Lagebegriffe wird bestimmt, indem rekursive virtuelle Mehrebenen-Maschinen keine bedeutend unterschiedliche Leistung gegenüber realen Gastmaschinen haben müssen. Eine weitere Möglichkeit zur Angabe dieser Erkenntnis bzw. Feststellung besteht darin, daß festgestellt wird, daß die zeitliche Lage und die räumliche Lage namens-unveränderlich sind. Unabhängig davon, welcher Speicherblock aufgssufen wird oder wie oft er mittels zusammengesetzter APläne umbenannt wird, existiert weiterhin eine wesentliche Möglichkeit der Bezugnahme auf den betreffenden Speicherblock durch ein laufendes Programm. Somit zeigt eine virtuelle Maschine, die durch eine Plan-Zusammenstellungsanordnung und einen assoziativen Speicher unterstützt bzw. durch derartige Einrichtungen versorgt wird, eine vergleichsweise Leistung wie die reaie Gastmaschine.

Wenn der /-Plan und der Φ-Plan hinreichend einfach sind, dann kann auf die Assoziationsanordnung verzichtet werden. Wenn z.B. F=R-B ist (wobei R—B das Verschiebungs-Grenzen-Register bedeutet) und wenn Φ= Identität bedeutet, dann kann es für das H V-Register ausreichend sein, die »unsichtbaren Zwischenspeicher-Register« (die im allgemeinen in dem Zentralsteuerwerk enthalten sind) zu versorgen, um statisch zusammengesetzte R— B-Werte zu erhalten, die lediglich auf eine Ebenen-Änderung hin geändert werden.

Wenn Φ Seitenbildung (paging) bzw. Segmentierung umfaßt, dann erfordert die reale Gastmaschine aus Leistungsgründen selbst eine Assoziationsanordnung. Diese Assoziationsanordnung wird dabei durch die HV-Asf.oziationsanordnung ersetzt. Wenn der /-Plan einfach ist, z.B. f=R—B, dann wird die H V-Assoziationsanordnung sehr ähnlich ausgebildet sein; wenn /Seitenbildung umfaßt, ist die betreffende Assoziationsanordnung jedoch etwas anders ausgebildet. Die Wahl, ob das VMID-Register oder das Ebenen-Register als Teil des sogenannten Suchschlüssels der Assoziationsanordnung eingeschlossen ist, kann aus Preis-Leistungs-Gründen gctroflcn werden. Die typische Assoziationsanordnung, die hier zuvor durch Bezugnahme erfaßt worden ist, •transformiert einen Prozeßnamen Pdirekt in einen realen Betriebsmittelnamen, indem der obige Zusammenstelturigsfnechanisrnus überbrückt wird. Dies ist im einzelnen zu Beginn der Seite 154 einer Dissertation von R. P. Goldberg unter dem Titel »Architectural Principles for Virtual Computer Systems«, erhältlich an der Harvard Universität, November 1972, angegeben.

Nunmehr seien Ausführungsbeispiele einer Hardware-Virtualisierungsanordnung näher betrachtet. Wie oben angedeutet, dient die Hardware-Virtualisicrungsanordnung gewissermaßen als Zentralmechanismus im Aufbau eines neuen Rechnersystems oder als Erweiterung eines existierenden Rechnersystems. Im letztgenannten Falle ist ein bekanntes Rechnersystem M mil einem vorgegebenen Φ-Ρ\αη angenommen. Der Aufbau der Hardware-Virtualisierungsanordnung HV, d.h. die zusätzlichen Datenstrukturen, die neuen Befehle (LVMID), sowie die virtuellen Maschinenfehler (VM-Fehler), etc. legten eine neue Maschine /W'rnit einer hinzugefügten eindeutigen Funktionsfähigkeit fest. Die Hardware-Virtualsierungsanordnung garantiert dabei, daß die neue Maschine M' eine rekursive virtuelle Maschine ist, welche eine Hierarchie vom M'Maschinen mit M Maschinen als Anschlußknoten im Bedarfsfall zu unterstützen imstande ist.

Um die Operation der Hardware-Virtualisierungsanordnung zu verdeutlichen, seien zwei Anwendungsbeispiele erläutert: Das erste Beispiel wird um ein typisches System der dritten Generation herum er>iwickelt, welches System ähnlich dem Rechnersystem Honeywell 6000 ist. Während das zweite Beispiel um komplexes Rechnersystem entwickelt ist, welches dem Rechnersystem Honeywell 6180 ähnlich ist.

Im ersten Beispiel sind einige Merkmale eines typischen Aufbaus der dritten Generation vorhanden; wobei die durch die Hardware-Virtualisierungsgeneration eingeführten Erweiterungen angezeigt worden. Sodann wird die Ausführung gewisser Befehle veranschaulicht. Das unten angegebene Beispiel wird um ein kanonisches Rechnersystem der dritten Generation, ähnlich dem Rechnersystem Honeywell 6000, dem System DEC PDP-IO oder dem IBM System/360, entwickelt. Die herausragenden Eigenschaften des Aufbaus bzw. der Architektur sind dabei

1) die Unterscheidung zwischen privilegierter/nichtprivilegierter Betriebsart (Master/Slave, Überwachungsanordnung/Problem, etc.), und zwar als Teil des Befehlszählers (IC),

2) ein einzelnes Verschiebungs-Grenzen-Register (R-B), dessen absoluter Inhalt in der privilegierten Be- «) triebsart geladen werden kann, und

3) gewisse feste Speicherplätze im Hauptspeicher, in denen alte und neue R— B und Befehlszählerregister auf eine Prozeßausnahme hin gewechselt werden.

Zur Vereinfachung des Beispiels sei angenommen, daß das R— ß-Register aktiv ist, und zwar selbst in der b5 privilegierten Betriebsart. Darüber hinaus sei bezüglich sämtlicher Befehle angenommen, daß sie in der privilegierten Betriebsart auszuführen sind. Da Betriebsartenstörungen örtliche Prozeßausnahmen sind und in gleicher Weise wie R— ß-Störungen behandelt werden, besteht kein Bedarf zur Veranschaulichung beider Störungen.

Das erweiterte Beispiel zur Erfassung einer homogenen Behandlung von Eingabe/Ausgabe-Vorgängen benutzt hingegen die Prinzipien, die Hardware und die oben angegebenen Verfahren. Es sei jedoch bemerkt, daß in diesem Beispiel veranschaulicht ist, daß der R— B-Plan der 0-Plan ist.

Die Hardware-Virtualisierungsanordnung ist hier durch folgende Erweiterungen des Aufbaus der dritten Generation realisiert: Die durch die Erweiterung eines Seiten-/-PIans (in dem Speicherbereich) eingeführten Modifikationen sind dargestellt, wobei 1000-Wort-Seiten angenommer, werden. (Siehe F i g. 7.) Die Modifikationen enthalten

1) eine Datenbank zur Speicherung von /:

Ein gewisser fester bekannter Speicherplatz, 704,714 (F i g. 7) in dem Speicher 700 der Ebene /?, zeigt auf die virtuelle Maschinentabelle (VMTAB) 707, 717, die die virtuellen Maschinen (VMCBl, etc) der Ebene /?+ 1 beschreibt In diesem Beispiel veranschaulicht jeder virtuelle Maschinensteuerblock (VMCB) (708,710,718) einen Speicherplan (Seitentabelle) 709, 711 bzw. 719 unH einen Prozessorplan 708a, 710a, 718a. Die Seitenpläne entsprechen den /-Plänen, z. B. f\ entspricht 709, während f₂ 711 entspricht Der Prozessorplan enthält

den Speicher für den Befehlszähler und R-B der Ebene n+1. Ferner ist die »nächste __ Silbe« der Ebene

/7+2 enthalten, jedoch nicht dargestellt; diese Silbe wird gepseichert, wenn die Ebene n+1 einen LVMID-Befehl abgibt

2) Ein Mechanismus zum Aufruf von /:

Ein Mehrsiibenregister VMID 701 und ein LVMID-BefehL der zuvor erläutert worden ist. werden hinzugefügt. Wenn eine virtuelle Maschine aktiviert wird, werden ihre Befehlszähler und ihr R—S-Plan von ihrem Steuerblock (VMCB) 708a, 710a, 718a her geladen.

3) Eine Zusammenstellungsanordnung:

Eine Hardware-Firmenware-Zusammenstellungsanordnung, wie sie zuvor erläutert worden ist, unterstützt mit einem Zwischenspeicher und einer Assoziationsanordnung (aus Leistungsgründen) sind hinzugefügt
4) Die Wirkung auf einen virtuelfen Maschinenfehler:

Der Befehlszähler und der R—S-Plan sind in ihrem virtuellen Maschinensteuerblock gespeichert; die geeignete(n) Silbe(n) wird (werden) aus dem VMID-Register entfernt, und die Steuerung gelangt zu einem festen bekannten Speicherplatz, wie zu dem virtuellen Maschinenfehler-Speicherplatz 705, 715 in dem virtuellen Maschinenmonitor VMM.

Es sei darauf hingewiesen, daß (Sreses Beispiel einen /-Plan des Typs I veranschaulicht in welchem Betriebsmittel der Ebene n+1 in Betrieosmittel der Ebene π abgebildet sind. Bei einem Ebenen-Wert η des Verschicbungs-Grenz-Registers R— S gelangt sonr..; der <?-Plan nicht in die Abbildung hinein. Wenn in diesem Beispiel LVMID ausgeführt wird, ist die Verschiebung koinzident Null, braucht dies jedoch nicht zu sein.

Nunmehr sei das erste Beispiel näher betrachtet. F i g. 7 zeigt in einem Diagramm den Zustand des Hauptspeichers in der eine Hardware-Virtualisierungsanordnung aufweisenden Maschine. In Fig.7 sind ferner die drei Register VMID, R-B und IC gezeigt, wobei jedoch ihre Werte nicht angegeben sind. Stattdessen zeigt eine nachfolgende Tabelle Il sechs Sätze von Werten für VMID, R-B und IC. Für jeden Satz ist der ausführende Befehl, identifiziert bzw. gekennzeichnet, während die im Zuge der Entwicklung einer absoluten physikalischen Speicheradresse benutzte Bewertungsfolge nicht dargestellt ist. Der Tabelleneintrag enthält eine Anzeige einer

Prozeßausnahme, eines VM-Fehlers und jeglicher Änderung bezüglich des VMID-Registers. Die Werte des Registers R— B sind als r— b dargestellt, wobei /-die Verschiebung (in tausenden von Worten) bedeutet, während b die Größe der abhängigen Zuteilung (in tausenden von Worten) bedeutet.

Die sechs Zeilen der Tabelle II sind in drei Sätzen unterteilt, nämlich in die Zeilen 1 bis 3, die Zeile 4 und die Zeilen 5 bis 6. Innerhalb dieser Sätze laufen die Zeilen 1 bis 3 und auch die Zeilen 5 bis 6 aufeinanderfolgend ab.

Gemäß F i g. 7 beginnt der physikalische Hauptspeicher 700 an der Speicherstelle 0 und erstreckt sich über 11 Worte. Eine erste Grenze des Hauptspeichers ist bei 3000 Worten dargestellt, und danach alle 1000 Wörter bis zu 11 000 Wörtern. Dieser Speicher ist ein Teil des Rechnersysteme Honeywell 6000, welches normalerweise das GCOS-Betriebssystem zur Verarbeitung des 0-Plans benutzt. Neben dem Befehlszähler IC 703 und dem Verschiebungs-Grenzen-Register R—B702 ist das virtuelle Maschinenidentifizierungsregister VMID 701 hinzugefügt Das VMID-Register 701 ist für die Software nicht sichtbar (d.h. für Software gibt es keinen Zugriff), während das /?-ß-Register 702 und das IC-Register 703 für Software sichtbar sind (d. h. für Software einen Zugriff haben). Die reale Gastmaschine ist mit einem virtuellen Maschinenmonitor dargestellt, der zwischen den Speicherplätzen 0 und 3K läuft. Eine erste virtuelle Maschine VMt ist zwischen den Speicherplätzen 3K und SK

dargestellt, während eine weitere virtuelle Maschine VM\,\ zwischen den Speicherplätzen 3K und 8K. in einer zweiten Ebene dargestellt ist; diese Maschine weist die virtuelle Maschine VMi als Ursprung auf. Eine weitere virtuelle Maschine VM₂ ist zwischen den Speicherplätzen 8/C und 11Kdargestellt

Die örtlichen Prozeßausnahmen für die reale Gastmaschine werden in dem örtlichen Prozeßausnahmcspeicherplatz 706 verarbeitet, während die örtlichen Prozeßausnahmen für die virtuelle Maschine VM in dem

bo Speicherplatz 716 für die örtliche Prozeßausnahme (VM\) behandelt bzw. verarbeitet werden. Diese Speicherplätze zeigen die Stelle an, zu der ein Programm, das auf den entsprechenden Maschinen läuft, transferiert werden muß. sobald eine Prozeßausname, d. h. eine (^-Plan-Ausnahme, vorhanden ist In diesem Fall erhält clic privilegierte Software (in diesem Beispiel GCOS) die Steuerung. Wenn ein Fehler in dem /-Plan auftritt, dann erhält, in ähnlicher Weise der virtuelle Maschinenmoriitor die Steuerung, indem ein auf einer vorgegebenen

bj virtuellen Maschine laufendes Programm auf deren in Frage kommenden VM-Fehlcrplatzbcrcich 705, 715 bezogen wird.

Tabelle II

Hardware-Virtualisierungsanordnung Beispiel: Auswertungsfolgen

Reihe

VMID

R-B IC (r-b)

Auswertungsfolge

VMIDn. dargestellter Punkt Ausw. Folge

Nu!!

0-14

2000

1-3

2100

1-3

2101

IC ist 2000 Φ (2000)=2000 hole Befehl: LVMID 2800 Φ (2800)=2800 füge 1 an VMID an

ICist2100 0(21OO)=31OO f\ (3100)=4100 hole Befehl ab: LADE 128 #(128)=1128 /,(1128) = 6128 lade 999

ICist2100 0(21O1)=31O1 /",(3101)=4101 hole Befehl ab: Lade 3500

2-4

1100

IC ist 1100 0(11OO)=31OO /■₂(3100)=9100 hole Befehl ab: Lade 100
0(1OO)=21OO

Null

0-5

3200

1.1

2-2

1100

LVMID-Befehl

Ausführung
des virtuellen
Maschinenbefehls

Prozeßausnahme in virtueller
Maschine

Virtueller
Maschinen-Fehler und anderes
VMID

LVMID

mit Rekursion

Ausführung
des rekursiven
Befehlsund
VM-Fehler

IC ist 3200 Φ (3200) = 320C /i (3200)=4200 hole Befehl ab: LVMID 1300 0(1300)1300 /i (1300) = 6300 füge 1 an VMlD an

ICistllOO 0(11OO)=31OO /i,(3100) = 2100 /i(2100) = 5100 hole Befehl ah: Lade 500
0(500) = 2500 /•,.,(2500)= t

Bezugnehmend auf F i g. 7 und die Tabelle II sei durch die ersten verschiedenen Auswertungsfolgen gegangen. Gemäß Reihe 1 der Tabelle II beträgt bei dem virtuellen Maschinenmonitor, der auf der realen Maschine abläuft, der Wert von VMID 701 Null. Sämtliche Steuerblöcke VMCB sind eingestellt, und ferner ist es an der Zeit, die virtuelle Maschine VMi zu aktivieren. Der Wert des Befehlszählers 703 ist 2000. Da der Wert des R—/9-P.egisters 702 hier 0—14 ist, wird eine Null zu 2000 addiert, wobei durch Überprüfung festgestellt wird, daß kleiner ist als 1900: ferner wird festgestellt, daß 0(2000) = 2000 ist. Das VMID-Register ist Null. Deshalb ist der Beiriebsmittelname 2000 ein reales Betriebsmittel, während der Befehl (LVMID 2800) in der physikalischen Spcicherstelle 200C (Bezugszeichen 712) gemäß F i g. 7 abgeholt wird. Der R— ß-Plan wird an 2800 abgegeben, d. h.. daß der Speicherplatz 2800 lokalisiert wird, wie dies durch das Bezugszeichen 713 veranschaulicht ist. Hierzu wird der Φ-Plan de; Maschine verwendet und vom Speicherplatz 2800 gegebenenfalls eine »1« abgeholt, wobei dieser Wert in das VMID-Register eingespeichert wird. Die virtuelle Maschine VMi in der Ebene 1 ist nunmehr aktiviert, und inre Register IC imd R-B werden von

VMCBl 708a her geladen. Gemäß Reihe 2 der Tabelle 11 nimmt das IC 703 den Wert 2100 auf, während R- B 702 den Wert 1—3 aufnimmt. Sogardann, wenn der Speicher der virtuellen Maschine VMi 5000 Wörter umfaßt (wie dies aus dessen Seitentabelle 709 ersichtlich ist), begrenzt das /?-5-Register 702 diesen aktiven Prozeß auf die Adressierung von lediglich 3000 Wörtern. Diese Grenze war als wahrscheinliche Grenze durch das Betriebssy-

stem der virtuellen Maschine VMi angenommen, weil der aktive Prozeß ein normaler Anwender-Prozeß ohne Monitor ist.

Aus Reihe 2 der Tabelle Il ergibt sich ferner, daß der Wert von IC 2100 beträgt. Um den «ö-Plan abzugeben, wird eintausend hinzuaddiert und durch Überprüfung ermittelt, daß 2100 kleiner ist als 3000, wobei man zu Φ (21OO) = 31OO gelangt. Da VMID hier 1 ist und auf einer virtuellen Maschine gearbeitet wird, muß f\ abgegeben

werden, um das virtuelle Betriebsmittel 3100 in sein reales Äquivalent abzubilden. Die Seitentabelle /_t 709, die

durch VMCBl 708 angezeigt ist, zeigt dabei an, daß die virtuelle Seite 3 sich an der Speicherstelle 4000 befindet.

Deshalb ist /, (3100) = 4100. wie dies durch das Bezugszeichen 720 angedeutet ist, und der Befehl LADE 128 wird abgeholt.

Die übrigen Folgen können in derselben Weise unter Heranziehung der Tabelle Il ausgewertet werden. In

Reihe 3 ist eine Prozeßausnahme bezüglich der örtlichen Ausnahmeverarbeitung von VMi veranschaulicht. In Reihe 5 ist die Aktivierung der Rekursion veranschaulicht, während in den Reihen 4 und 6 VM-Fehler für die Fehlerverarbeitungseinrichtungen ihrer entsprechenden virtueiien Maschinenmonitore veranschaulicht sind.

Die Zwischenspeicher-Register 651 von Fig.6b, steigern das Leistungsvermögen, und zwar dadurch,daß sie direkt auf den absoluten Speicherplatz der aktiven Seitentabellen hinzeigen, z. B. /, 709. Die assoziativen

Register 652 von F i g. 6b, steigern hingegen das Leistungsvermögen dadurch, daß die verschiedenen der erst zuvor zusammengestzten Plan- bzw. Tabellenwerte, ρ und /ο ^^gespeichert werden. Nach Beendigung der Reihe 2 von Tabelle Il sind somit in dem assoziativen Speicher-Darstellungsprozeß Eintragungen des Namens 2000 in den realen Betriebsmittelnamen 4000 und des Prozeßnamens 0000 in den realen Betricbsrr.ittclnamen 6000 vorhanden. Nach Abschluß der Befehlsabholung der Reihe 6 der Tabelle Il ist ein Eintrag in der assoziaii-

ven Speicherabbildung und zwar betreffend die Überführung des Prozeßnamens 1000 in den realen Betriebsmiitelnamen 5000 vorhanden.

Es sei darauf hingewiesen, daß ein Seiten aufweisender /-Plan hinzugefügt worden ist, der in der Ebene η für die Software unsichtbar ist. Die vorher vorhandenen Pläne R- B, Φ bleiben in der Ebene η sichtbar. Somit können Betriebssysteme, die von dem Λ-ß-Plan. z.B. GCOS, unterrichtet werden, nicht jedoch von dem

Seiten-Plan, ohne irgendwelche Änderungen auf der virtuellen Maschine ablaufen.

Es sei ferner darauf hingewiesen, daß das Hinzufügen eines R- B /-Planes anstelle eines Seiten aufweisenden /-Planes anstelle eines Seiten aufweisenden /-Planes möglich ist. Ein derartiger R-B /-Plan unterscheidet sich von dem vorhandenen R- B 0-Plan und bildet einen Zusatz zu diesem Plan. Er muß allerdings die Rekursionseigenschaften der /-Pläne erfüllen. In ähnlicher Weise unterscheidet sich ein Seilen aufweisender /-Plan, der einer

Maschine, wie der Maschine !BM 360/67 hinzugefügt wird, von dem existierenden, Seiten, aufweisenden «ö-Plan

Nunmehr sei das zweite Ausführungsbeispiel näher erläutert: Das zweite Beispiel ist um ein komplizierteres Rechnersystem, wie das Rechnersystem Honeywell 6180 entwickelt worden. Dieses Beispiel besitzt dabei zusätzliche Komplexität gegenüber einem Rechner der dritten Generation aufgrund eines segmentiertcn Adressenraumes. In der Maschine werden die Adressen als s/d dargestellt, wobei s die Segmentnummer und c/dic

Versetzung innnerhalb des Segments bedeuten. Die normale Adressenentwicklung benutzt sodann eine Segmenttabelle zur Lokalisierung des jeweiligen Segments.

Die Hardware-Virtualisierungsanordnung ist hier durch dieselben Erweiterungen wie in dem vorhergehenden Beispiel mit folgenden Ausnahmen realisiert: Der 0-Plan ist ein Unterteilungs- bzw. Segmentierungsplan, während der /-Plan R- B ist. In diesem Rahmen sollen lediglich die Unterschiede erläutert werden. F i g. 8a zeigt einen festliegenden bekannten Speicherplatz 804 in dem Speicher 800 der Ebene η auf die Tabelle VMTAB 805, die die virtuellen Maschinen (VMCBl, etc.) der Ebene η + 1 beschreibt. In diesem Beispiel veranschaulicht jeder virtuelle Maschinensteuerblock VMCB (806, 807) einen R- ß-Speicherplan 808 bzw. 809, der abhängig im übrigen Teil des virtuellen Maschinensteuerblocks VMCB gespeichert ist. Der Prozessorplan, der Eingabe/Ansgabe-Plan bzw. I/O-Plan und der Zustand sind nicht dargestellt. In dem Hauptspeicherbereich entspricht der

R-B-Plan somit dem /-Plan. Das VMID-Register 801 und die zuvor erwähnten LVMID-Befehle werden hinzugefügt. Die Plan-Zusammenstellungsanordnung und der zuvor erwähnte VM-Fehler-Mechanismus (Fi g. 6a.6b) sind hinzugefügt.

Nunmehr sei das dritte Beispiel näher betrachtet: Gemäß Fig. 8a beginnt ein physikalischer Hauptspeicher 800 an der Speicherstelle 0 und erstreckt sich über i4K Wörter. Die stark ausgezogenen Grenzlinien des

Hauptspeichers trennen die virtueiien Maschinen auf. Somit ist der virtuelle Maschinenmotor VMM zwischen 0 und 3K untergebracht, die virtuelle Maschine VMl liegt hingegen zwischen 3K und 8K, während die virtuelle Maschine VM2 zwischen 8K und 14K liegt. Die gestrichelten Grenzlinien des Hauptspeichers trennen die Segmente für einen Prozeß P. der auf der virtuellen Maschine VMl abläuft.

Wenn mit der Ausführung begonnen wird, ist der Prozeß P\ aktiv, wobei seine Segmenttabelle 802 dazu

benutzt wird, die Φ-Plan-Adresse zu entwickeln. Der Befehlszähler (IC) 803 enthält einen Wert von 2/500. Sodann gilt Φ (2/500) = 2500. weil das Segment 2 sich an der Speicherstelle 200 innerhalb des Speichers der virtuellen Maschine VMl befindet. Da der Wert von VMID 801 hier 1 beträgt, muß der Plan /, zum Ergebnis abgegeben werden. Somit ist Z₁ (2500) = 5500. Damit wird der Befehl 810 am Speicherplatz 5500 abgeholt und ausgeführt. Dies erfordert eine Adressenentwicklung des Operandenfeldes, was dazu führt, daß 0(1/2O)=4O2O.

o5 /i (4020) = 7020 erzeugt wird. Somit wird der Inhalt des Speicherplatzes 7020 geladen, wie dies das Kästchen 812 veranschaulicht. Der Befehlszähler wird in seinem Inhalt auf 2/501 erhöht, worauf die Ausführung weiter abläuft. Der nächste Befehl befindet sich am Speicherplatz 5501, wie dies das Kästchen 811 veranschaulicht f 55(2/501) = 2501, Z₁ (2501) = 5501; der betreffende Befehl 811 wird abgeholt, wobei derselbe erfordert, daß das

Opcrandenfeld 1/2000 abgebildet wird. «0 (1/2000) = e bewirkt jedoch eine Ausnahme, weil die Verschiebung, — d. h. 2000 — größer ist als die Größe des Segments, — d. h. 1000 — ist. Die Ausnahme bewirkt eine Übertragung der Steuerung auf die privilegierte Software innerhalb der vorliegenden virtuellen Maschine KMl. Somit wird das VMID-Register801 durch die Ausnahme nicht beeinflußt.

Um die Leistung zu steigern, sind das Zwischenspeicher-Register 651 und assoziative Register vorgesehen. Fig. 8H veranschaulicht den Inhalt der Assoziationsanordnung 850 nach der Ausführung in diesem Beispiel gemäii Fig. 8a. Bezüglich Fig. 8b sei bemerkt, daß das Segment 2 ein Suchschlüssel für dessen absoluten physikalischen Speicherplatz unabhängig von der Rekursion ist.

Durch die Erfindung ist also eine Hardware-Virtualisierungsanordnung für den Ablauf von Prozessen auf einer virtuellen Rechenmaschine unter einem zusammengestellten f- und 0-Plan geschaffen. Der <£-Plan stellt in die Prozeßnamen in Betriebsmittelnamen zusammen, während der /"-Plan die virtuellen Betriebsmittelnamen in reale Betriebsmittelnamen umformt. Der i^-Plan ist ein lntraebenen-Plan, der (zumindest) für die privilegierte Software einer gegebenen virtuellen Maschine sichtbar ist und eine Beziehung innerhalb einer einzigen Ebene ausdrückt. Der /-Plan ist hingegen ein Inter-Ebenen-Plan, der für die gesamte Software der virtuellen Maschine sichtbar ist und der eine Beziehung zwischen den Betriebsmitteln zweier benachbarter Ebenen der virtuellen Maschinen hervorruft.

Die Hardware-Virtualisierungsanordnung gemäß der Erfindung ermöglicht die Verarbeitung sämtlicher Prozeßausnahmen direkt innerhalb der laufenden virtuellen Maschine, und zwar ohne einen Eingriff der Software des virtuellen Maschinenmonitors. Sämtliche Betriebsmittelfehler (VM-Fehler), die von einer virtuellen Maschine erzeugt werden, werden auf den in Frage kommenden virtuellen Maschinenmonitor geleitet, und zwar ohne die Kenntnis von Prozessoren in der virtuellen Maschine, d. h. unabhängig von der Rekursionsebene.

Im folgenden sind die im vorstehenden bentzten Ausdrücke und deren Bedeutung erläutert:

Glossar

Aufbau bzw. Architektur:

Eigenschaften eines Systems, vom Programmierer aus gesehen, d. h. die Konzeptstruktur und das Funktionsverhalten im Unterschied zur Organisation des Datenflusses und der Steuerungen, dem logischen Aufbau und der physikalischen Realisierung.

Assoziationsanordnung:

Hardwareeinrichtung zur Ausführung einer schnellen Parallelsuche.

Grund-Maschinenschnittstelle:

Der Satz sämtlicher softwaresichtbarer Gegenstände und Befehle, die von dem Hardware- und Firmware-System direkt unterstützt werden.

Sieuerprogramm:

Virtueller Maschinenmotor.

Emulation:

Verfahren zur Simulation einer Innenausstattung einer Maschine mit gewissen Unterschieden.

Ausnahme:

Nicht programmierter Sprung, der durch eine Prozeßstörung hervorgerufen wird (im Unterschied zu einem Fehler); die Steuerung sollte in der laufenden virtuellen Maschine verbleiben.

Familie:

Kompatible Reihe von Rechnern mit möglichst wenigen Innenausstattungs-Unterschieden. z.B. IBM 360/40 und IBM 360/67.

Familien-Visualisierung:

Die virtuelle Maschine ist nicht identisch mit der Gastmaschine, sondern ein Glied derselben Rechnerfamilie; sie kann nicht rekursiv sein.

Familien-Virtualisierung FV:

Die virtuelle Maschine ist nicht identisch mit der Ausgangsmaschine, jedoch ein Glied derselben Rechnerfamilie; sie kann nicht rekursiv sein.

Virtueller Maschinenplan F:

Zusammenfassung des Planes zwischen zwei Ebenen einer virtuellen Hilfsquellenzuteilung.

Λ Plan:

Zusammenstellung des Plans zwischen zwei Ebenen der virtuellen Hilfsquellenzuteilung.

25-Plan:

Zusammenstellung bzw. Abstraktion eines Planes von Betriebsmittelnamen aus Prozeßnamen, unterstützt durch Hardware und manipuliert durch Betriebssystem.

Prozeß-Plan Φ:

Abstraktion eines Planes von Betriebsmittelnamen aus Prozeßnamen, unterstützt durch Hardware und manipuliert durch Betriebssystem.

Erzeugung:

Aufbaucharnkteristikcn der Hauptmaschinen der betreffenden Generation (hier bezieht sich der Begriff Generation stets auf die Architektur bzw. den Aufbau, niemals auf die physikalische Realisierung, etc.

Hardware-Virtuaiisierungsanordnung HV:

Sammelbegriff für die Hardware-Firmware-Anlage bzw. -Ausführung, die direkt virtuelle Maschinen wirksam unterstützt.

Gastrechner:

Maschine, auf der der virtuelle Maschinenmonitor läuft.

Ausgangsbetriebssystem:

Betriebssystem, unter dem ein virtueller Maschinenmonitor des Typs Il liuft.
Hybride virtuelle Maschine HVM:
■ Virtuelle Maschine, in der sämtliche Befehle, die innerhalb der meist-privilegierten Schicht abgegeben

5 werden, software-interpretiert sind und in der sämtliche übrigen Befehle direkt ausgeführt werden.

' Interne Ausgestaltung:

Software-sichtbare Definition eines Systems, d. h. die Architektur.
^f Intra-Ebenen-Plan:

Plan innerhalb einer virtuellen Maschinenebene, der die (Schicht-)Struktur innerhalb der Ebene festlegt: ίο Der Plan kann für die privilegierte Software der Ebene sichtbar sein, z. B. der 0-Plan.

I₁ Inter-Ebenen-Plan:

VM Plan zwischen zwei Ebenen virtueller Maschinen, z. B. Ebene /?+1 zu Ebene n, der für die höhere Ebene unsichtbar ist, z. B. die Ebenen+ l.z. B. der f-Plan.
'' Unsichtbar:

15 Unfähig, in Software ermittelt zu werden.

Schicht:

" Beschränkte Zugriffsstruktur (innerhalb ein<?r Ebene), wie Master/Slave-Betriebsarten oder Ringe.

Ebene:

Anzahl von /'■Plänen, die aufeinanderfolgend abgegeben werden müssen, um einen virtuellen Betriebsmit-20 telnamen in einen realen Betriebsmittelnamen darzustellen: Außerdem entspricht dies der Anzahl von

, Silben in VMID: Somit liegt die reale Maschine in der Ebene 0.

Natürliche Betriebsart:

Operation des Systems, z. B. der Zentraleinheit, mit bevorzugtem Befehlscode, nicht Emulation.
Prozeßsteuerblock PCB:
> 25 Prozeßzustand wird in Stystembasis gehalten.

P-Name:

^ Vom Prozeß benutzter Name, um auf eine gewisse Einheit Bezug zu nehmen.

/' Prozeß-Plan:

¹^ Abstraktion des Plans aus Prozeßnamen, z. B. Segmentnummer, für Betriebsmittelnamen, z. B. Speicher-

30 platz, 0-Plan.

_x Privilegierter Befehl:

_H Befehl, der lediglich in der privilegierten Betriebsart (richtig) abläuft bzw. ausgeführt wird.

* R- B:

' Verschiebungs-Grenze bei Adressenverschiebung, sowie sie beim System DEC PDP-10 auftritt.

t. 35 Betriebsmittel-Plan:

Virtueller Maschinenplan, bzw. /-Plan.
S' Ring:

?* In Schichten vorgesehenes Schutzsystem, Verallgemeinerung des Master/Slave-Betriebs, bzw. eines Übcr-

►< wachungs/Problem-Zusiandes.

5\ 40 Ring 0:

$ Der privilegierteste Ring.

ä. Laufende Prozeßwörter RPW:

I₁ Auf Systembasis einer typischen Maschine der vierten Generation ist eine Identifzierungseinrichtung für

|v aktiven Prozeß vorgesehen.

§ji 45 Selbst-virtualisierend SV:

I? Der Prozessor des virtuellen Rechnersystems ist mit der Ausgangsmaschine identisch, der rekursiven

Jl virtuellen Maschine,

jp Semaphor:

|l Einrichtung für Interprozeß-Nachrichtenverbindung in einem typischen Rechnersystem der vierten Rech-

jg so nergeneration der vierten Generation.

ii Überwachungsanforderung SVC:

H Befehl, der dazu benutzt wird, eine Nachrichtenverbindung mit dem Betriebssystem herzustellen.

ff] Systembasis:

H Datenbank für einen direkten Zugriff durch Firmware (und durch privilegierte Software aktualisiert) eines

55 typischen Systems der vierten Generation zur Unterstützung der Ausführung des Prozeßmodells.

Virtuelle Maschine:

Ein Hardware-Software-Duplikat eines real existierenden Rechnersystems, in welchem ein statistisch vorherrschender Untersatz der virtuellen Prozessorbefehle direkt auf einem Gastrechner abläuft.
Virtuelles Maschinenmodell·.
60 Zusammenstellung eines abstrakten Prozeßplans und eines Betriebsmittelplans, um das Ablaufen eines

Prozesses auf einem virtuellen Rechnersystems auszudrücken.
Visualisierung:

Handlung der Erzeugung bzw. Ablaufs virtueiler Maschine(n).
Virtualisierbar:

65 Fähigkeit, virtuelle bzw. selbstvirtualisierende Maschine(n) zu bilden.

VM-Fchler:

Betriebsmittelfehler durch virtuelle Maschine zu VMM.

22

VM-Plan:

Abstraktion eines Plans zwischen zwei Ebenen virtueller Betriebsmittelzuteilung (vollständig unterschiedlich vom Prozeß-Plan), /"-Plan.

VM-Rckursionscigcnschaft:

Bei einer selbstvirlualisierendcn virtuellen Maschine, Fähigkeit, ein Programm auf der virtuellen Maschine > ablaufen zu lassen.

A bkürzungs Verzeichnis

BOS: Grundbetriebssystem/360. m

CMS: Cambridge Monitorsystem.

CPU: Zentraleinheit.

OS/ASP: OS/360 angebrachter Unterstützungsprozessor.

DOS: Plattenbetriebssystem/360.

DOS-APL: DOS-APL/360(eine Programmiersprache). 15

ETSS: Experimentelles Zeitteilsystem (HITAC).

I/O: Eigabe/Ausgabe.

!TS: !nkomⁿstib!es Zeitteüs^'Stern bzw. Z£ilrnu!tiⁿ!s>;s^vstsfn.

MTS: Michigan Technisches System.

TOS: Bandbetriebssystem/360. 20

TOS/TDOS: Bandbetriebssystem/Band-Platten-Betriebssystem(HITAC).

Typ I SV: Band I, selbstvirtualisierende virtuelle Maschine.

Typ I VMM: Der virtuelle Maschinenmonitor (VMM) läuft auf einer Gastmaschine.

Typ 11 VM M: VMM läuft auf einer erweiterten Gastmaschine unter dem Gast-Betriebssystem.

UMMPS: Mehrprogrammsystem der Universität von Michigan. 25

VCS: Virtuelles Rechnersystem.

VMCB: Virtueller Maschinensleuerblock auf der Systembasis der Hardware-Virtualisierungsanordnung
zur Abgabe des /-Planes für die virtuelle Maschine.

VMTAB: Virtuelle Maschinentabelle auf der Systembasis der Hardwaro-Virtualisierungsanordnung zur

Aufnahme des Zeigers für die virtuellen Maschinensteuerblöcke der virtuellen Maschinen. 30

VM: Virtuelle Maschine.

VMID: Virtuelles Maschinenidentifizierungsregister in der Hardware-Virtualisierungsanordnung zur Anzeige der aktiven virtuellen Maschine.

LVMID: Lade VMID-Befehl der Hardware-Virtualisierungsanordnung, mit welchen die nächsten Silben an

VMID-Register anhängt und die virtuelle Maschine abgefertigt wird. 35

VMM: Virtueller Maschinenmonitor in Form von Software, welche zwischen der virtuellen Maschine und

der Gastmaschine vermittelt.

VMTSS: Virtuelles Maschinen-Zeitmultiplexsystem.

V-Name: Virtueller Betriebsmittelname.

Hierzu 9 Blatt Zeichnungen

Claims (2)

Patentansprüche:

1. Rechenanlage, welche mittels eines Gastrechners mit realen Betriebsmitteln eine oder mehrere andere Rechenanlagen als virtuelle Maschinen mit deren virtuellen Betriebsmitteln simuliert und dabei die virtuellen Maschinen in mehreren Betriebsebenen zur Ausführung bringt, dadurchgekennzeichnet,

daß der Gastrechner (101) mit einer Hardware-Virtualisierungsanordnung (650) versehen ist, welche interne Register (657—659) aufweist, die über entsprechende Leitungspfade (663—667) mit einem ersten Register (VMID-Register 653; 701; 801), das die gerade in Ausführung befindliche virtuelle Maschine (110,111; 158) identifiziert, und mit einem zweiten Register (Ebenen-Register 656), das die Betriebsebene (Fig. Iu) der

ίο gerade in Ausführung befindlichen virtuellen Maschinen anzeigt, verbunden sind und für diese Zwischeninformationen speichern, und

daß die Hardware-Virtualisierungsanordnung (650) derart ausgebildet ist, daß sie in Abhängigkeit von einem Prozeßnamen (P), den sie von einem Prozeßnamenregister (654) empfängt, und von Steuersignalen (661,662), die eine Zuordnung (0) zwischen Prozeßnamen und Betriebsmitteln und Zuordnungen (f„ F\.\ ...) zwischen

Betriebsmitteln in mehreren Betriebsebenen angebei·, jeweils einen Namen eines realen Betriebsmittels erzeugt und diesen über einen Leitungspfad (668) in ein weiteres Register (655) abgibt

2. Rechenanlage nach Anspruch 1, dadurch gekennzeichnet, daß die Hardware-Virtualisierungsanordnung (650) zusätzlich mit Zwischenspeicherregistern (651) sowie assoziativen Registern (652) versehen ist, wobei letztere der Einspeicherung der zuletzt benutzten Zuordnungen (Φ, f\, f\.\...) dienen.