Arm A-profile 架構的有一個長期缺陷就是不支持不可屏蔽中斷 (NMI) 。2021年，ARM宣布講支持NMI，所謂支持其實就是看CPU是否支持？GIC是否支持？但是究竟什么是 NMI，操作系統軟件如何使用這些功能，以及當有多種方法可以屏蔽它們時，為什么它們被稱為不可屏蔽？這篇博文更詳細地探討了這些問題。

對 NMI 的需求

讓我們首先探討為什么需要一類特殊的中斷以及為什么我們稱它們為不可屏蔽。首先要意識到，所有中斷在某些情況下都是可屏蔽的。例如，如果中斷控制器完全關閉，則不會向 CPU 傳遞任何中斷。術語不可屏蔽中斷實際上涵蓋了一類中斷，即使“正常”中斷被屏蔽，仍可以將其傳遞給 CPU。NMI 仍然可以被屏蔽，但是通過標準內核代碼難以訪問的單獨控制狀態。在某些情況下屏蔽所有中斷的能力也存在于其他具有悠久 NMI 歷史的架構上。

操作系統軟件需要僅在特定情況下被屏蔽的單獨中斷類別有兩個主要原因。第一個原因很簡單，中斷可能會意外地被禁用，從而使系統處于無響應狀態。乍一看，似乎可以輕松編寫軟件以在禁用中斷后始終啟用中斷，但事實并非如此。現代操作系統內核通常跨越數百萬行可以直接操作中斷標志的代碼。中斷處理例程可能會導致同步異常，從而導致非線性代碼路徑，并可能導致禁用中斷的死鎖。還要考慮以完全內核權限運行并能夠直接操縱 CPU 中斷標志的第三方驅動程序。應該清楚的是，簡單的代碼檢查或靜態分析不足以防止中斷被禁用。在一些場景中，能夠快速傳遞中斷至關重要，例如調試、跨 PE 同步和熱補丁。

第二個原因是操作系統依賴中斷來支持性能分析。比如Linux的perf AArch64 上的子系統依賴于 PMU 溢出中斷。通過將循環計數器編程為以特定間隔溢出來分析代碼路徑，并且在每次溢出時，都會將 PMU 中斷傳遞給 CPU。perf 處理中斷并對正在運行的進程的 PC 進行采樣。當程序員只有一個中斷掩碼可用時，任何禁用中斷的關鍵部分都不能被分析。用戶的一個常見抱怨是他們的分析結果顯示在 local_irq_enable() 期間花費了很多 CPU 時間。顯然情況并非如此，因為該功能將由操縱 PSTATE.I 標志的單個指令實現。誤導性信息是由于 PMU 中斷總是在 IRQ 重新啟用時傳遞，并且 perf 總是在此功能上對 PC 進行采樣。

為了在引入架構 NMI 支持之前解決這個問題，Linux 依賴于偽NMI，它使用了 GIC 架構中的中斷優先級特性。Linux 對 PMU 溢出中斷進行編程，其優先級高于所有其他中斷。這重寫了arm64特定的中斷啟用和禁用函數來更改CPU中斷優先級掩碼（ICC_PMR_EL1），而不是直接操作CPU IRQ異常標志（PSTATE.I）。提醒一下，Arm 架構將 CPU 異常（IRQ 和 FIQ 異常）與在 GIC 中完成的單個中斷的處理和配置分開。盡管當今大多數系統都使用 GIC，但可以使用不同的中斷控制器架構構建基于 Arm 的系統。

使用優先級實現偽 NMI 可以很好地支持 Linux 上的分析，但不幸的是在操作系統的關鍵路徑中引入了額外的軟件復雜性。例如，在 KVM 內置的 hypervisor 中進入 guest 虛擬機時，hypervisor 必須仔細執行幾個步驟。首先，優先級掩碼用于屏蔽非分析中斷，以便可以分析 VM 進入路徑。其次，在設置 CPU 返回狀態以執行向 VM 的異常返回之前，必須使用 PSTATE.I 屏蔽中斷以防止破壞異常返回狀態。第三，也是最后，必須降低優先級掩碼，以允許任何主機中斷在稍后的時間點導致從 VM 退出。此流程會在 VM 處理代碼的最關鍵路徑中產生開銷，最好避免。

最新架構擴展支持 NMI

不可屏蔽有點用詞不當，因為 NMI 可以被屏蔽。關鍵是某些中斷必須與其他中斷分開屏蔽，并且必須能夠防止軟件輕易直接屏蔽特定中斷。一些操作系統只需要單獨的屏蔽，而另一些則需要單獨的屏蔽和防止容易屏蔽中斷的機制。

在 RISC 風格的架構（如 Arm）上，必須能夠在異常進入和異常返回期間屏蔽異常級別內的所有中斷。這是因為異常信息存儲在 ELR_ELx 和 SPSR_ELx 寄存器中。如果 IRQ 異常在另一個異常的異常處理路徑中足夠早地傳遞，這些寄存器將被覆蓋。關鍵信息將丟失，無法恢復。

