linux arm mmu基礎__linux

ARM MMU頁表架構

先上一張arm mmu的頁表結構的通用框圖（以下的論述都由該圖來逐漸展開）：

以上是arm的頁表框圖的典型結構：即是二級頁表結構：

其中第一級頁表（L1）是由虛擬位址的高12bit（bits[31：20]）組成,所以第一級頁表有4096個item，每個item佔4個位元組，所以一級頁表的大小為16KB，而在第一級頁表中的每個entry的最低2bit可以用來區分具體是什麼種類的頁表項，2bit可以區分4種頁表項，具體每種頁表項的結構如下：

簡而言之L1頁表的頁表項主要有兩大類:

第一大類是指向第二級頁表（L2頁表）的基地址;

第二類直接指向1MB的實體記憶體。

在L1頁表中每個表項可以覆蓋1MB的記憶體，由於有4096K個選項（item），所以總計可以覆蓋4096K*1MB=4GB的記憶體空間。

具體對應到linux，由於linux的軟體架構是支援3級頁表結構，而arm架構實際只有2級的頁表結構，所以linux代碼中的中間級頁表的實現是空的。在linux代碼中，第一級的頁表的頁目錄表項用pgd表示，中間級的頁表的頁目錄表項用pud表示（arm架構其實不需要），第三級的頁表的頁目錄表項用pmd表示（由於中間pud是空的，所以pgd=pmd），另外目前arm體系的行動裝置中RAM的page大小一般都是4KB/page，所以L1頁表中的頁表項都是指向fine page table的。

但在linux核心啟動的初始化階段，臨時建立頁表（initial page tables）以供linux核心初始化提供執行環境，這時L1的頁表項使用的就是第二種頁表項（section enty），他直接映射的是1M的記憶體空間。具體的可以參考arch/arm/kernel/head.S中的__create_page_tables函數，限於篇幅，這裡就不展開說了。

針對這種section page translation，mmu硬體執行虛擬位址轉物理地址的過程如下：

以上在初始化過程使用的臨時頁表（initial page tables），在核心啟動的後期會被覆蓋掉，即在paging_init--->map_lowmem函數中會重建立立頁表，該函數為實體記憶體從0地址到低端記憶體（lowmem_limit）建立一個一一映射的映射表。所謂的一一映射就是物理地址和虛擬位址就差一個固定的位移量，該位移量一般就是0xc0000000（呵呵，為什麼是0xc0000000。）

說到這裡引入一個重要的概念，就是與低端記憶體相對的高端記憶體，什麼是高端記憶體。為什麼需要高端記憶體。為瞭解析這個問題，我們假設我們使用的實體記憶體有2GB大小，另外由於我們核心空間的位址範圍是從3G-4G的空間，並且前面也說到了，linux核心的低端記憶體空間都是一一映射的，如果不引入高端記憶體這個概念，全部都使用一一映射的方式，那核心只能訪問到1GB的實體記憶體，但實際上，我們是需要核心在核心空間能夠訪問所有的4GB的記憶體大小的，那怎麼做到呢。

方法就是我們不讓3G-4G的空間都使用一一映射，而是將物理地址的[0x00，fix_addr]（fix_addr<1GB）映射到核心空間虛擬位址[0x00+3G，fix_addr+3G]，然後將[fix_addr+3G，4G]這段空間保留下來用於動態映射，這樣我們可以通過這段虛擬位址來訪問從fix_addr到4GB的實體記憶體空間。怎麼做到的呢。

譬如我們想要訪問物理地址[fix_addr，4GB]這段區間中的任何一段，我就用寶貴的核心虛擬位址[fix_addr+3G，4G]的一段去映射他，建立好mmu硬體使用的頁表，訪問完後，將映射清除，將核心的這段虛擬位址釋放，以供下次訪問其他的實體記憶體使用。這樣就可以達到訪問所有4GB的實體記憶體的目的。

那麼核心代碼是如何建立映射表的呢。

我們著重從arch/arm/mm/mmu.c中的create_mapping函數來分析。在分析之前我們先看下arm mmu硬體是如何在二級頁表結構中，實現虛擬位址轉物理地址的。

先貼出原代碼（arch/arm/mm/mmu.c）：

