WHEA原理和架构

WHEA原理和架构

上文计算机硬件出错了会发生什么?)我们对计算机硬件错误处理有了初步的认识,今天我们来深入了解一下WHEA的原理和架构。

为什么需要WHEA

据调查有7~10%的系统崩溃是硬件错误导致。而OS对硬件错误了解甚少,同硬件打交道最多的固件虽然知道错误发生的原因却没有办法告知OS。这样导致错误的处理是割裂的,传统服务器会让BMC记录错误,OS只是在最后蓝屏了之,错误的报告和隔离远远谈不上规范。

微软当然不愿意被排除在游戏之外,它有感于现状,为了在IPF和X86之上建立统一的错误通知、处理和记录框架,在Vista/Longhorn中推出了WHEA(Windows Hardware Error Architecture)框架。

WHEA的组成和架构

WHEA组成框架如下:

它大致由三部分组成:

1. 固件和硬件。提供硬件支持,并在固件中提供接口和OS中的Platform Specific Hardware Error Driver进行交互。

2. 操作系统内核支持。Windows操作系统通过PSHED(Platform Specific Hardware Error Driver)和LLHEH (Low-Level Hardware Error Handler)对错误信息进行统计、分析和存储。

a. PSHED:它直接和固件打交道。它通过固件报告的HEST (H/W Error Source Table) ACPI tables知道如何与固件和硬件通信,了解错误的发生源;通过ERST (Error Record Serialization Table)可以在OS已经并不安全的时候,让UEFI固件代劳存储错误信息;通过BERT (Boot Error Record Table),知道在Boot阶段发生了什么错误;并在使用EINJ (Error Injection Table)在需要的时候,注入错误。它可以通过插件Plug-ins进行扩展,以支持新的硬件和新的功能。

b. LLHEH:它们位于Windows驱动的HAL层(硬件抽象层)。它最先从固件那里得到错误通知,如下图:

不同的错误通知方法有不同的LLHEH。NMI有NMI的LLHEH,CMCI/MCE有它的LLHEH,AER也有自己的LLHEH。它起到承上启下的作用,下面调用PSHED,上面报告给WHEA统一处理模块WheaReportHwErr。

3. 应用层。在应用层可以有丰富的错误展现和记录机会。通过ETW(Event Tracing For Windows)得到通知后,Windows事件记录器可以把它记录在系统日志里面,可以显示一个界面报告给用户“你的内存刚才出错了,别担心,我已经帮你搞定了,请叫我雷锋”等等。甚至可以发个短信给系统管理员:

当然这么复杂的事情并不是只有微软一个人搞定,硬件制造商,OEM等必须各司其职,完成自己应该干的那部分:

在一个典型的Intel平台上,错误处理如下:

错误处理流程

在出现硬件错误了以后,固件是如何处理的呢?WHEA规定有两种方法:并行处理或者固件优先。

1. 并行处理。OS和UEFI固件分别自行处理,OS通过CMCI,NMI处理;固件在收到SMI后也自行处理。这种方法基本不用

2. 固件优先。推荐这种方式。发生错误后,固件先得到通知,并做了预处理再通知OS处理。因为固件对硬件的了解,它可以做一些错误抑制(error containment),将一些UCE(不可修复错误)进行recovery,从而减少损失。固件通知OS的方式一般采用:UCE使用NMI,CE采用SCI。

其他

WHEA在推出后反响不错,微软于是在ACPI 4.0将其贡献到spec中,因为其名字中的W代表Windows而不得不取了个新名字:APEI(ACPI Platform Error Interface)。它和WHEA的唯一区别是GUID不同。

WHEA的架构介绍完了,对固件来说,它的核心主要在于四张ACPI table。理解了它们,对于固件如何处理就了然于胸了。具体参见ACPI spec。

欢迎大家关注本专栏和用微信扫描下方二维码加入微信公众号"UEFIBlog",在那里有最新的文章。同时欢迎大家给本专栏和公众号投稿!

用微信扫描二维码加入UEFIBlog公众号
编辑于 2017-10-28

文章被以下专栏收录

    从首次运用于Intel 安腾处理器,到第一版统一的可扩展固件接口(UEFI)规范出版,无论是在高性能服务器,移动设备或是深度嵌入式设备等,UEFI已在所有平台完全淘汰了BIOS。这里有关于UEFI的一切。