允许快速平台重启的方法和系统

技术领域

本发明涉及平台，并且更具体地说，涉及在平台重启期间，通过最小化与平台连接的输入/输出(IO)设备的硬件初始化来允许平台的快速重启，但并不仅涉及该方面。

背景技术

在平台的操作期间，非常期望平台具有连续的正常运行时间或可以连续地访问。平台的连续运行能力对终端用户很重要，并且对企业尤其重要，因为它会影响企业的运营。平台的正常运行时间和可靠性通常被测量并且称为5个9，即99.999％的可用性。在企业中，当平台在一年中有超过51/4分钟不可用时，其不可以被认定为满足5个9。针对企业的平台的销售通常由平台满足5个9的能力来确定。

影响平台的正常运行时间的因素之一是需要重启或重置平台。当平台被重启时，重启所花费的时间被认为是非正常运行时间并且其影响平台的可用性。需要重启平台的大量原因中的一些包括：由于加载新OS驱动程序、新软件或新软件补丁而重新初始化在平台上运行的操作系统(OS)。OS可以确定需要重启平台来更新其注册表项(registry key)或重启OS环境。

然而，在一些情况中，可能无需重启整个平台来允许OS更新它的注册表项或无需重启OS环境。在一个实例中，当平台不需要硬件改变而仅需软件改变时，无需重启整个平台以及再次重新初始化所有硬件。然而，传统的平台甚至在当平台不需要硬件改变而仅需要软件改变时也执行完全的平台重置。

图1A描述了支持遗留基本输入/输出系统(legacy based BIOS)的传统平台的现有技术的重启顺序100。时间线105示出了重启顺序100的时间基准。当传统的平台在时间0处加电时，其进入早期初始化的阶段110。在阶段110，中央处理单元(CPU)加电并执行位于其重置向量处的BIOS代码。BIOS可以执行平台的基本检查，例如加电自检(POST)和存储器检查。在检查完成后，BIOS启动硬件初始化的下一阶段115。在阶段115中，BIOS检测连接到或插在平台上的IO设备并执行初始化任务，例如外围部件互连(PCI)枚举、运行选项只读存储器(ROM)或轮询IO设备。

当硬件初始化阶段115完成时，在阶段120运行OS。在平台的操作期间，会遇到软件发起的重置请求或热重置。阶段125描述了平台接收到热重置请求。在接收到热重置请求时，平台执行完整的平台重置并再次进入早期初始化的阶段130、硬件初始化的阶段135和运行OS的阶段140。

附图说明

根据对主题的以下详细的描述，本发明实施例的特征和优点将变得明显，其中：

图1A描述了传统的平台(现有技术)的重启顺序；

图1B描述了根据本发明一个实施例的平台的重启顺序；

图2描述了平台的引导流程；

图3描述了根据本发明的一个实施例的平台的重启顺序；

图4描述了根据本发明的一个实施例的平台重启的流程图；

图5A描述了根据本发明的一个实施例的平台重启的流程图；

图5B描述了根据本发明的一个实施例的平台重启的流程图；

图6描述了根据本发明的一个实施例的实现快速平台重启的系统。

具体实施方式

说明书中提到的本发明的“一个实施例”或“一实施例”意味着结合实施例描述的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在说明书各处出现的短语“在一个实施例中”并非必然都指相同的实施例。

本发明的实施例在平台重启期间，通过最小化与平台连接的IO设备的硬件初始化来允许平台执行快速重置或重启。平台包括但不限于服务器、台式计算机、移动计算机、工作站或可以接收热重置请求以重启计算设备的任何计算设备。平台包含IO设备，所述IO设备包括但不限于硬盘驱动器、固态驱动器、存储器模块、处理器、芯片组、视频显示卡、声卡、压缩盘驱动器、软盘驱动器或为平台执行功能的任何其它IO设备。热重置请求是由在平台上运行的OS或由平台的本地或远程用户发起的软件发起重置请求(SIRR)。在平台中触发热重置的OS中的事件包括但不限于从平台的本地用户或远程用户接收到重引导或重启请求，以及在OS安装新软件模块或新软件补丁之后的重启请求。

