Restoring from a legacy operating system environment to a UEFI preboot environment

Abstract

A method for recovering from a legacy operating system environment to a Unified Extensible Firmware Interface (UEFI) preboot environment, comprising: Storing context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; Restoring an initial portion of the CPU execution context in response to a failure to load the legacy operating system through the UEFI preboot environment; Allowing the CPU associated with the UEFI preboot environment to enter a system management mode and restoring a second section of the CPU execution context under the system management mode; and Exit CPU system management mode and return to the UEFI preboot environment.

Description

background

[0001] The present invention relates to firmware in a computer system and, more particularly, to a method and system for restoring from a legacy operating system environment to a UEFI preboot environment.

[0002] A legacy BIOS (Basic Input / Output System) is a type of firmware that acts as a basic input / output system. It is responsible for tasks such as hardware booting and detection at power-on, and acts as an intermediary while the operating system controls the hardware. Since Windows NT and Linux, these operating systems have moved hardware control programs, which previously had to be performed by the BIOS, into the operating system. The programs are executed within the operating system, and there is no longer any need to call BIOS functionality. Due to the rapid evolution of hardware, legacy BIOS have become a burden during development.

[0003] Today, a new Extensible Firmware Interface (EFI) has been developed. The Unified Extensible Firmware Interface (UEFI) was developed based on EFI 1.10, and UEFI is a standard that describes a completely new type of interface. This type of interface is used by operating systems to automatically load from a preboot operating environment into an operating system, simplifying the boot process and saving time.

[0004] UEFI uses a C-style parameter stack passing approach and a dynamic linking approach to create a system. It is easier to implement than BIOS, has better fault tolerance and error recovery, and can reduce the time required for system research and development. Furthermore, UEFI operates in 32-bit or 64-bit mode, and its improved addressing capability can provide better performance compared to BIOS. Furthermore, the UEFI architecture driver is written in EFI bytecode, which is a set of virtual machine instructions for a UEFI driver. The instructions are interpreted to run in a UEFI-controlled operating environment, ensuring sufficient backward compatibility of UEFI. UEFI also integrates a graphics driver function that can provide a high-resolution color graphics environment.After entering the environment, users can adjust configurations by clicking a mouse, which is as simple as using application software in a Windows system. Furthermore, UEFI adopts a modular design and is logically divided into two parts: hardware control and operating system software management. Hardware control is common to all UEFI versions, and operating system software management is strictly speaking a programmable open interface through which motherboard manufacturers can implement various comprehensive functions. For example, various backup and diagnostic functions that are well known among professionals can be implemented through UEFI. Therefore, numerous computer manufacturers have currently begun to use UEFI firmware, and sales of machines supported by UEFI firmware are expected to become dominant.

[0005] From the perspective of UEFI firmware, operating systems can be divided into two types: the first type of operating system can support and utilize UEFI firmware, such as Windows Server 2008 R2; the second type of operating system cannot support UEFI firmware, i.e., legacy operating systems. UEFI can provide a compatibility support module that enables UEFI firmware to load and boot a legacy operating system, such as Windows XP in the 32-bit version, Windows Server 2003 for x86, etc.

[0006] The execution environment of UEFI firmware is a UEFI preboot environment. This environment executes UEFI firmware code and provides system boot levels for the operating system. When the UEFI firmware system loader loads an operating system that supports and uses UEFI, the system loader can directly return to the UEFI preboot environment if the operating system fails to load successfully due to a problem. However, when the UEFI firmware system loader loads and boots a legacy operating system, a compatibility support module is required in the system loader, or a compatibility support module is used directly without the system loader to enable the legacy operating system to load and boot.However, according to the current state of the art, once the UEFI enters the compatibility support module to attempt to boot the legacy operating system, there is no way to return to the UEFI preboot environment, even if the legacy operating system boot attempt fails. Therefore, developers cannot diagnose the problem.

[0007] Documents have already been published in this context. Document US 6,961,848 B2 describes a system and method for supporting the booting of older operating systems in non-legacy environments. Legacy-free firmware allows a legacy-free boot of a computer system from the moment the system is turned on until the operating system is loaded. If a legacy boot option is available, it can be used without initiating a reboot process, since the already loaded legacy-free drivers can be stopped. This enables coexistence of legacy-free boot processes and optional legacy ROMs for booting a system.

[0008] Furthermore, document US 7 146 512 B2 describes a method for activating a management mode over a network for monitoring a hardware unit and transmitting the monitored information over the network. Document US 2007 / 0 061 634 A1 describes hardware error handling based on an operating system and firmware using a transparent firmware-driven interrupt and firmware services. This can prevent handling of a hardware error by the operating system. Finally, document EP 2 393 008 A2 describes a process monitor for monitoring the status of processes executed with corresponding monitored driver programs.

