用于可配置错误处理的系统

背景技术

传统计算机硬件设备能够在它们运作时检测错误，并且向它们被安装在的计算平台报告错误。错误然后可能通过平台软件堆栈被传播以用于适当处理。错误可以被传播给固件或者被直接传播给操作系统(O/S)。如果错误首先被传播给固件，则BIOS系统管理模式组件接收用于处理错误的控制，并且控制然后被传递给O/S。

在预引导过程期间，平台被初始化以针对每个安装的硬件设备指定错误传播方案(例如，固件优先或者O/S优先)。这样的硬件设备可以包括存储器模块以及用于加速的联网、计算卸载、存储或者其他服务的外围设备组件互连快速(PCIe)设备。针对设备而被指定的错误传播方案在运行时期间无法被改变。

期望有灵活的错误处理机制，通过该机制O/S可以确定是否按照适合的方式处理错误或者针对典型的固件优先错误处理将控制提供回BIOS。也期望针对特定硬件端点、对错误传播方案的按需更新，特别是对不要求硬件重新初始化的更新。

附图说明

图1示出了根据一些实施例的平台架构中的错误传播。

图2是根据一些实施例的服务器平台的硬件架构的框图。

图3是根据一些实施例的用以传播存储器错误的过程的流程图。

图4是根据一些实施例的用以传播PCIe错误的过程的流程图。

图5是根据一些实施例的用以传播PCIe错误的过程的流程图。

图6是示出了根据一些实施例的替换I/O端点的框图

图7是根据一些实施例的用以改变针对服务器平台中的替换的I/O端点的错误传播方案、而不要求硬重新引导的过程的流程图。

具体实施方式

以下描述被提供以使得本领域任何人能够制作和使用所描述的实施例。然而，各种修改对本领域技术人员而言仍是容易地显而易见的。

一些实施例通过基于可更新过滤逻辑在O/S处确定是在O/S中还是在固件中处理错误提供了对修理错误传播方案的技术问题的技术解决方案。实施例也通过允许对过滤逻辑的更新而无需硬件重新初始化来提供了对在平台定制/更新期间的过多停机时间的问题的技术解决方案。

一般而言，一些实施例运作以检测硬件端点错误并且触发由高级配置和电源接口(ACPI)运行时组件接收的软件中断。ACPI运行时组件确定错误是否被指明为由基于固件的错误处理器(error handler)处理，并且如果是这样，则触发对固件组件的软件中断以用于处理错误。如果错误未被指明为由基于固件的错误处理器处理，则错误由适合的O/S错误处理器处理。

错误是否被指明为由基于固件的错误处理器处理的确定可以基于对应的ACPI设备特定方法在O/S层中是存在还是不存在。有利地，并且根据一些实施例，针对硬件端点的错误传播方案可以被改变，而无需改变平台BIOS，而是仅通过更新一个或多个ACPI设备特定方法和O/S处理器。在一些实例中，ACPI设备特定方案和O/S处理器可以被更新(并且错误传播方案由此被改变)，而无需重新初始化平台，由此使系统停机时间最小化。

图1是根据一些实施例的平台架构100的框图。平台架构100可以代表服务器运行时架构。架构100可以如本领域中已知的支持用户模式应用和/或虚拟机。

架构100的硬件层110包括中央处理单元(CPU)112，其被配置为从各种硬件端点114-117检测错误。根据一些实施例，硬件端点114-117错误由CPU 112的控制器或者端口检测。实施例可以包括多于一个CPU，并且这样的CPU中的每个CPU可以从任何数目的硬件端点接收错误通知。

硬件层110还包括服务处理器118。服务处理器118可以包括与CPU 112不同并且管理诸如监视环境状况和处理特定错误状况的平台特定功能的微控制器。服务处理器118可以在系统事件日志内维持错误记录以用于宕机后分析，例如，可以包括基板管理控制器的组件。

BIOS层120包括运行时组件，其在BIOS引导期间被初始化。具体而言，系统管理模式(SMM)运行时122被初始化并且被与设备特定错误管理器124相关联。ACPI运行时132页在BIOS引导期间被初始化。

BIOS引导还可以包括对如与被传播给SMM运行时122的SMI(系统管理中断)相反的ACPI系统控制中断(SCI)的错误信令的配置。这一配置可以经由如本领域中已知的平台控制器集线器(未示出)的通用IO(GPIO)设置而被指定。

O/S层130包括在跟随BIOS引导的O/S的引导期间被实例化的运行时组件。错误处理过滤器133可以包括与一个或多个硬件端点相关联的设备特定方法(_DSM)。对错误处理过滤器133的使用将在以下被详细描述。

