CN115495278A - 异常修复方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种异常修复方法、设备及存储介质。在本申请实施例中，响应于UCE内存被消费触发的中断请求，获取被中断任务的异常上下文；针对任务中断时处理器处于内核态的情况，可根据异常上下文，判定被中断任务是否为可修复异常；之后，对于可修复异常的被中断任务，可根据预先注册的异常修复表，修复异常上下文；并根据修复后的上下文，恢复处理器执行的内核态任务。由于处理器执行的内核态任务是基于修复后的上下文恢复的，而不是任务被中断时的上下文，因此，可降低再次出现内核消费UCE内存的概率，进而降低由于内核消费UCE内存导致系统宕机的概率。

Description

异常修复方法、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种异常修复方法、设备及存储介质。

背景技术

内存是计算设备的重要组成部分之一。内存故障是硬件系统最常见的故障，极大地影响了系统的可靠性，可用性和可服务性（Reliability, Availability andServiceability，RAS）。内存控制器可以采用错误校验与校正(Error Checking andCorrection，ECC)等纠错算法进行纠错。

ECC纠错算法为实际的内存数据生成单比特错误纠正和双比特错误检测（Single-bit Error Correction and Double-bit Error Detection，SECDED）码，并将SECDED码存储在内存中。内存控制器利用SECDED可以纠正单比特错误，并检测两比特错误。单比特错误被称为可纠正错误（Corrected Error，CE），两比特错误被称为不可纠正错误（UncorrectedCorrectable Error，UCE）。

在传统方案中，发生UCE的内存地址（简称UCE内存）被处理器的用户态的进程消费，可终止映射发生UCE的内存页（简称UCE内存页）的进程，并解除用户态中该UCE内存页的地址映射，以避免将来使用该UCE内存，从而隔离用户态消费的UCE错误。然而，一旦UCE内存被内核消费，导致系统立马宕机。

发明内容

本申请的多个方面提供一种异常修复方法、设备及存储介质，用以降低内核态消费UCE导致宕机的概率。

本申请实施例提供一种异常恢复方法，包括：

响应于中断请求，获取被中断任务的异常上下文；所述中断请求为不可纠正错误UCE内存被消费所触发的；

根据所述异常上下文，确定任务中断时处理器的状态；

在所述任务中断时处理器的状态为内核态的情况下，根据所述异常上下文，确定所述被中断任务的异常性质；

在所述异常性质为可修复异常的情况下，根据预先注册的异常修复表，修复所述异常上下文，以得到修复后的上下文；

根据所述修复后的上下文，恢复所述处理器执行的内核态任务。

本申请实施例还提供一种计算设备，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；所述存储器包括内存；所述处理器运行有内核；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行上述异常修复方法中的步骤。

本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述异常修复方法中的步骤。

在本申请实施例中，响应于UCE内存被消费触发的中断请求，获取被中断任务的异常上下文；根据异常上下文可判定任务中断时处理器是否处于内核态；以及针对任务中断时处理器处于内核态的情况，根据异常上下文，判定被中断任务是否为可修复异常；之后，对于可修复异常的被中断任务，可根据预先注册的异常修复表，修复异常上下文；并根据修复后的上下文，恢复处理器执行的内核态任务。由于处理器执行的内核态任务是基于修复后的上下文恢复的，而非任务中断时的上下文，可降低再次出现内核消费UCE内存的概率，进而降低由于内核消费UCE内存导致系统宕机的概率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为传统方案提供的固件优先模式进行异常修复的过程示意图；

图2为本申请实施例提供的异常修复方法的流程示意图；

图3和图4为本申请实施例提供的异常修复方法的具体实施过程示意图；

图5a为传统方案提供的固件优先模式进行异常修复的流程示意图；

图5b为本申请实施例提供的固件优先模式进行异常修复的流程示意图；

图6为本申请实施例提供的计算设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在云计算数据中心中，服务器宕机率一直是衡量数据中心的RAS的一个关键指标，也是满足云计算终端用户的服务水平协议（Service Level Agreement ，SLA）的首要问题。

系统非预期宕机影响服务的正常运行。在计算集群和数据中心，单台物理机部署的硬件和软件密度越来越高，每台物理机可部署上百个虚拟机（Virtual Machine，VM）和上千个容器实例。虽然硬件故障很少发生，但任何服务器宕机都可能导致巨大的成本损失。

内存故障是导致服务器故障的主要原因。双倍速率同步动态随机存储器（DoubleData Rate Dynamic Random Access Memory，简称DDR SDRAM或DRAM）凭借高密度、简单架构、低延迟和低功耗等优势，成为当今几乎所有应用中广泛使用的主存储器，遍布高性能计算（High Performance Computing，HPC）和移动应用。由于DRAM的掉电易失性，内存故障往往意味着数据丢失和不可恢复。因此，如何解决内存故障变得至关重要。

内存系统中流行的RAS方案之一是ECC纠错算法进行内存数据修复。ECC纠错算法为实际的内存数据生成SECDED码，并将SECDED码存储在内存中。内存控制器利用SECDED可以纠正单比特错误，并检测两比特错误。单比特错误被称为CE，两比特错误被称为UCE。调研报告显示，服务器约50%的宕机来自内存UCE相关错误。

在X86平台，处理器支持机器检测体系（Machine-Check Architecture，MCA）机制，检测、记录和上报机器的硬件故障信息，从而为系统恢复和隔离内存错误提供了可能。在X86平台中，中央处理器（Central Processing Unit，CPU）以可纠正的机器检测中断(Corrected Machine Check Interrupt，CMCI)上报 CE，以机器检测异常（Machine-CheckException，MCE）上报UCE。内核通过响应CMCI，记录CE。对于UCE错误，内核首先对发生UCE的内存页（简称为UCE内存页）标记特定的标签，如“有毒”（“poison”）标签，终止映射该UCE内存页的进程，并解除虚拟地址与该UCE内存页的物理地址之间的映射关系，从而避免后续进程使用该UCE内存页，从而隔离部分UCE错误。调研报告显示，通过支持MCA，服务器宕机从100%显著降低到50%，虚拟机迁移成功率从0%提高到40%。

先进精简指令集（Reduced Instruction Set Compute，RISC）处理器（AdvancedRISC Machines，ARM）平台，即ARM平台，也提供了错误检测、记录和上报的能力。RAS是ARMv8.2及之后架构的CPU的强制扩展。如果UCE内存页被用户态的进程消费，内核对UCE内存页标记“poison”标签，终止映射该UCE内存页的进程，并解除虚拟地址与该UCE内存页的物理地址之间的映射关系，从而避免后续进程使用该UCE内存页，从而隔离用户态消费的UCE。然而，一旦UCE内存被内核消费，导致系统立马宕机。调研报告显示，在内存UCE相关的错误中，30%的错误为内核态消费UCE错误。在ARM平台，Linux主线缺少解决内核态消费UCE错误导致宕机的技术方案。

在ARM架构下，硬件的错误处理通常为固件优先（Firmware First）模式，硬件的错误中断先由固件（Firmware）响应，固件收集硬件的错误信息，然后通知内核（Kernel），将控制权交给内核，内核按照错误类型分别处理。

在先进平台错误接口（Advanced Platform Error Interfaces，APEI）规范中，硬件错误源表（Hardware Error Source Table，HEST）描述了错误源的信息。错误源信息可包括：通知类型、上报的错误格式以及错误数据的物理地址等。通知类型是指固件通知内核的机制类型，可包括：系统错误中断（System Error Interrupt，SEI）、同步外部中止（Synchronous External Abort，SEA）、软件委托异常（Software Delegated Exception，SDE）等。其中，SEI、IRQ及FRQ均为异步中断。不同通知类型对应不同的系统事件。不同系统事件对应注册有不同的事件处理函数（Handler）。

内核的通用硬件错误源（Generic Hardware Error Source，GHES）驱动根据HEST表中的通知类型，注册事件处理函数（Handler），如图1中的SEA处理函数、软件委托异常接口（Software Delegated Exception Interface，SDEI）处理函数及IRQ处理函数等。具体地，如图1所示，对于一个内存UCE错误，RAS的工作流程如下：

1、被标记为“poison”的UCE内存页的数据被消费，CPU（图1中未示出）产生同步异常中断（Synchronous External Abort，SEA）；并把SEA请求发送给固件（Firmware）。

2、固件处理SEA请求后，并路由到独立管理模式（Standalone Management Mode，SMM）。