[0009] Despite these advances, there is still a need to better address the problem of legacy BIOS environments. Brief description

[0010] This problem is solved by the subject matter of the independent patent claims. Further embodiments are described by the respective dependent patent claims.

[0011] According to one aspect of the present invention, a method for restoring from a legacy operating system environment to a Unified Extensible Firmware Interface (UEFI) preboot environment is provided, comprising: storing context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; restoring a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system; allowing the CPU associated with the UEFI preboot environment to enter system management mode and restoring a second portion of the CPU execution context under the system management mode; and exiting the CPU system management mode and thereby returning to the UEFI preboot environment.

[0012] According to another aspect of the present invention, a system for restoring from a legacy operating system environment to a Unified Extensible Firmware Interface (UEFI) preboot environment is provided, comprising: a storage unit configured to store context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; a first restoration unit configured to restore a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system;a second recovery unit configured to allow the CPU associated with the UEFI preboot environment to enter the system management mode and restore a second portion of the CPU execution context under the system management mode; and an exit means configured to exit the CPU system management mode and thereby return to the UEFI preboot environment. Brief description of the different views of the drawings

[0013] The above and other objects, features and advantages of the present disclosure will become more apparent by describing some embodiments of the present disclosure in more detail in the accompanying drawings, wherein the same reference numerals generally refer to the same components throughout the embodiments of the present disclosure. Fig.1 illustrates an exemplary computer system 100 applicable to implementing embodiments of the present invention; Fig. 2 illustrates a block diagram of a UEFI preboot environment according to the present invention; Fig. 3 illustrates steps of a method for restoring from a legacy operating system environment to a UEFI preboot environment according to an embodiment of the present invention; Fig. 4 represents types of memory areas defined by UEFI firmware; and Fig. Figure 5 illustrates a structural block diagram of a system for recovering from a legacy operating system environment to a UEFI preboot environment. Detailed description

[0014] Some preferred embodiments will be described in more detail with reference to the accompanying drawings, in which the preferred embodiments of the present disclosure have been illustrated. However, the present disclosure may be implemented in various forms and should not be construed as limited to the embodiments disclosed herein. Rather, these embodiments are provided to fully and completely understand the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0015] Fig. 1 illustrates an exemplary computer system 100 applicable to implementing embodiments of the present invention. As shown in Fig.1, the computer system 100 may include: a CPU (Central Process Unit) 101, a RAM (Random Access Memory) 102, a ROM (Read Only Memory) 103, a system bus 104, a hard disk controller 105, a keyboard controller 106, a serial port controller 107, a parallel port controller 108, a display controller 109, a hard disk 110, a keyboard 111, a serial peripheral unit 112, a parallel peripheral unit 113, and a display 114. Of these units, the system bus 104 is connected to the CPU 101, the RAM 102, the ROM 103, the hard disk controller 105, the keyboard controller 106, the serial port controller 107, the controller 108 for parallel interfaces and the display control unit 109. The hard disk 110 is connected to the hard disk control unit 105.The keyboard 111 is connected to the keyboard control unit 106. The serial peripheral unit 112 is connected to the serial interface control unit 107. The parallel peripheral unit 113 is connected to the parallel interface control unit 108. And the display 114 is connected to the display control unit 109. It should be understood that the structure as shown in FIG. Fig. 1 is intended to be merely exemplary rather than limiting the present invention. In some cases, some units may be added to or removed from computer system 100 based on particular situations.

[0016] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method, or computer program product. Accordingly, aspects of the present invention may take a purely hardware embodiment, a purely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be generically referred to herein as a "circuit," "module," or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0017] Any combination of one or more computer-readable media may be used. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or unit, or any suitable combination of the above.More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. For the purposes of this document, a computer-readable storage medium can be any physical medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0018] A computer-readable signal medium may include a propagating data signal embodying computer-readable program code, for example, in baseband or as part of a carrier wave. Such a propagating signal may take a variety of forms, including, but not limited to, electromagnetic form, optical form, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium, other than a computer-readable storage medium, that can exchange, disseminate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0019] Program code embodied on a computer-readable medium may be transmitted using any suitable medium, such as, but not limited to, radio, cable, fiber optic cable, radio frequency (RF), etc., or any suitable combination of the above.

[0020] Computer program code for performing operations for aspects of the present invention may be written in any combination of one or more programming languages, for example, an object-oriented programming language such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remote computer may be connected to the user's computer through any type of network, for example, a local region network (LAN) or a wide region network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider).

