基于PMI和SMI的调度执行框架中用于并发处理程序执行的方法和系统

摘要

一种方法和系统，其在基于处理器管理中断(PMI)和系统管理中断(SMI)的调度执行框架中使能并发事件处理程序的执行，以服务PMI或SMI事件。多个事件处理程序被加载到隐藏的存储器空间中，该隐藏的存储器空间对于多处理器计算机系统中的多个处理器的每个所支持的隐藏执行模式是可访问的，但对于这些处理器的其他操作模式是不可访问的。接着，响应于隐藏执行模式事件，事件处理程序被调度到两个或多个处理器，并且被并发地执行以服务该事件。各种实施例包括使用用于服务事件的单个事件处理程序、执行不同任务的多个事件处理程序以及并发执行单个任务的多个事件处理程序实例。本发明还提供了资源锁定机制以防止资源访问冲突。

说明书

技术领域

本发明一般地涉及计算机系统，更具体地说，涉及用于扩展处理器的系统管理模式(SMM)和其他类似的隐藏执行模式的功能的机制。

背景技术

自从Intel公司推出386SL处理器，作为对操作系统是隐藏的、执行由基本输入输出系统(BIOS)或固件加载的代码的执行模式，SMM已经可在IA32处理器上使用。SMM是被提供用来处理象电源管理、系统硬件控制或专有的原始设备制造商(OEM)设计的代码之类的系统范围的功能。因为操作系统(OS)和软件应用程序看不见该执行模式，甚至不能访问它，所以该执行模式被认为是“隐藏的”。

IA32处理器被使得能够经由SMI(系统管理中断)信号的激活而进入SMM。大致与SMI信号相似的被称为PMI(处理器管理中断)信号的类似信号被用于Itanium^TM类处理器。这里，为了简化，SMI和PMI信号有是都被称为xMI信号。还有一种使用APIC/XAPIC IA32存储器映射传递机制或IPF SAPIC传递机制的被称为“SMI”或“PMI”的中断消息类型。

到目前为止，利用了前面提到的Intel处理器的SMM能力的大多数BIOS实施方式简单地注册在BIOS的构建过程中被创建的单段代码，以支持使用该BIOS的系统所特有的特定功能或一组功能。该代码包括IA32中的16位组件和用于Itanium处理器的64位组件。用于这些遗留实施方式的单个代码段响应于所有的xMI激活，从开始运行到结束。

在当前的系统中没有提供用于注册或执行第三方SMM代码的功能，从而不允许对于SMM框架的扩展。例如，如果对于给定的平台，原始设备制造商(OEM)或BIOS供应商所提供的SMM代码提供的功能不足，则开发者或增值分销商(VAR)必须要么许可来自BIOS供应商或OEM的现存代码并尝试将他们自己的逻辑移植到他们的SMM代码的实施方式中，要么忍受该不足，这是因为目前的SMM框架没有提供用于修改或扩展由单个代码段提供的功能的替代方式。另外，当前在IA32处理器上的实施方式被限制于处理器的16位的模式，从而限制了代码的大小和对32位或64位软件引擎技术的可能的利用。并且，由于SMM经常用于芯片组工作区(例如，产生由于芯片组或CPU中的设计或制造缺陷而引起的错误和/或不可预测的结果的CPU或芯片组勘误表)，所以获得该关键软件更新的能力被BIOS供应商或OEM的单个BIOS实施方式所控制。

在现今的情况中，大多数芯片组供应商选择让操作系统供应商利用OS驱动程序集成这样的工作区。通常，SMM功能的BIOS更新的生效存在问题，并且因为OS已经通过它自己的驱动程序模型而具有硬件可扩展性机制，所以BIOS供应商和OEM很少被推动来提供这些类型的BIOS更新。

附图说明

结合附图，参考下面的详细描述，本发明的前述方面和伴随的许多优点更容易被意识到，同时也更好理解，其中：

图1是图示了本发明的示例性实施方式的示意图，该实施方式使得各种事件处理程序(event handler)能够被加载进隐藏的存储器空间并且响应于系统管理中断(SMI)或者处理器管理中断(PMI)(统称xMI)事件被并发地执行；

图2A包含流程图的第一部分，图示了根据图1的体系结构，当处理xMI事件时本发明所使用的逻辑；

图2B包含图2A的流程图的第二部分，图示了根据一个实施例的本发明所使用的逻辑，其中多个事件处理程序被调度(dispatch)到多个处理器，并且被检查以查看它们是否适合处理该xMI事件；

图2C包含图2A的流程图的第二部分，图示了根据一个实施例的本发明所使用的逻辑，其中多个事件处理程序被调度到多个处理器，并且被执行至完成以服务该xMI事件；

图3是一个示意图，图示了根据对应于图2A和图2C的流程图的实施例，对应于双处理器计算机系统中的多个事件处理程序的调度和执行的时间线；

图4A是一个示意图，图示了被存储在隐藏的存储器空间堆中的示例的第一组数据，该组数据在事件处理程序的调度和执行过程中被使用，包括用于资源锁定的信号量表；

图4B是一个示意图，图示了被存储在隐藏的存储器空间堆中的示例的第二组数据，该组数据对应于一种使用情况，在该情况中，多个处理程序实例被并发地执行以服务纠错码(ECC)存储器故障事件；

图5是一个示意图，图示了对应于当并发地服务ECC存储器故障事件时所使用的多个事件处理程序和事件处理程序实例的调度和执行的时间线；

图6是一个流程图，图示了当加载并启动系统管理模式(SMM)中心(Nub)的执行时，本发明所使用的逻辑，该SMM中心用于当处理器运行在SMM中时管理事件处理；

图7是图示了SMM中心的各种功能和服务组件的框图；

图8是一个流程图，图示了当注册事件处理程序时，本发明所使用的逻辑；

图9是一个流程图，图示了当注册和安装被存储在固件卷(firmwarevolume)中的事件处理程序时，本发明所使用的逻辑，所述固件卷在预引导处理过程中被扫描；

图10是一个流程图，图示了当注册用于服务Itanium^TM处理器的处理器管理中断(PMI)事件的事件处理程序时，本发明所执行的操作；

图11A包含图示了当处理PMI事件时本发明所使用的逻辑的流程图的第一部分；