具体地，固件中的安全部分管理器（Secure Partion Manager）可调用SMM的管理模式（Management Mode，MM）错误处理函数（MM Error Handler），以路由到处于EL0模式的SMM。

3、SMM根据DDR控制器中的错误记录寄存器（Error Record Resiger）记录的错误信息，按照APEI规范，将APEI规范所需信息写入 HEST表指定的内存缓冲区，并返回EL3。

具体地，SMM中RAS驱动根据硬件的错误记录寄存器记录的错误信息，调用常见平台错误记录（Common Platform Error Record，CPER）生成库（CPER Generation Lib），生成CPER条目，即通用错误数据条目（Common Error Data Entry），并将CPER条目写入HEST。其中，错误记录寄存器记录的错误信息可包括：错误类型、错误数据的地址、错误号（number）及ECC标志（ECC Symbol）等。错误类型可包括：CE和UCE等。

4、处于EL3模式的固件分发软件委托异常接口（Software Delegated ExceptionInterface，SDEI）事件到内核（Kernel）注册的SEDI处理函数。

具体地，固件中的SDEI分发器根据预先配置的中断类型与事件号之间的对应关系，确定SDEI事件的目标事件号；并根据SDEI事件的目标事件号，确定目标事件号对应的SDEI处理函数。进一步，SDEI分发器可将SDEI事件分发至SDEI处理函数。

SDEI是固件到内核的通知机制，而CPER是固件到内核传递错误信息的载体。SDEI和CPER都是通过HEST承载。 HEST表支持多种错误源类型，其中RAS错误信息通过通用硬件错误源 (Generic Hardware Error Source，GHES) V2结构来表示。

5、内核中的GHES驱动可查询ACPI表从HEST指定的物理地址获取CPER条目。

6、 GHES驱动可调用SDEI处理函数解析CPER条目，获取CPER条目记录的错误信息；并根据错误信息，处理错误。

具体地，若UCE内存被用户态进程消费，内核中的GHES驱动将标记为“poison”的内存页隔离，并解除UCE内存页的页表映射。若标记为“poison”的内存页未被修改过，则利用缺页异常重新从磁盘中加载数据，用户态进程继续运行。若标记为“poison”的内存页被修改过，即该内存页为脏页，则停止映射到标记为“poison”的内存页的进程。由于进程的用户地址空间由页表提供隔离。对于用户态进程消费UCE 的情况，利用SEA同步异常的特性，内核通过将错误的影响范围控制到进程粒度，从而实现的UCE错误的隔离和恢复，避免了系统宕机。

然而，内核地址空间被所有进程共享，当UCE内存被内核消费，无法通过停止进程的方式，隔离错误。若UCE内存被内核消费，则立马宕机，避免错误传播。

7、GHES驱动将处理后的RAS事件通过串口输出控制台，同时GHES驱动还可触发插桩（Tracepoint）事件。Rasdeamon工具可监听插桩事件，并实现RAS事件的持久化。

需要说明的是，上述ELn（n=0，1，2，..，3）表示不同的异常等级（Exception Level，EL）。异常等级确定了处理器当前的特权级别，ELn的n数值越大特权级别越高。

EL0是指用户特权，用于运行普通用户程序。EL1是指系统特权，通常运行操作系统内核。EL2用于运行虚拟化扩展的虚拟机监测程序（如Hypervisor等）。EL3运行安全状态（Secure State）中的安全监测器（Secure Monitor），如固件等。

安全状态（Security state）为ARM体系结构提供运行环境，包括：安全状态（Secure State）和非安全状态（Non-secure State）。每种安全状态有独立的物理地址空间范围。处理器运行于安全状态时，处理器可以访问安全状态和非安全状态的物理地址空间范围。处理器运行于非安全状态时，处理器只能访问非安全状态的物理地址空间范围。

其中，EL0可存在安全状态和非安全状态。EL3只能存在安全状态。EL1和EL2只能存在于非安全状态。固件可处于EL3模式。内核可处于EL1或EL2模式。处于高EL模式的组件可访问低EL模式的组件的内存空间，而处于低EL模式的组件无访问高EL模式的组件的内存空间的权限。例如，图1中处于EL3模式的固件，可访问处于EL1或EL2模式的内核的内存空间，而处于EL1或EL2模式的内核无访问处于EL3模式的固件的内存空间的权限。

根据上述传统RAS方案的工作流程可知在UCE内存被内核消费的情况下，系统立马宕机，避免错误传播。但是，在实际应用中，并非所有内核消费UCE内存的情况，都需要宕机。例如，对于write(2)及futex(2) 等系统调用，内核可通过copy_from_user函数或get_user函数等Uaccess接口，从用户地址空间复制数据到内核地址空间，如果复制的数据包含UCE错误，按照可移植操作系统接口（Portable Operating System Interface，POSIX）标准，需要返回错误码（如EFAULT等）或已复制数据的长度，无需宕机，从而避免内核态消费UCE内存导致的宕机。

为了解决上述技术问题，在本申请一些实施例中，响应于UCE内存被消费触发的中断请求，获取被中断任务的异常上下文；根据异常上下文可判定任务中断时处理器是否处于内核态；以及针对任务中断时处理器处于内核态的情况，根据异常上下文，判定被中断任务是否为可修复异常；之后，对于可修复异常的被中断任务，可根据预先注册的异常修复表，修复异常上下文；并根据修复后的上下文，恢复处理器执行的内核态任务。由于处理器执行的内核态任务是基于修复后的上下文恢复的，而非任务中断时的上下文，可降低再次出现内核消费UCE内存的概率，进而降低由于内核消费UCE内存导致系统宕机的概率。

以下结合附图，详细说明本申请各实施例提供的技术方案。

应注意到：相同的标号在下面的附图以及实施例中表示同一物体，因此，一旦某一物体在一个附图或实施例中被定义，则在随后的附图和实施例中不需要对其进行进一步讨论。

图2为本申请实施例提供的异常处理方法的流程示意图。如图2所示，该方法主要包括：

201、响应于中断请求，获取被中断任务的异常上下文；该中断请求为UCE内存被消费所触发的。

202、根据异常上下文，确定任务中断时处理器的状态。

203、在任务中断时处理器的状态为内核态的情况下，根据异常上下文，确定被中断任务的异常性质。

204、在被中断任务的异常性质为可修复异常的情况下，根据预先注册的异常修复表，修复异常上下文，以得到修复后的上下文。

205、根据修复后的上下文，恢复所述处理器执行的内核态任务。

在本申请实施例中，中断请求为硬件中断请求。硬件可以是产生中断的各类硬件设备，又称作中断源（Interrupt Source），可以包括内存、网卡、硬盘以及看门狗（WatchDog）等。当硬件发生故障时可以触发CPU生成中断请求。此时不论CPU处于什么状态，都会停止工作响应，即中断当前执行任务，并处理该中断请求。

对于内存故障而言，在发生UCE的内存（简称为UCE内存）被进程消费时，CPU会产生中断请求。本申请实施例的中断请求，特指UCE内存被消费触发的中断请求。UCE内存被消费触发的中断请求，可能为用户态进程消费UCE内存触发的中断请求，也可能为内核态进程消费UCE内存触发的中断请求。对于用户态进程消费UCE内存的情况，可将用户态消费的UCE所在的内存页（即UCE内存页）隔离，并解除该UCE内存页的页表映射，之后，停止映射到UCE内存页的进程，通过将错误的影响范围控制到进程粒度，从而实现的UCE错误的隔离和恢复，避免了系统宕机。

对于内核态进程消费UCE内存的情况，传统方案会导致系统宕机。在本申请实施例中，考虑到实际应用中，并非所有内核态进程消费UCE内存的情况都需要宕机，提供一种新的异常处理方式。下面结合上述图2提供的方法实施例进行说明。

由于在实际应用中并非所有内核态进程消费UCE内存都需要宕机，而被中断任务的异常上下文（Context）可提供判定中断发生时处理器是处于用户态还是内核态的判定依据，被中断任务的异常上下文还可提供判定内核态进程消费UCE内存的被中断任务是否属于不需要系统宕机的情况的判定依据。基于此，在本实施例步骤201中，可响应于中断请求，获取被中断任务的异常上下文。该中断请求为UCE内存被消费所触发的。

