1、MMU概念介紹

MMU分為兩個部分: TLB maintenance 和 address translation

MMU的作用，主要是完成地址的翻譯，即虛擬地址到物理地址的轉換，無論是main-memory地址(DDR地址)，還是IO地址(設備device地址)，在開啟了MMU的系統中，CPU發起的指令讀取、數據讀寫都是虛擬地址，在ARM Core內部，會先經過MMU將該虛擬地址自動轉換成物理地址，然后在將物理地址發送到AXI總線上，完成真正的物理內存、物理設備的讀寫訪問.

那么為什么要用MMU？為什么要用虛擬地址？以下總結了三點：

多個程序獨立執行 --- 不需要知道具體物理地址

虛擬地址是連續的 --- 程序可以在多個分段的物理內存運行

允許操作系統管理內存 --- 哪些是可見的，哪些是允許讀寫的，哪些是cacheable的……

既然MMU開啟后，硬件會自動的將虛擬地址轉換成物理地址，那么還需要我們軟件做什么事情呢？即創建一個頁表翻譯都需要做哪些事情呢？或者說啟用一個MMU需要軟件做什么事情呢？

設置頁表基地址VBAR_EL3 (Specify the location of the translation table)

初始化MAIR_EL3 (Memory Attribute Indirection Register)

配置TCR_EL3 (Configure the translation regime)

創建頁表 (Generate the translation tables)

Enable the MMU

2、虛擬地址空間和物理地址空間

2.1、(虛擬/物理)地址空間的范圍

內核虛擬地址空間的范圍是什么？應用程序的虛擬地址空間的范圍是什么？以前我們在學習操作系統時，最常看到的一句話是：內核的虛擬地址空間范圍是3G-4G地址空間，應用程序的虛擬地址空間的范圍是0-3G地址空間；到了aarch64上，則為 ：內核的虛擬地址空間是0xffff000000000000 - 0xffffffffffffffff , 應用程序的虛擬地址空間是: 0x0000000000000000 - 0x0000ffffffffffff.

做為一名杠精，必需告訴你這句話是錯誤的。錯誤主要有兩點：(1) arm處理器，并沒有規定你的內核必需要使用哪套地址空間，以上這是Linux Kernel自己的設計，它設計了讓Linux Kernel使用0xffff000000000000 - 0xffffffffffffffff地址區間，Userspace使用0x0000000000000000 - 0x0000ffffffffffff地址區間，這里正好可以舉一個反例，比如optee os，它的kernel mode和user mode使用的都是高位的虛擬地址空間。(2) 高位是有幾個F（幾個1）是根據你操作系統使用的有效虛擬地址位來決定的，也并非固定的。比如optee中的mode和user mode的虛擬地址空間范圍都是：0x0000000000000000 - 0x00000000ffffffff

其實arm文檔中有一句標準的描述 :高位是1的虛擬地址空間，使用TTBR1ELx基地址寄存器進行頁表翻譯；高位是0的虛擬地址空間，使用TTBR0ELx基地址寄存器頁表翻譯。 所以不應該說，因為你使用了哪個寄存器(TTBR0/TTBR1)，然后決定了你使用的哪套虛擬地址空間；應該說，你操作系統(或userspace軟件)使用了哪套虛擬地址空間，決定了使用哪個哪個基地址寄存器(TTBR0/TTBR1)進行翻譯。

如下便是兩套虛擬地址空間和TTBRn_ELx的對應關系，其中高位的位數不是固定的16(即T1SZ和T0SZ不一定等于16)

以下摘自ARM文檔的官方描述：

As Figure shows, for 48-bit VAs:? The address range translated using TTBR0ELx is 0x0000000000000000 to 0x0000FFFFFFFFFFFF.? The address range translated using TTBR1ELx is 0xFFFF000000000000 to 0xFFFFFFFFFFFFFFFF.In an implementation that includes ARMv8.2-LVA and is using Secure EL3 the 64KB translation granule, for 52-bit VAs:? The address range translated using TTBR0ELx is 0x0000000000000000 to 0x000FFFFFFFFFFFFF.? The address range translated using TTBR1ELx is 0xFFF0000000000000 to 0xFFFFFFFFFFFFFFFF.Which TTBRELx is used depends only on the VA presented for translation. The most significant bits of the VA must all be the same value and:? If the most significant bits of the VA are zero, then TTBR0ELx is used.? If the most significant bits of the VA are one, then TTBR1_ELx is used.

2.2、物理地址空間有效位(范圍)