該函數的功能描述如下：

  Create the page directory entries and any necessary
  page tables for the mapping specified by `md'.  We
  are able to cope here with varying sizes and address
  offsets, and we take full advantage of sections and
  supersections.

line737-line742:參數合法性檢查，該函數不為使用者空間的虛擬位址建立映射表（記得多問自己一個為什麼。）

line744-line750：如果是iomemory，則映射的虛擬位址範圍應屬於高端記憶體區間，由於我們這裡是常規的memory，即type為MT_MEMORY，所以不會進入該分支

line775： 獲得該虛擬位址addr屬於第一級頁表（L1）的哪個表項，詳細跟蹤pgd_offset_k函數（定義在：arch/arm/include/asm/pgtable.h），你會發現，我們核心的L1頁目錄表的基地址位於0xc0004000，而我們的核心代碼則是放置在0xc0008000開始的位置。而從0xc0004000到0xc0008000區間大小是16KB，剛好就是L1頁表的大小（見文章開頭的描述）

在這裡需要注意一個概念：核心的頁目錄表項和進程的頁目錄表項，核心的頁目錄表項是對系統所有進程都是公用的；而進程的頁目錄表項則是跟特定進程相關的，每個應用進程都有自己的頁目錄表項，但各個進程對應的核心空間的頁目錄表相都是一樣的。正是由於每個進程都有自己的頁目錄表相，所以才能做到每個進程都可以獨立擁有屬於自己的[0，3GB]的記憶體空間。

line778 pgd_addr_end()確保[addr，next]地址不會跨越一個L1表項所能映射的最大記憶體空間2MB（為什麼是2MB而不是1MB呢。這個是linux的一個處理技巧，以後再詳細展開說）

line780 alloc_init_pud()函數為定位到的L1頁目錄表項pgd所指向的二級頁表（L2）建立映射表

line784 pdg++下移L1頁目錄表項pgd，映射下一個2MB空間的虛擬位址到對應的2MB的物理空間。

在這裡解析下，為什麼L1頁目錄表項pgd能夠映射2MB的虛地地址空間。

在本文的第一個圖中，他是arm典型的mmu映射架構圖，但並不是linux的，linux映射架構圖在它的基礎做了些調整和最佳化。

linux所做的調整描述如下（以下摘自linux核心：arch/arm/include/asm/pgtable-2level.h中提供的注釋說明）：

/*
 * Hardware-wise, we have a two level page table structure, where the first
 * level has 4096 entries, and the second level has 256 entries.  Each entry
 * is one 32-bit word.  Most of the bits in the second level entry are used
 * by hardware, and there aren't any "accessed" and "dirty" bits.
 *
 * Linux on the other hand has a three level page table structure, which can
 * be wrapped to fit a two level page table structure easily - using the PGD
 * and PTE only.  However, Linux also expects one "PTE" table per page, and
 * at least a "dirty" bit.
 *
 * Therefore, we tweak the implementation slightly - we tell Linux that we
 * have 2048 entries in the first level, each of which is 8 bytes (iow, two
 * hardware pointers to the second level.)  The second level contains two
 * hardware PTE tables arranged contiguously, preceded by Linux versions
 * which contain the state information Linux needs.  We, therefore, end up
 * with 512 entries in the "PTE" level.
 *
 * This leads to the page tables having the following layout:
 *

重要調整說明如下：

L1頁表從4096個item變為2048個item，但每個item的大小從原來的4位元組變為8個位元組。

一個page中，放置2個L2頁表，每個還是256項，每項是4個位元組，所以總計是256*2*4=2KB，放置在page頁的下半部，而上部分放置對應的linux記憶體管理系統使用的頁表，mmu硬體是不會去使用它的。所以剛好 佔滿一個page頁的大小（4KB），這樣就不浪費空間了。

     有了上面基礎，下面再詳細的分析以上的line780的函數alloc_init_pud，該函數會最終調用到alloc_init_pte函數：

                                                                

line598 early_pte_alloc函數判斷對應的pmd所指向的L2頁表是否存在，如果不存在就分配L2頁表，如果存在就返回L2頁表所在page頁的虛地址。

line572 判斷pmd所指向的L2頁表是否存在，不存在則通過early_alloc 函數分配PTE_HWTABLE_OFF（512*4=2KB）+PTE_HWTABLE_SIZE（512*4=2KB）總計4KB的一個物理頁來儲存2個linuxpet 頁表+2個hwpte頁表。

line574返回這個物理頁所在虛擬位址

回到alloc_init_pte函數的line599：

line183 pte_index用來確定該虛擬位址在L2頁表中的位移量。即虛擬位址的bit[12~21]共計9個bit，剛好用於定址兩個L2頁表（總計512項）

回到alloc_init_pte函數，其中line605行，是設定L2頁表中addr所定位到的頁表項（即pte），主要工作就是填充對應物理頁的物理地址，以供mmu硬體來實現地址的翻譯。

line604~line607迴圈填充完兩個hwpte頁表，完成一個2M實體記憶體的映射表的建立。

line608 將最終調用如下函數：static inline void __pmd_populate(pmd_t *pmdp, phys_addr_t pte, pmdval_t prot)

在執行這個函數之前，2個L2頁表已經建立，該函數的作用就是設定L1頁表的對應表項，使其指向剛建立的2個L2頁表（hwpte0，hwpte1），正如前面所說，由於linux的L1頁表項是8個位元組大小，所以：

line133 將頭4個位元組指向hwpte0頁表，

line135 將後4個位元組指向hwpte1頁表，至此L1---〉L2頁表的關聯已經建立。

line137 是重新整理TLB緩衝，使系統的cpu都可以看見該映射的變化

至此已完成struct map_desc *md結構體所指定的虛擬位址到物理地址的映射關係的建立，以供硬體mmu來自動實現虛擬到物理地址的翻譯。

以上過程，有選擇的將某些細節給省略了，限於篇幅，另外如果明白了這個過程，很細節的可以自己去看相關的代碼。譬如上面的set_pte_ext函數，會調用的彙編函數來實現pte表項的設定。