图1B描述了根据本发明的一个实施例的，支持遗留BIOS的平台的重启顺序150。早期初始化的阶段160类似于图1A中描述的阶段130。在一个实施例中，修改平台的BIOS来检测并捕获(trap)对平台的热重置请求。阶段160执行平台的基本检查的早期初始化，例如加电自检(POST)和存储器检测。在检查完成后，修改的BIOS启动硬件初始化的下一阶段165。阶段165的硬件初始化类似于阶段115的硬件初始化。

在另一实施例中，修改平台的BIOS，以在阶段165保存连接到平台的一些或全部IO设备的先前的硬件状态。IO设备的硬件状态包括但不限于IO设备的寄存器设置和在PCI枚举期间由BIOS确定的配置设置。

例如，当BIOS执行PCI枚举并检测到连接到平台的硬盘驱动器时，BIOS从硬盘驱动器请求信息，例如硬盘驱动器的类型或驱动器的模式(主或从)。BIOS基于从硬盘驱动器获得的信息来确定传输速度的最佳设置。硬盘驱动器的最佳设置由修改后的BIOS来保存，以使得硬盘的最佳设置在平台的重启期间可以被重新编程。通过保存最佳设置，避免了需要BIOS每次在热重置期间重启平台时从硬盘驱动器请求信息并确定最佳设置。

完成硬件初始化的阶段165之后，在阶段170运行OS并且在阶段175将OS的热重置请求发送到平台。在早期初始化的阶段180，修改后的BIOS检测并捕获热重置请求。当热重置请求被捕获时，修改后的BIOS将热重置请求转换为仅CPU初始化重置请求。通过将热重置请求转换为仅CPU初始化重置请求，平台中的IO设备不再接收执行自身初始化的重置请求。在图1B的阶段180中，CPU未执行在图1A的阶段130中执行的全部BIOS代码。阶段180的修改后的BIOS代码执行基本的CPU初始化，并且通过使用在阶段165所保存的先前的硬件状态对IO设备重新编程从而将平台中的IO设备恢复到它们先前的硬件状态。在一个实施例中，BIOS使用IO设备的先前的硬件状态的保存的寄存器设置来对IO设备的寄存器进行重新编程。

在阶段180完成后，平台绕过传统的硬件初始化阶段135，进入阶段190以重运行或重启先前在阶段170中加载的OS的相同版本。时间线105和155示出了与重启顺序100相比重启顺序150的基准时间节省。执行图1B中的平台的重启(阶段180和阶段190)所需的时间比执行图1A中的平台重启(阶段130、阶段135和阶段140)所需的时间短。

通过利用在早期初始化的阶段180中所执行的小规模的BIOS代码并且最小化平台中的IO设备的执行自身初始化的需求，平台的重启以快速的方式来执行。当不需要对平台硬件进行改变以及当仅需要对平台软件进行改变时，图1B的平台不执行完全的平台重置。相反，当平台接收到热重置请求时，仅重置对于软件事件重新初始化自身所需的平台的一部分。

在本发明的一个实施例中，减少了与平台的重启相关联的平台开销。平台中的硬件初始化的最小化是减少平台开销的一种方法，并且还可以执行其它用于减少平台开销的方法，以允许平台的快速重启。由于与软件补丁的安装和常规维护相关联的更低的平台开销，因此平台的更快速的重启提供了确保企业中更多的平台可以维持5个9的可用性的能力。

图2描述了支持可扩展固件接口(EFI)或统一EFI(UEFI)的平台的引导流程200。在一个实施例中，基于针对EFI的平台创新框架(Platform Innovation Framework)来实现平台中的UEFI，下文称为“框架”。引导流程200包括但不限于平台加电时的阶段201、平台初始化时的阶段202、OS引导时的阶段203、当OS接收到热重置请求时的阶段204。当平台重启时，引导流程200返回阶段201。

