ARM MMU頁表框架
先上一張arm mmu的頁表結(jié)構(gòu)的通用框圖(以下的論述都由該圖來逐漸展開):
以上是arm的頁表框圖的典型結(jié)構(gòu),即是二級頁表結(jié)構(gòu)。
其中第一級頁表(L1)是由虛擬地址的高12bit(bits[31:20])組成,所以第一級頁表有4096個item,每個item占4個字節(jié),所以一級頁表的大小為16KB,而在第一級頁表中的每個entry的最低2bit可以用來區(qū)分具體是什么種類的頁表項,2bit可以區(qū)分4種頁表項,具體每種頁表項的結(jié)構(gòu)如下:
簡而言之L1頁表的頁表項主要有兩大類:
-
第一大類是指向第二級頁表(L2頁表)的基地址;
-
第二類直接指向1MB的物理內(nèi)存。
在L1頁表中每個表項可以覆蓋1MB的內(nèi)存,由于有4096K個選項(item),所以總計可以覆蓋4096K*1MB=4GB的內(nèi)存空間。
具體對應(yīng)到Linux,由于Linux的軟件架構(gòu)是支持3級頁表結(jié)構(gòu),而arm架構(gòu)實際只有2級的頁表結(jié)構(gòu),所以linux代碼中的中間級頁表的實現(xiàn)是空的。在linux代碼中,第一級的頁表的頁目錄表項用pgd表示,中間級的頁表的頁目錄表項用pud表示(arm架構(gòu)其實不需要),第三級的頁表的頁目錄表項用pmd表示(由于中間pud是空的,所以pgd=pmd),另外目前arm體系的移動設(shè)備中RAM的page大小一般都是4KB/page,所以L1頁表中的頁表項都是指向fine page table的。
但在linux內(nèi)核啟動的初始化階段,臨時建立頁表(initial page tables)以供linux內(nèi)核初始化提供執(zhí)行環(huán)境,這時L1的頁表項使用的就是第二種頁表項(section enty),他直接映射的是1M的內(nèi)存空間。具體的可以參考arch/arm/kernel/head.S中的__create_page_tables函數(shù),限于篇幅,這里就不展開說了。
針對這種section page translation,mmu硬件執(zhí)行虛擬地址轉(zhuǎn)物理地址的過程如下:
以上在初始化過程使用的臨時頁表(initial page tables),在內(nèi)核啟動的后期會被覆蓋掉,即在paging_init--->map_lowmem函數(shù)中會重新建立頁表,該函數(shù)為物理內(nèi)存從0地址到低端內(nèi)存(lowmem_limit)建立一個一一映射的映射表。所謂的一一映射就是物理地址和虛擬地址就差一個固定的偏移量,該偏移量一般就是0xc0000000(呵呵,為什么是0xc0000000?)。
說到這里引入一個重要的概念,就是與低端內(nèi)存相對的高端內(nèi)存,什么是高端內(nèi)存?為什么需要高端內(nèi)存?為了解析這個問題,我們假設(shè)我們使用的物理內(nèi)存有2GB大小,另外由于我們內(nèi)核空間的地址范圍是從3G-4G的空間,并且前面也說到了,linux內(nèi)核的低端內(nèi)存空間都是一一映射的,如果不引入高端內(nèi)存這個概念,全部都使用一一映射的方式,那內(nèi)核只能訪問到1GB的物理內(nèi)存,但實際上,我們是需要內(nèi)核在內(nèi)核空間能夠訪問所有的4GB的內(nèi)存大小的,那怎么做到呢?
方法就是我們不讓3G-4G的空間都使用一一映射,而是將物理地址的[0x00,fix_addr](fix_addr<1GB)映射到內(nèi)核空間虛擬地址[0x00+3G,fix_addr+3G],然后將[fix_addr+3G,4G]這段空間保留下來用于動態(tài)映射,這樣我們可以通過這段虛擬地址來訪問從fix_addr到4GB的物理內(nèi)存空間。怎么做到的呢?
譬如我們想要訪問物理地址[fix_addr,4GB]這段區(qū)間中的任何一段,我就用寶貴的內(nèi)核虛擬地址[fix_addr+3G,4G]的一段去映射他,建立好mmu硬件使用的頁表,訪問完后,將映射清除,將內(nèi)核的這段虛擬地址釋放,以供下次訪問其他的物理內(nèi)存使用。這樣就可以達到訪問所有4GB的物理內(nèi)存的目的。
那么內(nèi)核代碼是如何建立映射表的呢?
我們著重從arch/arm/mm/mmu.c中的create_mapping函數(shù)來分析。在分析之前我們先看下arm mmu硬件是如何在二級頁表結(jié)構(gòu)中,實現(xiàn)虛擬地址轉(zhuǎn)物理地址的。
先貼出原代碼(arch/arm/mm/mmu.c),該函數(shù)的功能描述如下:
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:參數(shù)合法性檢查,該函數(shù)不為用戶空間的虛擬地址建立映射表(記得多問自己一個為什么?)
line744-line750:如果是iomemory,則映射的虛擬地址范圍應(yīng)屬于高端內(nèi)存區(qū)間,由于我們這里是常規(guī)的memory,即type為MT_MEMORY,所以不會進入該分支。
line775: 獲得該虛擬地址addr屬于第一級頁表(L1)的哪個表項,詳細跟蹤pgd_offset_k函數(shù)(定義在:arch/arm/include/asm/pgtable.h),你會發(fā)現(xiàn),我們內(nèi)核的L1頁目錄表的基地址位于0xc0004000,而我們的內(nèi)核代碼則是放置在0xc0008000開始的位置。而從0xc0004000到0xc0008000區(qū)間大小是16KB,剛好就是L1頁表的大小(見文章開頭的描述)。
在這里需要注意一個概念:內(nèi)核的頁目錄表項和進程的頁目錄表項,內(nèi)核的頁目錄表項是對系統(tǒng)所有進程都是公共的;而進程的頁目錄表項則是跟特定進程相關(guān)的,每個應(yīng)用進程都有自己的頁目錄表項,但各個進程對應(yīng)的內(nèi)核空間的頁目錄表相都是一樣的。正是由于每個進程都有自己的頁目錄表相,所以才能做到每個進程都可以獨立擁有屬于自己的[0,3GB]的內(nèi)存空間。
line778pgd_addr_end()確保[addr,next]地址不會跨越一個L1表項所能映射的最大內(nèi)存空間2MB(為什么是2MB而不是1MB呢?這個是linux的一個處理技巧,以后再詳細展開說)。
line780alloc_init_pud()函數(shù)為定位到的L1頁目錄表項pgd所指向的二級頁表(L2)建立映射表。
line784 pdg++下移L1頁目錄表項pgd,映射下一個2MB空間的虛擬地址到對應(yīng)的2MB的物理空間。
在這里解析下,為什么L1頁目錄表項pgd能夠映射2MB的虛地地址空間。
在本文的第一個圖中,他是arm典型的mmu映射框架圖,但并不是linux的,linux映射框架圖在它的基礎(chǔ)做了些調(diào)整和優(yōu)化。
linux所做的調(diào)整描述如下(以下摘自linux內(nèi)核: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:*
重要調(diào)整說明如下:
L1頁表從4096個item變?yōu)?048個item,但每個item的大小從原來的4字節(jié)變?yōu)?個字節(jié)。
一個page中,放置2個L2頁表,每個還是256項,每項是4個字節(jié),所以總計是256*2*4=2KB,放置在page頁的下半部,而上部分放置對應(yīng)的linux內(nèi)存管理系統(tǒng)使用的頁表,mmu硬件是不會去使用它的。所以剛好 占滿一個page頁的大小(4KB),這樣就不浪費空間了。
有了上面基礎(chǔ),下面再詳細的分析以上的line780的函數(shù)alloc_init_pud,該函數(shù)會最終調(diào)用到alloc_init_pte函數(shù):
line598early_pte_alloc函數(shù)判斷對應(yīng)的pmd所指向的L2頁表是否存在,如果不存在就分配L2頁表,如果存在就返回L2頁表所在page頁的虛地址。
line572 判斷pmd所指向的L2頁表是否存在,不存在則通過early_alloc 函數(shù)分配PTE_HWTABLE_OFF(512*4=2KB)+PTE_HWTABLE_SIZE(512*4=2KB)總計4KB的一個物理頁來存儲2個linuxpet 頁表+2個hwpte頁表。
line574返回這個物理頁所在虛擬地址,
回到alloc_init_pte函數(shù)的line599。
line183pte_index用來確定該虛擬地址在L2頁表中的偏移量。即虛擬地址的bit[12~21]共計9個bit,剛好用于尋址兩個L2頁表(總計512項)。
回到alloc_init_pte函數(shù),其中l(wèi)ine605行,是設(shè)置L2頁表中addr所定位到的頁表項(即pte),主要工作就是填充對應(yīng)物理頁的物理地址,以供mmu硬件來實現(xiàn)地址的翻譯。
line604~line607循環(huán)填充完兩個hwpte頁表,完成一個2M物理內(nèi)存的映射表的建立。
line608 將最終調(diào)用如下函數(shù):static inline void __pmd_populate(pmd_t *pmdp, phys_addr_t pte,pmdval_t prot)
在執(zhí)行這個函數(shù)之前,2個L2頁表已經(jīng)建立,該函數(shù)的作用就是設(shè)置L1頁表的對應(yīng)表項,使其指向剛建立的2個L2頁表(hwpte0,hwpte1),正如前面所說,由于linux的L1頁表項是8個字節(jié)大小,所以:
-
line133 將頭4個字節(jié)指向hwpte0頁表,
-
line135 將后4個字節(jié)指向hwpte1頁表,至此L1---〉L2頁表的關(guān)聯(lián)已經(jīng)建立。
-
line137 是刷新TLB緩沖,使系統(tǒng)的cpu都可以看見該映射的變化
至此已完成struct map_desc *md結(jié)構(gòu)體所指定的虛擬地址到物理地址的映射關(guān)系的建立,以供硬件mmu來自動實現(xiàn)虛擬到物理地址的翻譯。
以上過程,有選擇的將某些細節(jié)給省略了,限于篇幅,另外如果明白了這個過程,很細節(jié)的可以自己去看相關(guān)的代碼。譬如上面的set_pte_ext函數(shù),會調(diào)用的匯編函數(shù)來實現(xiàn)pte表項的設(shè)置。
-
ARM
+關(guān)注
關(guān)注
134文章
9084瀏覽量
367387 -
嵌入式
+關(guān)注
關(guān)注
5082文章
19104瀏覽量
304816 -
MMU
+關(guān)注
關(guān)注
0文章
91瀏覽量
18283
原文標題:帶你走進嵌入式ARM與MMU神秘的內(nèi)部世界
文章出處:【微信號:gh_c472c2199c88,微信公眾號:嵌入式微處理器】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論