图11B包含图11A的流程图的第二部分，图示了根据一个实施例的本发明所使用的逻辑，其中多个事件处理程序被调度到多个处理器，并且被检查以查看它们是否适合处理该PMI事件；

图11C包含图11A的流程图的第二部分，图示了根据一个实施例的本发明所使用的逻辑，其中多个事件处理程序被调度到多个处理器，并且被执行至完成以服务该PMI事件；以及

图12是适于实现本发明的多处理器计算机系统的示意图。

具体实施方式

在下面的描述中，阐述了很多具体细节，以提供对本发明的充分理解。但是，本领域的技术人员将认识到，没有这些具体细节中的一个或者多个，或者利用其他方法、组件等也可以实施本发明。在其他例子里，没有详细示出或描述公知的结构和操作，以免模糊了本发明的各种实施例的诸方面。

说明书中对“一个实施例”或“实施例”的引用是指与该实施例有关的具体特征、结构或特性至少被包括在本发明的一个实施例中。从而短语“在一个实施例中”或“在实施例中”在说明书不同地方的出现不一定都是指同一个实施例。此外，在一个或多个实施例中，特定的特征、结构或特性可以以任何适合的方式结合。

本发明提供了一种机制，使得以多个软件驱动程序形式的可执行内容能够被加载进Intel 32位系列微处理器(即，IA-32处理器)的系统管理模式(SMM)中，或者利用PMI信号激活的基于Itanium处理器的本地模式，并且在使用IA-32和基于Itanium的处理器的多处理器计算机系统上被并发的执行。在IA32 SMM中代码的执行状态是被SMI信号发起的，而在Itanium^TM处理器中该状态是被PMI信号的激活而发起的；简化起见，这些将被总地称为SMM。该机制允许可能由不同方编写的多个驱动程序被安装用于SMM操作。注册这些驱动程序的代理在EFI(可扩展固件接口)引导服务模式(即，操作系统启动前的模式)中运行，它由绑定了驱动程序的CPU特定(CPU-specific)组件和抽象xMI(PMI或者SMI)信号芯片组控制的平台组件组成。提供这些系列功能的API(应用程序接口)分别被称为SMM基本(SMM Base)协议和SMM访问(SMMAccess)协议。

在传统的SMM实施方式中，在交出控制权之前，SMM空间经常被平台软件/固件/BIOS经由硬件机制锁定；这为固件赋予了抽象这种绑定的安全和控制的能力。相反，通过本发明所提供的SMM访问协议的软件抽象使该设备的使用者不必知道和理解确切的硬件机制，因而使得驱动程序可在多个平台上移植。

如以下所进一步详细提供的，本发明包括下面的特征：供驱动程序使用的SMM中的库，其包括I/O访问抽象和存储器分配服务；用于与以非SMM模式执行的驱动程序和应用程序通信的方法；以给定频率周期性激活的可选择参数；在被加载进SMM的过程中验证驱动程序的方法；关闭注册权的能力；在多处理器环境中运行的能力，在所述多处理器环境中许多处理器接收xMI激活；以及最后，将遗留IA32 SMM代码当作一种特殊注册的事件处理程序来运行的能力。本系统的一个特点在于所有事件处理程序都在Itanium^TM本地处理器模式中运行，或者在IA32情况下，在调用事件处理程序前，框架将使处理器进入平展32位(flat 32)模式，同时以实模式(即，16位模式)运行可选择的(一个或多个)遗留IA32处理程序。

本发明的一个示例性实施方式的高级示图在图1中被描述。通过使用EFI框架使能了该实施方式，其为操作系统和平台固件之间的接口定义了新的模型。接口由包含有与平台相关的信息的数据表，加上操作系统及其加载程序可用的引导和运行时服务调用组成。同时，它们提供了用于引导操作系统和运行预引导应用程序的标准环境。

产生SMM可扩展性框架的过程在框10中被发起，其中，SMM可扩展性框架被实例化。这包括在框12中安装EFI SMM基本协议驱动程序。EFI SMM基本协议，即SMM_BASE，是CPU特定的协议，由CPU驱动程序或者另一能够抽象IA32或者Itanium处理器的ISA特定(ISA-specific)细节的代理来公布。一旦被安装，SMM_BASE在框14中公布SMM处理程序注册服务。该处理程序注册服务的公布使得遗留的和附加的驱动程序能够在框22中注册SMM事件处理程序，其中驱动程序被存储在各种存储设备上，包括EFI系统分区16和BIOS闪存芯片18，以及被存储在经由网络20被访问的存储设备上。除了这些类型的存储设备，驱动程序还可以被保存在其他的在其中实现本发明的计算机系统可访问的持久性存储设备上，包括基于主板的ROM、被包含在附加外设卡上的选项ROM(option-ROM)、本地硬盘以及CD ROM，它们共同由固件卷23描述。(注意，驱动程序6驻留在其上的远程存储设备和EFI系统分区16、BIOS闪存芯片18也可以包括固件卷。)如图1中描述的，这些驱动程序包括存储在EFI系统分区16中的遗留驱动程序1和附加(add-on)驱动程序2、存储在BIOS闪存芯片18上的附加驱动程序3、4和5以及通过网络20被访问的来自远程存储设备(例如，文件服务器)的附加驱动程序6。如这里用到的，术语“附加的”对应于没有配备计算机系统的原始设备制造商(OEM)提供的计算机系统原始固件的驱动程序和固件文件。

在可选择模式中，EFI SMM基本协议驱动程序可以扫描各种固件卷来识别被指定通过SMM而服务xMI事件的任何驱动程序。在一个实施例中，这些驱动程序通过它们的文件类型来识别，例如，作为例子的对应于附加驱动程序7的“DRIVER7.SMH”文件25。

在EFI SMM基本协议驱动程序的安装过程中，SMM中心24被加载进包括只用于SMM(SMM-only)存储器空间的SMRAM 26中。如以下被进一步详细解释的，当控制被转移给SMM时，SMM中心24负责协调所有活动，包括为事件处理程序提供SMM库28，该库包括PCI和I/O服务30、存储器分配服务32和配置表注册34。