具體每一個core的物理地址是多少位，其實都是定死的，虛擬地址是多少位，是編譯或開發的時候根據自己的需要自己配置的。如下表格摘出了部分arm core的物理地址有效位，所以你具體使用多少有效位的物理地址，可以查詢core TRM手冊。

2.2.1、頁表翻譯相關寄存器的配置

ID_AA64MMFR0_EL1.PARange: Physical address size : 讀取arm寄存器，得到當前系統支持的有效物理地址是多少位

TCR_EL1.IPS: Output address size : 告訴mmu，你需要給我輸出多少位的物理地址

TCR_EL1.T0SZ和TCR_EL1.T1SZ: Input address size : 告訴mmu，我輸入的是多少有效位的虛擬地址

3、Translation regimes

內存管理單元 (MMU) 執行地址翻譯。MMU 包含以下內容：

The table walk unit : 它從內存中讀取頁表，并完成地址轉換

Translation Lookaside Buffers (TLBs) ：緩存，相當于cache

軟件看到的所有內存地址都是虛擬的。這些內存地址被傳遞到 MMU，它檢查最近使用的緩存轉換的 TLB。如果 TLB沒有找到最近緩存的翻譯，那么翻譯單元將從內存中讀取適當的一個或多個表項目進行地址翻譯，如下所示：

Translation tables 的工作原理是將虛擬地址空間劃分為大小相等的塊，并在表中為每個塊提供一個entry。Translation tables 中的entry 0 提供block 0 的映射，entry 1 提供block 1 的映射，依此類推。每個entry都包含相應物理內存塊的地址以及訪問物理地址時要使用的屬性。

在當前的ARMV8/ARMV9體系中(暫不考慮armv9的RME擴展), 至少存在以下9類Translation regime：

Secure EL1&0 translation regime, when EL2 is disabledNon-secure EL1&0 translation regime, when EL2 is disabledSecure EL1&0 translation regime, when EL2 is enabledNon-secure EL1&0 translation regime, when EL2 is enabledSecure EL2&0 translation regimeNon-secure EL2&0 translation regimeSecure EL2 translation regimeNon-secure EL2 translation regimeSecure EL3 translation regime

這9類Translation regime的地址翻譯的場景如下圖所示：

Secure and Non-secure地址空間在REE(linux)和TEE(optee)雙系統的環境下，可同時開啟兩個系統的MMU.

在secure和non-secure中使用不同的頁表.secure的頁表可以映射non-secure的內存，而non-secure的頁表不能去映射secure的內存，否則在轉換時會發生錯誤

Two Stage TranslationsEL1&0 Translation regime處于VM(Virtual Machine)或SP(Secure Partition)時，EL2 enabled的情況下，是需要stage2轉換的。對于EL2 Translation regime 和 EL3 Translation regime是沒用stage2 轉換的。

4、地址翻譯/幾級頁表？

4.1、思考：頁表到底有幾級？

從以下圖來看，有的頁表從L2開始，有得從L1開始，有的從L0開始，還有從L-1開始的，都是到L3終止。那么我們的頁表到底有幾級呢？

4.2、以4KB granule為例，頁表的組成方式

除了第一級index(這里是leve 0 table中的index)，每一個查找table/page的index都是9個bit，也就是說除了第一級頁表，后面的每一級table都是有512個offset

如果VA_BIT = 39，那么leve 0 table用BIT[38:39]表示，只有1個offset

如果VA_BIT = 48，那么leve 0 table用BIT[47:39]表示，有512個offset

如果VABIT > 48，那是不存在的，因為arm規定，大于48的，只有一個，那就是VABIT=52，并且規定該情況下的最小granue size=64KB，而我們這里講述的是granue size=4KB的情況

如果VABIT = 32，那么leve 0 table就不用了，TTBRELx指向Level 1 table

另外我們還需注意一點，在Level 0 table中，他只能指向DTable，不能指向DBlock

以下針對虛擬地址是48有效位的情形做了一個總結：

4.3、optee實際使用的示例

32位有效虛擬地址、，3級頁表查詢(L1、L2、L3)，顆粒的位4KB

如下展示是optee os的頁表結構，TTBR0_EL1指向L1 Table，L1 Table中有4個表項，但只用了3個 , 也就對應著3張L2 Table.

配置相關的代碼如下：

5、頁表格式（Descriptor format）

5.1、ARMV8支持的3種頁表格式

AArch64 Long Descriptor:我們只學習這個

Armv7-A Long Descriptor ：for Large Physical Address Extension (LPAE)

Armv7-A Short Descriptor