[0021] Aspects of the present invention are described below with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executing via the processor of the computer or other programmable data processing apparatus, produce a means for implementing the functions / acts specified in the block or blocks of the flowchart and / or block diagrams.

[0022] These computer program instructions may also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture that includes instruction means that implement the function / act specified in the block or blocks of the flowchart and / or block diagrams.

[0023] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of steps of a process to be performed on the computer, other programmable device, or other devices to produce a computer-implemented process, such that the instructions executing on the computer or other programmable device provide processes to implement the functions / acts specified in the block or blocks of the flowchart and / or block diagrams.

[0024] With reference to Fig.Figure 2 shows a block diagram of a UEFI preboot environment according to the present invention, that is, a block diagram of UEFI firmware. In the description, UEFI preboot environment and UEFI firmware are synonymous and will not be differentiated. The UEFI preboot environment primarily includes a UEFI execution environment module, and this module further includes a security module, an initialization module, a driver execution environment module, a boot driver selection module, and a system load module or a compatibility support module. When the UEFI system load module loads an operating system that supports and utilizes UEFI, since such an operating system supports some standard interfaces defined by the UEFI specification, the system load module can directly return to the UEFI preboot environment if the operating system cannot be loaded successfully due to a problem.However, when the UEFI's compatibility support module loads and boots a legacy operating system, once the UEFI enters the compatibility support module to attempt to boot the legacy operating system, there is no way to return to the UEFI preboot environment, even if the legacy operating system's boot attempt fails. Therefore, developers cannot diagnose the problem.

[0025] Both UEFI firmware and an operating system are software that runs on CPU hardware. UEFI firmware is a code segment that runs before the operating system boots. It is responsible for hardware initialization before the operating system boots and for preparing service interfaces available to the operating system. A CPU system has various modes, including real mode, protected mode, virtual 8068 mode, and system management mode. The CPU system can be switched between different modes.The CPU generally operates in real mode after powering on. The CPU uses registers to inform the CPU of the memory location of instructions. It uses registers such as DS, ES, FS, GS, SS, and others to mark the memory location of data segments with different purposes, indicating the main content needed when executing a next program. Protected mode is consistent with real mode, and the essence of running a program in protected mode is still "the CPU executes one or more instructions to process related data." In this way, various code segments, data segments, stack segments, and interrupt service programs still exist in real mode, and their functions and effects remain unchanged.UEFI firmware runs in real mode after the CPU is powered on. UEFI also includes code that runs in the CPU's protected mode and code that runs in the CPU's system management mode. When the UEFI enters the compatibility support module to attempt to boot a legacy operating system, UEFI code runs in the CPU's protected mode. If the boot attempt fails and it is necessary to return to the UEFI preboot environment, it is first necessary to return to the CPU's protected mode. System management mode is a special processor mode that can provide some system-level functions, such as power management, system hardware control, and so on.The main advantage of system management mode is that it can provide a processor environment that is completely different and independent from the ordinary CPU operating environment. Such an environment is difficult for an operating system or application software to detect. When the CPU enters system management mode, the CPU stores a portion of the CPU execution context data, such as CPU register values, in a block of system management mode memory (SMM RAM), a so-called CPU state backup area. Upon exiting system management mode, the processor uses a portion of the CPU execution context in the processor state backup area to restore the processor state before entering system management mode.The UEFI firmware can use such a technical feature as processor state recovery before entering system management mode when exiting system management mode to return to the pre-execution UEFI environment.

[0026] For an operating system that supports UEFI, since the system loader is invoked directly by UEFI, if the system loader fails, it returns directly to the pre-execution UEFI environment. The operating system does not destroy the context of the UEFI preboot environment until it has successfully loaded. However, after the operating system has successfully booted, there is no way to directly return to the UEFI preboot environment.

[0027] The compatibility support module can boot a legacy operating system. This is because the compatibility support module provides implementations in the UEFI firmware of some interfaces required by legacy operating systems or legacy option ROMs that originally existed in the traditional BIOS. Option ROMs are a type of firmware that controls various boards and cards and can be placed on boards and cards or included in the UEFI firmware or BIOS firmware. However, after the UEFI firmware enters the compatibility support module to perform a legacy operating system boot, the UEFI preboot environment context is destroyed. This way, even if the attempt to boot the legacy operating system fails, there is no way to return to the UEFI preboot environment because the UEFI preboot environment context has been destroyed.

