DE112013002254T5

DE112013002254T5 - Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung

Info

Publication number: DE112013002254T5
Application number: DE112013002254.0T
Authority: DE
Inventors: Wenwei Tang; Adam Lee Soderlund; Songqing Wu
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-04-28
Filing date: 2013-04-12
Publication date: 2015-03-05
Also published as: JP2015518615A; US20150227427A1; JP6124994B2; US9081734B2; WO2013159652A1; US20130290778A1; GB2517333B; CN103377063B; CN103377063A; US9372754B2; GB201420702D0; GB2517333A

Abstract

Die vorliegende Erfindung offenbart ein Verfahren und ein System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer Unified-Extensible-Firmware-Interface(UEFI)-Preboot-Umgebung, wobei das Verfahren aufweist: Speichern von Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; Wiederherstellen eines ersten Abschnitts des CPU-Ausführungskontextes in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus und Wiederherstellen eines zweiten Abschnitts des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus; und Verlassen des CPU-Systemverwaltungsmodus und dadurch Zurückkehren zu der UEFI-Preboot-Umgebung. Das Verfahren und das System können zu der UEFI-Preboot-Umgebung wiederherstellen, nachdem ein Versuch, das Altbetriebssystem zu booten, fehlschlägt, und dadurch eine Diagnose über einen Boot-Fehler des Altbetriebssystems und einen nachfolgenden Boot-Versuch des UEFI-Betriebssystems unterstützen.

Description

