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"，在那裡有最新的文章。同時歡迎大家給本專欄和公眾號投稿！