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

對 NMI 的需求

讓我們首先探討為什么需要一類特殊的中斷以及為什么我們稱它們?yōu)椴豢善帘巍Ｊ紫纫庾R到，所有中斷在某些情況下都是可屏蔽的。例如，如果中斷控制器完全關(guān)閉，則不會向 CPU 傳遞任何中斷。術(shù)語不可屏蔽中斷實際上涵蓋了一類中斷，即使“正?！敝袛啾黄帘?，仍可以將其傳遞給 CPU。NMI 仍然可以被屏蔽，但是通過標(biāo)準(zhǔn)內(nèi)核代碼難以訪問的單獨(dú)控制狀態(tài)。在某些情況下屏蔽所有中斷的能力也存在于其他具有悠久 NMI 歷史的架構(gòu)上。

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

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

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

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

最新架構(gòu)擴(kuò)展支持 NMI

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

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

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

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

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

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

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

NMI 的虛擬化支持

2021 擴(kuò)展支持在 EL2 上運(yùn)行的虛擬機(jī)管理程序的控制下，在 EL1 的虛擬機(jī)中運(yùn)行的來賓操作系統(tǒng)的虛擬 NMI。CPU 架構(gòu)支持分別為 EL1 和 EL2 選擇掩碼模式。屏蔽模式分別使用 SCTLR_EL1 和 SCTRL_EL2 為 EL1 和 EL2 選擇，PSTATE 中的屏蔽狀態(tài)自然由管理程序通過 SPSR_EL2 保存和恢復(fù)。GIC 的虛擬 CPU 接口獲得與物理 CPU 接口相同的能力，用于單獨(dú)確認(rèn)和識別虛擬 NMI。

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

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

結(jié)論

總之，在 2021 架構(gòu)擴(kuò)展中引入 NMI 提供了一個簡單的編程模型，可以實現(xiàn)常見的 NMI 用例。在設(shè)計此功能時，與生態(tài)系統(tǒng)合作，以確保我們能夠提供必要的靈活性來滿足通用內(nèi)核和虛擬機(jī)管理程序?qū)?NMI 的不同要求。