其中，异常上下文为系统异常中断时产生的相关数据。通常，异常上下文可包括：系统异常中断时处理器中寄存器的状态信息。处理器中寄存器包括：通用寄存器、处理器状态（Processor State，PSTATE）寄存器、程序计数器（Program Counter，PC）寄存器、处于各异常等级（ELn）的异常综合征寄存器（Exception Syndrome Register，ESR）即ESR-ELn寄存器、处于各异常等级（ELn）的故障虚拟地址寄存器（Fault Address Register，FAR）即FAR-ELn寄存器、处于各异常等级（ELn）的异常链接寄存器 (Exception Link Register，ELR)即ELR-ELn、处于各异常等级（ELn）的故障虚拟地址寄存器（Fault Address Register，FAR）即FAR-ELn寄存器，以及保存的程序状态寄存器（Saved Program Status Register，SPSR）等，但不限于此。

上述通用寄存器为在基本指令集处理指令时，使用的通用寄存器。它包括32个通用寄存器R0-R31。这些寄存器可以作为32个64位寄存器X0-X30，或32个32位寄存器W0-W31。

PSTATE寄存器表示当前处理器的状态。

PC寄存器通常用来指向当前运行指令的下一条指令的地址（即当前待执行指令的地址），用于控制程序中指令的运行顺序。

ESR_ELn包含的异常信息，用以异常处理程序确定异常原因。仅针对同步异常SEA和异步异常SEI进行更新。

ELR_ELn包含异常返回地址。当处理器发生异常时，返回地址将保存在异常级别对应的ELR中。例如，当处理器将异常处理交给EL1处理时，会将异常返回地址保存在ELR_EL1中。在异常返回时，PC寄存器恢复到存储在ELR中的地址。例如，从EL1返回时，PC寄存器将恢复到ELR_EL1中存储的地址。

FAR-ELn用于表示异常的虚拟地址。

SPSR可保存处理器的备份程序。当异常将要发生时，处理器会把PSTATE寄存器的值暂时保存到SPSR里；当异常处理完成并返回时，再把SPSR的值恢复到PSTATE寄存器。

由于用户态进程消费UCE内存，可通过停止消费UCE内存的用户态进程进行异常修复，导致系统宕机的概率极低。因此，本申请实施例重点解决内核态消费UCE内存导致的系统宕机问题。由于被中断任务的异常上下文包括处理器的状态，即PSTATE寄存器表示处理器的状态。处理器的状态包括：异常中断时处理器处于内核态，还是用户态。基于此，在获取被中断任务的异常上下文之后，在步骤202中，可根据异常上下文，确定任务中断时处理器的状态。

具体地，可从被中断任务的异常上下文中，获取PSTATE寄存器的状态信息；PSTATE寄存器的状态信息表征任务中断时处理器的状态。进一步，可根据PSTATE寄存器的状态信息，确定任务中断时处理器的状态。确切地说，是确定任务中断时处理器是处于内核态，还是用户态。若任务中断时处理器处于用户态，说明任务中断时为用户态消费UCE内存，可采用上述图1提供的用户态消费UCE内存进行异常修复方式进行处理。

若任务中断时处理器处于内核态，说明任务中断时为内核态消费UCE内存。针对内核态消费UCE内存的情况，在本实施例中需要判定此次内核态消费UCE内存是否触发系统宕机。基于此，在步骤203中，可根据被中断任务的异常上下文，确定被中断任务的异常性质。被中断任务的异常性质包括：可修复异常和不可修复异常。

具体地，可从被中断任务的异常上下文中，获取ESR_EL3的状态信息；并从ESR_EL3的状态信息中，获取错误码（Error Code）、同步错误类型（Synchronous Error Type，SET）及数据错误状态码（Data Fault Status Code，DFSC）。错误码用于表征处理器的异常原因，通过错误码识别导致系统异常的原因。处理器的异常原因包括：复位异常、中断异常（IRQ或FIR）、预取指令中止异常、未定义指令异常、软件中断指令异常及数据中止（Data Abort）异常等。

SET用于表征同步错误类型，可包括：可修复状态（Recoverable state，UER）、不可控状态（Uncontainable，UC）及可重新开始的状态（Restartable State，UEO）。

DFSC用于给出数据中止（Data Abort）的相关信息，包括但不局限于：触发数据中止的机制等。触发数据中止的机制可为：SEA、SEI、IRQ或FIR等。

在本申请实施例中，UCE内存消费为内存数据访问异常，即数据中止异常（DataAbort）。又由于异步异常通知机制会导致UCE传播，异步异常修复无意义。因此，在处理器处于内核态消费UCE内存的情况下，可修复的被中断任务需要满足以下条件：错误码表征数据中止、同步错误类型（SET）为可修复类型（如UER或UEO）且数据错误状态码表征同步中止（SEA）。

相应地，可从ESR的状态信息中，获取错误码、同步错误类型及数据错误状态码；若错误码表征数据中止、同步错误类型为可修复类型且数据错误状态码表征同步中止（如表征SEA等），确定被中断任务的异常性质为可修复异常。

若错误码、同步错误类型及数据错误状态码中，存在不满足上述可修复的被中断任务需要满足的条件的情况，则确定被中断任务的异常性质为不可修复异常。不可修复异常，可导致系统宕机。因此，本申请实施例主要对可修复异常进行避免宕机处理。

进一步，对于可修复异常，在步骤204中，可根据预先注册的异常修复表（Exception Table，Extable），修复异常上下文，以得到修改后的上下文。

异常修复表配置了异常修复方式，因此，可根据异常修复表中配置的异常修复方式，修改异常上下文，得到修改后的上下文。

在一些实施例中，可响应于针对从用户地址空间复制数据到内核地址空间的接口的调用，在内核中注册异常修复表。从用户地址空间复制数据到内核地址空间的接口可为Uaccess接口。其中，异常修复表的格式可实现为四元组（insn，fixup，type，data)。Insn表示当前指令的地址，即任务中断时当前执行的指令的地址。 fixup表示异常修复指令（fixup section）的地址。type表示当前执行的指令的修复类型。不同的修复类型对应不同的异常修复函数。在本申请实施例中，当前执行的指令可实现为从用户地址空间复制数据到内核地址空间的指令，如copy_from_user函数或get_user函数包含的ldtrb、ldtrh、ldtr指令等。data表示异常修复的数据，即执行异常修复指令需要返回的数据。对于从用户地址空间复制数据到内核地址空间的接口（如Uaccess接口等），异常修复的数据可以为已复制的数据长度或错误码（EFAULT）等。

基于上述异常修复表，在一些实施例中，步骤204可实现为：根据异常上下文中PC寄存器的状态信息，在预先注册的异常修复表中进行查找，以确定记录的当前指令的地址（即insn的值）与PC寄存器的状态信息相同的目标异常修复表；进一步，可从目标异常修复表中，获取异常修复指令的地址；之后，可将保存的PC寄存器的状态信息修改为异常修复指令的地址。这样，由于PC寄存器指向异常修复指令的地址，因此后续在恢复内核态任务之后，内核可执行异常修复指令，而跳过任务中断时执行的当前指令，从而可避免再次消费上述当前指令所消费的UCE内存，降低由于内核消费UCE内存发生系统宕机的概率。

在一些实施例中，按照POSIX标准，执行从用户地址空间复制数据到内核地址空间的接口指令，需要返回错误码（EFAULT）或已复制数据的长度。相应地，上述步骤204还可包括：从目标异常修复表中，获取用于异常修改的目标数据，即上述Extable的data数据。目标数据可为错误码（如EFAULT等）或已复制数据的长度。进一步，可利用异常修复函数将保存的异常上下文中的通用寄存器的状态信息，修改为目标数据。在实际应用中，哪些通用寄存器用于返回数据是默认的。因此，在修改通用寄存器时，确切地是，可以异常修复函数，将保存的异常上下文中默认的用于数据返回的通用寄存器的状态信息，修复为通用寄存器。

在一些实施例中，可在完成异常上下文的修复之后，将异常上下文的错误级别从致命错误（Fatal）修改为可修复错误（Recoverable）；并解除发生UCE的内存页的地址映射。这样，后续内核态消费进程不再映射到该UCE内存页，可防止UCE传播。

在完成异常上下文的修复之后，在步骤205中，可根据修改后的上下文，恢复处理器执行的内核态任务。可选地，可根据修复后的上下文，恢复处理器的上下文，可恢复被中断请求抢占的任务现场，即恢复处理器执行的内核态任务。具体地，可根据PC寄存器存储的异常修复指令的地址信息，执行异常修复指令；并通过系统调用返回目标数据。