[0028] Therefore, to return to the UEFI preboot environment, one important thing to ensure the integrity of the UEFI preboot environment is to save the necessary data in the context of the UEFI preboot environment. Another aspect of using the above feature is that the CPU saves the processor state before entering system management mode when exiting system management mode.

[0029] Accordingly, the present invention provides a method and system for recovering from a legacy operating system environment to a UEFI preboot environment. Within an environment supporting multiple operating systems, such a method and system can be used to assist in diagnosing a legacy operating system boot failure and a subsequent UEFI operating system boot attempt.

[0030] Fig.3 illustrates steps of a method for restoring from a legacy operating system environment to a UEFI preboot environment according to an embodiment of the present invention. According to Fig. 3 the procedure has: In step S301, storing the context in the UEFI preboot environment that needs to be obtained under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be obtained includes CPU execution context; In step S302, restoring a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system; In step S303, allowing the CPU associated with the UEFI preboot environment to enter the system management mode and restoring a second portion of the CPU execution context under the system management mode; and In step S304, exit the CPU system management mode and thereby return to the UEFI preboot environment.

[0031] The context in the UEFI preboot environment that must be preserved includes the CPU execution context. Specifically, the CPU execution context can be divided into two sections: the first section includes a global descriptor table (GDT), an interrupt descriptor table (IDT), a control register, and a segment register; the second section includes a marker register, an instruction pointer register, a general register, and a system management base register.Because the CPU can only enter system management mode after the first section of the CPU execution context has been restored; whereas the second section of the CPU execution context must be restored under system management mode, so when the CPU exits system management mode, the CPU can use this CPU execution context to restore the processor state before entering system management mode, thereby restoring to the UEFI preboot environment.

[0032] CPU registers are software and hardware interfaces through which software exchanges data with CPU hardware. CPU register values (for example, a 64-bit CPU) that need to be saved and restored include: a marker register (such as RFLAGS), an instruction pointer register (such as RIP), a general purpose register (such as RDI, RSI, RBP, RSP, RBX, RDX, RCX, RAX, R8-R15), a system management base register (SMBASE), a control register (such as CR0, CR3), and a segment register (such as GS, FS, DS, SS, CS, ES). Registers that can be restored by modifying the CPU state storage area include: a marker register, an instruction pointer register, a general purpose register, and a system management base register. The segment register can be restored using a MOV or POP instruction; the control register can be restored by a MOV instruction.The global descriptor table is located in the memory space and stores global data structures (such as segment descriptors). The GDTR register points to a memory area where the global descriptor table is stored, and the address of the global descriptor table can be loaded or stored by an LGDT / SGDT instruction; the interrupt descriptor table is located in the memory space and stores interrupt descriptors. The IDTR register points to a memory area where the global descriptor table is stored, and the address of the interrupt descriptor table can be loaded or stored by an LIDT / SIDT instruction. Here, an instruction pointer register is used to point to a memory address of a code that is currently executing.

[0033] The above method can exit the CPU system management mode and thereby return to the original execution environment, that is, the UEFI preboot environment. However, this environment is not necessarily the original UEFI preboot environment. This is mainly because it is unknown whether another part of the context data used to return to the original UEFI preboot environment has been destroyed. Therefore, the context in the UEFI preboot environment that needs to be preserved further includes the address of a memory area where UEFI code and data are located and the contents of this memory area. Because the address and contents are the environment in which UEFI originally operates, this data can allow the system to directly return to the environment in which UEFI originally operates.UEFI boot service routines defined by the UEFI specification must be provided in the UEFI firmware implementation, and the GetMemorymap() method within it can be used to retrieve a memory map. This method returns an array containing memory descriptors, each of which specifies the type of the corresponding memory map, a starting address, a size, and an attribute. The address of the memory map to be retrieved can be determined by the starting address and size in memory descriptors, thereby retrieving the contents of that memory map.

[0034] Fig. 4 shows the types of memory areas defined by the UEFI firmware, with the upper half of Fig.4 shows the types of memory areas that must be preserved in the UEFI preboot environment. The memory type descriptors are as follows: EfiReservedMemoryType - the type of reserved memory area, this type of memory area is protected by the UEFI firmware and the operating system; EfiLoaderCode, EfiLoaderData - the memory area type for storing UEFI loading code and data; EfiBootServicesCode, EfiBootServicesData - the memory area type for storing code and data of the boot service driver program; EfiRuntimeServicesCode, EfiRuntimeServicesData - the memory area type for storing code and data of the runtime service driver program; EfiConventionalMemory - the type of usable conventional memory area; EfiUnusableMemory - the type of memory area that is unusable due to the presence of an error; EfiACPIReclaimMemory - the memory area type for storing an Advanced Configuration and Power Interface (ACPI) table; EfiACPIMemoryNVS - the memory area type reserved for use by firmware; fiMemoryMappedlO, - the memory map type for creating a memory-related input / output; fiMemoryMappedlOPortSpace - the memory space type for a memory-related input / output port; EfiPalCode - the memory type for storing processor abstraction layer code.