Hintergrund
Die vorliegende Erfindung bezieht sich auf Firmware in einem Computersystem und im Besonderen auf ein Verfahren und ein System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung.
Bei einem Alt-BIOS (Basic Input/Output System) handelt es sich um eine Art von Firmware als grundlegendes Eingabe-/Ausgabe-System, es ist für Aufgaben wie Hardware-Booten und -Erkennung beim Einschalten zuständig und fungiert als Zwischenglied, während das Betriebssystem die Hardware steuert. Seit Windows NT, Linux, haben diese Betriebssysteme Hardware-Steuerprogramme, die in der Vergangenheit durch das BIOS durchgeführt werden mussten, in das Betriebssystem verlagert, die Programme werden im Betriebssystem ausgeführt, und es besteht keine Notwendigkeit mehr, die BIOS-Funktionalität aufzurufen. Aufgrund der schnellen Entwicklung von Hardware sind Alt-BIOS bei der Entwicklung zu einer Belastung geworden.
Heutzutage ist ein neuestes Extensible Firmware Interface (EFI, erweiterbare Firmware-Schnittstelle) entwickelt worden. Unified Extensible Firmware Interface (UEFI, Vereinheitlichte erweiterbare Firmware-Schnittstelle) wurde auf der Grundlage von EFI1.10 entwickelt, und UEFI ist ein Standard, der einen vollständig neuen Schnittstellentyp beschreibt. Eine solche Schnittstelle wird durch Betriebssysteme zum automatischen Laden aus einer Preboot-Betriebsumgebung in einen Betriebssystemtyp verwendet, wodurch die Einschaltprozedur vereinfacht und Zeit eingespart wird.
UEFI verwendet einen Ansatz zur Parameterstapelübergabe im Stil der Sprache C und eine Art einer dynamischen Verbindung, um ein System zu erstellen, es ist leichter zu implementieren als ein IOS, weist eine bessere Fehlertoleranz und Fehlerkorrektur auf und kann den Zeitaufwand für Systemrecherche und -entwicklung verkürzen. Des Weiteren arbeitet UEFI im 32-Bit- oder 64-Bit-Modus, und eine bessere Adressierungsfähigkeit könnte eine bessere Leistungsfähigkeit im Vergleich zum BIOS bieten. Darüber hinaus ist der Treiber der UEFI-Architektur in EFI-Byte-Code geschrieben, wobei es sich um einen Satz virtueller Maschinenbefehle für einen UEFI-Treiber handelt, die Befehle werden so interpretiert, dass sie in einer UEFI-gesteuerten Betriebsumgebung ausgeführt werden und eine ausreichende Abwärtskompatibilität von UEFI sicherstellen können. Zudem ist eine Graphiktreiberfunktion in UEFI integriert, die eine Farbgraphikumgebung mit hoher Auflösung bereitstellen kann. Nach dem Eintreten in die Umgebung kann der Benutzer Konfigurationen durch Klicken mit einer Maus anpassen, was so einfach wie eine Anwendungs-Software in einem Windows-System ist. Des Weiteren setzt UEFI eine modulare Konstruktion ein und ist logisch in zwei Teile aufgeteilt: Hardware-Steuerung und Betriebssystem-Software-Verwaltung, wobei Hardware-Steuerung allen UEFI-Versionen gemein ist und es sich bei Betriebssystem-Software-Verwaltung genau genommen um eine programmierbare offene Schnittstelle handelt, durch die Hersteller von Hauptplatinen verschiedene umfangreiche Funktionen umsetzen können. Beispielsweise können verschiedene Sicherungs- und Diagnosefunktionen, die unter Fachleuten allgemein bekannt sind, durch UEFI umgesetzt werden. Daher haben derzeit zahlreiche Computerhersteller begonnen, UEFI-Firmware zu verwenden, und es wird erwartet, dass der Verkauf von durch UEFI-Firmware unterstützten Maschinen eine beherrschende Stellung einnehmen wird.
Aus Sicht der UEFI-Firmware können Betriebssysteme in zwei Typen eingeteilt werden: Der erste Betriebssystemtyp kann UEFI-Firmware unterstützen und nutzen, wie zum Beispiel Windows Server 2008 R2; der zweite Betriebssystemtyp kann UEFI-Firmware nicht unterstützen, d. h. Altbetriebssysteme. UEFI kann ein Kompatibilitätsunterstützungsmodul bereitstellen, das UEFI-Firmware in die Lage versetzt, ein Altbetriebssystem zu laden und zu booten, beispielsweise Windows XP in der 32-Bit-Version, Windows Server 2003 für x86 usw.
Die Ausführungsumgebung von UEFI-Firmware ist eine UEFI-Preboot-Umgebung, diese Umgebung führt UEFI-Firmware-Code aus und stellt System-Boot-Stufen der Boot-Umgebung für das Betriebssystem bereit. Wenn das Systemlademodul der UEFI-Firmware ein Betriebssystem lädt, das UEFI unterstützt und nutzt, kann das Systemlademodul direkt zu der UEFI-Preboot-Umgebung zurückkehren, wenn das Betriebssystem aufgrund eines Problems nicht erfolgreich geladen werden kann. Wenn das Systemlademodul der UEFI-Firmware ein Altbetriebssystem lädt und bootet, wird jedoch ein Kompatibilitätsunterstützungsmodul in dem Systemlademodul benötigt, oder es wird ein Kompatibilitätsunterstützungsmodul direkt ohne das Systemlademodul verwendet, um das Laden und Booten des Altbetriebssystems zu ermöglichen. Nach dem Stand der Technik gibt es jedoch, nachdem das UEFI in das Kompatibilitätsunterstützungsmodul eintritt, um einen Boot-Versuch an dem Altbetriebssystem durchzuführen, keine Möglichkeit, zu der UEFI-Preboot-Umgebung zurückzukehren, selbst wenn der Boot-Versuch des Altbetriebssystems fehlschlägt. Insofern können Entwickler keine Problemdiagnose durchführen.
Kurzdarstellung
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer Unified-Extensible-Firmware-Interface(UEFI)-Preboot-Umgebung bereitgestellt, das aufweist: Speichern von Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; Wiederherstellen eines ersten Abschnitts des CPU-Ausführungskontextes in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus und Wiederherstellen eines zweiten Abschnitts des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus; und Verlassen des CPU-Systemverwaltungsmodus und dadurch Zurückkehren zu der UEFI-Preboot-Umgebung.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer Unified-Extensible-Firmware-Interface(UEFI)-Preboot-Umgebung bereitgestellt, das aufweist: eine Speichereinheit, die dazu eingerichtet ist, Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung zu speichern, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; eine erste Wiederherstellungseinheit, die dazu eingerichtet ist, einen ersten Abschnitt des CPU-Ausführungskontextes in Reaktion darauf wiederherzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eine zweite Wiederherstellungseinheit, die dazu eingerichtet ist, die CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus eintreten zu lassen und einen zweiten Abschnitt des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus wiederherzustellen; und ein Beendigungsmittel, das dazu eingerichtet ist, den CPU-Systemverwaltungsmodus zu verlassen und dadurch zu der UEFI-Preboot-Umgebung zurückzukehren.
Kurzbeschreibung der verschiedenen Ansichten der Zeichnungen
Durch die ausführlichere Beschreibung einiger Ausführungsformen der vorliegenden Offenbarung in den beigefügten Zeichnungen werden die obigen und sonstige Aufgaben, Merkmale und Vorteile der vorliegenden Offenbarung besser ersichtlich, wobei sich dasselbe Bezugszeichen im Allgemeinen auf dieselben Komponenten in den Ausführungsformen der vorliegenden Offenbarung bezieht.
1 stellt ein beispielhaftes Computersystem 100 dar, das anwendbar ist, um die Ausführungsformen der vorliegenden Erfindung zu implementieren;
2 stellt ein Blockschaubild einer UEFI-Preboot-Umgebung gemäß der vorliegenden Erfindung dar;
3 stellt Schritte eines Verfahrens zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung dar;
4 stellt Arten von Speicherbereichen dar, die durch UEFI-Firmware definiert werden; und
5 stellt ein strukturelles Blockschaubild eines Systems zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung dar.
Ausführliche Beschreibung
Einige bevorzugte Ausführungsformen werden ausführlicher unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen die bevorzugten Ausführungsformen der vorliegenden Offenbarung veranschaulicht worden sind. Die vorliegende Offenbarung kann jedoch in verschiedenen Formen implementiert werden und sollte nicht so verstanden werden, dass sie auf die hierin offenbarten Ausführungsformen beschränkt ist. Vielmehr werden diese Ausführungsformen zum umfassenden und vollständigen Verständnis der vorliegenden Offenbarung und zum vollständigen Vermitteln des Umfangs der vorliegenden Offenbarung für Fachleute bereitgestellt.
1 stellt ein beispielhaftes Computersystem 100 dar, das anwendbar ist, um die Ausführungsformen der vorliegenden Erfindung zu implementieren. Wie in 1 dargestellt, kann das Computersystem 100 beinhalten: eine CPU (Central Process Unit, Zentraleinheit) 101, einen RAM (Random Access Memory, Direktzugriffsspeicher) 102, einen ROM (Read Only Memory, Festwertspeicher) 103, einen Systembus 104, eine Festplatten-Steuereinheit 105, eine Tastatursteuereinheit 106, eine Steuereinheit 107 für serielle Schnittstellen, eine Steuereinheit 108 für parallele Schnittstellen, eine Anzeigensteuereinheit 109, eine Festplatte 110, eine Tastatur 111, eine serielle Peripherieeinheit 112, eine parallele Peripherieeinheit 113 und eine Anzeige 114. Von diesen Einheiten ist der Systembus 104 mit der CPU 101, dem RAM 102, dem ROM 103, der Festplatten-Steuereinheit 105, der Tastatursteuereinheit 106, der Steuereinheit 107 für serielle Schnittstellen, der Steuereinheit 108 für parallele Schnittstellen und der Anzeigensteuereinheit 109 verbunden. Die Festplatte 110 ist mit der Festplatten-Steuereinheit 105 verbunden. Die Tastatur 111 ist mit der Tastatursteuereinheit 106 verbunden. Die serielle Peripherieeinheit 112 ist mit der Steuereinheit 107 für serielle Schnittstellen verbunden. Die parallele Peripherieeinheit 113 ist mit der Steuereinheit 108 für parallele Schnittstellen verbunden. Und die Anzeige 114 ist mit der Anzeigesteuereinheit 109 verbunden. Es versteht sich, dass die Struktur, wie sie in 1 dargestellt wird, statt einer Beschränkung der vorliegenden Erfindung lediglich beispielhaft sein soll. In manchen Fällen können auf der Grundlage bestimmter Situationen einige Einheiten zu dem Computersystem 100 hinzugefügt oder daraus entfernt werden.
Wie für einen Fachmann ersichtlich ist, können Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt verkörpert werden. Dementsprechend können Aspekte der vorliegenden Erfindung eine reine Hardware-Ausführungsform, eine reine Software-Ausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder eine Ausführungsform annehmen, in der Software- und Hardware-Aspekte kombiniert werden, die sämtlich hierin verallgemeinernd als „Schaltung”, „Modul” oder „System” bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien verkörpert wird, auf denen computerlesbarer Programmcode verkörpert ist.
Es kann eine beliebige Kombination eines oder mehrerer computerlesbarer Medien verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Bei einem computerlesbaren Speichermedium kann es sich zum Beispiel um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine solche Vorrichtung oder Einheit oder um eine beliebige geeignete Kombination aus Obigen handeln, ohne auf diese beschränkt zu sein. Zu konkreteren Beispielen (einer nicht erschöpfenden Liste) des computerlesbaren Speichermediums würden folgende gehören: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer, programmierbarer Festwertspeicher (erasable programmable read-only memory, EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact-Disk-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine Magnetspeichereinheit oder eine beliebige geeignete Kombination der Obigen. Im Rahmen dieses Dokuments kann ein computerlesbares Speichermedium jedes physische Medium sein, das ein Programm zur Verwendung durch ein System, eine Vorrichtung oder Einheit zur Befehlsausführung bzw. in Verbindung mit diesen enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein sich ausbreitendes Datensignal, in dem computerlesbarer Programmcode verkörpert wird, zum Beispiel im Basisband oder als Teil einer Trägerwelle beinhalten. Ein solches sich ausbreitendes Signal kann eine Vielfalt von Formen annehmen, darunter eine elektromagnetische Form, eine optische Form oder eine beliebige geeignete Kombination derselben, ohne auf diese beschränkt zu sein. Bei einem computerlesbaren Signalmedium kann es sich um ein beliebiges computerlesbares Medium handeln, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch ein System, eine Vorrichtung oder Einheit zur Befehlsausführung bzw. in Verbindung mit diesen austauschen, verbreiten oder transportieren kann.
Auf einem computerlesbaren Medium verkörperter Programmcode kann mithilfe eines beliebigen geeigneten Mediums übertragen werden, zum Beispiel über Funk, Kabel, Lichtwellenleiterkabel, Hochfrequenz (HF) usw. oder über eine beliebige geeignete Kombination der Obigen, ohne auf diese beschränkt zu sein.
Computerprogrammcode zum Ausführen von Vorgängen für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination einer oder mehrerer Programmiersprachen geschrieben werden, zum Beispiel in einer objektorientierten Programmiersprache wie etwa Java, Smalltalk, C++ oder dergleichen und in herkömmlichen verfahrensorientierten Programmiersprachen wie zum Beispiel der Programmiersprache „C” oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, zum Teil auf dem Computer des Benutzers, als eigenständiges Software-Paket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art von Netzwerk verbunden sein, zum Beispiel durch ein lokales Netzwerk (local region network, LAN) oder ein Weitverkehrs-Netzwerk (wide region network, WAN), oder die Verbindung kann mit einem externen Computer (zum Beispiel über das Internet mithilfe eines Internet-Diensteanbieters) hergestellt werden.
Aspekte der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaubildern durch Computerprogrammbefehle implementiert werden kann/können. Diese Computerprogrammbefehle können für einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Befehle, die über den Prozessor des Computers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel zum Implementieren der Funktionen/Vorgänge erzeugen, die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben sind.
Diese Computerprogrammbefehle können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, eine sonstige programmierbare Datenverarbeitungsvorrichtung oder sonstige Einheiten so steuern kann, dass sie in einer bestimmten Weise funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsgegenstand (article of manufacture) erzeugen, der Befehlsmittel beinhaltet, die die/den Funktion/Vorgang implementieren, die/der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben ist.
Die Computerprogrammbefehle können außerdem auf einen Computer, eine sonstige programmierbare Datenverarbeitungsvorrichtung oder sonstige Einheiten geladen werden, um zu bewirken, dass eine Reihe von Schritten eines Vorgangs auf dem Computer, einer sonstigen programmierbaren Vorrichtung oder sonstigen Einheiten ausgeführt wird, um einen computerimplementierten Prozess zu erzeugen, sodass die auf dem Computer oder einer sonstigen programmierbaren Vorrichtung ausgeführten Befehle Prozesse bereitstellen, um die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Vorgänge zu implementieren.
Unter Bezugnahme auf 2 wird ein Blockschaubild einer UEFI-Preboot-Umgebung gemäß der vorliegenden Erfindung, das heißt, ein Blockschaubild einer UEFI-Firmware dargestellt. In der Beschreibung sind UEFI-Preboot-Umgebung und UEFI-Firmware synonym und werden nicht unterschieden. Die UEFI-Preboot-Umgebung beinhaltet vor allem ein UEFI-Ausführungsumgebungsmodul, und dieses Modul beinhaltet des Weiteren ein Sicherheitsmodul, ein Initialisierungsmodul, ein Treiberausführungsumgebungs-Modul, ein Boot-Treiberauswahlmodul und ein Systemlademodul oder ein Kompatibilitätsunterstützungsmodul. Wenn das Systemlademodul des UEFI ein Betriebssystem lädt, das UEFI unterstützt und nutzt, kann das Systemlademodul, da ein solches Betriebssystem einige durch die UEFI-Spezifikation definierte Standardschnittstellen unterstützt, direkt zu der UEFI-Preboot-Umgebung zurückkehren, wenn das Betriebssystem aufgrund eines Problems nicht erfolgreich geladen werden kann. Wenn das Kompatibilitätsunterstützungsmodul des UEFI ein Altbetriebssystem lädt und bootet, gibt es jedoch, nachdem das UEFI in das Kompatibilitätsunterstützungsmodul eintritt, um einen Boot-Versuch an dem Altbetriebssystem durchzuführen, keine Möglichkeit, zu der UEFI-Preboot-Umgebung zurückzukehren, selbst wenn der Boot-Versuch des Altbetriebssystems fehlschlägt. Insofern können Entwickler keine Problemdiagnose durchführen.
Sowohl bei UEFI-Firmware als auch bei einem Betriebssystem handelt es sich um Software, die auf CPU-Hardware ausgeführt wird. UEFI-Firmware ist ein Codesegment, das vor dem Betriebssystem ausgeführt wird, und es ist für die Hardware-Initialisierung, bevor das Betriebssystem startet, und für die Vorbereitung von Service-Schnittstellen zuständig, die für das Betriebssystem verfügbar sind. Ein CPU-System weist verschiedene Modi auf, darunter den realen Modus, den geschützten Modus, den virtuellen 8068-Modus und den Systemverwaltungsmodus, und das CPU-System kann zwischen verschiedenen Modi umgeschaltet werden. Die CPU arbeitet im Allgemeinen im realen Modus, nachdem sie eingeschaltet worden ist, die CPU verwendet Register, um die CPU über den Speicherort von Befehlen im Speicher in Kenntnis zu setzen; sie verwendet die Register DS, ES, FS, GS, SS und andere, um den Speicherort von Datensegmenten mit unterschiedlichen Zwecken im Speicher zu kennzeichnen, um Hauptinhalt zu kennzeichnen, der beim Ausführen eines nächsten Programms benötigt wird. Der geschützte Modus stimmt mit dem realen Modus überein, und der Kern des Ausführens eines Programms unter dem geschützten Modus ist weiterhin „die CPU führt einen oder mehrere Befehle aus, um zugehörige Daten zu verarbeiten”. Auf diese Weise sind verschiedene Codesegmente, Datensegmente, Stapelsegmente, Interrupt-Service-Programme im realen Modus noch vorhanden, und ihre Funktionen und Auswirkungen bleiben unverändert. UEFI-Firmware arbeitet im realen Modus, nachdem die CPU eingeschaltet worden ist, und das UEFI beinhaltet außerdem Code, der im geschützten Modus der CPU ausgeführt wird, und Code, der im Systemverwaltungsmodus der CPU ausgeführt wird. Wenn das UEFI in das Kompatibilitätsunterstützungsmodul eintritt, um einen Boot-Versuch an einem Altbetriebssystem durchzuführen, wird Code des UEFI im geschützten Modus der CPU ausgeführt. Wenn der Boot-Versuch fehlschlägt und es erforderlich ist, zur UEFI-Preboot-Umgebung zurückzukehren, ist es zuerst erforderlich, in den geschützten Modus der CPU zurückzukehren. Bei dem Systemverwaltungsmodus handelt es sich um einen speziellen Prozessormodus, der einige Funktionen auf Systemebene bereitstellen kann, beispielsweise Stromquellenverwaltung, System-Hardware-Steuerung und so weiter. Der Hauptvorteil des Systemverwaltungsmodus besteht darin, dass er eine Prozessorumgebung bereitstellen kann, die sich vollständig von der gewöhnlichen CPU-Betriebsumgebung unterscheidet und von dieser unabhängig ist. Eine solche Umgebung ist für ein Betriebssystem oder eine Anwendungs-Software schwer zu erkennen. Wenn die CPU in den Systemverwaltungsmodus eintritt, speichert die CPU einen Abschnitt der CPU-Ausführungskontextdaten wie zum Beispiel Registerwerte der CPU in einem Block des Speichers des Systemverwaltungsmodus (SMM-RAM), d. h. einem sogenannten CPU-Statussicherungsbereich. Beim Verlassen des Systemverwaltungsmodus nutzt der Prozessor einen Abschnitt des CPU-Ausführungskontextes in dem Prozessor-Statussicherungsbereich, um den Prozessorstatus vor dem Eintreten in den Systemverwaltungsmodus wiederherzustellen. Die UEFI-Firmware kann ein solches technisches Merkmal wie eine Prozessorstatus-Wiederherstellung vor dem Eintreten in den Systemverwaltungsmodus beim Verlassen des Systemverwaltungsmodus nutzen, um zu der UEFI-Umgebung vor der Ausführung zurückzukehren.
Bei einem Betriebssystem, das UEFI unterstützt, kehrt, da das Systemlademodul direkt durch das UEFI aufgerufen wird, das Systemlademodul direkt zu der UEFI-Umgebung vor der Ausführung zurück, wenn dies fehlschlägt. Das Betriebssystem zerstört den Kontext der UEFI-Preboot-Umgebung nicht, bevor es erfolgreich geladen worden ist. Nachdem das Betriebssystem erfolgreich gestartet worden ist, besteht jedoch keine Möglichkeit, direkt zu der UEFI-Preboot-Umgebung zurückzukehren.
Das Kompatibilitätsunterstützungsmodul kann ein Altbetriebssystem starten, der Grund dafür ist, dass das Kompatibilitätsunterstützungsmodul Implementierungen einiger Schnittstellen in der UEFI-Firmware bereitstellt, die von Altbetriebssystemen oder Alt-Options-ROM benötigt werden, die ursprünglich im herkömmlichen BIOS vorhanden waren, wobei es sich bei dem Options-ROM um einen Firmware-Typ handelt, der verschiedene Platinen und Karten steuert und auf Platinen und Karten platziert werden kann oder in der UEFI-Firmware oder der BIOS-Firmware enthalten sein kann. Nachdem die UEFI-Firmware jedoch in das Kompatibilitätsunterstützungsmodul eintritt, um einen Boot-Vorgang des Altbetriebssystems durchzuführen, wird der Kontext der UEFI-Preboot-Umgebung zerstört. Auf diese Weise besteht keine Möglichkeit, zu der UEFI-Preboot-Umgebung zurückzukehren, selbst wenn der Versuch, das Altbetriebssystem zu booten, fehlschlägt, da der Kontext der UEFI-Preboot-Umgebung zerstört worden ist.
Um zu der UEFI-Preboot-Umgebung zurückzukehren, ist folglich eines wichtig, um die Integrität der UEFI-Preboot-Umgebung zu gewährleisten, nämlich, benötigte Daten im Kontext der UEFI-Preboot-Umgebung zu speichern. Ein weiterer Aspekt bei der Nutzung der obigen Funktion ist, dass die CPU den Prozessorstatus vor dem Eintreten in den Systemverwaltungsmodus speichert, wenn sie den Systemverwaltungsmodus verlässt.
Dementsprechend stellt die vorliegende Erfindung ein Verfahren und ein System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung bereit. Innerhalb einer Umgebung, die mehrere Betriebssysteme unterstützt, können ein solches Verfahren und System dazu verwendet werden, eine Diagnose bei einem Boot-Fehler eines Altbetriebssystems und einem nachfolgenden Boot-Versuch eines UEFI-Betriebssystems zu unterstützen.
3 stellt Schritte eines Verfahrens zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung dar. Gemäß 3 weist das Verfahren auf:
In Schritt S301 Speichern des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, CPU-Ausführungskontext aufweist;
In Schritt S302 Wiederherstellen eines ersten Abschnitts des CPU-Ausführungskontextes in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt;
In Schritt S303 Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus und Wiederherstellen eines zweiten Abschnitts des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus; und
In Schritt S304 Verlassen des CPU-Systemverwaltungsmodus und dadurch Zurückkehren zu der UEFI-Preboot-Umgebung.
Der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, weist CPU-Ausführungskontext auf. Im Besonderen kann der CPU-Ausführungskontext in zwei Abschnitte unterteilt werden: Der erste Abschnitt beinhaltet eine globale Deskriptortabelle (GDT), eine Interrupt-Deskriptortabelle (IDT), ein Steuerregister und ein Segmentregister; der zweite Abschnitt beinhaltet ein Markierungsregister, ein Befehlszeigerregister, ein Allgemeinregister, ein Systemverwaltungs-Basisregister. Da die CPU nur in den Systemverwaltungsmodus eintreten kann, nachdem der erste Abschnitt des CPU-Ausführungskontextes wiederhergestellt worden ist; wohingegen der zweite Abschnitt des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus wiederhergestellt werden muss, sodass die CPU diesen CPU-Ausführungskontext nutzen kann, um den Prozessorstatus vor dem Eintreten in den Systemverwaltungsmodus wiederherzustellen, wenn die CPU den Systemverwaltungsmodus verlässt, wodurch eine Wiederherstellung zu der UEFI-Preboot-Umgebung erfolgt.
Bei den Registern der CPU handelt es sich um Software- und Hardware-Schnittstellen, durch die Software Daten mit Hardware der CPU austauscht, und zu Registerwerten der CPU (beispielsweise einer 64-Bit-CPU), die gespeichert und wiederhergestellt werden müssen, zählen: ein Markierungsregister (wie zum Beispiel RFLAGS), ein Befehlszeigerregister (etwa RIP), ein Allgemeinregister (etwa RDI, RSI, RBP, RSP, RBX, RDX, RCX, RAX, R8~R15), ein Systemverwaltungs-Basisregister (SMBASE), ein Steuerregister (zum Beispiel CR0, CR3), ein Segmentregister (wie etwa GS, FS, DS, SS, CS, ES). Zu Registern, die durch Modifizieren des CPU-Zustandsspeicherbereichs wiederhergestellt werden können, zählen: ein Markierungsregister, ein Befehlszeigerregister, ein Allgemeinregister, ein Systemverwaltungs-Basisregister. Das Segmentregister kann durch einen MOV- oder POP-Befehl wiederhergestellt werden; das Steuerregister kann durch einen MOV-Befehl wiederhergestellt werden. Die globale Deskriptortabelle befindet sich im Speicherbereich und speichert globale Datenstrukturen (wie zum Beispiel Segmentdeskriptoren) darin. Das GDTR-Register verweist auf einen Speicherbereich, in dem die globale Deskriptortabelle gespeichert ist, und die Adresse der globalen Deskriptortabelle kann durch einen LGDT-/SGDT-Befehl geladen oder gespeichert werden; die Interrupt-Deskriptortabelle befindet sich im Speicherbereich und speichert Interrupt-Deskriptoren darin. Das IDTR-Register verweist auf einen Speicherbereich, in dem die globale Deskriptortabelle gespeichert ist, und die Adresse der Interrupt-Deskriptortabelle kann durch einen LIDT-/SIDT-Befehl geladen oder gespeichert werden. Hier wird ein Befehlszeigerregister dazu verwendet, auf eine Speicheradresse eines Codes zu verweisen, der zurzeit ausgeführt wird.
Das obige Verfahren kann den CPU-Systemverwaltungsmodus verlassen und dadurch zu der ursprünglichen Ausführungsumgebung, d. h. der UEFI-Preboot-Umgebung, zurückkehren, diese Umgebung ist jedoch nicht unbedingt die ursprüngliche UEFI-Preboot-Umgebung, dies liegt vor allem daran, dass nicht bekannt ist, ob ein weiterer Teil der Kontextdaten, die dazu verwendet werden, zur ursprünglichen UEFI-Preboot-Umgebung zurückzukehren, zerstört worden ist. Folglich weist der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, des Weiteren die Adresse eines Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und Inhalt dieses Speicherbereichs auf, da es sich bei der Adresse und dem Inhalt um eine Umgebung handelt, in der das UEFI ursprünglich arbeitet, diese Daten können dem System ermöglichen, direkt zu der Umgebung zurückzukehren, in der das UEFI ursprünglich arbeitet. Durch die UEFI-Spezifikation definierte UEFI-Boot-Service-Routinen müssen in der Implementierung von UEFI-Firmware bereitgestellt werden, und das GetMemorymap()-Verfahren darin kann dazu verwendet werden, eine Speicherbereichstabelle (Speicherzuordnung) abzurufen. Das Verfahren gibt ein Array zurück, das Speicherdeskriptoren enthält, die jeweils einen Typ eines entsprechenden Speicherbereichs, eine Startadresse, eine Größe und ein Attribut angibt. Die Adresse des Speicherbereichs, der erhalten werden muss, kann durch die Startadresse und die Größe in Speicherdeskriptoren ermittelt werden, wodurch der Inhalt dieses Speicherbereichs bezogen wird.
4 stellt die Typen von Speicherbereichen dar, die durch die UEFI-Firmware definiert werden, wobei in der oberen Hälfte von 4 die Typen von Speicherbereichen dargestellt werden, die in der UEFI-Preboot-Umgebung erhalten werden müssen. Wobei es sich bei den Speichertypdeskriptoren um folgende handelt:

EfiReservedMemoryType – der Typ des reservierten Speicherbereichs, dieser Speicherbereichstyp ist durch die UEFI-Firmware und das Betriebssystem geschützt;
EfiLoaderCode, EfiLoaderData – der Speicherbereichstyp zum Speichern von UEFI-Ladecode und -daten;
EfiBootServicesCode, EfiBootServicesData – der Speicherbereichstyp zum Speichern von Code und Daten des Boot-Service-Treiberprogramms;
EfiRuntimeServicesCode, EfiRuntimeServicesData – der Speicherbereichstyp zum Speichern von Code und Daten des Laufzeit-Service-Treiberprogramms;
EfiConventionalMemory – der Typ des verwendbaren herkömmlichen Speicherbereichs;
EfiUnusableMemory – der Speicherbereichstyp, der aufgrund des Vorliegens eines Fehlers nicht verwendbar ist;
EfiACPIReclaimMemory – der Speicherbereichstyp zum Speichern einer Advanced-Configuration-and-Power-Interface-Tabelle (ACPI-Tabelle);
EfiACPIMemoryNVS – der Speicherbereichstyp, der für die Verwendung durch Firmware reserviert ist;
fiMemoryMappedIO, – der Speicherbereichstyp zum Erstellen einer speicherbezogenen Eingabe/Ausgabe;
fiMemoryMappedIOPortSpace – der Speicherbereichstyp für einen speicherbezogenen Eingabe-/Ausgabe-Anschluss;
EfiPaICode – der Speichertyp zum Speichern von Code der Prozessorabstraktionsebene.

Bei einer Ausführungsform weist das in 3 dargestellte Verfahren, um dem System zu ermöglichen, direkt zu der ursprünglichen UEFI-Ausführungsumgebung zurückzukehren, des Weiteren auf: Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt. Bei dieser Wiederherstellungsweise besteht jedoch die Gefahr, dass gleichzeitig durch das Betriebssystem auf diesen Speicherbereich zugegriffen wird, sodass die Integrität des Kontextes der UEFI-Preboot-Umgebung zerstört wird. Bei einer weiteren Ausführungsform weist das Verfahren des Weiteren auf: in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt, Beenden der speicherbezogenen Eingabe/Ausgabe (memory mapped input Output, MMIO) von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden. Dies kann verhindern, dass durch einen Zugriff auf den Speicher durch eine Einheit mit direktem Speicherzugriff (direct memory access, DMA) der wiederhergestellte Bereich zerstört wird, um die Gefahr zu mindern, dass die Integrität des Kontextes der UEFI-Preboot-Umgebung zerstört wird. Der Schritt des Beendens kann durch Löschen des Basisadressregisters im Konfigurationsbereich der PCI-Einheit erreicht werden.
Bei einer weiteren Ausführungsform weist das in 3 dargestellte Verfahren, um dem System zu ermöglichen, direkt zu der ursprünglichen UEFI-Ausführungsumgebung zurückzukehren, des Weiteren auf: Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf, dass die CPU in den Systemverwaltungsmodus eintritt. Bei einer weiteren Ausführungsform weist das Verfahren des Weiteren auf: in Reaktion darauf, dass die CPU in den Systemverwaltungsmodus eintritt, Beenden der speicherbezogenen Eingabe/Ausgabe (MMIO) von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden. Dies kann verhindern, dass durch einen Zugriff auf den Speicher durch eine Einheit mit direktem Speicherzugriff (DMA) der wiederhergestellte Bereich zerstört wird. Der Schritt des Beendens kann durch Löschen des Basisadressregisters im Konfigurationsbereich der PCI-Einheit erreicht werden.
Der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, kann in einem beliebigen geeigneten Speicherbereich gespeichert werden, sofern die in diesem Speicherbereich gespeicherten Daten nicht in der UEFI-Preboot-Umgebung und dem Altbetriebssystem zerstört werden. Bei einer einfachen Ausführungsform kann ein externer Speicher (im Allgemeinen ein Speichermedium wie zum Beispiel ein USB-Speichermedium, eine optische Speicherplatte, eine Wechselfestplatte oder eine Diskette usw.) dazu verwendet werden, den Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss. Auf diese Weisen gespeicherter Inhalt kann durch ein Programm gesteuert werden und wird nicht durch die UEFI-Preboot-Umgebung und das Altbetriebssystem zerstört. Es wird jedoch eine relativ lange Zeit für die Wiederherstellung benötigt, und der Wiederherstellungsprozess ist relativ kompliziert, beispielsweise muss Code, der in der Lage ist, die Einheiten anzusteuern, während der Wiederherstellung ausgeführt werden, und es besteht die Möglichkeit, dass Kontextinhalt, der in einer externen Speichereinheit gespeichert ist, zerstört werden kann, wenn kein spezieller Schutzmechanismus (wie zum Beispiel Platzieren in einer verdeckten Partition) vorhanden ist.
Bei einer weiteren Ausführungsform kann für UEFI reservierter Speicher dazu eingesetzt werden, Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss. Die Integrität von Speicherbereichen solcher für EFI reservierter Speicher kann sowohl in der UEFI-Preboot-Umgebung als auch in der Altbetriebssystemumgebung garantiert werden. Der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, kann jederzeit nach dem Eintreten in die UEFI-Preboot-Umgebung gespeichert werden, sofern dies stattfindet, bevor das UEFI in das Kompatibilitätsunterstützungsmodul eintritt, um einen Boot-Vorgang des Altbetriebssystems aufzurufen. Bei einer bevorzugten Ausführungsform muss der UEFI-System-Service zuerst aufgerufen werden, um ausreichend reservierten Speicher zuzuordnen, sodass der Kontext in der obigen UEFI-Preboot-Umgebung, der erhalten werden muss, in dem zugeordneten reservierten Speicher gespeichert wird.
Bei einer Ausführungsform weist das Verfahren des Weiteren auf: Modifizieren des gespeicherten Befehlszeigerregisters in Reaktion darauf, dass die CPU in den Systemverwaltungsmodus eintritt, sodass das Befehlszeigerregister auf einen Befehl neben einem Aufrufbefehl verweist, der ein Booten des Altbetriebssystems durchführt, um ein erneutes Aufrufen des Altbetriebssystems und ein erneutes Zurückkehren zu der UEFI-Preboot-Umgebung zu vermeiden und so einen Teufelskreis auszulösen.
In Schritt S302, dem Wiederherstellen eines ersten Abschnitts des CPU-Ausführungskontextes in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt, werden hier einige Ausführungsformen dazu bereitgestellt, wie festzustellen ist, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
Bei einer Ausführungsform ruft, wenn das Kompatibilitätsunterstützungsmodul die Ladeeinheit des Altbetriebssystems in Reaktion auf einen Boot-Fehler startet, die Ladeeinheit des Altbetriebssystems üblicherweise einen Software-Interrupt (wie zum Beispiel INT18) auf, um die UEFI-Firmware in Kenntnis zu setzen. Aus der Perspektive der UEFI-Firmware kann in Reaktion auf das Empfangen eines Software-Interrupts von der Ladeeinheit des Altbetriebssystems festgestellt werden, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt. Wenn ein Fehlschlag festgestellt wird, kann die Art, mit der die CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus eintreten gelassen wird, eine Interrupt-Routinenfunktion nutzen, um einen ersten Abschnitt des CPU-Ausführungskontextes und/oder die Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und den Inhalt dieses Speicherbereichs wiederherzustellen.
Bei einer weiteren Ausführungsform kann in der UEFI-Firmware ein Watchdog-Zeitgeber hinzugefügt werden, um während des Boot-Zeitraums einen Zustand des Altbetriebssystems zu erkennen, in dem das System hängenbleibt. Der Watchdog-Zeitgeber wird auf eine vorgegebene Zeit voreingestellt, der Watchdog-Zeitgeber löst einen Hardware-Interrupt aus, wenn die UEFI-Preboot-Umgebung nicht innerhalb des durch den Watchdog-Zeitgeber voreingestellten vorgegebenen Zeitraums eine Benachrichtigung empfangen hat, dass das Booten des Altbetriebssystems erfolgreich ist, und es wird entsprechend dem Auslösen des Hardware-Interrupts festgestellt, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt. Wenn die UEFI-Preboot-Umgebung das Altbetriebssystem hingegen erfolgreich geladen hat, empfängt die UEFI-Preboot-Umgebung innerhalb des durch den Watchdog-Zeitgeber voreingestellten vorgegebenen Zeitraums eine Benachrichtigung, dass das Altbetriebssystem erfolgreich gebootet worden ist, und an dieser Stelle kann die UEFI-Firmware den Watchdog-Zeitgeber anhalten oder ihn auf einen unendlichen Zeitraum voreinstellen. Bei der spezifischen Ausführungsform kann eine Interrupt-Routinenfunktion dazu verwendet werden, einen ersten Abschnitt des CPU-Ausführungskontextes und/oder die Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und den Inhalt dieses Speicherbereichs wiederherzustellen.
Bei einer noch weiteren Ausführungsform kann ein Maschinenprüfungsausnahme-Mechanismus (Machine-Check Exception mechanism) verwendet werden. Die Maschinenprüfungsausnahme ist ein Mechanismus, der durch die CPU zum Erkennen und Melden eines Hardware-Fehlers bereitgestellt wird. Es handelt sich um eine Ausnahme mit der höchsten Priorität im PC-System, und sie kann nicht durch einen anderen Interrupt/eine andere Ausnahme unterbrochen werden. Bei einer Maschinenprüfungsausnahme kann zum Beispiel bei einer CPU mit einer X86-Architektur der Status eines aufgetretenen Fehlers über ein IA32_MCi_STATUS-Register gemeldet werden, wobei zwei Bits darin dazu verwendet werden können zu überprüfen, ob aktueller CPU-Ausführungskontext zerstört worden ist. Gültig (Bit 63) = 1 und PCC (Bit 57) = 0, dies stellt dar, dass der Kontext nicht zerstört worden ist. Wenn der CPU-Ausführungskontext nicht zerstört worden ist, können der erste Abschnitt des CPU-Ausführungskontextes und/oder die Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und der Inhalt dieses Speicherbereichs in der Routinenfunktion der Maschinenprüfungsausnahme wiederhergestellt werden. Bei einer weiteren Ausführungsform muss zunächst in der Ausnahmebehandlungsroutine-Funktion beurteilt werden, ob der CPU-Ausführungskontext zerstört worden ist. Wenn der CPU-Ausführungskontext nicht zerstört worden ist, können der erste Abschnitt des CPU-Ausführungskontextes und/oder die Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und der Inhalt dieses Speicherbereichs wiederhergestellt werden, nachdem der Fehler korrigiert worden ist; und wenn der CPU-Ausführungskontext zerstört worden ist, bleibt nur, das System neu zu booten.
Das Wiederherstellen des ersten Abschnitts des CPU-Ausführungskontextes weist ein Wiederherstellen der globalen Deskriptortabelle (GDT), der Interrupt-Deskriptortabelle (IDT), des Steuerregisters und des Segmentregisters auf, und es kann der folgende Pseudocode verwendet werden:
Um die Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und den Inhalt dieses Speicherbereichs wiederherzustellen, kann der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, dazu verwendet werden, den Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, zu der Adresse des Speicherbereichs zu kopieren, in dem sich UEFI-Code und -Daten befinden. Wenn reservierter Speicher eingesetzt wird, um den Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss, handelt es sich um eine Speicher-zu-Speicher-Kopierweise.
In Schritt S303 Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus und Wiederherstellen eines zweiten Abschnitts des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus. Das Wiederherstellen des zweiten Abschnitts des CPU-Ausführungskontextes weist ein Wiederherstellen des Markierungsregisters, des Befehlszeigerregisters, des Allgemeinregisters, des Systemverwaltungs-Basisregisters auf, und es kann Pseudocode ähnlich demjenigen verwendet werden, der zum Wiederherstellen des ersten Abschnitts des CPU-Ausführungskontextes verwendet worden ist. Zum Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus kann eine Hardware-Auslösermethode verwendet werden oder kann eine Methode zum Auslösen eines Software-Systemverwaltungs-Interrupts (Software-SMI) verwendet werden. Bevor die CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus eintreten gelassen wird, muss die CPU zunächst in den geschützten Modus geschaltet werden, und dann wird der Software-Systemverwaltungs-Interrupt (Software-SMI) ausgelöst, sodass die CPU in den Systemverwaltungsmodus eintreten kann.
In Schritt S304 Verlassen des CPU-Systemverwaltungsmodus, dadurch Zurückkehren zu der UEFI-Preboot-Umgebung, wobei das Verlassen des CPU-Systemverwaltungsmodus durch Ausführen eines RSM-Befehls durch die CPU erreicht werden kann, wodurch zu der ursprünglich gespeicherten UEFI-Preboot-Umgebung zurückgekehrt wird, sodass es möglich ist, eine nächste UEFI-Boot-Option auszuprobieren oder eine UEFI-Systemdiagnose durchzuführen. Da die Steuereinheiten in dem System während des Versuchs, das Altsystem zu booten, sämtlich durch das UEFI abgetrennt sind, wird des Weiteren, nachdem die UEFI-Preboot-Umgebung wiederhergestellt worden ist, in Reaktion auf das Zurückkehren zu der UEFI-Preboot-Umgebung veranlasst, dass die Treiber der Steuereinheiten, die durch das UEFI gesteuert werden, erneut ausgeführt werden, sodass die Steuerung der Steuereinheiten durch das UEFI wiederhergestellt werden kann.
Mit demselben Erfindungsgedanken offenbart die vorliegende Erfindung außerdem ein System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung, und 5 stellt ein strukturelles Blockschaubild des Systems zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer UEFI-Preboot-Umgebung dar. Gemäß 5 weist das System auf: eine Speichereinheit 501, die dazu eingerichtet ist, Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung zu speichern, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; eine erstes Wiederherstellungsmittel 502, das dazu eingerichtet ist, einen ersten Abschnitt des CPU-Ausführungskontextes in Reaktion darauf wiederherzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eine zweites Wiederherstellungsmittel 503, das dazu eingerichtet ist, die CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus eintreten zu lassen und einen zweiten Abschnitt des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus wiederherzustellen; und ein Beendigungsmittel 504, das dazu eingerichtet ist, den CPU-Systemverwaltungsmodus zu verlassen und dadurch zu der UEFI-Preboot-Umgebung zurückzukehren.
Bei einer Ausführungsform weist der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, des Weiteren eine Adresse eines Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und Inhalt dieses Speicherbereichs auf. Das Speichermittel verwendet bevorzugt für das UEFI reservierten Speicher, um den Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss.
Bei einer Ausführungsform stellt das erste Wiederherstellungsmittel, mithilfe eines von diesen fest, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt: eines ersten Feststellungsmittels, das dazu eingerichtet ist, in Reaktion auf das Empfangen eines Software-Interrupts von der Ladeeinheit des Altbetriebssystems festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eines zweiten Feststellungsmittels, das dazu eingerichtet ist, einen Watchdog-Zeitgeber in der UEFI-Firmware hinzuzufügen, wobei der Watchdog-Zeitgeber einen Hardware-Interrupt auslöst, wenn die UEFI-Preboot-Umgebung nicht innerhalb eines durch den Watchdog-Zeitgeber voreingestellten, vorgegebenen Zeitraums eine Benachrichtigung empfangen hat, dass das Booten des Altbetriebssystems erfolgreich ist, und entsprechend dem Auslösen des Hardware-Interrupts festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eines dritten Feststellungsmittels, das dazu eingerichtet ist, mithilfe eines Maschinenprüfungsausnahme-Mechanismus festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
Bei einer Ausführungsform ist das erste Wiederherstellungsmittel des Weiteren dazu eingerichtet, den Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf wiederherzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt. Das erste Wiederherstellungsmittel ist bevorzugt des Weiteren dazu eingerichtet, die speicherbezogene Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, zu beenden.
Bei einer weiteren Ausführungsform ist das zweite Wiederherstellungsmittel des Weiteren dazu eingerichtet, Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf wiederherzustellen, dass die CPU in den Systemverwaltungsmodus eintritt. Das zweite Wiederherstellungsmittel ist des Weiteren bevorzugt dazu eingerichtet, die speicherbezogene Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, zu beenden. Das zweite Wiederherstellungsmittel ist des Weiteren bevorzugt dazu eingerichtet, das gespeicherte Befehlszeigerregister in Reaktion darauf zu modifizieren, dass die CPU in den Systemverwaltungsmodus eintritt, sodass das Befehlszeigerregister auf einen Befehl neben einem Aufrufbefehl verweist, der ein Booten des Altbetriebssystems durchführt.
Bei einer Ausführungsform ist das Beendigungsmittel des Weiteren dazu eingerichtet, in Reaktion auf das Zurückkehren zu der UEFI-Preboot-Umgebung zu veranlassen, dass Treiber der Steuereinheiten, die durch das UEFI gesteuert werden, erneut ausgeführt werden.
Die Ablaufpläne und Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Arbeitsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der einen oder mehrere ausführbare Befehle zum Implementieren der angegebenen logischen Funktion(en) aufweist. Es ist außerdem zu beachten, dass bei einigen alternativen Implementierungen die in dem Block vermerkten Funktionen in einer anderen Reihenfolge als in den Figuren vermerkt auftreten können. Beispielsweise können je nach einbezogener Funktionalität zwei nacheinander dargestellte Blöcke sogar im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können bisweilen in der umgekehrten Reihenfolge ausgeführt werden. Es ist ferner zu beachten, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne und Kombinationen von Blöcken in den Blockschaubildern und/oder in den Ablaufplänen durch Spezialsysteme auf der Grundlage von Hardware, die die angegebenen Funktionen oder Vorgänge ausführen, oder durch Kombinationen von Spezial-Hardware und Computerbefehlen implementiert werden können.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung erfolgten zur Veranschaulichung, sind jedoch nicht erschöpfend oder auf die beschriebenen Ausführungsformen beschränkt gemeint. Viele Modifizierungen und Varianten sind für Fachleute ersichtlich, ohne vom Umfang und Gedanken der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder die technische Verbesserung gegenüber auf dem Markt erhältlichen Technologien am besten zu erläutern oder um anderen Fachleuten zu ermöglichen, die hierin beschriebenen Ausführungsformen zu verstehen.

Claims

Verfahren zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer Unified-Extensible-Firmware-Interface(UEFI)-Preboot-Umgebung, das aufweist: Speichern von Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; Wiederherstellen eines ersten Abschnitts des CPU-Ausführungskontextes in Reaktion darauf, dass ein Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; Eintretenlassen der CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in einen Systemverwaltungsmodus und Wiederherstellen eines zweiten Abschnitts des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus; und Verlassen des CPU-Systemverwaltungsmodus und dadurch Zurückkehren zu der UEFI-Preboot-Umgebung.
Verfahren nach Anspruch 1, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, des Weiteren eine Adresse eines Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und Inhalt dieses Speicherbereichs aufweist.
Verfahren nach Anspruch 2, wobei in dem Schritt zum Speichern von Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, für UEFI reservierter Speicher dazu eingesetzt wird, den Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss.
Verfahren nach einem der Ansprüche 2 bis 3, wobei mithilfe eines der folgenden Ansätze festgestellt wird, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt: I) Feststellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt, in Reaktion auf ein Empfangen eines Software-Interrupts von einer Ladeeinheit des Altbetriebssystems; II) Hinzufügen eines Watchdog-Zeitgebers in UEFI-Firmware, wobei der Watchdog-Zeitgeber einen Hardware-Interrupt auslöst, wenn die UEFI-Preboot-Umgebung nicht innerhalb eines durch den Watchdog-Zeitgeber voreingestellten vorgegebenen Zeitraums eine Benachrichtigung empfangen hat, dass das Booten des Altbetriebssystems erfolgreich ist, und entsprechend dem Auslösen des Hardware-Interrupts Feststellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; III) Feststellen mithilfe eines Maschinenprüfungsausnahme-Mechanismus, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
Verfahren nach Anspruch 4, wobei das Verfahren des Weiteren aufweist: Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
Verfahren nach Anspruch 5, wobei das Verfahren des Weiteren aufweist: Beenden einer speicherbezogenen Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden.
Verfahren nach Anspruch 4, wobei das Verfahren des Weiteren aufweist: Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf, dass die CPU in den Systemverwaltungsmodus eintritt.
Verfahren nach Anspruch 7, wobei das Verfahren des Weiteren aufweist: Beenden der speicherbezogenen Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden.
Verfahren nach Anspruch 5 oder 7, wobei das Verfahren des Weiteren aufweist: Modifizieren eines gespeicherten Befehlszeigerregisters in Reaktion darauf, dass die CPU in den Systemverwaltungsmodus eintritt, sodass das Befehlszeigerregister auf einen Befehl neben einem Aufrufbefehl verweist, der ein Booten des Altbetriebssystems durchführt.
Verfahren nach Anspruch 5 oder 7, wobei das Verfahren des Weiteren aufweist: in Reaktion auf das Zurückkehren zu der UEFI-Preboot-Umgebung Veranlassen, dass Treiber von Steuereinheiten, die durch das UEFI gesteuert werden, erneut ausgeführt werden.
System zum Wiederherstellen aus einer Altbetriebssystemumgebung zu einer Unified-Extensible-Firmware-Interface(UEFI)-Preboot-Umgebung, das aufweist: ein Speichermittel, das dazu eingerichtet ist, Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, unter der UEFI-Preboot-Umgebung zu speichern, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, einen CPU-Ausführungskontext aufweist; ein erstes Wiederherstellungsmittel, das dazu eingerichtet ist, einen ersten Abschnitt des CPU-Ausführungskontextes in Reaktion darauf wiederherzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; ein zweites Wiederherstellungsmittel, das dazu eingerichtet ist, die CPU, die der UEFI-Preboot-Umgebung zugehörig ist, in den Systemverwaltungsmodus eintreten zu lassen und einen zweiten Abschnitt des CPU-Ausführungskontextes unter dem Systemverwaltungsmodus wiederherzustellen; und ein Beendigungsmittel, das dazu eingerichtet ist, den CPU-Systemverwaltungsmodus zu verlassen und dadurch zu der UEFI-Preboot-Umgebung zurückzukehren.
System nach Anspruch 11, wobei der Kontext in der UEFI-Preboot-Umgebung, der erhalten werden muss, des Weiteren eine Adresse eines Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, und Inhalt dieses Speicherbereichs aufweist.
System nach Anspruch 12, wobei in dem Speichermittel für UEFI reservierter Speicher dazu eingesetzt wird, den Kontext in der UEFI-Preboot-Umgebung zu speichern, der erhalten werden muss.
System nach einem der Ansprüche 12 bis 13, wobei das erste Wiederherstellungsmittel mithilfe eines der folgenden feststellt, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt: eines ersten Feststellungsmittels, das dazu eingerichtet ist, in Reaktion auf ein Empfangen eines Software-Interrupts von der Ladeeinheit des Altbetriebssystems festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eines zweiten Feststellungsmittels, das dazu eingerichtet ist, einen Watchdog-Zeitgeber in UEFI-Firmware hinzuzufügen, wobei der Watchdog-Zeitgeber einen Hardware-Interrupt auslöst, wenn die UEFI-Preboot-Umgebung nicht innerhalb eines durch den Watchdog-Zeitgeber voreingestellten vorgegebenen Zeitraums eine Benachrichtigung empfangen hat, dass das Booten des Altbetriebssystems erfolgreich ist, und entsprechend dem Auslösen des Hardware-Interrupts festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt; eines dritten Feststellungsmittels, das dazu eingerichtet ist, mithilfe eines Maschinenprüfungsausnahme-Mechanismus festzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
System nach Anspruch 14, wobei das erste Wiederherstellungsmittel des Weiteren dazu eingerichtet ist, den Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf wiederherzustellen, dass das Laden des Altbetriebssystems durch die UEFI-Preboot-Umgebung fehlschlägt.
System nach Anspruch 15, wobei das erste Wiederherstellungsmittel des Weiteren dazu eingerichtet ist, die speicherbezogene Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, zu beenden.
System nach Anspruch 14, wobei das zweite Wiederherstellungsmittel des Weiteren dazu eingerichtet ist, Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, in Reaktion darauf wiederherzustellen, dass die CPU in den Systemverwaltungsmodus eintritt.
System nach Anspruch 17, wobei das zweite Wiederherstellungsmittel des Weiteren dazu eingerichtet ist, die speicherbezogene Eingabe/Ausgabe von PCI-Einheiten nach dem Wiederherstellen von Inhalt des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, innerhalb des Kontextes in der UEFI-Preboot-Umgebung, der erhalten werden muss, zu der Adresse des Speicherbereichs, in dem sich UEFI-Code und -Daten befinden, zu beenden.
System nach Anspruch 15 oder 17, wobei das zweite Wiederherstellungsmittel des Weiteren dazu eingerichtet ist, ein gespeichertes Befehlszeigerregister in Reaktion darauf zu modifizieren, dass die CPU in den Systemverwaltungsmodus eintritt, sodass das Befehlszeigerregister auf einen Befehl neben einem Aufrufbefehl verweist, der ein Booten des Altbetriebssystems durchführt.
System nach Anspruch 15 oder 17, wobei das Beendigungsmittel des Weiteren dazu eingerichtet ist, in Reaktion auf das Zurückkehren zu der UEFI-Preboot-Umgebung zu veranlassen, dass Treiber von Steuereinheiten, die durch das UEFI gesteuert werden, erneut ausgeführt werden.
Computerprogramm, das Programmcode aufweist, der dazu gestaltet ist, die Verfahrensschritte eines der Ansprüche 1 bis 10 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.