在本实施例中，可响应于UCE内存被消费触发的中断请求，获取被中断任务的异常上下文；根据异常上下文可判定任务中断时处理器是否处于内核态；以及针对任务中断时处理器处于内核态的情况，根据异常上下文，判定被中断任务是否为可修复异常；之后，对于可修复异常的被中断任务，可根据预先注册的异常修复表，修复异常上下文；并根据修复后的上下文，恢复处理器执行的内核态任务。由于处理器执行的内核态任务是基于修复后的上下文恢复的，因此，处理器执行的内核态任务可绕过任务中断时的上下文，可降低再次出现内核消费UCE内存的概率，进而降低由于内核消费UCE内存导致系统宕机的概率。

本申请实施例提供的异常修复方法可以应用于ARM架构中，例如，应用于ARM64架构。也可以应用于非ARM架构的系统中，只要可以运行安全监测软件或者可以产生类似于安全中断的系统，都可以利用本申请的思想来实现异常修复。

处理器运行有处于安全状态的固件和非安装状态的内核。APEI规范定义了两种模型处理RAS错误，分别是固件优先（Firmware First）模式和操作系统本地（OperatingSystem Native，OS Native）处理模式。其中，操作系统本地处理模式，也可称为内核优先模式。本申请实施例提供的异常修复方法，适用于固件优先模式，也同样适用于OS Native模式。下面结合具体实施例，对本申请实施例提供的固件优先模式进行异常修复的过程，以及，OS Native模式进行异常修复的过程分别进行说明。

图3和图4为本申请实施例提供的固件优先模式下的异常修复过程示意图。如图3和图4所示，在固件优先模式下，处理器可响应于UCE内存被消费的操作，产生中断请求，即图3中的硬件中断。进一步，可将中断请求发送给处于安全状态的固件（对应图3步骤3和图4步骤7）。具体地，处理器可响应于中断请求，将处理器切换至安全状态；并将中断请求发送给处于安全状态的固件。

例如，处理器可在内核执行从用户地址空间复制数据到内核地址空间的指令消费UCE内存时，产生中断请求。该中断请求可为SEA。其中，相应地，如图3所示，进程可使用系统调用，切换至内核态。可选地，处理器进程可使用write(2)或futex(2)等系统调用，切换至内核态（对应图3步骤1）。

进一步，内核可通过从用户地址空间复制数据到内核地址空间的接口指令，从用户地址空间复制数据到内核地址空间（对应图3步骤2中消费“有毒”数据）。其中，“有毒”数据是指UCE内存存储数据。其中，从用户地址空间复制数据到内核地址空间的接口指令可为copy_from_user函数或get_user函数包含的ldtrb、ldtrh或ldtr等指令。

若复制的数据为UCE内存存储的数据，即标记为“poison”（“有毒”）的数据，处理器确定内核态消费UCE内存，可产生中断请求，即SEA（对应图3步骤3和图4步骤7）。处理器响应中断请求，可将处理器切换至安全状态。具体地，处理器可响应中断请求，中断进程上下文，即图3步骤4和图4步骤8“任务被抢占”。进一步，将处理器切换至安全状态。此时内核陷入处于EL3模式的固件。

相应地，固件可获取被中断任务的异常上下文，并将异常上下文保存至安全状态中（对应图3步骤5和图4中步骤9“保存异常上下文”）。

基于上述图1提供的传统RAS方案中的固件优先模式可知：硬件的错误中断先由固件（Firmware）响应，固件收集硬件的错误信息，然后通知内核将控制权交给内核，内核按照错误类型分别处理。具体地，固件处理SEA请求后，并分发至处理函数。该处理函数部署于RAS驱动中。RAS驱动进行中断处理。具体地，RAS驱动可根据硬件的错误记录寄存器记录的错误信息，调用通用CPER生成库，生成CPER条目，并将CPER条目写入HEST（对应图4中步骤11“中断处理”）。进一步，RAS驱动将SDEI事件分发至固件中的SDEI分发器。

基于图1和图4可知，固件优先模式，异常上下文保存在安全状态，而由处于非安全状态的内核进行错误处理的。处于非安全状态的内核无访问安全状态的内存的权限，因此，处于非安全状态的内核无法获取安全状态保存的异常上下文。因此，在传统方案中内核缺少判断异常是否可以恢复的依据。

为了解决上述问题，在本申请实施例中，结合图3和图4，处于安全状态的固件可将被中断任务的异常上下文提供给处于非安全状态的内核（对应图3步骤6和7、图4步骤13和14）。这样，内核可获取被中断任务的异常上下文。

在本申请实施例中，不限定固件将被中断任务的异常上下文提供给内核的具体实施方式。在一些实施例中，固件可准备分发给内核的上下文（对应图3步骤6和图4步骤13“准备分发上下文”）。由于固件处于EL3模式，因此，固件保存的异常上下文为安全状态的上下文，可定义为安全上下文。相应地，异常上下文可包括：ESR_EL3的状态信息及FAR_EL3的状态信息。由于内核处于EL1或EL2模式，因此，内核可访问ESR_EL1和FAR_EL1，无权限访问ESR_EL3和FAR_EL3。基于此，固件可将ESR_EL1的第一状态信息和FAR_EL1的第一状态信息保存到安全状态。之后，固件可将ESR_EL1的第一状态信息修改为ESR_EL3的状态信息，以得到ESR_EL1的第二状态信息；并将FAR_EL1的第一状态信息修改为FAR_EL3的状态信息，以得到ESR_EL1的第二状态信息。这样，内核可通过ESR_EL1的第二状态信息和ESR_EL1的第二状态信息，获取ESR_EL3的状态信息和FAR_EL3的状态信息。

其中，上述ESR_EL1的第一状态信息是指被中断任务的异常上下文中ESR_EL1的状态信息；ESR_EL1的第二状态信息是指ESR_EL1的信息覆盖后存储的ESR_EL3的状态信息。相应地，FAR_EL1的第一状态信息是指被中断任务的异常上下文中FAR_EL1的状态信息；FAR_EL1的第二状态信息是指FAR_EL1的信息覆盖后存储的FAR_EL3的状态信息。

在本申请实施例中，被中断任务的上下文除了包括：ESR_EL3的状态信息和FAR_EL3的状态信息之外的其它寄存器的状态信息。其它寄存器可包括：通用寄存器及目标寄存器。目标寄存器可包括：PC寄存器、PSTATE寄存器及ELR-EL3寄存器等。

相应地，固件可响应于中断请求，通过SDEI事件将处理器切换至非安全状态，以将控制权转移至内核（对应图3中步骤7和图4步骤14“分发SDEI事件”）。固件可以SDEI事件的形式，将其它寄存器的状态信息提供给内核。

在本实施例中，通用寄存器可根据功能分为第一通用寄存器、第二通用寄存器及第三通用寄存器。第一通用寄存器是指用于传输SDEI处理函数（Handler）的入口参数的通用寄存器。第一通用寄存器的数量与SDEI处理函数的入口参数的数量相等。第二通用寄存器是指设定的用于任务处理的通用寄存器。第三寄存器是指除第一通用寄存器和第二通用寄存器之外的其它通用寄存器。

基于上述第一通用寄存器、第二通用寄存器及第三通用寄存器，上述图3中步骤7具体可实现为：固件可通过第一通用寄存器将内核预先注册的SDEI处理函数的入口参数，提供给内核；并将第二通用寄存器的状态信息传递给内核；以及，将目标寄存器的状态信息写入第三通用寄存器，并通过第三通用寄存器将目标寄存器的状态信息传递给内核。

在本申请实施例中，如图4所示，内核在启动过程中，可从HEST中获取HEST包含的事件号；并调用SDEI注册函数为HEST包含的事件号分别注册对应的SDEI处理函数。其中，SDEI注册函数可为SEDI_EVENT_REGISTER。具体地，内核可从GHES通知结构体（Notification Structure）中获取事件号；并调用SDEI注册函数为该事件号注册SDEI处理函数；并注册SDEI处理函数成功之后，返回成功标识（对应图4中步骤2“成功”）。进一步，可调用SDEI事件使能（SDEI_EVENT_ENABLE）函数，使能该SDEI事件，并在该SDEI处理函数使能之后，返回成功标识（对应图4中步骤4“成功”）。进一步，可调用使能中断处理函数，使能中断处理；并在中断处理使能之后，返回成功标识（对应图4中步骤6“1”）。至此，SDEI处理函数注册成功。其中，SDEI处理函数的入口参数可包括：事件号（Event_num）、入口地址（Entry_point）、内核提供的缓存地址（arg）及亲和性（flags和affinity）等。其中，事件号为SDEI事件的标识，是由HEST表提供的。入口地址为内核提供给固件分发SDEI事件的入口地址，可为“sdei_asm_entry_trampoline”。内核提供的缓存地址，用于固件分发SDEI事件时，提供非安全状态的上下文，包括但不局限于： PC寄存器的状态信息、PSTATE寄存器的状态信息和通用寄存器的状态信息。亲和性表示进程要在某个给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性。基于上述SDEI处理函数的入口参数的数量，因此，第一通用寄存器的数量为4个。例如，可采用通用寄存器X0-X3将SDEI处理函数的入口参数传递给内核。

