DE102022102241A1

DE102022102241A1 - Flexible rückkehr und ereignislieferung

Info

Publication number: DE102022102241A1
Application number: DE102022102241.2A
Authority: DE
Inventors: Gilbert Neiger; H. Peter Anvin; Vedvyas Shanbhogue; Deepak Gupta
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-03-02
Filing date: 2022-02-01
Publication date: 2022-09-08
Also published as: NL2030804B1; US20220283813A1; WO2022187254A1; NL2030804A; EP4302183A1

Abstract

Techniken zur flexiblen Rückkehr und Ereignislieferung sind beschrieben. Als ein Beispiel beinhaltet eine beispielhafte Einrichtung eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und eine Ausführungsschaltungsanordnung zum Ausführen des decodierten einzelnen Befehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.

Description

STAND DER TECHNIK
Eine Ankunft von Ereignissen, wie etwa Interrupts, Ausnahmen und Systemaufrufe von einem Betriebssystem (BS), führt typischerweise zu einer Übertragung der Steuerung von einem unterbrochenen Kontext (möglicherweise einer Benutzeranwendung) an einen Ereignishandler im BS; eine solche Übertragung wird Ereignislieferung genannt. Im Anschluss an seine Behandlung eines gelieferten Ereignisses überträgt das BS im Allgemeinen die Steuerung zurück an den unterbrochenen Kontext, typischerweise unter Verwendung eines Ereignisrückkehrbefehls. Einzelheiten des Betriebs von Ereignislieferungs- und Ereignisrückkehrbefehlen werden durch die Befehlssatzarchitektur (ISA) eines Prozessors definiert.
Figurenliste
Die vorliegende Offenbarung wird unter Bezugnahme auf die Zeichnungen beschrieben.

1 ist ein Blockdiagramm eines beispielhaften Computersystems.
2 veranschaulicht ein beispielhaftes flexibles konfigurationsmodellspezifisches Rückkehr- und Ereignislieferungs- bzw. FRED-Register (MSR).
3 veranschaulicht ein beispielhaftes FRED-SSP-MSR (Shadow Stack Pointer, Schattenstapelzeiger).
4 veranschaulicht eine beispielhafte Konfiguration vor der Ereignislieferung.
5 veranschaulicht die beispielhafte Konfiguration nach der Ereignislieferung.
6 veranschaulicht beispielhafte Elemente einer BS-Konfiguration.
7 veranschaulicht ein beispielhaftes Verfahren für FRED-Ereignislieferung.
8(A)-(E) veranschaulichen beispielhaften Pseudocode für FRED-Ereignislieferung.
9 veranschaulicht eine beispielhafte Behandlung eines Ereignisrückkehr-zu-Supervisor- bzw. ERETS-Befehls.
10 veranschaulicht eine beispielhafte Ausführung eines ERETS-Befehls.
11(A)-(B) veranschaulichen beispielhaften Pseudocode für eine Ausführung von ERETS.
12 veranschaulicht eine beispielhafte Behandlung eines Ereignisrückkehr-zu-Benutzer- bzw. ERETU-Befehls.
13 veranschaulicht eine beispielhafte Ausführung eines ERETU-Befehls.
14(A)-(C) veranschaulichen beispielhaften Pseudocode für eine Ausführung von ERETU.
15 veranschaulicht eine beispielhafte Behandlung eines CALL-Befehls.
16 veranschaulicht eine beispielhafte Behandlung eines Fernsprungbefehls.
17 veranschaulicht eine beispielhafte Behandlung eines Interrupt-Rückkehr- bzw. IRET-Befehls.
18 veranschaulicht eine beispielhafte Behandlung eines Fernrückkehr- bzw. RET-Befehls.
19 veranschaulicht eine beispielhafte Behandlung eines Systemaufruf- bzw. SYSCALL-Befehls.
20 veranschaulicht beispielhaften Pseudocode zur Ausführung von SYSCALL.
21 veranschaulicht eine beispielhafte Behandlung eines Systemeingabe- bzw. SYSENTER-Befehls.
22 veranschaulicht beispielhaften Pseudocode zur Ausführung von SYSENTER.
23 veranschaulicht eine beispielhafte Behandlung eines MSR-Schreib- bzw. WRMSR-Befehls.
24 veranschaulicht eine beispielhafte Behandlung eines XRSTORS-Befehls (Restore Processor Extended State Supervisor).
25 veranschaulicht eine beispielhafte Behandlung eines Laden-in-KERNEL_GS_BASE-MSR- bzw. LKGS-Befehls.
26 veranschaulicht eine beispielhafte Behandlung einer Wiederaufnahmeoperation eines unterbrochenen Programmbefehls.
27 veranschaulicht ein Beispiel für eine virtuelle Maschinenumgebung.
28 ist ein Flussdiagramm von Beispielen für einen Prozess zum Behandeln von Fehlern in einer virtuellen Maschinenumgebung.
29 veranschaulicht beispielhafte Beispiele für eine VMCS.
30 veranschaulicht Beispiele für ein beispielhaftes System.
31 veranschaulicht ein Blockdiagramm von Beispielen für einen Prozessor, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und integrierte Grafiken aufweisen kann.
32(A) ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgetreue Pipeline als auch eine beispielhafte reihenfolgeveränderte Ausgabe-/Ausführungspipeline mit Registerumbenennung gemäß Beispielen der Erfindung veranschaulicht.
32(B) ist ein Blockdiagramm, das sowohl ein beispielhaftes Beispiel für einen reihenfolgetreuen Architekturkern als auch einen beispielhaften reihenfolgeveränderten Ausgabe-/Ausführungsarchitekturkern mit Registerumbenennung, der in einen Prozessor aufzunehmen ist, gemäß Beispielen der Erfindung veranschaulicht.
33 veranschaulicht Beispiele für Ausführungseinheits-Schaltungsanordnung(en), wie etwa Ausführungseinheits-Schaltungsanordnung(en) aus 32(B).
34 ist ein Blockdiagramm einer Registerarchitektur gemäß einigen Beispielen.
35 veranschaulicht Beispiele für ein Befehlsformat.
36 veranschaulicht Beispiele für ein Adressierungsfeld.
37 veranschaulicht Beispiele für ein erstes Präfix.
38(A)-(D) veranschaulichen Beispiele dafür, wie die R-, X- und B-Felder des ersten Präfixes 3501(A) verwendet werden.
39(A)-(B) veranschaulichen Beispiele für ein zweites Präfix.
40 veranschaulicht Beispiele für ein drittes Präfix.
41 veranschaulicht ein Blockdiagramm, das die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Beispielen der Erfindung gegenüberstellt.

AUSFÜHRLICHE BESCHREIBUNG
Die vorliegende Offenbarung betrifft Verfahren, Einrichtungen, Systeme und nichtflüchtige computerlesbare Speicherungsmedien zur flexiblen Rückkehr und Ereignislieferung. Zumindest lädt die Ereignislieferung einen Befehlszeiger mit einer Adresse eines Ereignishandlers. Um den Ausführungskontext des Ereignishandlers einzurichten, kann die Ereignislieferung auch andere Prozessorzustandselemente (z. B. den Stapelzeiger) laden. Ereignislieferung kann auch Elemente des unterbrochenen Kontexts speichern, insbesondere die Werte der Register, die sie lädt, um den Ausführungskontext des Ereignishandlers einzurichten. Ereignislieferung kann diese Elemente in dedizierten Prozessorregistern oder an festen Orten im Speicher oder auf einem Stapel im Speicher speichern. Zusätzlich zu Elementen des unterbrochenen Kontexts kann die Ereignislieferung Informationen über das Ereignis, das zur Verwendung durch den Ereignishandler geliefert wird, speichern.
Ein Ereignisrückkehrbefehl stellt den unterbrochenen Kontext durch Laden jener Elemente, die als Teil der Ereignislieferung gespeichert wurden (aus dedizierten Prozessorregistern, festen Orten im Speicher oder einem Stapel im Speicher), wieder her. Aus diesem Grund werden diese Befehle typischerweise in Verbindung mit der Ereignislieferung konzipiert.
Für viele ISAs besitzen Ereignislieferungs- und -rückkehrbefehle Mängel, die die Fähigkeit von Betriebssystemen herausfordern, Ereignisse effizient und robust zu behandeln. Es folgen einige allgemeine Mangelkategorien.
Für einige ISAs identifiziert die Ereignislieferung Elemente des Ausführungskontexts des Ereignishandlers (z. B. den Befehlszeiger), indem sie sie aus einer oder mehreren speicherinternen Datenstrukturen liest, die durch das BS konfiguriert werden. Das Lesen aus diesen Datenstrukturen kann die BS-Behandlung des gelieferten Ereignisses verzögern. Außerdem kann bösartige Software in der Lage sein, die BS-Integrität durch Verfälschen dieser speicherinternen Datenstrukturen zu kompromittieren.
Ereignisse, wie etwa Interrupts, können geliefert werden, wenn sich ein Prozessor in einer beliebigen einer möglicherweise großen Anzahl von Konfigurationen oder Ausführungsmodi befindet, und diese können sich von jener des Ereignishandlers unterscheiden. (Zum Beispiel kann der Ereignishandler im 64-Bit-Modus laufen, während sich der unterbrochene Kontext im 32-Bit-Modus befand.) Ereignisrückkehrbefehle müssen in der Lage sein, beliebige dieser Konfigurationen oder Modi wiederherzustellen. Infolgedessen sind Ereignisrückkehrbefehle häufig sehr komplex und funktionieren nicht gut.
Der Ausführungskontext, der von den Ereignishandlern moderner Betriebssysteme benötigt wird, beinhaltet Prozessorregister, die nicht durch Ereignislieferung geladen werden, wie von einer ISA definiert. Infolgedessen wird ein Ereignishandler nur mit einem Teil seines erforderlichen Kontexts aufgerufen. Bis der Ereignishandler die Befehle ausführt, die notwendig sind, um seinen vollständigen Kontext einzurichten, kann das BS gefährdet sein, eine fehlerhafte Ausführung zu erfahren, insbesondere wenn ein anderes Ereignis während dieser Periode geliefert wird.
Mehrere Ereignisse können gleichzeitig auftreten, und sie werden typischerweise nacheinander geliefert. Es gibt Situationen, in denen nach der Lieferung eines Ereignisses (z. B. eines Interrupts) ein Ereignis geliefert werden kann, das synchron durch den unterbrochenen Kontext (z. B. einen Debug-Breakpoint) ausgelöst wurde. In diesem Fall kann es für den Handler des zweiten Ereignisses erscheinen, dass dieses Ereignis nicht durch den ursprünglichen Interrupt-Kontext ausgelöst wurde, sondern durch den Handler des ersten Ereignisses. Dies kann zu einer fehlerhaften Ausführung führen, es sei denn, das BS verwendet Workarounds, die komplex und fragil sein können.
Für korrektes Verhalten kann ein BS erwarten, dass eine ISA derart ist, dass ein Mikroprozessor seine Behandlung gewisser Ereignisse als Teil der Ereignislieferung und -rückkehr modifiziert. Betriebssysteme erwarten zum Beispiel die Lieferung eines nicht-maskierbaren Interrupts (NMI), um zusätzliche NMIs zu blockieren, bis der ursprüngliche NMI-Handler zurückkehrt. In einem anderen Beispiel erwartet ein BS, falls eine Benutzeranwendung durch einen Debugger einzelschrittweise ausgeführt wird (der eine Debug-Ausnahme nach jedem Befehl erzeugt), dass diese Einzelschritte beim Eintreten in das BS ausgesetzt (als Teil der Lieferung eines beliebigen Ereignisses, z. B. eines Systemaufrufs) und dann bei Rückkehr zum Interrupt-Kontext wiederhergestellt werden. Für einige ISAs sind Ereignislieferung und -rückkehr derart, dass ein BS wahrscheinlich vorzeitig NMIs entsperrt oder dass eine Debug-Ausnahme bei Rückkehr zu einer Nutzeranwendung verfehlt werden kann.
Bei einigen ISAs speichert die Ereignislieferung einige Informationen über das Ereignis, das geliefert wird, in dedizierten Prozessorregistern oder an festen Orten im Speicher. Dieser Ansatz kann problematisch sein, wenn ein zweites Ereignis auftritt und diese Informationen überschreibt, bevor der Ereignishandler sie an einem anderen Ort speichern kann. Betriebssysteme können versuchen, dieses Problem zu umgehen, indem versucht wird, das Auftreten eines zweiten Ereignisses zu verhindern, aber solche Arbeitsvorgänge können komplex und fragil sein.
Manche ISAs verwenden einen einzigen Raum von Ereignisnummern (oder Vektoren) für alle Ereignisse unabhängig vom Typ. (Eine ISA kann jede Ausnahme mit einer festen Zahl assoziieren, und ein BS kann angewiesen werden, keinem Interrupt eine Zahl zuzuweisen, die bereits mit einer Ausnahme assoziiert ist.) Manche ISAs beinhalten komplexe Merkmale zum Blockieren bösartiger Systemaufrufe (oder Software-Interrupts), die ein BS verwirren könnten, indem Ereignisnummern verwendet werden, die Ausnahmen oder E/A-Interrupts zugewiesen sind. Diese Merkmale können die Verwendung der speicherinternen Datenstrukturen erfordern.
Manche Architekturen versuchen, die obigen Probleme mit der Einführung von schnellen Systemaufrufbefehlen zu behandeln. Diese Befehle bewirken eine spezielle Form von Ereignislieferung, die einige Elemente des Prozessorzustands (z. B. den Befehlszeiger) aus Konfigurationsregistern oder mit festen Werten einrichtet, anstatt den Zustand aus speicherinternen Datenstrukturen zu laden. Die Verwendung dieser speziellen Form der Ereignislieferung ist auf die Befehle SYSCALL und SYSENTER beschränkt. Es gibt entsprechende Ereignisrückkehrbefehle (SYSRET und SYSEXIT), die den unterbrochenen Kontext entsprechend wiederherstellen und die sehr einfach und schnell sind.
Die schnellen Systemaufrufbefehle verbessern die Ereignislieferung, aber nur für Systemaufrufe. Sie bieten keinen Nutzen für die Lieferung von Interrupts und Ausnahmen. Jedes der Befehlspaare weist andere Mängel auf. SYSENTER speichert den aktuellen Befehlszeiger nicht; infolgedessen können Benutzeranwendungen den Befehl nicht frei verwenden, sondern können dies nur ab einer vorbestimmten Adresse tun. SYSCALL lädt den Stapelzeiger nicht (und SYSRET stellt ihn nicht wieder her); infolgedessen gilt ein oben stehendes Problem für den Stapel, der von dem SYSCALL-Handler verwendet wird, und Betriebssystemanbieter haben dies als ein ernsthaftes Problem identifiziert.
Manche Ansätze verwenden mehrere Berechtigungsebenen (z. B. nummeriert von 0 bis 3 und manchmal als Ringe bezeichnet), wobei eine größere Zahl eine niedrigere Berechtigung bedeutet. Der Grund für die Verwendung von Berechtigungsebenen besteht darin, die Zuverlässigkeit von Betriebssystemen zu verbessern. Die höchste Berechtigungsebene 0 wird für Softwaremodule verwendet, die die kritischsten Codemodule im System enthalten, üblicherweise den Kernel eines Betriebssystems. Die äußeren Ringe (mit progressiv niedrigeren Berechtigungen) werden für Segmente verwendet, die Codemodule für weniger kritische Software bis zur Berechtigungsebene 3 enthalten (z. B. Anwendungen).
Hier ausführlich beschriebene Beispiele definieren eine Form einer flexiblen Ereignislieferung und Ereignisrückkehr (hier FRED). FRED-Ereignislieferung lädt den gesamten Kontext, der von den Ereignishandlern moderner Betriebssysteme benötigt wird. Sie lädt diesen Kontext aus Konfigurationsregistern und nicht aus dem Speicher; sie speichert auch Komponenten des unterbrochenen Kontexts und Informationen über das gelieferte Ereignis auf einem Stapel im Speicher. Die FRED-Rückkehrbefehle stellen den Interrupt-Kontext vollständig wieder her und sind einfach und effizient. Kollektiv sind die neuen Ereignislieferungs- und -rückkehrbefehle dazu ausgelegt, BS-Anforderungen für Situationen zu erfüllen, wenn mehrere Ereignisse gleichzeitig auftreten.
Manche Beispiele eliminieren viele verdeckte Eckfälle, die in der Vergangenheit zu Sicherheitsanfälligkeiten und erforderlichen komplexen Softwarearbeitsabläufen geführt haben. Die systematische Behandlung gleichzeitiger und verschachtelter Ereignisse kann für Merkmale wichtig sein, die neue Ausnahmen (oder andere Ereignisse) definieren.
Es können Konfigurationsregister bereitgestellt werden, aus denen die Ereignislieferung den Kontext eines BS-Ereignishandlers laden würde, einschließlich Konfigurationsregistern, die jenen Elementen des Prozessorzustands entsprechen, die für ein modernes BS als notwendig erachtet werden. Folgende Prozessorzustandselemente könnten unterstützt werden: Befehlszeiger und Codesegmentregister; Stapelzeiger und Stapelsegmentregister; Schattenstapelzeiger; und Zeiger auf lokalen Thread-Speicher (z. B. GS-Segment).
Im Allgemeinen wird die Ereignislieferung Elemente des unterbrochenen Kontexts auf dem speicherinternen Stapel des BS-Ereignishandlers speichern (d. h. an der Adresse, die die Ereignislieferung in den Stapelzeiger lädt). Prozessorzustandselemente, wie etwa der Zeiger auf Thread-Iokale Speicherung, müssen nur bei Lieferung eines Ereignisses direkt von der Benutzersoftware geladen werden. Solche Zustandselemente können in dedizierten Registern anstatt auf dem Stapel gespeichert werden.
Zusätzlich dazu speichert die Ereignislieferung auf dem Stapel (anstelle oder zusätzlich zu dedizierten Prozessorregistern) Hauptinformationen über das gelieferte Ereignis. Diese Informationen könnten Folgendes beinhalten: Ereignistyp (z. B. Interrupt versus Ausnahme); Ereignisnummer oder -vektor (z. B. um Interrupts zu unterscheiden); einen Ausnahmefehlercode (der die Art einer Ausnahme weiter ausführlich beschreibt) und bestimmte ausnahmespezifische Informationen (z. B. die virtuelle Adresse, deren Zugriff zu einem Seitenfehler geführt hat). Das Identifizieren des Ereignistyps sowie der Ereignisnummer beseitigt das Risiko, dass ein BS das Ereignis falsch identifiziert, wodurch die Notwendigkeit entfällt, Systemaufrufe zum Blockieren von Merkmalen basierend auf der Ereignisnummer hinzuzufügen.
Ereignislieferung kann implementiert werden, um jegliche zusätzlichen ausstehenden Ereignisse, die synchron durch Benutzersoftware ausgelöst worden sein können (z. B. ein Debug-Breakpoint), zu löschen. Dies stellt sicher, dass der BS-Ereignishandler nicht durch die nicht rechtzeitige Lieferung eines solchen Ereignisses verwirrt werden kann. Falls die Lieferung des ausstehenden Ereignisses für korrekten Betrieb des unterbrochenen Kontexts erforderlich ist, speichert die Ereignislieferung Informationen über ein ausstehendes Ereignis auf dem Stapel (bevor es gelöscht wird), sodass die Ausführung eines nachfolgenden Ereignisrückkehrbefehls es bei Rückkehr zum unterbrochenen Kontext wiederherstellen kann.
Ein oder mehrere neue Ereignisrückkehrbefehle können bereitgestellt sein, die dazu ausgelegt sind, die Ereignislieferung zu ergänzen. Entsprechend der Ereignislieferung würden diese Befehle den gesamten unterbrochenen Kontext wiederherstellen, der durch die Ereignislieferung gespeichert wurde. Diese vollständige Wiederherstellung des unterbrochenen Kontexts beseitigt die Anforderung, dass der Ereignishandler teilweise im unterbrochenen Kontext arbeitet, bevor er einen Rückkehrbefehl ausführt.
Für die Funktionalität, die ein Rückkehrbefehl nur bei Rückkehr von gewissen Ereignissen bereitstellen sollte (z. B. ein NMI oder ein Systemaufruf), können die Rückkehrbefehle den Stapelrahmen heranziehen, um das ursprüngliche Ereignis zu identifizieren und diese Funktionalität auf eine angemessene ereignisspezifische Weise bereitzustellen.
Die FRED-Rückkehrbefehle sind näher an BS-Anforderungen ausgerichtet, und es ist wahrscheinlich, dass sie effizient implementiert werden können. Diese Effizienz kann weiter gefördert werden, indem mehrere Rückkehrbefehle bereitgestellt werden, die jeweils dazu bestimmt sind, zu einer spezifischen Berechtigungsebene oder einem spezifischen Ausführungsmodus zurückzukehren. Zum Beispiel könnte es einen Befehl zur Rückkehr zu einer Benutzerausführung und einen anderen für Rückkehren geben, die auf Supervisor-Ebene verbleiben. Alternativ dazu kann es unterschiedliche Befehle zum Zurückkehren zu einer 32-Bit- und 64-Bit-Operation geben.
Für ein Beispiel, das mehrere Rückkehrbefehle definiert, wählt ein BS-Ereignishandler den korrekten Rückkehrbefehl zum Zurückkehren zum Interrupt-Kontext aus. Falls die Latenz des Identifizierens des Rückkehrbefehls Echtzeitantwort oder -leistungsfähigkeit beeinträchtigen kann, könnte ein Beispiel dem BS ermöglichen, mehrere Einstiegspunkte für den Ereignishandler zu konfigurieren, einen Einstiegspunkt für jeden Rückkehrbefehl, der zur Lieferung von Ereignissen verwendet wird, die bei der Berechtigungsebene oder dem Modus, auf die bzw. den der Rückkehrbefehl abzielt, auftreten. Das Vorhandensein mehrerer Einstiegspunkte ermöglicht dem Ereignishandler, den korrekten Rückkehrbefehl ohne übermäßige Latenz zu identifizieren.
1 ist ein Blockdiagramm eines Beispiels für ein Computersystem 100, in dem verschiedene Beispiele implementiert werden können. Das Computersystem 100 kann ein Desktop-Computersystem, ein Laptop-Computersystem, einen Notebook-Computer, einen Tablet-Computer, ein Netbook, einen tragbaren Personal-Computer, ein Smartphone, ein Mobiltelefon, einen Server, ein Netzwerkelement (z. B. einen Router oder Switch), einen Smart-Fernseher, einen Nettop, eine Set-Top-Box, eine Videospielsteuerung, einen Medienabspieler oder eine andere Art von Computersystem oder elektronischer Vorrichtung darstellen.
Das Computersystem 100 umfasst einen Prozessor 101 und einen Speicher 114. Wenn sie zusammen in einem System eingesetzt werden, können der Prozessor 101 und der Speicher 114 durch einen Zwischenverbindungsmechanismus 198 miteinander gekoppelt sein. Der Zwischenverbindungsmechanismus 198 kann einen oder mehrere Busse oder andere Zwischenverbindungen, einen oder mehrere Hubs oder andere Chipsatzkomponenten und Kombinationen davon beinhalten. Verschiedene Arten der Kopplung von Prozessoren 100 mit Speichern 114, die in der Technik bekannt sind, sind geeignet. Obwohl der Speicher 114 in 1 gezeigt ist, betreffen andere Beispiele den Prozessor 101 allein, der nicht mit dem Speicher 114 gekoppelt ist (z. B. nicht in einem Computersystem 100 eingesetzt wird). Beispiele für unterschiedliche Arten von Speicher beinhalten unter anderem dynamischen Direktzugriffsspeicher (DRAM), Flash-Speicher und andere Arten von Speicher, die üblicherweise für Hauptspeicher verwendet werden.
Der Prozessor 101 kann mindestens zwei Arten von Speicherverwaltung bereitstellen: Segmentierung und Paging. Segmentierung stellt einen Mechanismus zum Isolieren einzelner Code- , Daten- und Stapelmodule bereit, so dass mehrere Programme (oder Aufgaben) auf demselben Prozessor laufen können, ohne sich gegenseitig zu stören. Paging stellt einen Mechanismus zum Implementieren eines herkömmlichen bedarfsgesteuerten virtuellen Speichersystems bereit, bei dem Abschnitte einer Ausführungsumgebung eines Programms nach Bedarf in physischen Speicher abgebildet werden. Paging kann auch verwendet werden, um Isolation zwischen mehreren Aufgaben bereitzustellen. Wenn im geschützten Modus gearbeitet wird (wobei ein geschützter Modus ein Prozessorbetriebsmodus ist, in dem Segmentierung aktiviert ist, und der eine Voraussetzung zum Aktivieren von Paging ist), muss irgendeine Form von Segmentierung verwendet werden. Es gibt kein Modusbit zum Deaktivieren der Segmentierung. Die Verwendung von Paging ist jedoch optional. Diese zwei Mechanismen (Segmentierung und Paging) können dazu konfiguriert sein, einfache Einzelprogrammsysteme (oder Einzelaufgabensysteme), Multitaskingsysteme oder Mehrprozessorsysteme, die gemeinsam genutzten Speicher verwenden, zu unterstützen. Segmentierung stellt einen Mechanismus zum Teilen des adressierbaren Speicherraums des Prozessors (linearer Adressraum genannt) in kleinere geschützte Adressräume bereit, die Segmente genannt werden. Segmente können verwendet werden, um den Code, die Daten und den Stapel für ein Programm zu halten oder Systemdatenstrukturen (wie etwa ein Aufgabenzustandssegment (TSS) oder eine lokale Deskriptor-Tabelle (LDT) zu halten. Falls mehr als ein Programm (oder eine Aufgabe) auf dem Prozessor 101 ausgeführt wird, kann jedem Programm sein eigener Satz von Segmenten zugewiesen werden. Der Segmentierungsmechanismus ermöglicht auch das Typisieren von Segmenten, sodass die Operationen, die an einem bestimmten Segmenttyp durchgeführt werden können, eingeschränkt werden können. Alle Segmente in einem System sind im linearen Adressraum des Prozessors enthalten.
Jedes Segmentregister kann einen „sichtbaren“ Teil und einen „verborgenen“ Teil aufweisen. (Der verborgene Teil wird manchmal als „Deskriptor-Cache“ oder „Schattenregister“ bezeichnet.) Wenn ein Segmentselektor in den sichtbaren Teil eines Segmentregisters geladen wird, lädt der Prozessor auch den verborgenen Teil des Segmentregisters mit der Basisadresse, der Segmentgrenze und Zugriffssteuerinformationen von dem Segmentdeskriptor, auf den der Segmentselektor zeigt. Die im Segmentregister zwischengespeicherten Informationen (sichtbar und verborgen) ermöglichen dem Prozessor, Adressen zu übersetzen, ohne zusätzliche Buszyklen zu benötigen, um die Basisadresse und die Grenze aus dem Segmentdeskriptor zu lesen. In Systemen, in denen mehrere Prozessoren Zugriff auf dieselben Deskriptortabellen haben, liegt es in der Verantwortung der Software, die Segmentregister neu zu laden, wenn die Deskriptortabellen modifiziert werden. Falls dies nicht geschieht, kann ein alter (z. B. veralteter) Segmentdeskriptor verwendet werden, der in einem Segmentregister zwischengespeichert ist, nachdem seine speicherresidente Version modifiziert wurde.
Um ein Byte in einem bestimmten Segment zu lokalisieren, muss eine logische Adresse (auch als Fernzeiger bezeichnet) bereitgestellt werden. Eine logische Adresse besteht aus einem Segmentselektor und einem Offset. Der Segmentselektor ist eine eindeutige Kennung für ein Segment. Der Segmentselektor kann zum Beispiel eine angeforderte bevorzugte Zwei-Bit-Ebene (RPL) (z. B. Bits 1:0), einen 1-Bit-Tabellenindikator (Tl) (z. B. Bit 2) und einen 13-Bit-Index (z. B. Bits 15:3) beinhalten. Unter anderem stellt sie einen Offset in eine Deskriptortabelle (wie etwa die globale Deskriptortabelle (GDT)) für eine Datenstruktur bereit, die als Segmentdeskriptor bezeichnet wird.
Jedes Segment weist einen Segmentdeskriptor auf, der die Größe des Segments, die Zugriffsrechte und Berechtigungsebene für das Segment, den Segmenttyp und den Ort des ersten Bytes des Segments in dem linearen Adressraum spezifiziert. Der Offset-Teil der logischen Adresse wird zu der Basisadresse für das Segment hinzugefügt, um ein Byte innerhalb des Segments zu lokalisieren. Die Basisadresse plus der Offset bildet somit eine lineare Adresse im linearen Adressraum des Prozessors.
Der Speicher 114 kann bevorzugte Systemsoftware 115 speichern. Beispiele für geeignete bevorzugte Systemsoftware 115 beinhalten unter anderem ein oder mehrere Betriebssysteme, einen Virtuelle-Maschine-Monitor (VMM), einen Hypervisor und dergleichen und Kombinationen davon. Der Speicher 114 kann auch eine oder mehrere Anwendungen 116 auf Benutzerebene speichern. Die Anwendungen 116 auf Benutzerebene können optional eine oder mehrere Multithread-Anwendungen auf Benutzerebene beinhalten. Wie unten weiter erläutert wird, können solche Multithread-Anwendungen auf Benutzerebene optional hierin offenbarte Befehle verwenden, um dabei zu helfen, die Effizienz des Ausführens von Multithreading auf Benutzerebene und/oder des Ausführens von Aufgabenwechseln auf Benutzerebene zu erhöhen.
Während des Betriebs kann der Speicher 114 auch einen Stapel 119 speichern. Der Stapel 119 wird manchmal als der Aufrufstapel, der Datenstapel oder nur der Stapel bezeichnet. Der Stapel 119 kann eine Stapeltyp-Datenstruktur repräsentieren, die dazu betreibbar ist, sowohl Daten 118 als auch Steuerung 117 zu speichern. Die Daten 118 können beliebige einer breiten Vielfalt unterschiedlicher Typen von Daten repräsentieren, die Software auf den Stapel schieben möchte (Parameter und andere Daten, die an Subroutinen weitergeleitet werden usw.). Üblicherweise kann die Steuerung 117 eine oder mehrere Rückkehradressen für einen oder mehrere zuvor durchgeführte Prozeduraufrufe beinhalten. Diese Rückkehradressen können Befehlsadressen repräsentieren, bei denen die aufgerufene Prozedur den Steuerfluss zurückgeben soll, wenn die aufgerufene Prozedur endet und zurückkehrt.
Ein Stapel 119 ist ein zusammenhängendes Array von Speicherorten. Er ist in einem Segment enthalten und wird durch den Segmentselektor in einem Stapelsegmentregister (z. B. SS-Register) identifiziert. Bei Verwendung eines flachen Speichermodells kann sich der Stapel 119 irgendwo in dem linearen Adressraum für das Programm befinden. Objekte werden unter Verwendung des PUSH-Befehls auf dem Stapel 119 platziert und unter Verwendung des POP-Befehls aus dem Stapel 119 entfernt. Wenn ein Element auf den Stapel 119 geschoben wird, wird ein Stapelzeigerregister (z. B. ESP) dekrementiert, und dann wird das Element an das obere Ende des Stapels 119 geschrieben. Wenn ein Element von dem Stapel 119 abgerufen wird, wird das Element vom oberen Ende des Stapels 119 gelesen, dann wird das Stapelzeigerregister inkrementiert. Auf diese Weise wächst der Stapel 119 im Speicher abwärts (zu kleineren Adressen hin), wenn Objekte auf den Stapel 119 geschoben werden, und schrumpft aufwärts (zu größeren Adressen hin), wenn die Objekte aus dem Stapel 119 abgerufen werden. Ein Programm oder Betriebssystem/Executive kann viele Stapel 119 einrichten. In Multitasking-Systemen kann zum Beispiel jeder Aufgabe ihr eigener Stapel 119 gegeben werden. Die Anzahl von Stapeln 119 in einem System ist durch die maximale Anzahl von Segmenten und den verfügbaren physischen Speicher begrenzt. Wenn ein System viele Stapel 119 einrichtet, steht gleichzeitig nur ein Stapel 119 - der aktuelle Stapel - zur Verfügung. Der aktuelle Stapel ist der, der in dem Segment enthalten ist, auf das durch das SS-Register verwiesen wird. Der aktuelle Stapel ist der, der durch das aktuelle Stapelzeigerregister referenziert wird und in dem Segment enthalten ist, auf das durch das SS-Register referenziert wird.
Ein Segmentregister kann einen Segmentselektor beinhalten, der eine Kennung eines Segments (z. B. eine 16-Bit-Kennung) ist. Dieser Segmentselektor zeigt möglicherweise nicht direkt auf das Segment, sondern kann stattdessen auf den Segmentdeskriptor zeigen, der das Segment definiert.
Der Segmentdeskriptor kann eines oder mehrere der Folgenden beinhalten:

1) ein Deskriptortyp-Flag (S) - (z. B. Bit 12 in einem zweiten Doppelwort eines Segmentdeskriptors), das bestimmt, ob der Segmentdeskriptor für ein Systemsegment oder ein Code- oder Datensegment ist.
2) ein Typfeld - (z. B. Bits 8 bis 11 in einem zweiten Doppelwort eines Segmentdeskriptors), das den Typ eines Code-, Daten- oder Systemsegments bestimmt.
3) ein Begrenzungsfeld - (z. B. Bits 0 bis 15 des ersten Doppelworts und Bits 16 bis 19 des zweiten Doppelworts eines Segmentdeskriptors), das die Größe des Segments bestimmt, zusammen mit dem G-Flag und E-Flag (für Datensegmente).
4) ein G-Flag - (z. B. Bit 23 im zweiten Doppelwort eines Segmentdeskriptors), das die Größe des Segments bestimmt, zusammen mit dem Begrenzungsfeld und E-Flag (für Datensegmente).
5) ein E-Flag - (z. B. Bit 10 im zweiten Doppelwort eines Datensegmentdeskriptors), das die Größe des Segments bestimmt, zusammen mit dem Begrenzungsfeld und G-Flag.
6) Ein Deskriptor-Berechtigungsebenen- bzw. DPL-Feld - (z. B. Bits 13 und 14 im zweiten Doppelwort eines Segmentdeskriptors), das die Berechtigungsebene des Segments bestimmt.

Ein Angeforderte-Berechtigungsebene- bzw. RPL-Feld in einem Selektor spezifiziert die angeforderte Berechtigungsebene eines Segmentselektors.
Eine aktuelle Berechtigungsebene (CPL) gibt die Berechtigungsebene des aktuell ausgeführten Programms oder der aktuell ausgeführten Prozedur an. Der Begriff CPL bezieht sich auf die Einstellung dieses Feldes.
Teile einer Paging-Struktur sind: ein Benutzer-/Supervisor- bzw. U/S-Flag - (z. B. Bit 2 von Paging-Struktur-Einträgen), das den Seitentyp bestimmt: Benutzer oder Supervisor; ein Lese-/Schreib- bzw. R/W-Flag - (z. B. Bit 1 von Paging-Struktur-Einträgen), das den Typ des Zugriffs bestimmt, der auf eine Seite erlaubt ist: schreibgeschützt oder Schreib-/Lese-Zugriff; und ein Ausführen/Deaktivieren- bzw. XD-Flag - (z. B. Bit 63 bestimmter Paging-Struktur-Entitäten), das den Typ des Zugriffs bestimmt, der auf eine Seite erlaubt ist: ausführbar oder nicht ausführbar.
Bei rückkehrorientierter Programmierung (ROP), sprungorientierter Programmierung (JOP) und anderen Steuerflussunterlaufungsangriffen versuchen die Angreifer häufig, die Steuerung des Stapels 119 zu erhalten, um den Programmsteuerfluss zu kapern. Ein Faktor, der dazu neigen kann, den herkömmlichen Datenstapel anfälliger gegenüber ROP-, JOP- und anderen Steuerflussunterlaufungsangriffen zu machen, ist, dass der Stapel 119 im Allgemeinen sowohl die Daten 118 als auch die Steuerung 117 speichert (z. B. sind Daten und Rückkehradressen im Allgemeinen auf demselben Stapel 119 miteinander gemischt). Ein anderer Faktor, der dazu neigen kann, den herkömmlichen Stapel 119 anfälliger gegenüber solchen Angriffen zu machen, ist, dass das Umschalten des Stapels 119 allgemein als eine nicht-berechtigte Operation durchgeführt werden kann. Beide Faktoren können dazu neigen, die Exposition gegenüber der Steuerflussunterlaufung aufgrund von Bugs zu erhöhen, die ermöglichen, dass der Stapelzeiger und/oder die Steuerflussinformationen (z. B. Rückkehradressen) modifiziert werden (z. B. um auf Malware/von einem Angreifer gesteuerten Speicher zu zeigen).
Ein oder mehrere Schattenstapel 120 können enthalten sein und verwendet werden, um dabei zu helfen, den Stapel 119 vor Manipulation zu schützen und/oder dabei zu helfen, die Computersicherheit zu erhöhen. Der eine oder die mehreren Schattenstapel 120 können eine oder mehrere zusätzliche Stapeltyp-Datenstrukturen repräsentieren, die von dem Stapel 119 getrennt sind. Wie gezeigt, können der eine oder die mehreren Schattenstapel 120 verwendet werden, um Steuerinformationen 121 zu speichern, aber keine Daten (z. B. keine Parameter und andere Daten des Typs, die auf dem Stapel 119 gespeichert sind, die Anwendungsprogramme 116 auf Benutzerebene schreiben und modifizieren können müssten). Die Steuerinformationen 121, die auf dem einen oder den mehreren Schattenstapeln 120 gespeichert sind, können rückkehradressenbezogene Informationen (z. B. tatsächliche Rückkehradressen, Informationen zum Validieren von Rückkehradressen, andere Rückkehradresseninformationen) repräsentieren. Als ein mögliches Beispiel können der eine oder die mehreren Schattenstapel 120 verwendet werden, um Kopien jeglicher Rückkehradressen zu speichern, die auf den Stapel 119 geschoben wurden, wenn Funktionen oder Prozeduren aufgerufen wurden (z. B. eine Kopie jeder Rückkehradresse in der Aufrufkette, die auch auf den regulären Aufrufstapel geschoben wurde). Jeder Schattenstapel 120 kann auch einen Schattenstapelzeiger (SSP) beinhalten, der betreibbar ist, um die Oberseite des Schattenstapels 120 zu identifizieren. Der eine oder die mehreren Schattenstapel 120 können optional zum Betrieb einzeln in einem nicht-berechtigten Modus auf Benutzerebene (z. B. einer Ring-3-Berechtigungsebene) oder in einem berechtigten Modus oder Modus auf Supervisor-Berechtigungsebene (einer Ring-0-, Ring-1- oder Ring-2-Berechtigungsebene) konfiguriert sein. In einem Aspekt können möglicherweise mehrere Schattenstapel 120 in einem System konfiguriert sein, es kann aber jeweils nur ein Schattenstapel 120 pro logischem Prozessor als der aktuelle Schattenstapel 120 konfiguriert sein.
Wie gezeigt, können der eine oder die mehreren Schattenstapel 120 in dem Speicher 114 gespeichert sein. Aktuelle oder aktive Schattenstapel 120 können durch einen linearen Adressbereich definiert sein, um dabei zu helfen, Stapelüberlauf und/oder Stapelunterlauf zu detektieren und zu verhindern, wenn Push- und/oder Pop-Operationen an dem Schattenstapel 120 durchgeführt werden. Um dabei zu helfen, zusätzlichen Schutz bereitzustellen, können der eine oder die mehreren Schattenstapel 120 optional in einem geschützten oder zugriffsgesteuerten Abschnitt des Speichers 114 gespeichert sein, auf den die nicht-berechtigten Anwendungen 116 auf Benutzerebene eingeschränkten und/oder unvollständigen Zugriff haben. Unterschiedliche Weisen zum Bereitstellen geeigneter geschützter Teile des Speichers 114 zum Speichern des einen oder der mehreren Schattenstapel 120 sind möglich. Der eine oder die mehreren Schattenstapel 120 sind optional in einem Teil des Speichers 114 gespeichert, der durch Paging-Zugriffssteuerungen geschützt ist. Zum Beispiel kann die bevorzugte Systemsoftware 115 (z. B. ein Betriebssystem) Zugriffsgenehmigungen (z. B. Lese-Schreib-Ausführungs-Zugriffsgenehmigungen) in Seitentabelleneinträgen konfigurieren, die Seiten entsprechen, auf denen der eine oder die mehreren Schattenstapel 120 gespeichert sind, um die Seiten lesbar, aber nicht beschreibbar oder ausführbar zu machen. Dies kann helfen zu verhindern, dass Befehle auf Benutzerebene, wie etwa Befehle zum Speichern in den Speicher 114, Befehle zum Bewegen in den Speicher 114 und dergleichen, in der Lage sind, Daten in den einen oder die mehreren Schattenstapel 120 zu schreiben oder diese zu modifizieren. Als eine andere Option können der eine oder die mehreren Schattenstapel 120 optional in einem Teil des Speichers 114 gespeichert sein, der mit ähnlichen Zugriffssteuerungsschutzelementen geschützt ist, wie jene, die für sichere Enklaven in sicheren Intel^® Software Guard Extensions- bzw. SGX-Enklaven oder anderen geschützten Containern, isolierten Ausführungsumgebungen oder dergleichen verwendet werden.
Der Speicher 114 kann auch lokale Thread-Speicherung (TLS) 122 speichern.
Wieder unter Bezugnahme auf 1 kann der Prozessor 101 zum Beispiel ein universeller Prozessor (z. B. des Typs, der üblicherweise als eine zentrale Verarbeitungseinheit (CPU) in Desktop- , Laptop- oder anderen Computersystemen verwendet wird) sein. Alternativ dazu kann der Prozessor 101 ein spezieller Prozessor sein. Beispiele von geeigneten speziellen Prozessoren umfassen, sind aber nicht beschränkt auf, Netzwerkprozessoren, Kommunikationsprozessoren, kryptografische Prozessoren, Grafikprozessoren, Koprozessoren, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs) und Steuerungen (z. B. Mikrosteuerungen). Der Prozessor 101 kann eine beliebige aus verschiedenen Rechenarchitekturen mit komplexem Befehlssatz (CISC, Complex Instruction Set Computing), Rechenarchitekturen mit reduziertem Befehlssatz (RISC, Reduced Instruction Set Computing), Architekturen mit sehr langen Befehlswörtern (VLIW, Very Long Instruction Word), hybriden Architekturen, anderen Typen von Architekturen aufweisen oder kann eine Kombination aus unterschiedlichen Architekturen aufweisen (z. B. können unterschiedliche Kerne unterschiedliche Architekturen aufweisen).
Register 140 des Prozessors 101 können durch den logischen Prozessor 109, die FRED-Logik 130 und/oder die Schattenstapellogik 110 verwendet werden. Diese Register 140 können die Register von Figur BPE beinhalten. Beispiele für Register 140 des Prozessors 101 beinhalten eines oder mehrere von Folgendem: Flag-Speicherung (z. B. EFLAGS, RFLAGS, FLAGS, Zustandscoderegister, Flags werden mit Daten gespeichert usw.), Befehlszeiger (z. B. EIP, RIP, usw.), eine aktuelle Berechtigungsebene (CPL), Stapelzeiger, Schattenstapel 120, Steuerung, modellspezifische Register, Segmentregister (z. B. Codesegment (CS), Datensegment (DS), Stapelsegment (SS), GS usw.) usw. RFLAGS beinhaltet mindestens ein Trap-Flag (TF), ein Interrupt-Aktivieren-Flag (IF) und ein Wiederaufnahme-Flag (RF).
Der Prozessor 101 kann eine oder mehrere Befehle und Logik aufweisen, um beim Verwalten und Schützen des einen oder der mehreren Schattenstapel 120 zu helfen. Der Prozessor 101 weist einen Befehlssatz 102 auf. Der Befehlssatz 102 ist Teil der Befehlssatzarchitektur (ISA) des Prozessors 101 und beinhaltet die nativen Befehle, zu deren Ausführung der Prozessor 101 betreibbar ist. Die Befehle des Befehlssatzes können Makrobefehle, Assemblersprachbefehle oder Befehle auf Maschinenebene darstellen, die dem Prozessor 101 zur Ausführung bereitgestellt werden, im Gegensatz zu Mikrobefehlen, Mikrooperationen oder anderen decodierten Befehlen oder Steuersignalen, die aus den Befehlen des Befehlssatzes decodiert wurden.
Wie gezeigt, beinhaltet der Befehlssatz 102 mehrere FRED-Unterstützungsbefehle 103, die eines oder mehrere von Folgendem beinhalten: einen Ereignisrückkehr-zu-Benutzer-Befehl (ERETU), einen Ereignisrückkehr-zu-Supervisor-Befehl (ERETS), einen Fernaufrufbefehl, einen Interrupt-Rückkehr-Befehl (IRET), einen Fernsprung-Befehl (JMP), einen Fernrückkehr-Befehl (RET), einen Systemaufruf-Befehl (SYSCALL), einen Systemeingabe-Befehl (SYSENTER), einen MSR-Schreib-Befehl (WRMSR), einen Kontextwiederherstellungsbefehl (XRSTORS), einen Laden-in-KERNEL_GS_SKE MSR-Befehl (LKGS) und/oder einen Wiederaufnahme-aus-dem-Systemverwaltungsmodus-Befehl (RSM). Ein Prozessor oder ein Kern kann bereitgestellt sein, um einen oder mehrere beliebige dieser Befehle durchzuführen (z. B. Decodieren und Ausführen). Des Weiteren wird ein Verfahren zum Durchführen (z. B. Decodieren und Ausführen) eines beliebigen dieser Befehle bereitgestellt.
Der Prozessor 101 kann mindestens ein Verarbeitungselement oder einen logischen Prozessor 108 beinhalten. Der Einfachheit halber ist nur ein einziger logischer Prozessor gezeigt, obwohl es sich versteht, dass der Prozessor 101 optional andere logische Prozessoren beinhalten kann. Beispiele für geeignete logische Prozessoren beinhalten unter anderem Kerne, Hardware-Threads, Thread-Einheiten, Thread-Schlitze und andere logische Prozessoren. Der logische Prozessor 108 kann dazu betreibbar sein, Befehle des Befehlssatzes 102 zu verarbeiten. Der logische Prozessor 108 kann eine Pipeline oder Logik zum Verarbeiten von Befehlen aufweisen. Beispielsweise kann jede Pipeline eine Befehlsabrufeinheit zum Abrufen von Befehlen, eine Befehlsdecodiereinheit zum Decodieren von Befehlen, Ausführungseinheiten zum Ausführen der decodierten Befehle, Register zum Speichern von Quell- und Zieloperanden der Befehle und dergleichen beinhalten. Die Offenbarung ist nicht auf einen bekannten Typ oder eine bekannte Gestaltung der Pipeline beschränkt. Der logische Prozessor 108 kann dazu betreibbar sein, den Aufrufbefehl und/oder den Rückkehrbefehl und/oder den Schattenstapelzeigerspeicherungsbefehl und/oder den Schattenstapelzeigerwiederherstellungsbefehl zu verarbeiten (z. B. Decodieren, Ausführen usw.).
Wie gezeigt, kann mindestens ein Teil der Logik des mindestens einen Verarbeitungselements oder Logikprozessors 108 Teil der FRED-Logik 130 des Prozessors 101 sein. Die FRED Logik 130 ist eine dedizierte Schaltungsanordnung. Die FRED-Logik 130 nutzt eine oder mehrere Zustandsmaschinen, die durch Ausführungseinheiten und/oder einen Mikrocontroller ausgeführt werden. Die FRED-Logik 130 ist für das Liefern von Ereignissen und das Unterstützen von FRED-Befehlen verantwortlich.
Die FRED-Logik 130 verwendet neue Übergänge, die die Berechtigungsebene ändern (Ringübergänge). Diese Übergänge verbessern die Gesamtleistungsfähigkeit und Reaktionszeit durch Ersetzen der Ereignislieferung durch die Interrupt-Deskriptor-Tabelle (IDT-Ereignislieferung) und Ereignisrückkehr durch den IRET-Befehl mit Übergängen mit niedrigerer Latenz. Sie verbessern auch die Softwarerobustheit, indem sie sicherstellen, dass die Ereignislieferung den vollen Supervisor-Kontext erstellt und dass die Ereignisrückkehr den vollen Benutzerkontext erstellt.
Einzelheiten werden hier für neue Übergänge bereitgestellt, die von FRED zur Ereignislieferung verwendet werden, und, für die Rückkehr von Ereignissen, von zwei FRED-Rückkehrbefehlen (unten ausführlicher beschrieben). FRED-Ereignislieferung kann einen Übergang von Ring 3 zu Ring 0 verursachen, wird aber auch verwendet, um Ereignisvorfälle an Ring 0 zu liefern. Ein FRED-Befehl (ERETU) bewirkt eine Rückkehr von Ring 0 zu Ring 3, während der andere (ERETS) zurückkehrt, während er in Ring 0 verbleibt.
Zusätzlich zu diesen Übergängen werden Beispiele für einen Befehl (LKGS) zum Verwalten des Zustands des GS-Segmentregisters und seiner Unterstützung beschrieben. Der LKGS-Befehl kann von Betriebssystemen verwendet werden (und diese möglicherweise begünstigen), die die neuen Ringübergänge nicht verwenden.
Die FRED-Logik 130 unterstützt Ereignislieferung. Ein Ereignis, das normalerweise eine IDT-Ereignislieferung verursachen würde (z. B. ein Interrupt oder eine Ausnahme), wird stattdessen neuen Kontext erstellen, ohne auf irgendeine der Legacy-Datenstrukturen (z. B. IDT) zuzugreifen. Varianten existierender SYSCALL- und SYSENTER-Befehle können auch eine FRED-Ereignislieferung anstelle ihrer existierenden Operationen verwenden, wie unten ausführlich beschrieben ist.
Auf den neun Prozessorzustand, der durch FRED definiert ist, kann, unabhängig vom Modus, von RDMSR und WRMSR zugegriffen werden. Es wird angemerkt, dass ein Präfix „IA32“ nicht in allen Beispielen für verschiedene MSRs enthalten ist.
Die FRED-Logik 130 verwendet eine Stapelebene. Die aktuelle Stapelebene (CSL) ist ein Wert im Bereich von 0 - 3, den der Prozessor 101 verfolgt, wenn CPL = 0. Es ist anzumerken, dass die Anzahl an Stapelebenen von den vier aufgelisteten variieren kann. FRED-Ereignislieferung bestimmt die Stapelebene, die mit dem gelieferten Ereignis assoziiert ist, und lädt, falls sie größer als die CSL ist (oder falls CPL nicht 0 gewesen wäre), den Stapelzeiger aus einem FRED_RSP-MSR, das mit der Stapelebene des Ereignisses assoziiert ist. Der FRED-Rückkehrbefehl ERETS stellt die alte Stapelebene wieder her. (Falls Supervisor-Schattenstapel 120 aktiviert sind, gilt die Stapelebene auch für den Schattenstapelzeiger SSP, der von einem FRED_SSP-MSR geladen werden kann.)
Der oben ausführlich beschriebene Schattenstapelzeiger beinhaltet einen Token-Verwaltungsmechanismus, um Schattenstapelintegrität beim Umschalten der Schattenstapel 120 sicherzustellen. Dieser Mechanismus verwendet gesperrte Lesen-Modifizieren-Schreiben-Operationen, die die Worst-Case-Leistungsfähigkeit negativ beeinflussen können. Die FRED-Logik 130 verwendet einen modifizierten Token-Verwaltungsmechanismus, der diese Operationen für die meisten Übergänge vermeidet. Dieser neue Mechanismus wird durch Definieren neuer verifizierter Bits in den FRED_SSP-MSRs unterstützt.
Da Betriebssysteme vom LKGS-Befehl profitieren können, ohne FRED-Logik 130 zu verwenden, werden die zwei Elemente unabhängig aufgezählt. In einigen Beispielen zählt ein Flag die Unterstützung für die neuen FRED-Übergänge auf. Es zählt auch die Unterstützung neuer Architekturzustände (MSRs) auf, die von FRED verwendet werden. In einigen Beispielen zählt ein Flag die Unterstützung für den LKGS-Befehl auf.
Die FRED-Logik 130 wird durch Setzen eines Bits in einem Steuerregister aktiviert. Zum Beispiel Setzen von Bit 32 in CR4. Das Setzen von CR4.FRED ermöglicht FRED-Ereignislieferung, aber nur im IA-32e-Modus (wenn IA32_EFER.LMA = 1). Diese Einstellung ermöglicht die FRED-Rückkehrbefehle, aber nur im 64-Bit-Modus (wenn IA32_EFER.LMA = CS.L = 1).
Wenn CR4.FRED = 1, bewirkt eine Ausführung eines beliebigen der folgenden Befehle in einem beliebigen Modus eine Ungültiger-Opcode-Ausnahme (#UD): SWAPGS, SYSEXIT und SYSRET.
Die Register 140 können mehrere modellspezifische Register (MSRs) beinhalten, die von der FRED-Logik 130 verwendet werden. Es kann ein FRED-Konfigurations-MSR (z. B. IA32_FRED_CONFIG oder FRED_CONFIG) geben. 2 veranschaulicht ein Beispiel für ein FRED-Konfigurations-MSR 201. Dieses MSR 201 ist wie folgt organisiert:

1) Bits 1:0 kennzeichnen die aktuelle Stapelebene (CSL). Dieser 2-Bit-Wert wird manipuliert und durch FRED-Ereignislieferung und die FRED-Rückkehrbefehle verwendet. Software kann die CSL unter Verwendung eines MSR-Schreib-Befehls (WRMSR) modifizieren.
2) Bit 2 ist reserviert.
3) Bit 3 gibt an, falls gesetzt, dass die FRED-Ereignislieferung den Schattenstapelzeiger (SSP) um 8 dekrementieren sollte, wenn Stapel nicht geändert werden.
4) Bits 5:4 sind reserviert.
5) Die Bits 8:6 identifizieren den Betrag (gemessen in 64-Byte-Cachezeilen), um den die FRED-Ereignislieferung den regulären Stapelzeiger (RSP) dekrementiert, wenn Stapel nicht geändert werden.
6) Die Bits 10:9 kennzeichnen die Stapelebene, die für maskierbare Interrupts verwendet wird, die geliefert werden, während CPL = 0.
7) Bit 11 ist reserviert.
8) Die Bits 63:12 enthalten die oberen Bits der linearen Adresse einer Seite in dem Speicher 114, der Ereignishandler enthält. FRED-Ereignislieferung lädt RIP, um auf einen Eintrittspunkt auf dieser Seite zu verweisen.

Ein Schreiben in dieses MSR 201 unter Verwendung von WRMSR bewirkt eine allgemeine Schutzausnahme (#GP), falls sein Quelloperand reservierte Bits setzt oder falls er nicht kanonisch bezüglich der maximalen linearen Adressbreite des Prozessors ist.
3 veranschaulicht ein FRED_SSP-MSR 301. Es kann 4 solche MSRs 301 (z. B. IA32_FRED_SSP0 - IA32_FRED_SSP3) geben.
Wenn Supervisor-Schattenstapel aktiviert sind und eine FRED-Ereignislieferung einen Übergang vom Ring 3 oder eine Änderung an der CSL bewirkt, lädt die FRED-Logik 130 SSP aus dem FRED_SSP-MSR, das der neuen Stapelebene entspricht. Es wird angemerkt, dass ein existierender MSR für SSP (z. B. IA32_PL0_SSP) einem der FRED_SSP-MSRs (z. B. IA32_FRED_SSP0 ist IA32_PL0_SSP) entsprechen kann. Wenn Supervisor-Schattenstapel aktiviert sind und eine FRED-Ereignislieferung einen Übergang vom Ring 3 oder eine Änderung an der CSL bewirkt, lädt die FRED-Logik SSP aus der FRED_SSP MSR, die der neuen Stapelebene entspricht. Jedes der FRED_SSP-MSRs ist wie folgt organisiert (und in 3 gezeigt):

1) Bit 0 ist das verifizierte Bit des MSR 301. Dieses Bit wird von der Tokenverwaltung verwendet, die von der FRED-Ereignislieferung und von Ausführungen von ERETS und ERETU durchgeführt wird. Es wird angemerkt, dass die verifizierten Bits nur in den FRED_SSP-MSRs und nicht in dem SSP selbst existieren. Auf Prozessoren, die keine Unterstützung für FRED aufzählen, erzwingt WRMSR auf IA32_PL0_SSP eine 4-Byte-Ausrichtung und behandelt somit die Bits 1:0 als reservierte Bits. Auf Prozessoren, die Unterstützung für FRED aufzählen, verursacht WRMSR zu IA32_PL0_SSP keine #GP, da Bit 0 in seinem Quelloperanden gesetzt ist. Nachfolgend ist gezeigt, wie WRMSR Bit 0 dieses MSR behandelt.
2) Für jeden der IA32_FRED_SSPi (1 <= i <= 3) werden Bits 2:1 reserviert. Für IA32_PL0_SSP ist Bit 1 reserviert, aber Bit 2 nicht.
3) Die Bits 63:3 enthalten die oberen Bits des ausgerichteten 8-Byte-Werts, der in SSP geladen werden soll.

In einigen Beispielen wird ein WRMSR für einen beliebigen dieser MSRs eine allgemeine Schutzausnahme (#GP) verursachen, falls sein Quelloperand nicht 64-Byte-ausgerichtet ist oder falls er nicht kanonisch bezüglich der maximalen linearen Adressbreite des Prozessors ist. Ein WRMSR zu einem beliebigen dieser MSRs löscht immer Bit 0 des MSR, unabhängig vom Wert des Quelloperanden des Befehls. Der WRMSR-Befehl ignoriert Bit 0 seines Quelloperanden, so dass der Versuch, Bit 0 zu setzen, nicht bewirkt, dass WRMSR fehlerhaft wird.
Die Register 140 des Prozessors 101 können eine Vielzahl von FRED_RSP-MSRs beinhalten. Zum Beispiel IA32_FRED_RSP0, IA32_FRED_RSP1, IA32_FRED_RSP2 und IA32_FRED_RSP3. Falls eine FRED-Ereignislieferung einen Übergang von Ring 3 oder eine Änderung zu der CSL bewirkt, wird das RSP-MSR aus dem FRED_RSP-MSR geladen, das der neuen Stapelebene entspricht. Ein WRMSR zu einem dieser MSRs bewirkt eine allgemeine Schutzausnahme (#GP), falls sein Quelloperand relativ zu der maximalen linearen Adressbreite des Prozessors nicht kanonisch ist.
Es gibt ein zusätzliches Konfigurationsregister (z. B. IA32_FRED_STKLVLS MSR). Dieses 64-Bit-Register enthält ein 2-Bit-Feld für jeden von 32 Ausnahmevektoren. Einer Doppelfehlerausnahme (DF, Vektor 8) wird Stapelebene 2, der Seitenfehlerausnahme (PF, Vektor 14) Stapelebene 0 und der Maschinenprüfausnahme (MC, Vektor 18) Stapelebene 3 zugewiesen.
Zusätzliche MSRs, die die FRED-Logik 130 verwenden kann, beinhalten unter anderem: ein Register zum Speichern einer Systemaufruf-Zieladresse (z. B. IA32_STAR); ein Register zum Speichern einer Systemaufruf-Flag-Maske (z. B. IA32_FMASK); ein Register zum Speichern eines Austauschziels einer Basisadresse von GS (z. B. IA32_KERNEL_GS_BASE); und ein Register zum Speichern einer Berechtigungsebene. Wie diese Register verwendet werden können, ist unten ausführlich beschrieben.
Der Prozessor 101 beinhaltet eine Schattenstapellogik 110 (z. B. Schaltungsanordnung, Zustandsmaschine usw.), um Schattenstapelfähigkeiten zu implementieren.
Steuerflussübergänge, die die CPL ändern, werden informell als Ringübergänge bezeichnet, und es gibt zwei Haupttypen: 1) Übergänge, die die Berechtigung erhöhen (durch Verringern der CPL), die Übergänge unter Verwendung von Interrupt- und Trap-Gattern in der Interrupt-Deskriptor-Tabelle (IDT) beinhalten, Ausführungen des fernen CALL-Befehls, die auf Aufrufgatter zugreifen, und Ausführungen von Systemaufrufbefehlen (wie etwa SYSCALL oder SYSENTER); und 2) Übergänge, die die Berechtigung verringern (durch Erhöhen der CPL), wie etwa ein Interrupt-Rückkehrbefehl (IRET), ein ferner RET-Befehl, Rückkehr-von-Systemaufrufen-Befehle (z. B. SYSEXIT oder SYSRET).
Da die CPL in den CS- und SS-Segmentregistern manifest ist, modifizieren Ringübergänge immer die CS- und SS-Segmentregister. GS ist ein weiteres Segment, das Software zum Zeitpunkt von Ringübergängen verwaltet. Denn 64-Bit-Betriebssysteme verwenden das GS-Segment, um Thread-Iokale Speicherung (TLS) 122 zu unterstützen: Die GS-Basisadresse identifiziert den Ort des TLS 122. Benutzer- und Supervisorsoftware verwenden die TLS 122 an unterschiedlichen Adressen, so dass sich die Basisadresse des GS-Segments in Abhängigkeit von der CPL unterscheidet.
Im Gegensatz zu CS und SS wird GS typischerweise nicht durch existierende Ringübergänge modifiziert. Dies bedeutet, dass nach einem Übergang zu Ring 0 die GS-Basisadresse immer noch Benutzer-TLS 122 referenziert. Aus diesem Grund sollte Supervisor-Software die GS-Basisadresse aktualisieren, bevor sie auf ihre eigene TLS 122 zugreifen kann. Gleichermaßen sollte sie die GS-Basisadresse auf den Benutzerwert zurückschalten, bevor sie zu Benutzersoftware zurückkehrt. Der SWAPGS-Befehl unterstützt effiziente Aktualisierungen der GS-Basisadresse.
Der Kontext, der durch Ereignislieferung und -rückkehr verwaltet wird, ist häufig auf den Befehlszeiger (und das Codesegment) und den Stapelzeiger (und das Stapelsegment) beschränkt. Der Kontext der Ereignishandler moderner Betriebssysteme beinhaltet auch den Zeiger auf die Thread-Iokale Speicherung des BS-Kernels (Betriebssysteme auf x86-Mikroprozessoren verwenden dafür das GS-Segment). Ereignislieferung und -rückkehr auf x86-Mikroprozessoren verwalten das GS-Segment nicht. Um dies zu adressieren, wurde ein neuer Befehl eingeführt (SWAPGS), der es einem Ereignishandler ermöglicht, den richtigen Wert für das GS-Segment (falls notwendig) kurz nach der Ereignislieferung festzulegen und den Wert des unterbrochenen Kontexts kurz vor der Ereignisrückkehr wiederherzustellen. (Aufgrund der Art und Weise, wie Betriebssysteme das GS-Segment verwenden, ist es notwendig, SWAPGS nur nach Ereignislieferung von Benutzersoftware und nur vor einer Ereignisrückkehr an Benutzersoftware auszuführen.)
Obwohl der SWAPGS-Befehl das Obige zur Thread-lokalen Speicherung adressiert, stellt er nur eine Teillösung bereit. Da SWAPGS nur bei einer Ereignislieferung oder -rückkehr ausgeführt werden sollte, die die Berechtigungsebene ändert, ist es unerlässlich, dass ein Ereignishandler zuverlässig bestimmen kann, ob er ein Ereignis behandelt, dessen Lieferung die Berechtigungsebene geändert hat.
4 veranschaulicht eine beispielhafte Konfiguration vor der Ereignislieferung. Die Ereignislieferung kann von der FRED-Logik 130 behandelt werden. Allgemein ist die in 4 veranschaulichte Konfiguration unabhängig von den Entitäten und Komponenten, die in den anderen Figuren gezeigt sind, und kann unabhängig betrachtet werden. Links sind Bereiche des Speichers 401 veranschaulicht, die durch den unterbrochenen Kontext für die Befehle (Code) 403, den Stapel 405 und die TLS 407 verwendet werden. In dieser Konfiguration beträgt die ursprüngliche Berechtigungsebene (CPL) 3 (gespeichert in der Speicherung 411 der aktuellen Berechtigungsebene), was eine Benutzeranwendung angibt. Das Befehlszeigerregister (RIP) (des Befehlszeigerspeichers 412) zeigt auf den Code 403 des unterbrochenen Kontexts; das Stapelzeigerregister (RSP) 415 zeigt auf das untere Ende seines aktuellen Stapels 405; und das GS-Segmentregister 417 zeigt auf seine TLS 407. Der unterbrochene Kontext umfasst auch den Flags-Speicher (RFLAGS) 414.
Zusätzlich zu dem unterbrochenen Kontext veranschaulicht 4 auch Register und Speicher, die das BS und seinen Ereignishandler 421 betreffen. Das BS-RIP 413 und das BS-RSP 416 sind BS-verwaltete Konfigurationsregister, die auf den Code 423 bzw. den Stapel 425 des Ereignishandlers zeigen. Ebenfalls veranschaulicht ist ein alternatives GS-Segmentregister 418, das auf die TLS 427 des BS zeigt.
5 veranschaulicht die beispielhafte Konfiguration nach der Ereignislieferung. Die Ereignislieferung wird von der FRED-Logik 130 behandelt. Allgemein ist die in 5 veranschaulichte Konfiguration unabhängig von den Entitäten und Komponenten, die in den anderen Figuren gezeigt sind, und kann unabhängig betrachtet werden. Die CPL wurde auf 0 aktualisiert, was für einen BS-Ereignishandler geeignet ist. Das RIP 412 und das RSP 415 wurden aktualisiert, um auf den Code 423 und den Stapel 425 zu zeigen, die von dem BS-Ereignishandler verwendet werden. Das Flag-Register 414 wurde gelöscht. Auf den Stapel 425 des BS-Ereignishandlers werden Informationen über das soeben gelieferte Ereignis (das in diesem Fall einen Seitenfehler an der angegebenen Adresse angibt) und die alten Werte des Stapelzeigers, des Flag-Registers, des Befehlszeigers und der CPLs geschoben.
Für die TLS wurden die Werte des GS-Segmentregisters 417 und des alternativen GS-Segmentregisters 418 vertauscht. Obwohl ähnlich dem, was mit einem existierenden SWAPGS-Befehl erfolgen könnte, führen hier ausführlich beschriebene Beispiele dieses Austauschen als Teil der Ereignislieferung aus, aber nur, falls die Ereignislieferung die CPL von 3 auf 0 ändert. Falls die CPL vor der Ereignislieferung bereits 0 gewesen wäre, würde die Ereignislieferung das GS-Segmentregister nicht ändern, da es bereits auf die TLS des BS zeigen würde. Spezifischere Einzelheiten der Ereignislieferung werden unten ausführlicher beschrieben.
Stapel sind nützliche Datenstrukturen zum Speichern von Informationen aufgrund ihrer dynamischen Natur. Neue Informationen können auf einen Stapel „geschoben“ werden, ohne ältere, bereits auf dem Stapel befindliche Informationen zu verfälschen. Wenn die neuen Informationen nicht mehr benötigt werden (weil die verbrauchte Softwareroutine zu einer bereits laufenden älteren Routine zurückkehrt), kann der Stapel „abgerufen“ werden, wodurch die älteren Informationen angemessen freigelegt werden. Da sich die Inhalte eines Stapels (und der aktuelle „Stapelzeiger“, der auf das aktuelle „obere Ende“ des Stapels verweist) dynamisch ändern, wenn ein Softwarethread arbeitet, ist jeder Steuerungsthread typischerweise mit seinem eigenen Stapel im Speicher assoziiert.
Zusätzlich zur Verwendung durch Software kann eine CPU (oder ein Kern davon) einen Stapel (z. B. Stapel 119) verwenden, wenn Ereignisse, wie etwa Interrupts und Ausnahmen, geliefert werden. Der Ereignisliefermechanismus der CPU (oder des Kerns davon) kann die Werte gewisser Register, die den Softwarekontext definieren, der zu dem Zeitpunkt, zu dem das Ereignis aufgetreten ist, ausgeführt wurde, auf den Stapel (z. B. Stapel 119) schieben. (Ereignislieferung kann auch Informationen über die Art des gelieferten Ereignisses auf den Stapel (z. B. Stapel 119) schieben.) Der Vorteil des Schiebens solcher Informationen auf einen Stapel (anstatt sie an einem festen Ort im Speicher oder in dedizierten Registern zu speichern) besteht darin, dass die Lieferung eines anderen Ereignisses später die gespeicherten Informationen nicht überschreibt. CPUs definieren typischerweise Ereignisrückkehrbefehle, die diesen Prozess umkehren, die alten Werte aus dem Stapel (z. B. Stapel 119) abrufen und sie in den entsprechenden Registern wiederherstellen. Ein sekundärer „Schattenstapel“ (z. B. Stapel 120) kann ähnlich verwendet werden, um die Steuerflussintegrität zu erhöhen.
Der Speicherstapel, der von der CPU (oder deren Kern) für Ereignislieferung und - rückkehr verwendet wird, wird von dem BS gesteuert. Es gibt verschiedene Gründe, aus denen ein BS möglicherweise Ereignislieferung bei unterschiedlichen Gelegenheiten unterschiedliche Stapel verwenden möchte. Einige Beispiele sind:

• Die Lieferung eines ersten Ereignisses (z. B. Interrupt) kann ein zweites Ereignis (z. B. Seitenfehler) erfahren, während Informationen über den Stapel gespeichert werden. (Das zweite Ereignis wird als verschachtelter Fehler bezeichnet.) Falls die Lieferung des verschachtelten Fehlers denselben Stapel verwendet hat und falls das zweite Ereignis ein Ergebnis eines Zugriffs auf den Stapel wäre, könnte sich das Problem unbegrenzt wiederholen. Ein BS würde bevorzugen, eine solche Situation zu identifizieren, falls es einen Mechanismus verwenden könnte, durch den solche verschachtelten Fehler einen anderen Stapel verwenden könnten.
• Ein BS kann einen Stapel im Supervisorspeicher für jeden Anwendungssoftwarethread zuweisen, und es kann bevorzugen, einen solchen Pro-Thread-Stapel zu verwenden, wenn Ereignisse behandelt werden, die durch einen Softwarethread ausgelöst werden (z. B. ein Systemaufruf). Das BS kann auch einen Stapel für jeden Prozessor (oder Hardware-Thread) zuweisen, und es kann bevorzugen, den Stapel des lokalen Prozessors zu verwenden, wenn Ereignisse behandelt werden, die asynchron auftreten (z. B. E/A-Interrupts).
• Manche CPUs definieren bestimmte Ereignisse spezifisch für Debug (z. B. Debug-Ausnahmen, die durch Unterbrechungspunkte, Einzelschritte usw. erzeugt werden). Während des Debugs (insbesondere des BS-Kernels) kann es vorteilhaft sein, dass der Debugger in einem separaten Kontext arbeitet. Aus diesem Grund möchte ein BS möglicherweise die Lieferung von Debug-bezogenen Ereignissen, um einen anderen Stapel als den zu verwenden, der für andere Ereignisse verwendet wird.

Existierende Befehlssatzarchitekturen (ISAs) stellen unterschiedliche Mechanismen zum Aufrufen von Ereignishandlern mit unterschiedlichen ereignisspezifischen Stapeln bereit. Die obige Erörterung konzentriert sich auf BS-konfigurierte Mechanismen, die verwendet werden sollen, wenn die Ereignislieferung auf einen neuen Stapel wechselt. Es gibt auch Situationen, in denen die Ereignislieferung den Stapel nicht wechselt. Dies kann zum Beispiel auftreten, wenn die Ausführung in Ring 0 auf einen Seitenfehler trifft. In diesen Fällen schiebt die Ereignislieferung Informationen über den aktuellen Stapel, unmittelbar über jenen Daten, auf die zugegriffen wurde, als das Ereignis aufgetreten ist.
Aufgrund dieses Verhaltens kann ein BS den Speicher (z. B. den Speicher 114) unmittelbar über dem „oberen Ende des Stapels“ nicht verwenden, um temporäre Daten zu speichern. Falls dies der Fall wäre, würden diese Daten bei Lieferung einer Ausnahme oder Unterbrechung verloren gehen, da diese Lieferung die temporären Daten überschreiben würde. Die Implikation ist, dass ein BS keine „rote Zone“ über dem Stapel verwenden kann, in der Weise, wie dies Anwendungssoftware kann.
Manche ISAs verwalten Ereignishandlerstapel basierend auf der Berechtigungsebene (oder Ring). Ein BS kann einen Stapel (vielleicht pro Softwarethread) für jeden Ring zuweisen, an dem ein Ereignishandler aufgerufen werden kann, und Zeiger auf diese Stapel in einer durch eine CPU (oder einen Kern davon) definierten Datenstruktur platzieren, die dieses TSS aufgerufen hat. Wenn die Lieferung eines Ereignisses den Ring ändert, wird der Stapelzeiger aus dieser Datenstruktur geladen (wobei der Zeiger ausgewählt wird, der dem neuen Ring zugewiesen ist).
BSe konfigurieren im Allgemeinen alle Ereignishandler, um eine maximale Berechtigung (Ring 0) zu verwenden, wobei immer derselbe BS-Stapelzeiger ausgewählt wird. Manche Architekturen erlauben eine unterschiedliche Anordnung unterschiedlicher Ereignisse (basierend auf dem numerischen Vektor des Ereignisses), erlauben aber normalerweise nicht, dass unterschiedliche Stapel verwendet werden. Ein BS kann einen anderen Stapel für ein Ereignis spezifizieren, indem dieses Ereignis zum Verwenden eines Aufgabengatters konfiguriert wird. Ein Ereignis, das unter Verwendung eines Aufgabengatters geliefert wird, verwendet einen Stapel durch Umschalten auf ein anderes TSS.
Aufgabengatter ermöglichen somit, dass ein BS angibt, dass bestimmte Ereignisse (basierend auf einem Vektor) unterschiedliche Stapel verwenden sollen. Sie ermöglichen einem BS selbst nicht, anzugeben, dass ein spezieller Stapel für einen verschachtelten Fehler verwendet werden sollte (siehe die Problemaussage oben). Manche Architekturen spezifizieren jedoch, dass in bestimmten Situationen ein verschachtelter Fehler zur Erzeugung eines Doppelfehlers führt, eines speziellen Fehlers, der einen eindeutigen Vektor aufweist. Ein BS kann den Doppelfehlervektor dazu konfigurieren, ein Aufgabengatter zu verwenden, wodurch sichergestellt wird, dass (in den meisten Problemfällen) ein verschachtelter Fehler einen Ereignishandler mit einem alternativen Stapel aufruft.
Manche Architekturen unterstützen keine Aufgabengatter, sondern definieren einen anderen Mechanismus, der ereignisspezifische Stapel unterstützt. Insbesondere wird das TSS um eine Interrupt-Stapeltabelle (IST) erweitert, die 7 zusätzliche Stapelzeiger enthält. Eine Architektur ordnet auch jedem Ereignisvektor einen 3-Bit-IST-Index zu. Falls der Vektor eines Ereignisses, das geliefert wird, einen IST-Index ungleich Null aufweist, wird der Stapelzeiger aus dem referenzierten Eintrag in der IST geladen (anstatt aus dem Standardstapelzeiger, der für Ring 0 definiert ist).
Ein 64-Bit-BS, das eine Architektur verwendet, kann einen von Null verschiedenen IST-Index für jedes Ereignis auswählen, dessen Handler einen anderen Stapel erfordert. Ebenso wie ein BS unter Verwendung einer 32-Bit-Architektur ein Aufgabengatter für den Doppelfehlervektor verwenden könnte, würde ein 64-Bit-BS, das eine 64-Bit-Architektur verwendet, wahrscheinlich einen von Null verschiedenen IST-Index für diesen Vektor verwenden.
Diese Lösungen weisen eine Vielzahl von Nachteilen auf. Der Aufgabengattermechanismus war mühsam zu verwenden und funktionierte nicht gut. Der IST-Mechanismus hat zwar ein geringeres Gewicht, bringt aber Herausforderungen hinsichtlich Wiedereintritt und Ereignisverschachtelung mit sich. Es wird angenommen, dass der Doppelfehler (#DF) und die Maschinenprüfung (#MC) zwei Ausnahmen waren, für die ein BS den IST-Mechanismus verwendet. Das BS muss jeweils einen unterschiedlichen IST-Index zuweisen. Es wird angenommen, dass dies nicht der Fall ist; dann lädt die Lieferung jedes Fehlers denselben Zahlenwert in den Stapelzeiger. Falls #MC zuerst geliefert würde, wird sein Handler Daten auf den neuen Stapel schieben, wodurch der Stapelzeiger aktualisiert wird. Falls dann ein #DF geliefert wird, wird der Stapelzeiger mit demselben Wert neu geladen, der geladen wurde, als die #MC geliefert wurde. Falls der #DF-Handler Daten auf den Stapel schiebt, überschreibt er die Daten, die durch den #MC-Handler geschrieben wurden. Falls der #DF-Handler schließlich zu dem #MC-Handler zurückkehrt, wird die Ausführung beschädigt.
Selbst wenn das BS für jeden gewünschten Ereignisvektor einen anderen IST-Index zuweist, kann dasselbe Problem auftreten, wenn zwei Ereignisse mit demselben Vektor nacheinander geliefert werden. Dies liegt daran, dass, wie im vorherigen Absatz, die Lieferung des zweiten Ereignisses den Stapelzeiger mit demselben Wert neu lädt, der durch die Lieferung des ersten Ereignisses verwendet wurde.
Betriebssysteme, die den IST-Mechanismus verwenden, sind bestrebt sicherzustellen, dass aufeinanderfolgende Ereignisse mit demselben Vektor (der konfiguriert ist, um den IST zu verwenden) nicht auftreten. Nichtsdestotrotz können diese Softwareansätze fragil sein und Anfälligkeiten in das BS einführen.
Weder der Aufgabengatter-Mechanismus noch der IST-Mechanismus verhindern, dass eine Ereignislieferung irgendwelche Daten überschreibt, die ein BS in einer „roten Zone“ über dem oberen Ende des Speicherstapels des BS speichern könnte.
Spezifizierte Anzahlen von Stapelebenen können von einem Prozessor (wie dem Prozessor 101) unterstützt werden, die jeweils mit einem unterschiedlichen Stapel im Supervisorspeicher assoziiert sind, und die jeweils mit einem unterschiedlichen Wert des Stapelzeigers spezifiziert sind. Zu jedem Zeitpunkt verfolgt die CPU (oder der Kern davon) die aktuelle Stapelebene. Ein Beispiel assoziiert jedes Ereignisgeschehen mit einer Ereignisstapelebene. Die Ereignisstapelebene kann durch den Ereignisvektor, die aktuelle Berechtigungsebene, ob das Ereignis verschachtelt ist, oder eine Kombination davon bestimmt werden. Wenn ein Ereignis geliefert wird, vergleicht die CPU (oder ein Kern davon) die Ereignisstapelebene mit der aktuellen Stapelebene. Falls die Ereignisstapelebene größer ist, schaltet die CPU (oder der Kern davon) Stapel auf die Ereignisstapelebene um; andernfalls fährt sie mit demselben Stapel fort. Ein komplementärer Mechanismus kann bereitgestellt sein, um den aktuellen Stapelzeiger anzupassen, um eine „rote BS-Zone“ zu unterstützen.
Die Verwendung von FRED, wie hier ausführlich beschrieben, kann das allgemeine Problem lösen, einem BS zu ermöglichen, flexibel zu spezifizieren, welcher Stapel in welcher Situation verwendet werden sollte. FRED korrigiert das zentrale Problem mit dem existierenden IST-Mechanismus, indem eine Beschädigung von Stapeldaten verhindert wird, wenn ein zweites Ereignis auftritt. Das liegt daran, dass es keinen Stapelwechsel gibt, wenn ein zweites Ereignis auf derselben Stapelebene eintrifft: der Stapelzeiger wird nicht neu geladen, und keine Daten werden überschrieben. Betriebssystemanbieter haben das Risiko des Überschreibens von Stapeldaten als ein wichtiges Sicherheitsbedenken identifiziert, und die ausgeführten Beispiele adressieren diese Bedenken.
Am einfachsten definiert ein Beispiel eine feste Anzahl von Stapelebenen (z. B. 4). Dies würde einen Mechanismus definieren, durch den ein BS einen Stapelzeiger für jede Stapelebene spezifizieren kann. Dies könnte eine speicherinterne Datenstruktur sein, die Orte enthält, an denen das BS die Stapelzeiger speichern kann (z. B. eine Erweiterung der Neudefinition des existierenden TSS), oder sie könnte ein Satz von Registern sein, die diese Stapelzeiger pro Ebene enthalten sollen. Ein Prozessor (z. B. Prozessor 101), der mehrere gleichzeitige Stapel (z. B. einen regulären Stapel und einen Schattenstapel) unterstützt, würde entsprechend mehrere Stapelzeiger (z. B. zwei, regulär und Schatten) für jede Stapelebene unterstützen.
Ein BS kann ermöglichen, die Stapelebene für jedes Ereignis zu spezifizieren. Die Ereignisstapelebene könnte basierend auf einer beliebigen oder allen der folgenden (oder anderen) Bedingungen definiert werden: 1) Die aktuelle Berechtigungsebene zum Zeitpunkt des Auftretens des Ereignisses; 2) die Art des Ereignisses (z. B. Ausnahme versus Interrupt); 3) die Ereignisnummer (oder der Vektor); 4) ob das Ereignis während der Lieferung eines früheren Ereignisses angetroffen wurde; und/oder 5) ereignisspezifische Details (z. B. die spezifischen Genehmigungsverletzungen, die einen Seitenfehler verursachen).
Ein Beispiel könnte verschiedene Mechanismen definieren, die das BS verwenden soll, um Ereignisstapelebenen zu spezifizieren. Zum Beispiel könnte es ein Konfigurationsregister geben, das die Stapelebene für jeden Ausnahmevektor spezifiziert. Im Gegensatz dazu könnte ein Beispiel ermöglichen, dass eine einzelne (BS-konfigurierbare) Stapelebene in einem anderen Register konfiguriert wird und dies für alle Interrupts verwendet (es ist häufig der Fall, dass es viel mehr Interrupt-Vektoren als Ausnahmevektoren gibt).
Die CPU (oder ein Kern davon) verfolgt immer die aktuelle Stapelebene (z. B. unter Verwendung der FRED-Logik 130). Wenn ein Ereignis eingeht, bestimmt die CPU (oder der Kern davon) zuerst die Ereignisstapelebene basierend auf der oben umrissenen BS-Konfiguration. Die Ereignisstapelebene wird dann mit der aktuellen Stapelebene verglichen. Ist die Ereignisstapelebene größer, so wird sie die neue aktuelle Stapelebene. Der eine oder die mehreren Stapelzeiger für diese Stapelebene werden wie durch das BS konfiguriert geladen, und Informationen über das Ereignis werden auf den referenzierten Stapel geschoben. Wenn die Ereignisstapelebene nicht größer als die aktuelle Stapelebene ist, werden der eine oder die mehreren Stapelzeiger nicht geladen, und Informationen über das Ereignis werden auf den aktuellen Stapel geschoben.
Eine Spezialbehandlung kann für Ereignisse gelten, die eine Änderung der Berechtigungsebene (z. B. vom Benutzer- zum Supervisorbetrieb) bewirken. Dies liegt darin begründet, dass solche Übergänge auch eine Stapeländerung bewirken sollten (ein BS sollte den Benutzerstapel nicht verwenden). Beispiele werden wahrscheinlich den einen oder die mehreren Stapelzeiger für die Ereignisstapelebene immer dann laden, wenn die Ereignislieferung die Berechtigungsebene ändert.
Um der CPU (oder dem Kern davon) zu ermöglichen, die aktuelle Stapelebene ordnungsgemäß zu verfolgen, kann ein Beispiel die alte Stapelebene auf dem Stapel speichern, wenn sie einen anderen Rückkehrzustand (z. B. die alten Befehls- und Stapelzeiger) speichert. Falls dies geschieht, kann eine Rückkehr von dem Ereignishandler dann die alte Stapelebene wiederherstellen, wenn er diesen Rückkehrzustand wiederherstellt.
Dieser Mechanismus auf Stapelebene kann einem BS die gewünschte Kontrolle darüber geben, welcher Stapel verwendet wird, wenn unterschiedliche Ereignisse in unterschiedlichen Kontexten behandelt werden. Er bietet einen wesentlichen Vorteil gegenüber dem existierenden IST-Mechanismus dahingehend, wie er aufeinanderfolgende Vorkommnisse derselben Art von Ereignis behandelt (mit demselben IST-Index oder derselben Stapelebene). Mit dem IST-Mechanismus führen diese Vorkommnisse zu Datenbeschädigung, wie zuvor beschrieben. Mit Stapelebenen wird das zweite Auftreten einfach seine Informationen über den aktuellen Stapel schieben, wobei die Informationen, die das erste Ereignis betreffen, bewahrt werden.
Dieser Schutz vor Beschädigung resultiert auch dadurch, dass die Stapelebenen geordnet sind: die Ereignislieferung kann die Stapelebene erhöhen, wird sie aber niemals verringern. Dies stellt sicher, dass, sobald die CPU (oder der Kern davon) zum Beispiel von Stapelebene 1 zu Stapelebene 2 übergeht, keine zukünftige Ereignislieferung Stapelebene 1 verwendet (bis Software eine Rückkehr von einem Ereignishandler bewirkt). Falls insbesondere ein Ereignis mit Ereignisstapelebene 1 eingeht, während sich die CPU (oder der Kern davon) bereits auf Stapelebene 2 befindet, wird das neue Ereignis auf dem Stapel auf Ebene 2 geliefert. Die CPU (oder ein Kern davon) schaltet auf Ebene 1 nicht auf den Stapel zurück. (Mit dem IST-Mechanismus würde dies zu Stapel 1 zurückschalten, wodurch Daten im Speicher beschädigt werden.)
Mechanismen können bereitgestellt sein, um BS-Daten über das aktuelle „obere Ende des Stapels“ zu schützen. Ein Beispiel könnte ein Konfigurationsregister (oder einen anderen Mechanismus) definieren, in dem das BS die Datenmenge (z. B. gemessen in Bytes) spezifizieren kann, die es oberhalb des aktuellen Stapels (z. B. Stapel 119) schützen möchte.
Wenn die Ereignislieferung den Stapel nicht wechselt (z. B. weil die Ereignisstapelebene die aktuelle Stapelebene nicht überschreitet), passt die CPU (oder der Kern davon) zuerst den aktuellen Stapelzeiger um die BS-spezifizierte Größe des geschützten Bereichs an. Erst nachdem der Stapelzeiger angepasst wurde, speichert die CPU (oder der Kern davon) Informationen für das Ereignis, das geliefert wird. Durch derartiges Anpassen des Stapelzeigers stellt die CPU (oder der Kern davon) sicher, dass jegliche existierenden Daten in dem geschützten Bereich nicht überschrieben werden.
Da es Änderungen an dem Stapelzeiger gibt (z. B. Laden von diesem aus der BS-Konfiguration, bei einer Änderung der Stapelebene oder durch Anpassen derselben, wie im vorherigen Absatz beschrieben), wird erwartet, dass der aktuelle Stapelzeiger in dem Rückkehrzustand enthalten sein wird, der durch Ereignislieferung gespeichert wird. Falls dies geschieht, können Rückkehrbefehle definiert werden, um den alten Stapelzeiger ordnungsgemäß wiederherzustellen.
6 veranschaulicht Elemente einer BS-Konfiguration. Dieses Beispiel unterstützt vier Stapelebenen. Die rechte Seite der Figur veranschaulicht vier separate Speicherbereiche, einen für jeden Stapel, der durch das BS unterstützt wird. Beispielhaft sind ein erster Stapel 0 602, ein zweiter Stapel 1 604, ein dritter Stapel 2 606 und ein vierter Stapel 3 608 bereitgestellt. Das Beispiel unterstützt vier Konfigurationsregister (als OS_RSP0 603, OS_RSP1 605, OS_RSP2 607 und OS_RSP3 609 bezeichnet), die jeweils zu der Basis eines der vier Stapel 602, 604, 606, 608 zeigen.
Es kann ein zusätzliches Konfigurationsregister (z. B. IA32_FRED_ STKLVLS-MSR 610) geben. Dieses 64-Bit-Register 610 enthält ein 2-Bit-Feld für jeden von 32 Ausnahmevektoren. In der Veranschaulichung wird der Doppelfehlerausnahme (DF, Vektor 8) Stapelebene 2, der Seitenfehlerausnahme (PF, Vektor 14) Stapelebene 0 und der Maschinenprüfausnahme (MC, Vektor 18) Stapelebene 3 zugewiesen.
Wenn eine dieser Ausnahmen auftritt, bestimmt die CPU (oder der Kern davon) die Ereignisstapelebene durch Verwenden des Ausnahmevektors, um einen 2-Bit-Wert (0-3) aus dem Register IA32_FRED_STKLVLS 610 auszuwählen. Die Lieferung des Ereignisses verwendet dann diese Ereignisstapelebene kombiniert mit der aktuellen Stapelebene (nicht dargestellt), um zu bestimmen, welcher Stapel (z. B. erster Stapel 0 602, zweiter Stapel 1 604, dritter Stapel 2 606 oder vierter Stapel 3 608) verwendet wird, um das Ereignis zu liefern. Zum Beispiel stellt für eine Ausnahme mit dem Vektor v (oder für einen speziellen Interrupt, dem die ISA einen festen Vektor zuweisen kann, der für keine Ausnahme verwendet wird), die auftritt, während CPL = 0, eine FRED-Ereignislieferung sicher, dass die neue Stapelebene mindestens den Wert IA32_FRED STKLVLS[2v+1: 2v] hat.
Wenn FRED-Übergänge aktiviert sind (z. B. CR4.FRED = IA32_EFER.LMA = 1), wird Interrupt (z. B. IDT) -Ereignislieferung von Ausnahmen und Interrupts durch FRED-Ereignislieferung ersetzt. Zusätzlich dazu können Legacy-Operationen bestimmter Befehle (z. B. SYSCALL und SYSENTER) durch FRED-Ereignislieferung ersetzt werden. Es ist anzumerken, dass diese Änderungen die Behandlung von Ausnahmen und Unterbrechungen des Prozessors vor der Ereignislieferung nicht beeinflussen. Zum Beispiel tritt eine beliebige Bestimmung, dass ein Ereignis einen Austritt einer virtuellen Maschine (VM) verursacht oder in einen Doppelfehler umgewandelt wird, normal auf.
Eine Funktionalität der FRED-Ereignislieferung besteht darin, einen neuen Kontext, den des Ereignishandlers in Ring 0, einzurichten, während der alte Kontext (wie etwa der Kontext, wenn das Ereignis stattgefunden hat) für eine anschließende Rückkehr gespeichert wird. Manche Teile des neuen Kontexts weisen feste Werte auf, während andere von dem alten Kontext, der Art des gelieferten Ereignisses und der Softwarekonfiguration abhängen.
7 veranschaulicht ein Beispiel eines Verfahrens für FRED-Ereignislieferung. Dieses Verfahren ist zum Beispiel durch die FRED-Logik 130 durchzuführen. Bei 701 erfolgt eine Bestimmung, ob eine FRED-Ereignislieferung konfiguriert ist. Ist CR4.FRED = IA32_EFER.LMA =1? Falls nein („NElN“ bei 701), dann wird bei 703 eine Nicht-FRED-Ereignislieferung verwendet.
Wenn FRED konfiguriert ist („JA“ bei 701), wird bei 705 eine Bestimmung eines Zustands eines neuen Kontexts vorgenommen. Ein Kontext eines Ereignishandlers, der durch FRED-Ereignislieferung aufgerufen wird, beinhaltet ein oder mehrere Segmentregister (z. B. CS und SS), einen Befehlszeiger (z. B. RIP), ein Flag-Register (z. B. EFLAGS, RFLAGS), den Stapelzeiger (RSP) und die Basisadresse eines Segments (z. B. GS.base). Der Kontext beinhaltet auch den Schattenstapelzeiger (SSP), falls Supervisor-Schattenstapel aktiviert sind.
Die FRED-Ereignislieferung stellt diesen Kontext her, indem diese Register bei Bedarf geladen werden. Die in RIP, RFLAGS, RSP und SSP zu ladenden Werte hängen von dem alten Kontext, der Art des gelieferten Ereignisses und der Softwarekonfiguration ab.
Eine FRED-Ereignislieferung verwendet zwei Eintrittspunkte in Abhängigkeit von der CPL zu der Zeit, zu der das Ereignis aufgetreten ist. Dies ermöglicht es einem Ereignishandler, den entsprechenden Rückkehrbefehl (z. B. ERETU oder ERETS) zu identifizieren. Insbesondere ist der neue RIP-Wert, den die FRED-Ereignislieferung feststellt, (IA32_FRED_CONFIG &~FFFH) für Ereignisse, die auftreten, während CPL = 3, und (IA32_FRED_CONFIG &~FFFH) + 26 für Ereignisse, die auftreten, während CPL = 0.
Ein neuer RFLAGS-Wert, der durch FRED-Ereignislieferung eingerichtet wird, kann der alte Wert mit Bits sein, die an Positionen gelöscht sind, die im IA32_FMASK-MSR und an bestimmten festen Positionen, die durch die ISA definiert sind, gesetzt sind (letzteres stellt sicher, dass spezifische Bits, z. B. RFLAGS.RF und RFLAGS.TF, null sein werden).
FRED-Übergänge können mehrere (z. B. 4) unterschiedliche Stapel zur Verwendung in Ring 0 unterstützen. Der gegenwärtig verwendete Stapel wird mit einem 2-Bit-Wert identifiziert, der die aktuelle Stapelebene (CSL) genannt wird.
FRED-Ereignislieferung bestimmt die Stapelebene des Ereignisses und verwendet diese dann, um zu bestimmen, ob sich die CSL ändern sollte. Die Stapelebene eines Ereignisses basiert auf der CPL, dem Wesen und Typ des Ereignisses, dem Vektor eines Ereignisses (für manche Ereignistypen) und/oder MSRs, die durch Systemsoftware konfiguriert werden: 1) falls das Ereignis, das während CPL = 3 aufgetreten ist, keine verschachtelte Ausnahme war, die während der Ereignislieferung angetroffen wurde, und kein Doppelfehler (#DF) war, ist die Stapelebene des Ereignisses 0; 2) falls das Ereignis, das während CPL = 0 aufgetreten ist, eine verschachtelte Ausnahme war, die während der Ereignislieferung angetroffen wurde, oder ein #DF war, gilt mindestens einer der folgenden Punkte: falls das Ereignis ein maskierbarer Interrupt ist, ist die Stapelebene des Ereignisses die Stapelebene für Interrupts (in IA32_FRED_CONFIG[10:9]); falls das Ereignis eine Ausnahme oder ein spezieller Interrupt mit einem Vektor ist, der durch die ISA (z. B. NMI) festgelegt wird, ist die Stapelebene des Ereignisses der Wert IA32_FRED STKLVLS[2v+1:2v], wobei v der Vektor des Ereignisses ist (im Bereich von 0 - 31); und die Stapelebene aller anderen Ereignisse ist 0.
Falls das Ereignis aufgetreten ist, während CPL = 3, ist die neue Stapelebene die Stapelebene des Ereignisses; andernfalls ist die neue Stapelebene das Maximum der CSL und der Stapelebene des Ereignisses.
Nach der Bestimmung der neuen Stapelebene wird ein neuer RSP-Wert wie folgt identifiziert: 1) Falls sich entweder die CPL oder die Stapelebene ändert, wird der neue RSP-Wert der des FRED_RSP-MSR sein, das der neuen Stapelebene entspricht; und 2) andernfalls wird der neue RSP-Wert der aktuelle RSP-Wert sein, der um die BS-spezifizierte Größe des geschützten Bereichs auf dem Stapel dekrementiert wird. In beiden Fällen kann der neue RSP-Wert dann auf eine 64-Byte-Grenze ausgerichtet werden.
Falls Supervisor-Schattenstapel aktiviert sind, kann ein neuer SSP-Wert wie folgt bestimmt werden: falls sich entweder die CPL oder die Stapelebene ändert, wird der neue SSP-Wert der des FRED_SSP-MSR sein, das der neuen Stapelebene entspricht. Der neue SSP-Wert kann Folgendem ausgesetzt sein: ein allgemeiner Schutzfehler (#GP) tritt auf, wenn die neue Stapelebene 0 ist und IA32_PL0_SSP[2] = 1 ist. Da Bit 0 jedes FRED_SSP-MSR das verifizierte Bit des MSR ist, wird dieses Bit nicht in SSP geladen, und stattdessen ist Bit 0 des neuen SSP-Werts immer null. Andernfalls wird der neue SSP-Wert der aktuelle SSP-Wert sein, der um die BS-spezifizierte Größe des geschützten Bereichs auf dem Stapel dekrementiert wird.
Bei 707 wird zumindest der alte Zustand auf einem oder mehreren Stapeln gespeichert. FRED-Ereignislieferung kann Informationen über den alten Kontext auf dem Stapel des Ereignishandlers speichern. Die oberen 40 Bytes des Stapels des Ereignishandlers können den Kontext in demselben Format wie jenem im Anschluss an die IDT-Ereignislieferung enthalten. FRED-Ereignislieferung kann auch Informationen über das Ereignis, das geliefert wird, sowie Hilfsinformationen speichern, die einen nachfolgenden Rückkehrbefehl leiten werden. Wenn Supervisor-Schattenstapel aktiviert sind, kann FRED-Ereignislieferung auch Informationen über den Schattenstapel des Ereignishandlers speichern. Es ist anzumerken, dass Speicherzugriffe, die zum Speichern von Informationen über die Stapel verwendet werden, mit Supervisorberechtigung durchgeführt werden können.
FRED-Ereignislieferung kann 64 Bytes Informationen auf dem regulären Stapel speichern. Zuvor wird der RSP mit dem neuen bestimmten Wert geladen, der oben erörtert wurde, und dieser Wert wird verwendet, um den neuen Stapel zu referenzieren. Es ist anzumerken, dass, falls eine FRED-Ereignislieferung eine verschachtelte Ausnahme oder einen VM-Austritt nach diesem Punkt nach sich zieht, die verschachtelte Ausnahme oder der VM-Austritt den Wert wiederherstellt, der im RSP lag, bevor das erste Ereignis aufgetreten ist, bevor die CPU diese verschachtelte Ausnahme oder diesen VM-Austritt liefert.
Eines oder mehrere der Folgenden werden auf den Stapel geschoben (z. B. erster Stapel 0602, zweiter Stapel 1604, dritter Stapel 2 606 oder vierter Stapel 3 608): die ersten 8 geschobenen Bytes (Bytes 63:56 des 64-Byte-Stapelrahmens) sind immer null; die nächsten 8 geschobenen Bytes (Bytes 55:48) enthalten Ereignisdaten und sind wie folgt definiert: 1) falls das Ereignis, das geliefert wird, ein Seitenfehler (#PF) ist, ist der geschobene Wert jener, den der Seitenfehler in ein Steuerregister wie etwa CR2 lädt (allgemein ist dies die fehlerhafte lineare Adresse); 2) falls das Ereignis, das geliefert wird, eine Debug-Ausnahme ist, identifizieren Ereignisdaten die Natur der Debug-Ausnahme (zum Beispiel Bits 3:0 - wenn gesetzt, gibt jedes dieser Bits an, dass die entsprechende Unterbrechungspunktbedingung erfüllt wurde). Jedes dieser Bits kann gesetzt werden, selbst wenn sein entsprechendes Freigabebit in DR7 nicht gesetzt ist; Bits 10:4 sind gegenwärtig nicht definiert; Bit 11 gibt an, dass die Ursache der Debug-Ausnahme die Erfassung einer Bussperre war; Bit 12 ist gegenwärtig nicht definiert; Bit 13 i Bit gibt an, dass die Ursache der Debug-Ausnahme „Debug-Registerzugriff detektiert“ war; Bit 14 gibt an, dass die Ursache der Debug-Ausnahme die Ausführung eines einzelnen Befehls war; Bit 15 ist momentan nicht definiert; Bit 16 gibt an, dass eine Debug-Ausnahme (#DB) oder eine Unterbrechungspunktausnahme (#BP) innerhalb einer RTM-Region aufgetreten ist, während fortgeschrittenes Debugging transaktionaler Regionen aktiviert wurde; Bits 63:17 sind gegenwärtig nicht definiert; 3) falls das gelieferte Ereignis eine Vorrichtung-nicht-verfügbar-Ausnahme ist, ist der geschobene Wert jener, den die Vorrichtung-nicht-verfügbar-Ausnahme in einem erweiterten Merkmalsdeaktivierungs- bzw. XFD-Fehler-MSR (z. B. IA32_XFD_ERR-MSR) einrichtet, das geladen wird, wenn eine erweiterte Merkmalsdeaktivierung einen Vorrichtung-nicht-verfügbar-Fehler verursacht; und 4) für ein beliebiges anderes Ereignis ist der geschobene Wert null.
Die nächsten 8 geschobenen Bytes (Bytes 47:40) enthalten Ereignisinformationen. Diese 64 Informationsbits weisen in einigen Beispielen das folgende Format auf: Bits 15:0 enthalten den Fehlercode (nur für bestimmte Ausnahmen definiert; Null, wenn es keine gibt); Bits 31:16 werden nicht verwendet und werden als Null gespeichert; Bits 39:32 enthalten den Vektor des Ereignisses (in einigen Beispielen für einen Systemaufruf oder Systemeingabebefehl, die eine FRED-Ereignislieferung, aber keine IDT-Ereignislieferung verwenden, werden Vektoren 1 bzw. 2 verwendet); Bits 47:40 werden nicht verwendet und werden als Null gespeichert; Bits 51:48 codieren den Ereignistyp wie folgt: 0 = externer Interrupt; 2 = nicht-maskierbarer Interrupt; 3 = Hardwareausnahme (z. B. Seitenfehler); 4 = Software-Interrupt (INT n); 5 = berechtigte Softwareausnahme (INT1); 6 = Softwareausnahme (INT3 oder INTO); und 7 = anderes Ereignis (verwendet zum Beispiel SYSCALL und SYSENTER); Bits 55:52 werden nicht verwendet und als Null gespeichert; Bit 56 wird auf 1 gesetzt, um anzugeben, dass das Ereignis bei der Enklaven-Ausführung vorlag (insbesondere wird es in einem der folgenden Fälle gesetzt: das Ereignis tritt auf, während sich der logische Prozessor im Enklaven-Modus befand, das Ereignis wurde durch den VM-Eintritt injiziert und das Gastunterbrechbarkeitszustandsfeld in der VMCS gibt eine „Enklaven-Unterbrechung“ an (Bit 4 des Feldes ist 1), das Ereignis war eine Debug-Ausnahme, die im Anschluss an einen VM-Eintritt ausstehend war, für den Gastunterbrechbarkeit eine „Enklaven-Unterbrechung“ angibt, das Ereignis war eine Debug-Ausnahme, die nach einer Ausführung eines RSM, für den SMRAM eine „Enklaven-Unterbrechung“ angibt, ausstehend war, das Ereignis war eine Ausnahme, die während der Lieferung eines der obigen Ereignisse angetroffen wurde, andernfalls wird das Bit auf 0 gelöscht; Bit 57 wird auf 1 gesetzt, falls sich der logische Prozessor im 64-Bit-Modus befand, als das Ereignis aufgetreten ist (0 gibt einen Ereignisvorfall an); Bits 61:58 enthalten die Länge des Befehls, der das Ereignis verursacht, wenn der Ereignistyp Software-Interrupt (INT n), berechtigte Softwareausnahme (INT1), Softwareausnahme (INT3 oder IN) oder ein anderes Ereignis (wenn für SYSCALL oder SYSENTER verwendet) ist; und Bits 63:62 werden nicht verwendet und als Null gespeichert.
Die verbleibenden 40 geschobenen Bytes (Bytes 39:0) sind der Rückkehrzustand und weisen im Allgemeinen das gleiche Format wie das auf, das zum Beispiel von der IDT-Ereignislieferung verwendet wird. Im Folgenden wird das Format des Rückkehrzustands auf dem Stapel von unten (höchste Adresse) nach oben angegeben: 1) SS-Selektor des unterbrochenen Kontexts (untere 16 Bits eines 64-Bit-Feldes), wobei Bits 63:16 dieses Feldes auf Null gelöscht werden; 2) RSP des unterbrochenen Kontexts (64 Bits); 3) RFLAGS des unterbrochenen Kontexts (64 Bits), wobei Bit 16 des RFLAGS-Feldes (das dem RF-Bit entspricht) als 1 gespeichert wird, wenn Ereignisse geliefert werden, die das gleiche für IDT-Ereignislieferung bewirken (dies sind Fehler, die keine Befehlsunterbrechungspunkte sind) sowie jegliche Traps oder Interrupts, die nach teilweiser Ausführung eines Befehls geliefert werden (z. B. zwischen Iterationen eines Befehls mit Zeichenfolge mit REP-Präfix). Die Lieferung anderer Ereignisse speichert in Bit 16 den Wert, den RFLAGS.RF zum Zeitpunkt des Auftretens des Ereignisses hatte; 4) CS-Selektor des unterbrochenen Kontexts (untere 16 Bits eines 64-Bit-Feldes). FRED-Ereignislieferung speichert zusätzliche Informationen im oberen Teil dieses Feldes (diese Informationen leiten die Ausführung der FRED-Rückkehrbefehle an): Bit 16 wird auf 1 gesetzt, falls das gelieferte Ereignis ein nicht-maskierbarer Interrupt (NMI) ist, und wird ansonsten auf 0 gelöscht, Bit 17 wird auf 1 gesetzt für FRED-Ereignislieferung von SYSCALL, SYSENTER oder INT n (für einen beliebigen Wert von n) und wird ansonsten auf 0 gelöscht, Bit 18 wird für eine FRED-Ereignislieferung einer Ausnahme auf 1 gesetzt, falls eine Interruptblockierung durch STI zu dem Zeitpunkt, zu dem die Ausnahme aufgetreten ist, wirksam war, und wird andernfalls auf 0 gelöscht, Bits 23:19 werden auf Null gelöscht, Bits 25:24: für eine Lieferung von Ereignissen, die auftreten, während CPL = 0, melden diese Bits die aktuelle Stapelebene (CSL) zu dem Zeitpunkt, zu dem das Ereignis aufgetreten ist, und für die Lieferung von Ereignissen, die auftreten, während CPL = 3, werden diese Bits auf 0 gelöscht, Bits 63:26 werden auf Null gelöscht; 5) RIP des unterbrochenen Kontexts (64 Bits). Falls der Ereignistyp Software-Interrupt (INT n), berechtigte Softwareausnahme (INT1), Softwareausnahme (INT3 oder INTO) oder ein anderes Ereignis (wenn für SYSCALL oder SYSENTER verwendet) ist; referenziert der gespeicherte RIP-Wert den Befehl nach dem, der bewirkt hat, dass das Ereignis geliefert wird. (Wenn die Lieferung eines solchen Ereignisses auf eine Ausnahme trifft, referenziert der durch die Lieferung der Ausnahme gespeicherte RIP-Wert den Befehl, der das ursprüngliche Ereignis verursacht hat.)
Informationen werden auf dem Schattenstapel (z. B. Schattenstapel 120) gespeichert, wenn Supervisor-Schattenstapel aktiviert sind. Wie FRED-Ereignislieferung mit dem Schattenstapel interagiert, hängt davon ab, ob ein neuer Wert in SSP geladen wird. Falls sich entweder die CPL oder die Stapelebene ändert, wird der neue SSP-Wert aus dem FRED_SSP-MSR geladen, das der neuen Stapelebene entspricht. In diesem Fall wird der neue Schattenstapel auf ein Token überprüft. Diese Tokenverwaltung kann sich von dem unterscheiden, was für die IDT-Ereignislieferung erfolgt. FRED-Tokenverwaltung hängt davon ab, ob das FRED_SSP-MSR bereits verifiziert wurde (angegeben durch Bit 0 des MSR, das gesetzt wird). Falls das MSR nicht verifiziert wurde, markiert FRED-Ereignislieferung die Basis des neuen Schattenstapels mit einem belegten Token wie folgt. Sie liest 8 Bytes aus der Adresse in SSP (die gerade aus dem MSR geladen wurde), wodurch die gelesene Adresse gesperrt wird. Wenn der gelesene Wert gleich dem SSP-Wert ist (der ein gültiges freies Token angibt), wird die Sperre freigegeben, und der Wert wird zurückgeschrieben, wobei aber Bit 0 gesetzt wird (was angibt, dass das Token nun belegt ist). Derselbe Wert wird in das MSR geladen. Dies setzt Bit 0 des MSR, was angibt, dass es verifiziert wurde. Andernfalls wird die Sperre freigegeben, der Wert wird unverändert zurückgeschrieben und ein allgemeiner Schutzfehler tritt auf. Falls das MSR bereits verifiziert wurde, wird eine Bestätigung, dass die Basis des neuen Schattenstapels ein gültiges belegtes Token aufweist, durch Lesen von 8 Bytes aus der Adresse in SSP durchgeführt. Falls der gelesene Wert nicht gleich dem SSP-Wert ist, wobei Bit 0 gesetzt ist (was ein belegtes Token angibt), tritt ein allgemeiner Schutzfehler auf.
In beiden Fällen (CPL oder Stapelebenenänderung) wird der SSP mit dem neuen Wert geladen. Es ist anzumerken, dass, falls FRED-Ereignislieferung anschließend eine verschachtelte Ausnahme oder einen VM-Austritt verursacht, der alte SSP-Wert implizit wiederhergestellt wird.
Falls sich weder die CPL noch die Stapelebene ändern, wird SSP nicht aus einem FRED_SSP-MSR geladen. Falls der aktuelle SSP-Wert nicht 8-Byte-ausgerichtet ist, werden stattdessen 4 Bytes Nullen auf den Schattenstapel geschoben, was zu einem SSP-Wert führt, der 8-Byte-ausgerichtet ist.
Falls das Ereignis, das geliefert wird, aufgetreten ist, während CPL = 0, werden der alte CS-Selektor, der alte lineare Befehlszeiger und der alte SSP auf den Schattenstapel geschoben. Falls SSP aus einem FRED_SSP-MSR geladen worden wäre, erfolgen diese Schiebevorgänge nach der oben umrissenen Tokenverwaltung auf den neuen Schattenstapel; wenn nicht, wird der existierende Schattenstapel (z. B. Schattenstapel 120) verwendet. Jeder dieser drei Werte wird in ein separates 8-Byte-Feld auf dem Schattenstapel (z. B. Schattenstapel 120) geschoben.
Nach dem Speichern des alten Kontexts und anderer Informationen werden Register geladen, um den neuen Kontext bei 709 einzurichten. Für Ereignisse, die auftreten, während CPL = 3, können die CS-, SS- und GS-Segmente sowie das IA32_KERNEL_GS_BASE-MSR aktualisiert werden. Für CS ist der Selektor auf IA32_STEM[47:32] AND FFFCH gesetzt (erzwingt CS.RPL auf 0), die Basisadresse wird auf 0 gesetzt. Die Begrenzung wird auf FFFFFH gesetzt, und das G-Bit wird auf 1 gesetzt, der Typ wird auf 11 gesetzt (Code mit Ausführungs-/Lesezugriff) und das S-Bit wird auf 1 gesetzt, und die DPL wird auf 0 gesetzt, die P- und L-Bits werden jeweils auf 1 gesetzt, und das D-Bit wird auf 0 gesetzt. Für SS wird der Selektor auf IA32_STEM[47:32] + 8 gesetzt, die Basisadresse wird auf 0 gesetzt. Die Begrenzung wird auf FFFFFH gesetzt, und das G-Bit wird auf 1 gesetzt, der Typ wird auf 3 gesetzt (Daten mit Lese-/Schreibzugriff), und das S-Bit wird auf 1 gesetzt, und die DPL wird auf 0 gesetzt und die P- und B-Bits werden jeweils auf 1 gesetzt. Für GS werden der Wert der GS-Basisadresse und der im IA32_KERNEL_GS_BASE-MSR gespeicherte Wert vertauscht.
Für Ereignisse, die auftreten, während CPL = 0, gibt es keine Modifikationen an CS, SS oder GS. Nach dem Aktualisieren der Segmentregister (falls erfolgt) werden RIP, RFLAGS und CSL mit den zuvor bestimmten Werten aktualisiert.
Falls das Ereignis aufgetreten ist, während CPL = 3, und Benutzerschattenstapel aktiviert sind, wird das IA32_PL3_SSP-MSR mit dem alten Wert von SSP geladen. Der in das MSR geladene Wert kann so angepasst werden, dass die Bits 63:N den Wert von Bit N-1 erhalten, wobei N die maximale Linearadressbreite der CPU ist.
Falls indirekte Supervisor-Verzweigungsverfolgung aktiviert ist, kann das IA32_S_CET-MSR aktualisiert werden, um den TRACKER-Wert auf WAIT_FOR_ENDBRANCH zu setzen und das SUPPRESS-Bit auf 0 zu löschen.
FRED-Ereignislieferung eines nicht-maskierbaren Interrupts (NMI) blockiert NMIs.
Eine Debug-Trap (Einzelschritt-Trap oder Daten- oder E/A-Unterbrechungspunkt) kann zu dem Zeitpunkt, zu dem ein anderes Ereignis geliefert wird, ausstehend sein. Eine solche Trap kann ausstehend gewesen sein, falls der vorherige Befehl MOV SS oder POP SS war, da diese Befehle zum Beispiel Debug-Traps an der folgenden Befehlsgrenze blockieren.
Debug-Traps, die zu dem Zeitpunkt, zu dem das ursprüngliche Ereignis aufgetreten ist, möglicherweise ausstehend waren, werden verworfen, unabhängig davon, ob das Ereignis geliefert wird. Beispielsweise werden beliebige ausstehende Daten- oder E/A-Unterbrechungspunkte (oder Einzelschritt-Traps) gelöscht, wenn INT n, INT3, INTO, SYSCALL oder SYSENTER unter Verwendung von FRED-Ereignislieferung geliefert werden.
8(A)-(E) veranschaulichen beispielhaften Pseudocode für FRED-Ereignislieferung.
Wie oben angemerkt, unterstützt FRED zwei neue Rückkehrbefehle - ERETS (Ereignisrückkehr zum Supervisor) und ERETU (Ereignisrückkehr zum Benutzer). Einzelheiten über die Operationen dieser beiden Befehle werden nachfolgend besprochen.
9 veranschaulicht ein Beispiel für die Behandlung eines ERETS-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 9 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 10, 12, 13, 15, 16, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 901 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode (auch als Operationscode, Befehlsmaschinencode, Befehlscode, Befehlssilbe bezeichnet) abgerufen, um eine Ereignisrückkehr zum Supervisor anzuzeigen, wenn die aktuelle Berechtigungsebene 0 ist. Der Opcode ist f2 0f 01 ca.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 902 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Alternativ dazu wird diese Übersetzung durch eine Softwareschicht, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer, durchgeführt.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 903 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden. Es ist anzumerken, dass ein Decodierer zum ordnungsgemäßen Decodieren dieses Befehls zuvor nicht vorhanden war.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 905 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 907 ausgeführt, um von einem Ereignishandler zurückzukehren, während er in Ring 0 bleibt, wodurch der Rückkehrkontext erstellt wird, der vor der FRED-Ereignislieferung wirksam war. Es ist anzumerken, dass, weil diese Ausführung innerhalb eines Supervisor-Kontexts verbleibt, die Ausführung die Segmentregister (z. B. CS, SS oder GS) nicht modifiziert. Der Rückkehrkontext kann nun durch nachfolgende Befehle verwendet werden.
Die Ausführung des Befehls (und/oder der Operandenabruf) beginnt mit dem Laden und Prüfen des Rückkehrkontexts aus dem Stapel. Wenn Supervisor-Schattenstapel aktiviert sind, prüft die Ausführung dann den Schattenstapel (z. B. Schattenstapel 120), um die Gültigkeit dieses Steuerflusstransfers zu bestätigen. Schließlich wird der Rückkehrkontext durch Laden der entsprechenden Register eingerichtet.
Ein Ergebnis des ausgeführten Befehls wird bei 909 übergeben.
10 veranschaulicht eine beispielhafte Ausführung eines ERETS-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 10 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 12, 13, 15, 16, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1001 kann überprüft werden, ob FRED korrekt konfiguriert wurde. Wenn FRED nicht korrekt konfiguriert wurde („NEIN“ bei 1001), dann wird bei 1003 ein Fehler (wie etwa ein allgemeiner Schutzfehler) verursacht.
Bei 1005, wenn FRED ordnungsgemäß konfiguriert ist („JA“ in 1001) (oder in Beispielen, in denen diese Prüfung nicht vorgenommen wird), wird ein Rückkehrkontext aus dem regulären Stapel abgerufen (wie durch den RSP referenziert), der durch eine FRED-Ereignislieferung gespeichert und geprüft wurde.

Der geprüfte Kontext wird gehalten, um den Registerzustand zu aktualisieren, wenn der Befehl abgeschlossen ist. Die folgende Tabelle zeigt, was abgerufen wird und welche Überprüfung durchgeführt werden kann.

Abgerufene Position	Überprüfung(en)	Andere Aktion(en)
RIP des Rückkehrkontexts (64-Bit-Wert)	Ist der Wert kanonisch relativ zum aktuellen Paging-Modus	GP-Fehler, falls die Prüfung fehlschlägt
CS-Selektor des Rückkehrkontexts (z. B. die unteren 16 Bits eines CS-64-Bit-Feldes)	Die Bits 23:19 und 63:26 dieses Feldes müssen Null sein.	GP-Fehler, falls die Prüfung fehlschlägt;
		Einrichten einer neuen Stapelebene als die minimale CSL und des Wertes der Bits 25:24 des CS-Feldes;
		Bits 18:16 dieses Feldes bestimmen, wie ERETS bestimmte Ereignisse verwaltet;
		Bits 15:0 werden nicht zum Laden von CS verwendet.
RFLAGS des Rückkehrkontexts (64 Bits)	Bit 1 dieses Feldes muss 1 sein;	GP-Fehler, falls die Prüfung fehlschlägt
RFLAGS des Rückkehrkontexts (64 Bits)	Bit 3, Bit 5, Bits 13:12 (IOPL), Bit 15, Bit 17 (VM) und Bits 63:22 des Feldes müssen 0 sein.	GP-Fehler, falls die Prüfung fehlschlägt
RSP des Rückkehrkontexts (z. B. 64 Bits)
SS-Selektor des unterbrochenen Kontexts (z. B. untere 16 Bits eines 64-Bit-Feldes).	Die Bits 63:16 dieses Feldes müssen Null sein.	GP-Fehler, falls die Prüfung fehlschlägt

Bei 1007 kann der Schattenstapel (z. B. Schattenstapel 120) überprüft werden. Bei 1009 erfolgt eine Bestimmung, ob ein Schattenstapel verwendet wird, und seines Status. Ob beispielsweise ein Supervisor-Schattenstapel aktiviert ist und wenn ja, ändert sich die Stapelebene.

Falls Supervisor-Schattenstapel aktiviert sind, werden Werte aus dem Schattenstapel (bezeichnet durch SSP), die durch FRED-Ereignislieferung gespeichert wurden, bei 1011 abgerufen. Die Prüfungen dieser Werte können Folgendes beinhalten:

Abgerufene Position	Überprüfung(en)	Andere Aktion(en)
SSP des Rückkehrkontexts (64-Bit-Wert)	1) Ist dieser Wert 4-Byte-ausgerichtet und sind die Bits 1:0 auf Null gesetzt;	Steuerungsschutzausnahme, falls Prüfung 1 fehlschlägt;
		Ein allgemeiner Schutzfehler, falls Prüfung 2 fehlschlägt
	2) Ist dieser Wert kanonisch relativ zum aktuellen Paging-Modus	Ein allgemeiner Schutzfehler, falls Prüfung 2 fehlschlägt
Der lineare Befehlszeiger des Rückkehrkontexts (64-Bit-Wert)	Dieser Wert muss gleich dem RIP des Rückkehrkontexts sein, der aus dem regulären Stapel abgerufen wurde.	Steuerungsschutzausnahme, falls die Prüfung fehlschlägt
CS des Rückkehrkontexts (64-Bit-Wert).	Dieser Wert muss gleich dem aktuellen CS-Selektor sein (Bits 63:16 des Werts müssen 0 sein)	Steuerungsschutzausnahme, falls die Prüfung fehlschlägt

Falls Supervisor-Schattenstapel aktiviert sind und sich die Stapelebene ändert (basierend auf dem Wert, der aus dem regulären Stapel abgerufen wird; siehe oben), hängt eine anschließende Operation von Befehlen von den Werten des FRED_SSP-MSR für die CSL (nicht die neue Stapelebene) und des SSP ab. Bei 1015 wird das FRED_SSP-MSR verifiziert, das FRED_SSP-MSR wird aktualisiert, und/oder eine Sperre wird freigegeben. (Das heißt, falls der Befehl mit CSL = 2 ausgeführt wird und zu Stapelebene 1 zurückkehrt, ist das relevante MSR IA32_FRED_SSP2.) Die Prüfungen dieser Werte können Folgendes beinhalten:

1) Falls Bit 0 des FRED_SSP-MSR gesetzt ist und die verbleibenden Bits gleich den entsprechenden Bits im SSP sind, wird das MSR verifiziert und keine andere Aktion durchgeführt;
2) Falls der Wert des FRED_SSP-MSR gleich dem des SSP ist (was impliziert, dass das FRED_SSP-MSR-Bit 0 gelöscht ist), werden 8 Bytes von der Adresse in dem SSP gelesen. Falls der gelesene Wert gleich dem SSP-Wert ist, wobei Bit 0 auf 1 gesetzt ist (und somit ein gesperrtes Token ist), wird dieser Wert in das FRED_SSP-MSR geladen. Dies setzt Bit 0 des FRED_SSP-MSR auf 1, was angibt, dass das FRED_SSP-MSR nun verifiziert ist. (Falls irgendein anderer Wert gelesen wird, ist das MSR nicht modifiziert.)
3) Falls das FRED_SSP-MSR einen beliebigen anderen Wert aufweist, werden 8 Bytes von der Adresse im SSP gelesen, was das Lesen der Adresse sperrt. Falls der gelesene Wert gleich dem SSP-Wert ist, aber Bit 0 auf 1 gesetzt ist (was ein belegtes Token angibt), wird die Sperre freigegeben und der Wert von SSP wird zurückgeschrieben. Das löscht Bit 0 in dem Token, was angibt, dass es nun frei ist. (Das Token wird freigegeben, weil SSP nicht mit dem FRED_SSP-MSR übereinstimmt.) Falls irgendein anderer Wert gelesen wird, wird die Sperre freigegeben, und der gelesene Wert wird zurückgeschrieben. Unabhängig von dem gelesenen Wert wird das FRED_SSP-MSR nicht modifiziert.

Bei 1017 wird ein Rückkehrkontext eingerichtet. Dies kann eine oder mehrere Operationen beinhalten. Bei 1019 werden RIP, RFLAGS, RSP und CSL mit den Werten geladen, die früher aus dem regulären Stapel abgerufen wurden. Falls Supervisor-Schattenstapel aktiviert sind, wird SSP bei 1021 mit dem Wert geladen, der früher aus dem Schattenstapel abgerufen wurde. Nicht-maskierbare Interrupts (NMIs) können bei 1023 freigegeben werden, wenn Bit 16 des abgerufenen CS-Feldes (oberhalb des Selektors) 1 ist. Wenn Bit 17 des abgerufenen CS-Feldes 1 ist und die Ausführung zu RFLAGS.TF = 1 führen wird, kann eine Einzelschritt-Trap vom Abschluss von ERETS bei 1025 ausstehend sein. Wenn Bit 18 dieses Feldes 1 ist und die Ausführung zu RFLAGS.IF = 1 führen wird, kann eine Blockierung durch STI bei Abschluss des Befehls bei 1027 wirksam sein.
11(A)-(B) veranschaulichen beispielhaften Pseudocode für eine Ausführung von ERETS.
12 veranschaulicht ein Beispiel für die Behandlung eines ERETU-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 12 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 13, 15, 16, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1201 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode abgerufen, um dem Benutzer eine Ereignisrückkehr anzuzeigen, wenn die aktuelle Berechtigungsebene 3 ist. In diesem Beispiel beträgt der Opcode f3 0f 01 ca.
Der abgerufene einzelne Befehl einer ersten ISA wird bei 1202 in einen oder mehrere Befehle einer zweiten ISA übersetzt. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1203 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden. Es ist anzumerken, dass ein Decodierer zum ordnungsgemäßen Decodieren dieses Befehls zuvor nicht vorhanden war.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1205 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1207 ausgeführt, um von einem Ereignishandler zurückzukehren, während er in Ring 3 bleibt, und den Rückkehrkontext zu erstellen, der vor der FRED-Ereignislieferung wirksam war. Die Kontextänderung beinhaltet Aktualisierungen an den Segmentregistern CS, SS oder GS. Der Rückkehrkontext kann nun durch nachfolgende Befehle verwendet werden.
Die Ausführung des Befehls (und/oder der Operandenabruf) kann mit dem Laden und Prüfen des Rückkehrkontexts aus dem Stapel beginnen. Wenn Supervisor-Schattenstapel aktiviert sind, prüft die Ausführung dann den Schattenstapel (z. B. Schattenstapel 120), um die Gültigkeit dieses Steuerflusstransfers zu bestätigen. Schließlich wird der Rückkehrkontext durch Laden der entsprechenden Register eingerichtet.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1209 übergeben.
13 veranschaulicht ein Beispiel für eine Ausführung eines ERETU-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 13 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 15, 16, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1301 kann überprüft werden, ob FRED korrekt konfiguriert wurde. Wenn FRED nicht korrekt konfiguriert wurde („NEIN“ bei 1301), dann wird bei 1303 ein Fehler (wie etwa ein allgemeiner Schutzfehler) verursacht.
Bei 1304, wenn FRED ordnungsgemäß konfiguriert ist („JA“ in 1301) (oder in einem Beispiel, in dem diese Prüfung nicht vorgenommen wird), wird ein Rückkehrkontext aus dem regulären Stapel abgerufen (wie durch den RSP referenziert), der durch eine FRED-Ereignislieferung gespeichert und geprüft wurde. Der geprüfte Kontext wird gehalten, um den Registerzustand zu aktualisieren, wenn der Befehl abgeschlossen ist. Dieser Vorgang kann mehrere Untervorgänge aufweisen.

Bei 1305 wird der alte Kontext aus dem Stapel abgerufen. Bei 1307 wird zumindest ein Teil der abgerufenen Werte auf Korrektheit überprüft. Wenn es eine falsche Verwendung gibt („NEIN“ bei 1307), wird bei 1309 ein Fehler verursacht. Die folgende Tabelle zeigt gemäß einigen Beispielen, was abgerufen wird und welche Überprüfung durchgeführt wird.

Abgerufene Position	Überprüfung(en)	Andere Aktion(en)
RIP des Rückkehrkontexts (64-Bit-Wert)	Prüfen, sobald die CS-Konfiguration bestimmt ist
CS-Selektor des Rückkehrkontexts (z. B. die unteren 16 Bits eines CS-64-Bit-Feldes)	Bits 63:18 dieses Feldes müssen Null sein.	GP-Fehler, falls die Prüfung fehlschlägt;
		Bits 17:16 des Feldes bestimmen, wie die Befehlsausführung Ereignisse verwaltet.
RFLAGS des Rückkehrkontexts (64 Bits)	Bit 1 dieses Feldes muss 1 sein;	GP-Fehler, falls die Prüfung fehlschlägt
RFLAGS des Rückkehrkontexts (64 Bits)	Bit 3, Bit 5, Bits 13:12 (IOPL), Bit 15, Bit 17 (VM) und Bits 63:22 des Feldes müssen 0 sein.	GP-Fehler, falls die Prüfung fehlschlägt
RSP des Rückkehrkontexts (z. B. 64 Bits)
SS-Selektor des unterbrochenen Kontexts (z. B. untere 16 Bits eines 64-Bit-Feldes).	Die Bits 63:16 dieses Feldes müssen Null sein.	GP-Fehler, falls die Prüfung fehlschlägt

Nach dem Abrufen und Prüfen der obigen Felder, wie angemerkt („JA“ bei 1307), wird bei 1311 eine Bestimmung und Konfiguration der CS- und SS-Segmentregister vorgenommen. Diese Bestimmung und Konfiguration können in Abhängigkeit von den Werten für den abgerufenen CS-Selektor unterschiedlich sein. Wenn der Selektor, der für CS abgerufen wird, IA32_STAR[63:48] + 16 ist und der Selektor, der für SS abgerufen wird, IA32_STAR[63:48] + 8 (Dezimal) ist, werden CS und SS in einer Standardkonfiguration für Ring 3 im 64-Bit-Modus eingerichtet, so dass für CS der Selektor auf IA32_STAR[63:48] + 16 (Dezimal) gesetzt wird; die Basisadresse wird auf 0 gesetzt. Die Begrenzung wird auf FFFFFH gesetzt und das G-Bit wird auf 1 gesetzt, der Typ wird auf 11b gesetzt (Code mit Ausführungs-/Lesezugriff), und das S-Bit wird auf 1 gesetzt, die DPL wird auf 3 (Dezimal) gesetzt, die P- und L-Bits werden jeweils auf 1 gesetzt, und das D-Bit wird auf 0 gesetzt; und für SS wird der Selektor auf IA32_STEM[63:48] + 8 gesetzt, die Basisadresse wird auf 0 gesetzt. Die Begrenzung wird auf FFFFFH gesetzt, und das G-Bit wird auf 1 gesetzt, der Typ wird auf 3 gesetzt (Daten mit Lese-/Schreibzugriff), und das S-Bit wird auf 1 gesetzt, und die DPL wird auf 3 gesetzt und die P- und B-Bits werden jeweils auf 1 gesetzt.
Wenn der Selektor, der für CS abgerufen wird, IA32_STAR[63:48] ist und der Selektor, der für SS abgerufen wird, IA32_STAR[63:48] + 8 ist, können CS und SS in einer Standardkonfiguration für Ring 3 im Kompatibilitätsmodus eingerichtet werden, sodass für CS der Selektor auf IA32_STAR[63:48] gesetzt ist, kann die Basisadresse auf 0 gesetzt werden. Die Begrenzung wird auf FFFFFH gesetzt, und das G-Bit wird auf 1 gesetzt, der Typ wird auf 11 gesetzt (Code mit Ausführungs-/Lesezugriff), und das S-Bit wird auf 1 gesetzt, die DPL wird auf 3 gesetzt, das P-Bit wird auf 1 gesetzt, und die D- und L-Bits werden jeweils auf 0 gesetzt; und für SS wird der Selektor auf IA32_STEM[63:48] + 8 gesetzt, die Basisadresse wird auf 0 gesetzt. Die Begrenzung wird auf FFFFFH gesetzt, und das G-Bit wird auf 1 gesetzt, der Typ wird auf 3 gesetzt (Daten mit Lese-/Schreibzugriff), und das S-Bit wird auf 1 gesetzt, die DPL wird auf 3 gesetzt und die P- und B-Bits werden jeweils auf 1 gesetzt.
Wenn beispielsweise CS und SS unterschiedliche Werte aufweisen, die oben ausführlich beschrieben sind, werden die Selektoren, die für CS und SS abgerufen werden, verwendet, um Deskriptoren aus einer globalen Deskriptortabelle (GDT) (z. B. verwendet, um die Charakteristiken der verschiedenen Speichersegmente zu definieren, die während einer Programmausführung verwendet werden, einschließlich der Basisadresse, der Größe und der Zugriffsberechtigungen, wie Ausführbarkeit und Schreibbarkeit) und/oder der lokalen Deskriptortabelle (LDT) (z. B. eine Speichertabelle) zu laden, wie es durch eine Ausführung eines Interrupt-Rückkehrbefehls (wie etwa IRET) erfolgen würde. Es wird geprüft, ob Bits 1:0 des Selektors für CS abgerufen werden, und ein allgemeiner Schutzfehler wird vorgenommen, wenn diese Bits keine Rückkehr zu Ring 3 anzeigen. Ein allgemeiner Schutzfehler wird erzeugt, wenn die Rückkehr in den Kompatibilitätsmodus erfolgt und die RIP des Rückkehrkontexts jenseits der neuen CS-Segmentgrenze liegen würde. Falls, im Allgemeinen, das Bestimmen, ob die Konfiguration korrekt ist, zu „NEIN“ führt, wird bei 1314 ein Fehler verursacht.
Falls die Ausführung in den 64-Bit-Modus zurückkehrt (z. B. wobei der Deskriptor, der für CS geladen ist, das L-Bit setzt), tritt ein allgemeiner Schutzfehler auf, falls der RIP des Rückkehrkontexts relativ zu dem aktuellen Paging-Modus nicht kanonisch ist.
Wenn kein Fehler vorliegt („JA“ bei 1313), werden CS und SS bei 1315 mit den abgerufenen Werten (für die Selektoren) und mit den aus dem Speicher gelesenen Deskriptoren geladen.
Bei 1317 wird der Schattenstapel überprüft. Bei 1319 erfolgt eine Bestimmung, ob ein Schattenstapel verwendet wird, und seines Typs. Ist beispielsweise ein Supervisor-Schattenstapel aktiviert oder ein Benutzerschattenstapel? Wenn Benutzerschattenstapel aktiviert sind, ist der SSP des Rückkehrkontexts bei 1321 der Wert von IA32_PL3_SSP-MSR. Es wird angemerkt, dass, falls die Rückkehr in den Kompatibilitätsmodus erfolgt, ein allgemeiner Schutzfehler auftritt, falls IA32_PL3_SSP[63:32] nicht alle Null sind, und falls die Rückkehr in den 64-Bit-Modus erfolgt, ein allgemeiner Schutz auftritt, falls der Wert von IA32_PL3_SSP relativ zu dem aktuellen Paging-Modus nicht kanonisch ist.
Wenn Supervisor-Schattenstapel aktiviert sind, hängt die Operation von ERETU bei 1323 von den Werten des FRED_SSP-MSR für die CSL und des SSP ab. Falls Bit 0 des FRED_SSP-MSR gesetzt ist und die verbleibenden Bits gleich den entsprechenden Bits im SSP sind, wird das MSR verifiziert und keine andere Aktion durchgeführt. Falls der Wert des FRED_SSP-MSR gleich dem des SSP ist (was impliziert, dass das FRED_SSP MSR-Bit 0 gelöscht ist), werden 8 Bytes von der Adresse in dem SSP gelesen. Falls der gelesene Wert gleich dem SSP-Wert ist, wobei Bit 0 auf 1 gesetzt ist (und somit ein gesperrtes Token ist), wird dieser Wert in das FRED_SSP-MSR geladen. Dies setzt Bit 0 des FRED_SSP-MSR auf 1, was angibt, dass das FRED_SSP-MSR nun verifiziert ist. (Falls irgendein anderer Wert gelesen wird, ist das MSR nicht modifiziert.) Falls das FRED_SSP-MSR einen beliebigen anderen Wert aufweist, werden 8 Bytes von der Adresse im SSP gelesen, was das Lesen der Adresse sperrt. Falls der gelesene Wert gleich dem SSP-Wert ist, aber Bit 0 auf 1 gesetzt ist (was ein belegtes Token angibt), wird die Sperre freigegeben und der Wert von SSP wird zurückgeschrieben. Das löscht Bit 0 in dem Token, was angibt, dass es nun frei ist. (Das Token wird freigegeben, weil SSP nicht mit dem FRED_SSP-MSR übereinstimmt.) Falls irgendein anderer Wert gelesen wird, wird die Sperre freigegeben, und der gelesene Wert wird zurückgeschrieben. Unabhängig von dem gelesenen Wert wird das FRED_SSP-MSR nicht modifiziert.
Bei 1325 wird ein Rückkehrkontext eingerichtet. Dies kann eine oder mehrere Operationen beinhalten. Bei 1327 werden RIP, RFLAGS, RSP, CS und SSL mit den Werten geladen, die früher bestimmt wurden. Alle 64 Bits von RIP, RFLAGS und RSP werden geladen. Falls Schattenstapel aktiviert sind, wird der SSP bei 1329 mit dem Wert geladen, der früher aus dem Schattenstapel abgerufen wurde.
Der Wert der GS-Basisadresse und der des IA32_KERNEL_GS_BASE-MSR können bei 1331 ausgetauscht werden.
Nicht-maskierbare Interrupts (NMIs) können bei 1333 freigegeben werden, wenn Bit 16 des abgerufenen CS-Feldes (oberhalb des Selektors) 1 ist. Wenn Bit 17 des abgerufenen CS-Feldes 1 ist und die Ausführung zu RFLAGS.TF = 1 führen wird, kann eine Einzelschritt-Trap bei Abschluss von ERETS ausstehend sein. Wenn Bit 18 dieses Feldes 1 ist und die Ausführung zu RFLAGS.IF = 1 führen wird, kann eine Blockierung durch STI bei Abschluss des Befehls bei 1335 wirksam sein.
14(A)-(C) veranschaulichen ein Beispiel für Pseudocode für eine Ausführung von ERETU.
Unterstützung für FRED kann Änderungen an sogenannten Legacy-Befehle beinhalten, z. B. jene, die einen Ringübergang verursachen können.
15 veranschaulicht ein Beispiel für die Behandlung eines entfernten CALL-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 15 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 16, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1501 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Anzeigen eines Fernaufrufs und einem oder mehreren Feldern zum Adressieren von Informationen abgerufen. Der Opcode kann entweder 9A oder FF sein. Eine absolute Adresse kann durch die Adressierungsinformationen bereitgestellt werden. Eine indirekte Adresse kann durch die Adressierungsinformationen gegeben sein. Wenn beispielweise im 32-Bit-Modus ein Selektor auf ein Gatter zeigt, gilt RIP = 32-Bit-Nullerweiterte Verschiebung aus dem Gatter; andernfalls RIP = Nullerweiterter 16-Bit-Offset aus dem Fernzeiger, auf den in dem Befehl verwiesen wird. Ein Fernaufruf ist ein Aufruf einer Prozedur, die sich in einem anderen Segment als einem aktuellen Codesegment befindet.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 1502 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1503 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1505 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1507 ausgeführt, um zu versuchen, einen Fernaufruf unter Verwendung der Adressierungsinformationen durchzuführen. Wenn ein Fernaufruf im realen Adressen- oder virtuellen-8086-Modus ausgeführt wird, wird der aktuelle Wert sowohl des CS- als auch des EIP-Registers auf den Stapel zur Verwendung als ein Rückkehrbefehlszeiger geschoben. Dann wird eine „Fernverzweigung“ zu dem Codesegment und dem mit dem Zieloperanden (unter Verwendung der Adressierungsinformationen) für die aufgerufene Prozedur spezifizierten Offset durchgeführt. Der Zieloperand spezifiziert eine absolute Fernadresse entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32). Mit dem Zeigerverfahren werden das Segment und der Offset der aufgerufenen Prozedur im Befehl unter Verwendung eines 4-Byte- (16-Bit-Operandengröße) oder 6-Byte- (32-Bit-Operandengröße) Fernadressen-Direktoperanden codiert. Mit dem indirekten Verfahren spezifiziert der Zieloperand einen Speicherort, der eine 4-Byte- (16-Bit-Operandengröße) oder 6-Byte- (32-Bit-Operandengröße) Fernadresse enthält. Das Operandengrößenattribut bestimmt die Größe des Offsets (16 oder 32 Bits) in der Fernadresse. Die Fernadresse wird direkt in die CS- und EIP-Register geladen. Falls das Operandengrößenattribut 16 ist, werden die oberen zwei Bytes des EIP-Registers gelöscht.
Im geschützten Modus wird ein Segmentselektorteil der Fernadresse verwendet, um auf den entsprechenden Deskriptor in der GDT oder LDT zuzugreifen. Der Deskriptortyp (Codesegment, Aufrufgatter, Aufgabengatter oder TSS) und Zugriffsrechte bestimmen den Typ der durchzuführenden Aufrufoperation. Falls der ausgewählte Deskriptor für ein Codesegment ist, wird ein Fernaufruf an ein Codesegment auf derselben Berechtigungsebene durchgeführt. (Falls sich das ausgewählte Codesegment auf einer anderen Berechtigungsebene befindet und das Codesegment nicht konform ist, wird eine allgemeine Schutzausnahme erzeugt.) Ein Fernaufruf auf dieselbe Berechtigungsebene im geschützten Modus ist einem sehr ähnlich, der im realen Adressen- oder virtuellen-8086-Modus ausgeführt wird. Der Zieloperand spezifiziert eine absolute Fernadresse entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32). Das Operandengrößenattribut bestimmt die Größe des Offsets (16 oder 32 Bits) in der Fernadresse. Der neue Codesegmentselektor und sein Deskriptor werden in das CS-Register geladen; der Offset vom Befehl wird in das EIP-Register geladen.
Ein Aufrufgatter kann auch verwendet werden, um einen Fernaufruf an ein Codesegment auf derselben Berechtigungsebene durchzuführen. Das Verwenden dieses Mechanismus stellt ein zusätzliches Niveau an Dereferenzierung bereit und ist ein beispielhaftes Verfahren zum Vornehmen von Aufrufen zwischen 16-Bit- und 32-Bit-Codesegmenten. Wenn ein Fernaufruf zwischen Berechtigungsebenen ausgeführt wird, muss auf das Codesegment für die Prozedur, die aufgerufen wird, über ein Aufrufgatter zugegriffen werden. Der durch den Zieloperanden spezifizierte Segmentselektor identifiziert das Aufrufgatter. Der Zieloperand kann den Aufrufgatter-Segmentselektor entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32) spezifizieren. Der Prozessor erhält den Segmentselektor für das neue Codesegment und den neuen Befehlszeiger (Offset) von dem Aufrufgatter-Deskriptor. In einigen Beispielen deaktiviert FRED die Verwendung von Aufrufgattern zu Codesegmenten auf einer numerisch niedrigeren Berechtigungsebene.
Die Ausführung des Befehls führt eine Prüfung durch, um zu bestimmen, ob FRED aktiviert ist. Wenn FRED aktiviert ist, verursacht eine Referenz auf ein Aufrufgatter einen allgemeinen Schutzfehler.
Bei Aufrufen zwischen Berechtigungsebenen schaltet der Prozessor (z. B. Prozessor 101) auf den Stapel für die Berechtigungsebene der aufgerufenen Prozedur um. Der Segmentselektor für das neue Stapelsegment ist im TSS für die aktuell laufende Aufgabe spezifiziert. Die Verzweigung zu dem neuen Codesegment erfolgt nach dem Stapelwechsel. (Es ist anzumerken, dass, wenn ein Aufrufgatter zum Durchführen eines Fernaufrufs an ein Segment auf derselben Berechtigungsebene verwendet wird, kein Stapelwechsel auftritt.) Auf dem neuen Stapel schiebt der Prozessor den Segmentselektor und Stapelzeiger für den Stapel der Aufrufprozedur, einen optionalen Satz von Parametern aus dem Aufrufprozedurstapel und den Segmentselektor und Befehlszeiger für das Codesegment der Aufrufprozedur. (Ein Wert in dem Aufrufgatter-Deskriptor bestimmt, wie viele Parameter auf den neuen Stapel zu kopieren sind.) Schließlich verzweigt der Prozessor zu der Adresse der Prozedur, die innerhalb des neuen Codesegments aufgerufen wird.
Das Ausführen eines Aufgabenwechsels mit dem Befehl ähnelt dem Ausführen eines Aufrufs durch ein Aufrufgatter. Der Zieloperand spezifiziert den Segmentselektor des Aufgabengatters für die neue Aufgabe, die durch den Schalter aktiviert wird (der Offset im Zieloperanden wird ignoriert). Das Aufgabengatter zeigt wiederum auf das TSS für die neue Aufgabe, die die Segmentselektoren für den Code der Aufgabe und Stapelsegmente enthält. Es ist anzumerken, dass das TSS auch den EIP-Wert für den nächsten Befehl enthält, der ausgeführt werden sollte, bevor die aufrufende Aufgabe ausgesetzt wurde. Dieser Befehlszeigerwert wird in das EIP-Register geladen, um die aufrufende Aufgabe neu zu starten.
Der Befehl kann auch den Segmentselektor des TSS direkt spezifizieren, was die Dereferenzierung des Aufgabengatters beseitigt.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1509 übergeben.
16 veranschaulicht ein Beispiel für die Behandlung eines Fernsprungbefehls. Es ist anzumerken, dass dieses Beispiel, wie in 16 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 17, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1601 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Anzeigen eines Fernsprungs und einem oder mehreren Feldern zum Adressieren von Informationen abgerufen. Der Opcode kann EA cd, EA cp oder FF /5 sein. Eine absolute Adresse kann durch die Adressierungsinformationen bereitgestellt werden. Eine indirekte Adresse kann durch die Adressierungsinformationen gegeben sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 1602 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1603 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1605 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1607 ausgeführt, um zu versuchen, einen Fernsprung unter Verwendung der Adressierungsinformationen durchzuführen. Wenn ein Fernsprung im realen Adressen- oder virtuellen-8086-Modus ausgeführt wird, kann der Prozessor zu dem Codesegment und dem mit dem Zieloperanden spezifizierten Offset springen. Hier spezifiziert der Zieloperand eine absolute Fernadresse entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32). Mit dem Zeigerverfahren werden das Segment und die Adresse der aufgerufenen Prozedur im Befehl unter Verwendung eines 4-Byte- (16-Bit-Operandengröße) oder 6-Byte- (32-Bit-Operandengröße) Fernadressen-Direktoperanden codiert.
Mit dem indirekten Verfahren spezifiziert der Zieloperand einen Speicherort, der eine 4-Byte- (16-Bit-Operandengröße) oder 6-Byte- (32-Bit-Operandengröße) Fernadresse enthält. Die Fernadresse wird direkt in die CS- und EIP-Register geladen. Falls das Operandengrößenattribut 16 ist, werden die oberen zwei Bytes des EIP-Registers gelöscht.
Wenn der Prozessor im geschützten Modus arbeitet, kann der JMP-Befehl verwendet werden, um die folgenden drei Arten von Fernsprüngen durchzuführen: einen Fernsprung zu einem konformen oder nicht konformen Codesegment; einen Fernsprung durch ein Aufrufgatter; oder einen Aufgabenwechsel. Im geschützten Modus verwendet der Prozessor immer den Segmentselektorteil der Fernadresse, um auf den entsprechenden Deskriptor in der GDT oder LDT zuzugreifen. Der Deskriptortyp (Codesegment, Aufrufgatter, Aufgabengatter oder TSS) und Zugriffsrechte bestimmen den Typ des durchzuführenden Sprunges.
Falls der ausgewählte Deskriptor für ein Codesegment ist, wird ein Fernsprung zu einem Codesegment auf derselben Berechtigungsebene durchgeführt. (Falls sich das ausgewählte Codesegment auf einer anderen Berechtigungsebene befindet und das Codesegment nicht konform ist, wird eine allgemeine Schutzausnahme erzeugt.) Ein Fernsprung zur selben Berechtigungsebene im geschützten Modus ist einem sehr ähnlich, der im realen Adressen- oder virtuellen-8086-Modus ausgeführt wird. Der Zieloperand spezifiziert eine absolute Fernadresse entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32). Das Operandengrößenattribut bestimmt die Größe des Offsets (16 oder 32 Bits) in der entfernten Adresse. Der neue Codesegmentselektor und sein Deskriptor werden in das CS-Register geladen, und der Offset vom Befehl wird in das EIP-Register geladen. Es ist anzumerken, dass ein Aufrufgatter auch verwendet werden kann, um einen Fernaufruf an ein Codesegment auf derselben Berechtigungsebene durchzuführen. Das Verwenden dieses Mechanismus stellt ein zusätzliches Niveau an Dereferenzierung bereit und ist das bevorzugte Verfahren zum Durchführen von Sprüngen zwischen 16-Bit- und 32-Bit-Codesegmenten.
Wenn ein Fernsprung durch ein Aufrufgatter ausgeführt wird, identifiziert der durch den Zieloperanden spezifizierte Segmentselektor das Aufrufgatter. (Der Offset-Teil des Zieloperanden wird ignoriert.) Der Prozessor springt dann zu dem Codesegment, das in dem Aufrufgatter-Deskriptor spezifiziert ist, und beginnt mit der Ausführung des Befehls mit dem in dem Aufrufgatter spezifizierten Offset. Es findet kein Stapelwechsel statt. Auch hier kann der Zieloperand die Fernadresse des Aufrufgatters entweder direkt mit einem Zeiger (ptr16: 16 oder ptr16: 32) oder indirekt mit einem Speicherort (m16: 16 oder m16: 32) spezifizieren.
Die Ausführung des Befehls kann eine Prüfung durchführen, um zu bestimmen, ob FRED aktiviert ist. Wenn FRED aktiviert ist (z. B. CR4.FRED = IA32_EFER.LMA = 1), verursacht eine Referenz auf ein Aufrufgatter einen allgemeinen Schutzfehler.
Das Ausführen eines Aufgabenwechsels mit dem JMP-Befehl ähnelt dem Ausführen eines Sprunges durch ein Aufrufgatter. Hier spezifiziert der Zieloperand den Segmentselektor des Aufgabengatters für die Aufgabe, zu der gewechselt wird (und der Offset-Teil des Zieloperanden wird ignoriert). Das Aufgabengatter zeigt wiederum auf das TSS für die Aufgabe, die die Segmentselektoren für den Code der Aufgabe und Stapelsegmente enthält. Das TSS enthält auch den EIP-Wert für den nächsten Befehl, der ausgeführt werden sollte, bevor die Aufgabe ausgesetzt wurde. Dieser Befehlszeigerwert wird in das EIP-Register geladen, sodass die Aufgabe bei diesem nächsten Befehl wieder ausgeführt wird.
Der JMP-Befehl kann auch den Segmentselektor des TSS direkt spezifizieren, was die Dereferenzierung des Aufgabengatters beseitigt.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1609 übergeben.
17 veranschaulicht ein Beispiel für die Behandlung eines Interrupt-Rückkehr- bzw. IRET-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 17 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 18, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1701 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben einer Interrupt-Rückkehr abgerufen. Der Opcode kann CF sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 1702 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung wird durch Hardware durchgeführt. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1703 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1705 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1707 ausgeführt, um die Programmsteuerung von einem Ausnahme- oder Interrupt-Handler an ein Programm oder eine Prozedur zurückzugeben, das bzw. die durch eine Ausnahme, einen externen Interrupt oder einen softwareerzeugten Interrupt unterbrochen wurde.
Im realen Adressenmodus kann der IRET-Befehl eine Fernrückkehr zu dem unterbrochenen Programm oder der unterbrochenen Prozedur durchführen. Während dieser Operation ruft der Prozessor den Rückkehrbefehlszeiger, den Rückkehrcodesegmentselektor und das EFLAGS-Bild aus dem Stapel in das EIP-, CS- bzw. EFLAGS-Register ab und nimmt dann die Ausführung des unterbrochenen Programms oder der unterbrochenen Prozedur wieder auf. Im geschützten Modus kann die Aktion des IRET-Befehls von den Einstellungen der NT- (verschachtelte Aufgabe) und VM-Flags im EFLAGS-Register und dem VM-Flag im EFLAGS-Bild, das auf dem aktuellen Stapel gespeichert ist, abhängen. In Abhängigkeit von dem Setzen dieser Flags führt der Prozessor die folgenden Arten von Unterbrechungsrückkehren durch: Rückkehr aus dem virtuellen-8086-Modus; Rückkehr in den virtuellen-8086-Modus; Rückkehr innerhalb einer Berechtigungsebene; berechtigungsübergreifende Rückkehr; und Rückkehr aus der verschachtelten Aufgabe (Aufgabenwechsel). Falls im geschützten Modus der RPL-Wert des Zielcodesegments größer als die CPL ist und wenn FRED-Übergänge aktiviert sind, kann eine solche Ausführung einen allgemeinen Schutzfehler verursachen.
Wenn das NT-Flag (EFLAGS-Register) gelöscht wird, führt der IRET-Befehl eine Fernrückkehr von der Interrupt-Prozedur ohne Aufgabenwechsel durch. Das Codesegment, zu dem zurückgekehrt wird, muss gleich oder weniger berechtigt sein als die Interrupt-Behandlungsroutine (wie durch das RPL-Feld des Codesegmentselektors angegeben, das aus dem Stapel abgerufen wird).
Wie bei einer Interrupt-Rückkehr im realen Adressenmodus ruft der IRET-Befehl den Rückkehrbefehlszeiger, den Rückkehrcodesegmentselektor und das EFLAGS-Bild aus dem Stapel in das EIP-, CS- bzw. EFLAGS-Register ab und nimmt dann die Ausführung des unterbrochenen Programms oder der unterbrochenen Prozedur wieder auf. Falls die Rückkehr zu einer anderen Berechtigungsebene erfolgt, ruft der IRET-Befehl auch den Stapelzeiger und SS aus dem Stapel ab, bevor die Programmausführung wiederaufgenommen wird. Falls die Rückkehr in einen virtuellen Modus erfolgt, ruft der Prozessor auch die Datensegmentregister aus dem Stapel ab.
Falls das NT-Flag gesetzt ist, führt der IRET-Befehl einen Aufgabenwechsel (Rückkehr) von einer verschachtelten Aufgabe (einer Aufgabe, die mit einem CALL-Befehl aufgerufen wird, einem Interrupt oder einer Ausnahme) zurück zu der aufrufenden oder unterbrochenen Aufgabe durch. Der aktualisierte Zustand der Aufgabe, die den IRET-Befehl ausführt, wird in ihrem TSS gespeichert. Falls später wieder in die Aufgabe eingetreten wird, wird der Code, der dem IRET-Befehl folgt, ausgeführt.
Wenn das NT-Flag gesetzt ist und sich der Prozessor im IA-32e-Modus befindet, bewirkt der IRET-Befehl eine allgemeine Schutzausnahme.
Falls nicht-maskierbare Interrupts (NMIs) blockiert sind, gibt die Ausführung des IRET-Befehls NMIs frei. Diese Freigabe tritt selbst dann auf, wenn der Befehl einen Fehler verursacht. In einem solchen Fall werden NMIs demaskiert, bevor der Ausnahmenhandler aufgerufen wird.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1709 übergeben.
18 veranschaulicht ein Beispiel für die Behandlung eines Fernrückkehr- bzw. RET-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 18 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 19, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1801 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Anzeigen einer Fernrückkehr abgerufen. Der einzelne Befehl kann einen Direktoperanden nutzen, um eine Größe von Bytes vorzugeben, die aus einem Stapel abgerufen werden sollen. Der Opcode kann CB oder CA sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 1802 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1803 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1805 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1807 ausgeführt, um per Fernrückkehr zu einer Aufrufprozedur zurückzukehren, und können die unmittelbare Größe von Bytes abrufen, die aus einem Stapel abgerufen werden sollen. Beispielsweise wird Programmsteuerung an eine Rückkehradresse transferiert, die sich am oberen Ende des Stapels befindet. Die Adresse wird üblicherweise durch einen CALL-Befehl auf dem Stapel platziert, und die Rückkehr erfolgt zu dem Befehl, der dem CALL-Befehl folgt. Der optionale Quelloperand spezifiziert die Anzahl von Stapelbytes, die freigegeben werden sollen, nachdem die Rückkehradresse abgerufen wurde; die Vorgabe ist keine. Dieser Operand kann verwendet werden, um Parameter aus dem Stapel freizugeben, die an die aufgerufene Prozedur übergeben wurden und nicht mehr benötigt werden. Eine Fernrückkehr kehrt zu einer Aufrufprozedur zurück, die sich in einem anderen Segment als dem aktuellen Codesegment befindet, manchmal als segmentübergreifende Rückkehr bezeichnet. Wenn eine Fernrückkehr ausgeführt wird, ruft der Prozessor (z. B. Prozessor 101) den Rückkehrbefehlszeiger vom oberen Ende des Stapels in das EIP-Register ab, ruft dann den Segmentselektor vom oberen Ende des Stapels in das CS-Register ab. Der Prozessor beginnt dann die Programmausführung im neuen Codesegment am neuen Befehlszeiger.
Falls im geschützten Modus der RPL-Wert des Zielcodesegments größer als die CPL ist und wenn FRED-Übergänge aktiviert sind, kann eine solche Ausführung einen allgemeinen Schutzfehler verursachen.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1809 übergeben.
Für Software-Interrupts und zugehörige Befehle (z. B. INT n, INT3, INTO INT1) können diese Befehle FRED-Ereignislieferung verwenden, wenn FRED-Übergänge aktiviert sind. Der Befehl INT n (Opcode CD, gefolgt von einem Direktoperanden-Byte) erzeugt einen Software-Interrupt mit einem durch das Direktoperanden-Byte spezifizierten Vektor. Es gibt 256 solcher Befehle, einen für jeden Wert von n (0 - 255). Der Befehl INT3 (Opcode CC) erzeugt eine Unterbrechungspunktausnahme (#BP) als eine Trap. Der Befehl INTO (Opcode CE) erzeugt, falls RFLAGS.OF = 1, eine Überlaufausnahme (#OF) als eine Trap, und erzeugt, falls RFLAGS.OF = 0, keine Ausnahme und gibt die Steuerung an den nächsten Befehl weiter. INTO kann nicht im 64-Bit-Modus ausgeführt werden, kann aber im Kompatibilitätsmodus ausgeführt werden. Der Befehl INT1 (Opcode F1) erzeugt eine Debug-Ausnahme (#DB) als eine Trap. Hardware-Anbieter können INT1 für Hardware-Debugging verwenden.
SYSCALL und SYSRET werden für FRED angepasst. Wenn zum Beispiel FRED-Übergänge aktiviert sind, verwendet die SYSCALL-Ausführung FRED-Ereignislieferung, und Ausführung von SYSRET kann eine Ungültiger-Opcode-Ausnahme (#UD) verursachen.
19 veranschaulicht ein Beispiel für die Behandlung eines SYSCALL-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 19 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 21, 23, 24, 25, 26, 28 gezeigt sind. Bei 1901 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben eines Aufrufs eines BS-Systemaufrufhandlers auf Berechtigungsebene 0 abgerufen. Der Opcode kann 0F 05 sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 1902 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 1903 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 1905 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 1907 ausgeführt, um einen BS-Systemaufrufhandler auf Berechtigungsebene 0 aufzurufen. Wenn FRED nicht aktiviert ist, ruft die Ausführung von SYSCALL einen BS-Systemaufrufhandler auf Berechtigungsebene 0 auf. Dies geschieht durch Laden von RIP aus dem IA32_LSTAR-MSR (nach Speichern der Adresse des Befehls nach SYSCALL in RCX). Die Ausführung von SYSCALL speichert auch RFLAGS in R11 und maskiert dann RFLAGS unter Verwendung des IA32_FMASK-MSR (MSR-Adresse C0000084H); insbesondere löscht der Prozessor in RFLAGS jedes Bit, das einem Bit entspricht, das im IA32_FMASK-MSR gesetzt ist.
Die Ausführung von SYSCALL lädt die CS- und SS-Selektoren mit Werten, die von den Bits 47:32 des IA32_STAR-MSR abgeleitet werden. Die CS- und SS-Deskriptor-Caches werden jedoch nicht von den Deskriptoren (in GDT oder LDT) geladen, auf die durch diese Selektoren verwiesen wird. Stattdessen werden die Deskriptor-Caches mit festen Werten geladen.
Die Ausführung von SYSCALL speichert den Stapelzeiger (RSP) nicht. Falls der BS-Systemaufrufhandler den Stapelzeiger ändert, liegt es in der Verantwortung der Software, den vorherigen Wert des Stapelzeigers zu speichern. Dies könnte vor dem Ausführen von SYSCALL erfolgen, wobei Software den Stapelzeiger mit dem Befehl nach SYSCALL (der nach SYSRET ausgeführt wird) wiederherstellt. Alternativ dazu kann der BS-Systemaufrufhandler den Stapelzeiger speichern und ihn wiederherstellen, bevor er SYSRET ausführt.
Wenn FRED aktiviert ist, verwendet die Ausführung von SYSCALL stattdessen eine FRED-Ereignislieferung.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 1909 übergeben.
20 veranschaulicht ein Beispiel für Pseudocode zur Ausführung von SYSCALL.
21 veranschaulicht ein Beispiel für die Behandlung eines SYSENTER-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 17 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 23, 24, 25, 26, 28 gezeigt sind. Bei 2101 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben eines Aufrufs eines BS-Systemaufrufhandlers auf Berechtigungsebene 0 abgerufen. Der Opcode kann 0F 34 sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 2102 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 2103 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 2105 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 2107 ausgeführt, um eine Systemprozedur oder -routine der Berechtigungsebene 0 aufzurufen. Wenn FRED nicht aktiviert ist, führt die Ausführung des SYSENTER einen Schnellaufruf zu einer Systemprozedur oder -routine der Ebene 0 durch. Der Befehl ist optimiert, um die maximale Leistungsfähigkeit für Systemaufrufe von Benutzercode, der auf Berechtigungsebene 3 läuft, zu Betriebssystem- oder Ausführungsprozeduren, die auf Berechtigungsebene 0 laufen, bereitzustellen. Vor dem Ausführen des SYSENTER-Befehls sollte Software das Codesegment der Berechtigungsebene 0 und den Codeeintrittspunkt der Berechtigungsebene 0 und das Stapelsegment der Berechtigungsebene 0 und den Stapelzeiger durch Schreiben von Werten in die folgenden MSRs spezifizieren:

• IA32_SYSENTER_CS (MSR-Adresse 174 H) - Die unteren 16 Bits dieses MSR sind der Segmentselektor für das Codesegment der Berechtigungsebene 0. Dieser Wert wird auch verwendet, um den Segmentselektor des Stapelsegments der Berechtigungsebene 0 zu bestimmen. Dieser Wert kann keinen Null-Selektor angeben.
• IA32_SYSENTER_EIP (MSR-Adresse 176H) - Der Wert dieses MSR wird in RIP geladen (somit referenziert dieser Wert den ersten Befehl der ausgewählten Betriebsprozedur oder -routine). Im geschützten Modus werden nur Bits 31:0 geladen.
• IA32_SYSENTER_ESP (MSR-Adresse 175H) - Der Wert dieses MSR wird in RSP geladen (somit enthält dieser Wert den Stapelzeiger für den Stapel der Berechtigungsebene 0). Dieser Wert kann keine nicht-kanonische Adresse darstellen. Im geschützten Modus werden nur Bits 31:0 geladen.

Diese MSRs können unter Verwendung von RDMSR/WRMSR gelesen und geschrieben werden. Der WRMSR-Befehl stellt sicher, dass die IA32_SYSENTER_EIP- und IA32_SYSENTER_ESP-MSRs immer kanonische Adressen enthalten.
Während SYSENTER die CS- und SS-Selektoren mit Werten lädt, die von dem IA32_SYSENTER_CS-MSR abgeleitet werden, werden die CS- und SS-Deskriptor-Caches nicht von den Deskriptoren (in GDT oder LDT) geladen, die durch diese Selektoren referenziert werden. Stattdessen werden die Deskriptor-Caches mit festen Werten geladen. Es liegt in der Verantwortung der BS-Software sicherzustellen, dass die Deskriptoren (in GDT oder LDT), die durch diese Selektorwerte referenziert werden, den festen Werten entsprechen, die in die Deskriptor-Caches geladen werden; der SYSENTER-Befehl stellt diese Entsprechung nicht sicher.
Der SYSENTER-Befehl kann aus allen Betriebsmodi außer dem realen Adressenmodus aufgerufen werden.
Wenn FRED aktiviert ist, kann die Ausführung von SYSENTER stattdessen FRED-Ereignislieferung verwenden.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 2109 übergeben.
22 veranschaulicht ein Beispiel für Pseudocode zur Ausführung von SYSENTER.
23 veranschaulicht ein Beispiel für die Behandlung eines MSR-Schreib-Befehls (WRMSR). Es ist anzumerken, dass dieses Beispiel, wie in 23 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 21, 24, 25, 26, 28 gezeigt sind. Bei 2301 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben eines Schreibvorgangs in ein spezifiziertes MSR abgerufen. Der Opcode kann 0F 30 sein. Das MSR kann durch ein Register, wie etwa ECX, spezifiziert werden. Der zu schreibende Wert kann aus anderen Registern stammen, wie etwa einer Verkettung von zwei Registern (z. B. EDX:EAX) oder einem einzigen Register.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 2302 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 2303 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 2305 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 2307 ausgeführt, um die Inhalte spezifizierter Register (z. B. EDX:EAX) in das modellspezifische 64-Bit-Register (MSR) zu schreiben, das in einem anderen Register (z. B. ECX) spezifiziert ist. Die Inhalte des EDX-Registers können in 32 Bits hoher Ordnung des ausgewählten MSR kopiert werden, und die Inhalte des EAX-Registers werden in 32 Bits niedriger Ordnung des MSR kopiert. (Bei Prozessoren, die die Intel 64-Architektur unterstützen, werden die 32 Bits höherer Ordnung sowohl von RAX als auch RDX ignoriert.) Undefinierte oder reservierte Bits in einem MSR sollten auf zuvor gelesene Werte gesetzt werden.
Dieser Befehl sollte auf Berechtigungsebene 0 oder im realen Adressenmodus ausgeführt werden; andernfalls wird eine allgemeine Schutzausnahme #GP(0) erzeugt. Das Spezifizieren einer reservierten oder nicht implementierten MSR-Adresse in ECX wird auch eine allgemeine Schutzausnahme verursachen. Der Prozessor (z. B. der Prozessor 101) wird auch eine allgemeine Schutzausnahme erzeugen, falls Software versucht, in Bits in einem reservierten MSR zu schreiben. Wenn FRED unterstützt wird (z. B. durch Aufzählen von CPUID.(EAX=7,ECX=1):EAX[bit 17]), wird bei einem Versuch, Bit 0 des IA32_PL0_SSP-MSR zu setzen, kein Fehler erzeugt. Jeder Schreibvorgang in dieses MSR durch einen Befehl löscht jedoch Bit 0 des MSR, unabhängig vom Wert des bzw. der Quelloperanden.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 2309 übergeben.
24 veranschaulicht ein Beispiel der Behandlung eines XRSTORS-Befehls (Restore Processor Extended State Supervisor). Es ist anzumerken, dass dieses Beispiel, wie in 24 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 21, 23, 25, 26, 28 gezeigt sind. Bei 2401 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben einer Wiederherstellung von Zustandskomponenten aus einem spezifizierten Speicherort abgerufen. Der Opcode kann 0F C7 /3 sein. Der Speicher kann durch ein Registerpaar (z. B. EDX:EAX) spezifiziert werden.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 2402 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 2403 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 2405 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 2407 ausgeführt, um eine vollständige oder teilweise Wiederherstellung von Prozessorzustandskomponenten aus einem Kontextbereich (z. B. XSAVE) durchzuführen, der sich an der durch den impliziten Quelloperanden spezifizierten Speicheradresse befindet. Das implizite EDX:EAX-Registerpaar spezifiziert eine 64-Bit-Befehlsmaske. Die wiederhergestellten spezifischen Zustandskomponenten entsprechen den Bits, die in der Bitmap mit angeforderten Merkmalen (RFBM) gesetzt sind, die das logische AND von EDX:EAX und das logische OR von XCR0 mit dem IA32_XSS-MSR ist. XRSTORS kann nur ausgeführt werden, wenn CPL = 0 ist.
Wenn FRED unterstützt wird (z. B. durch Aufzählen von CPUID.(EAX=7,ECX=1):EAX[bit 17]), wird bei einem Versuch, Bit 0 des IA32_PL0_SSP-MSR zu setzen, kein Fehler erzeugt. Jeder Schreibvorgang in dieses MSR durch einen Befehl löscht jedoch Bit 0 des MSR, unabhängig vom Wert des bzw. der Quelloperanden.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 2409 übergeben.
64-Bit-Betriebssysteme und ihre Anwendungen können das GS-Segment zur lokalen Thread-Speicherung verwenden. Da das Betriebssystem und die Anwendungen die TLS an unterschiedlichen Adressen verwenden, verwenden sie unterschiedliche Basisadressen für dieses Segment. FRED-Übergänge können sicherstellen, dass ein Betriebssystem immer mit seiner eigenen GS-Basisadresse arbeiten kann: 1) für Ereignisse, die in Ring 3 auftreten, tauscht FRED-Ereignislieferung die GS-Basisadresse mit dem IA32_KERNEL_GS_BASE-MSR aus, und 2) so, dass die Ausführung von ERETU (die FRED-Übergänge, die zu Ring 3 zurückkehren) auch die GS-Basisadresse mit dem IA32_KERNEL_GS_BASE-MSR austauscht.
Ein Betriebssystem kann die GS-Basisadresse eines Benutzer-Threads (z. B. als Teil eines Kontextwechsels) durch Aktualisieren des IA32_KERNEL_GS_BASE-MSR modifizieren. Existierende Befehle erlauben einem Betriebssystem jedoch nicht, die GS-Segmentattribute zu modifizieren, ohne seine Fähigkeit zu beeinträchtigen, immer mit seiner eigenen GS-Basisadresse zu arbeiten. Denn die Befehle, die diese Attribute aktualisieren (indem sie aus einer Deskriptortabelle geladen werden), aktualisieren auch die GS-Basisadresse.
Eine Ausführung eines Befehls, der als LKGS („Laden in IA32_KERNEL_GS_BASE“) bezeichnet wird, kann sich wie MOV zu GS verhalten, außer dass er die Basisadresse in das IA32_KERNEL_GS_BASE-MSR anstelle des Deskriptor-Caches des GS-Segments lädt.
Die Unterstützung für LKGS kann mit dem Merkmalsflag CPUID.(EAX=7,ECX=1):EAX[bit 18] aufgezählt werden.
25 veranschaulicht ein Beispiel für die Behandlung eines LKGS-Befehls. Es ist anzumerken, dass dieses Beispiel, wie in 25 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 21, 23, 24, 26, 28 gezeigt sind. Bei 2501 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode zum Angeben eines Ladens in KERNEL_GS_BASE-MSR einer Basisadresse von einem Deskriptor GDT oder LDT abgerufen. Der Ort des Deskriptors wird durch ein oder mehrere Felder bereitgestellt, die einen Operanden oder einen Operandenort definieren. Es ist anzumerken, dass der Operand ein Direktoperand, ein Register, das einen 16-Bit-Wert speichert, ein Speicherort, das einen 16-Bit-Wert speichert, usw. sein kann. Der Operand kann ein Segmentselektor sein. Der Opcode kann F2 0F 00 /6 sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 2502 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 2503 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 2505 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 2507 ausgeführt, um eine Basisadresse eines Segmentdeskriptors in KERNEL_GS_BASE-MSR zu laden. Beispielsweise wird ein Deskriptor aus der GDT oder der LDT basierend auf dem Quelloperanden identifiziert (ein GS-Segmentselektor). Der Deskriptor wird in den Deskriptor-Cache des GS-Segments geladen, aber die Basisadresse in dem geladenen Deskriptor wird nicht in die Basisadresse in dem Deskriptor-Cache geladen (der nicht modifiziert ist), sondern wird stattdessen in das IA32_KERNEL_GS_BASE-MSR geladen (die oberen 32 Bits des MSR werden gelöscht). Die Ausführung von LKGS kann eine Ungültiger-Opcode-Ausnahme (#UD) verursachen, falls CPL > 0.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 2509 übergeben.
26 veranschaulicht ein Beispiel für die Behandlung einer Wiederaufnahmeoperation eines unterbrochenen Programmbefehls. Es ist anzumerken, dass dieses Beispiel, wie in 26 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 21, 23, 24, 25, 28 gezeigt sind. Der Befehl kann ein Befehl zum Wiederaufnehmen aus dem Systemverwaltungsmodus (RSM) sein. Bei 2601 wird ein einzelner Befehl mit einem oder mehreren Feldern für einen Opcode abgerufen, um anzugeben, dass eine Wiederaufnahmeoperation eines unterbrochenen Programms durchzuführen ist. Der Opcode kann 0F AA sein.
Der abgerufene einzelne Befehl einer ersten ISA kann bei 2602 in einen oder mehrere Befehle einer zweiten ISA übersetzt werden. Diese Übersetzung kann von Hardware ausgeführt werden. Diese Übersetzung kann jedoch auch durch eine Softwareschicht durchgeführt werden, wie etwa einen Just-in-Time-Kompilierer oder einen vorzeitigen Kompilierer.
Der abgerufene Befehl oder übersetzte Befehl(e) wird/werden bei 2603 decodiert. Das Decodieren kann dazu führen, dass mehrere Mikrooperationen erzeugt werden.
Daten, die mit den Operanden des Befehls (oder der Befehle) (entweder explizit oder implizit) assoziiert sind, werden bei 2605 abgerufen, und der eine oder die mehreren decodierten Befehle werden geplant.
Der eine oder die mehreren decodierten Befehle werden bei 2607 ausgeführt, um die Programmsteuerung aus dem Systemverwaltungsmodus (SMM) an das Anwendungsprogramm oder die Betriebssystemprozedur zurückzugeben, das/die unterbrochen wurde, als der Prozessor einen SMM-Interrupt empfangen hat. Der Zustand des Prozessors wird aus dem beim Eintreten in SMM erzeugten Dump wiederhergestellt. Falls der Prozessor ungültige Zustandsinformationen während der Zustandswiederherstellung detektiert, tritt er in den Abschaltzustand ein. Die folgenden ungültigen Informationen können eine Abschaltung bewirken: 1) ein beliebiges reserviertes Bit von CR4 ist auf 1 gesetzt; 2) eine beliebige illegale Kombination von Bits in CR0, wie etwa (PG=1 und PE=0) oder (NW=1 und CD=0); 3) der Wert, der in dem Zustands-Dump-Basisfeld gespeichert ist, ist keine 32-KByte-ausgerichtete Adresse; 4) falls FRED-Übergänge nach RSM aktiviert wären (CR4.FRED = IA32_EFER.LMA = 1) und CPL 1 oder 2 wäre; oder 5) falls FRED-Übergänge nach RSM aktiviert wären, CPL = 3 wäre und die E/A-Berechtigungsebene (IOPL) ungleich Null wäre.
Die Inhalte der modellspezifischen Register werden von einer Rückkehr von SMM nicht beeinflusst. Die SMM-Zustandsabbildung, die von dem RSM verwendet wird, unterstützt Wiederaufnehmen des Prozessorkontexts für Nicht-64-Bit-Modi und 64-Bit-Modus.
Ein Ergebnis des ausgeführten Befehls wird zum Beispiel bei 2609 übergeben.
Wie zuvor angemerkt, kann ein Prozessor (wie etwa der Prozessor 101) Virtualisierung unterstützen (z. B. die Verwendung eines Virtuelle-Maschine-Monitors (VMM) oder Hypervisors, der typischerweise auf einem Computer läuft und anderer Software die Abstraktion einer oder mehrerer virtueller Maschinen (VMs) präsentiert). Jede virtuelle Maschine kann als eine eigenständige Plattform fungieren,, die ihr eigenes „Gastbetriebssystem“ (d. h. ein Betriebssystem (BS), das durch den VMM gehostet wird) und andere Software, die kollektiv als Gastsoftware bezeichnet wird, ausführt. Die Gastsoftware erwartet, so zu arbeiten, als ob sie auf einem dedizierten Computer statt auf einer virtuellen Maschine laufen würde. Das heißt, die Gastsoftware erwartet, verschiedene Ereignisse zu steuern und hat Zugriff auf Hardwareressourcen. Die Hardwareressourcen können prozessorresidente Ressourcen (z. B. Steuerregister), Ressourcen, die sich im Speicher befinden (z. B. Deskriptortabellen), und Ressourcen, die sich auf der darunterliegenden Hardwareplattform befinden (z. B. Eingabe-Ausgabe-Vorrichtungen), beinhalten. Die Ereignisse können interne Interrupts, externe Interrupts, Ausnahmen, Plattformereignisse (z. B. Initialisierung (INIT) oder Systemverwaltungsinterrupts (SMIs)) und dergleichen beinhalten.
In einer Virtuelle-Maschine-Umgebung sollte der VMM in der Lage sein, endgültige Kontrolle über die Ereignisse und Hardwareressourcen zu haben, wie in dem vorherigen Absatz beschrieben, um einen ordnungsgemäßen Betrieb von Gastsoftware, die auf den virtuellen Maschinen läuft, und zum Schutz vor und unter Gastsoftware, die auf den virtuellen Maschinen läuft, bereitzustellen. Um dies zu erreichen, empfängt der VMM typischerweise eine Steuerung, wenn Gastsoftware auf eine geschützte Ressource zugreift oder wenn andere Ereignisse (wie etwa Interrupts oder Ausnahmen) auftreten. Wenn zum Beispiel eine Operation in einer virtuellen Maschine, die von dem VMM unterstützt wird, eine Systemvorrichtung veranlasst, eine Unterbrechung zu erzeugen, wird die gegenwärtig laufende virtuelle Maschine unterbrochen, und die Steuerung des Prozessors wird an den VMM übergeben. Der VMM empfängt dann den Interrupt und behandelt den Interrupt selbst oder ruft eine geeignete virtuelle Maschine auf und liefert den Interrupt an diese virtuelle Maschine.
27 veranschaulicht eine Virtuelle-Maschine-Umgebung 2700, in der einige Beispiele arbeiten. In der Virtuelle-Maschine-Umgebung 2700 beinhaltet die reine Plattformhardware 2710 eine Rechenplattform, die zum Beispiel in der Lage sein kann, ein Standardbetriebssystem (BS) und/oder einen Virtueile-Maschine-Monitor (VMM), wie etwa einen VMM 2712, auszuführen. 27 zeigt drei VMs, 2730, 2740 und 2750. Die Gastsoftware, die auf jeder VM ausgeführt wird, kann ein Gast-BS, wie etwa ein Gast-BS 2754, 2760 oder 2770, und verschiedene Gastsoftwareanwendungen 2752, 2762 und 2772 beinhalten.
Die Gastbetriebssysteme 2754, 2760 und 2770 erwarten, dass sie auf physische Ressourcen (z. B. Prozessorregister, Speicher- und Eingabe-Ausgabe- bzw. E/A-Vorrichtungen) innerhalb entsprechender VMs (z. B. VM 2730, 2740 und 2750), auf denen die Gastbetriebssysteme laufen, zugreifen und andere Funktionen durchführen. Zum Beispiel erwartet das Gast-BS gemäß der Architektur des Prozessors und der Plattform, die in der VM präsentiert werden, Zugriff auf alle Register, Caches, Strukturen, E/A-Vorrichtungen, Speicher und dergleichen. Die Ressourcen, auf die die Gastsoftware zugreifen kann, können entweder als „berechtigt“ oder „nicht berechtigt“ klassifiziert werden. Für berechtigte Ressourcen ermöglicht der VMM 2712 eine Funktionalität, die durch Gastsoftware gewünscht wird, während eine endgültige Kontrolle über diese berechtigten Ressourcen beibehalten wird. Nicht berechtigte Ressourcen müssen nicht durch den VMM 2712 gesteuert werden, und auf sie kann durch Gastsoftware zugegriffen werden.
Ferner erwartet jedes Gast-BS, verschiedene Fehlerereignisse zu behandeln, wie etwa Ausnahmen (z. B. Seitenfehler, allgemeine Schutzfehler usw.), Interrupts (z. B. Hardware-Interrupts, Software-Interrupts) und Plattformereignisse (z. B. Initialisierung (INIT) und Systemverwaltungsinterrupts (SMIs)). Manche dieser Fehlerereignisse sind „berechtigt“, da sie durch den VMM 2712 behandelt werden müssen, um einen ordnungsgemäßen Betrieb der VMs 2730 bis 2750 und zum Schutz vor und unter Gastsoftware sicherzustellen.
Wenn ein berechtigtes Fehlerereignis auftritt oder Gastsoftware versucht, auf eine berechtigte Ressource zuzugreifen, kann die Steuerung an den VMM 2712 übertragen werden. Die Übertragung der Steuerung von Gastsoftware an den VMM 2712 wird hier als VM-Austritt bezeichnet. Nachdem der Ressourcenzugriff oder die Behandlung des Ereignisses angemessen ermöglicht wurde, kann der VMM 2712 die Steuerung an Gastsoftware zurückgeben. Die Übertragung der Steuerung vom VMM 2712 zur Gastsoftware wird als VM-Eintritt bezeichnet. Der VMM 2712 kann den Prozessor 2718 auffordern, einen VM-Eintritt durch Ausführen eines VM-Eintrittsbefehls durchzuführen.
Der Prozessor 2718 (z. B. Prozessor 101) kann den Betrieb der VMs 2730, 2740 und 2750 gemäß Daten steuern, die in einer Virtuelle-Maschine-Steuerstruktur (VMCS) 2726 gespeichert sind. Die VMCS 2726 ist eine Struktur, die einen Zustand von Gastsoftware, einen Zustand des VMM 2712, Ausführungssteuerinformationen, die angeben, wie der VMM 2712 den Betrieb von Gastsoftware steuern möchte, Informationen, die Übergänge zwischen dem VMM 2712 und einer VM steuern usw. enthalten kann. Die VMCS kann in dem Speicher 2720 gespeichert sein. Mehrere VMCS-Strukturen können verwendet werden, um mehrere VMs zu unterstützen.
Wenn ein berechtigtes Fehlerereignis auftritt, kann der VMM 2712 den Fehler selbst behandeln oder entscheiden, dass der Fehler durch eine geeignete VM behandelt werden muss. Falls der VMM 2712 entscheidet, dass der Fehler durch eine VM behandelt werden soll, fordert der VMM 2712 den Prozessor 2718 auf, diese VM aufzurufen und den Fehler an diese VM zu liefern. Der VMM 2712 kann dies durch Setzen eines Fehlerindikators auf einen Lieferwert und Erzeugen einer VM-Eintrittsanfrage bewerkstelligen. Der Fehlerindikator kann in der VMCS 2726 gespeichert sein.
Der Prozessor 2718 beinhaltet eine Fehlerlieferlogik 2724, die Anforderung des VMM 2712 für einen VM-Eintritt empfängt und bestimmt, ob der VMM 2722 die Lieferung eines Fehlers an die VM angefordert hat. Die Fehlerlieferlogik 2724 kann diese Bestimmung basierend auf dem aktuellen Wert des Fehlerindikators, der in der VMCS 2726 gespeichert ist, vornehmen. Falls die Fehlerlieferlogik 2724 bestimmt, dass der VMM die Lieferung des Fehlers an die VM angefordert hat, liefert sie den Fehler an die VM, wenn die Steuerung zu dieser VM übergeht. Es ist anzumerken, dass die FRED-Logik 130 ein Teil der Fehlerlieferlogik 2724 sein kann oder mit der Fehlerlieferlogik 2724 arbeiten kann.
Das Liefern des Fehlers kann das Durchsuchen einer Umleitungsstruktur nach einem Eintrag, der mit dem gelieferten Fehler assoziiert ist, das Extrahieren eines Deskriptors des Orts einer Routine, die zum Behandeln dieses Fehlers bestimmt ist, aus diesem Eintrag und das Springen zum Beginn der Routine unter Verwendung des Deskriptors beinhalten. Routinen, die dazu bestimmt sind, entsprechende Interrupts, Ausnahmen oder andere Fehler zu behandeln, werden als Handler bezeichnet. In einigen Befehlssatzarchitekturen (ISAs) sind bestimmte Fehler mit Fehlercodes assoziiert, die möglicherweise vor dem Springen zum Beginn des Handlers auf den Stapel geschoben (oder in einem Hardwareregister oder über andere Mittel bereitgestellt) werden müssen.
Während der Lieferung eines Fehlers kann der Prozessor 2718 einen oder mehrere Adressübersetzungen ausführen, die eine Adresse von einer virtuellen in eine physische Form umwandeln. Die Adresse der Interrupt-Tabelle oder die Adresse des assoziierten Handlers kann zum Beispiel eine virtuelle Adresse sein. Der Prozessor muss möglicherweise auch verschiedene Überprüfungen während der Lieferung eines Fehlers durchführen. Zum Beispiel kann der Prozessor Konsistenzprüfungen durchführen, wie etwa Validieren von Segmentierungsregistern und Zugriffsadressen (was zu Grenzverletzungsfehlern, Segment-nicht-vorhanden-Fehlern, Stapelfehlern usw. führt), Genehmigungsniveauprüfungen, die zu Schutzfehlern führen können (z. B. allgemeinen Schutzfehlern) usw.
Adressübersetzungen und Überprüfung während Fehlervektorisierung können zu einer Vielfalt von Fehlern führen, wie etwa Seitenfehlern, allgemeinen Schutzfehlern usw. Einige Fehler, die während der Lieferung eines aktuellen Fehlers auftreten, können einen VM-Austritt verursachen. Falls der VMM 2712 zum Beispiel erfordert, dass VM auf Seitenfehlern existiert, um den physischen Speicher zu schützen und zu virtualisieren, dann führt ein Seitenfehler, der während der Lieferung eines aktuellen Fehlers an die VM auftritt, zu einem VM-Austritt.
Die Fehlerlieferlogik 2724 kann das obige mögliche Auftreten zusätzlicher Fehler behandeln, indem sie prüft, ob die Lieferung des aktuellen Fehlers erfolgreich war. Falls die Fehlerlieferlogik 2724 bestimmt, dass die Lieferung nicht erfolgreich war, bestimmt sie ferner, ob ein resultierender zusätzlicher Fehler einen VM-Austritt verursacht. Falls ja, erzeugt die Fehlerlieferlogik 2724 einen VM-Austritt. Falls nicht, liefert die Fehlerlieferlogik 2724 den zusätzlichen Fehler an die VM.
28 ist ein Flussdiagramm eines Beispiels für einen Prozess 2800 zum Behandeln von Fehlern in einer virtuellen Maschinenumgebung. Es ist anzumerken, dass dieses Beispiel, wie in 28 gezeigt, unabhängig von den anderen beispielhaften Verfahren ist, wie etwa jenen, die in einer der 9, 10, 12, 13, 15, 16, 17, 18, 19, 21, 23, 24, 25, 26 gezeigt sind. Der Prozess kann durch Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltungsanordnung, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software (wie etwa die, die auf einem universellen Computersystem oder einer dedizierten Maschine ausgeführt wird) oder eine Kombination von beidem beinhalten kann. Der Prozess 2800 kann von der Fehlerlieferlogik 2724 und/oder der FRED-Logik 130 ausgeführt werden.
Unter Bezugnahme auf 28 beginnt der Prozess 2800 mit Verarbeitungslogik, die eine Anforderung zum Übergang der Steuerung von einem VMM zu einer VM empfängt (Block 2802). Die Anforderung zum Übergang der Steuerung kann über einen VM-Eintrittsbefehl empfangen werden, der durch den VMM ausgeführt wird.
Bei Entscheidungsbox 2804 bestimmt die Verarbeitungslogik, ob der VMM eine Lieferung eines Fehlers an die VM angefordert hat, die aufgerufen werden soll. Ein Fehler kann ein interner Interrupt (z. B. Software-Interrupt), ein externer Interrupt (z. B. Hardware-Interrupt), eine Ausnahme (z. B. Seitenfehler), ein Plattformereignis (z. B. Initialisierung (INIT) oder Systemverwaltungs-Interrupts (SMIs)) oder ein beliebiges anderes Fehlerereignis sein. Verarbeitungslogik kann bestimmen, ob der VMM die Lieferung eines Fehlers angefordert hat, indem er den aktuellen Wert eines Fehlerindikators liest, der von dem VMM verwaltet wird. Der Fehlerindikator kann sich in der VMCS oder einer beliebigen anderen Datenstruktur befinden, auf die der VMM und die Verarbeitungslogik zugreifen kann. Wenn der VMM möchte, dass ein Fehler an eine VM geliefert wird, kann der VMM den Fehlerindikator auf den Lieferwert setzen und erzeugt dann eine Anforderung, die Steuerung an diese VM zu übertragen. Falls während eines VM-Eintritts keine Fehlerlieferung benötigt wird, setzt der VMM den Fehlerindikator auf einen Nichtlieferungswert, bevor die Übertragung der Steuerung an die VM angefordert wird.
Falls Verarbeitungslogik bestimmt, dass der VMM eine Lieferung eines Fehlers angefordert hat, liefert Verarbeitungslogik den Fehler an die VM, während die Steuerung zur VM übergeht (Block 2806). Die Verarbeitungslogik prüft dann, ob die Lieferung des Fehlers erfolgreich war (Entscheidungsbox 2808). Falls ja, endet der Prozess 2800. Falls nicht, bestimmt die Verarbeitungslogik, ob ein resultierender zusätzlicher Fehler einen VM-Austritt verursacht (Entscheidungsbox 2810). Falls ja, erzeugt die Verarbeitungslogik einen VM-Austritt (Block 2812). Falls nicht, liefert die Verarbeitungslogik den zusätzlichen Fehler an die VM (Block 2814) und prüft, zurückkehrend zu Block 2808, ob dieser zusätzliche Fehler erfolgreich geliefert wurde. Falls ja, endet der Prozess 2800. Falls nicht, kehrt die Verarbeitungslogik zu Entscheidungsbox 2810 zurück.
Falls Verarbeitungslogik bestimmt, dass der VMM keine Lieferung eines Fehlers angefordert hat, übergibt Verarbeitungslogik die Steuerung an die VM, ohne irgendwelche fehlerbezogenen Operationen durchzuführen (Block 2818).
Wenn Verarbeitungslogik einen Fehler an eine VM liefern muss, kann sie eine Umleitungsstruktur (z. B. die Interrupt-Deskriptor-Tabelle in der Befehlssatzarchitektur (ISA) des Intel^® Pentium^® 4 (hier als die IA-32-ISA bezeichnet)) nach einem Eintrag durchsuchen, der mit dem gelieferten Fehler assoziiert ist, kann aus diesem Eintrag einen Deskriptor eines mit diesem Fehler assoziierten Handlers extrahieren und kann unter Verwendung des Deskriptors zum Anfang des Handlers springen. Die Interrupt-Deskriptor-Tabelle kann unter Verwendung von Fehleridentifikationsinformationen, wie etwa einer Fehleridentifikation und einem Fehlertyp (z. B. externer Interrupt, interner Interrupt, nicht-maskierbarer Interrupt (NMI), Ausnahme usw.), durchsucht werden. Bestimmte Fehler (z. B. einige Ausnahmen) können Fehlercodes zugeordnet sein, die vor dem Springen zum Beginn des Handlers auf den Stapel geschoben (oder in einem Hardwareregister oder über andere Mittel bereitgestellt) werden müssen. Die Fehleridentifizierungsinformationen und der assoziierte Fehlercode können durch den VMM unter Verwendung einer designierten Datenstruktur bereitgestellt werden. Die designierte Datenstruktur kann Teil der VMCS sein.
29 veranschaulicht ein Beispiel für eine VMCS. Jede virtuelle Maschine ist eine Gastsoftwareumgebung, die einen Stapel (und potenziell einen Schattenstapel) unterstützt, einschließlich zum Beispiel eines Betriebssystems und einer Anwendungssoftware. Jede VM kann unabhängig von anderen virtuellen Maschinen arbeiten und verwendet die gleiche Schnittstelle zu Prozessor(en), Speicher, Speicherung, Grafik und E/A, die von einer physischen Plattform bereitgestellt werden. Der Softwarestapel agiert so, als ob der Softwarestapel auf einer Plattform ohne VMM laufen würde. Software, die in einer virtuellen Maschine ausgeführt wird, arbeitet mit reduzierter Berechtigung oder ihrer ursprünglichen Berechtigungsebene, sodass der VMM zum Beispiel die Steuerung von Plattformressourcen gemäß einem Design des VMM oder einer Richtlinie, die den VMM regelt, beibehalten kann.
Der VMM kann einen Virtuelle-Maschine-Erweiterungs- bzw. VMX-Root-Betriebsmodus beginnen. Der VMM startet die Gastausführung durch Aufrufen eines VM-Eintrittsbefehls. Der VMM ruft einen Startbefehl zur Ausführung für einen ersten VM-Eintritt einer virtuellen Maschine auf. Der VMM ruft eine Wiederaufnahme zur Ausführung für alle nachfolgenden VM-Einträge dieser virtuellen Maschine auf.
Während der Ausführung einer virtuellen Maschine können verschiedene Operationen oder Ereignisse (z. B. Hardware-Interrupts, Software-Interrupts, Ausnahmen, Aufgabenwechsel und bestimmte VM-Befehle) einen VM-Austritt zu dem VMM bewirken, wonach der VMM die Steuerung wiedererhält. VM verlässt die Transfersteuerung zu einem Eintrittspunkt, der durch den VMM spezifiziert wird, z. B. einen Host-Befehlszeiger. Der VMM kann eine Aktion ergreifen, die für die Ursache des VM-Austritts geeignet ist, und kann dann zu der virtuellen Maschine unter Verwendung eines VM-Eintritts zurückkehren.
Diese Übergänge eines VM-Eintritts und eines VM-Austritts werden durch die im Speicher gespeicherte Datenstruktur der VMCS 2726 gesteuert. Der Prozessor steuert den Zugriff auf die VMCS 2726 durch eine Komponente des Prozessorzustands, die VMCS-Zeiger (einer pro virtuellem Prozessor) genannt wird, der durch den VMM eingerichtet wird. Ein VMM kann eine andere VMCS für jeden virtuellen Prozessor verwenden, den er unterstützt. Für eine virtuelle Maschine mit mehreren virtuellen Prozessoren könnte der VMM eine andere VMCS 2726 für jeden virtuellen Prozessor verwenden.
Die VMCS 2726 kann sechs logische Gruppen von Feldern beinhalten: einen Gastzustandsbereich 2902, einen Hostzustandsbereich 2904, VM-Ausführungssteuerfeider 2906, VM-Austrittssteuerfelder 2908, VM-Eingangssteuerfelder 2910 und VM-Austrittsinformationsfelder 2912. Diese sechs logischen Gruppen von Feldern sind lediglich beispielhaft, und andere Prozessoren können mehr oder weniger Gruppen von Feldern aufweisen.
Die VM-Ausführungssteuerfelder 2906 definieren, wie der Prozessor 2718 als Reaktion auf unterschiedliche Ereignisse reagieren sollte, die in der VM auftreten. Die VM-Austrittssteuerfelder 2908 können definieren, was der Prozessor tun sollte, wenn er aus der virtuellen Maschine austritt, z. B. einen Gastzustand der VM in der VMCS 2726 speichern und den VMM- (oder Host-)Zustand aus der VMCS 2726 laden. Der VMM-Zustand kann ein Host-Zustand sein, der Felder beinhaltet, die Prozessorregistern entsprechen, umfassend den VMCS-Zeiger, Selektorfelder für Segmentregister, Basisadressfelder für manche derselben Segmentregister, und Werte einer Liste modellspezifischer Register (MSRs), die für Debugging, Programmausführungsverfolgung, Computerleistungsüberwachung und Umschalten bestimmter Prozessormerkrnale verwendet werden.
Die VM-Eintrittssteuerfeider 2910 können definieren, was der Prozessor z. B. bei Eintritt in die virtuelle Maschine vornehmen sollte, um den Gastzustand der virtuellen Maschine bedingt aus der VMCS zu laden, einschließlich Debug-Steuerungen, und einen Interrupt oder eine Ausnahme nach Bedarf während des Eintritts in die virtuelle Maschine zu injizieren.
Der Gastzustandsbereich 2902 kann ein Ort sein, an dem der Prozessor einen VM-Prozessorzustand bei Austreten aus und Eintreten in die virtuelle Maschine speichert.
Der Host-Zustandsbereich 2904 kann ein Ort sein, an dem der Prozessor den VMM-Prozessor- (oder Host-)Zustand beim Austritt aus der virtuellen Maschine speichert.
Die VM-Austrittsinformationsfelder 2912 können ein Ort sein, an dem der Prozessor Informationen speichert, die einen Grund des Austritts aus der virtuellen Maschine beschreiben.
Wie zuvor angemerkt, kann das Ereignisstapelniveau, das von FRED-Ereignislieferung verwendet wird, davon abhängen, ob das Ereignis eine verschachtelte Ausnahme war, die während der Lieferung eines anderen Ereignisses auftritt. Zur ordnungsgemäßen Virtualisierung dieses Details unterstützen Prozessoren, die FRED unterstützen, zum Beispiel ein Merkmal, das VM-verschachtelte Ausnahmeunterstützung genannt wird. Ein Prozessor kann VMX-verschachtelte Ausnahmeunterstützung durch Setzen von Bit 58 in einem Fähigkeits-MSR (z. B. IA32_VMX_BASIC) aufzählen.
VM-verschachtelte Ausnahmeunterstützung ändert die Art und Weise, wie VM-Austritte bestimmte VM-Austrittsinformationsfelder 2912 einrichten, und die Art und Weise, wie VM-Eintritte ein zugehöriges VM-Eintrittssteuerfeld 2910 verwenden.

Die folgende Tabelle veranschaulicht Beispiele für ein VM-Austrittsinformationsfeld 2912

Format des Austrittsgrunds
Bitposition(en)	Inhalt
15:0	Grundlegender Austrittsgrund
16	immer auf 0 gelöscht
26:17	Aktuell nicht definiert
27	Ein VM-Austritt speichert dieses Bit als 1, um anzugeben, dass der VM-Austritt im Enklaven-Modus aufgetreten ist.
28	Ausstehender MTF-VM-Austritt
29	VM-Austritt aus VMX-Root-Operation
30	Aktuell nicht definiert
31	VM-Eintrittsfehler (0 = echter VM-Austritt; 1 = VM-Eintrittsfehler)

Ereignisspezifische Informationen können für VM-Austritte aufgrund der folgenden vektorisierten Ereignisse bereitgestellt werden: Ausnahmen (einschließlich jener, die durch Interrupt-Befehle erzeugt werden usw.); externe Interrupts, die auftreten, während die VM-Austrittssteuerung für „Interrupt bei Austritt bestätigen“ 1 ist; und nicht-maskierbare Interrupts (NMIs). Diese Informationen werden in den folgenden VM-Austrittsunterbrechungsinformationsfeldern bereitgestellt, wie unten gezeigt:

Format des VM-Austrittsunterbrechungsinformationsfelds
Bitposition(en)	Inhalt
7:0	Interrupt- oder Ausnahmevektor
10:8	Unterbrechungstyp:
	0: Externer Interrupt
	1: Nicht verwendet
	2: Nicht-maskierbarer Interrupt (NMI)
	3: Hardwareausnahme
	4: Nicht verwendet
	5: Berechtigte Softwareausnahme
	6: Softwareausnahme
	7: Nicht verwendet
11	Fehlercode gültig (0 = ungültig; 1 = gültig)
12	NMI-Entsperrung aufgrund von IRET
13	VM-verschachtelte Ausnahmeunterstützung
30:14	Aktuell nicht definiert
31	Gültig

Das VM-Austrittsinformationsfeld ist gültig für VM-Austritte aufgrund von Ereignissen, die mit Interrupt (z. B. Interrupt-Deskriptortabelle- bzw. IDT-Ereignislieferung oder FRED-Ereignislieferung) an Gastsoftware geliefert würden, falls sie keinen VM-Austritt verursachen. Das Feld gibt Einzelheiten über die Art des Ereignisses, das den VM-Austritt verursacht. VM-verschachtelte Ausnahmeunterstützung wird zum Beispiel durch Bit 13 dieses Feldes definiert, das durch Prozessoren ohne VM-verschachtelte Ausnahmeunterstützung immer als 0 gespeichert wird.
Mit VM-verschachtelter Ausnahmeunterstützung speichert ein VM-Austritt Bit 13 dieses Feldes als 1, falls der VM-Austritt auf eine verschachtelte Ausnahme zurückzuführen ist, die während der Lieferung eines früheren Ereignisses auftritt. Dies geschieht selbst, wenn FRED-Übergänge nicht aktiviert sind (d. h., selbst wenn dieses frühere Ereignis unter Verwendung der IDT-Ereignislieferung geliefert wurde). Andere VM-Austritte, für die das Feld gültig ist (einschließlich VM-Austritt aufgrund von #DF), speichern Bit 13 als 0. Der Wert dieses Bits kann immer identisch mit dem des gültigen Bits des IDT-Vektorisierungsinformationsfelds sein.

Zusätzliche Informationen werden für VM-Austritte bereitgestellt, die während der Ereignislieferung in Nicht-Root-VMX-Operationen auftreten. Dieses VM-Austrittsinformationsfeld ist gültig für VM-Austritte aufgrund von Ereignissen, die während der Lieferung eines früheren Ereignisses angetroffen werden, das an Gastsoftware mit IDT-Ereignislieferung oder FRED-Ereignislieferung geliefert wird (einschließlich SYSCALL und SYSENTER mit FRED-Ereignislieferung). Diese Informationen können in den folgenden Feldern für IDT-Vektorisierungsinformationen bereitgestellt werden.

Format des IDT-Vektorisierungsinformationsfelds
Bitposition(en)	Inhalt
7:0	Interrupt- oder Ausnahmevektor
10:8	Unterbrechungstyp:
	0: Externer Interrupt
	1: Nicht verwendet
	2: Nicht-maskierbarer Interrupt (NMI)
	3: Hardwareausnahme
	4: Software-Interrupt
	5: Berechtigte Softwareausnahme
	6: Softwareausnahme
	7: Nicht verwendet
11	Fehlercode gültig (0 = ungültig; 1 = gültig)
12	Aktuell nicht definiert
13	VM-verschachtelte Ausnahmeunterstützung
30:14	Aktuell nicht definiert
31	Gültig

VM-verschachtelte Ausnahmeunterstützung wird in Bit 13 dieses Feldes definiert, das durch Prozessoren ohne VM-verschachtelte Ausnahmeunterstützung immer als 0 gespeichert wird. Bei VM-verschachtelter Ausnahmeunterstützung speichert ein VM-Austritt Bit 13 als 1, falls das frühere Ereignis selbst eine verschachtelte Ausnahme war, die während der Lieferung eines anderen Ereignisses angetroffen wird. Das Bit kommuniziert keine Informationen über das spätere Ereignis, das den VM-Austritt verursacht hat. Dieses Merkmal gilt selbst, wenn FRED nicht aktiviert ist (und somit das frühere Ereignis unter Verwendung von IDT-Ereignislieferung geliefert wurde). Andere VM-Austritte, für die das Feld gültig ist (einschließlich VM-Austritten aufgrund von Ereignissen, die während der Lieferung von #DF auftreten), speichern Bit 13 als 0.

Die Software legt einen gültigen Wert in dem VM-Eintrittsunterbrechungsinformationsfeld des VM-Eintrittssteuerfelds fest, um ein Ereignis zu spezifizieren, das am Ende des nächsten VM-Eintritts injiziert werden soll. Beispiele für dieses VM-Eintrittsunterbrechungsinformationsfeld sind im Folgenden ausführlich beschrieben:

Format des VM-Eintrittsunterbrechungsinformationsfelds
Bitposition(en)	Inhalt
7:0	Interrupt- oder Ausnahmevektor
10:8	Unterbrechungstyp:
	0: Externer Interrupt
	1: Reserviert
	2: Nicht-maskierbarer Interrupt (NMI)
	3: Hardwareausnahme (z. B. #PF)
	4: Software-Interrupt (INT n)
	5: Berechtigte Softwareausnahme (INT1)
	6: Softwareausnahme (INT3 oder INTO)
	7: Anderes Ereignis
11	Liefern von Fehlercode (0 = nicht liefern; 1 = liefern)
12	Reserviert
13	VM-verschachtelte Ausnahmeunterstützung
30:14	Reserviert
31	Gültig

VM-verschachtelte Ausnahmeunterstützung wird durch Bit 13 dieses Feldes definiert. (Für Prozessoren ohne VM-verschachtelte Ausnahmeunterstützung schlägt der VM-Eintritt fehl, falls dieses Bit 1 ist.) Bei VM-verschachtelter Ausnahmeunterstützung ermöglicht der VM-Eintritt, dass das Bit 13 1 ist, falls das Feld die Injektion einer Hardwareausnahme angibt (Bits 10:8, der Typ, sollte den Wert 3 aufweisen). Falls FRED-Übergänge in dem Gast aktiviert werden und somit die injizierte Ausnahme unter Verwendung von FRED-Ereignislieferung geliefert wird, wird die Stapelebene des Ereignisses so bestimmt, als ob das Ereignis eine verschachtelte Ausnahme gewesen wäre, die während der Lieferung eines anderen Ereignisses angetroffen werden würde. Falls keine FRED-Übergänge in dem Gast aktiviert werden, wird Bit 13 des Feldes ignoriert. Falls das Feld die Injektion eines beliebigen anderen Ereignisses angibt (Bits 10:8 haben einen anderen Wert als 3), schlägt der VM-Eintritt fehl, falls dieses Bit 1 ist.
Es ist anzumerken, dass in manchen Beispielen manche der obigen Felder unterschiedliche Namen aufweisen. Für Ereignisse, die bewirken, dass VM austritt, wird anstelle von VM-Austrittsunterbrechungsinformationen der Name Austretendes-Ereignis-Identifikation verwendet, und anstelle von VM-Austrittsunterbrechungsfehlercode wird der Name Austretendes-Ereignis-Fehlercode verwendet. Für VM-Austritte, die während der Ereignislieferung auftreten, wird der Name IDT-Vektorisierungsinformationen durch Originalereignisidentifikation ersetzt und der Name IDT-Vektorisierungsfehlercode wird durch Originalereignisfehlercode ersetzt. Für Ereignisse, die durch den VM-Eintritt injiziert werden, wird der Name VM-Eintrittsunterbrechungsinformationen durch Injiziertes-Ereignis-Identifikation ersetzt, und VM-Eintrittsausnahmefehlercode wird durch einen Injiziertes-Ereignis-Fehlercode ersetzt.
Bei einigen Beispielen werden zusätzliche VMCS-Felder für die Ereignisdaten definiert, die durch FRED-Ereignislieferung gespeichert werden. Das erste Feld ist ein 64-Bit-VMX-Steuerfeld, genannt injizierte Ereignisdaten. Falls VM-Eintrittsinjektion eines Ereignisses FRED-Ereignislieferung verwendet, sind die auf dem Stapel gespeicherten Ereignisdaten der Wert dieses Feldes (siehe Abschnitt 9.5.1). Das zweite neue Feld ist ein 64-Bit-Austrittsinformationsfeld, genannt Originalereignisdaten. Tritt ein VM-Austritt während der FRED-Ereignislieferung auf, so werden stattdessen die Ereignisdaten, die auf dem Stapel gespeichert worden wären, in dieses Feld gespeichert.
Ein VMM (oder sein hostendes Betriebssystem) sollte in der Lage sein, FRED-Übergänge zu verwenden sowie Gastsoftware dafür zu erlauben. Aus diesem Grund müssen VM-Übergänge (VM-Eintritte und VM-Austritte) Kontext herstellen, der ausreicht, um eine FRED-Ereignislieferung unmittelbar nach dem Übergang zu unterstützen. Außerdem sollten VM-Austritte in der Lage sein, den entsprechenden Gastkontext vor dem Laden desselben für den VMM zu speichern.
Um diese Kontextverwaltung zu unterstützen, werden zum Beispiel neue Felder zur VMCS hinzugefügt, die den oben ausführlich beschriebenen Konfigurations-MSRs entsprechen (z. B. IA32_FRED_CONFIG, IA32_FRED_RSP0, IA32_FRED_RSP1, IA32_FRED_RSP2, IA32_FRED_RSP3, IA32_FRED_STKLVLS, IA32_FRED_SSP1, IA32_FRED_SSP2, IA32_FRED_SSP3 und IA32_STAR, IA32_FMASK, IA32_KERNEL_GS_BASE und IA32_PL0_SSP (auch als IA32_FRED_SSP0 bekannt)).
Felder für manche dieser MSRs werden zum Beispiel sowohl zu den Hostzustands- als auch Gastzustandsbereichen der VMCS hinzugefügt. VMCS-Felder werden möglicherweise nicht für alle diese MSRs benötigt. Beispielsweise werden Felder für die folgenden MSRs nicht hinzugefügt: IA32_FRED_RSP0, IA32_STAR und IA32_KERNEL_GS_BASE. Vor dem VM-Eintritt sollte ein Virtuelle-Maschine-Monitor sicherstellen, dass diese MSRs die Werte enthalten, die durch Gastsoftware in der virtuellen Maschine erwartet werden, die betreten wird (z. B. mit einem WRMSR-Befehl).
Ein VMM (oder sein hostendes Betriebssystem) sollte in der Lage sein, FRED-Übergänge zu verwenden sowie Gastsoftware dies zu ermöglichen. Aus diesem Grund stellen VM-Übergänge (VM-Eintritte und VM-Austritte) Kontext her, der ausreicht, um eine FRED-Ereignislieferung unmittelbar nach dem Übergang zu unterstützen. Außerdem sollten VM-Austritte in der Lage sein, den entsprechenden Gastkontext vor dem Laden desselben für den VMM zu speichern.
Zur Unterstützung dieser Kontextverwaltung beinhaltet die VMCS Felder, die den Konfigurations-MSRs entsprechen, die vorher in einigen Beispielen identifiziert wurden. Felder für die MSRs für FRED-Übergänge: IA32_FRED_CONFIG, IA32_FRED_RSP0, IA32_FRED_RSP1, IA32_FRED_RSP2, IA32_FRED_RSP3, IA32_FRED_STKLVLS, IA32_FRED_SSP1, IA32_FRED_SSP2 und IA32_FRED_SSP3; und Felder für MSRs, die von FRED-Übergängen verwendet werden: IA32_STAR, IA32_FMASK, IA32_KERNEL_GS_BASE und IA32_PL0_SSP (auch bekannt als IA32_FRED_SSP0).
Felder für manche dieser MSRs können sowohl zu den Hostzustands- als auch Gastzustandsbereichen der VMCS hinzugefügt werden. Es ist anzumerken, dass VMCS-Felder nicht für alle diese MSRs benötigt werden. Beispielsweise sind Felder für die folgenden MSRs nicht enthalten: IA32_FRED_RSP0, IA32_STAR und IA32_KERNEL_GS_BASE. Vor dem VM-Eintritt sollte ein Virtuelle-Maschine-Monitor sicherstellen, dass diese MSRs die Werte enthalten, die durch Gastsoftware in der virtuellen Maschine erwartet werden, die betreten wird (z. B. mit dem WRMSR-Befehl).
Wie zuvor angemerkt, muss jeder VM-Austritt die Konfiguration erstellen, die für FRED-Übergänge unmittelbar nach dem VM-Austritt erforderlich ist. Die CPL ist nach jedem VM-Austritt immer 0. Aus diesem Grund kann die Lieferung eines Ereignisses, das unmittelbar bei einem VM-Austritt eingeht, keinen Ringübergang verursachen; die Rückkehr von einem solchen Ereignis verwendet ERETS, nicht ERETU. Infolgedessen werden die folgenden MSRs nicht zur Lieferung und Rückkehr von einem solchen Ereignis benötigt: IA32_FRED_RSP0 und IA32_PL0_SSP (auch bekannt als IA32_FRED_SSP0). Falls CPL = 0, lädt FRED-Ereignislieferung RSP aus einem FRED_RSP-MSR nur, wenn die Stapelebene numerisch zunimmt; folglich würde eine solche FRED-Ereignislieferung IA32_FRED_RSP0 oder IA32_PL0_SSP nicht verwenden. Gleichermaßen verwendet ERETS IA32_FRED SSPi nur bei Rückkehr von der Stapelebene i zu einer numerisch niedrigeren Stapelebene; infolgedessen würde ERETS niemals IA32_PL0_SSP verwenden. (ERETS verwendet die FRED_RSP-MSRs überhaupt nicht.) IA32_STAR. FRED-Ereignislieferung verwendet dieses MSR nur beim Laden von CS und SS beim Liefern eines Ereignisses, das in Ring 3 eingeht. ERETS verwendet dieses MSR nicht. IA32_KERNEL_GS_BASE. FRED Ereignislieferung tauscht dieses MSR nur dann mit der GS-Basisadresse aus, wenn ein Ereignis geliefert wird, das in Ring 3 eingeht. ERETS führt dieses Austauschen nicht aus.
Der Host-Zustandsbereich 2904 kann 64-Bit-Felder für die folgenden MSRs beinhalten (ein beispielhaftes Codierungspaar für jedes Feld ist in Klammern gezeigt): IA32_FRED CONFIG (2C08H/2C09H), IA32_FRED_RSP1 (2C0AH/2C0BH), IA32_FRED_RSP2 (2C0CH/2C0DH), IA32_FRED_RSP3 (2C0EH/2C0FH), IA32_FRED_STKLVLS (2C10H/2C11H), IA32_FRED_SSP1 (2C12H/2C13H), IA32_FRED_SSP2 (2C14H/2C15H), IA32_FRED_SSP3 (2C16H/2C17H) und IA32_FMASK (2C18H/2C19H).
Da die MSRs des Host-Zustandsbereichs 2084 durch VM-Austritte geladen werden, muss es möglich sein, dass ihre Gastwerte früher durch diese VM-Austritte gespeichert werden. Aus diesem Grund werden entsprechende Felder zu dem Gastzustandsbereich 2902 der VMCS 2726 hinzugefügt. Außerdem beinhaltet der Gastzustandsbereich ein Feld, das dem IA32_PL0_SSP-MSR entspricht (die FRED-Übergänge als IA32_FRED_SSP0 verwenden).
Bit 0 jedes dieser MSRs ist das verifizierte Bit des MSR. Wie angemerkt, wird eine beliebige Ausführung von WRMSR, die eines dieser MSRs lädt (oder für IA32_PL0_SSP von XRSTORS), das verifizierte Bit des MSR löschen. Dementsprechend reichen WRMSR und XRSTORS nicht für VMM-Kontextverwaltung aus, da ihre Verwendung den Wert des verifizierten Bits, das durch Gastsoftware eingerichtet wird, verlieren könnte. Die einzige Weise, wie ein VMM den Kontext eines Gasts vollständig wiederherstellen kann (einschließlich der richtigen Einstellung der verifizierten Bits der FRED_SSP-MSRs), besteht darin, dass diese MSRs aus der VMCS geladen werden.
Der Host-Zustandsbereich 2904 beinhaltet 64-Bit-Felder für die folgenden MSRs (ein beispielhaftes Codierungspaar für jedes Feld ist in Klammern gezeigt): IA32_FRED_CONFIG (291AH/291BH), IA32_FRED_RSP1 (291CH/291DH), IA32_FRED_RSP2 (291EH/291FH), IA32_FRED_RSP3 (2820H/2821H), IA32_FRED_STKLVLS (2822H/2823H), IA32_FRED_SSP1 (2824H/2825H), IA32_FRED_SSP2 (2826H/2827H), IA32_FRED_SSP3 (2828H/2829H), IA32_FMASK (282AH/282BH) und IA32_PL0_SSP (282CH/282DH).

Die Verwaltung von FRED-Kontext wird unter Verwendung von VM-Eintrittssteuerungen unterstützt, die grundlegende Operation von VM-Eintritten regeln.

Definitionen von VM-Eintrittssteuerungen
Bitposition(en)	Name	Beschreibung
2	Lade-Debug-Steuerungen	Diese Steuerung bestimmt, ob DR7 und das IA32_DEBUGCTL-MSR bei VM-Eintritt geladen werden. Die ersten Prozessoren zum Unterstützen der Virtuelle-Maschine-Erweiterungen unterstützen nur die 1-Einstellung dieser Steuerung.
9	IA-32e-Modus-Gast	Auf Prozessoren, die Intel 64-Architektur unterstützen, bestimmt diese Steuerung, ob sich der logische Prozessor nach dem VM-Eintritt im IA-32e-Modus befindet. Sein Wert wird als Teil des VM-Eintritts 1 in IA32_EFER.LMA geladen. Diese Steuerung muss bei Prozessoren, die Intel 64-Architektur nicht unterstützen, 0 sein.
10	Eintritt in SMM	Diese Steuerung bestimmt, ob sich der logische Prozessor nach dem VM-Eintritt im Systemverwaltungsmodus (SMM) befindet. Diese Steuerung muss für jeden VM-Eintritt von außerhalb des SMM 0 sein.
11	Deaktivieren von Dualmonitorbehandlung	Falls auf 1 gesetzt, ist die Standardbehandlung von SMls und SMM nach dem VM-Eintritt wirksam (siehe Abschnitt 34.15.7). Diese Steuerung muss für jeden VM-Eintritt von außerhalb des SMM 0 sein.
13	Laden von IA32_PERF_GLOBAL L_CTRL	Diese Steuerung bestimmt, ob das IA32_PERF_GLOBAL_CTRL-MSR bei VM-Eintritt geladen wird.
14	Laden von IA32_PAT	Diese Steuerung bestimmt, ob das IA32_PAT-MSR bei VM-Eintritt geladen wird.
15	Laden von IA32_EFER	Diese Steuerung bestimmt, ob das IA32_EFER-MSR bei VM-Eintritt geladen wird.
16	Laden von IA32_BNDCFGS	Diese Steuerung bestimmt, ob das IA32_BNDCFGS-MSR bei VM-Eintritt geladen wird.
17	Verbergen von VMX vor PT	Falls diese Steuerung 1 ist, erzeugt Intel-Prozessor-Trace weder ein Paging-Informationspaket (PIP) bei einem VM-Eintritt noch ein VMCS-Paket bei einem VM-Eintritt, das von SMM zurückkehrt (siehe Kapitel 35).
18	Laden von IA32_RTIT_CTL	Diese Steuerung bestimmt, ob das IA32_RTIT_CTL-MSR bei VM-Eintritt geladen wird.
20	Laden des CET-Zustand	Diese Steuerung bestimmt, ob CET-bezogene MSRs und SPP bei VM-Eintritt geladen werden.
22	Laden von PKRS	Diese Steuerung bestimmt, ob das IA32_PKRS-MSR bei VM-Eintritt geladen wird.
23	Laden von FRED	Diese Steuerung bestimmt, ob VM-Eintritte den Gast-FRED-Zustand in den identifizierten Gastzustandsbereich laden.

In einigen Beispielen ist eine sekundäre VM-Austrittssteuerung 0 „Speichern von FRED“. Falls diese Steuerung gesetzt ist, speichern VM-Austritte den Gast-FRED-Zustand, der identifiziert ist in Fehler! Verweisquelle konnte nicht gefunden werden. In einigen Beispielen ist eine sekundäre VM-Austrittssteuerung 1 „Laden von FRED“. Falls diese Steuerung gesetzt ist, laden VM-Austritte den Host-FRED-Zustand, der in dem Host-Zustandsbereich identifiziert wird.
FRED-Übergänge können im Nicht-Root-VM-Betrieb aktiviert werden. Wenn VM-Austritte aufgrund von Ereignissen behandelt werden, kann ein VMM spezifizieren, dass VM-Austritte bei Auftreten von Ereignissen auftreten sollten, die mit FRED-Ereignislieferung geliefert würden. Diese Ereignisse beinhalten externe Interrupts, nicht-maskierbare Interrupts (NMIs) und Ausnahmen (einschließlich jener, die durch INT1, INT3 und INTO erzeugt werden). Falls ein solches Ereignis auftritt, tritt ein beliebiger spezifizierter VM-Austritt auf, wie es der Fall wäre, wenn FRED-Übergänge nicht aktiviert wären. FRED-Ereignislieferung findet nicht statt.
FRED-Ereignislieferung eines nicht-maskierbaren Interrupts (NMI) blockiert NMIs. Dies ändert sich im Nicht-Root-VM-Betrieb nicht. Es ist jedoch anzumerken, dass ein NMI im Nicht-Root-VM-Betrieb nur geliefert wird, falls die VM-Ausführungssteuerung „NMI tritt aus“ 0 ist.
Wie oben spezifiziert, gibt die Ausführung entweder von ERETS oder ERETU NMIs frei, falls Bit 16 des abgerufenen CS-Feldes 1 ist. Die folgenden Elemente beschreiben, wie dieses Verhalten zum Beispiel im Nicht-Root-VM-Betrieb in Abhängigkeit von den Einstellungen bestimmter VM-Ausführungssteuerungen geändert wird: Falls die VM-Ausführungssteuerung „NMI tritt aus“ 0 ist, wird dieses Verhalten von ERETS und ERETU nicht modifiziert (sie entsperren NMIs, wie oben angegeben). Falls die VM-Ausführungssteuerung „NMI tritt aus“ 1 ist, entsperren ERETS und ERETU physische NMIs nicht. Falls die VM-Ausführungssteuerung „virtuelle NMIs“ 1 ist (was impliziert, dass die VM-Ausführungssteuerung „NMI tritt aus“ ebenfalls 1 ist), verfolgt der logische Prozessor eine Virtuelle-NMI-Sperrung. In diesem Fall entsperren ERETS und ERETU jeweils virtuelle NMIs, falls Bit 16 des abgerufenen CS-Feldes 1 ist.
FRED-Übergänge können anschließend an einen VM-Eintritt aktiviert werden, wenn eine Gastmodus-VM-Eintrittssteuerung (z. B. IA-32e-Modus-Gast) gesetzt ist und ein Bit eines Steuerregisterfelds (z. B. Bit 29 von CR4) in dem Gastzustandsbereich gesetzt ist.
Ein VM-Eintritt kann bewirken, dass eine Prüfung an verschiedenen VMX-Steuerungen durchgeführt wird, einschließlich jener, die sich auf Ereignisinjektion beziehen. Wenn FRED-Übergänge nach dem VM-Eintritt aktiviert sind, können die folgenden Entspannungen für Prüfungen an einem Injiziertes-Ereignis-Feld gelten, wenn das gültige Bit (z. B. Bit 31) in diesem Feld gesetzt wird, indem geprüft wird, ob der „Ereignistyp“ des Feldes (Bits 10:8) 7 ist (anderes Ereignis), der Vektor des Interrupts oder der Ausnahme (Bits 7:0) kann den Wert 1 aufweisen (was SYSCALL angibt), aber es gibt keine Überprüfungen des Bits „Fehlercode liefern“ des Feldes (Bit 11).
Unabhängig davon, ob FRED-Übergänge nach dem VM-Eintritt aktiviert werden, wenden Prozessoren mit VMX-verschachtelter Ausnahmeunterstützung zum Beispiel die folgende Entspannung auf Prüfungen des VM-Eintrittsunterbrechungsfelds an, wenn das gültige Bit (Bit 31) in diesem Feld gesetzt ist, um zu prüfen, ob der „Ereignistyp“ (Bits 10:8) des Feldes 3 ist (Hardwareausnahme). Es ist anzumerken, dass das Bit 13 des Feldes den Wert 1 aufweisen kann (was eine verschachtelte Ausnahme angibt).
Die Unterstützung für FRED-Übergänge kann sich auf die VM-Eintrittszustandsprüfung auf mehrere Weisen auswirken, wie etwa die Weisen, in denen der FRED-Hostzustand geprüft wird, die Weisen, in denen der FRED-Gastzustand geprüft wird, und neue Prüfungen des existierenden Gastzustands, falls FRED-Übergänge nach dem VM-Eintritt aktiviert werden.
Wenn die VM-Austrittssteuerung „Laden von FRED“ 1 ist, wird der FRED-Hostzustand in der VMCS überprüft. Falls das Feld für irgendein MSR einen Wert enthält, der für dieses MSR nicht gültig ist, schlägt der VM-Eintritt fehl, wie dies normalerweise der Fall ist, wenn der Hostzustand überprüft wird. Die Eigenschaften, die gelten müssen, beinhalten für das IA32_FRED_CONFIG-MSR, dass Bit 2, Bits 5:4 und Bit 11 des Feldes 0 und die oberen Bits des Feldes derart sein müssen, dass der Wert des Feldes relativ zu der maximalen linearen Adressbreite des Prozessors kanonisch ist; für die IA32_FRED_RSP1 - IA32_FRED_RSP3-MSRs, dass der Wert jedes dieser Felder bezüglich der maximalen linearen Adressbreite des Prozessors kanonisch sein muss; und/oder für die IA32_FRED_SSP1- IA32_FRED SSP3-MSRs, dass Bits 2:1 jedes dieser Felder 0 und die oberen Bits jedes Feldes derart sein müssen, dass der Wert des Feldes bezüglich der maximalen linearen Adressbreite des Prozessors kanonisch ist.
Wenn die VM-Eintrittssteuerung „Laden von FRED“ 1 ist, wird der FRED-Gastzustand in der VMCS überprüft. Falls das Feld für irgendein MSR einen Wert enthält, der für dieses MSR nicht gültig ist, schlägt der VM-Eintritt fehl, wie dies normalerweise der Fall ist, wenn der Gastzustand überprüft wird. Die Eigenschaften, die gelten sollten, beinhalten: für das IA32_FRED_CONFIG-MSR, dass Bit 2, Bits 5:4 und Bit 11 des Feldes 0 und die oberen Bits des Feldes derart sein müssen, dass ihr Wert relativ zu der maximalen linearen Adressbreite des Prozessors kanonisch ist; für die IA32_FRED_RSP1 - IA32_FRED_RSP3-MSRs, dass der Wert jedes dieser Felder bezüglich der maximalen linearen Adressbreite des Prozessors kanonisch sein muss; für die IA32_FRED_SSP1-IA32_FRED_SSP3-MSRs, dass Bits 2:1 jedes dieser Felder 0 und die oberen Bits jedes Feldes derart sein müssen, dass ihr Wert relativ zu der maximalen linearen Adressbreite des Prozessors kanonisch ist; und/oder für das IA32_PL0_SSP-MSR, dass Bit 1 des Feldes 0 und die oberen Bits des Feldes derart sein müssen, dass ihr Wert relativ zur maximalen linearen Adressbreite des Prozessors kanonisch ist.
Wie an anderer Stelle angemerkt, kann Software nicht in Ring 1 oder Ring 2 eintreten, während FRED-Übergänge aktiviert sind. Zusätzlich muss die IOPL 0 sein, wenn CPL 3 ist. Prüfungen werden zum VM-Eintritt hinzugefügt, um diese Einschränkungen durchzusetzen. Wenn beispielsweise FRED-Übergänge nach dem VM-Eintritt aktiviert wurden, werden die folgenden Prüfungen an dem Gastzustandsbereich in der VMCS durchgeführt: der DPL-Wert (Bits 6:5) in dem SS-Attributfeld muss 0 oder 3 sein, und falls der DPL-Wert in dem SS-Attributfeld 3 ist, muss der IOPL-Wert (Bits 13:12) in dem RFLAGS-Feld 0 sein.
Wenn die VM-Eintrittssteuerung „Laden von FRED“ 1 ist, wird der FRED-Gastzustand geladen, der in dem Gastzustandsbereich aus der VMCS identifiziert wird. Im Gegensatz zu dem WRMSR-Befehl setzt VM-Eintritt Bit 0 eines FRED_SSP-MSR (das verifizierte Bit des MSR), wenn Bit 0 in dem entsprechenden Feld in dem Gastzustandsbereich der VMCS gesetzt ist. Dies gilt auch für das IA32_PL0_SSP-MSR.
Wenn das gültige Bit in dem VM-Eintrittsunterbrechungsfeld 1 ist, wird in manchen Beispielen ein Ereignis injiziert. Die Injektion eines externen Interrupts, eines nicht-maskierbaren Interrupts (NMI), einer Ausnahme (einschließlich jener, die durch INT1, INT3 und INTO verursacht werden) oder eines Software-Interrupts verwendet eine FRED-Ereignislieferung (anstelle einer IDT-Ereignislieferung), falls FRED-Übergänge nach dem VM-Eintritt aktiviert wurden. Wenn Bit 13 des VM-Eintrittsunterbrechungsfelds 1 ist (was impliziert, dass das Ereignis eine Ausnahme ist) und das injizierte Ereignis unter Verwendung von FRED-Ereignislieferung geliefert wird, wird die Stapelebene des Ereignisses so bestimmt, als ob das Ereignis während der Lieferung eines anderen Ereignisses angetroffen worden wäre. Wenn VM einen Seitenfehler (#PF) injiziert, der unter Verwendung einer FRED-Ereignislieferung geliefert wird, wird der aktuelle Wert von CR2 auf den Stapel geschoben, wie spezifiziert. In ähnlicher Weise schiebt VM-Eintrittsinjektion einer Debug-Ausnahme (#DB) mit FRED-Ereignislieferung den aktuellen Wert von DR6, und VM-Eintrittsinjektion einer Vorrichtungnicht-verfügbar-Ausnahme (#NM) schiebt den aktuellen Wert des IA32_XFD_ERR-MSR.
Wenn bei einigen Beispielen FRED-Ereignislieferung für ein Ereignis verwendet wird, das durch den VM-Eintritt injiziert wird, sind die gespeicherten Ereignisdaten der Wert des Injiziertes-Ereignis-Datenfelds in der VMCS. Wenn FRED-Ereignislieferung für ein solches Ereignis verwendet wird, das durch den VM-Eintritt injiziert wird, ist die gespeicherte Befehlslänge der Wert des VM-Eintritt-Befehlslängenfelds in der VMCS. Die folgenden Punkte beschreiben die beispielhafte existierende Behandlung von RIP durch VM-Eintrittsereignisinjektion:

1. Falls VM-Eintritt erfolgreich (ohne verschachtelte Ausnahme) ein Ereignis mit einem externen Interrupt, NMI oder einer Hardwareausnahme injiziert, wird der Gast-RIP (wie aus der VMCS geladen) auf den Stapel geschoben.
2. Falls VM-Eintritt erfolgreich (ohne verschachtelte Ausnahme) ein Ereignis mit Typsoftwareunterbrechung, berechtigter Softwareausnahme oder Softwareausnahme injiziert, wird der Gast-RIP um die VM-Eintrittsbefehlslänge inkrementiert, bevor er auf den Stapel geschoben wird.
3. Falls VM-Eintritt auf eine Ausnahme trifft, während ein Ereignis injiziert wird, und diese Ausnahme keinen VM-Eintritt verursacht, wird der Gast-RIP unabhängig vom Ereignistyp oder der VM-Eintrittsbefehlslänge auf den Stapel geschoben.
4. Falls VM-Eintritt auf einen VM-Austritt trifft, während ein Ereignis injiziert wird (vielleicht aufgrund einer Ausnahme), ist der RIP-Wert, der durch den VM-Austritt gespeichert wird, der Gast-RIP, der aus der VMCS geladen wird. Falls das injizierte Ereignis vom Typ Software-Interrupt, berechtigte Softwareausnahme oder Softwareausnahme ist, ist der Wert, der für die VM-Austrittsbefehlslänge gespeichert wird, die VM-Eintrittsbefehlslänge. Punkt Nr. 2 dieser existierenden Behandlung gilt auch, wenn der VM-Eintritt SYSCALL oder SYSENTER unter Verwendung von FRED-Ereignislieferung injiziert. Für Punkt Nr. 4 wird die Behandlung der Befehlslänge erweitert, um sie auch für die Injektion von SYSCALL und SYSENTER anzuwenden.

FRED-Übergänge können auch mit VM-Austritten interagieren. Wenn die VM-Austrittssteuerung „Speichern von FRED“ 1 ist, bewirkt ein VM-Austritt eine Speicherung des FRED-Gastzustands, der im Gastzustandsbereich identifiziert wird, in der VMCS. Wenn die VM-Austrittssteuerung „Laden von FRED“ 1 ist, bewirkt ein VM-Austritt ein Laden des FRED-Hostzustands, der in dem Hostzustandsbereich aus der VMCS identifiziert wird.
Falls ein Ereignis, das stattdessen FRED-Ereignislieferung verwenden würde, einen VM-Austritt verursacht, werden Informationen über das Ereignis in den VM-Austrittsunterbrechungsinformationen und VM-Austrittsunterbrechungsfehlercode-Feldern der VMCS gespeichert, wie es der Fall wäre, falls FRED-Übergänge nicht aktiviert wären, mit den folgenden Ausnahmen: wenn Bit 11 des VM-Austrittsunterbrechungsinformations-Feldes angibt, ob das Fehlercodefeld gültig ist (für Ereignisse, die auftreten, während FRED-Übergänge aktiviert sind, wird dieses Bit immer als 1 gespeichert), und für Ereignisse, die auftreten, während FRED-Übergänge aktiviert sind, kann der VM-Austrittsunterbrechungsfehlercode immer definiert werden; wenn Bit 13 des Austrittsereignisidentifikations-Feldes gesetzt ist, falls der VM-Austritt auf eine verschachtelte Ausnahme zurückzuführen ist, die während der Lieferung eines früheren Ereignisses auftritt. Andere VM-Austritte (einschließlich VM-Austritte aufgrund von #DF) löschen das Bit.
Ein VM-Austritt kann während der FRED-Ereignislieferung entweder aufgrund einer verschachtelten Ausnahme (die konfiguriert ist, um einen VM-Austritt zu verursachen) oder aufgrund eines VMX-spezifischen Auftretens (z. B. einer EPT-Verletzung) auftreten. Dies kann genauso behandelt werden wie ein VM-Austritt, der bei IDT-Ereignislieferung auftritt. Insbesondere wird kein Registerzustand durch die FRED-Ereignislieferung aktualisiert, die auf den VM-Austritt getroffen ist. In diesen Fällen werden Informationen über das Ereignis in den IDT-Vektorisierungsinformationen und IDT-Vektorisierungsunterbrechungsfehlercode-Feldern der VMCS gespeichert, wie dies der Fall wäre, wenn FRED-Übergänge nicht aktiviert wären, mit den folgenden Ausnahmen: wenn Bit 11 des IDT-Vektorisierungsinformationsfelds angibt, ob das Fehlercodefeld gültig ist (für VM-Austritte, die während der FRED-Ereignislieferung auftreten, wird dieses Bit immer als 1 gespeichert), und für VM-Austritte, die während der FRED-Ereignislieferung auftreten, kann der IDT-Vektorisierungsunterbrechungsfehlercode immer definiert werden. Allgemein gilt für Merkmale, die eine Spezialbehandlung während der IDT-Ereignislieferung aufweisen (z. B. Umwandlung von EPT-Verletzungen in Virtualisierungsausnahmen), diese Spezialbehandlung auch für FRED-Ereignislieferung; wenn Bit 13 des Originalereignisidentifikationsfelds gesetzt ist, falls das Originalereignis eine verschachtelte Ausnahme war, die während der Lieferung eines anderen Ereignisses angetroffen wurde. Andere VM-Austritte (einschließlich VM-Austritte aufgrund von Ereignissen, die während der Lieferung von #DF auftreten) löschen das Bit.
Ein VM-Austritt kann während der Ausführung von ERETS oder ERETU entweder aufgrund einer Ausnahme (falls konfiguriert, um einen VM-Austritt zu bewirken) oder aufgrund eines VMX-spezifischen Auftretens (z. B. einer EPT-Verletzung) auftreten. Dies wird, im Allgemeinen, auf die gleiche Weise behandelt wie VM-Austritte, die für fehlerähnliche VM-Austritte auftreten, und kein Registerzustand wird aktualisiert. Beispielsweise gibt eine Ausführung von ERETS und ERETU, die einen VM-Austritt bewirkt, NMIs (oder virtuelle NMIs) nicht frei. Infolgedessen setzt ein solcher VM-Austritt, der aus einem Fehler, einer EPT-Verletzung, einem Seitenmodifikations-Log-Voll-Ereignis, einer SPPT-Fehlkonfiguration oder einem SPPT-Fehltreffer resultiert, der von ERETS oder ERETU angetroffen wird, niemals Bit 12 der Austrittsqualifikation.
Hierin ausführlich beschriebene Beispiele können in vielen unterschiedlichen Typen von Architekturen, Systemen, Befehlsformaten usw. umgesetzt sein, von denen einige unten ausführlich beschrieben sind.
Beispielhafte Computerarchitekturen
Im Folgenden werden beispielhafte Computerarchitekturen ausführlich beschrieben. Andere im Fachgebiet bekannte Systemkonzeptionen und -auslegungen für Laptops, Desktops, handgestützte PCs, persönliche digitale Assistenten, technische Workstations, Server, Netzwerkvorrichtungen, Netzwerkknoten, Weichen, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienabspielvorrichtungen, handgestützte Vorrichtungen und verschiedene andere elektronische Vorrichtungen sind ebenfalls geeignet. Im Allgemeinen ist eine große Vielzahl an Systemen oder elektronischen Vorrichtungen allgemein geeignet, die zum Einbinden eines Prozessors und/oder anderer Ausführungslogik, wie hier offenbart, fähig sind.
30 veranschaulicht Beispiele für ein beispielhaftes System. Das Multiprozessorsystem 3000 ist ein Punkt-zu-Punkt-Verbindungssystem und umfasst mehrere Prozessoren, einschließlich eines ersten Prozessors 3070 und eines zweiten Prozessors 3080, die über eine Punkt-zu-Punkt-Verbindung 3050 gekoppelt sind. In einigen Beispielen sind der erste Prozessor 3070 und der zweite Prozessor 3080 homogen. In einigen Beispielen sind der erste Prozessor 3070 und der zweite Prozessor 3080 heterogen.
Die Prozessoren 3070 und 3080 sind einschließlich integrierter Speichersteuerungs- bzw. IMC-Einheitsschaltungsanordnungen 3072 bzw. 3082 gezeigt. Prozessor 3070 umfasst auch als Teil seiner Verbindungssteuerungseinheiten Punkt-zu-Punkt-Schnittstellen (P-P) 3076 und 3078; in ähnlicher Weise umfasst der zweite Prozessor 3080 P-P-Schnittstellen 3086 und 3088. Prozessoren 3070, 3080 können Informationen über die Punkt-zu-Punkt-Verbindung (P-P) 3050 unter Verwendung von P-P-Schnittstellenschaltungen 3078, 3088 austauschen. IMCs 3072 und 3082 koppeln die Prozessoren 3070, 3080 mit jeweiligen Speichern, insbesondere einem Speicher 3032 und einem Speicher 3034, die Teile des lokal mit den jeweiligen Prozessoren verbundenen Hauptspeichers sein können.
Prozessoren 3070, 3080 können auch jeweils Informationen mit einem Chipsatz 3090 über individuelle P-P-Verbindungen 3052, 3054 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 3076, 3094, 3086, 3098 austauschen. Der Chipsatz 3090 kann optional Informationen mit einem Koprozessor 3038 über eine Hochleistungsschnittstelle 3092 austauschen. In einigen Beispielen ist der Koprozessor 3038 ein spezieller Prozessor, wie etwa, beispielsweise, ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder ähnliches.
Ein gemeinsam genutzter Cache (nicht gezeigt) kann in beiden Prozessoren 3070, 3080 oder außerhalb beider Prozessoren enthalten sein, jedoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, sodass lokale Cacheinformationen eines oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in einen Niederleistungsmodus gesetzt wird.
Chipsatz 3090 kann über eine Schnittstelle 3096 mit einer ersten Zwischenverbindung 3016 gekoppelt sein. In einigen Beispielen kann die erste Zwischenverbindung 3016 eine periphere Komponentenverschaltungs- bzw. PCI-Zwischenverbindung oder eine Zwischenverbindung, wie etwa eine PCI-Express-Zwischenverbindung oder eine andere E/A-Zwischenverbindung sein. In einigen Beispielen ist eine der Zwischenverbindungen mit einer Leistungssteuereinheit (PCU) 3017 gekoppelt, die eine Schaltungsanordnung, Software und/oder Firmware beinhalten kann, um Leistungsverwaltungsoperationen in Bezug auf die Prozessoren 3070, 3080 und/oder den Koprozessor 3038 durchzuführen. Die PCU 3017 stellt Steuerinformationen für einen Spannungsregler bereit, um zu bewirken, dass der Spannungsregler die angemessene geregelte Spannung erzeugt. Die PCU 3017 stellt auch Steuerinformationen zum Steuern der erzeugten Betriebsspannung bereit. In verschiedenen Beispielen kann die PCU 3017 eine Vielzahl von Leistungsverwaltungslogikeinheiten (Schaltungsanordnungen) beinhalten, um eine hardwarebasierte Leistungsverwaltung durchzuführen. Eine solche Leistungsverwaltung kann vollständig prozessorgesteuert sein (z. B. durch verschiedene Prozessorhardware, und die durch Arbeitslast und/oder Leistung, thermische oder andere Prozessoreinschränkungen ausgelöst werden kann) und/oder die Leistungsverwaltung kann als Reaktion auf externe Quellen (wie etwa eine Plattform oder Leistungsverwaltungsquelle oder Systemsoftware) durchgeführt werden.
Die PCU 3017 ist als von dem Prozessor 3070 und/oder dem Prozessor 3080separate Logik vorhanden veranschaulicht. In anderen Fällen kann die PCU 3017 auf einem oder mehreren gegebenen Kernen (nicht gezeigt) des Prozessors 3070 oder 3080 ausgeführt werden. In manchen Fällen kann die PCU 3017 als ein Mikrocontroller (dediziert oder universell) oder eine andere Steuerlogik implementiert sein, die dazu ausgelegt ist, ihren eigenen dedizierten Leistungsverwaltungscode, manchmal als P-Code bezeichnet, auszuführen. In noch anderen Beispielen können Leistungsverwaltungsoperationen, die durch die PCU 3017 durchzuführen sind, außerhalb eines Prozessors implementiert werden, wie etwa mittels einer separaten integrierten Leistungsverwaltungsschaltung (PMIC) oder einer anderen Komponente außerhalb des Prozessors. In noch anderen Beispielen können Leistungsverwaltungsoperationen, die von der PCU 3017 auszuführen sind, innerhalb von BIOS oder anderer Systemsoftware implementiert werden.
Verschiedene E/A-Vorrichtungen 3014 können mit der ersten Zwischenverbindung 3016 gekoppelt sein, zusammen mit einer Zwischenverbindungs- bzw. Bus-Brücke 3018, die die erste Zwischenverbindung 3016 mit einer zweiten Zwischenverbindung 3020 koppelt. In manchen Beispielen sind ein oder mehrere zusätzliche Prozessoren 3015, wie etwa Koprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUS, Beschleuniger (wie etwa z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs- bzw. DSP-Einheiten, feldprogrammierbare Gate-Arrays (FPGAs) oder ein beliebiger anderer Prozessor, mit der ersten Zwischenverbindung 3016 gekoppelt. In einigen Beispielen kann die zweite Zwischenverbindung 3020 eine LPC-Zwischenverbindung (LPC: Low Pin Count) sein. Verschiedene Vorrichtungen können mit der zweiten Zwischenverbindung 3020 gekoppelt sein, einschließlich zum Beispiel einer Tastatur und/oder Maus 3022, Kommunikationsvorrichtungen 3027 und einer Speicherungseinheits-Schaltungsanordnung 3028. Die Speicherungseinheits-Schaltungsanordnung 3028 kann in manchen Beispielen ein Plattenlaufwerk oder eine andere Massenspeicherungsvorrichtung sein, die Befehle/Code und Daten 3030 beinhalten kann. Ferner kann eine Audio-E/A 3024 mit der zweiten Zwischenverbindung 3020 gekoppelt sein. Es ist anzumerken, dass andere Architekturen als die oben beschriebene Punkt-zu-Punkt-Architektur möglich sind. Zum Beispiel kann anstelle der Punkt-zu-Punkt-Architektur ein System, wie etwa das Multiprozessorsystem 3000, eine Multi-Drop-Zwischenverbindung oder eine andere solche Architektur implementieren.
Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
Prozessorkerne können auf unterschiedliche Weisen, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren umgesetzt sein. Beispielsweise können Implementierungen solcher Kerne Folgendes beinhalten: 1) einen universellen reihenfolgetreuen (In-order) Kern, gedacht für universelles Rechnen; 2) einen universellen reihenfolgeveränderten (Out-of-order) Hochleistungskern, gedacht für universelles Rechnen; 3) einen speziellen Kern, primär gedacht für Grafik und/oder wissenschaftliche (Durchsatz) Berechnung. Implementierungen unterschiedlicher Prozessoren können Folgendes beinhalten: 1) eine CPU, einen oder mehrere universelle reihenfolgetreue (In-order) Kerne, gedacht für universelles Rechnen, und/oder einen oder mehrere universelle reihenfolgeveränderte (Out-of-order) Kerne, gedacht für universelles Rechnen, umfassend; und 2) einen Koprozessor, einen oder mehrere spezielle Kerne, primär gedacht für Grafik und/oder Wissenschaft (Durchsatz), umfassend. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die Folgendes umfassen können: 1) den Koprozessor auf einem von der CPU separaten Chip; 2) den Koprozessor auf einem separaten Die im gleichen Chipgehäuse wie eine CPU; 3) den Koprozessor auf dem gleichen Die wie eine CPU (in diesem Fall wird ein solcher Koprozessor manchmal als spezielle Logik, wie etwa als integrierte Grafik und/oder wissenschaftliche (Durchsatz) Logik, oder als spezielle Kerne bezeichnet); und 4) ein System-on-a-Chip, das auf demselben Die die beschriebene CPU (manchmal als der bzw. die Anwendungskerne oder Anwendungsprozessoren bezeichnet), den oben beschriebenen Koprozessor und zusätzliche Funktionalität umfassen kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen beispielhafter Prozessoren und Computerarchitekturen.
31 veranschaulicht ein Blockdiagramm von Beispielen für einen Prozessor 3100, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann und integrierte Grafiken aufweisen kann. Die Felder mit den durchgezogenen Linien stellen einen Prozessor 3100 mit einem einzelnen Kern 3102A, einen Systemagenten 3110, eine Menge von einer oder mehreren Zwischenverbindungssteuerungseinheiten 3116 dar, während die optionale Hinzufügung der Felder mit gestrichelten Linien einen alternativen Prozessor 3100 mit mehreren Kernen 3102(A)-(N), eine Menge von einer oder mehreren integrierten Speichersteuerungseinheits-Schaltungsanordnungen 3114 in der Systemagenteneinheits-Schaltungsanordnung 3110 und spezieller Logik 3108 sowie eine Menge von einer oder mehreren Zwischenverbindungssteuerungseinheits-Schaltungsanordnungen 3116 darstellt. Es ist anzumerken, dass der Prozessor 3100 einer der Prozessoren 3070 oder 3080 oder ein Koprozessor 3038 oder 3015 aus 30 sein kann.
Dementsprechend können unterschiedliche Implementierungen des Prozessors 3100 Folgendes beinhalten: 1) eine CPU, wobei die spezielle Logik 3108 integrierte Grafik und/oder wissenschaftliche (Durchsatz) Logik ist (die einen oder mehrere Kerne umfassen kann, nicht gezeigt), und wobei die Kerne 3102(A)-(N) ein oder mehrere universelle Kerne sind (z. B. universelle reihenfolgetreue (In-order) Kerne, universelle reihenfolgeveränderte (Out-of-order) Kerne oder eine Kombination aus den zwei); 2) einen Koprozessor, wobei die Kerne 3102(A)-(N) eine große Anzahl von speziellen Kernen sind, primär für Grafik und/oder wissenschaftliches (Durchsatz) Rechnen gedacht; und 3) einen Koprozessor, wobei die Kerne 3102(A)-(N) eine große Anzahl von universellen reihenfolgetreuen (In-order) Kernen sind. Daher kann der Prozessor 3100 ein universeller Prozessor, Koprozessor oder spezieller Prozessor sein, wie etwa, beispielsweise, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine universelle Grafikprozessor-Berechnungseinheit (GPGPU), ein Koprozessor mit hohem Durchsatz und vielen integrierten Kernen (MIC, Many Integrated Core) (30 oder mehr Kerne umfassend), ein eingebetteter Prozessor oder ähnliches. Der Prozessor kann auf einem oder mehreren Chips umgesetzt sein. Der Prozessor 3100 kann ein Teil eines und/oder kann auf einem oder mehreren Substraten unter Verwendung einer beliebigen aus einer Anzahl von Prozesstechnologien umgesetzt sein, wie etwa, beispielsweise, BiCMOS, CMOS oder NMOS.
Eine Speicherhierarchie beinhaltet eine oder mehrere Ebenen von Cacheeinheits-Schaltungsanordnungen 3104(A)-(N) innerhalb der Kerne 3102(A)-(N), eine Menge von einer oder mehreren gemeinsam genutzten Cacheeinheits-Schaltungsanordnungen 3106 und externen Speicher (nicht gezeigt), der mit der Menge von integrierten Speichersteuerungseinheits-Schaltungsanordnungen 3114 gekoppelt ist. Die Menge von einer oder mehreren gemeinsam genutzten Cacheeinheits-Schaltungsanordnungen 3106 kann einen oder mehrere Mid-Level-Caches, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen, wie etwa einen Cache auf der untersten Ebene (LLC, Last Level Cache) und/oder Kombinationen davon umfassen. Während in manchen Beispielen die ringbasierte Zwischenverbindungs-Netzwerkschaltungsanordnung 3112 die spezielle Logik 3108 (z. B. integrierte Grafiklogik), die Menge gemeinsam genutzter Cacheeinheits-Schaltungsanordnungen 3106 und die Systemagenteneinheits-Schaltungsanordnungen 3110 miteinander verbindet, verwenden alternative Beispiele eine beliebige Anzahl wohlbekannter Techniken zum Verbinden solcher Einheiten. In einigen Beispielen wird Kohärenz zwischen einer oder mehreren der gemeinsam genutzten Cacheeinheits-Schaltungsanordnungen 3106 und Kernen 3102(A)-(N) aufrechterhalten.
In einigen Beispielen sind einer oder mehrere der Kerne 3102(A)-(N) zum Multithreading fähig. Die Systemagenteneinheits-Schaltungsanordnung 3110 beinhaltet jene Komponenten, die die Kerne 3102(A)-(N) koordinieren und betreiben. Die Systemagenteneinheits-Schaltungsanordnung 3110 kann zum Beispiel eine Leistungssteuerungseinheits- bzw. PCU-Schaltungsanordnung und/oder eine Anzeigeeinheits-Schaltungsanordnung (nicht gezeigt) beinhalten. Die PCU kann Logik und Komponenten sein oder beinhalten, die zum Regeln des Leistungszustands der Kerne 3102(A)-(N) und/oder der speziellen Logik 3108 (z. B. integrierte Grafiklogik) benötigt werden. Die Anzeigeeinheits-Schaltungsanordnung dient zum Ansteuern einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 3102(A)-(N) können homogen oder heterogen in Bezug auf den Architekturbefehlssatz sein; das heißt, zwei oder mehr der Kerne 3102(A)-(N) können zum Ausführen des gleichen Befehlssatzes in der Lage sein, während andere Kerne möglicherweise in der Lage sind, nur einen Teilsatz dieses Befehlssatzes oder einen unterschiedlichen Befehlssatz auszuführen.
Beispielhafte Kernarchitekturen
Blockdiagramm zu reihenfolgetreuem (In-order) und reihenfolgeverändertem (Out-of-order) Kern
32(A) ist ein Blockdiagramm, das sowohl eine beispielhafte reihenfolgetreue Pipeline als auch eine beispielhafte reihenfolgeveränderte Ausgabe-/Ausführungspipeline mit Registerumbenennung gemäß Beispielen der Erfindung veranschaulicht. 32(B) ist ein Blockdiagramm, das sowohl ein beispielhaftes Beispiel für einen reihenfolgetreuen Architekturkern als auch einen beispielhaften reihenfolgeveränderten Ausgabe-/Ausführungsarchitekturkern mit Registerumbenennung, der in einen Prozessor aufzunehmen ist, gemäß Beispielen der Erfindung veranschaulicht. Die Felder mit durchgezogenen Linien in 32(A)-(B) stellen die reihenfolgetreue Pipeline und den reihenfolgetreuen Kern dar, während die optionale Hinzufügung von Feldern mit gestrichelten Linien die/den reihenfolgeveränderte(n) Ausgabe-/Ausführungspipeline bzw. -kern mit Registerumbenennung darstellt. Unter der Voraussetzung, dass der reihenfolgetreue Aspekt eine Teilmenge des reihenfolgeveränderten Aspekts ist, wird der reihenfolgeveränderte Aspekt beschrieben.
In 32(A) umfasst eine Prozessorpipeline 3200 eine Abrufstufe 3202, eine optionale Längendecodierstufe 3204, eine Decodierstufe 3206, eine optionale Zuordnungsstufe 3208, eine optionale Umbenennungsstufe 3210, eine Ablaufsteuerungsstufe (Scheduling, auch als Verteilung oder Ausgabe bekannt) 3212, eine optionale Registerlese-/Speicherlesestufe 3214, eine Ausführungsstufe 3216, eine Zurückschreibe-/Speicherschreibestufe 3218, eine optionale Ausnahmenbehandlungsstufe 3222 und eine optionale Übergabestufe 3224. In jeder dieser Prozessor-Pipeline-Stufen können eine oder mehrere Operationen durchgeführt werden. Zum Beispiel werden während der Abrufstufe 3202 ein oder mehrere Befehle aus dem Befehlsspeicher abgerufen, während der Decodierungsstufe 3206 können der eine oder die mehreren abgerufenen Befehle decodiert werden, Adressen (z. B. Ladespeichereinheit- bzw. LSU-Adressen) können unter Verwendung weitergeleiteter Registerports erzeugt werden und Verzweigungsweiterleitung (z. B. Direktoperanden-Offset oder ein Verbindungsregister (LR)) kann durchgeführt werden. In einem Beispiel können die Decodierstufe 3206 und die Registerlese-/Speicherlesestufe 3214 in einer Pipeline-Stufe kombiniert sein. In einem Beispiel können während der Ausführungsstufe 3216 die decodierten Befehle ausgeführt werden, LSU-Adress-/Daten-Pipelining zu einer Advanced-Microcontroller-Bus- bzw. AHB-Schnittstelle kann durchgeführt werden, Multiplikations- und Additionsoperationen können durchgeführt werden, arithmetische Operationen mit Verzweigungsergebnissen können durchgeführt werden usw.
Beispielsweise kann die beispielhafte Kernarchitektur für reihenfolgeveränderte Ausgabe/Ausführung mit Registerumbenennung die Pipeline 3200 wie folgt implementieren: 1) der Befehlsabruf 3238 führt die Abruf- und die Längendecodierstufen 3202 und 3204 durch; 2) die Decodiereinheits-Schaltungsanordnung 3240 führt die Decodierstufe 3206 durch; 3) die Umbenennungs-/Zuordnungseinheits-Schaltungsanordnung 3252 führt die Zuordnungsstufe 3208 und die Umbenennungsstufe 3210 durch; 4) die Ablaufsteuerungseinheits-Schaltungsanordnung(en) 3256 führt bzw. führen die Ablaufsteuerungsstufe 3212 durch; 5) die physische(n) Registerdatei(en)einheits-Schaltungsanordnungen 3258 und die Speichereinheits-Schaltungsanordnung 3270 führen die Registerlese-/Speicherlesestufe 3214 durch; der Ausführungscluster 3260 führt die Ausführungsstufe 3216 durch; 6) die Speichereinheits-Schaltungsanordnung 3270 und die physische(n) Registerdatei(en)einheits-Schaltungsanordnungen 3258 führen die Zurückschreibe-/Speicherschreibestufe 3218 durch; 7) verschiedene Einheiten (Einheits-Schaltungsanordnungen) können bei der Ausnahmenbehandlungsstufe 3222 beteiligt sein; und 8) die Rückzugseinheit 3254 und die physische(n) Registerdatei(en)einheits-Schaltungsanordnungen 3258 führen die Übergabestufe 3224 durch.
32(B) zeigt den Prozessorkern 3290, eine mit einer Ausführungsengine-Einheits-Schaltungsanordnung 3250 gekoppelte Frontend-Einheits-Schaltungsanordnung 3230 umfassend, und wobei beide mit einer Speichereinheits-Schaltungsanordnung 3270 gekoppelt sind. Der Kern 3290 kann ein Kern mit reduziertem Befehlssatz (RISC, Reduced Instruction Set Computing), ein Kern mit komplexem Befehlssatz (CISC, Complex Instruction Set Computing), ein Kern mit sehr langen Befehlswörtern (VLIW, Very Long Instruction Word) oder ein hybrider oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 3290 ein spezieller Kern sein, wie etwa, beispielsweise, ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Koprozessorkern, ein universeller Berechnungskern für Grafikprozessoreinheiten (GPGPU, General Purpose Computing Graphics Processing Unit), ein Grafikkern oder ähnliches.
Die Frontend-Einheits-Schaltungsanordnung 3230 kann eine Verzweigungsvorhersageeinheits-Schaltungsanordnung 3232 beinhalten, die mit einer Befehlscacheeinheits-Schaltungsanordnung 3234 gekoppelt ist, die mit einem Befehlsübersetzungspuffer (TLB) 3236 gekoppelt ist, der mit einer Befehlsabrufeinheits-Schaltungsanordnung 3238 gekoppelt ist, die mit einer Decodierungseinheits-Schaltungsanordnung 3240 gekoppelt ist. In einem Beispiel ist die Befehlscacheeinheits-Schaltungsanordnung 3234 in der Speichereinheits-Schaltungsanordnung 3270 anstelle der Frontend-Einheits-Schaltungsanordnung 3230 enthalten. Die Decodiereinheits-Schaltungsanordnung 3240 (oder Decodierer) kann Befehle decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocodeeinstiegspunkte, Mikrobefehle oder Befehle oder andere Steuersignale decodieren, die aus den ursprünglichen Befehlen decodiert werden oder diese anderweitig widerspiegeln oder aus diesen abgeleitet sind. Die Decodiereinheits-Schaltungsanordnung 3240 kann ferner eine Adresserzeugungseinheits-Schaltungsanordnung (AGU, nicht gezeigt) beinhalten. In einem Beispiel erzeugt die AGU eine LSU-Adresse unter Verwendung weitergeleiteter Registerports und kann ferner Verzweigungsweiterleitung (z. B. Direktoperanden-Offset-Verzweigungsweiterleitung, LR-Registerverzweigungsweiterleitung usw.) durchführen. Die Decodiereinheits-Schaltungsanordnung 3240 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele für geeignete Mechanismen beinhalten unter anderem Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikarrays (PLAs), Mikrocode-Nur-Lese-Speicher (ROMs) usw. In einem Beispiel beinhaltet der Kern 3290 einen Mikrocode-ROM (nicht gezeigt) oder ein anderes Medium, das Mikrocode für gewisse Makrobefehle speichert (z. B. in Decodiereinheits-Schaltungsanordnung 3240 oder anderweitig innerhalb der Frontend-Einheits-Schaltungsanordnung 3230). In einem Beispiel beinhaltet die Decodiereinheits-Schaltungsanordnung 3240 eine Mikrooperation (Mikro-Op) oder einen Operations-Cache (nicht gezeigt), um decodierte Operationen, Mikro-Tags oder Mikrooperationen, die während der Decodierung oder anderer Stufen der Prozessor-Pipeline 3200 erzeugt werden, zu halten/zwischenzuspeichern. Die Decodiereinheits-Schaltungsanordnung 3240 kann mit der Umbenennungs-/Zuordnungseinheits-Schaltungsanordnung 3252 in der Ausführungsengine-Einheits-Schaltungsanordnung 3250 gekoppelt sein.
Die Ausführungsengine-Schaltungsanordnung 3250 beinhaltet die Umbenennungs-/Zuordnungseinheits-Schaltungsanordnung 3252, die mit einer Rückzugseinheits-Schaltungsanordnung 3254 und einer Menge von einer oder mehreren Ablaufsteuerungs-Schaltungsanordnung(en) 3256 gekoppelt ist. Der eine oder die mehreren Ablaufsteuerungen 3256 repräsentieren eine beliebige Anzahl unterschiedlicher Ablaufsteuerungen, einschließlich Reservierungsstationen, ein zentrales Befehlsfenster usw. In manchen Beispielen kann/können die Ablaufsteuerungs-Schaltungsanordnung(en) 3256 eine Ablaufsteuerung/Ablaufsteuerungs-Schaltungsanordnung einer arithmetischen Logikeinheit (ALU), ALU-Warteschlangen, eine Ablaufsteuerung/Ablaufsteuerungs-Schaltungsanordnung einer arithmetischen Erzeugungseinheit (AGU), AGU-Warteschlangen usw. beinhalten. Die Ablaufsteuerungs-Schaltungsanordnung(en) 3256 ist (sind) mit der bzw. den physischen Registerdatei(en)-Schaltungsanordnung(en) 3258 gekoppelt. Jede der physischen Registerdatei(en)-Schaltungsanordnungen 3258 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie etwa skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektor-Ganzzahl, Vektor-Gleitkomma, Status (z. B. ein Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. In einem Beispiel beinhaltet bzw. beinhalten die physische(n) Registerdatei(en)-Einheits-Schaltungsanordnung(en) 3258 eine Vektorregistereinheits-Schaltungsanordnung, eine Schreibmaskenregistereinheits-Schaltungsanordnung und eine Skalarregistereinheits-Schaltungsanordnung. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister, Universalregister usw. bereitstellen. Die physische(n) Registerdatei(en)-Einheits-Schaltungsanordnung(en) 3258 wird bzw. werden von der Rückzugseinheits-Schaltungsanordnung 3254 (auch als Rückzugswarteschlange oder Rückzugswarteschlange bekannt) überlappt, um verschiedene Weisen zu veranschaulichen, auf die Registerumbenennung und reihenfolgeveränderte Ausführung implementiert werden können (z. B. Verwenden eines oder mehrerer Neuordnungspuffer (ROB(s)) und einer oder mehrerer Rückzugsregisterdateien; Verwenden einer oder mehrerer zukünftiger Dateien, eines oder mehrerer Verlaufspuffer und einer oder mehrerer Rückzugsregisterdateien; Verwenden einer Registerabbildung und eines Pools von Registern usw.). Die Rückzugseinheits-Schaltungsanordnung 3254 und die physische(n) Registerdatei(en)-Schaltungsanordnungen 3258 sind mit dem bzw. den Ausführungscluster(n) 3260 gekoppelt. Der bzw. die Ausführungscluster 3260 umfassen eine Menge von einer oder mehreren Ausführungseinheits-Schaltungsanordnungen 3262 und eine Menge von einer oder mehreren Speicherzugriffs-Schaltungsanordnungen 3264. Die Ausführungseinheits-Schaltungsanordnung 3262 kann verschiedene arithmetische, logische, Gleitkomma- oder andere Arten von Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Arten von Daten (z. B. skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektor-Ganzzahl, Vektor-Gleitkomma) durchführen. Obwohl manche Beispiele eine Anzahl von Ausführungseinheiten oder Ausführungseinheits-Schaltungsanordnungen beinhalten können, die speziell für spezifische Funktionen oder Mengen von Funktionen bestimmt sind, können andere Beispiele nur eine Ausführungseinheits-Schaltungsanordnung oder mehrere Ausführungseinheiten/Ausführungseinheits-Schaltungsanordnungen beinhalten, die allesamt alle Funktionen durchführen. Die Ablaufsteuerungseinheits-Schaltungsanordnung(en) 3256, die physischen Registerdatei(en)einheits-Schaltungsanordnung(en) 3258 und das bzw. die Ausführungscluster 3260 werden als möglicherweise mehrere gezeigt, da gewisse Ausführungsformen separate Pipelines für gewisse Typen von Daten/Operationen erzeugen (z. B. eine skalare ganzzahlige Pipeline, eine skalare Gleitkomma-/gepackte ganzzahlige/gepackte Gleitkomma-/Vektorganzzahl-/Vektorgleitkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Ablaufsteuerungs-Schaltungsanordnung, physische Registerdatei(en)einheits-Schaltungsanordnung und/oder Ausführungscluster haben - und im Falle einer separaten Speicherzugriffspipeline sind gewisse Beispiele umgesetzt, bei denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheits-Schaltungsanordnung(en) 3264 hat). Es versteht sich auch, dass, wenn getrennte Pipelines verwendet werden, eine oder mehrere dieser Pipelines reihenfolgeveränderte Ausgabe/Ausführung-Pipelines und der Rest reihenfolgetreue Pipelines sein können.
In einigen Beispielen kann die Ausführungsengine-Einheits-Schaltungsanordnung 3250 Ladespeichereinheit- bzw. LSU-Adress-/Daten-Pipelining zu einer Advanced-Microcontroller-Bus- bzw. AHB-Schnittstelle (nicht gezeigt) und Adressphasen und Rückschreiben, Datenphasen-Laden, Speichern und Verzweigungen durchführen.
Die Menge von Speicherzugriffs-Schaltungsanordnungen 3264 ist mit der Speichereinheits-Schaltungsanordnung 3270 gekoppelt, die eine Daten-TLB-Einheits-Schaltungsanordnung 3272 beinhaltet, die mit einer Datencache-Schaltungsanordnung 3274 gekoppelt ist, die mit einer Level-2- bzw. L2-Cacheschaltungsanordnung 3276 gekoppelt ist. In einem beispielhaften Beispiel können die Speicherzugriffseinheits-Schaltungsanordnungen 3264 eine Ladeeinheits-Schaltungsanordnung, eine Adressspeichereinheits-Schaltungsanordnung und eine Datenspeichereinheits-Schaltungsanordnung beinhalten, von denen jede mit der Daten-TLB-Schaltungsanordnung 3272 in der Speichereinheits-Schaltungsanordnung 3270 gekoppelt ist. Die Befehlscache-Schaltungsanordnung 3234 ist ferner mit einer Level-2- bzw. L2-Cacheeinheits-Schaltungsanordnung 3276 in der Speichereinheits-Schaltungsanordnung 3270 gekoppelt. In einem Beispiel sind der Befehlscache 3234 und der Datencache 3274 zu einem einzigen Befehls- und Datencache (nicht gezeigt) in einer L2-Cacheeinheits-Schaltungsanordnung 3276, einer Level-3-bzw. L3-Cacheeinheits-Schaltungsanordnung (nicht gezeigt) und/oder einem Hauptspeicher kombiniert. Die L2-Cacheeinheits-Schaltungsanordnung 3276 ist mit einer oder mehreren anderen Cache-Ebenen und schließlich mit einem Hauptspeicher gekoppelt.
Der Kern 3290 kann einen oder mehrere Befehlssätze (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen, wie etwa NEON) unterstützen, einschließlich der hier beschriebenen Befehle. In einem Beispiel umfasst der Kern 3290 Logik zum Unterstützen einer Befehlssatzerweiterung mit gepackten Daten (z. B. AVX1, AVX2), dadurch ermöglichend, dass Operationen, die von vielen Multimedia-Anwendungen verwendet werden, mit gepackten Daten durchgeführt werden.
Beispielhafte Ausführungseinheits-Schaltungsanordnung(en)
33 veranschaulicht Beispiele für Ausführungseinheits-Schaltungsanordnung(en), wie etwa Ausführungseinheits-Schaltungsanordnung(en) 3262 aus 32(B). Wie veranschaulicht, kann/können die Ausführungseinheits-Schaltungsanordnung(en) 3262 eine oder mehrere ALU-Schaltungen 3301, Vektor/SIMD-Einheitsschaltungen 3303, Lade/Speicher-Einheitsschaltungen 3305 und/oder Verzweigungs-/Sprungeinheitsschaltungen 3307 beinhalten. Die ALU-Schaltungen 3301 führen ganzzahlige arithmetische und/oder boolesche Operationen durch. Die Vektor/SIMD-Einheitsschaltungen 3303 führen Vektor/SIMD-Operationen an gepackten Daten (wie etwa SIMD-/Vektorregistern) durch. Die Lade/Speicher-Einheitsschaltungen 3305 führen Lade- und Speicherbefehle aus, um Daten aus dem Speicher in Register zu laden oder von Registern im Speicher zu speichern. Die Lade/Speicher-Einheitsschaltungen 3305 können auch Adressen erzeugen. Verzweigungs-/Sprungeinheitsschaltungen 3307 bewirken je nach Befehl eine Verzweigung oder einen Sprung zu einer Speicheradresse. Gleitkommaeinheits- bzw. FPU-Schaltungen 3309 führen Gleitkomma-Arithmetik durch. Die Breite der Ausführungseinheits-Schaltungsanordnung(en) 3262 variiert in Abhängigkeit von dem Beispiel und kann von 16 Bit bis 1.024 Bit reichen. In einigen Beispielen werden zwei oder mehr kleinere Ausführungseinheiten logisch kombiniert, um eine größere Ausführungseinheit zu bilden (z. B. zwei 128-Bit-Ausführungseinheiten werden logisch kombiniert, um eine 256-Bit-Ausführungseinheit zu bilden).
Beispielhafte Registerarchitektur
34 ist ein Blockdiagramm einer Registerarchitektur gemäß einigen Beispielen. Wie dargestellt, gibt es Vektor-/SIMD-Register 3410, deren Breite von 128 Bit bis 1.024 Bit variiert. In einigen Beispielen sind die Vektor-/SIMD-Register 3410 physisch 512 Bits, und in Abhängigkeit von der Abbildung werden nur einige der unteren Bits verwendet. In einigen Beispielen sind die Vektor-/SIMD-Register 3410 zum Beispiel ZMM-Register, die 512 Bits sind: die unteren 256 Bits werden für YMM-Register verwendet, und die unteren 128 Bits werden für XMM-Register verwendet. Von daher gibt es eine Überlagerung von Registern. In einigen Beispielen wählt ein Vektorlängenfeld zwischen einer maximalen Länge und einer oder mehreren kürzeren Längen, wobei jede solche kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist. Skalaroperationen sind Operationen, die an der niedrigstwertigen Datenelementposition in einem ZMM/YMM/XMM-Register durchgeführt werden; die höherwertigen Datenelementpositionen werden je nach Beispiel entweder gleich gelassen wie vor dem Befehl oder auf Null gesetzt.
In einigen Beispielen umfasst die Registerarchitektur 3400 Schreibmasken - /Prädikatregister 3415. In einigen Beispielen gibt es zum Beispiel 8 Schreibmasken-/Prädikatregister (manchmal als k0 bis k7 bezeichnet), die jeweils 16 Bit, 32 Bit, 64 Bit oder 128 Bit groß sind. Schreibmasken-/Prädikatregister 3415 können Zusammenführen (wodurch z. B. ermöglicht wird, dass eine beliebige Menge von Elementen im Ziel vor Aktualisierungen während der Ausführung einer beliebigen Operation geschützt wird) und/oder Nullsetzen (z. B. Nullsetzen von Vektormasken kann ermöglichen, dass eine beliebige Menge von Elementen im Ziel während der Ausführung einer beliebigen Operation auf Null gesetzt wird) ermöglichen. In einigen Beispielen entspricht jede Datenelementposition in einem gegebenen Schreibmasken-/Prädikatregister 3415 einer Datenelementposition des Ziels. In anderen Beispielen sind die Schreibmasken-/Prädikatregister 3415 skalierbar und bestehen aus einer festgelegten Anzahl von Freigabebits für ein gegebenes Vektorelement (z. B. 8 Freigabebits pro 64-Bit-Vektorelement).
Die Registerarchitektur 3400 umfasst mehrere Universalregister 3425. Diese Register können 16-Bit, 32-Bit, 64-Bit usw. sein und können für Skalaroperationen verwendet werden. In einigen Beispielen werden diese Register mit RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
In einigen Beispielen beinhaltet die Registerarchitektur 3400 ein skalares Gleitkommaregister 3445, das für skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung oder als MMX-Register verwendet wird, um Operationen an gepackten 64-Bit-Ganzzahldaten durchzuführen sowie Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
Ein oder mehrere Flag-Register 3440 (z. B. EFLAGS, RFLAGS usw.) speichern Status- und Steuerinformationen für arithmetische, Vergleichs- und Systemoperationen. Das eine oder die mehreren Flag-Register 3440 können zum Beispiel Bedingungscodeinformationen, wie etwa Übertrag, Parität, Hilfsübertrag, Null, Vorzeichen und Überlauf, speichern. In einigen Beispielen werden das eine oder die mehreren Flag-Register 3440 Programmstatus- und Steuerregister genannt.
Segmentregister 3420 enthalten Segmentpunkte zur Verwendung beim Zugreifen auf Speicher. In einigen Beispielen werden diese Register durch die Namen CS, DS, SS, ES, FS und GS referenziert.
Maschinenspezifische Register (MSRs) 3435 steuern und melden über die Prozessorleistung. Die meisten MSRs 3435 handhaben systembezogene Funktionen und sind für ein Anwendungsprogramm nicht zugänglich. Die Maschinenprüfregister 3460 bestehen aus Steuer-, Status- und Fehlermeldungs-MSRs, die zum Erkennen und Melden von Hardwarefehlern verwendet werden.
Ein oder mehrere Befehlszeigerregister 3430 speichern einen Befehlszeigerwert. Steuerregister 3455 (z. B. CR0-CR4) bestimmen den Betriebsmodus eines Prozessors (z. B. Prozessor 3070, 3080, 3038, 3015 und/oder 3100) und die Charakteristiken einer aktuell ausgeführten Aufgabe. Debug-Register 3450 steuern und ermöglichen die Überwachung der Debug-Operationen eines Prozessors oder Kerns.
Die Speicherverwaltungsregister 3465 spezifizieren die Orte von Datenstrukturen, die bei der Speicherverwaltung im geschützten Modus verwendet werden. Diese Register können ein GDTR, IDRT, ein Aufgabenregister und ein LDTR-Register beinhalten.
Alternative Beispiele der Erfindung können breitere oder schmalere Register verwenden. Zusätzlich dazu können alternative Beispiele der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
Befehlssätze
Eine Befehlssatzarchitektur (ISA) kann ein oder mehrere Befehlsformate beinhalten. Ein gegebenes Befehlsformat kann verschiedene Felder (z. B. Anzahl an Bits, Position von Bits) definieren, um unter anderem die durchzuführende Operation (z. B. Opcode) und den/die Operand(en), an dem/denen die Operation durchzuführen ist, und/oder (ein) andere(s) Datenfeld(er) (z. B. Maske) zu spezifizieren. Einige Befehlsformate werden durch die Definition von Befehlsvorlagen (oder Unterformaten) weiter aufgeteilt. Zum Beispiel können die Befehlsvorlagen eines gegebenen Befehlsformats so definiert sein, dass sie unterschiedliche Teilsätze der Felder des Befehlsformats aufweisen (die enthaltenen Felder sind typischerweise in der gleichen Reihenfolge, aber zumindest manche weisen unterschiedliche Bitpositionen auf, weil dort weniger Felder enthalten sind), und/oder so definiert sein, dass sie ein gegebenes Feld aufweisen, das unterschiedlich interpretiert wird. Daher wird jeder Befehl einer ISA unter Verwendung eines gegebenen Befehlsformats (und, wenn definiert, in einer gegebenen der Befehlsvorlagen dieses Befehlsformats) ausgedrückt und umfasst Felder zum Angeben der Operation und der Operanden. Beispielsweise hat ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein Befehlsformat, das ein Opcode-Feld zum Angeben dieses Opcodes und Operandenfelder zum Auswählen von Operanden (Quelle1/Ziel und Quelle2) umfasst; und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom hat spezifische Inhalte in den Operandenfeldern, die spezifische Operanden auswählen.
Beispielhafte Befehlsformate
Beispiele des bzw. der hier beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt sein. Zusätzlich werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich beschrieben. Beispiele des bzw. der Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf diese aufgeführten beschränkt.
35 veranschaulicht Beispiele für ein Befehlsformat. Wie veranschaulicht, kann ein Befehl mehrere Komponenten beinhalten, einschließlich unter anderem eines oder mehrerer Felder für: ein oder mehrere Präfixe 3501, einen Opcode 3503, Adressierungsinformationen 3505 (z. B. Registeridentifikatoren, Speicheradressierungsinformationen usw.), einen Verschiebungswert 3507 und/oder einen Direktoperanden 3509. Es ist anzumerken, dass einige Befehle manche oder alle der Felder des Formats nutzen, wohingegen andere möglicherweise nur das Feld für den Opcode 3503 verwenden. In einigen Beispielen ist die dargestellte Reihenfolge die Reihenfolge, in der diese Felder zu codieren sind, es versteht sich jedoch, dass diese Felder in anderen Beispielen in einer anderen Reihenfolge codiert, kombiniert usw. werden können.
Das eine oder die mehreren Präfixfelder 3501 modifizieren, wenn verwendet, einen Befehl. In einigen Beispielen werden ein oder mehrere Präfixe verwendet, um Zeichenfolgenbefehle (z. B. 0xF0, 0xF2, 0xF3 usw.) zu wiederholen, Abschnittsüberschreibungen (z. B. 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E usw.) bereitzustellen, Bussperroperationen durchzuführen und/oder Operanden- (z. B. 0x66) und Adressgrößen (z. B. 0x67) zu ändern. Bestimmte Befehle erfordern ein obligatorisches Präfix (z. B. 0x66, 0xF2, 0xF3 usw.). Bestimmte dieser Präfixe können als „Legacy“-Präfixe angesehen werden. Andere Präfixe, von denen ein oder mehrere Beispiele hierin ausführlich beschrieben sind, geben weitere Fähigkeit an und/oder stellen diese bereit, wie etwa Spezifizieren spezieller Register usw. Die anderen Präfixe folgen typischerweise den „Legacy“-Präfixen.
Das Opcode-Feld 3503 wird verwendet, um die Operation, die bei einer Decodierung des Befehls durchzuführen ist, zumindest teilweise zu definieren. In einigen Beispielen weist ein primärer Opcode, der in dem Opcode-Feld 3503 codiert ist, eine Länge von 1, 2 oder 3 Byte auf. In anderen Beispielen kann ein primärer Opcode eine andere Länge aufweisen. Ein zusätzliches 3-Bit-Opcode-Feld wird manchmal in einem anderen Feld codiert.
Das Adressierungsfeld 3505 wird verwendet, um einen oder mehrere Operanden des Befehls zu adressieren, wie etwa einen Ort im Speicher oder ein oder mehrere Register. 36 stellt Beispiele für das Adressierungsfeld 3505 dar. In dieser Darstellung sind ein optionales ModR/M-Byte 3602 und ein optionales Skalierung-Index-Basis- bzw. SIB-Byte 3604 gezeigt. Das ModR/M-Byte 3602 und das SIB-Byte 3604 werden verwendet, um bis zu zwei Operanden eines Befehls zu codieren, von denen jeder ein direktes Register oder eine effektive Speicheradresse ist. Es ist anzumerken, dass jedes dieser Felder insofern optional ist, als nicht alle Befehle eines oder mehrere dieser Felder beinhalten. Das ModR/M-Byte 3602 umfasst ein MOD-Feld 3642, ein Registerfeld 3644 und ein R/M-Feld 3646.
Der Inhalt des MOD-Feldes 3642 unterscheidet zwischen Speicherzugriffs- und Nichtspeicherzugriffsmodi. In einigen Beispielen wird, wenn das MOD-Feld 3642 einen Wert von b11 aufweist, ein registerdirekter Adressierungsmodus genutzt, und andernfalls wird registerindirekte Adressierung verwendet.
Das Registerfeld 3644 kann entweder den Zielregisteroperanden oder einen Quellregisteroperanden codieren oder kann eine Opcode-Erweiterung codieren und nicht zum Codieren irgendeines Befehlsoperanden verwendet werden. Der Inhalt des Registerindexfelds 3644 spezifiziert direkt oder durch Adresserzeugung die Orte eines Quell- oder Zieloperanden (entweder in einem Register oder im Speicher). In einigen Beispielen wird das Registerfeld 3644 mit einem zusätzlichen Bit von einem Präfix (z. B. Präfix 3501) ergänzt, um eine größere Adressierung zu ermöglichen.
Das R/M-Feld 3646 kann verwendet werden, um einen Befehlsoperanden zu codieren, der auf eine Speicheradresse verweist, oder kann verwendet werden, um entweder den Zielregisteroperanden oder einen Quellregisteroperanden zu codieren. Es ist anzumerken, dass das R/M-Feld 3646 in manchen Beispielen mit dem MOD-Feld 3642 kombiniert werden kann, um einen Adressierungsmodus vorzugeben.
Das SIB-Byte 3604 beinhaltet ein Skalierungsfeld 3652, ein Indexfeld 3654 und ein Basisfeld 3656, die bei der Erzeugung einer Adresse zu verwenden sind. Das Skalierungsfeld 3652 gibt den Skalierungsfaktor an. Das Indexfeld 3654 spezifiziert ein zu verwendendes Indexregister. In einigen Beispielen wird das Indexfeld 3654 mit einem zusätzlichen Bit von einem Präfix (z. B. Präfix 3501) ergänzt, um eine größere Adressierung zu ermöglichen. Das Basisfeld 3656 spezifiziert ein zu verwendendes Basisregister. In einigen Beispielen wird das Basisfeld 3656 mit einem zusätzlichen Bit von einem Präfix (z. B. Präfix 3501) ergänzt, um eine größere Adressierung zu ermöglichen. In der Praxis ermöglicht der Inhalt des Skalierungsfelds 3652 die Skalierung des Inhalts des Indexfelds 3654 für Speicheradresserzeugung (z. B. für Adresserzeugung, die 2^Skalierung * Index + Basis verwendet).
Manche Adressierungsformen nutzen einen Verschiebungswert, um eine Speicheradresse zu erzeugen. Zum Beispiel kann eine Speicheradresse gemäß 2^Skalierung * Index + Basis + Verschiebung, Index*Skalierung + Verschiebung, r/m + Verschiebung, Befehlszeiger (RIP/EIP) + Verschiebung, Register + Verschiebung usw. erzeugt werden. Die Verschiebung kann ein 1 Byte, 2 Byte, 4 Byte usw. großer Wert sein. In einigen Beispielen stellt ein Verschiebungsfeld 3507 diesen Wert bereit. Zusätzlich wird in einigen Beispielen eine Verschiebungsfaktorverwendung in dem MOD-Feld des Adressierungsfelds 3505 codiert, die ein komprimiertes Verschiebungsschema angibt, für das ein Verschiebungswert durch Multiplizieren von disp8 in Verbindung mit einem Skalierungsfaktor N berechnet wird, der basierend auf der Vektorlänge, dem Wert eines b-Bits und der Eingabeelementgröße des Befehls bestimmt wird. Der Verschiebungswert wird in dem Verschiebungsfeld 3507 gespeichert.
In einigen Beispielen spezifiziert ein Direktoperandenfeld 3509 einen Direktoperanden für den Befehl. Ein Direktoperand kann als ein 1-Byte-Wert, ein 2-Byte-Wert, ein 4-Byte-Wert usw. codiert werden.
37 veranschaulicht Beispiele für ein erstes Präfix 3501(A). In einigen Beispielen ist das erste Präfix 3501(A) ein Beispiel für ein REX-Präfix. Befehle, die dieses Präfix verwenden, können universelle Register, 64-Bit-Register für gepackte Daten (z. B. Einzelbefehls-Mehrfachdaten- bzw. SIMD-Register oder Vektorregister) und/oder Steuerregister und Debug-Register (z. B. CR8-CR15 und D708-DR15) spezifizieren.
Befehle, die das erste Präfix 3501(A) verwenden, können je nach Format unter Verwendung von 3-Bit-Feldern bis zu drei Register spezifizieren: 1) Verwenden des reg-Feldes 3644 und des R/M-Feldes 3646 des Mod R/M-Bytes 3602; 2) Verwenden des Mod R/M-Bytes 3602 mit dem SIB-Byte 3604 einschließlich Verwenden des reg-Feldes 3644 und des Basisfelds 3656 und des Indexfelds 3654; oder 3) Verwenden des Registerfelds eines Opcodes.
Im ersten Präfix 3501(A) werden die Bitpositionen 7:4 als 0100 gesetzt. Bitposition 3 (W) kann verwendet werden, um die Operandengröße zu bestimmen, bestimmt aber möglicherweise nicht allein die Operandenbreite. Daher wird, wenn W = 0 ist, die Operandengröße durch einen Codesegmentdeskriptor (CS.D) bestimmt, und wenn W = 1 ist, beträgt die Operandengröße 64 Bit.
Es ist anzumerken, dass das Hinzufügen eines anderen Bits ermöglicht, dass 16 (2⁴) Register adressiert werden, wohingegen das MOD-R/M-reg-Feld 3644 und das MOD-R/M-R/M-Feld 3646 allein jeweils nur 8 Register adressieren können.
In dem ersten Präfix 3501(A) kann Bitposition 2 (R) eine Erweiterung des MOD-R/M-reg-Feldes 3644 sein und kann verwendet werden, um das ModR/M-reg-Feld 3644 zu modifizieren, wenn dieses Feld ein universelles Register, ein gepacktes 64-Bit-Datenregister (z. B. ein SSE-Register) oder ein Steuer- oder Debug-Register codiert. R wird ignoriert, wenn das Mod-R/M-Byte 3602 andere Register spezifiziert oder einen erweiterten Opcode definiert.
Bitposition 1 (X) X-Bit kann das SIB-Byteindexfeld 3654 modifizieren.
Die Bitposition B (B) B kann die Basis in dem Mod-R/M-R/M-Feld 3646 oder dem SIB-Byte-Basisfeld 3656 modifizieren; oder sie kann das Opcode-Registerfeld modifizieren, das zum Zugreifen auf universelle Register (z. B. universelle Register 3425) verwendet wird.
38(A)-(D) veranschaulichen Beispiele dafür, wie die R-, X- und B-Felder des ersten Präfixes 3501(A) verwendet werden. 38(A) veranschaulicht, wie R und B aus dem ersten Präfix 3501(A) verwendet werden, um das reg-Feld 3644 und das R/M-Feld 3646 des MOD-R/M-Bytes 3602 zu erweitern, wenn das SIB-Byte 3604 nicht zur Speicheradressierung verwendet wird. 38(B) veranschaulicht, wie R und B aus dem ersten Präfix 3501(A) verwendet werden, um das reg-Feld 3644 und das R/M-Feld 3646 des MOD-R/M-Bytes 3602 zu erweitern, wenn das SIB-Byte 3604 nicht verwendet wird (Register-Register-Adressierung). 38(C) veranschaulicht R, X und B von dem ersten Präfix 3501(A), das verwendet wird, um das REG-Feld 3644 des MOD-R/M-Bytes 3602 und das Indexfeld 3654 und das Basisfeld 3656 zu erweitern, wenn das SIB-BYTE 36 04 zur Speicheradressierung verwendet wird. 38(D) veranschaulicht, wie B aus dem ersten Präfix 3501(A) verwendet wird, um das reg-Feld 3644 des MOD-R/M-Bytes 3602 zu erweitern, wenn ein Register in dem Opcode 3503 codiert ist.
39(A)-(B) veranschaulichen Beispiele für ein zweites Präfix 3501(B). In einigen Beispielen ist das zweite Präfix 3501(B) ein Beispiel für ein VEX-Präfix. Die Codierung des zweiten Präfixes 3501(B) ermöglicht, dass Befehle mehr als zwei Operanden aufweisen, und ermöglicht, dass SIMD-Vektorregister (z. B. Vektor-/SIMD-Register 3410) länger als 64 Bit (z. B. 128 Bit und 256 Bit) sind. Die Verwendung des zweiten Präfixes 3501(B) stellt eine Syntax mit drei Operanden (oder mehr) bereit. Beispielsweise haben vorangegangene Befehle mit zwei Operanden Vorgänge durchgeführt wie A = A + B, die einen Quellenoperanden überschreiben. Die Verwendung des zweiten Präfixes 3501(B) ermöglicht Operanden, nichtdestruktive Operationen, wie etwa A = B + C, durchzuführen.
In einigen Beispielen kommt das zweite Präfix 3501(B) in zwei Formen vor - einer Zwei-Byte-Form und einer Drei-Byte-Form. Das zweite Zwei-Byte-Präfix 3501(B) wird hauptsächlich für 128-Bit-, skalare und einige 256-Bit-Befehle verwendet; während das zweite Drei-Byte-Präfix 3501(B) einen kompakten Ersatz des ersten Präfixes 3501(A) und der 3-Byte-Opcode-Anweisungen bereitstellt.
39(A) veranschaulicht Beispiele für eine Zwei-Byte-Form des zweiten Präfixes 3501(B). In einem Beispiel enthält ein Formatfeld 3901 (Byte 0 3903) den Wert C5H. In einem Beispiel beinhaltet Byte 13905 einen „R“-Wert in Bit [7]. Dieser Wert ist das Komplement desselben Wertes des ersten Präfixes 3501(A). Bit[2] wird verwendet, um die Länge (L) des Vektors vorzugeben (wobei ein Wert von 0 ein skalarer oder 128-Bit-Vektor ist und ein Wert von 1 ein 256-Bit-Vektor ist). Bits[1:0] stellen Opcode-Extensionalität bereit, die zu einigen älteren Präfixen äquivalent ist (z. B. 00 = kein Präfix, 01 = 66H, 10 = F3H und 11 = F2H). Bits[6:3], die als vvvv gezeigt sind, können verwendet werden zum: 1) Codieren des ersten Quellregisteroperanden, angegeben in invertierter Form (Einerkomplement) und ist gültig für Befehle mit 2 oder mehr Quelloperanden; 2) Codieren des Zielregisteroperanden, angegeben in Einerkomplementform für gewisse Vektorverschiebungen; oder 3) Nichtcodieren irgendeines Operanden, das Feld ist reserviert und sollte einen bestimmten Wert enthalten, wie etwa 1111b.
Befehle, die dieses Präfix verwenden, können das Mod-R/M-R/M-Feld 3646 verwenden, um den Befehlsoperanden zu codieren, der auf eine Speicheradresse verweist, oder entweder den Zielregisteroperanden oder einen Quellregisteroperanden zu codieren.
Befehle, die dieses Präfix verwenden, können das Mod-R/M-reg-Feld 3644 verwenden, um entweder den Zielregisteroperanden oder einen Quellregisteroperanden zu codieren, als eine Opcode-Erweiterung behandelt zu werden und nicht zum Codieren irgendeines Befehlsoperanden verwendet zu werden.
Für Befehlssyntax, die vier Operanden, vvvv, unterstützt, codieren das Mod-R/M-R/M-Feld 3646 und das Mod-R/M-reg-Feld 3644 drei der vier Operanden. Bits[7:4] des Direktoperanden 3509 werden dann verwendet, um den dritten Quellregisteroperanden zu codieren.
39(B) veranschaulicht Beispiele für eine Drei-Byte-Form des zweiten Präfixes 3501(B). In einem Beispiel enthält ein Formatfeld 3911 (Byte 0 3913) den Wert C4H. Byte 1 3915 beinhaltet in Bits [7:5] „R“, „X“ und „B“, die die Komplemente der gleichen Werte des ersten Präfixes 3501 (A) sind. Bits[4:0] des Bytes 1 3915 (als mmmmm gezeigt) beinhalten Inhalt zum Codieren, je nach Bedarf, eines oder mehrerer implizierter führender Opcode-Bytes. Zum Beispiel impliziert 00001 einen führenden 0Fh-Opcode, 00010 impliziert einen führenden 0F38H-Opcode, 00011 impliziert einen führenden 0F3AH-Opcode usw.
Bit[7] von Byte 2 3917 wird ähnlich W des ersten Präfixes 3501 (A) verwendet, was dabei hilft, unterstützbare Operandengrößen zu bestimmen. Bit[2] wird verwendet, um die Länge (L) des Vektors vorzugeben (wobei ein Wert von 0 ein skalarer oder 128-Bit-Vektor ist und ein Wert von 1 ein 256-Bit-Vektor ist). Bits[1:0] stellen Opcode-Extensionalität bereit, die zu einigen älteren Präfixen äquivalent ist (z. B. 00 = kein Präfix, 01 = 66H, 10 = F3H und 11 = F2H). Bits[6:3], als vvvv gezeigt, können verwendet werden zum: 1) Codieren des ersten Quellregisteroperanden, angegeben in invertierter Form (Einerkomplement) und ist gültig für Befehle mit 2 oder mehr Quelloperanden; 2) Codieren des Zielregisteroperanden, angegeben in Einerkomplementform für gewisse Vektorverschiebungen; oder 3) Nichtcodieren irgendeines Operanden, das Feld ist reserviert und sollte einen bestimmten Wert enthalten, wie etwa 1111b.
Befehle, die dieses Präfix verwenden, können das Mod-R/M-R/M-Feld 3646 verwenden, um den Befehlsoperanden zu codieren, der auf eine Speicheradresse verweist, oder entweder den Zielregisteroperanden oder einen Quellregisteroperanden zu codieren.
Befehle, die dieses Präfix verwenden, können das Mod-R/M-reg-Feld 3644 verwenden, um entweder den Zielregisteroperanden oder einen Quellregisteroperanden zu codieren, als eine Opcode-Erweiterung behandelt zu werden und nicht zum Codieren irgendeines Befehlsoperanden verwendet zu werden.
Für Befehlssyntax, die vier Operanden, vvvv, unterstützt, codieren das Mod-R/M-R/M-Feld 3646 und das Mod-R/M-reg-Feld 3644 drei der vier Operanden. Bits[7:4] des Direktoperanden 3509 werden dann verwendet, um den dritten Quellregisteroperanden zu codieren.
40 veranschaulicht Beispiele für ein drittes Präfix 3501(C). In einigen Beispielen ist das erste Präfix 3501(A) ein Beispiel für ein EVEX-Präfix. Das dritte Präfix 3501(C) ist ein Vier-Byte-Präfix.
Das dritte Präfix 3501(C) kann 32 Vektorregister (z. B. 128-Bit-, 256-Bit- und 512-Bit-Register) im 64-Bit-Modus codieren. In einigen Beispielen nutzen Befehle, die eine Schreibmaske/Opmaske (siehe Erörterung von Registern in einer vorherigen Figur, wie etwa 34) oder Prädikation nutzen, dieses Präfix. Opmaskenregister ermöglichen bedingte Verarbeitungs- oder Auswahlsteuerung. Opmaskenanweisungen, deren Quell-/Zieloperanden Opmaskenregister sind und die den Inhalt eines Opmaskenregisters als einen einzigen Wert behandeln, werden unter Verwendung des zweiten Präfixes 3501(B) codiert.
Das dritte Präfix 3501(C) kann Funktionalität codieren, die für Befehlsklassen spezifisch ist (z. B. ein gepackter Befehl mit „Laden+op“-Semantik kann eingebettete Broadcast-Funktionalität unterstützen, ein Gleitkomma-Befehl mit Rundungssemantik kann statische Rundungsfunktionalität unterstützen, ein Gleitkomma-Befehl mit arithmetischer Nichtrundungssemantik kann eine Funktionalität „Unterdrücken aller Ausnahmen“ unterstützen usw.).
Das erste Byte des dritten Präfixes 3501(C) ist ein Formatfeld 4011, das in einem Beispiel einen Wert von 62H aufweist. Nachfolgende Bytes werden als Nutzdatenbytes 4015-4019 bezeichnet und bilden gemeinsam einen 24-Bit-Wert von P[23:0], der eine spezifische Fähigkeit bereitstellt, in Form eines oder mehrerer Felder (hier ausführlich beschrieben).
In einigen Beispielen sind P[1:0] des Nutzdatenbytes 4019 identisch mit den unteren zwei mmmmm-Bits. P[3:2] sind in einigen Beispielen reserviert. Bit P[4] (R') ermöglicht Zugriff auf den hohen 16-Vektorregistersatz, wenn es mit P[7] und dem ModR/M-reg-Feld 3644 kombiniert wird. P[6] kann auch Zugriff auf ein hohes 16-Vektorregister bereitstellen, wenn keine SIB-Typ-Adressierung benötigt wird. P[7:5] bestehen aus einem R, X und B, die Operandenkennungsmodifikatorbits für Vektorregister, universelle Register, Speicheradressierung sind und Zugriff auf den nächsten Satz von 8 Registern jenseits der unteren 8 Register erlauben, wenn sie mit dem ModR/M-Registerfeld 3644 und dem ModR/M-R/M-Feld 3646 kombiniert werden. P[9:8] stellen Opcode-Extensionalität bereit, die zu einigen älteren Präfixen äquivalent ist (z. B. 00 = kein Präfix, 01 = 66H, 10 = F3H und 11 = F2H). P[10] ist in einigen Beispielen ein fester Wert von 1. P[14:11], gezeigt als vvvv, kann verwendet werden zum: 1) Codieren des ersten Quellregisteroperanden, angegeben in invertierter Form (Einerkomplement) und ist gültig für Befehle mit 2 oder mehr Quelloperanden; 2) Codieren des Zielregisteroperanden, angegeben in Einerkomplementform für gewisse Vektorverschiebungen; oder 3) Nichtcodieren irgendeines Operanden, das Feld ist reserviert und sollte einen bestimmten Wert enthalten, wie etwa 1111b.
P[15] ähnelt W des ersten Präfixes 3501(A) und des zweiten Präfixes 3511(B) und kann als ein Opcode-Erweiterungs-Bit oder Operandengrößenunterstützung dienen.
P[18:16] geben den Index eines Registers in den Opmasken- (Schreibmasken-)Registern (z. B. Schreibmasken/Prädikatregister 3415) an. In einem Beispiel der Erfindung hat der spezifische Wert aaa = 000 ein spezielles Verhalten, das impliziert, dass keine Opmaske für den bestimmten Befehl verwendet wird (dies kann auf eine Vielzahl von Weisen implementiert werden, einschließlich der Verwendung einer Opmaske, die mit allen fest verdrahtet ist, oder Hardware, die Maskierungshardware umgeht). Beim Zusammenführen erlauben Vektormasken, dass ein beliebiger Satz von Elementen in dem Ziel vor Aktualisierungen während der Ausführung einer beliebigen Operation (spezifiziert durch die Basisoperation und die Augmentationsoperation) geschützt wird; in einem anderen Beispiel wird der alte Wert jedes Elements des Ziels bewahrt, wo das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu erlauben beim Nullsetzen Vektormasken einem beliebigen Satz von Elementen im Ziel, während der Ausführung eines beliebigen Befehls (angegeben durch die Basisoperation und die Zusatzoperation) auf Null gesetzt zu werden; in einem Beispiel wird ein Element des Ziels auf 0 gesetzt, wenn das zugehörige Maskenbit einen 0-Wert hat. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der durchzuführenden Operation zu steuern (das heißt die Spanne von Elementen, die modifiziert werden, vom ersten bis zum letzten); allerdings ist es nicht notwendig, dass die Elemente, die modifiziert werden, aufeinander folgen. Daher erlaubt das Schreibmaskenfeld teilweise Vektoroperationen, einschließlich Ladeoperationen, Speicherungen, arithmetisch, logisch usw. Während Beispiele der Erfindung beschrieben werden, in denen der Inhalt des Opmaskenfelds eines aus einer Anzahl von Opmaskenregistern auswählt, das die zu verwendende Opmaske enthält (und daher der Inhalt des Opmaskenfelds indirekt die durchzuführende Maskierung identifiziert), erlauben alternative Beispiele stattdessen oder zusätzlich dem Inhalt des Opmaskenfelds, die durchzuführende Maskierung direkt anzugeben.
P[19] kann mit P[14:11] kombiniert werden, um ein zweites Quellvektorregister in einer nicht-destruktiven Quellsyntax zu codieren, die unter Verwendung von P[19] auf ein oberes 16-Vektorregister zugreifen kann. P[20] codiert mehrere Funktionalitäten, die sich über verschiedene Klassen von Befehlen unterscheiden und die Bedeutung des Vektorlängen-/Rundungssteuerspezifiziererfelds (P[22:21]) beeinflussen können. P[23] gibt Unterstützung für Zusammenführen von Schreibmaskierung (z. B. wenn auf 0 gesetzt) oder Unterstützung für Nullsetzen und Zusammenführen von Schreibmaskierung (z. B. wenn auf 1 gesetzt) an.

Beispielhafte Beispiele für das Codieren von Registern in Befehlen unter Verwendung des dritten Präfixes 3501(C) sind in den folgenden Tabellen ausführlich beschrieben. Tabelle 1: 32-Registerunterstützung im 64-Bit-Modus

	4	3	[2:0]	REG. TYP	ÜBLICHE VERWENDUNGEN
REG	R'	R	ModR/M reg	GPR, Vektor	Ziel oder Quelle
VVVV	V'	vvvv		GPR, Vektor	2. Quelle oder Ziel
RM	X	B	ModR/M R/M	GPR, Vektor	1. Quelle oder Ziel
BASIS	0	B	ModR/M R/M	GPR	Speicheradressierung
INDEX	0	X	SIB.index	GPR	Speicheradressierung
VIDX	V'	X	SIB.index	Vektor	VSIB-Speicheradressierung

Tabelle 2: Codieren von Registerspezifikatoren im 32-Bit-Modus

	[2:0]	REG. TYP	ÜBLICHE VERWENDUNGEN
REG	ModR/M reg	GPR, Vektor	Ziel oder Quelle
VVVV	vvvv	GPR, Vektor	2. Quelle oder Ziel
RM	ModR/M R/M	GPR, Vektor	1. Quelle oder Ziel
BASIS	ModR/M R/M	GPR	Speicheradressierung
INDEX	SIB.index	GPR	Speicheradressierung
VIDX	SIB.index	Vektor	VSIB-Speicheradressierung

Tabelle 3: Opmaskenregisterspezifikatorcodierung

	[2:0]	REG. TYP	ÜBLICHE VERWENDUNGEN
REG	ModR/M Reg	k0-k7	Quelle
VVVV	vvvv	k0-k7	2. Quelle
RM	ModR/M R/M	k0-7	1. Quelle
{k1]	aaa	k0¹-k7	Opmask

Programmcode kann auf die Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen angewendet werden. Im Zusammenhang mit dieser Anmeldung beinhaltet ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie etwa zum Beispiel einen Digitalsignalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer übergeordneten prozeduralen oder objektorientierten Programmiersprache zur Kommunikation mit einem Verarbeitungssystem implementiert sein. Der Programmcode kann auch, wenn gewünscht, in Assembler- oder Maschinensprache umgesetzt sein. Tatsächlich sind die hier beschriebenen Mechanismen in ihrem Umfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Beispiele der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination aus solchen Umsetzungsansätzen umgesetzt sein. Beispiele der Erfindung können als Computerprogramme oder Programmcode umgesetzt sein, die bzw. der auf programmierbaren Systemen, zumindest einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nicht-flüchtiger Speicher und/oder Speicherelemente), zumindest eine Eingabevorrichtung und zumindest eine Ausgabevorrichtung umfassend, ausgeführt werden bzw. wird.
Ein oder mehrere Aspekte von zumindest eines Beispiels können durch repräsentative Befehle, gespeichert auf einem maschinenlesbaren Medium, das unterschiedliche Logik innerhalb des Prozessors repräsentiert, umgesetzt sein, die, wenn von einer Maschine gelesen, die Maschine veranlassen, Logik zu erzeugen, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, auch als „IP-Kerne“ bekannt, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und verschiedenen Kunden oder Fertigungseinrichtungen bereitgestellt werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich fertigen.
Solche maschinenlesbaren Speichermedien können unter anderem umfassen: nicht-flüchtige, greifbare Anordnungen von Artikeln, die durch eine Maschine gefertigt oder gebildet werden, einschließlich Speichermedien, wie etwa Festplatten, jeder andere Typ von Platte, einschließlich Floppy Disks, optische Platten, CD-Nur-Lese-Speicher (CD-ROMs), wiederbeschreibbare Compact Disks (CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen, wie etwa Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAMs), wie etwa dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare, programmierbare Nur-Lese-Speicher (EPROMs), Flash-Speicher, elektrisch löschbare, programmierbare Nur-Lese-Speicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder jeden anderen Typ von zum Speichern von elektronischen Befehlen geeigneten Medien.
Entsprechend umfassen Beispiele der Erfindung auch nicht-flüchtige, greifbare, maschinenlesbare Medien, Befehle enthaltend oder Konzeptionsdaten enthaltend, wie etwa Hardwarebeschreibungssprache (HDL, Hardware Description Language), die Strukturen, Schaltungen, Einrichtungen, Prozessoren und/oder Systemmerkmale, wie hier beschrieben, definieren. Solche Beispiele können auch als Programmprodukte bezeichnet werden.
Emulation (einschließlich Binärübersetzung, Code-Morphing usw.)
In manchen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlsumwandler einen Befehl in einen oder mehrere andere durch den Kern zu verarbeitende Befehle (z. B. unter Verwendung statischer Binärübersetzung, dynamischer Binärübersetzung einschließlich dynamischer Kompilation) übersetzen, morphen, emulieren oder anderweitig umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlsumwandler kann prozessorintern, prozessorextern oder teilweise prozessorintern und teilweise prozessorextern sein.
41 stellt ein Blockdiagramm dar, die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz abgesetzt darstellend, gemäß Beispielen der Erfindung. In dem veranschaulichten Beispiel ist der Befehlsumwandler ein Softwarebefehlsumwandler, obwohl alternativ der Befehlsumwandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert sein kann. 41 zeigt, dass ein Programm in einer höheren Sprache 4102 unter Verwendung eines ersten ISA-Kompilierers 4104 kompiliert werden kann, um einen ersten ISA-Binärcode 4106 zu erzeugen, der nativ durch einen Prozessor mit zumindest einem ersten Befehlssatzkern 4116 ausgeführt werden kann. Der Prozessor mit mindestens einem ersten ISA-Befehlssatzkern 4116 repräsentiert einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel^® -Prozessor mit mindestens einem ersten ISA-Befehlssatzkern durchführen kann, durch kompatibles Ausführen oder anderweitig Verarbeiten (1) eines wesentlichen Teils des Befehlssatzes des ersten ISA-Befehlssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, die darauf abzielen, auf einem Intel-Prozessor mit mindestens einem ersten ISA-Befehlssatzkern ausgeführt zu werden, um im Wesentlichen das gleiche Ergebnis wie ein Prozessor mit zumindest einem ersten ISA-Befehlssatzkern zu erreichen. Der erste ISA-Kompilierer 4104 repräsentiert einen Kompilierer, der betreibbar ist, um ersten ISA-Binärcode 4106 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verknüpfungsverarbeitung auf dem Prozessor mit mindestens einem ersten ISA-Befehlssatzkern 4116 ausgeführt werden kann. Gleichermaßen zeigt 41, dass das Programm in der höheren Sprache 4102 unter Verwendung eines alternativen Befehlssatz-Kompilierers 4108 kompiliert werden kann, um alternativen Befehlssatzbinärcode 4110 zu erzeugen, der nativ durch einen Prozessor ohne einen ersten ISA-Befehlssatzkern 4114 ausgeführt werden kann. Der Befehlsumwandler 4112 wird verwendet, um den ersten ISA-Binärcode 4106 in Code umzuwandeln, der nativ durch den Prozessor ohne einen ersten ISA-Befehlssatzkern 4114 ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht derselbe wie der alternative Befehlssatz-Binärcode 4110, da ein Befehlsumwandler, der dazu in der Lage ist, schwierig herzustellen ist; der umgewandelte Code wird jedoch die allgemeine Operation durchführen und aus Befehlen aus dem alternativen Befehlssatz bestehen. Daher repräsentiert der Befehlsumwandler 4112 Software, Firmware, Hardware oder eine Kombination daraus, die, durch Emulierung, Simulation oder jeden anderen Prozess, einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen ersten ISA-Befehlssatzprozessor oder -kern hat, ermöglicht, den ersten ISA-Binärcode 4106 auszuführen.
Bezugnahmen auf „ein Beispiel“, „ein beispielhaftes Beispiel“ usw. geben an, dass das beschriebene Beispiel ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Charakteristik beinhalten kann, dass aber nicht notwendigerweise jedes Beispiel das spezielle Merkmal, die spezielle Struktur oder die spezielle Charakteristik beinhaltet. Darüber hinaus beziehen sich solche Ausdrücke nicht notwendigerweise auf dasselbe Beispiel. Ferner wird, wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder Charakteristik in Verbindung mit einem Befehl beschrieben wird, davon ausgegangen, dass es innerhalb der Kenntnis eines Fachmanns liegt, ein solches Merkmal, eine solche Struktur oder Charakteristik in Verbindung mit anderen Beispielen in Verbindung zu setzen, unabhängig davon, ob explizit beschrieben oder nicht.
Zudem soll in den verschiedenen oben beschriebenen Beispielen, sofern nicht speziell anders angegeben, disjunktive Sprache, wie etwa der Ausdruck „zumindest eines aus A, B oder C“, so verstanden werden, dass er entweder A, B oder C oder eine beliebige Kombination davon (z. B. A, B und/oder C) bedeutet. Von daher soll disjunktive Sprache weder implizieren noch so verstanden werden, dass ein gegebenes Beispiel erfordert, dass zumindest ein A, zumindest ein B oder zumindest ein C vorhanden sind.
Beispielhafte Beispiele beinhalten unter anderem:

1. Eine Einrichtung, umfassend:
- eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und
- Ausführungsschaltungsanordnung zum Ausführen des decodierten Einzelbefehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
2. Die Einrichtung aus Beispiel 1, wobei die Ausführung des decodierten Befehls Segmentregister nicht modifizieren soll.
3. Die Einrichtung aus einem der Beispiele 1-2, wobei der Opcode F2 0F 01 CA ist.
4. Die Einrichtung aus einem der Beispiele 1-3, wobei die höchste Berechtigungsebene Ring 0 ist.
5. Die Einrichtung aus einem der Beispiele 1-4, wobei zum Ausführen des Decodierbefehls die Ausführungsschaltungsanordnung den Rückkehrkontext aus einem Stapel laden und prüfen soll.
6. Die Einrichtung aus Beispiel 5, wobei die Ausführungsschaltungsanordnung einen Schattenstapel prüfen soll, um die Gültigkeit der Rückkehr zu bestätigen.
7. Die Einrichtung aus Beispiel 5, wobei die Ausführungsschaltungsanordnung den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register erstellen soll.
8. Ein Verfahren, umfassend:
- Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll;
und
- Ausführen des decodierten Befehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
9. Das Verfahren aus Beispiel 8, wobei Ausführen des decodierten Befehls ferner das Nichtmodifizieren von Segmentregistern umfasst.
10. Das Verfahren aus einem der Beispiele 8-9, wobei der Opcode F2 0F 01 CA ist.
11. Das Verfahren aus einem der Beispiele 8-10, wobei die höchste Berechtigungsebene Ring 0 ist.
12. Das Verfahren aus einem der Beispiele 8-11, wobei das Ausführen ferner Laden und Prüfen des Rückkehrkontexts aus einem Stapel umfasst.
13. Das Verfahren aus Beispiel 12, wobei das Ausführen dazu dient, einen Schattenstapel zu prüfen, um die Gültigkeit der Rückkehr zu bestätigen.
14. Das Verfahren aus Beispiel 12, wobei das Ausführen dazu dient, den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register herzustellen.
15. Ein Verfahren, umfassend:
- Übersetzen eines einzelnen Befehls aus einer ersten Befehlssatzarchitektur in einen oder mehrere Befehle einer zweiten Befehlssatzarchitektur, wobei der einzelne Befehl ein Feld für einen Opcode aufweist, wobei der Opcode angibt, dass die Ausführungsschaltung eine Rückkehr von einem Ereignishandler bewirken soll, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext erstellen soll, der vor der Ereignislieferung wirksam war;
Decodieren des einen oder der mehreren Befehle der zweiten Befehlssatzarchitektur und
- Ausführen des einen oder der mehreren decodierten Befehle der zweiten Befehlssatzarchitektur, um eine Rückkehr von einem Ereignishandier zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
16. Das Verfahren aus Beispiel 15, wobei der Opcode F2 0F 01 CA ist.
17. Das Verfahren aus einem der Beispiele 15-16, wobei die höchste Berechtigungsebene Ring 0 ist.
18. Ein System, umfassend:
- einen Prozessorkern, der Folgendes beinhaltet:
  - eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und
  - Ausführungsschaltungsanordnung zum Ausführen des decodierten Einzelbefehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war; und
  - einen Speicher, der mit dem Prozessorkern gekoppelt ist, um den einzelnen Befehl zu speichern.
19. Das System aus Beispiel 18, wobei der Opcode F2 0F 01 CA ist.
20. Das System aus einem der Beispiele 18-19, wobei die Ausführungsschaltungsanordnung den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register erstellen soll.
21. Eine Einrichtung, umfassend:
- eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und
- Ausführungsschaltungsanordnung zum Ausführen des decodierten Befehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er zu einem am wenigsten berechtigten Ring übergeht und der Rückkehrkontext eingerichtet wird, der vor der Ereignislieferung wirksam war.
22. Die Einrichtung aus Beispiel 21, wobei die Ausführung des decodierten Befehls Segmentregister modifizieren soll.
23. Die Einrichtung aus einem der Beispiele 21-22, wobei der Opcode F3 0F 01 CA ist.
24. Die Einrichtung aus einem der Beispiele 21-23, wobei die niedrigste Berechtigungsbene Ring 3 ist.
25. Die Einrichtung aus einem der Beispiele 21-24, wobei zum Ausführen des Decodierbefehls die Ausführungsschaltungsanordnung den Rückkehrkontext aus einem Stapel laden und prüfen soll.
26. Die Einrichtung aus Beispiel 25, wobei die Ausführungsschaltungsanordnung einen Schattenstapel prüfen soll, um die Gültigkeit der Rückkehr zu bestätigen.
27. Die Einrichtung aus Beispiel 25, wobei die Ausführungsschattungsanordnung den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register erstellen soll.
28. Ein Verfahren, umfassend:
- Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll;
und
- Ausführen des decodierten Befehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er zu einem am wenigsten berechtigten Ring übergeht und der Rückkehrkontext eingerichtet wird, der vor der Ereignislieferung wirksam war.
29. Das Verfahren aus Beispiel 28, wobei Ausführen des decodierten Befehls ferner das Modifizieren von Segmentregistern umfasst.
30. Das Verfahren aus einem der Beispiele 28-29, wobei der Opcode F3 0F 01 CA ist.
31. Das Verfahren aus einem der Beispiele 28-30, wobei die niedrigste Berechtigungsbene Ring 3 ist.
32. Das Verfahren aus einem der Beispiele 28-31, wobei das Ausführen ferner Laden und Prüfen des Rückkehrkontexts aus einem Stapel umfasst.
33. Das Verfahren aus Beispiel 32, wobei das Ausführen dazu dient, einen Schattenstapel zu prüfen, um die Gültigkeit der Rückkehr zu bestätigen.
34. Das Verfahren aus Beispiel 32, wobei das Ausführen dazu dient, den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register herzustellen.
35. Ein Verfahren, umfassend:
- Übersetzen eines einzelnen Befehls aus einer ersten Befehlssatzarchitektur in einen oder mehrere Befehle einer zweiten Befehlssatzarchitektur, wobei der einzelne Befehl ein Feld für einen Opcode aufweist, wobei der Opcode angibt, dass die Ausführungsschaltung eine Rückkehr von einem Ereignishandler bewirken soll, während er in einer niedrigsten Berechtigungsbene bleibt, und einen Rückkehrkontext erstellen soll, der vor der Ereignislieferung wirksam war;
Decodieren des einen oder der mehreren Befehle der zweiten Befehlssatzarchitektur und
- Ausführen des einen oder der mehreren decodierten Befehle der zweiten Befehlssatzarchitektur, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer niedrigsten Berechtigungsbene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
36. Das Verfahren aus Beispiel 35, wobei der Opcode F3 0F 01 CA ist.
37. Das Verfahren aus einem der Beispiele 35-36, wobei die höchste Berechtigungsebene Ring 3 ist.
38. Ein System, umfassend:
- einen Prozessorkern, der Folgendes beinhaltet:
  - eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und
  - Ausführungsschaltungsanordnung zum Ausführen des decodierten Befehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er zu einem am wenigsten berechtigten Ring übergeht und der Rückkehrkontext eingerichtet wird, der vor der Ereignislieferung wirksam war; und
  - einen Speicher, der mit dem Prozessorkern gekoppelt ist, um den einzelnen Befehl zu speichern.
39. Das System aus Beispiel 38, wobei der Opcode F3 0F 01 CA ist.
40. Das System aus einem der Beispiele 38-39, wobei die Ausführungsschaltungsanordnung den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register erstellen soll.
41. Eine Einrichtung, umfassend:
- Ereignislieferschaltungsanordnung zum Durchführen einer oder mehrerer Operationen bei einer Ereignislieferung einer Ausnahme oder eines Interrupts an einen Ereignishandler, wobei die eine oder die mehreren Operationen eine Einrichtung eines neuen Kontexts eines Ereignishandlers in einer ersten Berechtigungsebene beinhalten; und
- ein oder mehrere modellspezifische Register (MSRs), die durch die Ereignislieferschaltungsanordnung verwendet werden sollen, um die eine oder die mehreren Operationen durchzuführen, die eines oder mehrere aus Folgendem beinhalten:
  - ein Konfigurations-MSR, wobei eine erste echte Teilmenge von Bits des Konfigurationsregisters eine Stapelebene identifiziert, die für maskierbare Interrupts zu verwenden ist, die geliefert werden, während die aktuelle Berechtigungsebene einen ersten Zustand aufweist, eine zweite echte Teilmenge von Bits des Konfigurationsregisters den aktuellen Berechtigungsebenenzustand angibt, eine dritte echte Teilmenge von Bits des Konfigurationsregisters eine Menge von Cachezeilen identifiziert, um die die Ereignislieferung einen Stapelzeiger dekrementiert, wenn Stapel nicht geändert werden, und eine vierte echte Teilmenge von Bits des Konfigurationsregisters die oberen Bits der linearen Adresse einer Seite in einem Speicher enthält, der Ereignishandler enthält;
  - mehrere reguläre Stapelzeiger-MSRs;
  - ein Stapelebenen- bzw. STKLVLS-MSR; und
  - mehrere Schattenstapelzeiger-MSRs.
42. Die Einrichtung aus Beispiel 41, wobei die Ausführungsschaltungsanordnung eine Ereignislieferung durchführen soll zum:
- Bestimmen eines Zustands des neuen Kontexts;
- Speichern von Informationen über das Ereignis und einen ursprünglichen Kontext; und
- Laden des Zustands des neuen Kontexts;
43. Die Einrichtung aus einem der Beispiele 40-42, wobei das Bestimmen eines Zustands des neuen Kontexts das Bestimmen eines neuen Befehlszeigers, eines neuen Flag-Registerwerts und von Werten für eine Stapelebene, einen Stapelzeiger und einen Schattenstapelzeiger umfasst.
44. Die Einrichtung aus einem der Beispiele 40-43, wobei das Speichern von Informationen über das Ereignis und einen ursprünglichen Kontext Speichern von Informationen über einen regulären Stapel und Speichern von Informationen über einen Schattenstapel umfasst.
45. Die Einrichtung aus einem der Beispiele 40-44, wobei die Ausführungsschaltungsanordnung ferner bestätigen soll, dass die Ereignislieferung durch Durchführen einer Ereignislieferung unterstützt wird, indem bestimmt wird, dass ein Bit in einem Steuerregister gesetzt ist, um Unterstützung für flexible Rückkehr und Ereignislieferung anzugeben.
46. Die Einrichtung aus einem der Beispiele 40-45, die ferner Folgendes umfasst:
- einen Speicher zum Speichern des Ereignishandlers.

Die Beschreibung und die Zeichnungen sind dementsprechend in einem beispielhaften statt in einem einschränkenden Sinn zu sehen. Es versteht sich jedoch, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom breiteren Wesen und Schutzumfang der Offenbarung, wie in den Ansprüchen dargelegt, abzuweichen.

Claims

Einrichtung, umfassend: eine Decodierschaltungsanordnung zum Decodieren eines einzelnen Befehls, wobei der einzelne Befehl ein Feld für einen Opcode beinhalten soll; und Ausführungsschaltungsanordnung zum Ausführen des decodierten Einzelbefehls gemäß dem Opcode, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
Einrichtung nach Anspruch 1, wobei die Ausführung des decodierten Befehls Segmentregister nicht modifizieren soll.
Einrichtung nach einem der Ansprüche 1-2, wobei der Opcode F2 0F 01 CA ist.
Einrichtung nach einem der Ansprüche 1-3, wobei die höchste Berechtigungsebene Ring 0 ist.
Einrichtung nach aus einem der Ansprüche 1-4, wobei zum Ausführen des Decodierbefehls die Ausführungsschaltungsanordnung den Rückkehrkontext aus einem Stapel laden und prüfen soll.
Einrichtung nach Anspruch 5, wobei die Ausführungsschaltungsanordnung einen Schattenstapel prüfen soll, um die Gültigkeit der Rückkehr zu bestätigen.
Einrichtung nach Anspruch 5, wobei die Ausführungsschaltungsanordnung den Rückkehrkontext zumindest teilweise durch Laden eines oder mehrerer Register erstellen soll.
Verfahren, umfassend: Übersetzen eines einzelnen Befehls aus einer ersten Befehlssatzarchitektur in einen oder mehrere Befehle einer zweiten Befehlssatzarchitektur, wobei der einzelne Befehl ein Feld für einen Opcode aufweist, wobei der Opcode angibt, dass die Ausführungsschaltung eine Rückkehr von einem Ereignishandler bewirken soll, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext erstellen soll, der vor der Ereignislieferung wirksam war; Decodieren des einen oder der mehreren übersetzten Befehle der zweiten Befehlssatzarchitektur und Ausführen der decodierten übersetzten Befehle des zweiten Befehlssatzes gemäß dem Opcode des einzelnen Befehls aus der ersten Befehlssatzarchitektur, um eine Rückkehr von einem Ereignishandler zu bewirken, während er in einer höchsten Berechtigungsebene bleibt, und einen Rückkehrkontext einzurichten, der vor der Ereignislieferung wirksam war.
Verfahren nach Anspruch 8, wobei das Ausführen des decodierten Befehls ferner das Nichtmodifizieren von Segmentregistern umfasst.
Verfahren nach einem der Ansprüche 8-9, wobei der Opcode F2 0F 01 CA ist.
Verfahren nach einem der Ansprüche 8-10, wobei die höchste Berechtigungsebene Ring 0 ist.
Verfahren nach einem der Ansprüche 8-11, wobei das Ausführen ferner das Laden und Prüfen des Rückkehrkontexts aus einem Stapel umfasst.
Verfahren nach Anspruch 12, wobei das Ausführen dazu dient, einen Schattenstapel zu prüfen, um die Gültigkeit der Rückkehr zu bestätigen.
Verfahren nach Anspruch 12, wobei das Ausführen ausgelegt ist zum Einrichten des Rückkehrkontexts zumindest teilweise durch Laden eines oder mehrerer Register.
Computerprogramm, das Anweisungen umfasst, die, wenn das Programm durch einen Computer ausgeführt wird, den Computer dazu veranlassen, das Verfahren nach einem der Ansprüche 8-14 auszuführen.