[0035] In one embodiment, the Fig.3, to enable the system to return directly to the original UEFI execution environment, further comprises: restoring the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that must be preserved to the address of the memory area containing UEFI code and data in response to the failure of the UEFI preboot environment to load the legacy operating system. However, this recovery method risks concurrent access to this memory area by the operating system, thus destroying the integrity of the UEFI preboot environment context.In another embodiment, the method further comprises: in response to the UEFI preboot environment failing to load the legacy operating system, terminating memory mapped input / output (MMIO) of PCI devices after restoring contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that needs to be preserved to the address of the memory area containing UEFI code and data. This may prevent access to the memory by a direct memory access (DMA) device from destroying the restored area to mitigate the risk of destroying the integrity of the UEFI preboot environment context. The terminating step may be achieved by clearing the base address register in the configuration area of the PCI device.

[0036] In a further embodiment, the Fig.3 to enable the system to return directly to the original UEFI execution environment, further comprising: restoring, in response to the CPU entering system management mode, the contents of the memory area where UEFI code and data are located, within the context in the UEFI preboot environment that needs to be preserved, to the address of the memory area where UEFI code and data are located. In another embodiment, the method further comprises: in response to the CPU entering system management mode, terminating memory-related input / output (MMIO) of PCI devices after restoring, within the context in the UEFI preboot environment that needs to be preserved, the contents of the memory area where UEFI code and data are located.This can prevent the restored area from being destroyed by a direct memory access (DMA) device accessing the memory. The exit step can be achieved by clearing the base address register in the PCI device's configuration area.

[0037] The context in the UEFI preboot environment that needs to be preserved can be stored in any suitable memory area, provided that the data stored in that memory area is not destroyed by the UEFI preboot environment and the legacy operating system. In a simple embodiment, an external storage device (generally a storage medium such as a USB storage device, an optical disk, a removable hard disk, or a floppy disk, etc.) can be used to store the context in the UEFI preboot environment that needs to be preserved. Content stored in this way can be controlled by a program and will not be destroyed by the UEFI preboot environment and the legacy operating system.However, it takes a relatively long time to recover, and the recovery process is relatively complicated. For example, code capable of controlling the units must be executed during recovery, and there is a possibility that context content stored in an external storage unit may be destroyed if there is no special protection mechanism (such as placing it in a hidden partition).

[0038] In another embodiment, UEFI reserved memory may be used to store context in the UEFI preboot environment that needs to be preserved. The integrity of memory areas of such EFI reserved memory may be guaranteed in both the UEFI preboot environment and the legacy operating system environment. The context in the UEFI preboot environment that needs to be preserved may be saved at any time after entering the UEFI preboot environment, provided this occurs before the UEFI enters the compatibility support module to invoke a legacy operating system boot process. In a preferred embodiment, the UEFI system service must first be invoked to allocate sufficient reserved memory so that the context in the above UEFI preboot environment that needs to be preserved is stored in the allocated reserved memory.

[0039] In one embodiment, the method further comprises: modifying the stored instruction pointer register in response to the CPU entering the system management mode so that the instruction pointer register points to an instruction adjacent to a call instruction that performs a boot of the legacy operating system to avoid re-calling the legacy operating system and re-entering the UEFI pre-boot environment, thus triggering a vicious cycle.

[0040] In step S302, restoring a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system, some embodiments are provided herein for determining that the UEFI preboot environment fails to load the legacy operating system.

[0041] In one embodiment, when the compatibility support module starts the legacy operating system loader in response to a boot failure, the legacy operating system loader typically calls a software interrupt (such as INT18) to notify the UEFI firmware. From the perspective of the UEFI firmware, in response to receiving a software interrupt from the legacy operating system loader, it may be determined that the UEFI preboot environment is failing to load the legacy operating system. If a failure is detected, the manner in which the CPU associated with the UEFI preboot environment is allowed to enter system management mode may utilize an interrupt routine function to restore a first portion of the CPU execution context and / or the address of the memory location containing UEFI code and data, and the contents of that memory location.

