DE112015001502T5

DE112015001502T5 - Ausstieg aus mehreren Threads in einem Computer

Info

Publication number: DE112015001502T5
Application number: DE112015001502.7T
Authority: DE
Inventors: Lisa Cranton Heller; Fadi Yusuf Busaba; Mark Farrell
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2014-03-27
Filing date: 2015-03-06
Publication date: 2017-04-27
Also published as: GB2539600B; JP6556747B2; GB201616861D0; US9213569B2; JP2017515202A; CN106133692B; US20150277947A1; GB2539600A; CN106133692A; WO2015144422A1

Abstract

Gemäß einem Aspekt enthält ein Computersystem eine Konfiguration mit einer Maschine, die fähig ist, in einem Einzel-Thread-(ST)Modus und einem Multithread-(MT)Modus zu arbeiten. Außerdem enthält die Maschine physische Threads. Die Maschine ist so konfiguriert, dass sie ein Verfahren ausführt, das die Ausführung einer Gastentität auf dem Kern im MT-Modus enthält. Die Gastentität enthält die gesamte oder einen Teil einer Gast-VM und eine Mehrzahl von logischen Threads, die auf den physischen Threads ausgeführt werden. Ein Ausstiegsereignis wird an der Maschine erfasst. Auf Grundlage einer Erfassung des Ausstiegsereignisses wartet die Maschine, bis alle logischen Threads, die aktuell auf den physischen Threads ausgeführt werden, einen Synchronisierungspunkt erreicht haben. Ein Zustand, der Ausstiegsgrundinformationen enthält, wird für jeden der logischen Threads gespeichert, und die Ausführung eines Hosts wird auf einem der physischen Threads im ST-Modus initiiert.

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein Multithreading (MT) und insbesondere eine Maschinenumsetzung des Ausstiegs aus einer virtuellen Ausführung von mehreren Threads in einem Computer.
Multithreading (MT) bietet ein Mittel zum Erhöhen der Anzahl von Prozessor-Threads, die parallel in einem einzelnen physischen Prozessorkern arbeiten können ohne die Notwendigkeit, weitere Kerne hinzuzufügen. Idealerweise bietet MT diese erhöhte Kapazität, indem ein oder mehrere Threads veranlasst werden, Teile der Kern-Hardware zu nutzen, die derzeit nicht von dem oder den anderen Threads verwendet werden, der bzw. die auf demselben Kern ausgeführt werden. Zum Beispiel können ein oder mehrere andere Threads während der durch einen Cachefehler oder eine andere Verzögerung in einem Thread verursachten Latenz die Kernressourcen nutzen und somit die Auslastung der Ressourcen erhöhen. Auch wenn diese gemeinsame Nutzung in der Praxis zu einigen Störungen zwischen den Threads führt und einige zusätzliche Hardware erfordert, bietet MT immer noch die Möglichkeit, die Arbeit jedes Threads unter Verwendung von weniger Hardware auszuführen als erforderlich wäre, wenn jeder Thread auf seiner eigenen gesonderten Kern-Hardware ausgeführt werden müsste. Oft lässt sich zusätzlicher Nutzen aus dem MT ziehen, wenn die gemeinsame Verwendung von Hardware-Ressourcen zwischen Threads auch die Gesamtbelastung des Computersystems verringert, um Informationen wie beispielsweise Daten aus dem Arbeitsspeicher für zwei spezifische Kerne bereitzustellen.
Obwohl MT bei Hardware Einsparungen bietet, verbraucht das Hinzufügen eines weiteren Arbeits-Threads typischerweise dieselben Koordinierungskosten auf Hypervisor-Ebene, die erforderlich wären, um eine erhöhte Kapazität unter Verwendung eines zusätzlichen separaten Kerns bereitzustellen. Sobald ein bestimmtes Skalierungsverhältnis erreicht ist, ist der Aufwand zum Koordinieren von Ressourcen zwischen Arbeits-Threads, gleichgültig, ob sie auf einem einzelnen oder einem gemeinsam genutzten Kern ausgeführt werden, in vielen Fällen beträchtlich und kann die Vorteile, die sich aus der Möglichkeit einer Ausführung eines unabhängigen Arbeits-Threads ergeben, verringern oder sogar überwiegen. Das heißt, dass allgemein der Verwaltungsaufwand zunimmt, je höher die Anzahl der zu verwaltenden Elemente wird.
KURZDARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Verfahren, wie in Anspruch 1 beansprucht, und ein entsprechendes System und Computerprogramm bereit.
KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
Die als Ausführungsformen betrachtete Thematik wird insbesondere in den Ansprüchen am Ende der Spezifikation dargelegt und eindeutig beansprucht. Die vorgenannten und weitere Merkmale und Vorteile der Ausführungsformen werden aus der folgenden ausführlichen Beschreibung in Verbindung mit den begleitenden Zeichnungen offenkundig, wobei:
1 eine Datenverarbeitungsumgebung darstellt, die gemäß einer Ausführungsform umgesetzt werden kann;
2 einen physischen Prozessor darstellt, der gemäß einer Ausführungsform umgesetzt werden kann;
3 eine Datenverarbeitungsumgebung darstellt, die gemäß einer Ausführungsform umgesetzt werden kann;
4 eine Zustandsbeschreibung eines als Multithread-(MT)Prozess ausgeführten logischen Threads gemäß einer Ausführungsform darstellt;
5 ein Blockschaubild einer Thread-Gültigkeitsmaske (TVM) gemäß einer Ausführungsform darstellt;
6 eine Zustandsbeschreibungsgruppe mit festgelegtem relativen Offset gemäß einer Ausführungsform darstellt;
7 eine Zustandsbeschreibungsgruppe darstellt, die als Adressenliste gemäß einer Ausführungsform angegeben ist;
8 eine Zustandsbeschreibungsgruppe darstellt, die als verknüpfte Liste gemäß einer Ausführungsform angegeben ist;
9 eine Zustandsbeschreibungsgruppe darstellt, die als kreisförmige Liste oder Ring gemäß einer Ausführungsform angegeben ist;
10 einen Kernzuteilungsprozess gemäß einer Ausführungsform darstellt;
11 einen koordinierten Ausstieg aus einer virtuellen Ausführung gemäß einer Ausführungsform darstellt;
12 ein Blockschaubild eines Systemkontrollbereichs gemäß einer Ausführungsform darstellt;
13 einen Prozessablauf für die Koordination zwischen Multithread-Kernen gemäß einer Ausführungsform darstellt;
14A und 14B eine Maschinenumsetzung einer Kernzuteilung gemäß einer Ausführungsform darstellen;
15A und 15B eine Maschinenumsetzung eines koordinierten Ausstiegs aus einer virtuellen Ausführung gemäß einer Ausführungsform darstellen; und
16 ein von einem Computer lesbares Medium gemäß einer Ausführungsform darstellt.
AUSFÜHRLICHE BESCHREIBUNG
Hierin beschriebene Ausführungsformen können zum Verringern des Hypervisor-Verwaltungsaufwands in einer Multithreading-(MT)Umgebung verwendet werden. Wie hierin beschrieben, kann die Verwaltung von mehreren Threads zwischen einem Hypervisor, der die mehreren Threads als einen einzelnen logischen Kern verwaltet, und einer Maschine aufgeteilt werden, die Interaktionen zwischen den mehreren Threads verwaltet, wenn sie auf Ressourcen des physischen Kerns zugreifen. Dies kann zu einer wesentlichen Verringerung der Multithreading-(MT)Aufwandskosten führen, wenn dem Hypervisor gestattet wird, einen Großteil der Hypervisor-Infrastrukturressourcen auf der Grundlage eines logischen Kerns zu verwalten, und der Maschine gestattet wird, andere Ressourcen auf einer differenzierteren Thread-Grundlage zu verwalten. Eine Ausführungsform enthält eine Kernzuteilungsanweisung, die von einem Hypervisor ausgeführt werden kann, der auf einem einzelnen Thread (ST) ausgeführt wird. Die Ausführung der Kernzuteilungsanweisung, die hierin als „VE-Startanweisung mit angegebenem MT“ bezeichnet wird, kann dazu führen, dass mehrere logische Gast-Threads, die die gesamte oder einen Teil einer virtuellen Maschine (VM) eines Gasts ausmachen, einem einzelnen physischen Kern zugeteilt werden. In einer Ausführungsform gibt die vom Hypervisor zum Zuteilen des Gasts verwendete Anweisung an, ob der zuzuteilende Gast ein Einzel-Thread oder Multithread-Gast ist.
Hierin beschriebene Ausführungsformen können Strukturen wie eine Thread-Gültigkeitsmaske für die Angabe, welche logischen Threads im logischen Kern eines Gasts aktuell gültig sind, und eine Zustandsbeschreibungsgruppe mit einem Zustandsbeschreibungsring zum Verwalten der Zuteilung eines logischen Kerns mit mehreren Threads enthalten. Des Weiteren können primäre und sekundäre Zustandsbeschreibungen und Feldtypen (z.B. primär, mit gemeinsamem Kern, threadspezifisch) umgesetzt werden, um eine effiziente Verwaltung der Computerressourcen zu ermöglichen, wenn ein logischer Kern mit mehreren Threads zugeteilt wird. Ferner kann ein koordinierter Ausstieg bereitgestellt werden, bei dem alle Threads in einem logischen Kern zum selben Zeitpunkt aus einer virtuellen Ausführung aussteigen, um Verwaltungsfunktionen für Hypervisor und logischen Kern zu vereinfachen.
Ausführungsformen können eine durch den Hypervisor verwaltete Steuerstruktur enthalten, die hierin als kernorientierter Systemsteuerbereich (COSCA) bezeichnet wird. Der COSCA wird vom Hypervisor und der Maschine zum Verwalten bestimmter Funktionen verwendet, was sich auf mehrere logische Prozessoren in der Gastkonfiguration auswirken kann. Eine COSCA-Ausführungsform wird als Baumstruktur umgesetzt, deren Blätter logische Kerne darstellen, und wobei jedes Blatt eine Liste enthält, die den Threads dieses Kerns entspricht. Die COSCA-Struktur kann Felder enthalten (z.B. Zustandsbeschreibungsadressen), die es dem Hypervisor gestatten, problemlos auf die Zustandsbeschreibungen für alle Threads in einem bestimmten Kern zuzugreifen.
Ausführungsformen können auch eine Maschinenumsetzung der Kernzuteilung enthalten (z.B. die VE-Startanweisung mit angegebenem MT), wobei auf der Maschine befindlicher Millicode zum Verwalten des Kernzuteilungsprozesses verwendet werden kann.
Hierin wird der Begriff Millicode für den Verweis auf lizenzierten internen Code verwendet, der zum Betrieb der Prozessor-Hardware gehört. Millicode wird von der Maschine ausgeführt, wenn sie in einem Ausführungsmodus läuft, der hierin als Millimodus bezeichnet wird.
Wenn ein logischer Kern eines Gasts mehrere Threads enthält, wird einer der logischen Threads als primärer Thread bezeichnet, und der Rest wird als sekundäre Threads bezeichnet. Der Begriff „primär“ bezieht sich auf den logischen Thread. Ein physischer Thread ist weder ein primärer noch ein sekundärer Thread von einer Hardware-Perspektive aus; er wird zum primären Thread, sobald eine VE-Startanweisung mit angegebenem MT darauf ausgegeben wird. Der Grund für diese temporäre Unterscheidung auf physischer Ebene besteht darin, dass die Zurückgabe der Steuerung an den Host typischerweise auf dem primären Thread erfolgt, d.h. die Steuerung wird an den Hypervisor auf demselben physischen Thread zurückgegeben, auf dem die VE-Startanweisung ausgegeben wurde.
In einer Ausführungsform kann Millicode zum Laden fast des gesamten Zustands jedes Threads (primär oder sekundär) aus einem beliebigen anderen Thread (primär oder sekundär) verwendet werden. In Ausführungsformen verwendet der Millicode diese Zustandsladeflexibilität zum Laden eines sehr kleinen Abschnitts eines anderen Threads, um die potenzielle Effizienz zu nutzen, die durch das parallele Laden des eigenen Zustands durch jeden Thread gesteigert werden kann. Einige Befehle (wie Adressumsetzpuffer löschen oder „PTLB“) und allgemeine Ressourcen können auf alle Threads angewendet werden, und dies ermöglicht es, sie nur von einem einzigen Thread aus auszuführen oder zu laden. Dies spart nicht nur Zeit für den Befehl oder das Laden selbst, sondern in einigen Fällen auch beim Testen, das erforderlich ist, um zu ermitteln, ob die Aktion tatsächlich erforderlich ist. Diese in der Auslegung enthaltene Flexibilität kann Millicode ein konstantes Anpassen des Algorithmus ermöglichen, der zum Unterstützen der Kernzuteilung bei zunehmendem Fortschritt von Design, Entwicklung und Testzyklus verwendet wird. Zum effizienten Starten und Stoppen der Thread-Ausführung können Mechanismen bereitgestellt werden. Außerdem kann Millicode auch zum Berücksichtigen der Situation verwendet werden, in der interne Firmware auf einem Thread ausgeführt wird, der auf der Software-Ebene als ungültig betrachtet wird.
Weitere Ausführungsformen betreffen die Maschinenumsetzung eines koordinierten Ausstiegs aus einem zugeteilten logischen Kern eines MT-Gasts zurück zu einem ST-Host (z.B. einem Hypervisor). In einer Ausführungsform wird Millicode zum Synchronisieren des Systems verwendet, und dies umfasst die Koordinierung aller verschiedenen Threads unter Berücksichtigung jedes ihrer aktuellen Zustände. Eine Ausführungsform kann auch die Bearbeitung von Unterbrechungen höchster Priorität enthalten, während Unterbrechungen mit niedrigerer Priorität blockiert werden, die den Ausstieg verzögern können. Das Beenden von sekundären Threads kann auf eine Weise erfolgen, die nach Beendigung des Ausstiegs die effizienteste Nutzung der Kernressourcen gestattet. Zum Beispiel kann der Millicode bestimmte Unterbrechungen deaktivieren, um zu verhindern, dass Kernressourcen zum Zuteilen des Handlers für Millicode-Unterbrechungen verwendet werden, wenn dies nicht erforderlich ist. Millicode kann auch für die Angabe verwendet werden, dass bestimmte physische Register nicht mehr verwendet werden, sodass sie zur Verwendung durch den ST frei sind, der ausgeführt wird.
Der hierin verwendete Begriff „Thread“ bezieht sich auf einen einzelnen Anweisungsdatenstrom und dessen zugehörigen Zustand. Das bedeutet, dass jeder logische Thread auf einer Architekturebene eine unabhängige CPU oder einen unabhängigen Prozessor darstellt. Auf einer Hardware-Ebene ist ein physischer Thread die Ausführung eines Anweisungsdatenstroms, der einem logischen Thread zugehörig ist, kombiniert mit der Verwaltung des Gastzustands, wenn dieser Thread zugeteilt wird. Das Verwalten dieses Thread-Zustands durch die Maschine verringert die auf der Hypervisor-Ebene erforderliche Verwaltung. Die Gesamtanzahl logischer Threads, die zur Verwendung durch logische Kerne verfügbar sind, wird durch die Gesamtanzahl physischer Threads begrenzt, die für physische Kerne zur Verfügung stehen.
Der hierin verwendete Begriff „physischer Kern“ bezieht sich auf eine Hardware-Verarbeitungseinheit, die einen oder mehrere unabhängige Anweisungsdatenströme oder Threads ausführt, aber viele grundlegende Ressourcen gemeinsam nutzt, wie Ausführungseinheiten und untergeordnete Cache-Speicher. Diese gemeinsame Nutzung kann auf vielerlei Weise erfolgen, einschließlich durch Veranlassen, dass jeder Thread dieselben Hardware-Ressourcen an unabhängigen Zeitpunkten verwendet, oder indem veranlasst wird, dass die Ressourcen logisch bei jedem physischen Einstieg gemeinsam genutzt werden, der mit einer Thread-Kennung gekennzeichnet ist. Eine ordnungsgemäße Synergie zwischen den Threads, zum Beispiel einem Thread, der Ressource A oft, Ressource B aber nur selten benötigt, und einem anderen Thread, der typischerweise Ressource B, aber nicht Ressource A verwendet, kann die Effizienz dieser gemeinsamen Nutzung verbessern. Der hierin verwendet Begriff „Maschine“ bezieht sich auf Hardware, die in dem physischen Kern enthalten ist, sowie Millicode und andere Hardware, die zur Unterstützung des physischen Kerns verwendet werden.
Die hierin verwendeten Begriffe „Gast-VM“ und „Gast“ werden austauschbar verwendet und verweisen auf eine einzelne Gastkonfiguration, die eine einzelne CPU oder mehrere CPUs enthalten kann. Der hierin verwendete Begriff „logischer Kern“ bezieht sich auf die Gruppe logischer Threads oder CPUs eines Gasts, die so definiert sind, dass sie zusammen als Teil einer VE-Startanweisung mit angegebenem MT zugeteilt werden. Eine Gast-VM kann aus einem einzelnen logischen Kern (entweder ST oder MT) oder mehreren logischen Kernen bestehen (von denen jeder ebenfalls ST oder MT sein kann).
Der hierin verwendete Begriff „Software“ bezieht sich entweder auf das Hypervisor-Programm (z.B. PR/SM oder zVM) oder das Gastbetriebssystem oder ein Anwendungsprogramm, das als Ergebnis der VE-Startanweisung zugeteilt wird.
Die hierin verwendeten Begriffe „Hypervisor“ und „Host“ beziehen sich auf das Programm, das die Systemressourcen verwaltet und den bzw. die logischen Prozessoren des Gasts zuteilt, der bzw. die auf der physischen Hardware ausgeführt werden sollen.
Der Operand der VE-Startanweisung, der zum Zuteilen eines Gastes verwendet wird, verweist auf eine Zustandsbeschreibung oder Gruppe von Zustandsbeschreibungen, die den Zustand des Prozessors oder Kerns des Gasts definiert. Die Zustandsbeschreibung selbst besitzt Zeiger auf „Satellitenblöcke“, die als eine Erweiterung der Zustandsbeschreibung betrachtet werden können und weitere Informationen enthalten, die den Zustand des Kerns oder Prozessors des Gasts weiter definieren. Der hierin verwendete Begriff „Zustandsbeschreibung“ bezieht sich nicht nur auf die Zustandsbeschreibung selbst, sondern auch auf die Satellitenblöcke. Der kernorientierte Systemsteuerbereich (COSCA), einer dieser Satellitenblöcke, ist in 12 dargestellt.
Unter folgender Bezugnahme auf 1 wird allgemein eine Datenverarbeitungsumgebung 100 gezeigt, die durch eine beispielhafte Ausführungsform umgesetzt werden kann. Die Datenverarbeitungsumgebung 100 kann zum Beispiel auf der z/Architecture beruhen, die von International Business Machines Corporation, Armonk, New York angeboten wird. Die z/Architecture wird in einer IBM^®-Veröffentlichung mit dem Titel „z/Architecture – Principles of Operation“ beschrieben, Veröffentlichungsnr. SA22-7832-09, August 2012. In einem Beispiel enthält eine auf der z/Architecture beruhende Datenverarbeitungsumgebung eine von International Business Machines Corporation, Armonk, New York angebotene eServer zSeries.
Zum Beispiel kann die Datenverarbeitungsumgebung 100 einen Prozessorkomplex 102 enthalten, der mit einem Systemcontroller 120 verbunden ist. Der Prozessorkomplex 102 kann zum Beispiel eine oder mehrere Partitionen 104 (z.B. logische Partitionen LP1 bis LPn), einen oder mehrere physische Kerne 106 (z.B. Kern 1 bis Kern m) und einen Hypervisor 108 der Ebene 0 (z.B. einen logischen Partitionsmanager) enthalten, die jeweils im Folgenden beschrieben werden.
Jede logische Partition 104 ist fähig, als ein separates System zu arbeiten. Das heißt, jede logische Partition 104 kann unabhängig zurückgesetzt, zunächst mit einem Betriebssystem 110 geladen werden, sofern gewünscht, und mit verschiedenen Programmen arbeiten. Bei einem Betriebssystem 110 oder einem Anwendungsprogramm, die in einer logischen Partition 104 ausgeführt werden, kann es so aussehen, als hätten sie Zugriff auf ein ganzes und vollständiges System, während in Wirklichkeit nur ein Teil davon verfügbar ist. Eine Kombination von Hardware und lizenziertem internen Code (die allgemein als Mikrocode oder Millicode oder Firmware bezeichnet wird), hält ein Programm in einer logischen Partition 104 davon ab, störend in ein Programm in einer anderen logischen Partition 104 einzugreifen. Dies ermöglicht es verschiedenen logischen Partitionen 104, auf einem einzelnen oder mehreren physischen Kernen 106 in einem Zeitscheibenverfahren zu arbeiten. In einer Ausführungsform enthält jeder physische Kern einen oder mehrere zentrale Prozessoren (die hierin auch als „physische Threads“ bezeichnet werden). In dem in 1 gezeigten Beispiel hat jede logische Partition 104 ein residentes Betriebssystem 110, das für eine oder mehrere logische Partitionen unterschiedlich sein kann. Das Betriebssystem 110, das auf jeder logischen Partition 104 ausgeführt wird, ist ein Beispiel für eine virtuelle Maschine oder Gastkonfiguration. In einer Ausführungsform ist das Betriebssystem 110 das Betriebssystem z/OS^®, das von International Business Machines Corporation, Armonk, New York angeboten wird.
Die physischen Kerne 106 enthalten physische Prozessorressourcen, die den logischen Partitionen 104 zugeordnet sind. Eine logische Partition 104 kann einen oder mehrere logische Prozessoren enthalten, von denen jeder alle oder einen Teil der physischen Prozessorressourcen darstellt, die der Partition 104 zugeordnet sind. Die physischen Kerne 106 können entweder den logischen Kernen einer bestimmten Partition 104 dediziert zugewiesen werden, sodass physische Prozessorressourcen des bzw. der zugrunde liegenden Kerne 106 für diese Partition 104 reserviert werden; oder gemeinsam mit den logischen Kernen einer anderen Partition 104 genutzt werden, sodass physische Prozessorressourcen der Ressourcen des bzw. der zugrunde liegenden Kerne potenziell für eine andere Partition 104 verfügbar sind.
In der in 1 gezeigten Ausführungsform werden die logischen Partitionen 104 von dem Hypervisor 108 der Ebene 0 verwaltet, der durch Firmware umgesetzt wird, die auf den physischen Kernen 106 ausgeführt wird. Die logischen Partitionen 104 und der Hypervisor 108 weisen jeweils ein oder mehrere Programme auf, die sich in jeweiligen Abschnitten des zentralen Speichers (Arbeitsspeichers) befinden, der den physischen Kernen 106 zugehörig ist. Ein Beispiel für den Hypervisor 108 ist der Processor Resource/System Manager (PR/SM^TM, der von International Business Machines Corporation, Armonk, New York angeboten wird.
Der Systemcontroller 120, der in 1 mit dem zentralen Prozessorkomplex 102 verbunden ist, kann eine zentralisierte Logik enthalten, die für die Entscheidung zwischen verschiedenen Prozessoren zuständig ist, die Anforderungen ausgeben. Wenn der Systemcontroller 120 beispielsweise eine Anforderung für Zugriff auf den Arbeitsspeicher empfängt, bestimmt er, ob der Zugriff auf diese Speicherposition zulässig ist, und stellt gegebenenfalls die Inhalte dieser Speicherposition für den zentralen Prozessorkomplex 102 bereit, wobei die Arbeitsspeicherkonsistenz zwischen den Prozessoren in diesem Komplex beibehalten wird.
Unter folgender Bezugnahme auf 2 wird allgemein ein Blockschaubild einer Verarbeitungsschaltung 200 zum Umsetzen einer Maschine oder eines physischen Kerns, wie beispielsweise der physische Kern 106 in 1, gemäß einer Ausführungsform gezeigt. Die Verarbeitungsschaltung 200 kann einen physischen Kern einer Mehrzahl von physischen Kernen in einer Mehrprozessorumgebung enthalten. Die in 2 gezeigte Verarbeitungsschaltung 200 enthält eine Systemcontroller-Schnittstelleneinheit 202, die die Verarbeitungsschaltung 200 mit anderen Kernen und Peripherie-Einheiten verbinden kann. Die Systemcontroller-Schnittstelleneinheit 202 kann auch einen Dcache 204, der Datenwerte liest und speichert, einen Icache 208, der Programmanweisungen liest, und eine Cache-Schnittstelleneinheit 206 mit einem externen Arbeitsspeicher, Prozessoren und anderen Peripherie-Einheiten verbinden.
Der Icache 208 kann ein Laden von Anweisungsdatenströmen in Verbindung mit einer Anweisungsabrufeinheit (IFU) 210 bereitstellen, die Anweisungen vorabliest und Funktionalitäten für spekulatives Laden und Verzweigungsvoraussage enthalten kann. Die abgerufenen Anweisungen können für eine Anweisungsdecodiereinheit (IDU) 212 zum Entschlüsseln in Anweisungsverarbeitungsdaten bereitgestellt werden.
Die IDU 212 kann die Anweisungen für eine Ausgabeeinheit 214 bereitstellen, die die Ausgabe der Anweisungen an verschiedene Ausführungseinheiten steuern kann, wie beispielsweise eine oder mehrere Festkommaeinheiten (FXU) 216 zum Ausführen allgemeiner Operationen und eine oder mehrere Gleitkommaeinheiten (FPU) 218 zum Ausführen von Gleitkomma-Operationen. Die FPUs 218 können eine binäre Gleitkommaeinheit (BFU) 220, eine Dezimalgleitkommaeinheit (DFU) 222 oder eine andere Gleitkommaeinheit enthalten. Die Ausgabeeinheit 214 kann auch mit einer oder mehreren Lade-/Speichereinheiten (LSU) 228 über eine oder mehrere LSU-Pipelines verbunden werden. Die mehreren LSU-Pipelines werden als Ausführungseinheiten zum Ausführen von Lade- und Speichervorgängen und zur Adressgenerierung für Verzweigungen behandelt. Die LSU 228 und die IFU 210 können einen Adressumsetzpuffer (TLB) 230 verwenden, um gepufferte Umsetzungen für die Operanden- und Anweisungsadressen bereitzustellen
Die FXU 216 und FPU 218 sind mit verschiedenen Ressourcen verbunden, wie beispielsweise Mehrzweckregistern (GPR) 224 und Gleitkommaregistern (FPR) 226. Das GPR 224 und FPR 226 stellen einen Datenwertspeicher für Datenwerte bereit, die von einer LSU 228 aus dem Dcache 204 geladen und gespeichert wurden.
Unter folgender Bezugnahme auf 3 wird allgemein eine Datenverarbeitungsumgebung 300 gezeigt, die durch eine Ausführungsform umgesetzt werden kann. Die in 3 gezeigte Datenverarbeitungsumgebung 300 ähnelt der in 1 gezeigten Datenverarbeitungsumgebung 100 mit dem Zusatz eines Hypervisors 302 der Ebene 1, der die mit LP2 bezeichnete logische Partition 104 ausführt. Wie in 3 gezeigt, kann der Hypervisor 302 der Ebene 1 dieselben Hypervisorfunktionen bereitstellen, die vorher unter Bezugnahme auf den Hypervisor 108 beschrieben wurden (der hierin auch als „Hypervisor der Ebene 0“ bezeichnet wird), wie zum Beispiel transparentes Zeitscheibenverfahren für Ressourcen zwischen mehreren Betriebssystem (z.B. OS1 314, OS2 312 und OS3 310, die auf virtuellen Maschinen VM1 304, VM2 306 und VM3 308 ausgeführt werden) und Isolation dieser Betriebssysteme voneinander in der logischen Partition 104 mit der Bezeichnung LP2). Die in 3 gezeigte Ausführungsform enthält zum Beispiel drei virtuelle Maschinen, und andere Ausführungsformen können auf Grundlage von Anwendungsanforderungen mehr oder weniger virtuelle Maschinen enthalten.
Wie in 3 gezeigt, besitzt die mit LP1 bezeichnete logische Partition 104 ein residentes Betriebssystem 110, und die mit LP2 bezeichnete logische Partition 104 führt einen Hypervisor 302 der Ebene 1 aus, wodurch wiederum die virtuellen Maschinen 304, 306, 308 erstellt werden, von denen jede ihr eigenes residentes Betriebssystem 314, 312, 310 ausführt. Ein Hypervisor 302 der Ebene 1 kann von einer beliebigen Anzahl von logischen Partitionen 104 ausgeführt werden. In einer Ausführungsform ist der Hypervisor 302 der Ebene 1 der Hypervisor z/VM, der von International Business Machines Corporation, Armonk, New York angeboten wird. Die residenten Betriebssysteme, die in den verschiedenen logischen Partitionen ausgeführt werden, können unterschiedlich sein, und residente Betriebssysteme (z.B. die Betriebssysteme 314, 312, 310) in einer einzelnen Partition 104 (z.B. LP2) können ebenfalls unterschiedlich sein, wenn sie unter einem Hypervisor 302 der Ebene 1 ausgeführt werden. In einer Ausführungsform ist das Betriebssystem 110 in der mit LP1 bezeichneten logischen Partition 104 das Betriebssystem z/OS, das von International Business Machines Corporation, Armonk, New York angeboten wird. In einer Ausführungsform sind die Betriebssysteme 310 und 312 von Linux, und das Betriebssystem 314 ist z/OS.
Wenn ein Hypervisor 302 der Ebene 1 in einer logischen Partition 104 ausgeführt wird, kann er dieselbe Ressourcenvirtualisierung, die von einem Hypervisor der Ebene 0 für logische Partitionen 104 bereitgestellt wird, wie beispielsweise Hypervisor 108, für die Betriebssysteme 310, 312, 314 bereitstellen, die in den virtuellen Maschinen 308, 306, 304 ausgeführt werden. Wie auf der ersten Ebene kann jede virtuelle Maschine mehrere virtuelle Prozessoren enthalten.
Die physischen Kerne 106 enthalten physische Prozessorressourcen, die den logischen Partitionen 104 LP1, LP2, LP3 und LP4 dediziert zugewiesen oder gemeinsam von diesen genutzt werden, wie für 1 beschrieben. Wenn die logische Partition LP2 auf einer oder mehreren physischen Kernen zugeteilt ist, kann der Hypervisor 302 der Ebene 1 diese Ressourcen transparent auf seinen virtuellen Maschinen VM1 304, VM2 306 und VM3 308 gemeinsam nutzen. In einer Ausführungsform verwendet der Hypervisor 108 der Ebene 0 eine VE-Startanweisung mit angegebenem MT, um einen Multithread-Hypervisor 302 der Ebene 1 zuzuteilen, der anschließend eine VE-Startanweisung mit angegebenem ST verwendet, um virtuelle Einzel-Thread-Maschinen VM1 304, VM2 306 und VM3 308 zuzuteilen. In einer anderen Ausführungsform verwendet der Hypervisor 108 der Ebene 0 eine VE-Startanweisung mit angegebenem ST, um einen Einzel-Thread-Hypervisor 302 der Ebene 1 zuzuteilen, der anschließend eine VE-Startanweisung mit angegebenem MT verwendet, um virtuelle Multithread-Maschinen VM1 304, VM2 306 und VM3 308 zuzuteilen. In einer weiteren Ausführungsform weisen sowohl der Hypervisor 302 der Ebene 1 als auch seine Gast-VMs 304, 306, 308 einen Einzel-Thread auf.
in einer Gastmehrprozessor-(MP)Umgebung kann der Hypervisor eine als Systemsteuerbereich (SCA) bekannte Steuerstruktur verwalten, die sowohl vom Hypervisor als auch der Maschine zum Verwalten bestimmter Funktionen verwendet wird, was sich auf mehrere logische Prozessoren in der Gastkonfiguration auswirken kann. Dieselbe SCA-Herkunft (SCAO) wird in der Zustandsbeschreibung für alle Gastprozessoren in der Konfiguration oder virtuellen Maschine angegeben. In einer Ausführungsform kann dieser Bereich einen allgemeinen Bereich (der im Allgemeinen zum Koordinieren von Funktionen für die gesamte Gastkonfiguration verwendet wird) und separate prozessorspezifische Einträge enthalten. Der allgemeine Bereich enthält zum Beispiel Informationen darüber, welche virtuellen Prozessoren in der Gastkonfiguration gültig sind. Der separate prozessorspezifische Bereich in dem SCA kann zum Beispiel zum Interpretieren oder Emulieren von Funktionen zwischen Gastprozessoren verwendet werden, wie beispielsweise Unterbrechungen zwischen Prozessoren, oder zum Bereitstellen von leicht zugänglichen Zeigern auf die jeweilige Zustandsbeschreibung jedes logischen Prozessors. In einer Ausführungsform wird der für ST verwendete SCA auf MT-Verwendung erweitert, indem zusätzliche threadspezifische Einträge für jeden potenziellen Gast-Thread hinzugefügt werden.
Eine Ausführungsform einer Kernzuteilung kann es einem auf einem Einzel-Thread ausgeführten Hypervisor gestatten, einen Multithread-Gast auf seinem Kern unter Verwendung einer Variation der VE-Startanweisung zuzuteilen, was manchmal als virtueller Multithread-Ausführungsstart (start-MVE) bezeichnet wird. Jeder Thread in dem Multithread-Gast kann eine logische Gastzentraleinheit (CPU) oder einen Gast-Thread darstellen. Die VE-Startanweisung kann eine Ausführung eines Multithread-(MT)Gasts auf dem physischen Kern über ein Steuerfeld in der Zustandsbeschreibung aktivieren. Der Operand der VE-Startanweisung kann im Fall einer Verwendung zur Kernzuteilung entweder eine einzelne Zustandsbeschreibung angeben, die den Zustand aller Gast-Threads enthält, oder eine Gruppe von Zustandsbeschreibungen, von denen jede zum Beispiel den Zustand eines Threads eines einzelnen Gasts darstellt. In einer Ausführungsform enthält der logische Kern diese Gruppe von Zustandsbeschreibungen. Eine Kernzuteilung erfordert einen Einstieg in die virtuelle Ausführung, um den Zustand des logischen Kerns und jedes dieser logischen Gast-Threads in einen physischen Kern-Thread und seine Threads zu laden. Diese Threads können Anweisungsdatenströme sein, die unabhängig voneinander arbeiten. In verschiedenen Ausführungsformen kann eine Gruppe von Zustandsbeschreibungen auf vielerlei Arten angegeben werden, einschließlich als voneinander festgelegte Offsets, als Liste von Zustandsbeschreibungsadressen oder Zustandsbeschreibungen oder als kreisförmige Liste (Ring) von Zustandsbeschreibungen, die für den Kern gilt, wobei jede Zustandsbeschreibung in der Gruppe einen separaten Gast-Thread darstellt. Derartige Techniken gestatten einen einfachen Zugriff durch den Hypervisor und die Maschine auf andere Threads in dem logischen Kern und lassen Felder zu, die für den gesamten logischen Kern gelten, der an einer einzige Stelle verwaltet werden soll.
Das Gastbetriebssystem kann Multithread-Verarbeitung nutzen, indem einfach eine MT-Einrichtungsanweisung ausgegeben wird, die eine Multithread-Verarbeitung in dem Gast ermöglicht. Damit wird dem Gastbetriebssystem gestattet, diese neuen Threads als zusätzliche unabhängige CPUs zu behandeln und sie so zu verwalten, wie es ohne Multithread-Verarbeitung der Fall wäre. Außerdem kann das Gastbetriebssystem diese Threads unter Nutzung der Tatsache verwenden, dass sie einen Kern gemeinsam nutzen, oder es kann veranlassen, dass sie unabhängiger arbeiten. Für den Hypervisor und die Maschine ist all dies transparent. Der Hypervisor stellt dann diese zusätzlichen Threads für das Gastbetriebssystem bereit, während der Hypervisor selbst weiter auf einem einzelnen Thread pro Kern ausgeführt wird und einen Großteil der Gast-MT-Umgebung auf Kerngrundlage verwaltet. Die Aktivierung der Multithread-Verarbeitung durch das Betriebssystem wird ausführlicher in der U.S.-Patentanmeldungsnummer 14/226 895 mit dem Titel „Thread Context Preservation in a Multithreading Computer System“ beschrieben.
In einer Ausführungsform der Kernzuteilung ist die Zustandsbeschreibung, die als der Operand der VE-Startanweisung mit angegebenem MT angegeben ist, eine „primäre“ Zustandsbeschreibung, und der zugehörige logische Gast-Thread ist der „primäre“ Thread. Die anderen Zustandsbeschreibungen in der Gruppe werden hierin als „sekundäre“ Zustandsbeschreibungen bezeichnet und gelten, sofern zutreffend, für sekundäre logische Threads. Wenn die Zustandsbeschreibungsgruppe entweder als Liste oder Ring umgesetzt wird, kann in der primären Zustandsbeschreibung ein Feld mit der Beschreibung des nächsten Zustands (NSD) vorhanden sein, das auf die erste sekundäre Zustandsbeschreibung verweist, die wiederum 1) entweder auf die nächste sekundäre Zustandsbeschreibung in der Gruppe verweist oder 2) einen Wert enthält, der das Ende einer Gruppe angibt. Der NSD-Wert in der Zustandsbeschreibung für die letzte in der Liste kann die Adresse der primären Zustandsbeschreibung sein, wobei die Liste in diesem Fall einen Ring von Zustandsbeschreibungen bildet.
In einer Nicht-MT-Umsetzung teilt der Hypervisor jeweils einen logischen Gastprozessor (der hierin auch als „logischer Thread“ bezeichnet wird) auf einem bestimmten physischen Kern zu. Wenn ein bestimmter logischer Prozessor sich in einem ungültigen Zustand befindet, zum Beispiel im gestoppten Zustand oder in einem gesperrten Wartezustand, teilt der Hypervisor diesen Gast nicht zu. In einer MT-Umgebung ermöglicht die Kernzuteilung dem Hypervisor die gleichzeitige Zuteilung mehrerer Gast-Threads auf dem Kern. Um die Möglichkeit zu berücksichtigen, dass einer oder mehrere der Threads in der Zustandsbeschreibungsgruppe dieses logischen Kerns ungültig sind, verwendet eine Ausführungsform eine Thread-Gültigkeitsmaske (TVM) in der primären Zustandsbeschreibung, wobei jedes ihrer Bits aus Software-Perspektive die Gültigkeit des logischen Threads in der entsprechenden Zustandsbeschreibung in der Gruppe angibt.
In einer weiteren Ausführungsform sind nur gültige Threads in der Zustandsbeschreibungsgruppe enthalten, und es ist keine Gültigkeitsangabe notwendig. Eine Ausführungsform, die ungültige logische Threads in der Zustandsbeschreibungsgruppe enthält, gestattet dem Hypervisor den Zustand zu verwalten, der diesen ungültigen Threads zugehörig ist, und diese Threads können in der Zukunft wieder gültig werden. Die Maschine initialisiert und führt nur solche Threads aus, die einen gültigen Zustand aufweisen. Der Hypervisor teilt einen logischen Gastkern nur zu, wenn mindestens ein Thread in der Gruppe gültig ist.
Unter folgender Bezugnahme auf 4 wird allgemein eine Zustandsbeschreibung eines logischen Threads, der den Hauptteil des architekturdefinierten Zustands des Gasts enthält, gemäß einer Ausführungsform gezeigt. In diesem Kontext umfasst der Begriff „Zustandsbeschreibung“ nicht nur die Zustandsbeschreibung selbst, sondern auch die Satellitenblöcke, deren Zeiger sich in der Zustandsbeschreibung befinden, die als Erweiterung fungieren. Wie in 4 gezeigt, kann eine Zustandsbeschreibung 400 die Gastmehrzweckregister (GRs) 402, Zugriffsregister (ARs) 404, Steuerregister (CRs) 406, Gastzeitgeber 408 (einschließlich Uhrzeitvergleicher und CPU-Zeitgeber), Gastpräfixregister 410, virtuelle CPU-Nummer (VCN) 412, Programmstatuswort (PSW) und Anweisungsadresse (IA) 414 enthalten. Außerdem kann sie Steuerinformationen enthalten, wie beispielsweise Abfangsteuerungs-(IC)Bits 420 für die Angabe, ob bestimmte Anweisungen (z.B. Programmstatuswort laden (LPSW) und Seitentabelleneintrag ungültig machen) (IPTE) ein Abfangen für den Host erfordern, oder ob ein Löschen des Gastadressumsetzpuffers (TLB) erforderlich ist, bevor die Ausführung der Gastanweisung beginnen kann. Die Zustandsbeschreibung enthält auch die Beschreibung des nächsten Zustands (NSD) 422, die zum Definieren von Zustandsbeschreibungslisten und Ringen verwendet wird, wie in 6 bis 9 beschrieben. Die primäre Zustandsbeschreibung enthält auch die TVM 430, wie in 5 beschrieben, und die logische Partitionsnummer (LPN) 432. Die virtuelle CPU-Nummer (VCN) 412 entspricht der CPU-Nummer, die möglicherweise angepasst ist, um die Thread-Nummer im MT-Modus aufzunehmen, wie in der U.S.-Patentanmeldungsnummer 14/116 947 mit dem Titel „Address Expansion and Contraction in a Multithreading Computer System“ beschrieben.
Threads in einem Kern können durch eine binäre Thread-Kennung (TID) identifiziert werden. Der Kürze halber wird Thread x in den folgenden Figuren oft mit dem Begriff TIDx bezeichnet, was in diesem Fall bedeutet „der Thread mit der TID x“.
Unter folgender Bezugnahme auf 5 wird allgemein ein Blockschaubild einer Thread-Gültigkeitsmaske (TVM) 520 gemäß einer Ausführungsform gezeigt. Wie in 5 gezeigt, stellt Bit 0 530 der TVM 520 die Gültigkeit des logischen Threads 0 in der Zustandsbeschreibungsgruppe dar, Bit 1 531 stellt die Gültigkeit von Thread 1 dar, Bit 2 532 stellt die Gültigkeit von Thread 2 dar, Bit 3 533 stellt die Gültigkeit von Thread 3 dar usw. bis Bit n 537, das die Gültigkeit von Thread n darstellt, dem letzten möglichen logischen Thread in der diesem Kern zugehörigen Zustandsbeschreibungsgruppe. Die TVM kann sich in der primären Zustandsbeschreibung für die Gruppe befinden.
Unter folgender Bezugnahme auf 6 wird allgemein eine Struktur einer Zustandsbeschreibungsgruppe von festgelegten Offsets gemäß einer Ausführungsform gezeigt. Wie in 6 gezeigt, wird die Zustandsbeschreibungsgruppe mit voneinander festgelegten Offsets (N) angegeben. In diesem Fall verweist der Operand einer VE-Startanweisung 602 auf eine primäre Zustandsbeschreibung 603 für einen logischen Thread 0. Die sekundäre Zustandsbeschreibung für einen logischen Thread x 605 befindet sich in einem festgelegten Offset von N Byte nach der primären Zustandsbeschreibung, und die sekundäre Zustandsbeschreibung für einen logischen Thread y 607 befindet sich N Byte nach der sekundären Zustandsbeschreibung für Thread x. Dies setzt sich für alle Threads in der Gruppe fort. Die Anzahl der Threads in der Gruppe kann auf mehrere Arten bestimmt werden, einschließlich einer Anzahl in der primären Zustandsbeschreibung oder durch eine Ende-Markierung nach der letzten Zustandsbeschreibungsadresse in der Liste.
6 kann zwei Fälle darstellen, wobei im ersten Fall die Gruppe Zustandsbeschreibungen für alle logischen Threads in der Gruppe enthält, gleichgültig, ob sie gültig sind, und im zweiten Fall nur gültige Zustandsbeschreibungen in der Gruppe enthalten sind. Im ersten Fall stellt die Zustandsbeschreibung für Thread x 605 den Zustand von Thread 1 dar, und diejenige für Thread y 607 stellt den Zustand für Thread 2 dar. Die TVM 620, die nur in diesem ersten Fall benötigt wird, stellt die Gültigkeit jedes dieser logischen Threads dar. In dem zweiten Fall stellt die Zustandsbeschreibung für den Thread x 605 den Zustand des ersten gültigen logischen sekundären Threads dar, und die Zustandsbeschreibung für den logischen Thread y 607 stellt den Zustand des zweiten gültigen sekundären Threads dar. Wenn zum Beispiel Thread 1 nicht gültig ist und die Threads 2 und 3 beide gültig sind, würde der Thread x 605 Thread 2 darstellen, und der Thread y 607 würde Thread 3 darstellen. In der Gruppe wäre keine Zustandsbeschreibung für Thread 1 enthalten, da er ungültig ist. Diese selben beiden Fälle können auch auf die in den folgenden 7 bis 9 gezeigten Ausführungsformen angewendet werden, doch wird nur Fall 1 beschrieben und veranschaulicht.
Unter folgender Bezugnahme auf 7 wird allgemein eine als Liste angegebene Struktur einer Zustandsbeschreibungsgruppe gemäß einer Ausführungsform gezeigt. In diesem Fall stellt der Operand einer VE-Startanweisung 702 eine Liste von Zustandsbeschreibungsadressen dar, wobei der erste Eintrag in einer Liste 704 auf eine primäre Zustandsbeschreibung 705 für Thread 0 verweist, der zweite Eintrag in einer Liste 706 auf die sekundäre Zustandsbeschreibung für Thread 1 707 verweist, der dritte Eintrag in einer Liste 708 auf die sekundäre Zustandsbeschreibung für Thread 2 709 verweist usw., was sich für alle Threads in der Gruppe fortsetzt. Eine TVM 720 stellt die Gültigkeit jedes dieser Threads dar.
Unter folgender Bezugnahme auf 8 wird allgemein eine als verknüpfte Liste angegebene Struktur einer Zustandsbeschreibungsgruppe gemäß einer Ausführungsform gezeigt. In diesem wie auch dem in 6 veranschaulichten Fall verweist der Operand einer VE-Startanweisung 802 auf die primäre Zustandsbeschreibung für Thread 0 803, ein Zeiger 804 für die sekundäre Zustandsbeschreibung für Thread 1 805 wird aber stattdessen in der primären Zustandsbeschreibung als Feld 804 zur Beschreibung des nächsten Zustands (NSD) bereitgestellt. Ein Zeiger 806 für die sekundäre Zustandsbeschreibung für Thread 2 807 wird wiederum als eine NSD 806 in der sekundären Zustandsbeschreibung für Thread 1 bereitgestellt. Dies würde für alle Threads in der Gruppe mit einer NSD 810 in der Zustandsbeschreibung für einen letzten Thread n 809 fortgesetzt, der als Nullen oder irgendein anderer eindeutiger Wert angegeben wird, der das Ende der Liste angibt. Eine in der primären Zustandsbeschreibung 803 bereitgestellte TVM 820 stellt die Gültigkeit jedes dieser Threads dar.
Unter folgender Bezugnahme auf 9 wird allgemein eine als kreisförmige Liste oder Ring angegebene Struktur einer Zustandsbeschreibungsgruppe gemäß einer Ausführungsform gezeigt. Dieser Fall ist mit dem in 8 gezeigten Fall insofern identisch, als der Operand einer VE-Startanweisung 902 auf eine primäre Zustandsbeschreibung 903 für Thread 0 verweist, die eine NSD 904 für die sekundäre Zustandsbeschreibung für Thread 1 905 enthält, die eine NSD 906 für die sekundäre Zustandsbeschreibung für Thread 2 907 enthält, und dies wird für alle Threads bis zum letzten Thread n fortgesetzt. In der in 9 gezeigten Ausführungsform bildet eine NSD 910 in der Zustandsbeschreibung für Thread n 909 jedoch eine kreisförmige Liste und verweist auf die primäre Zustandsbeschreibung 903 zurück. Eine in der primären Zustandsbeschreibung 903 bereitgestellte TVM 920 stellt die Gültigkeit jedes dieser Threads dar.
Die Kernzuteilung gestattet dem Hypervisor, viele Aspekte der logischen Threads auf der Kernebene zu verwalten. Eine Kernzuteilung vereinfacht nicht nur oft den Hypervisorcode, der für die Thread-Verwaltung erforderlich ist, indem die Koordinierung einer virtuellen Ausführung von mehreren Threads eines Kerns mit Push-Operation in die Maschine übertragen wird, sondern kann auch den Aufwand verringern, der zum Verwalten von mehreren Prozessoren in der Konfiguration erforderlich ist. Eine Prioritätsverwaltung für logische Partitionen (oder Gäste) kann weiterhin auf der logischen Kernebene erfolgen, wodurch der Skalierungsdruck auf diese Art der Verwaltung verringert wird. Der Hypervisor selbst muss immer noch die Sammlung von Threads verwalten, die einem logischen Kern zugehörig sind, um sicherzustellen, dass alle seiner Anforderungen (wie beispielsweise Abfangvorgänge für Anweisungen) erfüllt werden, bevor die VE-Startanweisung erneut ausgegeben wird.
Unter folgender Bezugnahme auf 10 wird allgemein ein Kernzuteilungsprozess gemäß einer Ausführungsform gezeigt. Wie in 10 gezeigt, wird ein Hypervisor mit einem einzelnen Thread auf einem physischen Kern N 1010 und einem physischen Thread A 1020 ausgeführt. Im Block 1022 gibt der Hypervisor die VE-Startanweisung mit angegebenem MT aus, um den Multithread-Gastkern zuzuteilen. Die Maschine bestimmt, dass es sich um einen Multithread-Gast handelt und stellt im Block 1024 die physischen Threads B und C für die Ausführung von Software zur Verfügung. Die Maschine lädt den Gastzustand aus der Zustandsbeschreibung für jeden der Threads in einen entsprechenden physischen Thread. In der in 10 dargestellten Ausführungsform verwendet die Maschine mehrere physische Threads zum Ausführen dieser Funktion, das heißt, auf dem physischen Thread A 1020 ausgeführter Millicode lädt den Zustand des logischen Gast-Threads X in den physischen Thread A, wie im Block 1026 gezeigt. Desgleichen lädt Millicode, der auf den physischen Threads B 1040 und C 1060 ausgeführt wird, den Zustand der logischen Gast-Threads Y und Z in die physischen Threads B und C, wie in den Blöcken 1046 und 1066 gezeigt. Sobald der Gastzustand geladen ist, läuft die auf den logischen Gast-Threads X, Y und Z ausgeführte Software auf den physischen Threads A, B und C, wie in den Blöcken 1028, 1048 und 1068 gezeigt.
Unter folgender Bezugnahme auf 11 wird allgemein ein koordinierter Ausstieg aus der virtuellen Ausführung gemäß einer Ausführungsform gezeigt. Wie in 11 gezeigt, führen die logischen Gast-Threads X, Y und Z Gast-Software auf physischen Threads A 1120, B 1140 und C 1160 aus, wie in den Blöcken 1128, 1148 und 1168 angegeben. Einer oder mehrere Gast-Threads bestimmen, dass ein Ausstieg aus der virtuellen Ausführung erforderlich ist. Unter Bezugnahme auf 11 bestimmt ein logischer Gast-Thread Y, der auf dem physischen Thread B 1140 ausgeführt wird, dass er die virtuelle Ausführung verlassen muss, wie im Block 1150 gezeigt, was die Maschine veranlasst, den physischen Threads A 1120 und C 1160 den Ausstieg aus der virtuellen Ausführung zu signalisieren, wie im Block 1152 gezeigt. In den Blöcken 1136, 1154 und 1174 koordiniert Millicode, der auf jedem der physischen Threads ausgeführt wird, den Ausstieg aus der virtuellen Ausführung und blockiert anschließend die Verfügbarkeit der physischen Threads B 1140 und C 1160 für die Verwendung durch Software, wie in den Blöcken 1156 und 1176 angegeben. Millicode auf dem physischen Thread A 1120 lädt den Host-Zustand erneut in die Hardware, wie im Block 1138 gezeigt, was zu der Ausführung der Hypervisor-Software auf dem physischen Thread A führt, wie im Block 1140 gezeigt. Der Hypervisor verarbeitet anschließend je nach Bedarf alle ausstehenden Gastabfangvorgänge und Host-Unterbrechungen.
12 stellt ein Blockschaubild eines kernorientierten Systemkontrollbereichs (COSCA) für eine Einzelgastkonfiguration mit mehreren logischen Kernen gemäß einer Ausführungsform dar. Der in 12 gezeigte COSCA kann zum Bereitstellen von Koordination zwischen logischen Threads in einem Kern und zwischen logischen Threads auf verschiedenen Kernen verwendet werden. Der COSCA kann einen allgemeinen Bereich enthalten, der die gesamte Gastkonfiguration mit Zeigern darstellt, einen für jeden logischen Kern, um Kernbeschreibungsbereiche zu trennen. Jede Kernbeschreibung enthält einen allgemeinen Bereich, der diesen Kern und eine Reihe von zusammenhängenden, separaten threadspezifischen Bereichen oder Thread-Beschreibungen für diesen Kern enthält. In einer weiteren Ausführungsform stellt die Kernbeschreibung die Speicherorte der Thread-Beschreibungen bereit. Die bereitgestellten Speicherorte können eingeschlossen sein (z.B. sind sie eine Liste, die in der Kernbeschreibung enthalten ist, oder sie können sich in Arbeitsspeicherblöcken befinden, die auf die Kernbeschreibung folgen). In weiteren Ausführungsformen können Zeiger auf andere Arbeitsspeicherorte bereitgestellt werden, die die Thread-Beschreibungen enthalten. Der hierin verwendete Begriff „Angabe eines Speicherorts“ wird verwendet, um auf irgendeinen davon zu verweisen oder auf irgendeine zusätzliche Art zum Bestimmen eines Speicherorts eines Elements (z.B. die Thread-Beschreibungen oder andere Elemente in dem COSCA). Diese Struktur verwaltet die baumähnliche Darstellung der MT-Gastkonfiguration, die in manchen Situationen, insbesondere auf der Hypervisor-Ebene, die Verwaltung von Elementen auf Kerngrundlage, aber in anderen Situationen die Verwaltung von Dingen auf einer Thread- oder Prozessor-Grundlage vereinfacht.
Dieselbe COSCA-Herkunft (COSCAO) kann im Feld SCA-Herkunft (SCAO) in den Zustandsbeschreibungen für alle Gast-Threads in der Gastkonfiguration bereitgestellt werden, und dieselbe Kernbeschreibungsbereichsadresse (CDAA) kann für alle Threads in einem bestimmten Kern bereitgestellt werden. Ein Vorteil dieser Ausführungsform besteht darin, dass nicht viel zusammenhängender Speicher erforderlich ist, dessen Bereitstellung für einige Hypervisoren schwierig sein kann. Eine weitere Ausführungsform könnte eine zusätzliche Dereferenzierungsebene hinzufügen und veranlassen, dass jede Kernbeschreibung eine Liste von Zeigern für jeden threadspezifischen Bereich enthält, wodurch die Notwendigkeit von Steuerblöcken mit diesen zusammenhängenden Bereichen entfällt.
Unter folgender Bezugnahme auf 12 wird allgemein eine beispielhafte Ausführungsform eines COSCA für eine Einzelgastkonfiguration gezeigt, die zwei logische Kerne mit drei logischen Threads in jedem Kern enthält. In einer Ausführungsform enthält der COSCA die Inhalte des allgemeinen COSCA-Bereichs 1260 (in 12 als „COSCACA 1260“ gezeigt), eines Kernbeschreibungsbereichs 1270 und Kernbeschreibungsbereichs 1280. Die primäre Zustandsbeschreibung für die einem logischen Kern 0 1203 zugehörige Zustandsbeschreibungsgruppe wird als der Operand der VE-Startanweisung angegeben, die durch den Hypervisor zum Zuteilen eines Gastkerns 0 1202 verwendet wird. Außerdem wird die primäre Zustandsbeschreibung für die einem logischen Kern 1 1233 zugehörige Zustandsbeschreibungsgruppe als der Operand der VE-Startanweisung angegeben, die zum Zuteilen eines Kerns 1 1232 verwendet wird. Diese primäre Zustandsbeschreibung für den „Kern 0 Thread 0“ 1203 enthält eine NSD01 1205, die auf die sekundäre Zustandsbeschreibung für einen Kern 0 Thread 1 1213 verweist, die wiederum eine NSD01 1215 enthält, die auf die letzte sekundäre Zustandsbeschreibung für einen Kern 0 Thread 2 1223 in der Gruppe verweist. Desgleichen beginnt die Zustandsbeschreibungsgruppe für den logischen Kern 1 mit der primären Zustandsbeschreibung für den Kern 1 Thread 0 1233, die eine NSD11 1235 enthält, die auf die sekundäre Zustandsbeschreibung für einen Kern 1 Thread 1 1243 verweist, die wiederum eine NSD12 1245 enthält, die auf die letzte sekundäre Zustandsbeschreibung für einen Kern 1 Thread 2 1253 in der Gruppe verweist. Die Zustandsbeschreibungen für alle sechs Threads in dieser Gastkonfiguration 1203 1213 1223 1233 1243 1253 enthalten denselben Wert in der SCAO 1204 1214 1224 1234 1244 1254, die auf den allgemeinen COSCA-Bereich 1260 verweist.
Der in 12 gezeigte allgemeine COSCA-Bereich 1260 enthält Informationen auf Kernebene, die zum Koordinieren von Funktionen für die gesamte Gastkonfiguration verwendet werden. Der allgemeine COSCA-Bereich 1260 enthält eine SCA-Kerngültigkeitsmaske (SCVM) 1261, die die Gültigkeit jedes logischen Kerns in der Gastkonfiguration angibt und auch eine Kernbeschreibungsbereichsadresse (CDAA) für jeden Kern 1262 1264 enthält. Die Bits in der SCVM und im Array von Kernbeschreibungsadressen können durch die Kernnummer indexiert werden. CDAA0 1262, die auf den Kernbeschreibungsbereich (CDA) für den Kern 0 1270 verweist, ist im allgemeinen COSCA-Bereich 1260 enthalten. Außerdem verweist das CDAA-Feld in den Zustandsbeschreibungen für alle Threads in Kern 0 1206 1216 1226 auch auf den CDA für den Kern 0 1270. CDAA1 1264, die auf den CDA für den Kern 1 1280 verweist, ist auch im allgemeinen COSCA-Bereich 1260 enthalten, und desgleichen verweist das CDAA-Feld in den Zustandsbeschreibungen für alle Threads in Kern 1 1236 1246 1256 auch auf den CDA für den Kern 1 1280. Der Kernbeschreibungsbereich (CDA) für den Kern 0 1270 enthält eine SCA-Thread-Gültigkeitsmaske (STVM0) 1271, die die Gültigkeit jedes logischen Threads in Kern 0 angibt. Er enthält auch die Thread-Beschreibungsbereiche für einen Kern 0 Thread 0 1272, einen Thread 1 1274 und einen Thread 2 1276. Der CDA für den Kern 1 1280 enthält desgleichen eine STVM1 1281 und die Thread-Beschreibungsbereiche für einen Kern 1 Thread 0 1282, einen Thread 1 1284 und einen Thread 2 1286. Jeder dieser Thread-Beschreibungsbereiche 1272 1274 1276 1282 1284 1286 enthält eine Zustandsbeschreibungsadresse (SDA) 1273 1275 1277 1283 1285 1287 für den Thread, der jeweils dem Thread-Beschreibungsbereich von Kern 0 Thread 0, Kern 0 Thread 1, Kern 0 Thread 2, Kern1 Thread 0, Kern1 Thread 1 und Kern 1 Thread 2 entspricht. Die Bits in der STVM und im Array von Thread-Beschreibungsbereichen können durch die Thread-Kennung indexiert werden. Diese SDAs erleichtern es dem Hypervisor, Threads in einem Kern zu verwalten, und der Maschine, Unterbrechungen zwischen Gastprozessoren darzustellen.
13 stellt einen Prozessablauf zum Verwalten von Multithread-Kernen gemäß einer Ausführungsform dar, die den in 12 gezeigten COSCA verwendet. In dem in 13 gezeigten Beispiel am Block 1302 hat ein Gastbetriebssystem (OS), das auf einem ersten physischen Thread ausgeführt wird (z.B. Kern 0 Thread 1, definiert durch die Zustandsbeschreibung 1213), bestimmt, dass es einen zweiten logischen Thread oder Ziel-Thread (z.B. Kern 1 Thread 2, definiert durch die Zustandsbeschreibung 1253) signalisieren wird. Am Block 1304 nimmt das Gastbetriebssystem dies zum Beispiel durch Ausgeben einer Anweisung zur Unterbrechung zwischen Prozessoren vor. Die Maschine verwendet als Teil der Ausführung der Anweisung zur Unterbrechung zwischen Prozessoren den COSCA, um die Anweisung zur Unterbrechung zwischen Gastprozessoren zu emulieren. Die Anweisung zur Unterbrechung zwischen Prozessoren wird durch die Maschine emuliert, da der Kern, der den logischen Ziel-Thread enthält, zum Zeitpunkt der Signalisierung zugeteilt oder nicht zugeteilt sein kann. Am Block 1306 sucht die Maschine (z.B. über die SCA0 1214, da die Anweisung zur Unterbrechung zwischen Prozessoren durch den logischen Kern 0 Thread 1 ausgeführt wurde) einen allgemeinen Bereich (z.B. den allgemeinen COSCA-Bereich 1260) für die Gastkonfiguration, um auf eine SCVM (z.B. die SCVM 1261) zuzugreifen, um die Gültigkeit des Zielkerns zu prüfen und die entsprechende CDAA (z.B. die CDAA1 1264) zu erhalten, da sich der Ziel-Thread auf Kern 1 befindet).
Am Block 1308 sucht die Maschine als Nächstes (z.B. über die CDA1 1264) den Kernbeschreibungsbereich für den Zielkern (z.B. die CDA 1280). Die Maschine prüft, ob der Ziel-Thread gültig ist, indem sie auf eine STVM im Kernbeschreibungsbereich zugreift (z.B. die STVM1 1281 im CDA 1280). Am Block 1310 sucht die Maschine den Thread-Beschreibungsbereich (z.B. Thread-Beschreibungsbereich 1286, der dem Thread 2 entspricht, da Thread 2 der Ziel-Thread ist). Am Block 1312 werden Informationen über die Unterbrechung in dem Thread-Beschreibungsbereich für den Ziel-Thread aufgezeichnet (z.B. wird die Identität des sendenden Threads in den Thread-Beschreibungsbereich 1286 gestellt). Am Block 1314 sucht die Maschine (z.B. über die SDA 12 1287 im Thread-Beschreibungsbereich 1286) die Zustandsbeschreibung für den Ziel-Thread (z.B. sekundäre Zustandsbeschreibung für den Kern 1 TID1 1253). Am Block 1316 wird veranlasst, dass die Unterbrechung in der Zielzustandsbeschreibung als ausstehend angegeben wird (z.B. wird das IP-Bit 1275 in der Zustandsbeschreibung für den Kern 1 TID2 1253 gesetzt). Wenn der logische Zielprozessor (z.B. Kern 1 Thread 2) als Ergebnis dessen auf einem physischen Thread zugeteilt wird und für die Unterbrechung aktiviert ist, gibt die Maschine die Unterbrechung, sofern aktiviert, für das Gastbetriebssystem an. Wenn der logische Zielprozessor zu dem Zeitpunkt bereits zugeteilt ist, zu dem die Unterbrechung ausstehend wird, wird die Unterbrechung angenommen, sobald sie aktiviert wird.
Es gibt Fälle, in denen die Maschine auch die Tatsache nutzen kann, dass Threads in einem logischen Kern gemeinsame Attribute aufweisen. Zum Beispiel bietet sich die Kernzuteilung selbstverständlich dafür an, zu veranlassen, dass sich alle Gast-Threads auf einem logischen Kern in derselben LPAR-Zone oder Partition befinden. Die Auslegung kann die Hardware klein halten, indem der Zone zugehörige Elemente nur einmal pro Kern umgesetzt werden müssen, anstatt einmal pro Thread. Außerdem kann eine komplizierte Steuerlogik (zum Beispiel Bearbeitung von systemweiten Unterbrechungen) ebenfalls vereinfacht werden, da sie sich nur mit einem einzigen Kernwert befassen muss.
In einer Ausführungsform wird jedes Feld (oder Bit in einem Feld) in der Gruppe von Zustandsbeschreibungen, die einen Multithread-Gast darstellen, als primär, mit gemeinsamem Kern oder threadspezifisch klassifiziert. Ein primäres Feld befindet sich nur in der primären Zustandsbeschreibung und gilt für alle Prozessoren in dem logischen Kern; jeder Zugriff auf ein primäres Feld für einen beliebigen Thread eines Kerns muss den Wert aus der zugehörigen primären Zustandsbeschreibung verwenden. Diese Klassifizierung wird für Felder verwendet, die den Gesamtzustand des Kerns definieren, wie beispielsweise die Thread-Gültigkeitsmaske. Ein Kernen gemeinsames Feld ist für alle Prozessoren in einem logischen Kern üblich, und dieses Feld hat denselben Wert in jeder Zustandsbeschreibung in der Gruppe; jeder Zugriff auf eines dieser Felder für einen Prozessor kann den Wert aus einer beliebigen Zustandsbeschreibung in der Gruppe verwenden. Diese Klassifizierung wird für Felder verwendet, die über den gesamten Kern übergreifend verwendet werden, wie beispielsweise die LP-Nummer. Der Hypervisor muss die Kernen gemeinsamen Felder in allen Zustandsbeschreibungen verwalten, aber die Maschine darf auf dieses Feld in der Zustandsbeschreibung jedes Threads zugreifen, der gerade die beste Leistung bietet. Da diese Felder durch den Hypervisor nicht oft geändert werden, die Maschine bei jedem Einstieg in die virtuelle Ausführung aber oft darauf zugreift, ermöglicht die Definition eines Kernen gemeinsamen Felds statt eines threadspezifischen den Einstieg in die virtuelle Ausführung beispielsweise zum Laden einer sekundären Thread-Funktion aus dem primären Thread unter Verwendung des Werts in der primären Zustandsbeschreibung. Ein threadspezifisches Feld ist für jeden logischen Thread spezifisch; jeder Zugriff auf eines dieser Felder für irgendeinen Thread muss den Wert aus der Zustandsbeschreibung dieses Threads verwenden. Diese Klassifizierung wird für Felder verwendet, die typischerweise zwischen Threads eindeutig sind, wie beispielsweise das Gastpräfix.
Eine Ausführungsform enthält eine Maschinenumsetzung der Kernzuteilungsanweisung. Wenn ein Hypervisor eine Kernzuteilung oder eine VE-Startanweisung mit angegebenem MT ausgibt, wird der logische Kern, der durch die zugehörige Zustandsbeschreibungsgruppe beschrieben wird, durch den Millicode des Einstiegs in die virtuelle Ausführung (VE-Einstieg) in einen physischen Kern geladen. Als Teil dieses Prozesses wird der Zustand jedes gültigen logischen Threads in einen physischen Thread geladen. Die Zuordnung von logischen Threads zu physischen Threads kann eine direkte Eins-zu-Eins-Zuordnung oder virtualisiert sein. Bevor der VE-Einstieg beginnt, enthalten die Inhalte jedes physischen Threads den Zustand des jeweils zuletzt darauf ausgeführten virtuellen Threads. Daher ersetzt der VE-Einstiegs-Millicode den gesamten Zustand durch den Zustand des neu zugeteilten Gast-Threads.
Wenn die Kernzuteilung durch einen Einzel-Thread-Hypervisor aufgerufen wird, ist der Millicode dafür zuständig, den Zustand des einzelnen Gast-Threads (logischer Prozessor) in die Hardware zu laden und die Hardware einzurichten, um mit der Multithread-Ausführung zu beginnen. Indem zugelassen wird, dass jeder physische Thread den größten Teil seines eigenen Zustands zum Verbessern der Effizienz parallel lädt, kann der Millicode eine kleine Anzahl von Hardware-Registern für jeden der sekundären Threads laden (entweder durch den primären Thread oder einen anderen, bereits initiierten sekundären Thread). Dies kann erfordern, dass ein sekundärer Thread, der von einer Hardware-Perspektive aus aktuell inaktiv ist, „aufgeweckt“ werden muss, um mit der Ausführung einer Millicode-Routine zu beginnen, die die Initialisierung ihres eigenen Gastzustands abschließt und schließlich mit der Ausführung des Gastprogramms beginnt. Es gibt Fälle, in denen auch ohne die Ausführung eines Hypervisors oder Gastprogrammcodes auf einem sekundären Thread eine interne Firmware ausgeführt werden kann, um zum Beispiel eine interne Systemverwaltungsfunktion zu verarbeiten. Wenn dies der Fall ist, muss die Maschine dies mit der Zuteilung der Gast-Threads koordinieren.
Es gibt einige Operationen, wie beispielsweise Löschen des TLB, deren Anwendung für den gesamten Kern angegeben werden kann. Damit entfällt die Notwendigkeit für jeden Thread zu bestimmen, ob der Löschvorgang notwendig ist, und den Löschvorgang erforderlichenfalls auszuführen. Außerdem gibt es einige Kernressourcen, die gemeinsam genutzt werden oder den physischen Threads in einem Kern gemeinsam sind. Millicode kann die Tatsache nutzen, dass gemeinsam genutzte Ressourcen nur aus einem einzelnen Thread geladen werden müssen, und dass ein einzelner Thread alle Kopien von gemeinsamen Thread-Ressourcen laden kann, wenn sich dadurch Einsparungen erkennen lassen. VE-Einstieg-Millicode kann auch die Bits für aktivierte Gast-Multithread-Ausführung und Thread-Gültigkeit zum Umgehen der Initialisierung von ungültigen logischen Threads in dem Bemühen verwenden, die Ausführung des Initialisierungs-Millicodes auf den gültigen Threads zu beschleunigen. Die flexible Hardware-Auslegung ermöglicht es Ausführungsformen des Millicodes, ihre Umsetzungen in Weiterentwicklungen der Auslegung zu optimieren.
Unter folgender Bezugnahme auf 14A und 14B wird allgemein eine Maschinenumsetzung einer Kernzuteilung gemäß einer Ausführungsform gezeigt. Wie in 14A am Block 1400 gezeigt, wird eine Kernzuteilung durch den Hypervisor initiiert, der auf einem einzelnen Thread (bezeichnet als der primäre Thread) unter Verwendung einer VE-Startanweisung mit angegebenem MT ausgeführt wird. Auf der Grundlage, dass der Hypervisor die VE-Startanweisung ausgibt, wird der VE-Einstieg-Millicode auf dem primären Thread aufgerufen, d.h. dem Thread, der die Anweisung ausgegeben hat, und er beginnt mit der Multithreading-Initiierung auf der Hardware für den gesamten Kern. Ein großer Teil dieser Initialisierung kann ein Testen von Hardware-Zustandsbits aus allen anwendbaren sekundären Threads und/oder Einrichten von Hardware-Steuerbits oder Feldern in allen anwendbaren sekundären Threads enthalten. Die in 14A gezeigten Steuer- und Zustandsbits 1450 können sich logisch in der Hardware des sekundären Threads selbst befinden, oder sie können sich logisch in allen allgemeinen Hardware-Ressourcen befinden, die von den Threads gemeinsam genutzt werden, die aber den sekundären Thread darstellen und steuern. Am Block 1402 bestimmt der VE-Einstieg-Millicode unter Verwendung der Thread-Gültigkeitsmaske (TVM) in der Zustandsbeschreibung, welcher bzw. welche logischen Gast-Threads von einer Software-Perspektive aus gültig sind und daher in die Hardware geladen werden müssen. Außerdem bestimmt er die Zuordnung der gültigen logischen Threads zu physischen Threads.
Die Blöcke 1404 bis 1414 von 14A werden durch den Millicode zur Überprüfung ausführt, ob die angeforderten physischen Threads verfügbar sind. Am Block 1404 hindert der Millicode die anwendbaren sekundären Hardware-Threads an der Annahme neuer Unterbrechungen, die einen internen Code aufrufen können, oder am Beginn der Ausführung irgendeines neuen Programmcodes. Dies kann durch die Einrichtung geeigneter Hardware-Steuerungen in dem oder den sekundären Threads erreicht werden. Am Block 1406 wird bestimmt, ob Software auf den sekundären Threads ausgeführt wird. In einer Ausführungsform garantiert der Hypervisor, der die VE-Startanweisung auf dem primären Thread ausgibt, dass andere Hardware-Threads auf diesem Kern keinen Programmcode ausführen (z.B. Hypervisor oder Gast-Code). In einer anderen Ausführungsform ist der Hypervisor, der die VE-Startanweisung ausgibt, möglicherweise nicht fähig, ohne Schwierigkeiten zu bestimmen, ob irgendwelche anderen Hardware-Threads, die für diesen neuen VE-Start erforderlich sind, Programmcode ausführen, zum Beispiel Code, der einem unabhängigen VE-Start zugehörig ist. In diesem Fall prüft der VE-Einstieg-Millicode das bzw. die entsprechenden Hardware-Zustandsbits auf dem bzw. den sekundären Threads am Block 1406.
Wenn am Block 1406 bestimmt wird, dass Programmcode auf Hardware ausgeführt wird, die zum Ausführen eines sekundären Gast-Threads benötigt wird, wird die neue VE-Startanweisung abgeschlossen, und am Block 1408 wird der Hypervisor durch die Maschine informiert, dass die VE-Startanweisung nicht erfolgreich war, und wird möglicherweise über die Anzahl von derzeit verfügbaren Hardware-Threads informiert. In Reaktion darauf kann der Hypervisor geeignete Maßnahmen ergreifen, wie beispielsweise die Anzahl gültiger Gast-Threads zu verringern, die zugeteilt werden sollen, oder eine bestimmte vorab festgelegte Zeit zu warten, wie am Block 1410 angegeben, bevor die VE-Startanweisung erneut am Block 1400 ausgegeben wird. Wenn am Block 1406 bestimmt wird, dass die Hardware verfügbar ist, fährt die Verarbeitung mit Block 1412 fort. Am Block 1412 bestimmt der Millicode zum Beispiel durch Prüfen des oder der entsprechenden Zustandsbits in der Hardware, ob irgendeiner bzw. irgendwelche der anwendbaren sekundären Hardware-Threads internen Firmware-Code ausführen. Ist dies der Fall, wartet der primäre Thread in einer Ausführungsform darauf, dass der bzw. die sekundären Threads die Ausführung des internen Codes beenden, und um Blockierungen zu vermeiden, kann der primäre Thread während des Wartens bestimmte Unterbrechungen akzeptieren. Er kann jedoch den oder die sekundären Threads für die Annahme anderer Unterbrechungen sperren, sodass sie den Leerlauf schneller erreichen. Die Verarbeitung wird anschließend am Block 1416 fortgesetzt. Wenn in einer weiteren Ausführungsform ein Hardware-Thread internen Firmware-Code ausführt, wie am Block 1412 bestimmt, kann die Maschine die VE-Startanweisung auf Nullwert setzen und die Steuerung am Block 1414 wieder an den Hypervisor zurückgeben, Damit erhält der primäre Thread die Möglichkeit, Unterbrechungen der internen Firmware anzunehmen und potenzielle Blockierungen zu vermeiden, und sobald keine Unterbrechung mehr auf dem primären Thread aussteht, wird die VE-Startanweisung wieder ausgeführt. Beide dieser Ausführungsformen haben Vorteile im Vergleich mit einem Anhalten der internen Firmware und deren erneutem Starten auf der Hardware beim Abschließen von Multithread-Arbeit, da eine Operation von Firmware-Code oft wesentlich für den Systembetrieb ist (zum Beispiel gleichzeitig ablaufendes Upgrade), und außerdem führen Threads interne Firmware selten genug aus, sodass die Option, auf das Ende der Ausführung zu warten, durchaus praktikabel ist.
Die Verarbeitung fährt dann am Block 1416 fort, mit dem Laden des oder der logischen Threads in die physischen Threads auf dem physischen Kern zu beginnen. Am Block 1416 prüft der Millicode auf Ausnahmen in Bezug auf bestimmte Ausnahmebedingungen und nimmt sie an. Einige der Ausnahmebedingungen können für die VE-Startanweisung selbst gelten (z.B. ungültige Ringstruktur der Zustandsbeschreibung), und andere betreffen die Bedingungen, die auf einen sekundären logischen Thread anwendbar sind (z.B. eine Zugriffausnahme auf einer NSD). Am Block 1418 können Einträge aus assoziativen Gast-Hardwarepufferspeichern (einschließlich TLBs) gelöscht werden. Dazu kann ein Löschen von assoziativen Pufferspeichern für den bzw. die sekundären Threads gehören, sofern anwendbar. Am Block 1420 werden die Mindestzustände aus den primären und sekundären Zustandsbeschreibungen geladen, und die erforderlichen Hardware-Funktionen werden einschließlich jedes der gültigen Threads initialisiert In einer Ausführungsform enthalten die Mindestzustände die Zustandsbeschreibungsadressen für die sekundären Threads. Am Block 1422 kontrolliert die Hardware, ob der bzw. die sekundären Threads so eingerichtet sind, dass sie ein Abrufen von irgendeinem internen Anweisungsdatenstrom bzw. Anweisungsdatenströmen stoppen. Dies kann einen Wechsel von einer Einzel-Thread-Ausführung zu einer Multithread-Ausführung vereinfachen. Am Block 1424 wird die Millicode-Anweisungsadresse (milli-IA) für jeden des oder der anderen gültigen sekundären Threads geladen. Die milli-IA ist der Speicherort, an dem die sekundären Threads die Ausführung starten, sobald sie mit dem Abrufen eines internen Anweisungsdatenstroms beginnen, und typischerweise verweist sie auf einen Speicherort im Millicode, der die Initialisierung jedes gültigen logischen Threads abschließt. Der primäre Thread fährt mit der Ausführung von VE-Einstieg-Millicode fort, und daher muss dort keine neue milli-IA geladen werden. In einer Ausführungsform weckt der primäre Thread am Block 1426 den oder die sekundären Threads durch Einrichten von Hardware-Steuerungen auf, die ihren Ausführungsmodus in Millimodus ändern, was dazu führt, dass sie mit der Ausführung an der vorher geladenen milli-IA beginnen. In einer anderen Ausführungsform kann der primäre Thread (Ta) den ersten sekundären Thread (Tb) aufwecken; Tb kann den nächsten sekundären Thread (Tc) aufwecken; und so weiter, bis alle gültigen Threads aktiv sind und in der Hardware ausgeführt werden. In einer Ausführungsform beginnen sekundäre Threads mit der Ausführung von Millicode-Anweisungen erst, wenn ein anderer Thread seinen Ausführungsmodus auf Millicode-Ausführungsmodus oder Millimodus setzt.
Unter folgender Bezugnahme auf 14B führen an den Blöcken 1428 und 1478 der primäre Thread und jeder gültige sekundäre Thread den Millicode aus, der zum Abschließen des Ladens des Zustands des zugehörigen logischen Gast-Threads in Hardware nötig ist. In einer Ausführungsform enthält der Zustand die/das Gastmehrzweckregister (GRs) 402, Zugriffsregister (ARs) 404, Steuerregister (CRs) 406, Präfixregister 408, Gastzeitgeber 410, virtuelle CPU-Nummer (VCN) 412, Programmstatuswort (PSW) und Anweisungsadresse (IA) 414, Abfangsteuerungs-(IC)Bits 420 und logische Partitionsnummer (LPN) 432, wie in 4 gezeigt. An den Blöcken 1430 und 1480 schließen der primäre Thread und die sekundären Threads die Ausführung des VE-Einstiegs ab, und sie verlassen den Millicode-Modus (z.B. Millimodus). An den Blöcken 1432 und 1482 beginnen sie mit der Ausführung des Programmanweisungsdatenstroms des Gast-Threads. In einer Ausführungsform ist der Abschluss des VE-Einstiegs jedes Threads von dem der anderen Threads unabhängig. In einer weiteren Ausführungsform synchronisieren sich die Threads vor dem Abschließen des VE-Einstiegs.
Um die Verwendung einer Kernzuteilung und die Einzel-Thread-Ausführung des Hypervisors zu unterstützen, kann in einer Ausführungsform ein koordinierter Ausstieg aus der virtuellen Ausführung (VE-Ausstieg) bereitgestellt werden, bei dem alle Gast-Threads in einem bestimmten Kern gleichzeitig wieder auf den ST-Host zurück aussteigen. Im Kontext des koordinierten VE-Ausstiegs können Typen eines VE-Ausstiegs in drei Kategorien eingeteilt werden. (1) Host-Unterbrechungen, die zum Host-Betrieb gehören; (2) Host-Unterbrechungen, die zum Gastbetrieb gehören; und (3) Gastabfangvorgänge. Hostexterne, E/A- und einige Unterbrechungen bei Maschinenfehlern fallen in die VE-Ausstiegskategorie (1). In diesem Fall müssen alle Gast-Threads den virtuellen Ausführungsmodus verlassen, damit der Host die Unterbrechung bearbeiten kann. Diese Unterbrechung verursacht wahrscheinlich, dass der Host einen anderen Gast zuteilt. Wenn die Unterbrechung während des virtuellen Ausführungsmodus auftritt, kann die Host-Unterbrechung entweder auf allen Threads erfasst werden, sodass sie den virtuellen Ausführungsmodus verlassen können, oder sie kann auf einem einzelnen Thread erfasst werden, der dann den anderen Threads signalisiert, ob sie aussteigen sollen.
Die VE-Ausstiegskategorie (2), Host-Unterbrechungen, die zum Gast gehören, kann einige Unterbrechungen bei Maschinenfehlern enthalten (beispielsweise einen nicht korrigierbaren Speicherfehler). In einer Nicht-Multithread-Situation werden diese Bedingungen als Host-Unterbrechungen angegeben. Bei der Kernzuteilung ist nur ein Host-Thread vorhanden, aber da diese Ausnahmen zum Gastbetrieb gehören, haben mehrere Gast-Threads die Möglichkeit, eindeutige und verschiedene Gründe für dieselbe Host-Unterbrechung zu erfassen. Um dies, sofern anwendbar, für die Kernzuteilung einzurichten, werden diese Host-Unterbrechungen stattdessen in den entsprechenden Gastzustandsbeschreibungen als ein neuer Typ von Gastabfangvorgang dargestellt und werden genauso bearbeitet wie bei der nachstehend beschriebenen Kategorie (3). In einer Ausführungsform fallen Unterbrechungen wegen Host-Adressumsetzungsfehlern aufgrund von Gastspeicherreferenzen ebenfalls unter Kategorie (2) und können als ein weiterer neuer Typ von Gastabfangvorgang dargestellt werden.
Selbst in einer Gast-Multithread-Umgebung gehören Gastabfangvorgänge für die VE-Ausstiegskategorien (2) und (3) (oben) zu einem einzelnen Gast-Thread und sind von der Gastausführung eines anderen Threads unabhängig. Es ist ferner möglich, dass mehrere Gast-Threads derartige Bedingungen gleichzeitig erkennen, was eine Bearbeitung aller durch den Host erfordert. Wenn der Host auf einen Abfangvorgang trifft, simuliert er typischerweise eine Verhaltensweise des Gasts und teilt denselben Gast dann erneut zu. Da der Host einen Einzel-Thread ausführt, müssen in diesen Fällen alle Gast-Threads den virtuellen Ausführungsmodus verlassen, bevor der Host den oder die Abfangvorgänge bearbeiten kann. Dies kann erreicht werden, indem entweder auf einen natürlichen Ausstieg aller Threads gewartet wird, oder indem den anderen Threads ein Ausstieg signalisiert wird, wenn ein Thread bestimmt hat, dass er einen Abfangvorgang zum Host zurück ausführen muss. Dies wird als „koordinierter VE-Ausstieg“ bezeichnet.
Da der jeweilige Thread bestimmt, dass er den virtuellen Ausführungsmodus verlassen muss, tritt er in den VE-Ausstieg ein und wartet in der Erstsynchronisierungsschleife des VE-Ausstiegs, bis alle anderen gültigen Threads ebenfalls für den Ausstieg bereit sind. Wenn die Umsetzung dies erfordert, signalisiert sie den anderen Threads auszusteigen, bevor der Eintritt in die Synchronisierungsschleife erfolgt. In der Synchronisierungsschleife des VE-Ausstiegs wird nur ein Minimum an Unterbrechungen bearbeitet. Um die Situation zu berücksichtigen, in der ein Gast-Thread den virtuellen Ausführungsmodus verlassen muss, wenn keine Host-Unterbrechung und kein Gastabfangvorgang vorliegen, wird ein „Keine Aktion“-Abfangvorgang definiert, um für den Host anzugeben, dass keine Abfangaktion für den Gast erforderlich ist.
Sobald sich alle Threads in der Erstsynchronisierungsschleife des VE-Ausstiegs befinden, kann die Speicherung von Gastdaten in allen gültigen Zustandsbeschreibungen abgeschlossen werden. Das heißt, der aktuelle Gastzustand in der Hardware wird in der entsprechenden Zustandsbeschreibung gespeichert, sodass dieser logische Gast-Thread zu einem späteren Zeitpunkt erneut zugeteilt werden kann. Nach Beendigung dieser Speicherung ist ein Abschlusssynchronisierungspunkt des VE-Ausstiegs erforderlich, um zu gewährleisten, dass alle Aktualisierungen der Zustandsbeschreibungen von sekundären Threads abgeschlossen sind, bevor die Kontrolle wieder an den Hypervisor zurückgegeben wird (der typischerweise auf dem primären Thread ausgeführt wird). Sobald der VE-Ausstieg abgeschlossen ist, kann der Hypervisor jeden Thread in dem Ring verarbeiten, um zu bestimmen, ob ein Abfangvorgang vorgelegen hat und diesen gegebenenfalls entsprechend zu bearbeiten. Danach kann er entweder den logischen Kern desselben Gasts erneut zuteilen oder einen anderen auf dem physischen Prozessor zuteilen.
Eine Ausführungsform enthält eine Maschinenumsetzung eines koordinierten Ausstiegs aus der virtuellen Ausführung, der die Aussetzung der Gast-Multithread-Ausführung und die Rückgabe der Kontrolle an einen Host mit Einzel-Thread enthält. In einer MT-Umgebung ist der Millicode des Ausstiegs aus der virtuellen Ausführung (VE-Ausstieg) unter den meisten Bedingungen dafür zuständig, den anderen gültigen Gast-Threads zu signalisieren, die virtuelle Ausführung sobald wie möglich zu verlassen. Es ist möglich, dass die Verzögerung, die von dem den Ausstieg anfordernden Thread gesehen wird, beträchtlich ist, vor allem, wenn ein Thread aktuell internen Code ausführt, der für den Ausstieg aus der virtuellen Ausführung nicht unterbrochen werden kann. Während ein Thread darauf wartet, dass andere Threads die virtuelle Ausführung verlassen, kann Millicode zum Bearbeiten bestimmter Unterbrechungen verwendet werden, wie beispielsweise diejenigen, die zu Blockierbedingungen führen können oder diejenigen, die sich auf die gesamte Systemleistung auswirken können. Die Bearbeitung anderer Unterbrechungen ist möglicherweise für Millicode nicht optimal, wenn dadurch nur der letztendliche Ausstieg aus der virtuellen Ausführung verzögert wird, nachdem andere Threads (deren Arbeit möglicherweise unterbrochen wurde) signalisiert worden sind. Dies alles muss unter Einhaltung der entsprechenden Unterbrechungspriorität erfolgen.
Außerdem muss ein Großteil der für den Ausstieg aus der virtuellen Ausführung erforderlichen Koordinierung durch Millicode den Zustand jedes Threads berücksichtigen. Zum Beispiel muss berücksichtigt werden, ob jeder logische Thread gültig ist, und ob der physische Thread internen Code ausführt. Ungeachtet dessen, ob der primäre Thread ungültig ist, muss er trotzdem signalisiert werden, da dies typischerweise der Thread ist, auf dem das Host-Programm wieder aufgenommen wird. Dies wird insgesamt unter Verwendung eines internen, durch Millicode angeforderten Unterbrechungssystems erreicht.
Der Millicode kann auch einige Aktionen ausführen, um physische Register freizusetzen, die durch den oder die sekundären Gast-Threads verwendet wurden, aber nicht mehr benötigt werden, da der Gastzustand gespeichert worden ist, und der Host den oder die sekundären Threads nicht verwendet. Zum Beispiel kann Millicode zugeordnete Register auf Null zurücksetzen als Mittel zum Freisetzen von Ressourcen, da Hardware in bestimmten Umsetzungen alle logischen Register mit Null-Inhalten einem einzelnen physischen Register zuordnen kann, wodurch die anderen physischen Register der Verwendung durch den primären Thread überlassen bleiben. Weitere Ressourcen können vorhanden sein, die gemeinsam von den Threads genutzt werden und für die alleinige Verwendung durch den primären Thread freigesetzt werden können. Millicode kann auch bestimmte Unterbrechungen maskieren, sodass keine Kernressourcen für einen unnötigen Millicode-Aufruf verwendet werden.
Sobald ein Thread bestimmt, dass ein Ausstieg aus der virtuellen Ausführung erforderlich ist, signalisiert er die anderen Threads, wie im Folgenden zum Beispiel unter Bezugnahme auf 15A und 15B beschrieben. Der verwendete Prozess kann auf der Grundlage dessen variieren, ob der Thread, der die virtuelle Ausführung verlässt, der primäre Thread oder ein sekundärer Thread ist.
In einer Ausführungsform kann ein primärer Thread gültigen sekundären Threads den Ausstieg aus der virtuellen Ausführung signalisieren, wenn alle der folgenden Bedingungen erfüllt sind: (1) er möchte den virtuellen Ausführungsmodus verlassen und die Kontrolle an den Hypervisor zurückgeben; (2) alle anderen gültigen Threads befinden sich nicht bereits im Ausstiegsprozess (d.h. mindestens ein Thread führt noch Gastanweisungen aus); (3) allen anderen Threads wurde nicht bereits der Ausstieg signalisiert; und (4) es gibt mindestens einen anderen gültigen Thread. Wenn diese Bedingungen nicht erfüllt sind, wird jedem sekundären Thread Zeit zur Bereinigung und zum individuellen Ausstieg aus der virtuellen Ausführung gegeben. In einer Ausführungsform signalisiert ein sekundärer Thread dem primären Thread (selbst wenn er ungültig ist) und allen anderen gültigen sekundären Threads den Ausstieg aus dem virtuellen Ausführungsmodus, wenn alle der oben genannten Bedingungen (1) bis (3) erfüllt sind. In einer Ausführungsform muss ein sekundärer Thread ein Signal an den primären Thread senden, selbst wenn er der einzige gültige Thread ist, da er dem primären Thread signalisieren muss, den koordinierten Ausstieg aus der virtuellen Ausführung abzuschließen.
Unter folgender Bezugnahme auf 15A und 15B wird allgemein eine Maschinenumsetzung für einen koordinierten Ausstieg aus der virtuellen Ausführung gemäß einer Ausführungsform gezeigt. In dem in 15A und 15B gezeigten Beispiel führt ein primärer Thread P einen Gastanweisungsdatenstrom P bei 1502 aus, ein sekundärer Thread A führt einen Gastanweisungsdatenstrom A bei 1542 aus, und ein sekundärer Thread B führt einen Gastanweisungsdatenstrom B bei 1572 aus. Am Block 1544 bestimmt der sekundäre Thread A, dass er die virtuelle Ausführung verlassen muss und bestimmt unter Verwendung der oben beschriebenen Kriterien am Block 1546, dass er den anderen Threads den Ausstieg ebenfalls signalisieren muss. Der sekundäre Thread A signalisiert die anderen Threads, indem er eine Anforderung einer internen Unterbrechung durch Ausstieg aus der virtuellen Ausführung vornimmt, die in der Hardware-Zustandssteuerung eines primären Threads P 1508 und der Hardware-Zustandssteuerung eines sekundären Threads B 1578 aussteht. In 15A wird auch die Hardware-Zustandssteuerung eines sekundären Threads A 1548 gezeigt. Bei der Antwort auf die interne Unterbrechung am Block 1510 für den primären Thread P und am Block 1580 für den sekundären Thread B prüft jeder Thread den Grund für die interne Unterbrechung und bestimmt am Block 1512 für den primären Thread P und am Block 1582 für den sekundären Thread B, ob die interne Unterbrechung eine Anforderung für einen Ausstieg aus der virtuellen Ausführung ist. Wenn bestimmt wird, dass es sich nicht um eine Anforderung des Ausstiegs aus der virtuellen Ausführung handelt, führen der primäre Thread P und der sekundäre Thread B jeweils die Blöcke 1514 und 1584 aus, um die andere Unterbrechungsanforderung zu bearbeiten.
Wenn die Unterbrechung eine Anforderung zum Ausstieg aus der virtuellen Ausführung ist, kann in einer Ausführungsform jeder Thread den folgenden Prozess unabhängig ausführen. Am Block 1516 für den primären Thread P und am Block 1586 für den sekundären Thread B wird bestimmt, ob der Thread gültig ist. Der sekundäre Thread A, der den Ausstieg aus der virtuellen Ausführung angefordert hat, kann als gültig angenommen werden. Bei einem als gültig bestimmten Thread wird der größte Teil des zugehörigen Gastzustands aus der Hardware in seiner eigenen Zustandsbeschreibung gespeichert. Wie in 4 gezeigt, umfasst dies die/das Gastmehrzweckregister (GRs) 402, Zugriffsregister (ARs) 404, Steuerregister (CRs) 406, Programmstatuswort (PSW) und Anweisungsadresse (IA) 414. Ein Gastzustand, der sich während der virtuellen Ausführung nicht geändert hat, wie beispielsweise die virtuelle CPU-Nummer (VCN) 412 und die logische Partitionsnummer (LPN) 432, müssen nicht gespeichert werden. Dies wird in 15A am Block 1518 für den primären Thread P, am Block 1558 für den sekundären Thread A und am Block 1588 für den sekundären Thread B gezeigt. Jeder Thread aktualisiert seinen internen Zustand, um anzugeben, dass er sich am Erst-VE-Synchronisierungspunkt des VE-Ausstiegs befindet. Dies wird in 15A am Block 1520 für den primären Thread P, am Block 1560 für den sekundären Thread A und am Block 1590 für den sekundären Thread B gezeigt.
Die Threads warten jeweils darauf, dass der primäre Thread (z.B. der primäre Thread P) und alle gültigen sekundären Threads (z.B. die sekundären Threads A und B) den Erstsynchronisierungspunkt erreichen, bevor sie fortfahren. Dies wird in 15A am Block 1521 für den primären Thread P, am Block 1561 für den sekundären Thread A und am Block 1591 für den sekundären Thread B gezeigt. Sobald alle Threads den Erst-VE-Synchronisierungspunkt im Millicode für den Ausstieg aus der virtuellen Ausführung erreichen, beendet jeder der Threads das Aktualisieren der entsprechenden Informationen in der Zustandsbeschreibung. Beispiele für diese Informationen können den Gast-CPU-Zeitgeber umfassen, der Teil der Gastzeitgeber in 4 ist. Dies wird in 15A am Block 1522 für den primären Thread P, am Block 1562 für den sekundären Thread A und am Block 1592 für den sekundären Thread B gezeigt. Eine Verzögerung des Speicherns dieses Zustands bis zum Synchronisierungspunkt verbessert die Konsistenz des Gastzeittakts zwischen den Threads.
Unter folgender Bezugnahme auf 15B aktualisiert jeder Thread seinen eigenen internen Zustand, um anzugeben, dass er sich im Millicode für den VE-Ausstieg am Abschlusssynchronisierungspunkt befindet. Dies wird in 15B an den Blöcken Block 1524 für den primären Thread P, an den Blöcken 1564 für den sekundären Thread A und an den Blöcken 1594 für den sekundären Thread B gezeigt. Außerdem wartet der primäre Thread A darauf, dass alle Threads einen Abschlusssynchronisierungspunkt 1599 am Block 1526 erreichen, bevor mit Block 1528 fortgefahren wird. Jeder sekundäre Thread setzt ein internes Hardware-Bit, um anzugeben, das kein gültiger Programmanweisungsdatenstrom mehr ausgeführt wird, wodurch die Maschine veranlasst wird, den Millimodus zu verlassen und die Ausführung von Code zu stoppen. Dies wird in 15B am Block 1566 für den sekundären Thread A und am Block 1596 für den sekundären Thread B gezeigt. In einer Ausführungsform führt jeder sekundäre Thread keinen Programmcode bis zum nächsten Start der virtuellen Ausführung aus, allerdings kann bei Bedarf interner Code ausgeführt werden, um interne Unterbrechungen zu bearbeiten.
Sobald alle Threads den Abschlusssynchronisierungspunkt im Millicode für den VE-Ausstieg erreicht haben, gezeigt als Punkt 1599 in 15B, wird eine Einzel-Thread-Ausführung am primären Thread P gestartet. Der primäre Thread P schließt die Kernbereinigung am Block 1528 ab, lädt den Hypervisor-Zustand mit der Host-Programm-IA am Block 1530 in die Hardware und verlässt den Millimodus am Block 1532. Als Ergebnis dessen wird der primäre Thread P im Host-Modus ausgeführt und bearbeitet alle entsprechenden Host-Unterbrechungen, und der Hypervisor bearbeitet alle Gastabfangvorgänge.
Technische Auswirkungen und Vorteile umfassen die Fähigkeit zum Ausführen eines koordinierten Ausstiegs aus einem logischen Kern mit zugeteiltem MT-Gast zurück zu einem ST-Host.
Ausführungsformen umfassen ein System, Verfahren und Computerprogrammprodukt zum Verlassen einer virtuellen Maschine (VM) mit Multithread-Gast. Gemäß einem Aspekt enthält ein Computersystem eine Konfiguration mit einer Maschine, die fähig ist, in einem Einzel-Thread-(ST)Modus und einem Multithread-(MT)Modus zu arbeiten. Außerdem enthält die Maschine physische Threads. Die Maschine ist so konfiguriert, dass sie ein Verfahren ausführt, das die Ausführung einer Gastentität auf dem Kern im MT-Modus enthält. Die Gastentität enthält die gesamte oder einen Teil einer Gast-VM und eine Mehrzahl von logischen Threads, die auf den physischen Threads ausgeführt werden. Ein Ausstiegsereignis wird an der Maschine erfasst. Auf Grundlage einer Erfassung des Ausstiegsereignisses wartet die Maschine, bis alle logischen Threads, die aktuell auf den physischen Threads ausgeführt werden, einen Synchronisierungspunkt erreicht haben. Ein Zustand, der Ausstiegsgrundinformationen enthält, wird für jeden der logischen Threads gespeichert, und die Ausführung eines Hosts wird auf einem der physischen Threads im ST-Modus initiiert.
Gemäß einem weiteren Aspekt wird ein durch den Computer umgesetztes Verfahren zum Verlassen einer Multithread-Gast-VM in einer Konfiguration vorgestellt, die eine Maschine enthält, die fähig ist, in einem ST-Modus und einem MT-Modus zu arbeiten, und die physische Threads enthält. Die Maschine enthält die Ausführung einer Gastentität auf dem Kern im MT-Modus. Die Gastentität enthält die gesamte oder einen Teil einer Gast-VM und eine Mehrzahl von logischen Threads, die auf den physischen Threads ausgeführt werden. Ein Ausstiegsereignis wird an der Maschine erfasst. Auf Grundlage einer Erfassung des Ausstiegsereignisses wartet die Maschine, bis alle logischen Threads, die aktuell auf den physischen Threads ausgeführt werden, einen Synchronisierungspunkt erreicht haben. Ein Zustand, der Ausstiegsgrundinformationen enthält, wird für jeden der logischen Threads gespeichert, und die Ausführung eines Hosts wird auf einem der physischen Threads im ST-Modus initiiert.
Ein weiterer Aspekt enthält ein Computerprogrammprodukt zum Verlassen einer Multithread-Gast-VM in einer Konfiguration, die eine Maschine enthält, die fähig ist, in einem ST-Modus und einem MT-Modus zu arbeiten, und die physische Threads enthält. Das Computerprogrammprodukt enthält ein von einem Computer lesbares Speichermedium mit darauf ausgeführten Programmanweisungen, wobei das vom Computer lesbare Speichermedium kein Signal ist. Die Programmanweisungen sind von einer Verarbeitungsschaltung lesbar, um die Verarbeitungsschaltung zu veranlassen, ein Verfahren auszuführen. Die Maschine enthält die Ausführung einer Gastentität auf dem Kern im MT-Modus. Die Gastentität enthält die gesamte oder einen Teil einer Gast-VM und eine Mehrzahl von logischen Threads, die auf den physischen Threads ausgeführt werden. Ein Ausstiegsereignis wird an der Maschine erfasst. Auf Grundlage einer Erfassung des Ausstiegsereignisses wartet die Maschine, bis alle logischen Threads, die aktuell auf den physischen Threads ausgeführt werden, einen Synchronisierungspunkt erreicht haben. Ein Zustand, der Ausstiegsgrundinformationen enthält, wird für jeden der logischen Threads gespeichert, und die Ausführung eines Hosts wird auf einem der physischen Threads im ST-Modus initiiert.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen die Stelle der Erfassung an einem oder mehreren der Threads in der Gastentität enthalten.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Funktion enthalten, bei der auf der Grundlage der Erfassung mindestens einer von dem einem oder den mehreren der Threads, der bzw. die das Ausstiegsereignis erfasst haben, anderen Threads in der Gastentität den Ausstieg aus dem Kern signalisiert.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Funktion enthalten, bei der mindestens einer von dem einem oder den mehreren der Threads, der bzw. die das Ausstiegsereignis erfasst haben, anderen logischen Threads ein Signal gesendet wird, indem eine Unterbrechung verursacht wird, die an jedem der anderen Threads aussteht.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Stelle enthalten, an der von jedem der mehreren Threads ein Bit gesetzt wird, um anzugeben, dass der Synchronisierungspunkt erreicht worden ist.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Stelle enthalten, an der ein Abschnitt des Zustands von jedem der Threads in einem Zustandsbeschreibungs-Speicherort gespeichert wird, bevor jeder der Threads den Synchronisierungspunkt erreicht.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Stelle enthalten, an der die Maschine vor dem Initiieren einer Ausführung eines Hosts im ST-Modus auf einem der physischen Threads wartet, bis der vollständige Zustand jedes der Threads in den Zustandsbeschreibung-Speicherort gespeichert worden ist.
Zusätzlich zu einer oder mehreren der oben beschriebenen Funktionen oder als Alternative können weitere Ausführungsformen eine Stelle enthalten, an der auf der Grundlage des Initiierens der Ausführung des Hosts im ST-Modus der Host im ST-Modus auf einem der physischen Threads ausgeführt wird.
Die hierin verwendete Terminologie dient nur zum Zweck der Beschreibung von besonderen Ausführungsformen und soll die Erfindung keinesfalls einschränken. Wie hierin verwendet, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch die Pluralformen mit einschließen, es sei denn, der Kontext gibt eindeutig anderes vor. Es versteht sich des Weiteren, dass die Begriffe „weist auf“ und/oder „aufweisend“ bei Verwendung in dieser Patentschrift das Vorhandensein ausgewiesener Funktionen, Ganzzahlen, Schritte, Operationen, Elemente und/oder Komponenten angeben, das Vorhandensein oder die Hinzufügung von einem oder mehreren anderen Funktionen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon aber nicht ausschließen.
Die entsprechenden Strukturen, Materialien, Handlungen und Entsprechungen aller Mittel oder Schritt-plus-Funktion-Elemente in den nachstehenden Ansprüchen sollen alle Strukturen, Materialien oder Handlungen zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen enthalten, wie speziell beansprucht. Die Beschreibung der vorliegenden Erfindung wurde zum Zweck der Veranschaulichung und Beschreibung erstellt, sie soll aber keineswegs erschöpfend oder auf die Erfindung in der offenbarten Form eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, ohne vom Schutzbereich und dem Erfindungsgedanken der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung am besten zu erklären und es anderen Fachleuten zu ermöglichen, die Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifizierungen zu verstehen, die für die vorgesehene bestimmte Verwendung geeignet sind.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zweck der Veranschaulichung erstellt, sie sollen aber keineswegs erschöpfend oder auf die offenbarten Ausführungsformen eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, die nicht von dem Schutzbereich und dem Erfindungsgedanken der beschrieben Ausführungsformen abweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, der praktischen Anwendung oder technischen Verbesserung gegenüber auf dem Markt gefundenen Technologien bestmöglich zu erklären oder anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.
Unter folgender Bezugnahme auf 16 enthält in einem Beispiel ein Computerprogrammprodukt 1600 beispielsweise ein oder mehrere Speichermedien 1602, wobei die Medien konkret und/oder nicht-flüchtig sein können, um darauf vom Computer lesbare Programmcodemittel oder Logik 1604 zu speichern, um einen oder mehrere Aspekte von hierin beschriebenen Ausführungsformen bereitzustellen und zu ermöglichen.
Die vorliegende Erfindung kann ein System, ein Verfahren und/oder ein Computerprogrammprodukt sein. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder Speichermedien) mit einem computerlesbaren Programmcode darauf enthalten, um einen Prozessor zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Das computerlesbare Speichermedium kann eine konkrete Einheit sein, die Anweisungen zur Verwendung durch eine Anweisungsausführungseinheit beibehalten und speichern kann. Ein computerlesbares Speichermedium kann zum Beispiel eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiter-Speichereinheit oder jede geeignete Kombination aus dem Vorgenannten sein, es ist aber nicht darauf beschränkt. Eine nicht erschöpfende Liste von spezielleren Beispielen für das computerlesbare Speichermedium enthält Folgendes: eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), einen statischer Arbeitsspeicher (SRAM), einen tragbaren CD-ROM, ein DVD-Laufwerk (DVD), einen Speicherstick, eine Diskette, eine mechanisch verschlüsselte Einheit wie beispielsweise Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Anweisungen und jede geeignete Kombination des Vorgenannten. Ein computerlesbares Speichermedium, wie hierin verwendet, muss nicht als transitorische Signale per se ausgelegt sein, wie beispielsweise Funkwellen oder andere sich verbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder andere Übertragungsmedien verbreiten (z.B. Lichtimpulse, die ein Lichtwellenleiterkabel durchlaufen) oder elektrische Signale, die durch einen Draht übertragen werden.
Hierin beschriebene computerlesbare Programmanweisungen können auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten von einem computerlesbaren Speichermedium oder auf einen externen Computer oder eine externe Speichereinheit über ein Netzwerk, zum Beispiel das Internet, ein lokales Netz, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk heruntergeladen werden. Das Netzwerk kann Kupferübertragungsleitungen, Lichtwellenleiter, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerk-Adapterkarte oder Netzwerk-Schnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen von dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium in der jeweiligen Datenverarbeitungs-/Verarbeitungseinheit weiter.
Computerlesbare Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung können Assembler-Anweisungen, Anweisungssatzarchitektur-(Instruction Set Architecture) (ISA) Anweisungen, Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, Zustandseinstellungsdaten oder anderer Quellcode oder Objektcode sein, die in jeder Kombination von einer oder mehreren Programmiersprachen, einschließlich Smalltalk, C++ oder dergleichen, und herkömmlichen prozeduralen Programmiersprachen wie der Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben sind. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers über jeden Typ von Netzwerk verbunden werden, einschließlich ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann zu einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Nutzung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Arrays (FPGA) oder programmierbare Logik-Arrays (PLA) die computerlesbaren Programmanweisungen unter Verwendung von Zustandsinformationen der computerlesbaren Programmanweisungen zum Personalisieren der elektronischen Schaltung ausführen, um Aspekte der vorliegenden Erfindung auszuführen.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block in den Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern und Kombinationen von Blöcken in den Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern durch computerlesbare Programmanweisungen umgesetzt werden können.
Diese computerlesbaren Programmanweisungen können für einen Prozessor eines Mehrzweckcomputers, eines Spezialcomputers oder andere Vorrichtungen, die programmierbare Daten verarbeiten, bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über den Prozessor des Computers oder andere Vorrichtungen, die programmierbare Daten verarbeiten, ausgeführt werden, Mittel zum Umsetzen der Funktionen/Handlungen erstellen, die in dem Ablaufplan und/oder dem Block oder den Blöcken des Blockschaubilds angegeben sind. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Weise funktionieren, sodass das computerlesbare Speichermedium mit den darin gespeicherten Anweisungen einen Fertigungsartikel aufweist, einschließlich Anweisungen, welche die in dem Ablaufplan und/oder dem Block oder den Blöcken des Blockschaubilds angegebene Funktion/Handlung umsetzen.
Die computerlesbaren Programmanweisungen können auch auf einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder eine andere Einheit geladen werden, um die Ausführung einer Serie von Arbeitsschritten auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit zu veranlassen, um einen über den Computer umgesetzten Prozess zu erzeugen, sodass die Anweisungen, die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführt werden, die Funktionen /Handlungen umsetzen, die in dem Ablaufplan und/oder dem Block oder den Blöcken des Blockschaubilds angegeben sind.
Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb von möglichen Umsetzungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Diesbezüglich kann jeder Block in dem Ablaufplan oder in den Blockschaubildern ein Modul, ein Segment oder einen Abschnitt von Anweisungen darstellen, der eine oder mehrere ausführbare Anweisungen zum Umsetzen der angegebenen logischen Funktion(en) aufweist. In einigen alternativen Umsetzungen können die in dem Block angegebenen Funktionen außerhalb der Reihenfolge auftreten, die in den Figuren angegeben ist. Zum Beispiel können zwei nacheinander gezeigte Blöcke tatsächlich im Wesentlichen parallel ausgeführt werden, oder die Blöcke können manchmal in der umgekehrten Reihenfolge ausgeführt werden, was von der beteiligten Funktionalität abhängt. Es wird ebenfalls angemerkt, dass jeder Block der Blockschaubilder und/oder Veranschaulichung des Ablaufplans und Kombinationen von Blöcken in den Blockschaubildern und/oder der Veranschaulichung des Ablaufplans durch spezielle Systeme auf Grundlage von Hardware umgesetzt werden können, die die angegebenen Funktionen oder Handlungen ausführen oder Kombinationen von spezieller Hardware und Computeranweisungen ausführen.

