DE102010034555A1 - Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus - Google Patents

Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus Download PDF

Info

Publication number
DE102010034555A1
DE102010034555A1 DE102010034555A DE102010034555A DE102010034555A1 DE 102010034555 A1 DE102010034555 A1 DE 102010034555A1 DE 102010034555 A DE102010034555 A DE 102010034555A DE 102010034555 A DE102010034555 A DE 102010034555A DE 102010034555 A1 DE102010034555 A1 DE 102010034555A1
Authority
DE
Germany
Prior art keywords
smm
processor
state
memory
smi
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102010034555A
Other languages
English (en)
Inventor
Mahesh S. Portland Natu
Baskaran Ganesan
Thanunathan Rangarajan
Mohan J. Aloha Kumar
Gautam B. Doshi
Rajesh S. Hillsboro Parthasarathy
Shammanna M. Hillsboro Datta
Frank Portland Binns
Rajesh Nagaraja Murthy
Robert C. Olympia Swanson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102010034555A1 publication Critical patent/DE102010034555A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24—Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C11/00—Digital stores characterised by the use of particular electric or magnetic storage elements; Storage elements therefor
    • G11C11/21—Digital stores characterised by the use of particular electric or magnetic storage elements; Storage elements therefor using electric elements
    • G11C11/34—Digital stores characterised by the use of particular electric or magnetic storage elements; Storage elements therefor using electric elements using semiconductor devices
    • G11C11/40—Digital stores characterised by the use of particular electric or magnetic storage elements; Storage elements therefor using electric elements using semiconductor devices using transistors
    • G11C11/401—Digital stores characterised by the use of particular electric or magnetic storage elements; Storage elements therefor using electric elements using semiconductor devices using transistors forming cells needing refreshing or charge regeneration, i.e. dynamic cells
    • G11C11/406—Management or control of the refreshing or charge-regeneration cycles
    • G11C11/40615—Internal triggering or timing of refresh, e.g. hidden refresh, self refresh, pseudo-SRAMs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
    • G11C7/10—Input/output [I/O] data interface arrangements, e.g. I/O data control circuits, I/O data buffers
    • G11C7/1072—Input/output [I/O] data interface arrangements, e.g. I/O data control circuits, I/O data buffers for memories with random access ports synchronised on clock signal pulse trains, e.g. synchronous memories, self timed memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Hardware Design (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Multi Processors (AREA)
  • Hardware Redundancy (AREA)
  • Advance Control (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

Bei einer Ausführungsform beinhaltet die vorliegende Erfindung einen Prozessor, der einen On-Die-Speicher aufweist, wie z. B. ein statischer Direktzugriffspeicher, um einen Architektur-Zustand eines oder mehr Threads zu speichern, die bei Eintritt in einen Systemmanagement-Modus (system management mode, SMM) aus dem Architektur-Zustandsspeicher ausgelagert werden. Auf diese Weise kann Kommunikation dieser Zustands-Information an einen Systemmanagement-Speicher vermieden werden, wodurch Latenz verringert wird, die mit Eintritt in SMM verbunden ist. Ausführungsformen können ebenfalls den Prozessor in die Lage versetzen, einen Zustand von ausführenden Agenten zu aktualisieren, die entweder in einem langen Befehlsablauf sind oder in einem Systemmanagement-Unterbrechungs-(system management interrupt, SMI)-Blockiert-Zustand, um eine Anzeige an die Agenten innerhalb des SMM bereitzustellen. Weitere Ausführungsformen sind beschrieben und werden beansprucht.

Description

  • Hintergrund
  • Die meisten Prozessoren eines Computersystems unterstützen einen speziellen Betriebsmodus, genannt Systemmanagement-Modus (system management mode, SMM). SMM stellt eine eigene Betriebsumgebung bereit, die der Betriebssystem-(operating system, OS)-Software gegenüber transparent ist. Dieser Modus wird oft von Originalgeräteherstellern (original equipment manufacturers, OEMs) genutzt, um spezielle Tasks, u. a. Systemmanagement, Geräte-, Energie- und Wärmemanagement durchzuführen. Serverbezogene Zuverlässigkeits-, Verfügbarkeits- und Wartungsfreundlichkeits-(reliability, availability and serviceability, RAS)-Funktionen werden normalerweise mittels SMM implementiert. In SMM wird typischerweise eingetreten, indem an den Prozessor eine Systemmanagement-Unterbrechungs-(system management interrupt, SMI)-Nachricht gesendet wird. Bei Bestätigung der SMI sichert der Prozessor den derzeitigen Prozessorkontext, auch Prozessor-Speicherzustand genannt, in einem Teil des Systemspeichers, der dem SMM spezifisch zugeteilt ist, genannt Systemmanagement-Direktzugriffspeicher (system management random access memory, SMRAM), und führt den SMI-Verarbeitungscode aus, der in SMRAM enthalten ist. Wenn der SMI-Verarbeiter seine Operationen ausgeführt hat, führt er einen speziellen (nur in SMM gültig) Wiederaufnahme-Befehl aus, der den Prozessor veranlasst, den gesicherten Prozessorkontext aus dem SMRAM erneut zu laden und das Ausführen der unterbrochenen Task wieder aufzunehmen.
  • In einem Mehrprozessor-System wird im Allgemeinen eine SMI-Nachricht an alle Prozessoren gesendet. Der SMI-Verarbeiter wählt einen Prozessor, genannt SMM-Monarch, aus, um das Ereignis zu verarbeiten. Dieser Prozessor wartet, bis sich alle anderen Prozessoren innerhalb SMM zusammengefunden haben, bevor er das SMI-Ereignis verarbeitet. Nicht-Monarch-Prozessoren verweilen in SMM, bis der Monarch die Ereignisverarbeitung ausgeführt hat. Wenn das SMM-Ereignis verarbeitet wurde, signalisiert der Monarch den anderen Prozessoren, aus SMM auszutreten. Dieses synchronisierte Eintritts- und Austrittsverhalten wird implementiert, um jegliche Ressourcen-Konflikte zwischen den beiden Parallelumgebungen (OS und SMM) zu vermeiden. Das heißt, wenn einige Prozessoren in der OS-Umgebung aktiv sind und der Rest gleichzeitig in der SMM-Umgebung aktiv ist, ist es möglich, dass sie eine gemeinsam benutzte Ressource modifizieren und dadurch die Operationen des anderen stören, wodurch das System abstürzt. Zusätzlich können bestimmte SMM-Ereignisse nur von einem spezifischen Logik-Prozessor oder einem Satz an Logik-Prozessoren verarbeitet werden. Eine Übertragung stellt sicher, dass diese Bedingung immer erfüllt ist, da alle Logik-Prozessoren in SMI eintreten.
  • Daher ist SMI-Verarbeitung in einem Mehrprozessor-System komplex und kann alle Systemressourcen verbrauchen, wodurch das Verarbeiten anderer nützlicher Arbeiten verhindert wird, da ein Prozessor, solange er in SMM ist, dem Betriebssystem nicht zur Verfügung steht.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm eines Prozessors gemäß einer erfindungsgemäßen Ausführungsform.
  • 2 ist ein Blockdiagramm eines Mehrprozessor-Systems gemäß einer erfindungsgemäßen Ausführungsform.
  • 3 ist ein Ablaufdiagramm eines Verfahrens gemäß einer erfindungsgemäßen Ausführungsform.
  • 4 ist ein Ablaufdiagramm eines Verfahrens gemäß einer erfindungsgemäßen Ausführungsform.
  • Ausführliche Beschreibung
  • Bei verschiedenen Ausführungsformen kann On-Die-Speicher als Alternative zum Gebrauch von externem physikalischem Speicher verwendet werden, um den Speicherzustand von einzelnen Threads bei SMM-Eintritt/Austritt zu speichern. Im Gegensatz dazu hängen derzeitige Systeme von externem physikalischem Speicher ab, um in SMM ein- und auszutreten. Diese SMM-Abhängigkeit von System-RAM führt zu Skalierung, leistungs- und zuverlässigkeitsbezogenen Einschränkungen bei missionskritischen Anwendungen, und kann vermieden werden, indem eine erfindungsgemäße Ausführungsform verwendet wird. Es ist anzumerken, dass der Begriff „Thread”, wie hierin verwendet, ebenfalls auf einen Hardware-Thread verweisen kann, der Speicher in einem Prozessor für den Architektur-Zustand beinhaltet, der mit einem Prozess verbunden ist (z. B. eine Registerdatei und verbundene Konfigurations- und Zustandsregister). Wie hierin verwendet, wird der Begriff „Hardware-Thread” synonym mit dem Begriff „Logik-Prozessor” verwendet. Jeder Prozessorkern kann mehrere Logik-Prozessoren beinhalten, von denen jeder einen zugehörigen Architektur-Zustandsspeicher aufweist, der aber andere Kernressourcen, wie z. B. Front-End-Einheiten, Ausführungseinheiten und so weiter, gemeinsam benutzt.
  • Bei unterschiedlichen Implementierungen kann der On-Die-Speicher, der bereitgestellt ist, um den Speicherzustand von jeglichen aktiven Threads während eines SMM zu speichern, ein On-Die statischer RAM (static RAM, SRAM) oder eine Registerdatei in dem Prozessor selbst sein, um als kleiner zugehöriger Speicher zum Speichern des Speicherzustands zu dienen. Einige Prozessoren können einen On-Die-SRAM für spezifische Tasks wie Power Management beinhalten, z. B. einen OS-verwalteten Energiesparzustand, wie z. B. gemäß einem Advanced Configuration and Power Interface(ACPI)-Zustand (z. B. C6-Zustand oder andere Power Management-Operationen). Bei solchen Prozessoren kann ein Teil dieses SRAM, der auf einer Per-Thread-Basis aufgeteilt ist, für den SRAM-Speicherzustand eines jeden Threads reserviert werden. Als Beispiel kann jeder Logik-Prozessor 1 Kilobyte (KB) von SRAM-Speicher für SMM-Speicherzustand verwenden. Wenn ein gegebener Prozessor diese Menge an SRAM nicht für SMM-Speicherzustand abgeben kann, kann eine Ausführungsform implementiert werden, sodass er SRAM einsetzen kann, der für C6-Abläufe reserviert ist. In diesem Fall können C6/C7-Transaktionen innerhalb SMM in einen niedrigeren Energiesparzustand (z. B. C3) zurückversetzt werden, um eine gegenseitig exklusive Verwendung des gemeinsam benutzten SRAM-Raums für SMM-Speicherzustand sicherzustellen. Einige Prozessoren implementieren keinen zugehörigen SRAM für das Sichern von C6-Zuständen und setzen stattdessen einen Teil eines Last Level Cache (LLC) ein, um Prozessorzustand während einer Sicherung von C6-Zustand zu speichern. Bei diesen Prozessoren kann der SMM-Speicherzustand in dem LLC gespeichert werden.
  • Sobald er gespeichert ist, kann auf diesen internen SMM-Speicherzustand auf verschiedene Art und Weise zugegriffen werden. Beispielsweise kann auf den internen Zustand mittels modellspezifischer Register-(model-specific register, MSR)-Adressierung auf einer Per-Thread-Basis oder eines rückwärtskompatiblen Mechanismus zugegriffen werden. Herkömmlicherweise kann ein Prozessor bei bestimmten Systemspeicheradressen auf einen SMM-Speicherzustand zugreifen. Der rückwärtskompatible Mechanismus beinhaltet Logik in dem Prozessor, die den Zugriff eines Logik-Prozessors auf diese Legacy-Speicheradressen festhält und diese an den entsprechenden SRAM-Ort umleitet. Solch eine Umleitung kann implementiert werden, wenn absolute Rückwärtskompatibilität bei bestehender Basis-Eingabe-/Ausgabe-System-(basic input/output system, BIOS)-Software erforderlich ist. Diese MSRs können nur in SMM-Modus gelesen oder beschrieben werden und folgen Beschränkungen, die mit dem SMM-Speicherzustand verbunden sind. Wenn ein Logik-Prozessor Zugriff auf einen Speicherzustand eines anderen Prozessors benötigt, kann dies über ein Software-Protokoll erreicht werden.
  • Bei einigen Ausführungsformen kann ein zugehöriges Prozessor-Identifikator-Leaf (z. B. ein CPUID-Leaf) oder ein Bereich davon oder ein featureermöglichendes MSR-(modellspezifisches Register)-Bit verwendet werden, um die Verwendung des internen SRAM zu ermöglichen. Es wird Bezug genommen auf 1, die ein Blockdiagramm eines Prozessors gemäß einer erfindungsgemäßen Ausführungsform zeigt. Wie in 1 gezeigt, kann der Prozessor 100 ein mehrstufiger Out-Of-Order-Prozessor mit Pipeline sein. Prozessor 100 ist in relativ vereinfachter Ansicht gezeigt, um verschiedene Merkmale, die in Verbindung mit den hierin beschriebenen SMM-Techniken verwendet werden, zu veranschaulichen. Wie gezeigt, kann Prozessor 100 ein Mehrkern-Prozessor sein, einschließlich einer Vielzahl von Prozessorkernen 105, und der auf einem einzelnen Halbleiter-Die gebildet sein kann. Während dies mit vier solchen Kernen in der Ausführungsform von 1 gezeigt wird, ist der Umfang der vorliegenden Erfindung jedoch in dieser Hinsicht in keiner Weise einschränken. Wie weiter in 1 gezeigt, können in Prozessor 100 zusätzliche Komponenten vorhanden sein. Beispielsweise kann ein integrierter Memory-Controller (integrated memory controller, IMC) 108 vorhanden sein, zusammen mit einem statischen Direktzugriffspeicher (static random access memory, SRAM) 106. Wie vorstehend erörtert, kann dieser Speicher bei einigen Implementierungen verwendet werden, um Kontextzustand gemäß einer erfindungsgemäßen Ausführungsform zu speichern, der anderenfalls in SMRAM gespeichert werden würde. Noch weiter kann Prozessor 100 einen Last Level Cache (LLC) 109 beinhalten, der ein gemeinsam benutzter Cache sein kann, der von allen Prozessorkernen gemeinsam benutzt wird.
  • Wie in 1 gezeigt, umfasst Prozessor 100 Front-End-Einheit 110, die zum Einholen von auszuführenden Makrobefehlen und zu deren Vorbereitung für die spätere Verwendung in dem Kern verwendet werden kann. Front-End-Einheit 110 kann z. B. einen Befehls-Prefetcher, einen Befehls-Decoder und einen Trace-Cache zusammen mit Mikrocode-Speicher und einen Mikro-Befehls-(μOp)-Speicher umfassen. Der Befehls-Prefetcher kann z. B. Makrobefehle aus dem Speicher einholen und diese dem Befehls-Decoder zuführen, um diese in die primitive Form zu entschlüsseln, d. h. μOp für die Ausführung durch den Prozessor. Der Trace-Cache kann entschlüsselte μOp nehmen und in geordneten Programmsequenzen assemblieren. Es ist selbstverständlich, dass auch weitere Komponenten und Merkmale in Front-End-Einheit 110 implementiert werden können.
  • Zwischen der Front-End-Einheit 110 und den Ausführungseinheiten 120 ist eine OOO-(out of Order)-Engine 115 eingekoppelt, die zum Empfangen der Mikrobefehle und deren Vorbereitung für die Ausführung verwendet werden kann. Spezieller kann OOO-Engine 115 verschiedene Puffer für die Rückordnung des Mikrobefehlablaufs und die Zuteilung verschiedener für die Ausführung benötigter Ressourcen umfassen, sowie für die Bereitstellung der Umbenennung von logischen Registern in den Speicherorten innerhalb verschiedener Registerdateien, wie eine Registerdatei 130a. Registerdatei 130 kann separate Registerdateien für Integer- und Floating-Point-Operationen umfassen. Es ist anzumerken, dass mehrere Registerdateien 130a–n vorhanden sein können, jede für einen anderen Logik-Prozessor. Zusätzliche Register, nämlich Zustands- und Konfigurationsregister 135, können ebenfalls vorhanden sein. Wie gezeigt, kann jeder Satz an Registern 135a–n für einen anderen Logik-Prozessor sein. Diese verschiedenen Register können verwendet werden, um einen Kern für unterschiedliche Betriebsmodi zu konfigurieren, und um Zustandsinformation hinsichtlich des Threads und unterschiedlicher ausgeführter Befehle bereitzustellen.
  • Bei dem Beispiel, das in 1 gezeigt ist, können solche Register ein SMM-Speicherzustandsregister 136 beinhalten. Bei verschiedenen Implementierungen kann eine Vielzahl von solchen Registern vorhanden sein, wobei jedes mit einem gegebenen Thread, der auf dem Kern betrieben wird, verbunden ist. Wie vorstehend erörtert, kann solch ein Register einen Indikator, z. B. ein Enable-Bit, speichern, um es dem Zustand des Threads zu ermöglichen, gespeichert zu werden, z. B. innerhalb des Kerns selbst bei Eintritt in SMM. Wenn dieser Indikator nicht freigegeben ist, wird bei Eintritt in SMM der Kontext eines Threads stattdessen in SMRAM gespeichert. Bei einigen Ausführungsformen kann dieses MSR andere Bits beinhalten, die andere Prozessor-Merkmale steuern können. Bei einigen Ausführungsformen kann diese Registerdatei 135, die den Indikator enthält, nur in SMM veränderbar gemacht werden, wodurch verhindert wird, dass sie durch eine Malware-Komponente außerhalb von SMM bösartig verändert wird, was sowohl die Sicherheit als auch die Robustheit des Systems erhöht.
  • Wie weiter gezeigt, kann Registerdatei 135 ebenfalls ein oder mehr SMM-Zustands-Indikatorregister 138 beinhalten. Solche Indikatorregister können in Form einer Bitmap oder eines Bit-Vektors sein, wobei jeder Logik-Prozessor einen Ort aufweist, um anzuzeigen, wenn der Logik-Prozessor davon abgehalten wird, in einen SMM einzutreten, oder ob der Logik-Prozessor sich in einer langen Ablaufausführung befindet. Bei einer Ausführungsform kann ein separates Register für jede solche Anzeige vorhanden sein. Wechselweise kann ein einzelnes Register vorhanden sein und ein logisch kombinierter Indikator kann daher verwendet werden, um die Gegenwart eines dieser Zustände für jeden Logik-Prozessor anzuzeigen. Weitere Details hinsichtlich der Verwendung dieser Register sind nachstehend beschrieben.
  • Unter weiterer Bezugnahme auf 1, können verschiedene Ressourcen in Ausführungseinheiten 120 vorhanden sein, u. a. in verschiedenen Logik-Einheiten für Integer, Floating-Point und Single-Instruction-Multiple-Data (SIMD) sowie in anderer spezialisierter Hardware. Die Ergebnisse können an eine Rückordnungs-Einheit 140 bereitgestellt werden, die betrieben wird, um zu bestimmen, ob ausgeführte Befehle richtig rückgeordnet und die resultierenden Daten in den Architektur-Zustand des Prozessors aufgenommen werden können, oder ob eine oder mehr Ausnahmen eingetreten sind, die eine richtige Rückordnung der Befehle verhindern.
  • Wie in 1 gezeigt, ist Rückordnungs-Einheit 140 mit einem Cache-Speicher 150 gekoppelt, welcher bei einer Ausführungsform ein Low Level Cache sein kann (z. B. ein L1-Cache) sein kann, doch der Umfang der vorliegenden Erfindung ist in dieser Hinsicht nicht eingeschränkt. Auch Ausführungseinheiten 120 können direkt mit dem Cache 150 gekoppelt sein (nicht in 1 gezeigt). Von Cache-Speicher 150 aus kann die Datenkommunikation mit Caches höherer Levels, Systemspeicher usw. erfolgen. Dieser High-Level ist in der Ausführungsform in 1 gezeigt, dies soll jedoch den Umfang der vorliegenden Erfindung in dieser Hinsicht in keiner Weise einschränken. Beispielsweise können andere Ausführungsformen in einem In-Order-Prozessor implementiert werden.
  • Durch Speichern des SMM-Speicherzustands intern in dem Prozessor, kann die Zuverlässigkeit und Robustheit des Systems verbessert werden. Das heißt, der physikalische Speicher, der typischerweise ein Satz an externen dynamische Direktzugriffspeicher-(dynamic random access memory, DRAM)-Geräten ist, auf denen der SMRAM verbleibt, ist anfällig für Speicherfehler. Ohne eine erfindungsgemäße Ausführungsform laufen SMM-Operationen aus diesem externen Speicher und sind deshalb unter Fehlerbedingungen nicht zuverlässig. Wenn stattdessen eine erfindungsgemäße Ausführungsform verwendet wird, kann die Zuverlässigkeit von SMRAM-Speicher verbessert werden, indem ein SMI-Verarbeiter von nicht-flüchtigem Raum ausgeführt wird, wenn Fehler verarbeitet werden. Beispielsweise kann der SMM-Verarbeiter von einem robusteren Speicher, wie BIOS-Flash oder externem SRAM laufen, während er Speicherfehler verarbeitet. Ebenfalls, wenn SMM-Speicherzustand sich intern zu dem Prozessor befindet, kann der Architektur-Zustand dieses Speichers nur durch MSRs der äußeren Software offengelegt werden. Der mikroarchitektonische Zustand des Prozessors, der benötigt wird, um Maschinenausführungszustand wiederherzustellen, nachdem SMM-Code einen „Wiederaufnahme-(Resume, RSM)”-Befehl ausgeführt hat, muss nicht der äußeren Software offengelegt werden, da diese keine legitime Verwendung für diesen internen Maschinenzustand hat. Dies bedeutet ebenfalls, dass bösartiger Software-Code keinen Zugriff auf den empfindlichen mikroarchitektonischen Zustand hat (wie es sonst der Fall wäre, wenn der Speicher der gesicherten Daten in SMRAM ist), wodurch die Maschine sicherer und robuster gemacht wird.
  • Ausführungsformen können ebenfalls Leistung und Latenz verbessern. Viele Serveranwendungen/Betriebssysteme sind NUMA-(nichteinheitliche Speicherarchitektur)-optimiert, und BIOS konfiguriert Speicher typischerweise so, dass der gesamte SMRAM, der ein durchgängiger Speicherbereich ist, einem einzelnen Sockel zugeordnet wird. Daher erscheinen alle SMM-Speicherzustands-/Zustands-Wiederherstellungs-Operationen als entfernte Schreibzugriffe/entfernte Lesezugriffe für alle Logik-CPUs, mit Ausnahme derjenigen, die in einem Sockel enthalten sind, bei denen der SMRAM lokal befindlich ist. Leistungsanalyse für eine Serverkonfiguration mit vier Sockeln, von denen jeder 12 Kerne umfasst, zeigt an, dass SMM-Speicherzustands-Schreiboperationen durch die Kopplungsstruktur und Speicherbandbreite beschränkt sein und bis zu 5 Mikrosekunden dauern können. Da Anwendungen immer stärker NUMA-optimiert werden, können Prozessoren weniger Puffer für entfernten Datenverkehr zuordnen. Wenn dies geschieht, benötigen SMRAM-Speicherzustands-Schreib- und -Leseoperationen sogar noch mehr Zeit. Betriebssysteme haben typischerweise einen Grenzwert, wie lange eine CPU in SMM verweilen kann, um eine akzeptable Echtzeit-Leistung aufrechtzuerhalten und um Zeitüberschreitungen bei Hochgeschwindigkeits-Netzwerkverbindungen zu vermeiden.
  • Überschreiten dieses Grenzwerts beeinträchtigt die Reaktionsfähigkeit des OS, Anwendungslatenzen, und kann ebenfalls zu Fehlfunktionen des Betriebssystems führen. Dementsprechend verringert das Verwenden eines On-Die-SMM-Speicherzustands gemäß einer erfindungsgemäßen Ausführungsform die Latenz und ermöglicht daher weitere Zeit, die einem SMM-Verarbeiter zugeteilt wird, um das SMM-Ereignis (die nützliche Arbeit des SMM) zu bedienen.
  • Zusätzlich können Ausführungsformen Skalierbarkeit verbessern. In einem Mehrprozessor-System, wenn eine SMI auftritt, muss jeder Thread in dem System seinen Speicherzustand in seinem eigenen zugehörigen Speicherzustandsbereich in externem Systemspeicher speichern, wie während des Systemstarts durch das System-BIOS definiert und reserviert. Die Gesamtmenge an physikalischem Speicher, der als der SMRAM-Raum reserviert werden soll, der erforderlich ist, um alle Speicherzustände aller Threads in dem System zu erfassen, steigt linear mit der Anzahl an Threads in dem System. Bei einem Mehrkern-, Mehrsockel-System mit symmetrischer Multi-Threading-Unterstützung kann die Menge an Raum ziemlich groß sein (und kann sich bei einer Ausführungsform in der Größenordnung von circa 256 KB befinden). Durch Bereitstellen von On-Die-Speicher für SMM-Speicherzustand kann der Bedarf an einem ständig wachsenden SMRAM-Bereich, um alle Kerne und zugehörigen Threads davon unterzubringen, vermieden werden, wodurch das Skalieren vereinfacht wird. Er beseitigt ebenfalls die Notwendigkeit, dass BIOS einen einzigartigen, nicht-überlappenden Bereich in SMRAM für jeden Thread findet und zuordnet. Noch weiter erspart dies ebenfalls den Speicherschutzbereichen in Silizium implementiert zu werden. Bei Hot-Plug-Szenarien liegt der architektonisch definierte SMM-Speicherzustandsbereich in SMRAM unter 1 MB. Ohne eine erfindungsgemäße Ausführungsform legt BIOS einen Speicherschutzbereich fest und lagert Daten aus, um OS-Angriffe und/oder -Störung zu vermeiden, wenn neue Prozessoren hinzugefügt werden. Ausführungsformen beseitigen den Bedarf dies zu tun, da der Speicherzustand nicht länger in dem sichtbaren OS-Speicher gespeichert ist.
  • Es wird Bezug genommen auf 2, die ein Blockdiagramm eines Mehrprozessor-Systems gemäß einer erfindungsgemäßen Ausführungsform zeigt. Wie in 2 gezeigt, beinhaltet Mehrprozessor-System 200 eine Vielzahl von Prozessoren 2101–210n (allgemein Prozessor 210). Während dies mit vier solchen Prozessoren in der Ausführungsform von 2 gezeigt wird, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt. Wie bei der Implementierung in 2 gezeigt, ist ein NUMA-(nichteinheitliches Speicherarchitektur)-System vorhanden, sodass Systemspeicher 2201 und 2203 den Prozessoren 2101 und 2103 über die Kopplungsstruktur 2171 und 2173 lokal zugeordnet ist. Daher erfordert Zugriff auf Speicher durch Prozessoren 2102 und 210n eine Kommunikation über eine einer Vielzahl von Point-to-Point-(PTP)-Kopplungsstrukturen 215 mit einem von Prozessoren 2101 und 2103. Wie bei der Implementierung in 2 gezeigt, beinhaltet Speicher 2201, der ein DRAM sein kann, einen SMRAM 225. In dieser NUMA-Architektur ist SMRAM 225 der Systemmanagement-Speicher für das gesamte System. Dementsprechend muss ohne eine erfindungsgemäße Ausführungsform jeder Prozessor bei einem SMM-Eintritt oder -Austritt Kontext in seinem SMRAM 225 sichern/erneut speichern. Dies wiederum verursacht einen hohen Verbrauch an Bandbreite auf PTP-Kopplungsstruktur 215 und Kopplungsstruktur 2171 sowie eine steigende Latenz bei Eintritt in und Austritt aus dem SMM.
  • Dementsprechend kann bei verschiedenen Ausführungsformen jeder Prozessor 210 SRAM 216 zusätzlich zu einem oder mehr Kernen 212 und einem integrierten Memory-Controller 214 beinhalten. Bei verschiedenen Ausführungsformen kann SRAM 216 für das Speichern von SMM-Speicherzuständen bestimmt sein. Das heißt, wenn eine Systemmanagement-Unterbrechung erfolgt, kann der Kontextzustand für die verschiedenen Logik-Prozessoren eines jeden Prozessors 210 lokal in seinem SRAM 216 gespeichert werden, wodurch der Bedarf an Kommunikation von Zustandsinformation mit SMRAM 225 vermieden wird. Bei anderen Ausführungsformen kann dieser Kontextzustand anstatt in einem zugehörigen On-Die-Speicher in auf dem Chip integrierten Registern gespeichert werden, z. B. einer Registerdatei oder anderem Ort, wie einem Cache-Speicher. Während diese bestimmte Implementierung in der Ausführungsform von 2 gezeigt wird, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt. Beispielsweise können Ausführungsformen weiter mit einem einheitlichen Speicherarchitektursystem verwendet werden.
  • Es wird Bezug genommen auf 3, die ein Ablaufdiagramm eines Verfahrens gemäß einer erfindungsgemäßen Ausführungsform zeigt. Wie in 3 gezeigt, kann Verfahren 300 ausgeführt werden, um Eintritt in SMM zu verarbeiten, ohne Zugriffsbedarf auf SMRAM zum Sichern der Zustandsinformation. Es ist anzumerken, dass, aufgrund der Vereinfachung der Erörterung, angenommen wird, dass nur ein einzelner Hardware-Thread vorhanden ist, obwohl bei vielen Implementierungen mehrere Threads zusammen in SMM eintreten können. Wie in 3 gezeigt, kann Verfahren 300 durch den Erhalt einer Systemmanagement-Unterbrechung (Block 310) beginnen. Nach Erhalt dieser Unterbrechung kann ein derzeitiger aktiver Zustand (z. B. eines gegebenen Hardware-Threads) in einem On-Die-Speicher gesichert werden (Block 320). Wie vorstehend erörtert, kann dieser On-Die-Speicher ein zugehöriger SRAM, SRAM, der für einen anderen Zweck verwendet wird (z. B. Power Management-Zustände), Registerspeicher, ein On-Die-Cache-Speicher und so weiter sein.
  • Unter der weiteren Bezugnahme auf 3, ist ein Prozessorzustand modifiziert, um mit einem SMM-Eintrittszustand übereinzustimmen, z. B. wie definiert durch Prozessorspezifikation (Block 330). Dieser Zustand beinhaltet Werte für verschiedene Steuer- und Konfigurationsregister sowie Ausgangswerte für eine Registerdatei. Diese Festlegung bereitet daher eine SMM-Ausführungsumgebung vor, die für einen SMM-Verarbeiter geeignet ist, indem vorbestimmte Werte, die mit dem SMM-Eintrittszustand verbunden sind, in den Zustandsspeicher geladen werden. Wenn der SMM-Zustand festgelegt wurde, geht die Steuerung weiter zu Block 340, wo SMM mittels Code und Daten von SMRAM ausgeführt wird (Block 340). Dementsprechend kann eine gewünschte SMM-Operation ausgeführt werden. Während der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist, umfassen Beispiele von SMM-Operationen Power Management-Operationen, Fehlerverarbeitungs-Operationen und so weiter.
  • Es kann sodann bestimmt werden, ob SMM-Operationen ausgeführt worden sind (Raute 350). Wenn nicht, kann die Ausführung in SMM fortgesetzt werden. Wenn ausgeführt, führt der Prozessor einen Wiederaufnahme-Befehl aus (Block 360). Als Ergebnis dieses Befehls kann der vorherige Zustand aus dem On-Die-Speicher zurück in die Register des Prozessors geladen werden (Block 370). Der Prozessor kann sodann die Ausführung des Threads wieder aufnehmen, der diesem vorherigen Zustand entspricht, der zurück in den aktiven Zustand versetzt wurde (Block 380). Während diese bestimmte Implementierung in der Ausführungsform von 3 gezeigt wird, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist. Beispielsweise können bei einigen Ausführungsformen anstelle eines Ausführens von SMM-Operationen von SMRAM, insbesondere wenn der SMM einen Fehler verarbeiten soll, wie z. B. einen DRAM-Fehler, Ausführungsformen stattdessen SMM-Zustandsinformation, SMM-Code und Daten von einem Permanentspeicher, wie z. B. ein Flash-Memory, erhalten.
  • Wie vorstehend beschrieben, kann Siliziumspeicherung eines aktiven Zustands SMM-Latenz verringern. Ausführungsformen können weiter Latenz verringern, indem ein schnellerer Eintritt in SMM in bestimmten Situationen ermöglicht wird, wie nun erörtert wird.
  • SMM-Latenz wird definiert als die Dauer, für die ein Prozessor per einzelner SMI in der SMM-Umgebung ist. Es gibt zwei hauptsächliche Kontributoren für vollständige SMM-Latenz, Prozessor-Overhead und OEM-BIOS-Code. Diese Latenz muss unter Kontrolle gehalten werden, um Nebeneffekte auf die OS-Umgebung, wie z. B. Zeitüberschreitungen und Taktverschiebungen, zu vermeiden. Weitere Anforderungen erfordern, dass diese Latenz verringert wird, was schwierig umzusetzen sein wird. Derzeit ist vorgeschrieben, dass die SMI-Latenz unter circa 190 Mikrosekunden sein soll. Neue Gebrauchsmodelle, wie Internet-Portal-Daten-Center und Utility Computing, erwarten vorhersehbarere Latenzen von Anwendungen. Folglich drängen OS-Anbieter auf weitere Verringerungen der SMM-Latenz. Auf der anderen Seite haben andere Technologien das Potenzial, SMI-Latenz über die Zeit zu erhöhen. Beispielsweise bedeutet das Drängen der Industrie auf Mehrkern-Prozessoren, dass ein SMI-Verarbeiter eine stetig wachsende Anzahl an Prozessorkernen zusammenfinden muss. Neue SMM-basierte Fähigkeiten üben ebenfalls weiteren Druck auf SMM-Latenz aus. Beispielsweise sind Hochleistungs-RAS-Fähigkeiten von SMM abhängig. Zusätzlich setzen einige OEMs SMM ein, um einzigartige Power Management-Fähigkeiten zu liefern, um ihre Produkte abzugrenzen. Viele OEMs sind bekannt dafür, SMIs zu erzeugen, die bis zu 8-mal pro Sekunde hoch sind.
  • Bestimmte Befehlssatz-Architekturen (instruction set architectures, ISAs) beinhalten Befehle, wie z. B. ein Zurückschreib- und Invalidierungsbefehl (z. B. wbinvd), der alle Cache-Leitungen invalidiert und diese zurück in den Speicher schreibt. Diese Operationen können eine sehr lange Zeit für die Ausführung benötigen, z. B. im Größenbereich von 103 bis 107 Prozessor-Zyklen, insbesondere bei Prozessoren, die große Cache-Größen unterstützen. Zusätzlich gibt es bestimmte Prozessorzustände, wo eine SMI-Antwort verzögert sein kann (z. B. C3 und C6 niedrige Prozessorzustände). Insgesamt können diese Befehls- und Prozessorzustände als „lange Ablauf”-Zustände bezeichnet werden, was in der Definition einen Befehl oder Prozess bedeutet, der eine ungewöhnlich lange Anzahl an Zyklen für die Ausführung benötigen kann (z. B. in der Größenordnung von 103 Takte), und der einen Eintritt in SMM verzögern kann. Bei einer Ausführungsform kann jeder Ablauf, der SMM-Eintritt um mehr als 5 Mikrosekunden verzögert, als langer Ablauf bezeichnet werden. Hinsichtlich SMM, wenn einer oder mehr Logik-Prozessoren sich in einem langen Ablauf befindet, verzögert er SMM-Eintritt.
  • Wie vorstehend erklärt, wartet der SMM-Monarch, bis alle erwarteten Logik-Prozessoren in SMM eingetreten sind. Bei Eintritt in SMM setzt jeder Prozessor sein eigenes Bit in SMRAM, wodurch angezeigt wird, dass er in SMM eingetreten ist. Der Monarch wartet, bis alle erwarteten Prozessoren ihre Bits gesetzt haben. Wenn einer oder mehr Logik-Prozessoren sich in einem langen Ablauf befindet und spät in SMM eintritt, hält er den SMM-Monarch auf, wodurch die SMM-Latenz erhöht wird. Zusätzlich gibt es bestimmte Architektur-Zustände, wie z. B. Wait For Startup Interprocessor Interrupt (WFS)- und TXT-Sleep-Zustand, wo ein SMI-Ereignis inhibiert wird. Wenn das OS/BIOS einen oder mehr Logik-Prozessoren in einen SMI-inhibierten Zustand versetzt, tritt er nicht in SMM ein, bis das OS/BIOS ihn ausdrücklich aus diesem Zustand herausbringt. Da ein SMI-Ereignis alle anderen Prozessoren in SMM versetzt, ist das OS nicht in der Lage, die SMI zu demaskieren. In diesem Szenario muss der SMM-Monarch sich auf eine lange Zeitüberschreitung verlassen, um die Gegenwart eines SMI-inhibierten Prozessors zu bestimmen. Diese Zeitüberschreitungen verzögern SMM-Rendezvous und entweder erhöhen sie die Gesamt-SMM-Latenz oder verringern die Menge an Zeit, die für die Verarbeitung von SMM-Ereignis zur Verfügung steht.
  • Bei verschiedenen Ausführungsformen kann der Bedarf an Zeitüberschreitungen innerhalb SMM vermieden werden, sogar dort, wo einige Logik-Prozessoren sich in einem langen Ablauf befinden. Das Beseitigen solcher Zeitüberschreitungen kann die durchschnittliche SMM-Latenz um 10–20% verbessern und ungünstigste SMM-Latenz um zumindest ein paar Millisekunden.
  • Ausführungsformen verlassen sich auf die Tatsache, dass ein Prozessor, der sich in einem langen Ablauf oder in einem SMI-inhibierten Zustand befindet, wahrscheinlich nicht auf eine gemeinsam benutzte Ressource zugreift. Außerdem hat solch ein Prozessor wahrscheinlich die SMI nicht verursacht, und daher ist seine Teilnahme für SMI-Verarbeitung nicht notwendig. Daher kann der SMM-Monarch mit SMM-Verarbeitung fortfahren, bevor solch ein Prozessor in einen SMM eingetreten ist.
  • Vor dem Fortfahren muss der SMM-Monarch jedoch in der Lage sein, zuverlässig zu ermitteln, welche Prozessoren sich in einem langen Ablauf und/oder SMI-inhibierten Zustand befinden. Um Prozessoren zu ermitteln, die sich geschäftig in einem langen Ablauf oder in einem SMI-inhibierten Zustand befinden, können Ausführungsformen Indikatoren für diese Zustände bereitstellen, wie z. B. mittels Bitmaps. Bei einer Ausführungsform können solche Indikatoren über global sichtbare Konfigurations-Register bereitgestellt werden, genannt LONG_FLOW_INDICATION und SMI_INHIBITED_INDICATION. Bei dieser Ausführungsform kann ein Bit zu jedem Logik-Prozessor in einem Sockel zugeteilt werden. Als ein Beispiel können die Register von Register 138 von 1 dargestellt werden. Bei Implementierungen, bei denen Prozessor-Mikrocode beim Eintritt in und Austritt aus langen Abläufen und SMI-inhibierten Zuständen beteiligt ist, kann der Mikrocode/die Hardware diese Register-Bits besiedeln. Einige der langen Abläufe können länger als 5 Mikrosekunden anhalten und deshalb kann die Fähigkeit, auf diese Prozessoren in diesen Zuständen nicht zu warten, wesentliche Einsparnisse bei der SMM-Latenz bereitstellen. Zukünftige Prozessoren können mehr als 5 Mikrosekunden für SMM-Mikrocode-Eintrittsablauf benötigen und können selbst als ein langer Ablauf betrachtet werden. Der SMM-Monarch kann warten, bis alle Prozessoren ausgewiesen sind, d. h. sie schließen sich entweder dem SMM an oder es wird berichtet, dass sie sich in einem langen Ablauf oder in SMI-inhibiertem Zustand befinden. Um bei solch einer Bestimmung behilflich zu sein, können eine oder mehr Tabellen, wie z. B. Bitmaps, die in SMRAM gespeichert sind, verwendet werden, wie nachstehend beschrieben.
  • Bei einer Implementierung sichert der Monarch-Prozessor seinen Zustand und lässt den SMM-Vorspann-Code laufen, bevor er eine Überprüfung der Indikator-Register ausführt. Diese Schritte können leicht mehr als 0,5 Mikrosekunden beanspruchen. Diese Dauer ist viel höher als die Laufzeit für jegliche In-Flight-Unterbrechung, wodurch sichergestellt wird, dass es keine Wettlaufsituation zwischen SMI-Lieferung an einen Kern und ein Lesen seiner Indikator-Register gibt. Wenn die Verzögerung bei bestimmten Konfigurationen geringer ist, kann der Monarch-Prozessor eine kleine Verzögerungsschleife einsetzen, um dies zu kompensieren.
  • Es wird Bezug genommen auf 4, die ein Ablaufdiagramm eines Verfahrens gemäß einer weiteren erfindungsgemäßen Ausführungsform zeigt. Insbesondere zeigt 4 ein Ablaufdiagramm zur Verarbeitung eines Eintritts in und Austritts aus SMM, wenn alle Logik-Prozessoren sich nicht in dem SMM-Zustand zusammenfinden müssen. Auf diese Weise kann die Latenz, die mit dem Warten auf alle Logik-Prozessoren vor der Ausführung von SMM-Operationen verbunden ist, vermieden werden. Wie in 4 gezeigt, kann Verfahren 400 durch Erzeugen eines SMI-Ereignisses beginnen (Block 410). Dieses SMI-Ereignis kann an alle Threads weitergegeben werden. Es ist anzumerken, dass für die Erleichterung der Erörterung angenommen wird, dass die Threads von 4 mit einem einzelnen Prozessor-Sockel beschrieben sind, obwohl Implementierungen verwendet werden können, um SMM über mehrere Sockel zusammenzufinden.
  • Als Nächstes kann ein Indikator in einer SMM-Indikator-Speicherabbildung für jeden Thread eingestellt werden, der in einen SMM-Rendezvous-Zustand eintritt (Block 420). Es ist selbstverständlich, dass zuerst verschiedene Vorbereitungsmaßnahmen für den Eintritt in SMM von den Threads ausgeführt werden, z. B. ein Sichern des Zustands, wie vorstehend mit Bezug auf 3 beschrieben. Jeder Thread, der in SMM-Rendezvous-Zustand eintritt, kann einen Indikator in einer SMM-Indikator-Speicherabbildung einstellen, die in SMRAM gespeichert werden kann. Bei einer Ausführungsform kann diese Speicherabbildung eine Bitmap sein, bei der jeder Logik-Prozessor mit einem Bit der Speicherabbildung verbunden ist, und wo Logik-Prozessoren eines jeden Sockels in unterschiedliche Segmente der Speicherabbildung aufgeteilt werden können. Wenn daher ein gegebener Thread in den SMM eintritt, kann sein entsprechendes Bit in der Bitmap eingestellt werden. Einer der Threads innerhalb des SMM kann anschließend als ein Monarch oder ausführender Thread ausgewählt werden (Block 430). Bei verschiedenen Ausführungsformen kann die Bestimmung, welcher Thread der ausführende Thread ist, variieren. Beispielsweise kann der Monarch vorher festgelegt werden (z. B. Logik-Prozessor 0 auf Sockel 0) oder dynamisch über einen Wählmechanismus ausgewählt werden.
  • Unter weiterer Bezugnahme auf 4, kann jeder Thread sodann bestimmen, ob er als Monarch ausgewählt worden ist (Raute 435). Wenn nicht, kann der Thread in einen Schlafzustand eintreten, wo er darauf wartet, dass der Monarch-Thread die Ausführung signalisiert (Block 470).
  • Dementsprechend geht die Steuerung für den Monarch-Thread weiter zu Block 440. Dort kann sie einen ACCOUNTED-Zustand für alle Threads bestimmen. Bei einer Ausführungsform kann dieser Status auf verschiedenen Konfigurations-Registern, der SMM-Indikator-Speicherabbildung, zusätzlich zu einer Thread-Gegenwarts-Speicherabbildung, die ebenfalls in SMRAM vorhanden sein kann, basieren. Diese Gegenwarts-Speicherabbildung kann eine Bitmap sein, ähnlich derer der SMM-Indikator-Speicherabbildung, und die während SMM-Initialisierung eingestellt werden kann, um die Threads, die in dem System vorhanden sind, anzuzeigen. Bei einer Ausführungsform kann die Bestimmung bei Block 440 eine bitweise OR-Operation wie folgt sein: OR (LONG_FLOW_INDICATION, SMI_INHIBITED_INDICATION, IN_SMM_INDICATION) wo LONG_FLOW_INDICATION von einem Status-Register erhalten wird, das einen Bit-Vektor speichert, wobei jedes Bit davon anzeigt, ob ein entsprechender Thread sich in langer Ablauf-Operation befindet, SMI_INHIBITED_INDICATION von einem Status-Register erhalten wird, das einen Bit-Vektor speichert, wobei jedes Bit davon anzeigt, ob ein entsprechender Thread sich in einem SMI-inhibierten Zustand befindet, und IN_SMM_INDICATION ist die SMM-Indikator-Speicherabbildung. Das Ergebnis der bitweisen OR, ACCOUNTED, kann in einer Bitmap, z. B. in SMRAM, gespeichert werden. Nach dieser Analyse geht die Steuerung weiter zu Raute 450, wo bestimmt werden kann, ob der ACCOUNTED-Zustand für alle vorhandenen Threads aktiv ist (Raute 450). Dies kann bestimmt werden, basierend auf einem Vergleich zwischen dem Ergebnis der ACCOUNTED-Operation und der vorhandenen Speicherabbildung. Wenn nicht, geht die Steuerung weiter zu Block 440. Andernfalls geht die Steuerung weiter zu Block 455, wo das SMI-Ereignis verarbeitet werden kann. Der Monarch-Thread kann somit den gewünschten SMM-Code ausführen. Bei Abschluss des SMM, der durch den Monarch-Thread ausgeführt wird, geht die Steuerung weiter zu Block 460. Bei Block 460 können der ACCOUNTED-Zustand und die SMM-Indikator-Speicherabbildung zurückgesetzt werden (Block 460). Das heißt, der Monarch-Thread kann die Werte in beiden dieser Bitmaps zurücksetzen. Anschließend kann der Monarch-Thread anderen Logik-Prozessoren signalisieren, dass sie aus SMI zurückkehren können (Block 465). Auf diese Weise werden die anderen Threads aus ihrer Warteschleife befreit. Dementsprechend können alle Threads bei Block 475 aus SMM zurückkehren. Während diese bestimmte Implementierung in der Ausführungsform von 4 gezeigt wird, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt.
  • Ausführungsformen ermöglichen somit eine Ausführung von SMM-Verarbeiter ohne Speicherabhängigkeit, wodurch die Zuverlässigkeit verbessert wird. Dieser Mechanismus adressiert ebenfalls Leistungs- und Skalierbarkeits-Themen, die mit SMM verbunden sind, sodass SMI-Verarbeitung vermeiden kann, ein Engpass in Mehrkern-/Mehrsockel-Systemen zu werden. Ausführungsformen vermeiden daher die Ausführung von SMM-Code mit DRAM-Abhängigkeit, wodurch Gebrauchsmodelle mit hoher Verfügbarkeit ermöglicht werden, bei denen SMM-Code Speicherfehler diagnostiziert und korrigiert.
  • Ausführungsformen ermöglichen weiter Eintritt in SMM mit verringerter Latenz in der Gegenwart eines Logik-Prozessors, der sich in einem langen Ablauf- oder SMI-inhibierten Zustand befindet. Im Gegensatz dazu gibt es derzeit keinen zuverlässigen Mechanismus, durch den SMM-Code bestimmen kann, ob einer oder mehr Prozessoren spät in SMM eintreten oder sich in einem SMM-inhibierten Zustand befinden, und daher wird eine Zeitüberschreitung festgesetzt, die höher ist, als der längste Ablauf-Zustand. Diese Lösung erhöht SMM-Latenz und verringert OS-Antwort in Echtzeit, zusätzlich zu der Tatsache, dass sie unzuverlässig und schwer implementierbar ist, und kann unter Verwendung einer erfindungsgemäßen Ausführungsform bewältigt werden.
  • Ausführungsformen können als Code implementiert und auf einem Speichermedium gespeichert werden, das Anweisungen enthält, die zum Programmieren eines Systems für die Ausführung der Anweisungen verwendet werden können. Das Speichermedium kann beinhalten, ist aber nicht beschränkt auf, jede Art Disks, u. a. Floppy Disks, Optische Disks, Solid State-Laufwerke (SSDs), Compact Disk Read-Only Memories (CD-ROMS), Compact Disk Rewritables (CD-RWs) und magnetooptische Disks (MO), Halbleiter-Geräte, wie Read-Only Memories (ROMS), Random Access Memories (RAMs), wie dynamische Random Access Memories (DRAMs), statische Random Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flash Memories, Electrically Erasable Programmable Read-Only Memories (EEPROMs), magnetische oder optische Karten oder jede andere Art Speichermedium, die sich für das Speichern von elektronischen Befehlen eignet.
  • Obwohl die vorliegende Erfindung im Hinblick auf eine begrenzte Anzahl von Ausführungsformen beschrieben wurde, sind sich Fachleute bewusst, dass viele weitere Modifikationen und Varianten davon möglich sind. Die beigefügten Ansprüche sollen alle solchen Modifikationen und Varianten abdecken, die dem Sinn und Schutzbereich der vorliegenden Erfindung entsprechen.

Claims (24)

  1. Vorrichtung, umfassend: einen Prozessorkern, um Befehle auszuführen und um in einen Systemmanagement-Modus (system management mode, SMM) einzutreten, wobei bei Eintritt in den SMM der Prozessorkern einen aktiven Zustand, der in einem Zustandsspeicher des Prozessorkerns vorhanden ist, in eine Speichereinheit des Prozessorkerns speichern soll, und eine SMM-Ausführungs-Umgebung festlegen soll, indem Werte, die mit dem SMM verbunden sind, in den Zustandsspeicher eingegeben werden.
  2. Die Vorrichtung nach Anspruch 1, wobei der Prozessorkern Information offenlegen soll, die in der Speichereinheit als maschinenspezifische Register (machine specific registers, MSRs) gespeichert ist, auf die nur von SMM-Code zugegriffen werden kann.
  3. Die Vorrichtung nach Anspruch 1, weiter umfassend ein erstes Zustandsregister, um einen Indikator zu speichern, um anzuzeigen, dass der Prozessorkern in der Lage ist, den aktiven Zustand in der Speichereinheit zu speichern und nicht in einem Systemmanagement-Direktzugriffspeicher (system management random access memory, SMRAM).
  4. Die Vorrichtung nach Anspruch 3, wobei das erste Zustandsregister nur durch einen Agenten aktualisiert werden kann, der in dem SMM ausgeführt wird.
  5. Die Vorrichtung nach Anspruch 3, wobei der Prozessorkern SMM-Code ausführen soll, der in dem SMRAM gespeichert ist.
  6. Die Vorrichtung nach Anspruch 5, wobei, wenn der SMM einen Speicherfehler beseitigen soll, der Prozessorkern einen Wiederherstellungs-SMM-Code von einem Permanentspeicher erhalten soll und den SMM-Code nicht von dem SMRAM erhalten soll.
  7. Die Vorrichtung nach Anspruch 3, weiter umfassend ein zweites Zustandsregister, um einen Indikator zu speichern, um anzuzeigen, dass ein Logik-Prozessor des Prozessorkerns sich in einer langen Ablauf-Operation befindet.
  8. Die Vorrichtung nach Anspruch 7, weiter umfassend ein drittes Zustandsregister, um einen Indikator zu speichern, um anzuzeigen, dass ein Logik-Prozessor des Prozessorkerns sich in einem Systemmanagement-Unterbrechungs-(system management interrupt, SMI)-inhibierten Zustand befindet.
  9. Die Vorrichtung nach Anspruch 8, weiter umfassend eine SMM-Indikator-Speicherabbildung, um einen Indikator eines jeden Logik-Prozessors des Prozessorkerns zu speichern, der in SMM eingetreten ist.
  10. Die Vorrichtung nach Anspruch 8, wobei das erste, zweite und dritte Zustandsregister außerhalb von SMM nicht beschreibbar sind.
  11. Die Vorrichtung nach Anspruch 1, weiter umfassend einen Monarch-Prozessor, um den SMM auszuführen, ohne dass sich alle Logik-Prozessoren des Prozessorkerns in dem SMM zusammengefunden haben.
  12. Die Vorrichtung nach Anspruch 11, wobei der Monarch-Prozessor auf ein erstes Statusregister zugreifen soll, das anzeigt, dass ein Logik-Prozessor des Prozessorkerns sich in einer langen Ablauf-Operation befindet, auf ein zweites Statusregister, das anzeigt, dass ein Logik-Prozessor des Prozessorkerns sich in einem SMI-inhibierten Zustand befindet, und auf eine SMM-Indikator-Speicherabbildung, die anzeigt, dass jeder Logik-Prozessor des Prozessorkerns in SMM eingetreten ist, und basierend darauf zu bestimmen, eine angefragte SMM-Operation auszuführen, ohne dass sich alle Logik-Prozessoren zusammengefunden haben.
  13. Die Vorrichtung nach Anspruch 12, wobei der Monarch-Prozessor die angefragte SMM-Operation ausführen soll, ohne dass sich alle Logik-Prozessoren zusammengefunden haben, wenn jeder Logik-Prozessor des Prozessorkerns in SMM eingetreten ist, sich in einer langen Ablauf-Operation oder in einem SMI-inhibierten Zustand befindet.
  14. Verfahren, umfassend: Bestimmen, ob alle Threads, die auf einem Prozessor ausgeführt werden, in einen Systemmanagement-Modus-(system management mode, SMM)-Rendezvous-Zustand, der auf ein Systemmanagement-Unterbrechungs-(system management interrupt, SMI)-Ereignis reagiert, eingetreten sind; und wenn nicht, Bestimmen, ob die verbleibenden Threads eine lange Ablauf-Operation ausführen oder sich in einem SMI-inhibierten Zustand befinden, und wenn dies der Fall ist, Verwenden eines Monarch-Threads, um das SMI-Ereignis zu verarbeiten, während die verbleibenden Threads die lange Ablauf-Operation ausführen oder in dem SMI-inhibierten Zustand sind, ansonsten Warten darauf, dass die verbleibenden Threads in den SMM-Rendezvous-Zustand eintreten, bevor das SMI-Ereignis verarbeitet wird.
  15. Das Verfahren nach Anspruch 14, weiter umfassend Einstellen eines Indikators in einer SMM-Indikator-Speicherabbildung für jeden Thread, der in den SMM-Rendezvous-Zustand eintritt.
  16. Das Verfahren nach Anspruch 15, weiter umfassend: Einstellen eines Indikators eines ersten Zustandsregisters des Prozessors, um anzuzeigen, dass ein Thread sich in einer langen Ablauf-Operation befindet; und Einstellen eines Indikators eines zweiten Zustandsregisters des Prozessors, um anzuzeigen, dass ein Thread sich in einem SMI-inhibierten Zustand befindet; und
  17. Das Verfahren nach Anspruch 16, wobei das Bestimmen das Ausführen einer bitweisen OR-Operation zwischen der SMM-Indikator-Speicherabbildung, dem ersten Zustandsregister und dem zweiten Zustandsregister umfasst.
  18. Das Verfahren nach Anspruch 14, wobei bei Eintritt in den SMM, der Monarch-Thread einen aktiven Zustand, der in einem Zustandsspeicher des Prozessors vorhanden ist, in eine Speichereinheit des Prozessors speichern soll, und einen SMM-Zustand in den Zustandsspeicher speichern soll.
  19. System, umfassend: einen ersten Prozessor, umfassend einen ersten Kern, um Befehle auszuführen und um in einen Systemmanagement-Modus (system management mode, SMM) einzutreten, einen ersten Indikator, um anzuzeigen, ob ein Thread, der auf dem ersten Kern ausgeführt wird, sich in einer langen Ablauf-Operation befindet, einen zweiten Indikator, um anzuzeigen, ob der Thread sich in einem Systemmanagement-Unterbrechungs-(system management interrupt, SMI)-inhibierten Zustand befindet, und eine Speichereinheit, wobei bei Eintritt in den SMM, der erste Kern einen aktiven Zustand, der in einem Zustandsspeicher des ersten Kerns vorhanden ist, in eine Speichereinheit speichern soll, und einen SMM-Ausführungs-Zustand in den Zustandsspeicher speichern soll, wobei die Speichereinheit dem Speicher des aktiven Zustands während des SMM zugehörig ist; einen zweiten Prozessor, umfassend einen zweiten Kern, um Befehle auszuführen und um in den SMM einzutreten, einen ersten Indikator, um anzuzeigen, ob ein zweiter Thread, der auf dem zweiten Kern ausgeführt wird, sich in einer langen Ablauf-Operation befindet, einen zweiten Indikator, um anzuzeigen, ob sich der zweite Thread in dem SMI-inhibierten Zustand befindet, und eine zweite Speichereinheit, wobei bei Eintritt in den SMM, der zweite Kern einen aktiven Zustand, der in einem Zustandsspeicher des zweiten Kerns vorhanden ist, in die zweite Speichereinheit speichern soll, und einen SMM-Ausführungs-Zustand in den Zustandsspeicher speichern soll, wobei die zweite Speichereinheit dem Speicher des aktiven Zustands während des SMM zugehörig ist; einen dynamischen Direktzugriffspeicher (dynamic random access memory, DRAM), der mit den ersten und zweiten Prozessoren gekoppelt ist, wobei ein Teil des DRAM ein Systemmanagement-Direktzugriffspeicher (system management random access memory, SMRAM) für das System ist.
  20. Das System nach Anspruch 19, wobei der DRAM mit einer nichteinheitlichen Speicherarchitektur (non-uniform memory architecture, NUMA) gekoppelt ist, wobei der zweite Prozessor mit dem DRAM über den ersten Prozessor kommunizieren soll.
  21. Das System nach Anspruch 19, wobei der zweite Prozessor den aktiven Zustand nicht in dem SMRAM speichern soll, der auf ein SMI-Signal reagiert, und stattdessen den aktiven Zustand in der zweiten Speichereinheit speichern soll.
  22. Das System nach Anspruch 19, wobei der erste Prozessor einen Monarch-Prozessor beinhaltet, um eine SMM-Operation nach einem SMM-Rendezvous-Zustand auszuführen, wobei zumindest ein Logik-Prozessor der ersten und zweiten Prozessoren nicht in den SMM-Rendezvous-Zustand eintritt.
  23. Das System nach Anspruch 22, wobei der zumindest eine Logik-Prozessor sich in einer langen Ablauf-Operation oder in einem SMI-inhibierten Zustand befindet.
  24. Das System nach Anspruch 22, wobei der Monarch-Prozessor auf eine erste Bitmap zugreifen soll, die anzeigt, ob irgendein Logik-Prozessor des ersten Prozessors sich in einer langen Ablauf-Operation befindet, eine zweite Bitmap, die anzeigt, ob irgendein Logik-Prozessor des ersten Prozessors sich in einem SMI-inhibierten Zustand befindet und eine dritte Bitmap, die anzeigt, ob jeder Logik-Prozessor des ersten Prozessors in den SMM-Rendezvous-Zustand eingetreten ist, und basierend darauf, zu bestimmen, ob die SMM-Operation ausgeführt wird, wenn der zumindest eine Logik-Prozessor nicht in den SMM-Rendezvous-Zustand eintritt.
DE102010034555A 2009-08-31 2010-08-17 Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus Withdrawn DE102010034555A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/550,737 US8578138B2 (en) 2009-08-31 2009-08-31 Enabling storage of active state in internal storage of processor rather than in SMRAM upon entry to system management mode
US12/550,737 2009-08-31

Publications (1)

Publication Number Publication Date
DE102010034555A1 true DE102010034555A1 (de) 2011-03-03

Family

ID=43525352

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102010034555A Withdrawn DE102010034555A1 (de) 2009-08-31 2010-08-17 Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus

Country Status (8)

Country Link
US (4) US8578138B2 (de)
JP (2) JP5430756B2 (de)
KR (3) KR101635778B1 (de)
CN (1) CN102004668B (de)
BR (1) BRPI1010234A2 (de)
DE (1) DE102010034555A1 (de)
GB (1) GB2510792A (de)
WO (1) WO2011025626A2 (de)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255594B2 (en) * 2009-10-15 2012-08-28 Intel Corporation Handling legacy BIOS services for mass storage devices using systems management interrupts with or without waiting for data transferred to mass storage devices
US8954790B2 (en) 2010-07-05 2015-02-10 Intel Corporation Fault tolerance of multi-processor system with distributed cache
US8819225B2 (en) * 2010-11-15 2014-08-26 George Mason Research Foundation, Inc. Hardware-assisted integrity monitor
US8892924B2 (en) * 2011-05-31 2014-11-18 Intel Corporation Reducing power consumption of uncore circuitry of a processor
GB2513748B (en) 2011-12-22 2020-08-19 Intel Corp Power conservation by way of memory channel shutdown
US9507937B2 (en) * 2012-03-30 2016-11-29 Intel Corporation Reporting malicious activity to an operating system
JP2013214210A (ja) * 2012-04-02 2013-10-17 Nec Corp フォールトトレラントシステム、ｃｐｕの動作周波数変更方法、及びプログラム
US8984313B2 (en) * 2012-08-31 2015-03-17 Intel Corporation Configuring power management functionality in a processor including a plurality of cores by utilizing a register to store a power domain indicator
US9383812B2 (en) * 2012-09-28 2016-07-05 Intel Corporation Method and apparatus for efficient store/restore of state information during a power state
KR20150112075A (ko) * 2014-03-26 2015-10-07 삼성전자주식회사 스토리지 장치 및 스토리지 장치의 동작 방법
US9396032B2 (en) * 2014-03-27 2016-07-19 Intel Corporation Priority based context preemption
US20160170767A1 (en) * 2014-12-12 2016-06-16 Intel Corporation Temporary transfer of a multithreaded ip core to single or reduced thread configuration during thread offload to co-processor
US9977682B2 (en) * 2015-12-09 2018-05-22 Intel Corporation System management mode disabling and verification techniques
US9898351B2 (en) * 2015-12-24 2018-02-20 Intel Corporation Method and apparatus for user-level thread synchronization with a monitor and MWAIT architecture
US20210026950A1 (en) * 2016-03-07 2021-01-28 Crowdstrike, Inc. Hypervisor-based redirection of system calls and interrupt-based task offloading
US11182315B2 (en) * 2017-02-10 2021-11-23 Intel Corporation Apparatuses, methods, and systems for hardware control of processor performance levels
US10678909B2 (en) * 2017-04-21 2020-06-09 Vmware, Inc. Securely supporting a global view of system memory in a multi-processor system
US10990159B2 (en) * 2017-04-25 2021-04-27 Apple Inc. Architected state retention for a frequent operating state switching processor
US10528398B2 (en) * 2017-09-29 2020-01-07 Intel Corporation Operating system visibility into system states that cause delays and technology to achieve deterministic latency
US10552280B2 (en) 2017-12-14 2020-02-04 Microsoft Technology Licensing, Llc In-band monitor in system management mode context for improved cloud platform availability
US11354135B2 (en) * 2017-12-25 2022-06-07 Intel Corporation Pre-memory initialization multithread parallel computing platform
US11593154B2 (en) * 2018-12-20 2023-02-28 Intel Corporation Operating system assisted prioritized thread execution
KR20200114017A (ko) * 2019-03-27 2020-10-07 에스케이하이닉스 주식회사 컨트롤러 및 그 동작 방법
US11481206B2 (en) * 2019-05-16 2022-10-25 Microsoft Technology Licensing, Llc Code update in system management mode
US11119770B2 (en) * 2019-07-26 2021-09-14 Microsoft Technology Licensing, Llc Performing atomic store-and-invalidate operations in processor-based devices
US11385903B2 (en) 2020-02-04 2022-07-12 Microsoft Technology Licensing, Llc Firmware update patch
US11520653B2 (en) 2020-10-15 2022-12-06 Nxp Usa, Inc. System and method for controlling faults in system-on-chip
CN117331676B (zh) * 2023-11-30 2024-03-19 上海兆芯集成电路股份有限公司 系统管理模式进入方法、处理器和计算机系统

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5369771A (en) * 1991-12-23 1994-11-29 Dell U.S.A., L.P. Computer with transparent power-saving manipulation of CPU clock
US5357628A (en) * 1992-03-25 1994-10-18 Intel Corporation Computer system having integrated source level debugging functions that provide hardware information using transparent system interrupt
US5764999A (en) * 1995-10-10 1998-06-09 Cyrix Corporation Enhanced system management mode with nesting
US5819020A (en) 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
US5689698A (en) 1995-10-20 1997-11-18 Ncr Corporation Method and apparatus for managing shared data using a data surrogate and obtaining cost parameters from a data dictionary by evaluating a parse tree object
US6240414B1 (en) 1997-09-28 2001-05-29 Eisolutions, Inc. Method of resolving data conflicts in a shared data environment
US6571206B1 (en) * 1998-01-15 2003-05-27 Phoenix Technologies Ltd. Apparatus and method for emulating an I/O instruction for the correct processor and for servicing software SMI's in a multi-processor environment
US6766326B1 (en) 2000-07-24 2004-07-20 Resty M Cena Universal storage for dynamic databases
US6848046B2 (en) * 2001-05-11 2005-01-25 Intel Corporation SMM loader and execution mechanism for component software for multiple architectures
US8032592B2 (en) 2002-04-18 2011-10-04 Intuit Inc. System and method for data collection and update utilizing surrogate e-mail addresses using a server
DE60330035D1 (de) 2002-09-09 2009-12-24 Dell Marketing Usa L P System und verfahren zur anwendungsüberwachung und automatischen katastrophenbehebung für hohe verfügbarkeit
US7152169B2 (en) * 2002-11-29 2006-12-19 Intel Corporation Method for providing power management on multi-threaded processor by using SMM mode to place a physical processor into lower power state
US7219241B2 (en) 2002-11-30 2007-05-15 Intel Corporation Method for managing virtual and actual performance states of logical processors in a multithreaded processor using system management mode
US7117319B2 (en) 2002-12-05 2006-10-03 International Business Machines Corporation Managing processor architected state upon an interrupt
JP2004220070A (ja) * 2003-01-09 2004-08-05 Japan Science & Technology Agency コンテキスト切り替え方法及び装置、中央演算装置、コンテキスト切り替えプログラム及びそれを記憶したコンピュータ読み取り可能な記憶媒体
US7380106B1 (en) 2003-02-28 2008-05-27 Xilinx, Inc. Method and system for transferring data between a register in a processor and a point-to-point communication link
US7251745B2 (en) 2003-06-11 2007-07-31 Availigent, Inc. Transparent TCP connection failover
US7363411B2 (en) 2003-10-06 2008-04-22 Intel Corporation Efficient system management synchronization and memory allocation
US7617488B2 (en) * 2003-12-30 2009-11-10 Intel Corporation Method and apparatus and determining processor utilization
US7653727B2 (en) * 2004-03-24 2010-01-26 Intel Corporation Cooperative embedded agents
US8996455B2 (en) 2004-04-30 2015-03-31 Netapp, Inc. System and method for configuring a storage network utilizing a multi-protocol storage appliance
US7487222B2 (en) 2005-03-29 2009-02-03 International Business Machines Corporation System management architecture for multi-node computer system
US7818388B2 (en) 2005-10-07 2010-10-19 International Business Machines Corporation Data processing system, method and interconnect fabric supporting multiple planes of processing nodes
US7433985B2 (en) * 2005-12-28 2008-10-07 Intel Corporation Conditional and vectored system management interrupts
US20070156960A1 (en) 2005-12-30 2007-07-05 Anil Vasudevan Ordered combination of uncacheable writes
US8973094B2 (en) * 2006-05-26 2015-03-03 Intel Corporation Execution of a secured environment initialization instruction on a point-to-point interconnect system
US20080040524A1 (en) * 2006-08-14 2008-02-14 Zimmer Vincent J System management mode using transactional memory
US7555671B2 (en) * 2006-08-31 2009-06-30 Intel Corporation Systems and methods for implementing reliability, availability and serviceability in a computer system
JP4802123B2 (ja) 2007-03-07 2011-10-26 富士通株式会社 情報送信装置、情報送信方法、情報送信プログラムおよび該プログラムを記録した記録媒体
US20090037932A1 (en) 2007-08-01 2009-02-05 Clark Michael T Mechanism for broadcasting system management interrupts to other processors in a computer system
US7831858B2 (en) * 2007-08-31 2010-11-09 Intel Corporation Extended fault resilience for a platform
US7962314B2 (en) * 2007-12-18 2011-06-14 Global Foundries Inc. Mechanism for profiling program software running on a processor
US7996663B2 (en) * 2007-12-27 2011-08-09 Intel Corporation Saving and restoring architectural state for processor cores
US7802042B2 (en) * 2007-12-28 2010-09-21 Intel Corporation Method and system for handling a management interrupt event in a multi-processor computing device
US7913018B2 (en) * 2007-12-28 2011-03-22 Intel Corporation Methods and apparatus for halting cores in response to system management interrupts
US7991933B2 (en) * 2008-06-25 2011-08-02 Dell Products L.P. Synchronizing processors when entering system management mode

Also Published As

Publication number Publication date
US8578138B2 (en) 2013-11-05
JP5430756B2 (ja) 2014-03-05
BRPI1010234A2 (pt) 2016-03-22
US20180143923A1 (en) 2018-05-24
KR101635778B1 (ko) 2016-07-04
JP5801372B2 (ja) 2015-10-28
KR101572079B1 (ko) 2015-11-27
US20140040543A1 (en) 2014-02-06
JP2014075147A (ja) 2014-04-24
WO2011025626A9 (en) 2011-05-26
KR20120061938A (ko) 2012-06-13
WO2011025626A3 (en) 2011-07-14
KR20130081301A (ko) 2013-07-16
CN102004668A (zh) 2011-04-06
US10169268B2 (en) 2019-01-01
KR20130081302A (ko) 2013-07-16
GB201122094D0 (en) 2012-02-01
US20170010991A1 (en) 2017-01-12
US9465647B2 (en) 2016-10-11
KR101392109B1 (ko) 2014-05-07
GB2510792A (en) 2014-08-20
CN102004668B (zh) 2014-08-20
JP2012531680A (ja) 2012-12-10
WO2011025626A2 (en) 2011-03-03
US20110055469A1 (en) 2011-03-03

Similar Documents

Publication Publication Date Title
DE102010034555A1 (de) Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus
DE112011105298B4 (de) Reduzieren des Energieverbrauchs von Uncore-Schaltkreisen eines Prozessors
DE69633166T2 (de) Integrierter schaltkreis mit mehreren funktionen und gemeinsamer verwendung mehrerer interner signalbusse zur verteilung der steuerung des buszugriffes und der arbitration
DE102014003798B4 (de) Verfahren zum Booten eines heterogenen Systems und Präsentieren einer symmetrischen Kernansicht
DE102020120019A1 (de) Proaktive di/dt-spannungs-dachabfall-abschwächung
DE69807729T2 (de) Threadumschaltungssteuerung in einem multithreadprozessorsystem
DE112012005210B4 (de) Bereitstellen eines gemeinsamen Caching-Agenten für ein Kern- und integriertes Ein-/Ausgabe-(IO)-Modul
DE69901176T2 (de) Rechnersystem mit einem emulationscoprozessor und verfahren zur emulation eines anwendungsprogramms
DE102010052680A1 (de) Ein Befehl, um einen Prozessor-Wartezustand zu ermöglichen
DE112004001887B4 (de) Optimierung der SMI-Behandlung und -Initialisierung
DE112016007566T5 (de) Systeme, Verfahren und Vorrichtungen zur heterogenen Berechnung
DE112010004965T5 (de) Steuerung von Zeitstempelzähler-(TSC)-Offsets für Mehrfach-Kerne und -Threads
DE102010035603A1 (de) Bereitstellen von Hardwareunterstützung für gemeinsam benutzten virtuellen Speicher zwischen physischem Lokal- und Fernspeicher
DE112013003731T5 (de) Neue befehls- und hocheffiziente Mikroarchitektur zum ermöglichen einer sofortigen Kontextumschaltung für Benutzerebenen-Threading
DE112016004303T5 (de) Hardware-Vorhersageelement mit geringem Verwaltungsaufwand zur Verringerung der Leistungsumkehr für Kern-zu-Kern-Datenübertragungsoptimierungsbefehle
DE112010002425B4 (de) Delegieren einer Anfrageoperation an eine ander Einrichtung
DE112010004971T5 (de) Ein System, Verfahren und eine Vorrichtung für einen Cache-Flush eines Seitenbereichs und TLB Invalidierung eines Bereichs von Einträgen
DE112007001171T5 (de) Verfahren für virtualisierten Transaktionsspeicher bei globalem Überlauf
DE112012007115T5 (de) Wahlweise Logikprozessor-Zählung und Typauswahl für eine gegebene Arbeitsbelastung basierend auf Wärme- und Leistungsbudget-Einschränkungen der Plattform
DE112015001477B4 (de) Hardwarezähler zum Verfolgen einer Auslastung in einem Multithreading-Computersystem
DE112004001133T5 (de) Warteschlangen-Sperren mit Monitor-Memory-Wait
DE112013004751T5 (de) Prozessor mit mehreren Kernen, gemeinsam genutzter Kernerweiterungslogik und gemeinsam genutzten Kernerweiterungsnutzungsbefehlen
DE102010045743A1 (de) Verfahren und Vorrichtung um Turboleistung für das Event-Handling zu verbessern
DE112010003330T5 (de) Einrichten von Prüfpunkten bei Cachespeichern für die spekulative Versionierung
DE10393727T5 (de) Prozessor-Cache-Speicher als RAM zur Ausführung von Boot-Code

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20150303