[0042] In another embodiment, a watchdog timer may be added to the UEFI firmware to detect a hang condition of the legacy operating system during the boot period. The watchdog timer is preset to a predetermined time. The watchdog timer triggers a hardware interrupt if the UEFI preboot environment has not received notification that the legacy operating system boot is successful within the predetermined time period preset by the watchdog timer. According to the triggering of the hardware interrupt, it is determined that the UEFI preboot environment failed to load the legacy operating system.However, if the UEFI preboot environment successfully loads the legacy operating system, the UEFI preboot environment receives a notification that the legacy operating system has successfully booted within the predefined time period preset by the watchdog timer. At this point, the UEFI firmware can pause the watchdog timer or preset it to an infinite period. In the specific embodiment, an interrupt routine function can be used to restore a first portion of the CPU execution context and / or the address of the memory location containing UEFI code and data, and the contents of that memory location.

[0043] In yet another embodiment, a machine-check exception mechanism may be used. The machine-check exception is a mechanism provided by the CPU for detecting and reporting a hardware error. It is the highest priority exception in the PC system and cannot be interrupted by another interrupt / exception. For a machine-check exception, for example, on a CPU with an x86 architecture, the status of an error that has occurred may be reported via an IA32_MCi_STATUS register, where two bits can be used to check whether the current CPU execution context has been destroyed. Valid (bit 63) = 1 and PCC (bit 57) = 0, this represents that the context has not been destroyed.If the CPU execution context has not been destroyed, the first section of the CPU execution context and / or the address of the memory area where UEFI code and data are located, and the contents of that memory area, can be restored in the machine check exception handler function. In another embodiment, it must first be judged in the exception handler function whether the CPU execution context has been destroyed. If the CPU execution context has not been destroyed, the first section of the CPU execution context and / or the address of the memory area where UEFI code and data are located, and the contents of that memory area, can be restored after the error has been corrected; and if the CPU execution context has been destroyed, the only option left is to reboot the system.

[0044] Restoring the first section of the CPU execution context involves restoring the global descriptor table (GDT), the interrupt descriptor table (IDT), the control register, and the segment register, and the following pseudocode can be used: MemoryCopy (ORIGINAL_GDT_ADDRESS, SAVED_GDT_ADDRESS, sizeof(GDT) ) / / Restore global descriptor table LGDT ORIGINAL_GDT_ADDRESS MemoryCopy (ORIGINAL_IDT_ADDRESS, SAVED_IDT_ADDRESS, sizeof(IDT) ) / / Restore interrupt descriptor table LIDT ORIGINAL_IDT_ADDRESS MOV CONTROL_REGISTER, SAVED_CR_VALUE / / Restore control register FAR JMP ADDRESS_OF_NEXT_INSTRUCTION / / Perform intersegment jump to the next instruction, change execution flow and serialize processor MOV ESEGMENT_REGISTER, / / Restore segment register NT_REGISTER_VALUESAVED_SEGM

[0045] To restore the address of the memory area where UEFI code and data are located and the contents of that memory area, the context in the UEFI preboot environment that needs to be preserved can be used to copy the contents of the memory area where UEFI code and data are located to the address of the memory area where UEFI code and data are located. Using reserved memory to store the context in the UEFI preboot environment that needs to be preserved is a memory-to-memory copy method.

[0046] In step S303, the CPU associated with the UEFI preboot environment enters the system management mode and restores a second portion of the CPU execution context under the system management mode. Restoring the second portion of the CPU execution context includes restoring the marker register, the instruction pointer register, the general register, and the system management base register. Pseudocode similar to that used to restore the first portion of the CPU execution context may be used. A hardware trigger method may be used to enter the CPU associated with the UEFI preboot environment into the system management mode, or a software system management interrupt (software SMI) trigger method may be used.Before the CPU belonging to the UEFI preboot environment is allowed to enter system management mode, the CPU must first be switched to protected mode, and then the software system management interrupt (software SMI) is triggered so that the CPU can enter system management mode.

[0047] In step S304, exit the CPU system management mode, thereby returning to the UEFI preboot environment. Exiting the CPU system management mode can be achieved by the CPU executing an RSM command, thereby returning to the originally stored UEFI preboot environment, making it possible to try a next UEFI boot option or perform UEFI system diagnostics. Furthermore, since the control units in the system are all disconnected by the UEFI during the attempt to boot the legacy system, after the UEFI preboot environment is restored, in response to returning to the UEFI preboot environment, the drivers of the control units controlled by the UEFI are caused to be re-executed, allowing control of the control units to be restored by the UEFI.