在引导流程200的加电阶段201期间，平台进入“框架”的安全(SEC)阶段210。预验证器210处理所有平台重启事件，其包括但不限于从未加电状态向平台供电，从活动状态重启平台以及接收各种异常情况。引导流程200中的下一阶段是平台初始化阶段202。平台初始化阶段202包括“框架”的预EFI初始化(PEI)阶段220和驱动执行环境(DXE)阶段230。

在SEC阶段210之后，PEI阶段220配置平台以满足“框架”结构的DXE阶段230的最低必要条件。在PEI阶段220期间，PEI核心222初始化关键IO设备，例如CPU 224、芯片组226和主板228。PEI核心222还初始化图2中未示出的、平台中的所有其它关键IO设备。在PEI阶段之后，EFI驱动调度器232在DXE阶段230期间加载在平台中连接的IO设备的设备驱动器、总线驱动器或串行驱动器236。架构协议234也在该阶段被加载。元件244和246描绘了针对设备驱动器236和架构协议246的UEFI接口。

在DXE阶段230之后，进入引导设备选择(BDS)阶段240。引导管理器242确定大容量存储设备驱动器从而引导用于平台的OS，并且当多个操作系统出现或安装在平台中时还确定将哪一个OS加载到平台中。引导流程200进入OS引导阶段并且平台进入“框架”的瞬时系统加载(TSL，transient system load)阶段250。引导管理器242加载瞬时OS引导加载程序256，并且瞬时OS引导加载程序256启动瞬时OS环境254。OS空缺(OSabsent)应用程序252可以由瞬时OS环境254运行。在瞬时OS引导加载程序256完成后运行最终OS引导加载程序258。

在一个实施例中，修改引导管理器242以加载最终OS加载程序的映像两次并且将映像复制到高速缓存中。在其它实施例中，引导管理器242加载最终OS引导加载程序两次，并且将最终OS引导加载程序映像的第一副本保存为未改变的基于存储器的源，并且运行最终OS引导加载程序映像的第二副本。在其它实施例中，OS的部分映像或整个映像也可以被复制为未改变的基于存储器的源，从而允许恢复OS的部分映像或整个映像。

当最终OS引导加载程序258启动最终OS环境262并执行OS存在(OSpresent)应用程序264时，平台进入运行时间(RT)阶段。当在RT阶段期间由OS接收到热重置请求时，引导流程200返回加电阶段201以重启平台并且再次进入平台初始化阶段202和OS引导阶段203。

图3描述了根据本发明的一个实施例的平台的重启顺序300。平台从OS接收热重置请求304。在一个实施例中，热重置请求304接着引导流程200。当接收到热重置请求时，平台进入加电阶段301。修改预验证器312以检测并捕获任何热重置请求。预验证器312还被修改为当热重置被捕获时，将该热重置转换为仅CPU初始化重置请求。

当预验证器312检测到热重置304时，其捕获热重置304并且将热重置304转换为仅CPU初始化重置请求。平台初始化CPU并且预验证器将平台中的IO设备恢复到它们先前的硬件状态。在一个实施例中，预验证器调用“框架”的block IO.reset函数，其将每个IO设备恢复到已知状态。由于平台中的IO设备被预验证器312恢复到已知的硬件状态或其先前的硬件状态，所以重启顺序300避免了平台初始化阶段302，并且不执行PEI阶段320和DXE阶段330。

执行PEI核心322的步骤以及初始化CPU 324、芯片组326和主板328的步骤不被执行，并且它们用虚线来表示。此外，EFI驱动调度程序332、设备驱动器336和架构协议334不被重新加载，并且它们也用虚线来表示。在BDS阶段340，预验证器312调用引导管理器342。在一个实施例中，引导管理器342使用在BDS阶段340期间所保存的最终OS引导加载程序映像的副本来恢复最终OS引导加载程序358。在其它实施例中，引导管理器342也可以被修改为从平台的引导盘加载另外的映像以加速平台的重启。

由于使用先前的OS加载程序映像，所以不执行用于执行瞬时OS引导加载程序356、瞬时OS环境354和OS空缺应用程序352的步骤，并且用虚线来表示它们。使用在BDS阶段340期间所保存的最终OS引导加载程序映像的副本来执行最终OS引导加载程序358，并且在RT阶段360中执行最终OS环境362和OS存在应用程序364。

