1. 背景介绍
在超大规模云计算数据中心中，服务器宕机率一直是衡量RAS（可靠性、可用性和可服务性）的一个关键指标，也是满足云计算终端用户SLA（服务水平协议）的首要问题[1]。
系统非预期宕机不仅影响业务的正常运行，同时损害企业的声誉。在计算集群和数据中心，单台物理机部署的硬件和软件密度越来越高，每一个物理机可部署上百个VM[3]和2500个容器实例[4]。虽然硬件故障很少发生，但任何服务器宕机都可能导致巨大的成本损失。根据一项对63个数据中心的研究显示[2]，每一分钟的停机时间会造成近9000美元的损失。
内存故障是导致服务器故障的主要原因[5]。DDR SDRAM （DRAM）凭借高密度、简单架构、低延迟和低功耗等优势，成为当今几乎所有应用中广泛使用的主存储器，遍布高性能计算（HPC）和移动应用。由于DRAM的掉电易失性，内存故障往往意味着数据丢失和不可恢复。
内存子系统中最流行的RAS方案之一是错误纠正码（ECC）内存。通过为实际数据生成ECC SECDED码并将其存储在额外的DRAM存储中，DDR控制器可以纠正单比特错误并检测从DRAM接收数据的两比特错误。单比特错误被称为CE错误，两比特错误被称为UCE错误。腾讯云报告显示[1]，在2018年第四季度末，Purley Cloud VM服务器约50%的宕机来自内存UCE相关错误。
在X86平台，Intel Xeon Scalable系列处理器支持MCA机制，检测、记录和上报机器的硬件故障信息，从而为系统恢复和隔离内存错误提供了可能。CPU以CMCI中断上报CE，以MCE异常上报UCE。内核通过响应CMCI，将CE错误记录。对于UCE错误，内核首先将内存页标记为“poison”，终止映射该页的进程，并避免将来使用该页，从而隔离部分UCE错误。腾讯云报告显示[1]，通过支持MCA，服务器宕机率从100%显著降低到50%，虚拟机迁移成功率从0%提高到40%。
Arm平台，也提供了错误检测、记录和上报的能力。RAS是Armv8.2及更高版本CPU的强制扩展。如何联合硬件、固件、内核、虚拟化团队，在倚天平台找到有效的解决方案，来解决内存故障变得至关重要。
2. 整体方案
OS联合ECS、BIOS、Hardware同学，发挥软硬件协同优势，建设倚天平台全链路RAS体系，通过内存隔离手段，实现内核降级运行，从而显著降低ECS宕机率。
3. SDEI: Software Delegated Exception Interface
发生UCE的数据，通常我们称之为poison data。如果访存指令读取poison data，则意味着poison data将被消费，CPU产生同步异常Synchronous External Aborts。此时，内核失去CPU的控制权，CPU从EL1进入EL3。倚天当前使用SDEI通知的形式，通知内核硬件的产生RAS事件。
Firmware在处理完SEA后，通过eret跳转预先注册的trampoline，实现从Firmware到内核的跳转。内核通过错误类型和错误的严重级别，实现内存隔离和恢复。
4. Linux内存隔离和恢复
4.1 EL0 UCE降级运行
进程的用户地址空间由页表提供隔离，对于用户态进程消费UCE的情况，利用SEA同步异常的特性，内核通过将错误的影响范围控制到进程粒度，从而实现的UCE错误的隔离和恢复，避免系统宕机。
简单来说，如果UCE错误被用户态进程消费，内核GHES驱动将poison页隔离，打上poison标记，并解除页表映射。若poison页未被修改过，利用缺页异常重新从磁盘中加载数据；否则，poison页为脏页，向映射poison所在页的进程发送SIGBUS信号。如果进程不处理SIGBUS，则默认会被kill掉。
对于进程内存共享的情况，通过只将current进程kill掉，避免影响扩大化。当然，内核也提供了prctl接口，实现进程感知的MCA，通过设置PF_MCE_EARLY标记，内核会同时kill掉其他共享内存的进程。
4.2 EL2 UCE降级运行
与用户地址空间不同的是，内核地址空间被所有进程共享，当UCE错误被内核消费，无法通过停止进程的方式，隔离错误，因此，通常情况下，发生在内核地址空间的内存错误，通常需要立马宕机。
然而，并不是所有被内核消费的UCE错误，都需要宕机。用户态进程调用系统调用，通过SVC指令触发同步异常陷入内核态，内核根据系统调用号执行对应的系统调用后，返回用户态。对于write(2)、futex(2)等系统调用，内核通过copy_from_user和get_user等uaccess接口，从用户地址空间拷贝数据到内核地址空间，如果拷贝的数据中包含UCE错误，按照POSIX标准，只需要返回错误码EFAULT或已拷贝的长度，从而避免内核态消费UCE错误宕机。
Firmware First模式下，任务异常的现场上下文由Firmware保存在Secure，而Kernel对异常上下文的修改在Non-secure，Firmware在恢复任务上下文时，仍然使用的是Secure现场。当前SDEI缺少将Non-secure现场的修改同步到Secure现场的机制。
首先，内核联合BIOS，通过寄存器覆盖和参数传递等方式，解决SDEI上下文同步问题，为Kernel修复错误异常提供可能。其次，内核在uaccess接口，为load类指令在extable注册了fixup handler，内核通过fixup handler实现异常上下文的修复。
4.3 Scrub降级运行
除了core会发起DDR的读写请求外，DDR控制器中Scrubber也会定期发起DDR请求，用于巡检DDR错误。通常，巡检周期配置为24小时。
在Scrubber发出的DDR请求中，如果消费了poison data，则DDR控制器上报一个UE中断。由于这个UE中断并不是进程的访存行为导致的，与进程上下文无关（Non-execution Path），不会导致错误传播，因此，并不需要立马宕机。内核只需要将poison页，打上poison标记，并解除页表映射即可。如果在后面进程的生命周期内，读取poison页，则在触发page fault时，向进程发送SIGBUS信号。
5. 效果更新
在倚天710平台，通过全链路RAS的通力协作，预计将OS内存故障隔离率由0%提高到50%。
参考文献
[1]https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/reduce-server-crash-rate-tencent-paper.pdf
[2]Ponemon Institute. 2016. Cost of Data Center Outages. https://www.vertivco. com/globalassets/documents/reports/2016-cost-of-data-center-outages-11-11_ 51190_1.pdf
[3]Zhang X, Zheng X, Wang Z, et al. Fast and scalable VMM live upgrade in large cloud infrastructure[C]//Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems. 2019: 93-105.
[4]Li Z, Cheng J, Chen Q, et al. {RunD}: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing[C]//2022 USENIX Annual Technical Conference (USENIX ATC 22). 2022: 53-68.
[5]Sun X, Chakrabarty K, Huang R, et al. System-level hardware failure prediction using deep learning[C]//2019 56th ACM/IEEE design automation conference (DAC). IEEE, 2019: 1-6.
[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/sdei.html