错误处理器134、内核136和O/S层的O/S事件日志137可以如本领域中已知的操作。例如，对应于具有错误状况的硬件的错误处理器134创建错误分组并且将分组转发给内核136。内核136基于错误分组来创建错误记录并且可以在O/S事件日志137的错误记录138之中日志记录错误记录。在非致命未纠正硬件错误的情况中，内核136可以尝试纠正错误状况。

图2是根据一些实施例的平台200的框图。平台200可以实现架构100，但是实施例并不被限制于此。

平台200包括两个CPU 202和204，其可以包括已知或将变成已知的任何类型的CPU。实施例并不限于包括任何特定数目的CPU的平台。每个CPU 202和204被链接到各种I/O接口，对应的硬件I/O端点可以被安装到这些接口中。

例如，CPU 202被耦合到双列直插式存储器模块(DIMM)212和214。CPU 202包括集成存储器控制器203以与DIMM 212对接。因此，存储器控制器203操作以检测DIMM 212和214中的错误，并且如果可能的话采取适当的纠正动作。存储器控制器203页将错误信息日志记录到例如CPU 202的存储器特定寄存器(MSR)的构造的错误上下文寄存器中。CPU 203被直接耦合到DIMM 213和215并且包括可以如以上描述的操作的存储器控制器205。

CPU 202也被直接耦合到PCIe插槽222、224和226。PCIe插槽222、224和226可以安装提供联网、图形处理、存储或者其他功能的扩展卡。每个扩展卡可以直接通过它的相关联的PCIe插槽222、224或者226以及连接该插槽与CPU 202的总线与CPU 202的PCIe根端口通信。CPU 202的PCIe根端口可以检测其被连接到的任何PCIe端点上的错误。再次，CPU 204也被耦合到PCIe插槽225和227，并且可以包括PCIe根端口以从被安装在其中的PCIe端点检测错误。

CPU 202被耦合到如本领域中已知的平台控制器集线器(PCH)230。PCH 230控制特定数据路径并且支持连同CPU 202和204而被使用的功能。PCH 230被耦合到存储BIOS的闪存239以及基板管理控制器(BMC)240。BMC 240是专用服务处理器，其监视平台200的物理状态，并且可以支持通过管理接口246与系统管理员的带外通信。

图3包括根据一些实施例的过程300的流程图。在一些实施例中，计算设备(例如，计算机服务器)的处理单元(例如，一个或多个处理器、处理核、处理器线程)执行程序代码以使得设备执行过程300。过程300和本文提及的所有其他过程可以被体现在从诸如硬盘、闪存等非瞬态计算机可读介质中的一个或多个被读取的处理器可执行程序代码中，并且人后按照压缩、未编译和/或加密格式被存储。在一些实施例中，硬接线电路可以替代程序代码或者结合程序代码而被使用，以用于根据一些实施例对过程的实现。实施例因此并不限于硬件和软件的任何特定组合。

过程300开始自在S310对存储器错误的检测。如上所述，平台存储器控制器(其可以或者可以不被集成到平台CPU中)可以在S310使用一致错误信令和检测协议检测存储器错误。存储器控制器可以采取纠正动作，并且也可以将对应的错误信息日志记录到平台CPU的构建的错误上下文寄存器中。

日志记录的错误信息使得CPU在S320触发中断。中断可以包括如图1中所示由ACPI运行时组件接收的SCI。接着，在S330，ACPI运行时组件确定错误是应当由BIOS运行时中的基于固件的错误处理器处理，还是由O/S错误处理器处理。

在S330的确定可以包括确定O/S是否包括与错误源相关联的设备特定方法。如果没有这样的方法存在，则流程前进到S340以使用O/S错误处理器(例如，处理器134)处理中断。有利地，这样的错误处理可以前进到接收错误的处理线程，留下其他处理线程来执行O/S功能。

如果设备特定方法存在，在中断在S350由向BIOS运行时(例如，向系统管理模式运行时)注册的错误处理器处理。在这方面，ACPI运行时可以如图1中所示发起系统管理中断(SMI)以触发SMM错误处理器。流程然后从S350继续到S340以向O/S错误处理器传递控制。

过程300无需被限于存储器错误，而是可以被扩展到处理针对任何硬件端点而被检测到的错误。错误检测的特定实现和SCI的发起可以取决于硬件端点而不同。图4的过程400描绘根据一些实施例的对检测到的PCIe错误的处理。

PCIe错误在S410被检测到。被安装在平台中的每个PCIe端点与PCIe根端口相关联。PCIe根端口可以从它的相关联的PCIe设备检测错误。PCIe根端点可以被集成到CPU、PCH或者任何适当的硬件组件中。