对于固件来说，可根据预先配置的中断类型与事件号之间的对应关系，确定SDEI事件的目标事件号。在本申请实施例中，中断类型可为SEA。进一步，固件可根据SDEI事件的目标事件号，确定目标事件号对应的SDEI处理函数，并确定目标事件号对应的SDEI处理函数的入口参数。其中，目标事件号对应的SDEI处理函数即为上述通过第一通用寄存器传递入口参数的SDEI处理函数。

对于内核可通过通用寄存器，获取除ESR_EL3的状态信息和FAR_EL3的状态信息之外的其它寄存器的状态信息。

可选地，固件可将ELR_EL3的状态信息，修改为内核预先注册的SDEI处理函数的入口地址。相应地，上述通过SDEI事件将处理器从安全状态切换至所述非安全状态，可实现为：根据ELR_EL3的状态信息，执行异常返回（Exception Return，ERET）指令，以通过SDEI处理函数的入口地址将处理器从安全状态切换至非安全状态。相应地，内核可利用SDEI处理函数将通用寄存器的状态信息，保存至非安全状态的缓存中，以获取第二通用寄存器的状态信息和目标寄存器的状态信息。由于第一通用寄存器的状态信息仍然保存在安全状态。因此，内核可通过调用SDEI接口，从固件保存的异常上下文中，获取第一通用寄存器的状态信息。至此，内核获取了被中断任务的异常上下文；进一步，内核可将被中断任务的异常上下文，保存至非安全状态的缓存中，得到非安全状态下的异常上下文。内核可根据非安全状态保存的异常上下文，判断被中断任务是否可修复（对应图3中步骤9和图4步骤15）。可选地，内核GHES驱动中的SDEI处理函数可根据非安全状态保存的异常上下文，判断被中断任务是否可修复。在一些实施例中，SDEI处理函数可调用其它处理函数，并跳转至其它处理函数（对应图3中步骤8）；由其它处理函数根据非安全状态保存的异常上下文，判断被中断任务是否可修复。

其中，根据非安全状态保存的异常上下文，判断被中断任务是否可修复可实现为：根据非安全状态保存的异常上下文，确定任务中断时的处理器状态。具体地，内核可从异常上下文中，获取所述PSTATE寄存器的状态信息；PSTATE寄存器的状态信息表征任务中断时处理器的状态。因此，可根据PSTATE寄存器的状态信息，确定任务中断时处理器的状态。若PSTATE寄存器的状态信息表征任务中断时，处理器处于内核态，则确定任务中断时处理器的状态为内核态。相应地，若PSTATE寄存器的状态信息表征任务中断时，处理器处于用户态，则确定任务中断时处理器的状态为用户态。

进一步，对于任务中断时处理器处于内核态的实施例，内核还可根据非安全状态的异常上下文，确定被中断任务的异常性质，即可根据非安全状态的异常上下文，判断被中断任务是否可修复（对应图3中步骤9和图4中步骤15“判断是否可修复”）。关于根据非安全状态的异常上下文，确定被中断任务的异常性质的具体实施方式，可参见上述实施例的相关内容，在此不再赘述。

对于被中断任务的异常性质为可修复异常的实施例，内核可根据预先注册的异常修复版，修复异常上下文（对应图3中步骤10-12及图4中步骤16“修复上下文”）。可选地，如图3所示，内核可根据PC寄存器的第一状态信息在预先注册的异常修复表中进行查找，以确定记录的当前指令的地址与PC寄存器的第一状态信息相同的目标异常修复表（对应图3中步骤10“确定目标异常修复表”）；进一步，可从目标异常修复表中，获取异常修复指令的地址；并将非安全状态保存的PC寄存器的第一状态信息修改为异常修复指令的地址。

具体地，内核可从目标异常修复表中，获取当前指令的类型；并根据当前指令的类型，通过内核预先注册的SDEI处理函数调用当前指令的类型适配的异常修复函数（FixupHandler）；之后，可利用异常修复函数将非安全状态保存的PC寄存器的第一状态信息，修改为异常修复指令的地址（对应图3中步骤11“调整至异常修复函数”和步骤12“修改PC寄存器”）。这样，由于PC寄存器指向异常修复指令的地址，因此后续在恢复内核态任务之后，内核可执行异常修复指令，而跳过任务中断时执行的当前指令，从而可避免再次消费上述当前指令所消费的UCE内存，降低由于内核消费UCE内存发生系统宕机的概率。

在一些实施例中，按照POSIX标准，执行从用户地址空间复制数据到内核地址空间的接口指令，需要返回错误码（EFAULT）或已复制数据的长度。相应地，上述步骤204还可包括：内核从目标异常修复表中，获取用于异常修改的目标数据，即上述Extable的data数据。目标数据可为错误码（如EFAULT等）或已复制数据的长度。进一步，可利用异常修复函数将保存的异常上下文中的通用寄存器的状态信息，修改为目标数据（对应图3中步骤12“修改通用寄存器”）。在修改完通用寄存器的状态信息和PC寄存器的状态信息之后，内核得到修改后的上下文，并可将该修改后的上下文保存至非安全状态的缓存中。

之后，如图4步骤17所示，内核可处理SDEI事件。具体地，内核可将异常上下文的错误级别从致命错误（Fatal）修改为可修复错误（Recoverable）；并解除发生UCE的内存页的地址映射。此处发生UCE的内存页为上述内核态消费的UCE所在的内存页。具体地，可跳转至GHES驱动，并通过内核中的GHES驱动解除UCE内存页的地址映射（对应图3中步骤13“跳转至GHES驱动”和“解除UCE内存页映射”）。这样，后续内核态消费进程不再映射到该UCE内存页，可防止UCE传播。

由于固件优先模式下，被中断任务的异常上下文时由固件保存在安全状态的，而内核对异常上下文的修改是在非安全状态的。因此，固件恢复内核态任务的上下文时，使用的仍然是安全状态保存的异常上下文。安全状态保存的异常上下文中PC寄存器依然指向任务中断时执行的指令（即当前指令）的地址，因此，固件恢复内核态任务，内核依然指向PC寄存器存储的当前指令的地址，依然会导致UCE内存被内核消费，产生SEA，导致异常的重复复发。如此不断循环触发异常，最终导致系统不可用而宕机。

在本申请实施例中，为了解决该问题，提供将内核修改的保存至非安全状态的修复后的上下文，同步至安全状态的固件。具体地，内核可通过安全监测调用（SecureMonitor Call，SMC）指令将处理器从内核跳转至固件。可选地，SMC指令可为图3中步骤15和图4步骤18中的“SDEI_EVENT_COMPLETE”指令。固件可从非安全状态获取非安全状态保存的修复后的上下文，并根据安全状态保存的ESR_EL1寄存器的第一状态信息和FAR_EL1寄存器的第一状态信息，恢复ESR_EL1寄存器和FAR_EL1寄存器，以得到安全状态中的修复后的上下文，从而将保存在非安全状态的修复后的上下文，同步至安全状态的固件（对应图3中步骤16和图4步骤19中的“同步修复后的上下文”）。

可选地，如图4步骤20和步骤21所示，固件中的SDEI分发器可在修复后的上下文同步至固件之后，返回值RAS驱动。RAS驱动向EL3返回错误处理完成。

进一步，固件可根据安全状态中修改后的上下文，恢复处理器执行的内核态任务（对应图3中步骤17-20及图4步骤21-23）。具体地，固件可根据安全状态中修复后的上下文，恢复处理器的上下文，以恢复内核态任务（图3中步骤17和图4步骤22 “恢复处理器上下文”以及图3中步骤18和图4步骤23“恢复内核态任务”）。其中，根据安全状态中修复后的上下文，恢复处理器的上下文具体可实现为：根据安全状态中修复后的上下文记录的各寄存器的状态信息，将处理器的寄存器赋值为修复后的上下文中相应寄存器的状态信息，实现处理器的上下文恢复，以恢复内核态任务。