图4描述了根据本发明的一个实施例的平台的重启顺序的流程图。在步骤405，在平台上运行的OS接收到热重置请求。在一些实施例中，重启平台的热重置请求由在OS中安装应用程序来触发，或由平台的本地或远程用户来触发。OS启动平台向断电状态的转变。在一些实施例中，OS启动平台向系统功率状态5(S5)的转变。

在步骤410中，平台开始执行OS的关闭，并且OS将OS中的脏数据(dirty data)写回到大容量存储设备。大容量存储设备包括但不限于硬盘驱动器、快闪驱动器、固态存储器、通用串行总线(USB)驱动器或用于平台的任何形式的数据存储单元。不执行到大容量存储设备的回写。在一个实施例中，脏数据被回写到回写(WB)高速缓存。

在步骤410中回写脏数据之后，在步骤415中OS关闭并触发热重置。在一个实施例中，通过经由端口64h向板载键盘控制器写入来触发热重置以执行平台的热重置。在步骤420中，平台通过BIOS来执行定制的快速重启流程。在一个实施例中，由在图1B中讨论的修改的BIOS 180来执行定制的快速重启流程420。在其它实施例中，由在图3中讨论的预验证器312来执行定制的快速重启流程420。修改的BIOS 180和预验证器312都检测并捕获热重置请求，并且将热重置转换为仅CPU初始化重置请求。由修改的BIOS 180或预验证器312将平台中的IO设备恢复到先前的硬件状态。

在步骤425，修改后的BIOS发出中断19h(十六进制)以加载OS。在另一实施例中，预验证器运行引导管理器342以使用先前的OS加载程序映像的副本来恢复OS引导加载程序。在步骤430中，OS引导加载程序通过发出中断13h(十六进制)来命中快闪驱动器。在步骤435中，使用本地驱动器来引导OS，并且在步骤440中，OS重启完成。

图5A示出了根据本发明的一个实施例的、支持遗留BIOS或“框架”的平台的重启顺序的流程图。在步骤502，平台进入早期初始化阶段并且对平台的CPU和存储器供电。CPU执行位于其重置向量处的BIOS代码并执行平台的基本检查，例如加电自检(POST)和存储器检测。在步骤504，流程检查是否支持平台的快速重启。如果不支持，那么在步骤508流程进行平台的常规硬件初始化。在常规硬件初始化期间，检测连接到或插入平台的IO设备，并且执行例如外围部件互连(PCI)枚举、运行选项只读存储器(ROM)或轮询IO设备这样的任务。如果支持，那么在步骤506，流程检查平台的当前的硬件配置是否与平台的先前的硬件配置不同。

如果硬件配置有改变，那么流程继续到步骤508以执行平台的常规初始化。如果硬件配置未改变，那么流程继续到步骤510以检测是否有热重置请求。如果有，那么流程继续到步骤5B。在图5B中讨论了步骤5B。如果没有，那么流程继续到步骤512以执行平台的常规初始化。在一个实施例中，由图1B中讨论的修改后的BIOS 180来执行步骤502、504、506和510。在另一实施例中，由图3的预验证器312来执行步骤502、504、506和510。在PEI 320阶段和DXE 330阶段期间，执行常规初始化的步骤512。尽管步骤506和508显示了当检测到硬件改变时平台不执行快速平台重启，但是在其它实施例中，可以修改流程以允许平台在检测到硬件改变时支持快速平台重启。例如，流程检测到连接到平台的新的IO设备并执行新的IO设备的常规初始化，并且流程继续到步骤510。

在步骤512之后，流程继续到步骤514以检查平台是否支持遗留BIOS。如果支持，那么流程继续到步骤518以将平台的遗留BIOS存储器区域中的数据复制到缓冲器。遗留BIOS存储器区域中的数据包括但不限于BIOS数据区域(BDA)中的数据和扩展BIOS数据区域(EBDA)中的数据。在一个实施例中，在平台的存储器映射中，将所述缓冲器指示为对OS或OS加载程序不可用。在另一实施例中，复制的数据被预先配置签名并且被放置在缓冲器的特定存储器粒度处，以使得其可以由平台发现。