[0048] With the same inventive idea, the present invention also discloses a system for restoring from a legacy operating system environment to a UEFI preboot environment, and Fig. Figure 5 shows a structural block diagram of the system for restoring from a legacy operating system environment to a UEFI preboot environment. According to Fig.5, the system comprises: a storage unit 501 configured to store context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; a first restoration means 502 configured to restore a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system; a second restoration means 503 configured to allow the CPU associated with the UEFI preboot environment to enter the system management mode and restore a second portion of the CPU execution context under the system management mode; and an exit means 504 configured to exit the CPU system management mode and thereby return to the UEFI preboot environment.

[0049] In one embodiment, the context in the UEFI preboot environment that needs to be preserved further comprises an address of a memory area where UEFI code and data are located, and the contents of that memory area. The storage means preferably uses memory reserved for the UEFI to store the context in the UEFI preboot environment that needs to be preserved.

[0050] In one embodiment, the first recovery means determines that the loading of the legacy operating system by the UEFI preboot environment fails using one of: a first determination means configured to determine that the loading of the legacy operating system by the UEFI preboot environment fails in response to receiving a software interrupt from the legacy operating system loading unit; a second determination means configured to add a watchdog timer in the UEFI firmware, wherein the watchdog timer triggers a hardware interrupt if the UEFI preboot environment has not received a notification that the booting of the legacy operating system is successful within a predetermined period of time preset by the watchdog timer, and to determine that the loading of the legacy operating system by the UEFI preboot environment fails in accordance with the triggering of the hardware interrupt;a third means of determination configured to use a machine check exception mechanism to determine that the loading of the legacy operating system by the UEFI preboot environment fails;

[0051] In one embodiment, the first recovery means is further configured to restore the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that must be preserved to the address of the memory area containing UEFI code and data in response to the UEFI preboot environment failing to load the legacy operating system. Preferably, the first recovery means is further configured to terminate memory-related input / output of PCI devices after restoring the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that must be preserved to the address of the memory area containing UEFI code and data.

[0052] In another embodiment, the second restoration means is further configured to restore the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that needs to be preserved to the address of the memory area containing UEFI code and data in response to the CPU entering the system management mode. The second restoration means is preferably further configured to terminate the memory-related input / output of PCI devices after restoring the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that needs to be preserved to the address of the memory area containing UEFI code and data.The second recovery means is further preferably configured to modify the stored instruction pointer register in response to the CPU entering the system management mode so that the instruction pointer register points to an instruction other than a call instruction that performs a boot of the legacy operating system.

[0053] In one embodiment, the terminating means is further configured to cause drivers of the control units controlled by the UEFI to be re-executed in response to returning to the UEFI pre-boot environment.

[0054] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code comprising one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur in a different order than noted in the figures. For example, depending on the functionality involved, two consecutively illustrated blocks may even execute substantially concurrently, or the blocks may sometimes execute in the reverse order.It is further to be understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or operations, or by combinations of special purpose hardware and computer instructions.

[0055] The descriptions of the various embodiments of the present invention have been presented for illustrative purposes, but are not intended to be exhaustive or limited to the described embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over commercially available technologies, or to enable others skilled in the art to understand the embodiments described herein.

Claims