由于恢复后的处理器的上下文中PC寄存器存储的是异常修改指令的地址信息，因此，内核可根据处理器的上下文中PC寄存器的状态信息，执行PC寄存器存储的地址信息所指向的异常修复指令，而非执行任务中断时PC寄存器指向的当前指令，因此，可降低出现内核消费UCE内存的概率，降低由于内核消费UCE内存导致系统宕机的概率。在一些实施例中，按照POSIX标准，执行从用户地址空间复制数据到内核地址空间的接口指令，需要返回错误码（EFAULT）或已复制数据的长度。基于此，针对上述异常修复表中的data，内核在执行异常修复指令之后，还可通过系统调用返回目标数据（对应图3中步骤19“修改返回值”和步骤20“系统调用返回”）。目标数据可为错误码（如EFAULT）或已复制数据的长度等。

上述实施例示出了固件优先模式的具体实施方式，本申请实施例提供的异常修复方式还可适用于内核优先模式，即OS Native模式。下面对内核优先模式进行异常修复的具体实施方式进行示例性说明。

在内核优先模式下，内核负责直接响应和处理RAS中断，然后收集故障硬件寄存器的错误信息并处理错误。由于在内核优先下，中断请求由内核直接响应，由内核负责进程上下文切换，也就是说，内核可以直接获取内核任务消费UCE内存时的被中断任务的上下文，避免了异常上下文的同步问题。内核可利用异常修复表修复技术直接修复上下文，从而避免宕机，实现系统正常运行。

具体地，在内核优先模式下，内核可响应于中断请求，获取被中断任务的异常上下文；并将被中断任务的异常上下文保存至非安全状态。该中断请求为UCE内存被消费所触发的。由于该异常上下文是由处于非安全状态的内核所获取的。因此，该异常上下文包括：ESR_EL1的状态信息、FAR-EL1的状态信息、FAR-EL1的状态信息、PC寄存器的状态信息及PSTATE寄存器的状态信息等，不包括处于EL3模式的寄存器的状态信息。

进一步，内核可根据被中断任务的异常上下文，确定任务中断时处理器的状态。关于该步骤的具体实施方式可参见上述实施例的相关内容，在此不再赘述。

进一步，在步骤203中，内核可根据被中断任务的异常上下文，确定被中断任务的异常性质。被中断任务的异常性质包括：可修复异常和不可修复异常。

具体地，可从被中断任务的异常上下文中，获取ESR_EL1的状态信息；并从ESR_EL1的状态信息中，获取错误码、同步错误类型及数据错误状态码。进一步，可从ESR_EL1的状态信息中，获取错误码、同步错误类型及数据错误状态码；若错误码表征数据中止（DataAbort）、同步错误类型为可修复类型且数据错误状态码表征同步中止（如表征SEA），确定被中断任务的异常性质为可修复异常。

进一步，对于可修复异常，在步骤204中，内核可根据预先注册的异常修复表，修复异常上下文，以得到修改后的上下文。关于步骤204的具体实施方式可参见上述实施例的相关内容，在此不再赘述。

在上述实施例中，内核可利用异常修复表（Extable）修复技术直接修复上下文，从而避免宕机，实现系统正常运行。然而，内核优先模式需要内核为每一个系统芯片（Systemon Chip，SoC）实现一整套RAS驱动，即错误检测与纠正（Error Detection AndCorrection，EDAC）系统，用于解析支持RAS特性的知识产权（ Intellectual Property ，IP）核（Core）的错误状态等寄存器。同时，内核还需要实现和基板管理控制器（BaseboardManagement Controller，BMC）交互的逻辑，用于上报RAS信息给BMC，增加了内核的维护负担。此外，部分RAS寄存器和中断被固件配置为EL2不可访问，内核无法获取这部分寄存器的状态信息。因此，本申请实施例提供的异常修复方法优先应用于固件优先模式。

为了更清楚地说明本申请实施例提供的异常修复方法与传统异常修复方法的区别，下面结合图5a为传统异常修复方法的流程示意图和图5b为本申请实施例提供的异常修复方法，进行对比说明。其中，图5a为传统异常修复方法的流程示意图；图5b为本申请实施例提供的异常修复方法的流程示意图。图5b中灰色部分为本申请实施例提供的异常修复方法，相较于传统异常修复方法的改进部分。

如图5a和图5b所示，在从用户地址空间复制数据到内核地址空间时，即用户态的应用程序读内存或写内存时，应用程序可调用从用户地址空间复制数据到内核地址空间的接口（如图5a和图5b中的Uaccess接口），访问内核地址空间。若待访问的内存页为UCE内存，则UCE内存被消费。CPU可产生SEA请求，并将SEA请求发送给固件。

在图5a所示的传统异常修复方案中，固件可以SDEI事件的形式将错误分发给内核中预先注册的SDEI处理函数进行处理。该错误级别为致命错误。若SDEI处理函数当前错误确定为内核消费UCE内存，则发生系统宕机。若SDEI处理函数当前错误确定为用户态消费UCE内存，进行内存错误修复。关于内存错误修复的方式可参见上述图1中步骤6的相关内容，在此不再赘述。

在图5b所示的本申请实施例提供的异常修复方案中，固件在接收到SEA请求之后，可保存被中断任务的异常上下文；并将被中断任务的异常上下文提供给内核。内核可根据被中断任务的异常上下文，判定任务中断时处理器的状态是否处于内核态；若处理器处于内核态，则根据被中断任务的异常上下文，判定被中断任务是否为可修复任务；若判断结果为是，则利用异常修复表（Extable）技术调用异常修复函数，修复异常上下文，得到修复后的上下文。之后，固件可同步修复后的上下文；并根据修复后的上下文，恢复内核态任务，实现内存错误处理。相应地，在图5b中，若被中断任务为不可修复任务，则发生系统宕机。

根据上述图5a和图5b可以得出：本申请实施例提供的异常修复方法通过SDEI技术在内核与固件之间同步上下文，并通过用Extable修复技术进行上下文修复，降低了由于UCE内存被内核消费导致的系统宕机的概率，有助于提高系统稳定性。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤201和202的执行主体可以为设备A；又比如，步骤201的执行主体可以为设备A，步骤202的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如201、202等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述异常修复方法中的步骤。

图6为本申请实施例提供的计算设备的结构示意图。如图6所示，计算设备包括：存储器60a和处理器60b。存储器60a包括：内存601和其它存储介质602。存储器60a用于存储计算机程序。其中，计算机程序可存储于内存601，也可存储于其它存储介质602。处理器60b运行有内核。

在本实施例中，处理器60b耦合至存储器60a，用于执行计算机程序以用于：响应于中断请求，获取被中断任务的异常上下文；中断请求为内存601中的UCE内存被消费所触发的；根据异常上下文，确定任务中断时处理器的状态；在任务中断时处理器的状态为内核态的情况下，根据异常上下文，确定被中断任务的异常性质；在异常性质为可修复异常的情况下，根据预先注册的异常修复表，修复异常上下文，以得到修复后的上下文；根据修复后的上下文，恢复处理器执行的内核态任务。

在一些实施例中，内核运行于非安全状态；处理器还运行有处于安全状态的固件。相应地，处理器60b在响应于中断请求获取被中断任务的异常上下文时，具体用于：响应于中断请求，将处理器切换至安全状态；利用固件将异常上下文保存至安全状态；并利用固件将异常上下文提供给处于内核；以及，利用内核获取异常上下文。

可选地，异常上下文包括： ESR_EL3的状态信息，及FAR_EL3的状态信息；

相应地，处理器60b在利用固件将异常上下文提供给处于非安全状态的内核时，具体用于：利用固件将处于ESR_EL1的第一状态信息，及FAR_EL1的第一状态信息，保存到安全状态；并利用固件将ESR_EL1的第一状态信息修改为ESR_EL3的状态信息，以得到ESR_EL1的第二状态信息；并将FAR_EL1的第一状态信息修改为FAR_EL3的状态信息，以得到ESR_EL1的第二状态信息。

相应地，处理器60b在利用内核获取异常上下文时，具体用于：利用内核通过ESR_EL1的第二状态信息和ESR_EL1的第二状态信息，获取ESR_EL3的状态信息和FAR_EL3的状态信息。

在一些实施例中，异常上下文还包括：通用寄存器的状态信息及目标寄存器的状态信息；通用寄存器包括：第一通用寄存器、第二通用寄存器及第三通用寄存器。处理器60b还用于：利用固件响应于中断请求，通过软件委托异常接口SDEI事件将处理器切换至非安全状态，以将控制权转移至内核。