SMM事件处理程序的注册是使处理程序能够执行被设计要执行的特定xMI事件服务功能的第一步。SMM事件处理程序包括一组代码(即，被编码的机器指令)，该代码当被系统处理器(CPU)执行时，以类似于中断服务例程的方式执行事件服务功能。通常，每个SMM事件处理程序将包含用于服务特定硬件组件或者子系统的代码，或者特定的一类硬件。例如，SMM事件处理程序可以被提供来服务系统实时时钟引起的错误、I/O端口错误、PCI设备错误等。通常，给定的驱动程序和SMM事件处理程序之间可以有某种对应。然而，这并不是严格的要求，因为处理程序可以包括一组从单个驱动程序文件或者对象中提取的功能块。

当用于遗留驱动程序1的事件处理程序被注册时，它被作为遗留处理程序36加载进SMRAM26中。遗留处理程序是一种事件处理程序，一般具有原始系统固件，并且代表处理xMI事件的传统机制。随着各附加SMM事件处理程序在框22中被注册，其被加载进SMRAM26的附加SMM事件处理程序部分38；一旦所有的附加事件处理程序都被加载，附加SMM事件处理程序部分28就包括一组如框42所描绘的对应于附加驱动程序2-7的事件处理程序。另外，随着各SMM事件处理程序被注册，其也可以在框44中选择性地被验证，以确保该事件处理程序对于用于计算机系统的具体的处理器和/或固件的使用是有效的。例如，可以使用一种实现数字签名和公钥的加密方法。随着SMM事件处理程序被注册，它们被加入存储在由SMM中心24维护的堆47中的处理程序列表46中。

一旦所有的遗留的和附加的SMM事件处理程序都已经被注册并被加载进SMRAM 26中，而且正确的配置数据(元数据)被写入SMM中心24，则SMRAM被锁定，阻止另外的SMM事件处理程序的注册。处理程序列表还被复制到处理程序队列48中，它可以被存储在堆47并且由SMM中心24访问或者直接存储在SMM中心24中。该系统现在已经准备好通过SMM处理各种xMI事件。

参考图1、图2A和2B，根据本发明的第一实施例，用IA32处理器处理xMI事件的过程如下进行：在框54中，xMI事件信号49被多处理器系统中的所有处理器接收，例如在图示的实施例中被处理器50(CPU1)和处理器51(CPU2)接收。一般，对于IA32处理器，xMI(SMI)事件可以是响应于系统芯片组上的引脚、总线周期类型或者处理器间中断(IPI)的激活而产生的，该激活引起IA32处理器进入SMM。对于Itanium^TM处理器，xMI(PMI)事件可以是响应于系统芯片组上的引脚、总线周期类型或者IPI的激活而产生的，该激活引起Itanium^TM处理器返回物理模式并执行向用于服务PMI事件的PAL(处理器抽象层)注册的代码。

响应于xMI事件，处理器50切换为SMM模式，并且将指令指针重定向到SMM中心24中的第一指令，SMM中心在这里开始执行，如框56所提供的。接着在框58中，每个处理器的机器状态通过各处理器内置的硬件注册处理所执行的操作和由SMM中心执行的控制操作而被存储。

接着，在判断框60中，判断是否存在已经被注册并加载的任何遗留16位处理程序。如果答案为“是”，则所有的处理器在框62中被同步，因此，除了所选择的处理器(例如，在预引导过程中被识别的第一处理器)之外的所有处理器都被停止，而在框64中，(一个或多个)16位处理程序被所选择的处理器执行。为了方便，在该示例中，假定处理器50是被选择的处理器。从而，所有16位处理程序将被处理器50执行，而任何其他处理器(例如，处理器51)将在这些16位处理程序的执行过程中被停止。接着，在框66中，被停止的处理器被释放，并且它们的机器执行模式被切换为平展32保护模式。该保护模式包括具有未分页32位、零基寻址的平展32位模式。

一旦执行模式切换被完成，则本地32位处理程序按照它们被存储在处理程序队列48中顺序被调度到下一个可用处理器，直至适当的事件处理程序被执行完毕以服务xMI事件，如图2B中的开始循环和结束循环框68和70提供的。在一个实施例中，事件处理程序被保存为从头到尾依次游历的链表，其中第一个事件处理程序被调度到第一处理器，另外的事件处理程序被调度到下一个可用的处理器，直到适当的事件处理程序已经在系统处理器中的一个上被执行。如果处理程序希望独占地执行，则它可以被标记为“单处理器(Single-processor)”；这是对于被优化用于单位处理器桌面的模块或遗留代码的情况。在后者的情况下，所有其他处理器将被保持在等待服务状态中，直到“单处理器”处理程序完成执行。当本地32位处理程序被调度时，在框72中，处理程序队列48被更新，这包括递增下一个调度的指针的位置以及识别事件处理程序被调度到哪个处理器。

各事件处理程序包含有被用来判断该处理程序是否是服务xMI事件的适当处理程序的前期部分代码。典型的这类判断包括询问对应于该事件处理程序的硬件组件、子系统等，以查看对象是否发生错误。在某些情况下，在本地事件处理程序的这种初始代码部分或其他代码部分的执行过程中，可能有多于一个处理器可以执行试图并发地访问同一系统资源的处理程序代码。例如，许多设备，包括内置外围设备和驱动器组件(例如声音芯片、视频芯片、网络接口芯片等)和附加外围设备(例如，声卡、视频卡、网络接口卡等)，工作在PCI(外围部件接口)体系结构下。在该体系结构下，可以通过发送请求字符串到PCI CF8h I/O(输入/输出)端口来询问PCI设备，该字符串包括与该设备和保存了该询问所关心的数据的寄存器有关的信息。典型的请求字符串具有“总线/设备/功能/寄存器”的格式，其中“总线”指明了设备所连接到的被列举的PCI总线，“/设备”指明了在PCI初始化过程中分配给设备的被列举的设备号，“/功能”指明了由设备所执行的PCI功能，“/寄存器”指明了存储关于提交该请求的事件处理程序可能感兴趣的设备的信息的寄存器，所述信息例如是错误代码。为了检查各种PCI请求，PCI控制器“监听”被提交到CF8h I/O端口的请求。因此，在向PCI控制器提交这样的请求后，PCI控制器和/或设备将检查以查看该请求是否涉及这些设备。请求所不涉及的设备简单地忽略该请求。相反，由字符串的“/设备”部分指明的设备通过将由“/功能/寄存器”寄存器所指明的值复制到PCI CFCh I/O端口来进行响应，这使得处理程序的询问代码能够读取被存储在所指明的寄存器中的值。