如果在步骤514中确定平台不支持遗留BIOS，那么流程继续到步骤516。步骤516加载OS加载程序两次并将OS加载程序映像的第一副本保存为未改变的基于存储器的源，并且运行OS加载程序映像的第二副本。在其它实施例中，OS的部分映像或整个映像也可以被复制为未改变的基于存储器的源，以允许恢复OS的部分或整个映像。在步骤520，流程检查OS加载程序是否尝试转变为运行时间。如果不是，那么在步骤522，流程继续平台的OS初始化。如果是，那么流程在步骤524，在平台重启期间，维护引导服务存储器以便于平台保持其固件基础结构。

在一个实施例中，在支持EFI或支持所述框架的平台的BDS阶段中，由引导管理器342来执行步骤516、520、522、524。当接收到对“框架”的函数ExitBootServices的调用时，引导管理器不解构(deconstruct)引导服务存储器。在步骤508、518和524后，在步骤526运行OS。在步骤528，流程接收重置并继续到步骤502以执行平台的早期初始化。

图5B说明了当步骤510检测到存在热重置请求时的流程图。在一个实施例中，由图1B中讨论的修改后的BIOS 180来执行步骤552、554、556和558。在另一实施例中，由图3的预验证器312来执行步骤552、554、560、562和564。在步骤552，修改后的BIOS 180或预验证器312检测到并捕获热重置请求。修改后的BIOS 180或预验证器312还将热重置请求转换为仅CPU初始化重置请求。CPU被初始化为其先前的状态或已知的状态。在步骤554，流程检查平台是否支持遗留BIOS。如果是，那么在步骤556，修改后的BIOS 180将平台的CPU切换为实模式，并对高级可编程中断控制器(APIC)进行重新编程。在步骤518，修改的BIOS 180使用其先前的值的复制的数据将遗留BIOS存储器区域恢复为其先前的值。在步骤558，修改的BIOS 180经由中断19h(十六进制)来启动引导(boot strap)加载程序，从而运行OS以重启平台。

如果平台不支持遗留BIOS而支持EFI或“框架”，那么在步骤560中预验证器312将平台的CPU切换为保护模式，并对高级可编程中断控制器(APIC)进行重新编程。在步骤562，预验证器312将平台中的IO设备恢复到它们先前的硬件状态或已知的状态。在一个实施例中，预验证器312调用“框架”的block_io重置函数，其将每个IO设备重置为已知的状态或先前的硬件状态。可以针对每个IO设备实现block_io重置函数，或者为所有IO设备共同地实现block_io重置函数。

在步骤564，使用在步骤516中所保存的先前的OS加载程序映像的副本来恢复平台的OS加载程序。使用在步骤516所保存的OS加载程序映像来运行OS。尽管步骤564仅恢复OS加载程序映像，但是在其它实施例中，步骤564可以恢复其它映像，该其它映像允许平台以快速方式来重启。步骤564和558继续到步骤568来运行OS，并且流程返回步骤5A。尽管流程图5A和5B描述了针对支持遗留BIOS或EFI的平台的重启顺序，但是并不意味着限制性的。本发明的实施例还可以支持其它形式的引导固件以允许平台的快速重启。

图6示出了根据实施例的实现本文公开的方法的系统600的框图。系统600包括但不限于台式计算机、膝上型电脑、笔记本电脑、个人数字助理(PDA)、服务器、工作站、蜂窝电话、移动计算设备、互联网装置或任何其它类型的计算设备。在另一实施例中，用来实现本文公开的方法的系统600可以是片上系统(SOC)类型的系统。

系统600包括具有存储器控制器630和输入/输出(I/O)控制器640的芯片组635。芯片组通常提供存储器和I/O管理功能，以及可以由处理器625访问或使用的多个通用和/或专用寄存器、计时器等。可以使用一个或多个处理器来实现处理器625。