相应地，处理器60b在固件将异常上下文提供给处于非安全状态的内核时，具体用于：利用固件通过第一通用寄存器将内核预先注册的SDEI处理函数的入口参数，提供给内核；第一通用寄存器的数量与SDEI处理函数的入口参数的数量相等；以及，利用固件将第二通用寄存器的状态信息传递给内核；第二通用寄存器是设定的用于任务处理的通用寄存器；并利用固件将目标寄存器的状态信息写入第三通用寄存器；以及通过第三通用寄存器将目标寄存器的状态信息传递给内核。

可选地，处理器还用于：利用固件将ELR_EL3的状态信息，修改为内核预先注册的SDEI处理函数的入口地址。相应地，处理器60b在通过SDEI事件将处理器从安全状态切换至非安全状态时，具体用于：根据ELR_EL3的状态信息，执行异常返回指令，以通过SDEI处理函数的入口地址将处理器从安全状态切换至非安全状态。

相应地，处理器60b在利用内核获取异常上下文时，具体用于：内核利用SDEI处理函数将通用寄存器的状态信息，保存至非安全状态的缓存中，以获取第二通用寄存器的状态信息和目标寄存器的状态信息；内核通过调用SDEI接口，从固件保存的异常上下文中，获取第一通用寄存器的状态信息。

在一些实施例中，异常上下文包括：处理器状态PSTATE寄存器的状态信息。相应地，处理器60b在根据异常上下文，确定任务中断时处理器的状态时，具体用于：内核从异常上下文中，获取PSTATE寄存器的状态信息；PSTATE寄存器的状态信息表征任务中断时处理器的状态；以及，根据PSTATE寄存器的状态信息，确定任务中断时处理器的状态。

可选地，异常上下文包括：ESR_EL3寄存器的状态信息。处理器60b在根据异常上下文，确定被中断任务的异常性质时，具体用于：内核从非安全状态保存的异常上下文中，获取ESR_EL3的状态信息；从ESR_EL3的状态信息中，获取错误码、同步错误类型及数据错误状态码；在错误码表征数据中止、同步错误类型为可修复类型且数据错误状态码表征同步中止的情况下，确定被中断任务的异常性质为可修复异常。

在另一些实施例中，异常上下文包括：程序计数器PC寄存器的第一状态信息。处理器60b还用于：利用内核将异常上下文保存至非安全状态。相应地，处理器60b在根据预先注册的异常修复表，修复异常上下文时，具体用于：内核根据PC寄存器的第一状态信息在预先注册的异常修复表中进行查找，以确定记录的当前指令的地址与PC寄存器的第一状态信息相同的目标异常修复表；从目标异常修复表中，获取异常修复指令的地址；以及，将非安全状态保存的PC寄存器的第一状态信息修改为异常修复指令的地址。

进一步，处理器60b在将非安全状态保存的PC寄存器的第一状态信息修改为异常修复指令的地址时，具体用于：内核从目标异常修复表中，获取当前指令的类型；根据当前指令的类型，通过内核预先注册的SDEI处理函数调用当前指令的类型适配的异常修复函数；利用异常修复函数将非安全状态保存的PC寄存器的第一状态信息修改为异常修复指令的地址。

可选地，异常上下文还包括：通用寄存器的状态信息。相应地，处理器60b在根据预先注册的异常修复表，修复异常上下文时，还用于：内核从目标异常修复表中，获取用于异常修复的目标数据；利用异常修复函数将非安全状态保存的通用寄存器的状态信息，修改为目标数据。

可选地，处理器60b还用于：在根据预先注册的异常修复表，修复异常上下文之后，内核将异常上下文的错误级别从致命错误修改为可修复错误；并解除被消费的UCE内存对应的内存页的地址映射。

可选地，处理器60b还用于：内核通过SMC指令将处理器从内核跳转至固件；固件从非安全状态获取非安全状态保存的修复后的上下文，并根据安全状态保存的ESR_EL1寄存器的第一状态信息和FAR_EL1寄存器的第一状态信息，恢复ESR_EL1寄存器和FAR_EL1寄存器，以得到安全状态中的修复后的上下文。

相应地，处理器60b在根据修复后的上下文，恢复处理器执行的内核态任务时，具体用于：固件根据安全状态中修复后的上下文，恢复处理器的上下文，以恢复内核态任务；修复后的上下文包括：PC寄存器存储的异常修复指令的地址信息；内核根据异常修复指令的地址信息，执行异常修复指令；并通过系统调用返回目标数据。

可选地，处理器60b还用于：内核在启动过程中，从HEST中，获取HEST包含的事件号；调用SDEI注册函数为HEST包含的事件号分别注册对应的SDEI处理函数。

可选地，处理器60b还用于：固件根据预先配置的中断类型与事件号之间的对应关系，确定SDEI事件的目标事件号；根据SDEI事件的目标事件号，确定目标事件号对应的SDEI处理函数，作为预先注册的SDEI处理函数；确定目标事件号对应的SDEI处理函数的入口参数。

在一些可选实施方式中，如图6所示，该计算设备还可以包括：通信组件60c、电源组件60d等组件。在一些实施例中，计算设备可实现为手机、电脑等终端设备。相应地，计算设备还可包括：显示组件60e及音频组件60f等组件。图6中仅示意性给出部分组件，并不意味着计算设备必须包含图6所示全部组件，也不意味着计算设备只能包括图6所示组件。

本实施例提供的计算设备，可响应于UCE内存被消费触发的中断请求，获取被中断任务的异常上下文；针对任务中断时处理器处于内核态的情况，可根据异常上下文，判定被中断任务是否为可修复异常；之后，对于可修复异常的被中断任务，可根据预先注册的异常修复表，修复异常上下文；并根据修复后的上下文，恢复处理器执行的内核态任务。由于处理器执行的内核态任务是基于修复后的上下文恢复的，因此，处理器执行的内核态任务可绕过任务中断时的上下文，可降低再次出现内核消费UCE内存的概率，进而降低由于内核消费UCE内存导致系统宕机的概率。

在本申请实施例中，存储器用于存储计算机程序，并可被配置为存储其它各种数据以支持在其所在设备上的操作。其中，处理器可执行存储器中存储的计算机程序，以实现相应控制逻辑。存储器（内存或其它存储介质）可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（Static Random-Access Memory，SRAM），电可擦除可编程只读存储器（Electrically Erasable Programmable Read Only Memory，EEPROM），可擦除可编程只读存储器（Electrical Programmable Read Only Memory，EPROM），可编程只读存储器（Programmable Read Only Memory，PROM），只读存储器（ReadOnly Memory，ROM），磁存储器，快闪存储器，磁盘或光盘。

在本申请实施例中，处理器可以为任意可执行上述方法逻辑的硬件处理设备。可选地，处理器可以为中央处理器（Central Processing Unit，CPU）、图形处理器（GraphicsProcessing Unit，GPU）或微控制单元（Microcontroller Unit，MCU）；也可以为现场可编程门阵列（Field-Programmable Gate Array，FPGA）、可编程阵列逻辑器件（ProgrammableArray Logic，PAL）、通用阵列逻辑器件（General Array Logic，GAL）、复杂可编程逻辑器件（Complex Programmable Logic Device，CPLD）等可编程器件；或者为先进精简指令集（Reduced Instruction Set Compute，RISC）处理器（Advanced RISC Machines，ARM）或系统芯片（System on Chip，SoC）等等，但不限于此。

在本申请实施例中，通信组件被配置为便于其所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G，5G或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件还可基于近场通信（Near Field Communication，NFC）技术、射频识别（Radio Frequency Identification，RFID）技术、红外数据协会（Infrared Data Association，IrDA）技术、超宽带（Ultra WideBand，UWB）技术、蓝牙（Bluetooth，BT）技术或其他技术来实现。

在本申请实施例中，显示组件可以包括液晶显示器（Liquid Crystal Display，LCD）和触摸面板（Touch Panel，TP）。如果显示组件包括触摸面板，显示组件可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

在本申请实施例中，电源组件被配置为其所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