如果第一处理器几乎与第二处理器在相同的时间提交了请求，并且被写入CFC I/O端口的数据涉及错误的请求，则传统的PCI设备查询方案将出现一个潜在的问题。为了防止这种情况，本发明利用了资源锁定方案，其中，信号量55被用于保证给定的资源或一组资源(例如，I/O端口或一组I/O端口、存储器范围等)同时只能被一个事件处理程序访问。

一般，这种资源锁定方案涉及存储跟踪资源用途(例如，I/O端口、存储器)的信号量数据，以及在执行访问这些资源的处理程序代码部分之前检查该数据，其中，这些代码部分的执行被延迟，直到对应于该资源的(一个或多个)信号量被清除(指示这些资源可用)。因此，对应于被调度的事件处理程序的(一个或多个)资源信号量55在框74中被检查以证实对被那些事件处理程序所使用的相关I/O端口的访问是可用的。如判断框76所提供的，如果该检查结果是假(否)，则在框78中，事件处理程序执行预定的等待，并且逻辑循环返回判断框76。该等待/检查过程被重复，直到(一个或多个)资源信号量清除的检查结果是真(是)。

在证实与(一个或多个)资源信号量检查相对应的资源可用后，在框80中，对应的信号量数据被更新或改写，如图1中的信号量S₁、S₂、S₃和S_N所示。实际上，这通过指示资源对任何其他事件处理程序不可用而“锁定”了该资源。接着，根据判断框82，允许执行判断该事件处理程序是否是适合的事件处理程序的代码部分。如果该代码部分判断出该事件处理程序不是适合的处理程序(即，该代码部分判断出其对应的设备不引起该错误)，则它向SMM中心返回一个指示这种情况的代码，并且在框84中，SMM中心清除上面在框80中被改写或更新的(一个或多个)I/O信号量。接着逻辑进行到结束循环框70，在此，其循环回到起始循环框68，其中SMM中心将处理程序队列48中的下一个处理程序调度到下一个可用的处理器，并且对于该处理程序重复前述的操作。

如果事件处理程序是用于服务该xML事件的适合的处理程序，则判断框82的答案是“真”，并且逻辑进行到框86，在此执行处理程序代码直到完成，完成后处理程序代码向它于其上运行的处理器返回数据，以标识xMI事件是否被成功地处理。获知xML事件被处理后，在框88中，SMM中心清除对应于该处理程序的(一个或多个)资源信号量(即，上面在框80中的改写或更新)，并且在框90中，恢复机器状态并对所有的处理器执行适合的指令(对于IA32为RSM，在b0返回进入PAL PMI代码)，以将处理器返回到它们先前的执行模式。这完成了对xML事件的处理。核心需要保证所有的被登记并且已经按次序从它们的处理程序返回了的处理器在SMM中心中具有单一的点，以将机器控制返回各个处理器。

在执行处理程序之前，SMM中心需要在执行任何处理程序之前保存某些机器和平台资源。这样存储包括寄存器的内容，例如当前台代码在对0CF8h和0CFCh的PCI配置访问的中间时所发生的SMI或PMI的情况下的PCI配置空间地址端口0CF8h。这与SIO配置端口22h/23h、RTC端口70h/71h等的情况相同。平台特性“状态保存”模块将被用于该目的。

对于在IA32上支持32位处理程序和遗留16位处理程序的情况，SMM中心应在运行遗留处理程序之前进入保护模式，以保存数学协处理器和浮点的状态。因为在保护模式中比在实模式中存在更多的浮点(FP)状态，所以首先进入保护模式。

应该注意，图2B中所示的和上面涉及的全部过程所讨论的资源信号量检查的时序只是示例性的。除了I/O端口，信号量可以用于任何可以被两个或多个事件处理程序共享的资源。另外，资源信号量检查可以在除了示于图2B中的那些操作以外的操作过程中被执行。例如，信号量的使用可用应用于给定处理程序的任何I/O访问部分，其中在单个处理程序的执行过程中可以执行多于一个的信号量检查。

在前述的实施例中，各种事件处理程序被调度到下一个可用处理器，并且每个处理程序的早期部分被执行以判断其是否是对于该xML事件的适合的处理程序。该步骤被重复，直到识别出适合的事件处理程序，接着允许该处理程序一直执行完毕以服务该事件。在另一个实施例中，可以将多个事件处理程序执行完毕，以进行与该xMI事件相关的单个服务操作或一组相关的操作。对于该框架的逻辑示于图2A和图2C中，其中图2A的处理部分与上面所讨论的相同，并且在图2C中，与图2B中对应的框共享相同标号的各种操作框执行基本上类似的操作。因此，这些类似标号的框的细节将不被进一步讨论。

通常，每个事件处理程序将基于其在处理程序队列48中的顺序以类似于上述的方式被调度。接着处理程序被执行至完成，如框86A所示。在这种情况下，在执行该事件处理程序代码的过程中，可以以类似于上面所描述的方式进行信号量检查、等待和锁定，如框74A、76A、78A和80A所提供的。一旦处理程序代码已经执行完毕，则在框88中，所有对应的资源信号量被清除，并且在判断框92判断是否有任何其他处理程序要执行。如果有，则它们按照它们的队列顺序被调度。一旦所有的事件处理程序已经被调度，则判断框92的判断将为“真”，并且在框94中，系统将等待，直到所有的处理程序已经执行完毕。接着在框90中，机器状态和先前的执行模式被恢复，完成了xMI事件处理过程。

在图3中描述了根据本实施例的xMI事件的示例处理。响应于xMI事件49A，对应于前面的图2A的流程图部分，使用CPU50和51执行操作。接着，处理程序的调度开始，其中处理程序2被调度到处理器50，处理程序3被调度到处理器51。在处理程序2的执行过程中，生成信号量S₂以锁定由该处理程序使用的资源。类似地，生成信号量S₃以锁定由处理程序3使用的资源。处理程序2和处理程序3两者都被执行到完成，并且它们各自的信号量被清除。

在完成处理程序3之后，处理程序4被调度到处理器51，它立即生成信号量S₄。之后不久，处理程序5被调度到处理器50。处理程序5需要访问被信号量S₄锁定的共享资源。因此，处理程序5必须等待该资源变为可用，如等待段96所指示的。处理程序4的共享资源的使用完成后，它清除信号量S₄，从而释放对应的资源以由处理程序5使用。处理程序5之后立即生成信号量Sx以锁定该资源。处理程序4和处理程序5都继续执行到完成，之后随后的处理程序基于该处理程序在处理程序队列48中的顺序被调度到下一个可用的处理器。

