共計 5139 個字符，預計需要花費 13 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章主要為大家展示了“ARM64 內核中對 52 位虛擬地址支持的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“ARM64 內核中對 52 位虛擬地址支持的示例分析”這篇文章吧。

隨著 64 位硬件的引入，增加了處理更大地址空間的需求。

當 64 位硬件變得可用之后，處理更大地址空間（大于 232 字節）的需求變得顯而易見。現如今一些公司已經提供 64TiB   或更大內存的服務器，x86_64 架構和 arm64 架構現在允許尋址的地址空間大于 248 字節（可以使用默認的 48 位地址支持）。

x86_64 架構通過讓硬件和軟件啟用五級頁表以支持這些用例。它允許尋址的地址空間等于 257 字節（詳情見  x86：在 4.12 內核中啟用 5 級頁表）。它突破了過去虛擬地址空間 128PiB 和物理地址空間 4PiB 的上限。

arm64 架構通過引入兩個新的體系結構 mdash; mdash; ARMv8.2 LVA（更大的虛擬尋址）和 ARMv8.2 LPA（更大的物理地址尋址）  mdash; mdash; 拓展來實現相同的功能。這允許使用 4PiB 的虛擬地址空間和 4PiB 的物理地址空間（即分別為 252 位）。

隨著新的 arm64 CPU 中支持了 ARMv8.2 體系結構拓展，同時現在開源軟件也支持了這兩種新的硬件拓展。

從 Linux 5.4 內核開始，arm64 架構中的 52 位（大）虛擬地址（VA）和物理地址（PA）得到支持。盡管內核文檔描述了這些特性和新的內核運行時對舊的 CPU（硬件層面不支持 52 位虛擬地址拓展）和新的 CPU（硬件層面支持 52 位虛擬地址拓展）的影響，但對普通用戶而言，理解這些并且如何“選擇使用”52 位的地址空間可能會很復雜。

因此，我會在本文中介紹下面這些比較新的概念：

鴻蒙官方戰略合作共建——HarmonyOS 技術社區

在增加了對這些功能的支持后，內核的內存布局如何“翻轉”到 Arm64 架構

對用戶態應用的影響，尤其是對提供調試支持的程序（例如：kexec-tools、makedumpfile 和 crash-utility）

如何通過指定大于 48 位的 mmap 參數，使用戶態應用“選擇”從 52 位地址空間接受 VA？

ARMv8.2 架構的 LVA 和 LPA 拓展

ARMv8.2 架構提供兩種重要的拓展：大虛擬尋址（LVA）和大物理尋址（LPA）。

當使用 64 KB 轉換粒度時，ARMv8.2-LVA 為每個翻譯表基地址寄存器提供了一個更大的 52 位虛擬地址空間。

在 ARMv8.2-LVA 中允許：

當使用 64 KB 轉換粒度時，中間物理地址（IPA）和物理地址空間拓展為 52 位。

如果使用 64 KB 轉換粒度來實現對 52 位物理地址的支持，那么一級塊將會覆蓋 4TB 的地址空間。

需要注意的是這些特性僅在 AArch74 架構中支持。

目前下列的 Arm64 Cortex-A 處理器支持 ARMv8.2 拓展：

Cortex-A55

Cortex-A75

Cortex-A76

更多細節請參考  Armv8 架構參考手冊。

Arm64 的內核內存布局

伴隨著 ARMv8.2 拓展增加了對 LVA 地址的支持（僅當以頁大小為 64 KB 運行時可用），在第一級轉換中，描述符的數量會增加。

用戶地址將 63-48 位位置為 0，然而內核地址將這些位設置為 1。TTBRx 的選擇由虛擬地址的 63 位決定。swapper_pg_dir  僅包含內核（全局）映射，然而  pgd  僅包含用戶（非全局）的映射。swapper_pg_dir  地址會寫入 TTBR1，且永遠不會寫入 TTBR0。

頁面大小為 64 KB 和三個級別的（具有 52 位硬件支持）的 AArch74 架構下 Linux 內存布局如下：

  開始   結束   大小   用途  ----------------------------------------------------------------------- 0000000000000000 000fffffffffffff 4PB  用戶  fff0000000000000 fff7ffffffffffff 2PB  內核邏輯內存映射  fff8000000000000 fffd9fffffffffff 1440TB [間隙] fffda00000000000 ffff9fffffffffff 512TB Kasan  陰影區  ffffa00000000000 ffffa00007ffffff 128MB bpf jit  區域  ffffa00008000000 ffffa0000fffffff 128MB  模塊  ffffa00010000000 fffff81ffffeffff ~88TB vmalloc  區  fffff81fffff0000 fffffc1ffe58ffff ~3TB [保護區域] fffffc1ffe590000 fffffc1ffe9fffff 4544KB  固定映射  fffffc1ffea00000 fffffc1ffebfffff 2MB [保護區域] fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O  空間  fffffc1fffc00000 fffffc1fffdfffff 2MB [保護區域] fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap ffffffffffe00000 ffffffffffffffff 2MB [保護區域]

