理解 ARM64 內(nèi)核中對 52 位虛擬地址的支持
隨著 64 位硬件的引入,增加了處理更大地址空間的需求。
當 64 位硬件變得可用之后,處理更大地址空間(大于 232 字節(jié))的需求變得顯而易見?,F(xiàn)如今一些公司已經(jīng)提供 64TiB 或更大內(nèi)存的服務(wù)器,x86_64 架構(gòu)和 arm64 架構(gòu)現(xiàn)在允許尋址的地址空間大于 248 字節(jié)(可以使用默認的 48 位地址支持)。
x86_64 架構(gòu)通過讓硬件和軟件啟用五級頁表以支持這些用例。它允許尋址的地址空間等于 257 字節(jié)(詳情見 x86:在 4.12 內(nèi)核中啟用 5 級頁表)。它突破了過去虛擬地址空間 128PiB 和物理地址空間 4PiB 的上限。
arm64 架構(gòu)通過引入兩個新的體系結(jié)構(gòu) —— ARMv8.2 LVA(更大的虛擬尋址) 和 ARMv8.2 LPA(更大的物理地址尋址) —— 拓展來實現(xiàn)相同的功能。這允許使用 4PiB 的虛擬地址空間和 4PiB 的物理地址空間(即分別為 252 位)。
隨著新的 arm64 CPU 中支持了 ARMv8.2 體系結(jié)構(gòu)拓展,同時現(xiàn)在開源軟件也支持了這兩種新的硬件拓展。
從 Linux 5.4 內(nèi)核開始, arm64 架構(gòu)中的 52 位(大)虛擬地址(VA)和物理地址(PA)得到支持。盡管內(nèi)核文檔描述了這些特性和新的內(nèi)核運行時對舊的 CPU(硬件層面不支持 52 位虛擬地址拓展)和新的 CPU(硬件層面支持 52 位虛擬地址拓展)的影響,但對普通用戶而言,理解這些并且如何 “選擇使用” 52 位的地址空間可能會很復(fù)雜。
因此,我會在本文中介紹下面這些比較新的概念:
- 在增加了對這些功能的支持后,內(nèi)核的內(nèi)存布局如何“翻轉(zhuǎn)”到 Arm64 架構(gòu)
- 對用戶態(tài)應(yīng)用的影響,尤其是對提供調(diào)試支持的程序(例如:kexec-tools、 makedumpfile 和 crash-utility)
- 如何通過指定大于 48 位的 mmap 參數(shù),使用戶態(tài)應(yīng)用“選擇”從 52 位地址空間接受 VA?
ARMv8.2 架構(gòu)的 LVA 和 LPA 拓展
ARMv8.2 架構(gòu)提供兩種重要的拓展:大虛擬尋址(LVA)和大物理尋址(LPA)。
當使用 64 KB 轉(zhuǎn)換粒度時,ARMv8.2-LVA 為每個翻譯表基地址寄存器提供了一個更大的 52 位虛擬地址空間。
在 ARMv8.2-LVA 中允許:
- 當使用 64 KB 轉(zhuǎn)換粒度時,中間物理地址(IPA)和物理地址空間拓展為 52 位。
- 如果使用 64 KB 轉(zhuǎn)換粒度來實現(xiàn)對 52 位物理地址的支持,那么一級塊將會覆蓋 4TB 的地址空間。
需要注意的是這些特性僅在 AArch64 架構(gòu)中支持。
目前下列的 Arm64 Cortex-A 處理器支持 ARMv8.2 拓展:
- Cortex-A55
- Cortex-A75
- Cortex-A76
更多細節(jié)請參考 Armv8 架構(gòu)參考手冊。
Arm64 的內(nèi)核內(nèi)存布局
伴隨著 ARMv8.2 拓展增加了對 LVA 地址的支持(僅當以頁大小為 64 KB 運行時可用),在第一級轉(zhuǎn)換中,描述符的數(shù)量會增加。
用戶地址將 63-48 位位置為 0,然而內(nèi)核地址將這些位設(shè)置為 1。TTBRx 的選擇由虛擬地址的 63 位決定。swapper_pg_dir
僅包含內(nèi)核(全局)映射,然而 pgd
僅包含用戶(非全局)的映射。swapper_pg_dir
地址會寫入 TTBR1,且永遠不會寫入 TTBR0。
頁面大小為 64 KB 和三個級別的(具有 52 位硬件支持)的 AArch64 架構(gòu)下 Linux 內(nèi)存布局如下:
開始 結(jié)束 大小 用途
-----------------------------------------------------------------------
0000000000000000 000fffffffffffff 4PB 用戶
fff0000000000000 fff7ffffffffffff 2PB 內(nèi)核邏輯內(nèi)存映射
fff8000000000000 fffd9fffffffffff 1440TB [間隙]
fffda00000000000 ffff9fffffffffff 512TB Kasan 陰影區(qū)
ffffa00000000000 ffffa00007ffffff 128MB bpf jit 區(qū)域
ffffa00008000000 ffffa0000fffffff 128MB 模塊
ffffa00010000000 fffff81ffffeffff ~88TB vmalloc 區(qū)
fffff81fffff0000 fffffc1ffe58ffff ~3TB [保護區(qū)域]
fffffc1ffe590000 fffffc1ffe9fffff 4544KB 固定映射
fffffc1ffea00000 fffffc1ffebfffff 2MB [保護區(qū)域]
fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O 空間
fffffc1fffc00000 fffffc1fffdfffff 2MB [保護區(qū)域]
fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap
ffffffffffe00000 ffffffffffffffff 2MB [保護區(qū)域]
4 KB 頁面的轉(zhuǎn)換查詢表如下:
+--------+--------+--------+--------+--------+--------+--------+--------+
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+--------+--------+--------+--------+--------+--------+--------+--------+
| | | | | |
| | | | | v
| | | | | [11:0] 頁內(nèi)偏移量
| | | | +-> [20:12] L3 索引
| | | +-----------> [29:21] L2 索引
| | +---------------------> [38:30] L1 索引
| +-------------------------------> [47:39] L0 索引
+-------------------------------------------------> [63] TTBR0/1
64 KB 頁面的轉(zhuǎn)換查詢表如下:
+--------+--------+--------+--------+--------+--------+--------+--------+
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+--------+--------+--------+--------+--------+--------+--------+--------+
| | | | |
| | | | v
| | | | [15:0] 頁內(nèi)偏移量
| | | +----------> [28:16] L3 索引
| | +--------------------------> [41:29] L2 索引
| +-------------------------------> [47:42] L1 索引 (48 位)
| [51:42] L1 索引 (52 位)
+-------------------------------------------------> [63] TTBR0/1
arm64 Multi-level Translation
內(nèi)核對 52 位虛擬地址的支持
因為支持 LVA 的較新的內(nèi)核應(yīng)該可以在舊的 CPU(硬件不支持 LVA 拓展)和新的 CPU(硬件支持 LVA 拓展)上都正常運行,因此采用的設(shè)計方法是使用單個二進制文件來支持 52 位(如果硬件不支持該特性,則必須在剛開始啟動時能回退到 48 位)。也就是說,為了滿足 52 位的虛擬地址以及固定大小的 PAGE_OFFSET
,VMEMMAP
必須設(shè)置得足夠大。
這樣的設(shè)計方式要求內(nèi)核為了新的虛擬地址空間而支持下面的變量:
VA_BITS 常量 *最大的* 虛擬地址空間大小
vabits_actual 變量 *實際的* 虛擬地址空間大小
因此,盡管 VA_BITS
設(shè)置了最大的虛擬地址空間大小,但實際上支持的虛擬地址空間大小由 vabits_actual
確定(具體取決于啟動時的切換)。
翻轉(zhuǎn)內(nèi)核內(nèi)存布局
保持一個單一內(nèi)核二進制文件的設(shè)計方法要求內(nèi)核的 .text
位于高位地址中,因此它們對于 48/52 位虛擬地址是不變的。因為內(nèi)核地址檢測器(KASAN)區(qū)域僅占整個內(nèi)核虛擬地址空間的一小部分,因此對于 48 位或 52 位的虛擬地址空間,KASAN 區(qū)域的末尾也必須在內(nèi)核虛擬地址空間的上半部分。(從 48 位切換到 52 位,KASAN 區(qū)域的末尾是不變的,且依賴于 ~0UL
,而起始地址將“增長”到低位地址)
為了優(yōu)化 phys_to_virt()
和 virt_to_phys()
,頁偏移量將被保持在 0xFFF0000000000000
(對應(yīng)于 52 位),這消除了讀取額外變量的需求。在早期啟動時將會計算 physvirt
和 vmemmap
偏移量以啟用這個邏輯。
考慮下面的物理和虛擬 RAM 地址空間的轉(zhuǎn)換:
/*
* 內(nèi)核線性地址開始于虛擬地址空間的底部
* 測試區(qū)域開始處的最高位已經(jīng)是一個足夠的檢查,并且避免了擔心標簽的麻煩
*/
#define virt_to_phys(addr) ({ \
if (!(((u64)addr) & BIT(vabits_actual - 1))) \
(((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
})
#define phys_to_virt(addr) ((unsigned long)((addr) - PHYS_OFFSET) | PAGE_OFFSET)
在上面的代碼中:
PAGE_OFFSET — 線性映射的虛擬地址的起始位置位于 TTBR1 地址空間
PHYS_OFFSET — 物理地址的起始位置以及 vabits_actual — *實際的*虛擬地址空間大小
對用于調(diào)試內(nèi)核的用戶態(tài)程序的影響
有幾個用戶空間應(yīng)用程序可以用于調(diào)試正在運行的/活動中的內(nèi)核或者分析系統(tǒng)崩潰時的 vmcore 轉(zhuǎn)儲(例如確定內(nèi)核奔潰的根本原因):kexec-tools、makedumpfile 和 crash-utility。
當用它們來調(diào)試 Arm64 內(nèi)核時,因為 Arm64 內(nèi)核內(nèi)存映射被“翻轉(zhuǎn)”,因此也會對它們產(chǎn)生影響。這些應(yīng)用程序還需要遍歷轉(zhuǎn)換表以確定與虛擬地址相應(yīng)的物理地址(類似于內(nèi)核中的完成方式)。
相應(yīng)地,在將“翻轉(zhuǎn)”引入內(nèi)核內(nèi)存映射之后,由于上游破壞了用戶態(tài)應(yīng)用程序,因此必須對其進行修改。
我已經(jīng)提議了對三個受影響的用戶態(tài)應(yīng)用程序的修復(fù);有一些已經(jīng)被上游接受,但其他仍在等待中:
除非在用戶空間應(yīng)用程序進行了這些修改,否則它們將仍然無法調(diào)試運行/活動中的內(nèi)核或分析系統(tǒng)崩潰時的 vmcore 轉(zhuǎn)儲。
52 位用戶態(tài)虛擬地址
為了保持與依賴 ARMv8.0 虛擬地址空間的最大為 48 位的用戶空間應(yīng)用程序的兼容性,在默認情況下內(nèi)核會將虛擬地址從 48 位范圍返回給用戶空間。
通過指定大于 48 位的 mmap 提示參數(shù),用戶態(tài)程序可以“選擇”從 52 位空間接收虛擬地址。
例如:
.mmap_high_addr.c
----
maybe_high_address = mmap(~0UL, size, prot, flags,...);
通過啟用以下的內(nèi)核配置選項,還可以構(gòu)建一個從 52 位空間返回地址的調(diào)試內(nèi)核:
CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
請注意此選項僅用于調(diào)試應(yīng)用程序,不應(yīng)在實際生產(chǎn)中使用。
結(jié)論
總結(jié)一下:
- 內(nèi)核版本從 5.14 開始,新的 Armv8.2 硬件拓展 LVA 和 LPA 在內(nèi)核中得到良好支持。
- 像 kexec-tools 和 makedumpfile 被用來調(diào)試內(nèi)核的用戶態(tài)應(yīng)用程序現(xiàn)在無法支持新拓展,仍在等待上游接受修補。
- 過去的用戶態(tài)應(yīng)用程序依賴于 Arm64 內(nèi)核提供的 48 位虛擬地址將繼續(xù)原樣工作,而較新的用戶態(tài)應(yīng)用程序通構(gòu)指定超過 48 位更大的 mmap 提示參數(shù)來 “選擇加入”已接受來自 52 位的虛擬地址。