[1] A method for recovering from a legacy operating system environment to a Unified Extensible Firmware Interface (UEFI) preboot environment, comprising: Storing context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; Restoring an initial portion of the CPU execution context in response to a failure to load the legacy operating system through the UEFI preboot environment; Allowing the CPU associated with the UEFI preboot environment to enter a system management mode and restoring a second section of the CPU execution context under the system management mode; and Exit CPU system management mode and return to the UEFI preboot environment. [2] The method of claim 1, wherein the context in the UEFI preboot environment that needs to be obtained further comprises an address of a memory area in which UEFI code and data are located and contents of that memory area. [3] The method of claim 2, wherein in the step of storing context in the UEFI preboot environment that needs to be preserved, UEFI reserved memory is used to store the context in the UEFI preboot environment that needs to be preserved. [4] The method according to any one of claims 2 to 3, wherein the failure to load the legacy operating system through the UEFI preboot environment is determined using one of the following approaches: I) Determining that the UEFI preboot environment fails to load the legacy operating system in response to receiving a software interrupt from a legacy operating system loading unit; II) Adding a watchdog timer in UEFI firmware, wherein the watchdog timer triggers a hardware interrupt if the UEFI preboot environment has not received a notification that the booting of the legacy operating system is successful within a predetermined period of time preset by the watchdog timer, and determining that the UEFI preboot environment fails to load the legacy operating system according to the triggering of the hardware interrupt; III) Determine, using a machine check exception mechanism, that the UEFI preboot environment fails to load the legacy operating system. [5] The method of claim 4, further comprising: restoring contents of the memory area in which UEFI code and data are located, within the context in the UEFI preboot environment that needs to be preserved, to the address of the memory area in which UEFI code and data are located, in response to the UEFI preboot environment failing to load the legacy operating system. [6] The method of claim 5, further comprising: terminating memory-related input / output of PCI devices after restoring contents of the memory area where UEFI code and data are located, within the context in the UEFI preboot environment that needs to be preserved, to the address of the memory area where UEFI code and data are located. [7] The method of claim 4, further comprising: restoring contents of the memory area in which UEFI code and data are located, within the context in the UEFI preboot environment that needs to be preserved, to the address of the memory area in which UEFI code and data are located, in response to the CPU entering the system management mode. [8] The method of claim 7, further comprising: terminating memory-related input / output of PCI devices after restoring contents of the memory area where UEFI code and data are located, within the context in the UEFI preboot environment that needs to be preserved, to the address of the memory area where UEFI code and data are located. [9] The method of claim 5 or 7, wherein the method further comprises: Modifying a stored instruction pointer register in response to the CPU entering system management mode so that the instruction pointer register points to an instruction adjacent to a call instruction that performs a boot of the legacy operating system. [10] The method of claim 5 or 7, the method further comprising: in response to returning to the UEFI preboot environment, causing drivers of control units controlled by the UEFI to be re-executed. [11] A system for recovering from a legacy operating system environment to a Unified Extensible Firmware Interface (UEFI) preboot environment, comprising: a storage means configured to store context in the UEFI preboot environment that needs to be preserved under the UEFI preboot environment, wherein the context in the UEFI preboot environment that needs to be preserved comprises a CPU execution context; a first recovery means configured to restore a first portion of the CPU execution context in response to the UEFI preboot environment failing to load the legacy operating system; a second recovery means configured to allow the CPU associated with the UEFI preboot environment to enter the system management mode and to restore a second portion of the CPU execution context under the system management mode; and an exit means configured to exit the CPU system management mode and thereby return to the UEFI preboot environment. [12] The system of claim 11, wherein the context in the UEFI preboot environment that needs to be obtained further comprises an address of a memory area in which UEFI code and data are located and contents of that memory area. [13] The system of claim 12, wherein memory reserved for UEFI in the storage means is used to store the context in the UEFI preboot environment that needs to be preserved. [14] The system of any one of claims 12 to 13, wherein the first recovery means determines that the loading of the legacy operating system by the UEFI preboot environment fails by one of the following: a first determining means configured to determine, in response to receiving a software interrupt from the legacy operating system loading unit, that loading of the legacy operating system by the UEFI preboot environment fails; a second determination means configured to add a watchdog timer in UEFI firmware, wherein the watchdog timer triggers a hardware interrupt if the UEFI preboot environment has not received a notification that booting of the legacy operating system is successful within a predetermined period of time preset by the watchdog timer, and to determine, in accordance with the triggering of the hardware interrupt, that loading of the legacy operating system by the UEFI preboot environment fails; a third means of determination configured to use a machine check exception mechanism to determine that the UEFI preboot environment fails to load the legacy operating system. [15] The system of claim 14, wherein the first recovery means is further configured to restore the contents of the memory area containing UEFI code and data within the context in the UEFI preboot environment that needs to be obtained to the address of the memory area containing UEFI code and data in response to the UEFI preboot environment failing to load the legacy operating system. [16] The system of claim 15, wherein the first recovery means is further configured to terminate the memory-related input / output of PCI devices after restoring contents of the memory area in which UEFI code and data are located, within the context in the UEFI preboot environment that needs to be obtained, to the address of the memory area in which UEFI code and data are located. [17] The system of claim 14, wherein the second restoring means is further configured to restore contents of the memory area in which UEFI code and data are located, within the context in the UEFI preboot environment that needs to be obtained, to the address of the memory area in which UEFI code and data are located, in response to the CPU entering the system management mode. [18] The system of claim 17, wherein the second recovery means is further configured to terminate the memory-related input / output of PCI devices after restoring contents of the memory area in which UEFI code and data are located, within the context in the UEFI preboot environment that needs to be obtained, to the address of the memory area in which UEFI code and data are located. [19] The system of claim 15 or 17, wherein the second recovery means is further configured to modify a stored instruction pointer register in response to the CPU entering the system management mode so that the instruction pointer register points to an instruction other than a call instruction that performs a boot of the legacy operating system. [20] The system of claim 15 or 17, wherein the terminating means is further configured to cause drivers of control units controlled by the UEFI to be re-executed in response to returning to the UEFI pre-boot environment. [21] A computer program comprising program code designed to perform the method steps of any one of claims 1 to 10 when the program is executed on a computer.

Images