這可能是提醒讀者另一個 Arm 架構特性 PSTATE.SP 的好時機。在對 ELx 產生異常時，目標異常級別的專用堆棧指針 SP_ELx 用于訪問堆棧。然后，軟件可以選擇在初始異常進入后切換到使用 SP_EL0 堆棧指針，例如，如果它想重用用戶空間線程堆棧指針來執行內核。這允許使用專用的異常入口堆棧，與在線程上下文中執行分開。通過寫入專用寄存器SPSel來切換堆棧指針. 一些操作系統使用此模型，而其他操作系統則不使用。例如，Linux 在分別運行在 EL1 或 EL2 時總是使用專用堆棧指針 SP_EL1 或 SP_EL2，并使用 SP_EL0 作為附加寄存器。

2021 擴展引入了在 GIC 中使用專用 NMI 優先級配置中斷的能力，該優先級嚴格高于其他優先級。（這忽略了跨多個安全狀態的優先級。例如，仍然可以將安全世界中斷配置為比非安全世界中的 NMI 具有更高的優先級），配置有 NMI 優先級的中斷，從這里稱為“NMI”，與其他中斷分開屏蔽。然后，CPU 架構允許操作系統使用 SCTLR_ELx 系統寄存器中的新選擇控件來選擇如何屏蔽 NMI。沒有 NMI 優先級的正常中斷使用現有的 PSTATE.I 位進行屏蔽。

第一種屏蔽模式利用現有的 SP 選擇邏輯。這會在異常進入和退出路徑期間屏蔽包括 NMI 在內的所有中斷，并防止操作系統內核的其余部分屏蔽 NMI。當使用專用 SP_ELx 堆棧指針時，此模式通過屏蔽 NMI 來工作。當操作系統完成異常入口路徑并將堆棧指針切換到 SP_EL0 時，只能通過將堆棧指針更改回 SP_ELx 來屏蔽 NMI，這實際上阻止了軟件直接屏蔽 NMI。通過使用 Armv8.6 架構擴展中引入的細粒度陷阱，在 EL2 上運行的管理程序可以防止在 EL1 上運行的操作系統更改異常入口路徑之外的堆棧指針。

第二種屏蔽模式只是引入了一個單獨的屏蔽位 PSTATE.AllInt，它在異常進入期間設置，與設置 PSTATE.I 的方式相同。PSTATE.AllInt 獨立于堆棧指針選擇，并由軟件直接設置和清除，盡管運行在 EL2 的管理程序也可能捕獲從 EL1 到 PSTATE.AllInt 的寫入。這種屏蔽模式預計將由主要需要 NMI 來進行分析支持并希望避免實現基于優先級的偽 NMI 的復雜性的操作系統使用。Arm 期望 Linux 內核從這種屏蔽模式中受益。例如，KVM 中的 VM 入口路徑會在即將運行 VM 時通過設置 PSTATE.I 來屏蔽正常中斷。KVM 隨后會在設置異常返回寄存器以進入 VM 之前設置 PSTATE.AllInt。在 EL1 中運行 VM 時，針對 EL2 的物理中斷不會被 PSTATE 位屏蔽（它們現在只屏蔽虛擬中斷）。通過使用這個新的 PSTATE.AllInt 控件，管理程序避免了必須臨時管理優先級掩碼和 PSTATE.I，如上一節所述。

2021 擴展還為 GIC 添加了一個新的中斷確認寄存器 ICC_NMIAR1_EL1，可用于將 NMI 與其他中斷分開確認。引入此功能是為了避免軟件無意中從無法處理該中斷的上下文中確認中斷的情況。例如，當在設置了 PSTATE.I 的關鍵部分期間發出對電平敏感的 NMI 信號時，可能會發生這種情況，但在軟件確認中斷之前 NMI 的電平被取消斷言。

NMI 的虛擬化支持

2021 擴展支持在 EL2 上運行的虛擬機管理程序的控制下，在 EL1 的虛擬機中運行的來賓操作系統的虛擬 NMI。CPU 架構支持分別為 EL1 和 EL2 選擇掩碼模式。屏蔽模式分別使用 SCTLR_EL1 和 SCTRL_EL2 為 EL1 和 EL2 選擇，PSTATE 中的屏蔽狀態自然由管理程序通過 SPSR_EL2 保存和恢復。GIC 的虛擬 CPU 接口獲得與物理 CPU 接口相同的能力，用于單獨確認和識別虛擬 NMI。

在支持 NMI 的硬件系統上運行的 Hypervisor 軟件需要擴展以支持虛擬 NMI。2021 擴展包括通過擴展 EL2 列表寄存器 (LR) 對 NMI 的虛擬化支持，其中包含要傳遞給 VM 的虛擬中斷。LR 獲得一個新的 NMI 位，以指示虛擬中斷在呈現給虛擬 CPU 接口時具有 NMI 優先級。支持直接注入虛擬 SGI 的 GIC 實現也支持配置狀態以直接注入具有 NMI 優先級的虛擬 SGI。

虛擬 GIC 分配器和再分配器由軟件中的管理程序模擬。必須使用用于配置中斷的 NMI 優先級的新寄存器來擴展軟件仿真，最后需要進行一些小的更改以在虛擬功能寄存器中公開對 NMI 的支持。

結論

總之，在 2021 架構擴展中引入 NMI 提供了一個簡單的編程模型，可以實現常見的 NMI 用例。在設計此功能時，與生態系統合作，以確保我們能夠提供必要的靈活性來滿足通用內核和虛擬機管理程序對 NMI 的不同要求。