最终，最后两个处理程序M和N被调度。在处理程序N的情况下，处理程序包括在不同的时间点访问不同资源的代码部分。因此，生成两个信号量，即S_N1和S_N2。处理程序M和N都继续执行直到完成，处理程序M首先完成。接着，处理器50等待，直到处理程序N已经完成执行，之后，在框90中，处理器被恢复到先前的机器状态和执行模式。

与前面的示例相对应的存储在堆47中的示例性数据示于图4A中。堆47一般将包括SMRAM 26的保留部分。如上面所讨论的，它将包括与处理程序列表46、处理器队列48和信号量55相关的数据。在被图示的实施例中，处理程序列表包括用于标识每个处理程序98的处理程序标识符98，以及对应的起始地址100，该地址规定用于该处理程序的代码的第一指令。处理程序队列48包括表，该表包括三列：处理程序标识符102、处理程序状态104和CPU标识符106，CPU标识符106标识了处理程序正在或曾在哪个CPU上被执行。

通常，信号量55可以以各种数据结构被存储。一般地，信号量将包括资源值对，从该资源值对，处理程序可以判断给定的资源是否被另一个处理程序锁定。在示于图4A中的实施例中，信号量55包括信号量表108，该表包括各种I/O端口和它们对应的可用性，这些可用性是用布尔信号量来标记的，其包括“0”以指示资源可用(即，信号量被清除)和“1”以指示资源被锁定。在一个实施例中，使用了I/O端口“位映射表(bitmap)”，其中该位映射表包括对应于各个I/O端口的一位存储单元的序列，利用各个一位存储单元，从各I/O端口的基址和每个各自的位对应的从该基址的偏移量，得到各I/O端口的标识。被设置的位指示对应的资源被锁定，而被清除的位指示对应的资源是被释放了的。因此，信号量表108指示出I/O端口70h、71h、CF8h、CFCh、D06h和DA1h被锁定。

在另一个实施例中，与支持并发访问的资源相对应的处理程序(或其代码部分)被调度到不同的处理器，并且被允许并发地执行。对应于该实施例的示例使用情况的时间线被示于图5中，而被存储在堆47A中的对应的数据被示于图4B中。在该示例中，对应于纠错码(ECC)事件的xMI信号被发送到四个处理器50、51、52和53中的每一个。用于处理xMI事件的初始操作以类似于上面参照图2A所讨论的方式被执行。随后，处理程序H2被调度到处理器50，而处理程序H3、H4和H5分别被调度到处理器51、52和53。在这种情况下，假定处理程序H2是用于处理ECC事件的适合的处理程序，而处理程序H3、H4和H5是不适合的处理程序。从而，这些不适合的处理程序的早期部分被允许执行，并向SMM中心24返回信息，指示出它们是不适合用于该事件的处理程序。

在一个实施例中，并发类型列110被添加到处理程序列表46中，以指示处理程序是否支持并发执行。可选地，该信息可以由处理程序代码的早期部分来判断。基于前面的方案之一，应该认识到，处理程序H2所支持的资源(即，在ECC事件处理程序情况下的存储器)可以支持并发访问。因此，处理程序H2的早期代码部分更新了处理程序列表46和处理程序队列48，使得将要被调度给处理器51、52和53的接下来的代码部分是服务ECC事件的处理程序H2的核心部分或者是处理程序H2的附加实例。这些处理程序或者处理程序核心部分被描述为处理程序H2A、H2C和H2D，在处理程序H3、H5和H4完成后，它们分别被调度到处理器51、53和52。

ECC事件由提供了纠错码支持的系统存储器来发布。基本上，ECC事件是在存储器检测到潜在的错误状态时被发布的。在一个实施例中，对这样的事件的响应是使处理器读取被存储在由ECC代码标识的一个或多个存储器块中的数据，并且写回这些存储器块。在本示例中，将假定存储器的ECC能力相当粗略，通过该能力，存储器只能检测整个DIMM(双列直插存储器模块)的错误，并且其中在系统中安装了四个64兆(M)的DIMM(总共256M)。此外，假定与从64M到128M的存储器块相对应的第二DIMM产生了ECC事件。

根据前面的情况，处理程序H2或者SMM库28中的代码确定出因为有64M存储器要纠正(即，读取和写回以实现“基于软件”的存储器整理(scrub))，并且有四个处理器用于执行该任务，所以每个处理器被分配来纠正16M存储器。在一个实施例中，资源锁定数据(例如，信号量)可以被存储在信号量表55中，以标识哪些存储器块被分配给哪个处理器来纠正，如图4B所示。如图4B所图示的，有四组信号量112、114、116和118，每个包含与16个1M存储器块相对应的数据，其中每组信号量锁定它对应的存储器块，使得那些存储器块只可以被由信号量所标识的处理器访问。例如，信号量112锁定从64M到80M的存储器块，使得它们只可以被处理器50(CPU1)访问，信号量114锁定从80M到96M的存储器块，使得它们只可以被处理器51(CPU2)访问，等等。除了所示的基于信号量的锁定方案，也可以使用其他资源锁定方案，例如标识由各处理器锁定的存储器的范围。

每个处理程序或处理程序核心部分H2、H2A、H2B和H2C继续执行，直到它们对应的存储器块已经被纠正。对应的处理程序完成之后，处理器50、51、52和53中的每个等待，直到执行了所有剩余的处理程序代码，之后，在框90B中，所有的处理器被恢复到它们各自的机器状态和先前的执行模式。

为了使用事件处理程序，必须首先安装EFI SMM基本协议处理程序。参照图6，用于IA32处理器的EFI SMM基本协议驱动程序(SMM_BASE)通过如下过程被安装。首先，在框120中，SMM_BASE::Initialize服务被调用。这是利用DXE(驱动程序执行环境)引导服务驱动程序来实现的，所述DXE引导服务驱动程序加载并输出该构造器。