Claims

Durch einen Computer umgesetztes Verfahren für einen Ausstieg aus einer virtuellen Maschinen (VM) für einen Multithread-Gast in einer Konfiguration, eine Maschine aufweist, die fähig ist, in einem Einzel-Thread-(ST)-Modus und einem Multithread(MT)-Modus zu arbeiten, wobei die Maschine physische Threads enthält, wobei das Verfahren aufweist: Ausführen einer Gastentität auf einen Kern im MT-Modus, wobei die Gastentität die gesamte oder einen Teil einer Gast-VM enthält, und die Gastentität eine Mehrzahl von logischen Threads aufweist, die auf den physischen Threads ausgeführt werden, wobei jeder logische Thread einen unabhängigen Prozessor darstellt, der einen einzelnen Anweisungsdatenstrom und einen zugehörigen Zustand enthält; Erfassen eines Ausstiegsereignisse an der Maschine; und auf Grundlage des Erfassens: Warten, bis alle logischen Threads, die aktuell auf den physischen Threads ausgeführt werden, einen Synchronisierungspunkt erreicht haben, wobei der Synchronisierungspunkt erreicht ist, wenn alle logischen Threads bereit sind, den Kern zu verlassen; Speichern eines Zustands, der Ausstiegsgrundinformationen von jedem der logischen Threads aufweist; und Initiieren einer Ausführung eines Hosts im ST-Modus auf einem der physischen Threads.
Verfahren nach Anspruch 1, wobei die Erfassung durch einen oder mehrere Threads in der Gastentität erfolgt.
Verfahren nach Anspruch 2, wobei auf Grundlage der Erfassung mindestens einer von dem einen oder den mehreren Threads, der bzw. die das Ausstiegsereignis erfasst haben, mindestens eines ausführt von: anderen Threads in der Gastentität den Ausstieg aus dem Kern zu signalisieren; und Veranlassen, dass eine interne Unterbrechung an jedem der anderen Threads aussteht.
Verfahren nach Anspruch 1, wobei ein Bit durch jeden der mehreren Threads gesetzt wird, um anzugeben, dass der Synchronisierungspunkt erreicht worden ist.
Verfahren nach Anspruch 1, wobei ein Abschnitt des Zustands von jedem der Threads in einem Zustandsbeschreibungs-Speicherort gespeichert wird, bevor jeder der Threads den Synchronisierungspunkt erreicht.