4 KB 頁面的轉換查詢表如下：

 +--------+--------+--------+--------+--------+--------+--------+--------+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| +--------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | | | v | | | | | [11:0]  頁內偏移量  | | | | +-  [20:12] L3  索引  | | | +-----------  [29:21] L2  索引  | | +---------------------  [38:30] L1  索引  | +-------------------------------  [47:39] L0  索引  +-------------------------------------------------  [63] TTBR0/1

64 KB 頁面的轉換查詢表如下：

 +--------+--------+--------+--------+--------+--------+--------+--------+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| +--------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | v | | | | [15:0]  頁內偏移量  | | | +----------  [28:16] L3  索引  | | +--------------------------  [41:29] L2  索引  | +-------------------------------  [47:42] L1  索引  (48  位) | [51:42] L1  索引  (52  位) +-------------------------------------------------  [63] TTBR0/1

arm64 Multi-level Translation

內核對 52 位虛擬地址的支持

因為支持 LVA 的較新的內核應該可以在舊的 CPU（硬件不支持 LVA 拓展）和新的 CPU（硬件支持 LVA   拓展）上都正常運行，因此采用的設計方法是使用單個二進制文件來支持 52 位（如果硬件不支持該特性，則必須在剛開始啟動時能回退到 48   位）。也就是說，為了滿足 52 位的虛擬地址以及固定大小的  PAGE_OFFSET，VMEMMAP  必須設置得足夠大。

這樣的設計方式要求內核為了新的虛擬地址空間而支持下面的變量：

VA_BITS  常量  * 最大的 *  虛擬地址空間大小  vabits_actual  變量  * 實際的 *  虛擬地址空間大小 

因此，盡管  VA_BITS  設置了最大的虛擬地址空間大小，但實際上支持的虛擬地址空間大小由  vabits_actual  確定（具體取決于啟動時的切換）。

翻轉內核內存布局

保持一個單一內核二進制文件的設計方法要求內核的  .text  位于高位地址中，因此它們對于 48/52   位虛擬地址是不變的。因為內核地址檢測器（KASAN）區域僅占整個內核虛擬地址空間的一小部分，因此對于 48 位或 52   位的虛擬地址空間，KASAN 區域的末尾也必須在內核虛擬地址空間的上半部分。（從 48 位切換到 52 位，KASAN   區域的末尾是不變的，且依賴于  ~0UL，而起始地址將“增長”到低位地址）

為了優化  phys_to_virt()  和  virt_to_phys()，頁偏移量將被保持在  0xFFF0000000000000 （對應于 52 位），這消除了讀取額外變量的需求。在早期啟動時將會計算  physvirt  和  vmemmap  偏移量以啟用這個邏輯。

考慮下面的物理和虛擬 RAM 地址空間的轉換：

/* *  內核線性地址開始于虛擬地址空間的底部  *  測試區域開始處的最高位已經是一個足夠的檢查，并且避免了擔心標簽的麻煩  */ #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  mdash;  線性映射的虛擬地址的起始位置位于  TTBR1  地址空間  PHYS_OFFSET  mdash;  物理地址的起始位置以及  vabits_actual  mdash; * 實際的 * 虛擬地址空間大小 

對用于調試內核的用戶態程序的影響

有幾個用戶空間應用程序可以用于調試正在運行的 / 活動中的內核或者分析系統崩潰時的 vmcore 轉儲（例如確定內核奔潰的根本原因）：kexec-tools、makedumpfile 和 crash-utility。

當用它們來調試 Arm64 內核時，因為 Arm64 內核內存映射被“翻轉”，因此也會對它們產生影響。這些應用程序還需要遍歷轉換表以確定與虛擬地址相應的物理地址（類似于內核中的完成方式）。

相應地，在將“翻轉”引入內核內存映射之后，由于上游破壞了用戶態應用程序，因此必須對其進行修改。

我已經提議了對三個受影響的用戶態應用程序的修復；有一些已經被上游接受，但其他仍在等待中：

提議 makedumpfile 上游的修復

提議 kexec-tools 上游的修復

已接受的 crash-utility 的修復

除非在用戶空間應用程序進行了這些修改，否則它們將仍然無法調試運行 / 活動中的內核或分析系統崩潰時的 vmcore 轉儲。

52 位用戶態虛擬地址

為了保持與依賴 ARMv8.0 虛擬地址空間的最大為 48 位的用戶空間應用程序的兼容性，在默認情況下內核會將虛擬地址從 48 位范圍返回給用戶空間。

通過指定大于 48 位的 mmap 提示參數，用戶態程序可以“選擇”從 52 位空間接收虛擬地址。

例如：

.mmap_high_addr.c---- maybe_high_address = mmap(~0UL, size, prot, flags,...);

通過啟用以下的內核配置選項，還可以構建一個從 52 位空間返回地址的調試內核：

 CONFIG_EXPERT=y   CONFIG_ARM64_FORCE_52BIT=y

請注意此選項僅用于調試應用程序，不應在實際生產中使用。

以上是“ARM64 內核中對 52 位虛擬地址支持的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合！