响应于实例化驱动程序，当在保护模式中操作时，用于SMM中心24的起始代码在CPU缺省SMRAM地址处(0x3000段，偏移0x8000)被加载进SMRAM。然后，在框122中，处理器模式在执行地址0x38000p处转移到实模式。接着，在框124中，用于平台的SMRAM实施方式的可允许的地址范围被确定和分配。如下面所描述的，通过利用SMM_BASE::Initialize驱动程序，调用SMM_ACCESS::GetCapabilities和SMM_ACCESS::AcquireSmramRange方法可以得到该信息。如果该驱动程序不存在，则缺省策略将会是具有缺省大小(对于IA32A段是128千字节，对于Itanium^TM是256千字节)的对于IA32处理器的0xA000段(或者对于顶段(T-SEG)芯片组实施方式的存储器顶端(top-of-memeory)，以及对于高段(H-SEG)芯片组实施方式的接近4GB)和对于Itanium^TM处理器的运行时数据。

地址范围已经被分配之后，在框126中，SMM_ACCESS::Open服务被调用，并且对于IA32，在框128中，用于SMRAM的初始地址从缺省CPU地址(0x38000p)被重定位至平台地址。被重定位的代码将包括一个实模式组件和一个保护模式组件。实模式组件将包括进入SMRAM重定位地址的SMM入口(SMMEntry)。在框130中，该代码在必要的时候被执行以进行所有遗留服务，并将处理器切换为保护模式操作。然后，在框132中，控制权被交给SMM核心。

如上面所讨论的，当处理器运行在SMM中时，SMM中心24负责协调各活动。图7中以图形的方式描述了SMM中心24的一个实施例提供的各种功能和服务。如功能块134、136和138所提供的，这些功能和服务包括同步用于多处理器配置的所有处理器、保存机器状态，包括需要时的浮点寄存器，以及刷新高速缓存。SMM中心还提供了将处理器模式由实模式切换到保护模式的模式切换功能140，如上面参考框130所讨论的。模式切换功能130还使能了处理器的内部高速缓存。如功能块142、144和146所描述的，SMM中心24所提供的其他功能包括在SMRAM 26中建立调用栈、维护处理程序列表46以及维护处理程序队列48。

SMM中心24通过SMM库28为各种事件处理程序提供一系列服务，包括PCI和I/O服务30、存储器分配服务32和配置表注册服务34。另外，SMM中心24还提供在xMI事件被服务之后被执行的若干功能。如果计算机系统实现了多处理器配置，则这些处理器由功能148释放。功能150还原(一个或多个)处理器的机器状态，包括需要时的浮点寄存器。最后，功能152被用来在系统中所有处理器上执行RMS指令。

如上面所讨论的，本发明提供了两种用于加载事件处理程序的机制：(1)基于驱动程序的安装；和(2)从固件卷中自主加载。

对于基于驱动程序的安装，SMM_BASE协议将通过被DXE调度器加载的驱动程序被安装。SMM_BASE协议被安装之后，它公布一个使能事件处理程序被注册和加载的接口。用于注册的协议由EFI1.0说明书描述，它定义了一种在EFI环境中公布新的可调用的接口的机制。SMM_BASE协议公布基本上包括用EFI核心揭示在SMM-CIS(描述在预引导空间中抽象这种注册机制的API集或者EFI2.0协议的EFI2.0文档或者SMM“组件接口规范”)中描述的API。EFI核心维护GUID/接口指针对的协议数据库。GUID包括接口的128位全球唯一标识符(ID)。

通过该机制，当SMM_BASE协议被安装时，希望安装事件处理程序的任何驱动程序都能使用EFI1.0的标准机制来发现SMM_BASE协议实例(通过核心服务“定位协议(LocateProtocol)”)或者向要被警告的EFI核心注册一个通知，其中在一个实施例中，所述事件处理程序是某些代码，可以是IA32或者Itanium^TM指令集中的PE32+二进制代码，或者是用于IA32的遗留16位处理程序。在任一情况下，一旦SMM_BASE协议被安装，各种驱动程序可以使接口指针指向SMM_BASE实例(通过EFI1.0“处理协议(HandleProtocol)服务”)，然后调用SMM_BASE::Register服务。使用SMM_BASE服务的驱动程序所用的二进制代码能从它自己的驱动程序映像、来自磁盘或者网络的文件来确定。文件可以在固件卷中或者在FAT磁盘分区上。

通过SMM_BASE::Register服务，事件处理程序的注册更容易。该服务包括允许事件处理程序注册的DXE引导服务驱动程序。参考图8，注册事件处理程序的过程在框154中开始，其中注册事件处理程序的请求通过SMM_BASE协议驱动程序从另一个引导服务驱动程序或者应用程序(即，驱动程序1-7)被接收。作为响应，在框156中，利用IPI或者SMM_CONTROL协议产生SMI。利用ESP存储器栈指针，自变量在存储器栈被传送，似乎是调用另一处理程序。处理程序可以用C和所生成的映像PE32+来编写。接着，在框158中进行存储器重定位，并且ST(来自EFI1.0的系统表)指针被指向SMST(系统管理系统表)的指针替换。

接着，在框160中，使用SMM_ACCESS::Open服务，SMRAM被打开，它通过SMM_ACCESS协议被访问。下面的附录中给出了SMM_ACCESS协议的进一步的细节。SMM_ACCESS::Open服务抽象了从基于非SMRAM的代码的使能SMRAM可见性的存储器控制器的编程。这使得SMM_BASE协议能将代码，例如SMM中心，复制和安装进SMRAM中。

接着，在判断框162中，判断是否有足够的SMRAM可用来保存事件处理程序例程。如果没有足够的SMRAM存储器空间可用，则逻辑进行到框164，在其中警告调用者。作为选项，响应于被警告，调用者可以用SMM_ACCESS::GetCapabilities和SMM_ACCESS::AcquireSmramRang方法来获得SMRAM中额外的存储器空间，如框166所提供的。如果没有足够的SMRAM存储器空间可用，则在错误返回框168中，通过调用SMM_ACCESS::Close方法，SMRAM被关闭，并且向调用者返回一个错误代码。

如果判断出有足够的SMRAM存储器空间可用，则在框170中，用于处理程度的SMRAM映像的存储器缓冲区被分配。在判断框172中，判断分配是否成功。如果分配不成功，则逻辑进行到错误返回框168。如果分配成功，则在框174中，事件处理程序的映像被加载进入先前被分配的SMRAM存储器空间。然后在判断框176中，判断映像是否是好的。如果不是，则逻辑进行到错误返回框168。如果映像被证实是好的，则在框178中，SMM中心24通过将新的事件处理程序加入它的处理程序列表46中来注册该新的事件处理程序，并且在返回框180中，SMRAM被关闭，过程返回到调用者。