在本申请实施例中，音频组件可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风（Microphone，MIC），当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。例如，对于具有语言交互功能的设备，可通过音频组件实现与用户的语音交互等。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、只读光盘（Compact Disc Read-Only Memory，CD-ROM）、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU等)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (Random-Access Memory，RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机的存储介质为可读存储介质，也可称为可读介质。可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (Phase-Change Memory，PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (Dynamic Random Access Memory，DRAM)、其他类型的随机存取存储器(RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘 (Digital Video Disc，DVD) 或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括上述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上内容仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

1.一种异常恢复方法，其特征在于，包括：

响应于中断请求，获取被中断任务的异常上下文；所述中断请求为不可纠正错误UCE内存被消费所触发的；

根据所述异常上下文，确定任务中断时处理器的状态；

在所述任务中断时处理器的状态为内核态的情况下，根据所述异常上下文，确定所述被中断任务的异常性质；

在所述异常性质为可修复异常的情况下，根据预先注册的异常修复表，修复所述异常上下文，以得到修复后的上下文；

根据所述修复后的上下文，恢复所述处理器执行的内核态任务。

2.根据权利要求1所述的方法，其特征在于，所述处理器运行有处于非安全状态的内核和处于安全状态的固件；所述响应于中断请求，获取被中断任务的异常上下文，包括：

响应于中断请求，将所述处理器切换至安全状态；

所述固件将所述异常上下文保存至所述安全状态；

所述固件将所述异常上下文提供给处于所述内核；

所述内核获取所述异常上下文。

3.根据权利要求2所述的方法，其特征在于，所述异常上下文包括：处于异常等级3模式的异常综合表征寄存器ESR_EL3的状态信息，及处于异常等级3模式的故障虚拟地址寄存器FAR_EL3的状态信息；

所述固件将所述异常上下文提供给处于非安全状态的内核，包括：

所述固件将处于异常等级1模式的异常综合表征寄存器ESR_EL1的第一状态信息，及处于异常等级1模式的故障虚拟地址寄存器FAR_EL1的第一状态信息，保存到所述安全状态；

所述固件将所述ESR_EL1的第一状态信息修改为所述ESR_EL3的状态信息，以得到所述ESR_EL1的第二状态信息；并将所述FAR_EL1的第一状态信息修改为所述FAR_EL3的状态信息，以得到所述ESR_EL1的第二状态信息；

所述内核获取所述异常上下文，包括：

所述内核通过所述ESR_EL1的第二状态信息和所述ESR_EL1的第二状态信息，获取所述ESR_EL3的状态信息和所述FAR_EL3的状态信息。

4.根据权利要求2所述的方法，其特征在于，所述异常上下文包括：通用寄存器的状态信息及目标寄存器的状态信息；所述通用寄存器包括：第一通用寄存器、第二通用寄存器及第三通用寄存器；所述方法还包括：

所述固件响应于中断请求，通过软件委托异常接口SDEI事件将所述处理器切换至所述非安全状态，以将控制权转移至所述内核；

所述固件将所述异常上下文提供给处于非安全状态的内核，包括：

所述固件通过所述第一通用寄存器将所述内核预先注册的SDEI处理函数的入口参数，提供给所述内核；所述第一通用寄存器的数量与所述SDEI处理函数的入口参数的数量相等；

所述固件将所述第二通用寄存器的状态信息传递给所述内核；所述第二通用寄存器是设定的用于任务处理的通用寄存器；

所述固件将所述目标寄存器的状态信息写入所述第三通用寄存器；并通过所述第三通用寄存器将所述目标寄存器的状态信息传递给所述内核。

5.根据权利要求4所述的方法，其特征在于，还包括：

所述固件将处于异常等级3的异常链接寄存器ELR_EL3的状态信息，修改为所述内核预先注册的SDEI处理函数的入口地址；

所述通过SDEI事件将所述处理器从安全状态切换至所述非安全状态，以将控制权转移至所述内核，包括：

根据所述ELR_EL3的状态信息，执行异常返回指令，以通过所述SDEI处理函数的入口地址将所述处理器从所述安全状态切换至所述非安全状态；

所述内核获取所述异常上下文，包括：

所述内核利用所述SDEI处理函数将所述通用寄存器的状态信息，保存至所述非安全状态的缓存中，以获取所述第二通用寄存器的状态信息和所述目标寄存器的状态信息；

所述内核通过调用SDEI接口，从所述固件保存的异常上下文中，获取所述第一通用寄存器的状态信息。

6.根据权利要求2所述的方法，其特征在于，所述异常上下文包括：处理器状态PSTATE寄存器的状态信息；

所述根据所述异常上下文，确定任务中断时处理器的状态，包括：

所述内核从所述异常上下文中，获取所述PSTATE寄存器的状态信息；所述PSTATE寄存器的状态信息表征任务中断时处理器的状态；

根据所述PSTATE寄存器的状态信息，确定所述任务中断时处理器的状态。

7.根据权利要求2所述的方法，其特征在于，所述异常上下文包括：ESR_EL3寄存器的状态信息；

所述根据所述异常上下文，确定所述被中断任务的异常性质，包括：

所述内核从非安全状态保存的异常上下文中，获取所述ESR_EL3的状态信息；

从所述ESR_EL3的状态信息中，获取错误码、同步错误类型及数据错误状态码；

在所述错误码表征数据中止、所述同步错误类型为可修复类型且所述数据错误状态码表征同步中止的情况下，确定所述被中断任务的异常性质为可修复异常。

8.根据权利要求2所述的方法，其特征在于，所述异常上下文包括：程序计数器PC寄存器的第一状态信息；所述方法还包括：

所述内核将所述异常上下文保存至所述非安全状态；

所述根据预先注册的异常修复表，修复所述异常上下文，包括：

所述内核根据所述PC寄存器的第一状态信息在预先注册的异常修复表中进行查找，以确定记录的当前指令的地址与所述PC寄存器的第一状态信息相同的目标异常修复表；

从所述目标异常修复表中，获取异常修复指令的地址；

将所述非安全状态保存的所述PC寄存器的第一状态信息修改为所述异常修复指令的地址。

9.根据权利要求8所述的方法，其特征在于，所述将所述非安全状态保存的所述PC寄存器的第一状态信息修改为所述异常修复指令的地址，包括：

所述内核从所述目标异常修复表中，获取所述当前指令的类型；

根据所述当前指令的类型，通过所述内核预先注册的SDEI处理函数调用所述当前指令的类型适配的异常修复函数；

利用所述异常修复函数将所述非安全状态保存的所述PC寄存器的第一状态信息修改为所述异常修复指令的地址。

10.根据权利要求9所述的方法，其特征在于，所述异常上下文还包括：通用寄存器的状态信息；所述根据预先注册的异常修复表，修复所述异常上下文，还包括：

从所述目标异常修复表中，获取用于异常修复的目标数据；

利用所述异常修复函数将所述非安全状态保存的通用寄存器的状态信息，修改为所述目标数据。

11.根据权利要求2所述的方法，其特征在于，在根据预先注册的异常修复表，修复所述异常上下文之后，还包括：

所述内核将所述异常上下文的错误级别从致命错误修改为可修复错误；并解除被消费的UCE内存对应的内存页的地址映射。

12.根据权利要求10所述的方法，其特征在于，还包括：

所述内核通过安全监测调用SMC指令将所述处理器从所述内核跳转至所述固件；

所述根据所述修复后的上下文，恢复所述处理器执行的内核态任务，包括：

所述固件从所述非安全状态获取所述非安全状态保存的修复后的上下文，并根据所述安全状态保存的ESR_EL1寄存器的第一状态信息和FAR_EL1寄存器的第一状态信息，恢复所述ESR_EL1寄存器和所述FAR_EL1寄存器，以得到所述安全状态中的修复后的上下文；

所述固件根据所述安全状态中修复后的上下文，恢复所述处理器的上下文，以恢复所述内核态任务；所述修复后的上下文包括：PC寄存器存储的异常修复指令的地址信息； 以及，

所述内核根据所述异常修复指令的地址信息，执行所述异常修复指令；

通过系统调用返回所述目标数据。

13.根据权利要求4所述的方法，其特征在于，所述方法还包括：

所述内核在启动过程中，从HEST中，获取HEST包含的事件号；

调用SDEI注册函数为所述HEST包含的事件号分别注册对应的SDEI处理函数。

14.根据权利要求13所述的方法，其特征在于，所述方法还包括：

所述固件根据预先配置的中断类型与事件号之间的对应关系，确定所述SDEI事件的目标事件号；

根据所述SDEI事件的目标事件号，确定所述目标事件号对应的SDEI处理函数，作为所述预先注册的SDEI处理函数；

确定所述目标事件号对应的SDEI处理函数的入口参数。

15.一种计算设备，其特征在于，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；所述存储器包括内存；所述处理器运行有内核；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行权利要求1-14任一项所述方法中的步骤。

16.一种存储有计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求1-14任一项所述方法中的步骤。

Images