响应于对错误的检测，PCIe根端点在S420触发PCIe高级错误报告(AER)消息信号中断(MSI)。MSI由O/S根端点错误处理器接收，O/S根端点错误处理器响应于这一点而触发SCI。如前所述，SCI由ACPI运行时组件接收，ACPI运行时组件在S430确定错误是否应当由BIOS运行时中的基于固件的错误处理器处理。

在S430的确定可以类似于相对于S330如前所述地进行。具体而言，如果与错误源相关联的设备特定的方法存在，则ACPI运行时可以在S440发起SMI以触发对应的SMM错误处理器以处理错误。流程然后前进到S450以将控制返回O/S根端口错误处理器。如果在S430未标识对应的设备特定方法，则错误在S450被返回给O/S根端口错误处理器，而无需将控制首先返回给BIOS。

图5的过程500示出了根据一些实施例的用以处理PCIe错误的备选方式。S510、S520、S530和S540在确定检测到的PCIe错误将由O/S根端口处理器排他地处理的情况中类似于如上所述的。S410、S420、S430和S440来进行。

然而，如果在S530确定检测到的PCIe错误将由SMM处理器处理，则流程首先前进到S550以使用SMM处理器处理错误。在SMM处理器完成它的陈露之后，在S560确定错误是否是可纠正错误。如果是，则SCI在S570被触发以将通知返回给ACPI运行时。如果错误在S560被确定为不可纠正，则不可屏蔽中断(NMI)在S580被触发。NMI被报告给O/S，无论处理器的当前中断优先级水平。NMI通常指示致命硬件错误状况，并且由O/S相印地处理。

图6示出了利用未标识(例如，升级的)PCIe端点对被安装在平台200的插槽222中的PCIe端点的替换。这样的端点的替换通常可以要求固件更新或者至少系统重新引导以确保正确的错误处理。

图7示出了根据一些实施例的用于响应于替换的硬件端点的过程700。在S710，端点在O/S执行期间被替换。例如，在S710的平台(例如，服务器)内的端点的替换期间，平台以完全引导到它的O/S中，并且O/S运行以服务于从应用接收的请求。

接着，贼S720，O/S被更新以利用BIOS错误处理器将端点取消关联。因此假设之前端点与SMM错误处理器相关联，并且它的错误首先如关于过程400和500所述的由SMM错误处理器处理。也如前所述，一些实施例可以使用ACPI设备特定方法将错误源与SMM错误处理器相关联。因此，S720可以包括禁用或者卸载将之前端点与SMM错误处理器相关联的ACPI设备特定方法。O/S然后在S730被更新以包括与替换端点相关联的O/S错误处理器。

在S740，平台被重新引导到现在更新的O/S，而无需执行BIOS。在一些实施例中，S740包括内核软重新引导(KSR)，其重新引导O/S而无需重新初始化平台硬件。例如，控制在关机后被传递给驱动器而不是固件，并且直接前进到内核初始化，同时绕过平台初始化、引导管理器和O/S加载器。KSR可以有利地允许对更新的O/S的执行，而同时体验最低平台停机时间。

由于前述，并且根据过程400和500，来自新端点的检测到的错误将由新包括的O/S处理器而不是由与之前端点相关联的SMM处理器处理。这样的布置允许将新端点硬件错误处理引入平台，而不要求固件更新。此外，使用KSR或者其他类似技术，平台停机时间被显著地减少。

本文描述的每个功能组件可以如现有技术中已知的在计算机硬件(集成和/或离散电路组件)中、在程序代码中和/或在执行这样的程序代码的一个或多个计算系统中被实施。这样的计算系统可以包括一个或多个处理单元，该一个或多个处理单元执行被存储在存储器系统中的可执行程序代码。

前述附图代表根据一些实施例的用于描述过程的逻辑架构，并且实际试下你可以包括按照其他方式被布置的更多或者不同的组件。其他拓扑可以连通其他实施例被使用。此外，本文中描述的每个组件或者设备可以由经由任何数目的其他公开和/或私有网络通信的任何数目的设备实现。这样的计算设备中的两个或更多个计算设备可以被定位为相互远离，并且可以经由(多个)网络和/或专用链接的任何已知方式相互通信。每个组件或者设备可以包括适合于提供本文中描述的功能以及任何其他功能的任何数目的硬件和/或软件元素。

本文中描述的实施例仅出于例示的目的。本领域技术人员将认识到其他实施例可以利用对以上描述的实施例的修改或者变更而被实践。