从固件卷中自主加载事件处理程序的机制并不依赖于使另一个驱动程序使用SMM_BASE接口和SMM_BASE::Register服务。不是使驱动程序发起注册过程，而是在预引导过程中被具体化(materialize)的各种固件卷(FV)被扫描来寻找适当的驱动程序文件，所述驱动程序文件包含可以被SMM_BASE驱动程序加载的事件处理程序。

固件卷是固件文件的集合。除了在固件文件头中的其他元数据，固件卷中的每一个固件文件都具有类型(TYPE)字段。一个被称为“SmmHandler”的新类型被包括在固件文件头内的类型字段的列举中。理解了固件卷和固件文件系统，实现和公布SMM_BASE接口的所有驱动程序都将知道ReadFile(读取文件)服务和这种新类型。

参考图9，该机制开始于框182，其中SMM_BASE驱动程序搜索预引导过程中在系统中被具体化的所有固件卷。如开始循环框和结束循环框184和186定义的，下面的逻辑被应用于这些固件卷中的每一个。在判断框188中，判断固件卷是否包括任何与固件文件系统一致的固件文件。如果答案是“否”，则逻辑循环返回以检测下一个固件卷。如果找到了一个或者多个一致的固件文件，则利用下面的过程，这些文件中每一个都被检测，如开始循环框和结束循环框190和192所定义的。在判断框194中，SMM_BASE驱动检测当前文件的文件类型，以确定它是否是“SMMHandle”文件。如果不是，逻辑循环返回，以开始下一个文件的检测。如果文件类型是“SMMHandler”，则在框196中，SMM_BASE驱动程序分解固件文件节(section)；节是固件文件内的内部打包机制。如框198所提供的，如果一个节包含有PE32+可执行映像，或者，如果SMM_BASE的实施方式是在支持加载遗留16位处理程序的IA32系统上的，则SMM_BASE驱动程序将安装包含在该节中的遗留16位处理程序或者可执行映像，其中PE32+是微软在可移动映像(Portable Image)规范(于“www.microsoft.com/hwdev/efi”张贴在互联网上)中描述的可移动可执行映像类型，它与实现SMM_BASE的机器类型是相同的(例如，计算机系统是IA32机器并且处理程序是IA32 PE32+映像)。然后，逻辑以类似方式继续处理随后的固件文件和固件卷。

一般，当从固件文件中自主加载处理程序时，SMM_BASE将假定以上提出的用于SMM_BASE::Register的自变量具有缺省值，例如浮点保存和MakeFirst＝FALSE

一般，处理IA32处理器的SMI和Itanium类处理器的PMI包括类似的过程。然而，也存在着一些区别。二者之间一个主要的区别是Itanium^TM处理器没有基于它的xMI信号的激活而进入的专用CPU模式。而是Itanium^TM处理器仅仅提供一种将处理程序绑定进处理器的机制以处理PMI事件。这种绑定通过进入处理器抽象层(PAL)的注册调用来起作用，其中PAL是Intel为所有Itanium平台构建器提供的固件，包括Itanium体系结构的一部分，其用来提供相容的固件接口以抽象处理器实施方式特定(processor implementation-specific)的特征。

图10和图11示出了用Itanium^TM处理器处理PMI事件和注册处理程序的细节。注册过程在框200中开始，其中EFI 2.0 SMM_BASE驱动程序加载64位版本的SMM中心。一旦加载了SMM中心，则在框202中，EFI用在存储器中被加载的中心的映像调用PAL_PMI_ENTRYPOINT服务，这创建了进入中心代码的入口点。

在初始化过程中，PAL公布一组称为PAL_PROCS的服务。然后，在框204中，这些PAL_PROCS中的一个被用于向适当的处理器特定(processor-specific)的资源注册入口点，所述资源例如处理器模型特定(processor’s model-specific)的寄存器(MSR)。由此，入口点的注册创建了处理器和经由SMM中心被访问的一组PMI事件处理程序之间的绑定。

参考图11A，PMI事件处理然后可以如下进行。在框206中，PAL_PMI事件处理程序接收PMI事件。然后，在框208中，PAL_PMI事件处理程序调用SMM中心24，使得被选择执行可扩展PMI事件处理的处理器的处理被引导至在上面被注册的中心入口点。接下来，在框210中，所有的处理器被集中(rendezvous)，由此，除了所选择的处理器(例如，在预引导过程中被识别的第一处理器)之外的所有处理器被停止，而被选择的处理器中的SMM中心被执行。然后，在框212中，各CPU的机器状态被CPU硬件和SMM中心24两者保存。

在一个实施例中，根据图11B，一旦处理器的机器状态已经被保存，则本地64位处理程序按照处理程序队列的顺序被调度到下一个可用的处理器，直到适当的事件处理程序被执行完毕以服务PMI事件，如开始循环框和结束循环框68A和70A所提供的。在该实施例中，在框68A、70A、72A、74A、76A、78A、80A、82A、84A、88A和90A中所执行的操作反映了由示于图2B中的框中的共用了相同的基础参考标号的框所执行的操作，除了在64位处理程序替代32位处理程序被调度和执行的情况以外。举例来说，在以类似于上面参照图2B中的框72所讨论的更新处理程序队列48的方式，在每个处理程序的调度之后，在框72A中，处理程序队列48被更新。在确认PMI事件被处理后，在框90A中，SMM中心恢复机器状态并执行对于处理器/所有处理器的适当的指令(IA32上的RSM和对于IPF的在b0的返回)，以将(一个或多个)处理器返回它/它们的先前的处理模式。

在示于图11C中的另一个实施例中，多个事件处理程序被调度到可用处理器，并通过类似于上面参照图2C所讨论的方式被执行至完成，其中类似的操作在具有共同基础参考标号的框中执行。除了这些实施例，PMI事件处理还可以包括以类似于上面参照图4B和图5所描述的方式，调度和执行并发事件处理程序。