存储器控制器630执行使得处理器625能够经由总线665对主存储器615进行访问并与其进行通信的功能，其中，所述主存储器615包括易失性存储器610和非易失性存储器620。在本发明的一个实施例中，修改的BIOS180存储在非易失性存储器620中。在本发明的其它实施例中，预验证器312存储在非易失性存储器620中。

易失性存储器610包括但不限于同步动态随机存取存储器(SDRAM)、动态随机存取存储器(DRAM)、RAMBUS动态随机存取存储器(RDRAM)和/或任何其它类型的随机存取存储设备。非易失性存储器620包括但不限于闪存、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)和/或任何其它期望的类型的存储器设备。

存储器615存储信息和由处理器625执行的指令。存储器615还可以存储当处理器625执行指令时的临时变量或其它中间信息。

系统600包括但不限于耦合到总线665的接口电路655。接口电路655使用任何类型的公知的接口标准来实现，包括但不限于以太网接口、通用串行总线(USB)、第三代输入/输出接口(3GIO)和/或任何其它合适类型的接口。

一个或多个输入设备645连接到接口电路655。输入设备645允许用户向处理器625输入数据和命令。例如，使用键盘、鼠标、触摸屏、轨迹板、轨迹球和/或语音识别系统来实现输入设备645，但并不局限于此。

一个或多个输出设备650连接到接口电路655。例如，使用发光显示器(LED)、液晶显示器(LCD)、阴极射线管(CRT)显示器、打印机和/或扬声器来实现输出设备650，但并不局限于此。接口电路655包括图形驱动卡。

系统600还包括用于存储软件和数据的一个或多个大容量存储设备660。这种大容量存储设备660的例子包括但不限于软盘和驱动器、硬盘驱动器、快闪盘驱动器、固态硬盘驱动器、压缩盘和驱动器以及数字多用途盘(DVD)和驱动器。

接口电路655包括通信设备，例如调制解调器或网络接口卡，以便经由网络与外部计算机交换数据。系统600与网络之间的通信链路可以是任何类型的网络连接，例如以太网连接、数字用户线(DSL)、电话线、蜂窝电话系统、同轴电缆等。

通常由I/O控制器640以传统的方式来控制对输入设备645、输出设备650、大容量存储设备660和/或网络的访问。特别地，I/O控制器640执行允许处理器625经由总线665和接口电路655来与输入设备645、输出设备650、大容量存储设备660和/或网络进行通信的功能。

虽然图6中示出的部件被描绘为系统600内的分离的模块，但是这些模块中的一些所执行的功能可以集成在单个半导体电路内，或者可以使用两个或多个分离的集成电路来实现。例如，尽管存储器控制器630和I/O控制器640被描述为芯片组635内的分离的模块，但是相关领域中的普通技术人员将容易理解，存储器控制器630和I/O控制器640可以集成在单个半导体电路内。

尽管描述了公开主题的实施例的示例，但是相关领域中的普通技术人员将容易理解，可以替代地使用用于实现所公开的主题的多种其它方法。例如，流程图中的块的执行的顺序可以改变，和/或框/流程图中描述的一些块可以改变、删除或组合。

在上述描述中，描述了公开主题的各个方面。为了解释说明的目的，阐述了具体的数量、系统和配置，以便于对主题的透彻的理解。然而，对于受益于本公开的相关领域的技术人员来说，可以在没有具体的细节的情况下实施本主题是显而易见的。在其它例子中，省略、简化、组合或分离了已知的特征、部件或模块，以便不使所公开的主题模糊。

可以用硬件、固件、软件或其组合来实现所公开主题的各种实施例，并且可以通过参考或结合程序代码来描述其，所述程序代码例如指令、函数、过程、数据结构、逻辑、应用程序、用于设计的仿真、模拟和制造的设计表示或格式，当由机器访问它们时，导致机器执行任务、定义抽象数据类型或低级硬件环境或产生结果。

虽然参考示例性实施例描述了所公开的主题，但是该描述并非旨在以限制性的含义来解释。对于公开主题所属领域中的技术人员来说显而易见的示例性的实施例的各种变型以及本主题的其它实施例被认为在公开的主题的范围内。