內(nèi)核態(tài)內(nèi)存的page table與用戶態(tài)內(nèi)存的page table

dean_go

看書上說，線性空間4G，前3G用于用戶進程，后1G用于內(nèi)核態(tài)。
每個用戶進程都有4G的線性空間。
那么每個進程都包含同樣的后1G空間，用于內(nèi)核態(tài)。那么這1G空間的頁表是怎么處理的？
每個進程都有一份copy嗎？
是什么時候copy的？

求大家指占迷津。

humjb_1983

dean_go 發(fā)表于 2013-12-26 12:27
看書上說，線性空間4G，前3G用于用戶進程，后1G用于內(nèi)核態(tài)。
每個用戶進程都有4G的線性空間。
那么每個進 ...

每個進程都有一份copy，當發(fā)生內(nèi)核態(tài)缺頁異常時，從內(nèi)核的主頁表中同步到進程自己的頁表中。

goter

內(nèi)核用的1G空間不需要頁表項

arm-linux-gcc

32位arm的實現(xiàn)方法：
1，每個進程有自己的一份kernel space頁表，也就是說每個進程自己的頁表就完整的表示了4G范圍的映射關(guān)系。
2，kernel的lowmem部分用一級頁表映射，每個entry對應(yīng)1M；vmalloc zone等非線性部分使用二級頁表來映射。
3，做ioremap時并不會更新本進程自己的內(nèi)核頁表，而是更新內(nèi)核主頁表（0xc0004000這個地方），于是本進程在首次使用這個ioremap的返回值時，就會發(fā)生異常，然后在異常處理中會去將內(nèi)核一級主頁表中的對應(yīng)entry同步到本進程的內(nèi)核頁表中，然后重新執(zhí)行發(fā)生異常處的指令，此時本進程的一級頁表中的對應(yīng)entry已經(jīng)有了內(nèi)容，這個內(nèi)容是指向的二級頁表，而二級頁表中的對應(yīng)entry已經(jīng)在ioremap時填好了，所以這次就能夠正常運行了。
4，做iounmap時，不會釋放二級頁表的buffer，只會將buffer里面的內(nèi)容設(shè)置為無效，內(nèi)核主頁表和本進程的內(nèi)核頁表的一級頁表對應(yīng)的entry也仍然會一直指向這個buffer。然后如果對iounmap的地址再訪問，在做虛擬到物理地址轉(zhuǎn)換時，就會發(fā)現(xiàn)對應(yīng)二級頁表中的entry內(nèi)容是非法的，于是發(fā)生異常。當下一次再有ioremap時，就又會重復(fù)利用這個已經(jīng)分配的二級頁表的buffer。

64位arm的實現(xiàn)方法：
用戶空間和內(nèi)核空間的頁表是分離的，TTBR0用來指向用戶空間頁表，TTBR1用來指向內(nèi)核空間頁表，這樣就不存在從內(nèi)核主頁表同步的問題了。
其實armv7中已經(jīng)實現(xiàn)了分離頁表，只是kernel中還沒有使用。
在arm64分支中就用上了分離頁表，因為內(nèi)核地址和用戶地址之間差距巨大（見Documentation\arm64\memory.txt），如果不分離的話，光是頁表就要占據(jù)上百M的內(nèi)存。

冬瓜頭

goter 發(fā)表于 2013-12-26 22:12
內(nèi)核用的1G空間不需要頁表項

哦？能否稍微詳細說一下巍峨不需要頁表項，沒有頁表項，怎么做的轉(zhuǎn)換呢？謝謝。

arm-linux-gcc

回復(fù) 3# goter


    只有mips才不需要吧，arm肯定是需要的，powerpc貌似也需要，x86不了解

xs3c

回復(fù) 6# arm-linux-gcc

32bit PPC BOOKE的話用三個TLB1 entry來映射lowmem，每個entry 對應(yīng)256M. highmem 還是跟arm32類似。
64bit PPC BOOKE 基本上幾個entry就把所有的內(nèi)存都一一映射了，另外你說Ioremap這些還是走swapper_dir。


   

kiongf

回復(fù) 3# goter


    如果內(nèi)核空間沒有頁表項, 那么支持大頁的架構(gòu)的內(nèi)核空間如何使用大頁？
   
   x86的架構(gòu) 就使用kernel_physical_mapping_init()函數(shù)初始化了一個swapper_pg_dir的paging hierarchy.