框架还规定了在SMM模式中的时候的服务中断。除了上述响应于SMI或PMI激活而以同步方式调度处理程序外，还提供了处理程序的周期性激活的机制。这部分地通过软件xMI定时器服务处理程序被支持。该服务处理程序可以编程平台资源，来以某个给定的时间间隔造成周期性的SMI/PMI的激活。相关联的处理程序还可以向其他希望成为监听者或代理以响应这些周期性事件的对等处理程序公布该能力。这样，来自软件xMI定时服务处理程序的基于GUID的服务可以被其他处理程序使用，并且允许它们在时间被分片的基础上被调用。该框架还提供了用于取消周期性激活的服务。

这种周期性服务能力的一种示例的使用涉及软件存储器整理处理程序。存储器整理经常被用来纠正存储器错误，并且涉及读取存储器和写回存储器。通常，该任务是通过系统的芯片组(例如，存储器控制器)和/或由存储器组件(例如，DRAM DIMM)提供的内置功能而自动处理的。但是，在某些情况中，存储器控制器或内置功能不够完善，该任务必须由软件通过服务处理程序来执行。例如，假定给定的芯片组只能够在DRAM存储体级别报告SBE(单比特错误)，并且该存储体大小可达到1G字节。如果SMI或PMI处理程序在单个激活过程中试图软件整理存储器，则对十亿个存储器单元的每个的读/写访问将具有长期延迟，特别是因为该访问需要向真实的DRAM写回。前台操作系统控制的这种损耗将很可能对该操作系统产生不利的影响，至少引起明显的系统“冻结”并且可能使OS崩溃。如此，一种解决方法是让存储器整理处理程序使用上面所描述的本发明的并行调度机制以进行分段的并发存储器整理，其中处理程序被分阶段地进行，使得每个阶段期间只处理存储器整理的一个部分(例如10MB或者100MB的块)。例如，在一个实施例中，处理程序将调用xMI定时器处理程序来以连续的间隔请求激活(例如，100毫秒、1秒等)，其中在每个间隔期间，预定的存储器块被整理，直到所有的存储器已经被整理。

用于实现本发明的示例机器

参考图12，图示了结合实践本发明而适于使用的一般的传统多处理器计算机系统300。多处理器计算机系统300包括处理器机箱302，其中安装有软盘驱动器304、硬盘驱动器306、其上组装了包括多个处理器(描述为处理器309A和309B)的适当的集成电路的主板308、一个或多个存储器模块310以及以及电源(未示出)，这是本领域的普通技术人员一般公知的。主板308还包括本地固件存储设备311(例如，闪烁可擦除只读存储器(flash EPROM))，其上存储了BIOS固件基本部分。为了方便对经由网络314从远程固件存储设备312取得的BIOS固件的部分进行访问，个人计算机300包括网络接口卡316或者集成在主板208中的等效电路。网络314可以包括局域网(LAN)、广域网(WAN)和/或者互联网，并且可以提供个人计算机300和远程固件存储设备312之间的有线或者无线连接。

该机器还包括显示器318，用于显示由个人计算机运行的软件程序所产生的以及在POST(上电自检)和其他方式的固件加载/执行的过程中通常会显示的图像和文本。鼠标320(或者其他点选设备)被连接至处理器机箱302背面的串口(或总线端口)，来自鼠标320的信号被传输至主板308以控制显示器上的光标，以及选择通过在个人计算机上执行的软件程序而显示在显示器318上的文本、菜单项和图像成分。另外，键盘322被耦和至主板，用于文本和命令的使用户输入，它们影响在个人计算机上执行的软件程序的运行。

个人计算机300也可选择地包括光盘只读存储(CD-ROM)驱动器324，CD-ROM盘可以插入其中，使得盘上的可执行文件和数据能够被读出，以传输至个人计算机300的存储器和/或者硬盘驱动器306上的存储装置里。如果基本BIOS固件被保存在可重写设备上，例如flash EPROM，用于更新BIOS固件基本部分的机器指令可以被存储在CD-ROM盘上或者软盘上，由计算机的处理器读出并处理，以重写存储在flash EPROM上的BIOS固件。可更新的BIOS固件也可以经由网络314加载。

虽然已经结合了实践本发明及其修改的优选方式描述了本发明，但是本领域的普通技术人员应当理解，可以在所附权利要求范围内，对本发明作出许多其他的修改。所以，本发明的范围并不意味着以任何方式由以上的描述来限定，而是完全根据所附的权利要求来决定。

附录

用于IA32的SMM_ACCESS协议

SMM_ACCESS协议被芯片组驱动程序，即82815芯片组的MCH驱动程序公布。该驱动程序抽象了存储器控制器开、关和锁定SMRAM的能力。它还描述了用于SMRAM的可能区域，包括在0xA000处的遗留帧缓冲区的位置以及物理DRAM顶部附近的存储器(T-SEG)。

SMM_ACCESS协议构造器应在ExitBootServices上注册一个回调(call-back)。SMM_ACCESS协议提供了以下功能：SMM_ACCESS::Open

该服务抽象了从基于非SMRAM代码的使能SMRAM可见性的存储器控制器编程。这使得SMM_BASE协议能将代码，例如SMM中心，复制和安装进SMRAM中。

SMM_ACCESS::Close

该服务抽象了从非SMRAM代码的禁止SMRAM可见性的存储器控制器编程。这使得SMM_BASE协议能阻止其他预引导代理查看基于SMRAM的内容。

SMM_ACCESS::Lock

该服务抽象了保证SMRAM安全的硬件能力，以使以后的尝试不能成功开启该区域的可见性。

SMM_ACCESS::GetCapabilities

该调用为调用者提供了可被用作SMRAM的可用存储器区域，其中调用者很可能是SMM_BASE驱动程序。这是公布信息的只读报告服务。影响对SMRAM中这种存储的解码的芯片组编程以及对该区域的声明，通过获得所指的区域而生效(见下一服务)。

SMM_ACCESS::AcquireSmramRange

该服务提供了两种类型的功能。第一个是它是对EFI2.0引导服务调用者可见的资源管理数据库。平台中可用的SMRAM的可能区域被GetCapabilities的服务SMRAM映射公布，并且区域是可以通过该服务被请求使能的映射。该请求至少包括对驱动程序所有权的更新，但是该调用还需要实际上使请求方式有效的芯片组编程。

SMM_ACCESS::ReleaseSmramRange

该服务提供了两种类型的功能。该请求至少包括释放区域所有权的驱动程序的更新，但是该调用还需要实际上使请求方式无效的芯片组编程。