5.2、AArch64 Long Descriptor支持的四種entry

對于AArch64 Long Descriptor，又分為下面四種entry：

An invalid or fault entry.

A table entry, that points to the next-level translation table.

A block entry, that defines the memory properties for the access.

A reserved format

注意：entry[1:0] 表示該entry屬于哪類entry， Block Descriptor和Page Descriptor是一個意思。在當前架構中，reserved也是invalid。

5.3、頁表的屬性位介紹（ Block Descriptor/Page Descriptor ）

5.3.1、stage1的頁表屬性

（Attribute fields in stage 1 VMSAv8-64 Block and Page descriptors）

PBHA, bits[62:59] ：for FEAT_HPDS2

XN or UXN, bit[54] ：Execute-never or Unprivileged execute-never

PXN, bit[53] ：Privileged execute-never

Contiguous, bit[52] ：translation table entry 是連續的，可以存在一個TLB Entry中

DBM, bit[51] ：Dirty Bit Modifier

GP, bit[50] ：for FEAT_BTI

nT, bit[16] ：for FEAT_BBM

nG, bit[11] ：緩存在TLB中的翻譯是否使用ASID標識

AF, bit[10] ：Access flag, AF=0后，第一次訪問該頁面時，會將該標志置為1. 即暗示第一次訪問

SH, bits[9:8] ：shareable屬性

AP[2:1], bits[7:6] ：Data Access Permissions bits,

NS, bit[5] ：Non-secure bit

AttrIndx[2:0], bits[4:2] ：

5.3.2、stage2的頁表屬性

（Attribute fields in stage 2 VMSAv8-64 Block and Page descriptors）

PBHA[3:1], bits[62:60] ：for FEAT_HPDS2

PBHA[0], bit[59] ：for FEAT_HPDS2

XN[1:0], bits[54:53] ：Execute-never

Contiguous, bit[52] ：translation table entry 是連續的，可以存在一個TLB Entry中

DBM, bit[51] ：Dirty Bit Modifier

nT, bit[16] ：for FEAT_BBM

FnXS, bit[11] ：for FEAT_XS

AF, bit[10] ：Access flag

SH, bits[9:8] ：shareable屬性

S2AP, bits[7:6] ：Stage 2 data Access Permissions

MemAttr, bits[5:2] ：

5.3.3、其它標志位的詳細介紹

（1）、MemAttr指向MAIR_ELx寄存器中的attrn屬性域，表示內存的緩存屬性，如cachable、shareable等

（2）、NSNon-secure比特表示轉換后的物理地址是secure的還是non-secure的。

（3）、APData access permissions 數據訪問權限

（4）、SH

shareable屬性

（5）、AFAccess flag, AF=0后，第一次訪問該頁面時，會將該標志置為1. 即暗示第一次訪問（6）、nG對于 EL0/EL1 虛擬地址空間，Page Descriptor屬性字段中的 nG 位將轉換標記為Gloabl(G) 或non-Gloabl(nG)。例如，內核映射是Gloabl(G)翻譯，應用程序映射是non-Gloabl翻譯。Gloabl翻譯適用于當前正在運的任何應用程序。非全局翻譯僅適用于特定應用程序

non-Gloabl映射在 TLB 中使用 ASID進行標記。在 TLB 查找時，將 TLB 條目中的 ASID 與當前選擇的 ASID 進行比較。如果它們不匹配，則不使用TLB 條目。下圖顯示了內核空間中沒有 ASID 標記的全局映射和用戶空間中具有 ASID 標記的非全局映射

（7）、XN or UXN特權和非特權不可從該memory-region中執行指令的標志位：Execute-neverUnprivileged execute-never

6、地址翻譯指令介紹

address translation的指令大約14個：

總結一下：

7、地址翻譯相關的系統寄存器總結

地址轉換由系統寄存器的組合控制：

7.1 SCTLR_ELx

系統控制寄存器，控制著MMU、I-cache、D-cache的打開與關閉，也控制著translation table walks訪問內存的大小端。

M - Enable Memory Management Unit (MMU).

C - Enable for data and unified caches.

EE - Endianness of translation table walks.

7.2 TTBRn_ELx

BADDR : 基地址

ASID ：TLB entry區分user程序所用的ASID

7.3 TCR_ELx

在ARM Core中(aarch64)，有三個Translation Control Register 寄存器:

7.3 MAIR_ELx

內存屬性寄存器，分為8個Attrn，所以一個core，最多只支持8中內存屬性。頁表中的每一個entry，都會指向一個Attr域。

審核編輯 ：李倩