深入理解Linux記憶體映射機制

一. 緒 論
我們經常在程式的反組譯碼代碼中看到一些類似0x32118965這樣的地址，作業系統中稱為線性地址，或虛擬位址。虛擬位址有什麼用？虛擬位址
又是如何轉換為實體記憶體地址的呢？本章將對此作一個簡要闡述。
1.1  Linux記憶體定址概述
現代意義上的作業系統都處於32位保護模式下。每個進程一般都能定址4G的物理空間。但是我們的實體記憶體一般都是幾百M，進程怎麼能獲得4G
的物理空間呢？這就是使用了虛擬位址的好處，通常我們使用一種叫做虛擬記憶體的技術來實現，因為可以使用硬碟中的一部分來當作記憶體使用量
。例外一點現在作業系統都劃分為系統空間和使用者空間，使用虛擬位址可以很好的保護核心空間被使用者空間破壞。
對於虛擬位址如何轉為物理地址,這個轉換過程有作業系統和CPU共同完成. 作業系統為CPU設定好頁表。CPU通過MMU單元進行地址轉換。
1.2  瀏覽核心代碼的工具
現在的核心都很大， 因此我們需要某種工具來閱讀龐大的原始碼體系，現在的核心開發工具都選用vim+ctag+cscope瀏覽核心代碼，網上已有
現成的makefile檔案用來產生ctags/cscope/etags。
一、用法：
    找一個空目錄，把附件Makefile拷貝進去。然後在該目錄中選擇性地運行如下make命令：
$ make
將處理/usr/src/linux下的源檔案，在目前的目錄產生ctags, cscope
   註：SRCDIR用來指定核心原始碼目錄，如果沒有指定，則預設為/usr/src/linux/
1) 只建立ctags
$ make SRCDIR=/usr/src/linux-2.6.12/ tags
2) 只建立cscope
$ make SRCDIR=/usr/src/linux-2.6.12/ cscope
3) 建立ctags和cscope
$ make SRCDIR=/usr/src/linux-2.6.12/
4) 只建立etags
$ make SRCDIR=/usr/src/linux-2.6.12/ TAGS
二、處理時包括的核心源檔案：
1) 不包括drivers，sound目錄
2) 不包括無關的體繫結構目錄
3) fs目錄只包括頂層目錄和ext2，proc目錄
三、最簡單的ctags命令
1) 進入
進入vim後，用
:tag func_name
跳到函數func_name
2) 看函數（identifier）
想進入游標所在的函數，用
CTRL + ]
3) 回退
回退用    CTRL + T
1.3  核心版本的選取
本次論文分析， 我選取的是linux-2.6.10版本的核心。最新的核心代碼為2.6.25。但是現在主流的伺服器都使用的是RedHat AS4的機器，它使
用2.6.9的核心。我選取2.6.10是因為它很接近2.6.9，現在紅帽企業Linux 4以Linux2.6.9核心為基礎，是最穩定、最強大的商業產品。在2004
年期間，Fedora等開源項目為Linux 2.6核心技術的更加成熟提供了一個環境，這使得紅帽企業 Linux v.4核心可以提供比以前版本更多更好的
功能和演算法，具體包括:
? 通用的邏輯CPU發送器：處理多核心和超執行緒CPU。
? 基於對象的逆向映射虛擬記憶體：提高了記憶體受限系統的效能。
? 讀複製更新：針對作業系統資料結構的SMP演算法最佳化。
? 多I/O發送器：可根據應用環境進行選擇。
? 增強SMP和NUMA支援：提高了大型伺服器的效能和可擴充性。
? 網路中斷緩和（NAPI）：提高了大流量網路的效能。
Linux 2.6 核心使用了許多技術來改進對大量記憶體的使用，使得 Linux 比以往任何時候都更適用於企業。包括反向映射（reverse mapping）
、使用更大的記憶體頁、頁表條目儲存在高端記憶體中，以及更穩定的管理器。因此，我選取linux-2.6.10核心版本作為分析對象。

二. X86的硬體定址方法
請參考Intel x86手冊^_^

三. 核心對頁表的設定
CPU做出映射的前提是作業系統要為其準備好核心頁表，而對於頁表的設定，核心在系統啟動的初期和系統初始化完成後都分別進行了設定。
3.1 與記憶體映射相關的幾個宏
這幾個宏把不帶正負號的整數轉換成對應的類型
    #define __pte(x)              ((pte_t) { (x) } )
    #define __pmd(x)             ((pmd_t) { (x) } )
    #define __pgd(x)              ((pgd_t) { (x) } )
    #define __pgprot(x)            ((pgprot_t) { (x) } )
    根據x把它轉換成對應的不帶正負號的整數
    #define pte_val(x)              ((x).pte_low)
    #define pmd_val(x)             ((x).pmd)
    #define pgd_val(x)             ((x).pgd)
    #define pgprot_val(x)           ((x).pgprot)
    把核心空間的線性地址轉換為物理地址
    #define __pa(x)                ((unsigned long)(x)-PAGE_OFFSET)
    把物理地址轉化為線性地址
    #define __va(x)             ((void *)((unsigned long)(x)+PAGE_OFFSET))
  
    x是頁表項值， 通過pte_pfn得到其對應的物理頁框號， 最後通過pfn_to_page得到對應的物理頁描述符
    #define pte_page(x)             pfn_to_page(pte_pfn(x))
    如果對應的表項值為0， 返回1
    #define pte_none(x)             (!(x).pte_low)
    x是頁表項值， 右移12位後得到其對應的物理頁框號
    #define pte_pfn(x)         ((unsigned long)(((x).pte_low >> PAGE_SHIFT)))
根據頁框號和頁表項的屬性值合并成一個頁表項值
    #define pfn_pte(pfn, prot)     __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
    根據頁框號和頁表項的屬性值合并成一個中間表項值
    #define pfn_pmd(pfn, prot)   __pmd(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
    向一個表項中寫入指定的值
    #define set_pte(pteptr, pteval)         (*(pteptr) = pteval)
    #define set_pte_atomic(pteptr, pteval)   set_pte(pteptr,pteval)
    #define set_pmd(pmdptr, pmdval)      (*(pmdptr) = pmdval)
    #define set_pgd(pgdptr, pgdval)       (*(pgdptr) = pgdval)
    根據線性地址得到高10位值， 也就是在目錄表中的索引
    #define pgd_index(address) (((address)>>PGDIR_SHIFT) & (PTRS_PER_PGD-1))
    根據頁描述符和屬性得到一個頁表項值
    #define mk_pte(page, pgprot)    pfn_pte(page_to_pfn(page), (pgprot))
3.2核心頁表的初始化
核心在進入保護模式前， 還沒有啟用分頁功能， 在這之前核心要先建立一個臨時核心頁表，因為在進入保護模式後， 核心繼續初始化直到建
立完整的記憶體映射機制之前， 仍然需要用到頁表來映射相應的記憶體位址。 臨時頁表的初始化是在arch/i386/kernel/head.S中進行的：
swapper_pg_dir是臨時頁全域目錄表， 它是在核心編譯過程中靜態初始化的.
pg0是第一個頁表開始的地方， 它也是核心編譯過程中靜態初始化的.
核心通過以下代碼建立臨時頁表：
ENTRY(startup_32)
    …………
/* 得到開始目錄項的索引，從這可以看出核心是在swapper_pg_dir的768個表項開始進行建立的， 其對應的線性地址就是0xc0000000以上的地
址， 也就是核心在初始化它自己的頁表 */
        page_pde_offset = (__PAGE_OFFSET >> 20);
/* pg0地址在核心編譯的時候， 已經是加上0xc0000000了， 減去0xc00000000得到對應的物理地址 */
        movl $(pg0 - __PAGE_OFFSET), %edi
/* 將目錄表的地址傳給edx， 表明核心也要從0x00000000開始建立頁表， 這樣可以保證從以物理地址取指令到以線性地址在系統空間取指令
的平穩過渡， 下面會詳細解釋 */      
        movl $(swapper_pg_dir - __PAGE_OFFSET), %edx  
        movl $0x007, %eax          
        leal 0x007(%edi),%ecx      
        Movl %ecx,(%edx)
        movl %ecx,page_pde_offset(%edx)
        addl $4,%edx
        movl $1024, %ecx
11:
        stosl  addl $0x1000,%eax
        loop 11b
        /* 核心到底要建立多少頁表， 也就是要映射多少記憶體空間， 取決於這個判斷條件。在核心初始化程中核心只要保證能映射到包括內
核的程式碼片段，資料區段， 初始頁表和用於存放動態資料結構的128k大小的空間就行 */
        leal (INIT_MAP_BEYOND_END+0x007)(%edi),%ebp
        cmpl %ebp,%eax
        jb 10b
        movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
在上述代碼中， 核心為什麼要把使用者空間和核心空間的前幾個目錄項映射到相同的頁表中去呢，雖然在head.S中核心已經進入保護模式，但是
核心現在是處於保護模式的段式定址方式下，因為核心還沒有啟用分頁映射機制，現在都是以物理地址來取指令， 如果代碼中遇到了符號地址
，只能減去0xc0000000才行， 當開啟了映射機制後就不用了現在cpu中的取指令指標eip仍指向低區，如果只建立核心空間中的映射， 那麼當
核心開啟映射機制後， 低區中的地址就沒辦法定址了，應為沒有對應的頁表， 除非遇到某個符號地址作為絕對轉移或調用子程式為止。因此
要儘快開啟CPU的頁式映射機制.
movl $swapper_pg_dir-__PAGE_OFFSET,%eax
        movl %eax,%cr3          /* cr3控制寄存器儲存的是目錄表地址 */
        movl %cr0,%eax          /* 向cr0的最高位置1來開啟映射機制 */
        orl $0x80000000,%eax
        movl %eax,%cr0
        ljmp $__BOOT_CS,$1f     /* Clear prefetch and normalize %eip */
1:
        lss stack_start,%esp
通過ljmp $__BOOT_CS,$1f這條指令使CPU進入了系統空間繼續執行 因為__BOOT_CS是個符號地址，地址在0xc0000000以上。
在head.S完成了核心臨時頁表的建立後，它繼續進行初始化，包括初始化INIT_TASK，也就是系統開啟後的第一個進程;建立完整的中斷處理程
序，然後重新載入GDT描述符，最後跳轉到init/main.c中的start_kernel函數繼續初始化.
3.3核心頁表的完整建立
核心在start_kernel()中繼續做第二階段的初始化，因為在這個階段中， 核心已經處於保護模式下，前面只是簡單的設定了核心頁表， 核心
必須首先要建立一個完整的頁表才能繼續運行，因為記憶體定址是核心繼續啟動並執行前提。
pagetable_init()的代碼在mm/init.c中：
[start_kernel()>setup_arch()>paging_init()>pagetable_init()]
為了簡單起見， 我忽略了對PAE選項的支援。
static void __init pagetable_init (void)
{
       ……
        pgd_t *pgd_base = swapper_pg_dir;
        ……
        kernel_physical_mapping_init(pgd_base);
        ……
}
在這個函數中pgd_base變數指向了swapper_pg_dir， 這正是核心目錄表的開始地址，pagetable_init()函數在通過
kernel_physical_mapping_init()函數完成核心頁表的完整建立。
kernel_physical_mapping_init函數同樣在mm/init.c中， 我略去了與PAE模式相關的代碼：
static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
{
        unsigned long pfn;
        pgd_t *pgd;
        pmd_t *pmd;
        pte_t *pte;
        int pgd_idx, pmd_idx, pte_ofs;
        pgd_idx = pgd_index(PAGE_OFFSET);
        pgd = pgd_base + pgd_idx;
        pfn = 0;
        for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
                pmd = one_md_table_init(pgd);
                if (pfn >= max_low_pfn)
                        continue;
                for (pmd_idx = 0; pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn; pmd++, pmd_idx++) {
                unsigned int address = pfn * PAGE_SIZE + PAGE_OFFSET;
                ……
                pte = one_page_table_init(pmd);
                for (pte_ofs = 0; pte_ofs < PTRS_PER_PTE && pfn < max_low_pfn; pte++, pfn++, pte_ofs++) {
                      if (is_kernel_text(address))
                           set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
                      else
                           set_pte(pte, pfn_pte(pfn, PAGE_KERNEL));
               ……
         }
}
通過作者的注釋， 可以瞭解到這個函數的作用是把整個實體記憶體地址都映射到從核心空間的開始地址，即從0xc0000000的整個核心空間中，
直到實體記憶體映射完畢為止。這個函數比較長， 而且用到很多關於記憶體管理方面的宏定義，理解了這個函數， 就能大概理解核心是如何建立
頁表的，將這個抽象的模型完全的理解。 下面將詳細分析這個函數:
函數開始定義了4個變數pgd_t *pgd， pmd_t *pmd， pte_t *pte， pfn;
pgd指向一個目錄項開始的地址，pmd指向一個中間目錄開始的地址，pte指向一個頁表開始的地址pfn是頁框號被初始為0. pgd_idx根據
pgd_index宏計算結果為768，也是核心要從目錄表中第768個表項開始進行設定。 從768到1024這個256個表項被linux核心設定成核心目錄項，
低768個目錄項被使用者空間使用. pgd = pgd_base + pgd_idx; pgd便指向了第768個表項。
然後函數開始一個迴圈即開始填充從768到1024這256個目錄項的內容。
one_md_table_init()函數根據pgd找到指向的pmd表。
它同樣在mm/init.c中定義:
static pmd_t * __init one_md_table_init(pgd_t *pgd)
{
        pmd_t *pmd_table;
#ifdef CONFIG_X86_PAE
        pmd_table = (pmd_t *) alloc_bootmem_low_pages(PAGE_SIZE);
        set_pgd(pgd, __pgd(__pa(pmd_table) | _PAGE_PRESENT));
        if (pmd_table != pmd_offset(pgd, 0))
                BUG();
#else
        pmd_table = pmd_offset(pgd, 0);
#endif
        return pmd_table;
}
可以看出， 如果核心不啟用PAE選項， 函數將通過 pmd_offset返回pgd的地址。因為linux的二級映射模型，本來就是忽略pmd中間目錄表的。
接著又個判斷語句：
>> if (pfn >= max_low_pfn)
>>        continue;
這個很關鍵， max_low_pfn代表著整個實體記憶體一共有多少頁框。 當pfn大於max_low_pfn的時候，表明核心已經把整個實體記憶體都映射到了系
統空間中， 所以剩下有沒被填充的表項就直接忽略了。因為核心已經可以映射整個物理空間了， 沒必要繼續填充剩下的表項。
緊接著的第2個for迴圈，在linux的3級映射模型中，是要設定pmd表的， 但在2級映射中忽略， 只迴圈一次，直接進行頁表pte的設定。
>> address = pfn * PAGE_SIZE + PAGE_OFFSET;
address是個線性地址， 根據上面的語句可以看出address是從0xc000000開始的，也就是從核心空間開始，後面在設定頁表項屬性的時候會用
到它.
>> pte = one_page_table_init(pmd);
根據pmd分配一個頁表, 代碼同樣在mm/init.c中:
static pte_t * __init one_page_table_init(pmd_t *pmd)
{
        if (pmd_none(*pmd)) {
        pte_t *page_table = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
        set_pmd(pmd, __pmd(__pa(page_table) | _PAGE_TABLE));
        if (page_table != pte_offset_kernel(pmd, 0))
               BUG();
        return page_table;
        }
        return pte_offset_kernel(pmd, 0);
}
pmd_none宏判斷pmd表是否為空白, 如果為空白則要利用alloc_bootmem_low_pages分配一個4k大小的物理頁面。 然後通過set_pmd(pmd, __pmd
(__pa(page_table) | _PAGE_TABLE));來設定pmd表項。page_table顯然屬於線性地址，先通過__pa宏轉化為物理地址,在與上_PAGE_TABLE宏，
此時它們還是不帶正負號的整數，在通過__pmd把不帶正負號的整數轉化為pmd類型，經過這些轉換， 就得到了一個具有屬性的表項， 然後通過set_pmd宏設
置pmd表項.
接著又是一個迴圈，設定1024個頁表項。
is_kernel_text函數根據前面提到的address來判斷address線性地址是否屬於核心程式碼片段,它同樣在mm/init.c中定義:
static inline int is_kernel_text(unsigned long addr)
{
        if (addr >= (unsigned long)_stext && addr <= (unsigned long)__init_end)
                return 1;
        return 0;
}
_stext, __init_end是個核心符號， 在核心連結的時候產生的， 分別表示核心程式碼片段的開始和終止地址.
如果address屬於核心程式碼片段， 那麼在設定頁表項的時候就要加個PAGE_KERNEL_EXEC屬性，如果不是，則加個PAGE_KERNEL屬性.
#define _PAGE_KERNEL_EXEC /
        (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED)
      
#define _PAGE_KERNEL /
        (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_NX)
      
最後通過set_pte(pte, pfn_pte(pfn, PAGE_KERNEL));來設定頁表項， 先通過pfn_pte宏根據頁框號和頁表項的屬性值合并成一個頁表項值，
然戶在用set_pte宏把頁表項值寫到頁表項裡。
當pagetable_init()函數返回後，核心已經設定好了核心頁表，緊著調用load_cr3(swapper_pg_dir);
#define load_cr3(pgdir) /
        asm volatile("movl %0,%%cr3": :"r" (__pa(pgdir)))
將控制swapper_pg_dir送入控制寄存器cr3. 每當重新設定cr3時， CPU就會將頁面映射目錄所在的頁面裝入CPU內部快取中的TLB部分. 現
在記憶體中(實際上是快取中）的映射目錄變了，就要再讓CPU裝入一次。由於頁面映射機制本來就是開啟著的， 所以從這條指令以後就擴大
了系統空間中有映射地區的大小, 使整個映射覆蓋到整個實體記憶體(高端記憶體)除外. 實際上此時swapper_pg_dir中已經改變的目錄項很可能還
在快取中， 所以還要通過__flush_tlb_all()將快取中的內容沖刷到記憶體中，這樣才能保證記憶體中映射目錄內容的一致性。
3.4 對如何構建頁表的總結
通過上述對pagetable_init()的剖析， 我們可以清晰的看到， 構建核心頁表， 無非就是向相應的表項寫入下一級地址和屬性。 在核心空間
保留著一部分記憶體專門用來存放核心頁表.當cpu要進行定址的時候，無論在核心空間，還是在使用者空間， 都會通過這個頁表來進行映射。對於
這個函數， 核心把整個實體記憶體空間都映射完了， 當使用者空間的進程要使用實體記憶體時， 豈不是不能做相應的映射了？ 其實不會的， 核心
只是做了映射， 映射不代表使用， 這樣做是核心為了方便管理記憶體而已。

四. 執行個體分析映射機制
4.1範例程式碼
    通過前面的理論分析，我們通過編寫一個簡單的程式， 來分析核心是如何把線性地址映射到物理地址的。
[root@localhost temp]# cat test.c
#include <stdio.h>
void test(void)
{
        printf("hello, world./n");
}
int main(void)
{
        test();
}
這段代碼很簡單， 我們故意要main調用test函數， 就是想看下test函數的虛擬位址是如何映射成物理地址的。
4.2  段式映射分析
我們先編譯， 在反組譯碼下test檔案
[root@localhost temp]# gcc -o test test.c
[root@localhost temp]# objdump -d test
08048368 <test>:
8048368:       55                      push   %ebp
8048369:       89 e5                    mov    %esp,%ebp
804836b:       83 ec 08                  sub    $0x8,%esp
804836e:       83 ec 0c                  sub    $0xc,%esp
8048371:       68 84 84 04 08             push   $0x8048484
8048376:       e8 35 ff ff ff               call   80482b0 <printf@plt>
804837b:       83 c4 10                  add    $0x10,%esp
804837e:       c9                       leave
804837f:       c3                       ret
08048380 <main>:
8048380:       55                      push   %ebp
8048381:       89 e5                   mov    %esp,%ebp
8048383:       83 ec 08                 sub    $0x8,%esp
8048386:       83 e4 f0                 and    $0xfffffff0,%esp
8048389:       b8 00 00 00 00            mov    $0x0,%eax
804838e:       83 c0 0f                  add    $0xf,%eax
8048391:       83 c0 0f                  add    $0xf,%eax
8048394:       c1 e8 04                  shr    $0x4,%eax
8048397:       c1 e0 04                  shl    $0x4,%eax
804839a:       29 c4                    sub    %eax,%esp
804839c:       e8 c7 ff ff ff               call   8048368 <test>
80483a1:       c9                       leave
80483a2:       c3                       ret
80483a3:       90                       nop
從上述結果可以看到, ld給test()函數分配的地址為0x08048368.在elf格式的可執行檔代碼中，ld的實際位置總是從0x8000000開始安排程式
的程式碼片段， 對每個程式都是這樣。至於程式在執行時在實體記憶體中的實際位置就要由核心在為其建立記憶體映射時臨時做出安排， 具體地址則
取決於當時所分配到的實體記憶體頁面。假設該程式已經運行， 整個映射機制都已經建立好， 並且CPU正在執行main()中的call 8048368這條指
令， 要轉移到虛擬位址0x08048368去運行. 下面將詳細介紹這個虛擬位址轉換為物理地址的映射過程.
首先是段式映射階段。由於0x08048368是一個程式的入口，更重要的是在執行的過程中是由CPU中的指令計數器EIP所指向的， 所以在程式碼片段中
。 因此， i386CPU使用程式碼片段寄存器CS的當前值作為段式映射的選擇子， 也就是用它作為在段描述表的下標.那麼CS的值是多少呢？
用GDB調試下test：
(gdb) info reg
eax            0x10     16
ecx            0x1      1
edx            0x9d915c 10326364
ebx            0x9d6ff4 10317812
esp            0xbfedb480       0xbfedb480
ebp            0xbfedb488       0xbfedb488
esi            0xbfedb534       -1074940620
edi            0xbfedb4c0       -1074940736
eip            0x804836e        0x804836e
eflags          0x282    642
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
可以看到CS的值為0x73, 我們把它分解成二進位:
0000 0000 0111 0011
最低2位為3， 說明RPL的值為3， 應為我們這個程式本省就是在使用者空間，RPL的值自然為3.
第3位為0表示這個下標在GDT中。
高13位為14， 所以段描述符在GDT表的第14個表項中， 我們可以到核心代碼中去驗證下:
在i386/asm/segment.h中:
#define GDT_ENTRY_DEFAULT_USER_CS       14
#define __USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)
可以看到段描述符的確就是GDT表的第14個表項中。
我們去GDT表看看具體的表項值是什麼， GDT的內容在arch/i386/kernel/head.S中定義:
ENTRY(cpu_gdt_table)
        .quad 0x0000000000000000        /* NULL descriptor */
        .quad 0x0000000000000000        /* 0x0b reserved */
        .quad 0x0000000000000000        /* 0x13 reserved */
        .quad 0x0000000000000000        /* 0x1b reserved */
        .quad 0x0000000000000000        /* 0x20 unused */
        .quad 0x0000000000000000        /* 0x28 unused */
        .quad 0x0000000000000000        /* 0x33 TLS entry 1 */
        .quad 0x0000000000000000        /* 0x3b TLS entry 2 */
        .quad 0x0000000000000000        /* 0x43 TLS entry 3 */
        .quad 0x0000000000000000        /* 0x4b reserved */
        .quad 0x0000000000000000        /* 0x53 reserved */
        .quad 0x0000000000000000        /* 0x5b reserved */
        .quad 0x00cf9a000000ffff       /* 0x60 kernel 4GB code at 0x00000000 */
        .quad 0x00cf92000000ffff       /* 0x68 kernel 4GB data at 0x00000000 */
        .quad 0x00cffa000000ffff       /* 0x73 user 4GB code at 0x00000000 */
        .quad 0x00cff2000000ffff       /* 0x7b user 4GB data at 0x00000000 */
        .quad 0x0000000000000000        /* 0x80 TSS descriptor */
        .quad 0x0000000000000000        /* 0x88 LDT descriptor */
         /* Segments used for calling PnP BIOS */
        .quad 0x00c09a0000000000        /* 0x90 32-bit code */
        .quad 0x00809a0000000000        /* 0x98 16-bit code */
        .quad 0x0080920000000000        /* 0xa0 16-bit data */
        .quad 0x0080920000000000        /* 0xa8 16-bit data */
        .quad 0x0080920000000000        /* 0xb0 16-bit data */
         /*
         * The APM segments have byte granularity and their bases
         * and limits are set at run time.
         */
        .quad 0x00409a0000000000        /* 0xb8 APM CS    code */
        .quad 0x00009a0000000000        /* 0xc0 APM CS 16 code (16 bit) */
        .quad 0x0040920000000000        /* 0xc8 APM DS    data */
        .quad 0x0000000000000000        /* 0xd0 - unused */
        .quad 0x0000000000000000        /* 0xd8 - unused */
        .quad 0x0000000000000000        /* 0xe0 - unused */
        .quad 0x0000000000000000        /* 0xe8 - unused */
        .quad 0x0000000000000000        /* 0xf0 - unused */
        .quad 0x0000000000000000    /* 0xf8 - GDT entry 31: double-fault TSS */
.quad 0x00cffa000000ffff        /* 0x73 user 4GB code at 0x00000000 */
我們把這個值展開成二進位:
0000 0000 1100 1111 1111 1010 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111
根據上述對段描述符表項值的描述， 可以得出如下結論：
B0-B15, B16-B31是0， 表示基地址全為0.
L0-L15, L16-L19是1， 表示段的上限全是0xffff.
G位是1               表示段長度單位均為4KB。
D位是1               表示對段的訪問都是32位指令
P位是1               表示段在記憶體中。
DPL是3               表示特權級是3級
S位是1               表示為程式碼片段或資料區段
type為1010            表示程式碼片段， 可讀， 可執行， 尚未收到訪問
這個描述符指示了段從0地址開始的整個4G虛存空間，邏輯地址直接轉換為線性地址。
所以在經過段式映射後就把邏輯地址轉換成了線性地址， 這也是在linux中， 為什麼邏輯地址等同於線性地址的原因了。
4.3 頁式映射分析
現在進入頁式映射的過程了,  Linux系統中的每個進程都有其自身的頁面目錄PGD, 指向這個目錄的指標儲存在每個進程的mm_struct資料結構
中。 每當調度一個進程進入啟動並執行時候，核心都要為即將啟動並執行進程設定好控制寄存器cr3， 而MMU的硬體則總是從cr3中取得指向當前頁面目
錄的指標。當我們在程式中要轉移到地址0x08048368去的時候， 進程正在運行，cr3早以設定好，指向我們這個進程的頁面目錄了。 先將線性
地址0x08048368展開成二進位：
0000 1000 0000 0100 1000 0011 0110 1000
對照線性地址的格式，可見最高10位為二進位的0000 1000 00, 也就是十進位的32，所以MMU就以32為下標在其頁面目錄中找到其目錄項。這個
目錄項的高20位指向一個頁面表，CPU在這20位後添上12個0就得到頁面表的指標。找到頁面表以後， CPU再來看線性地址中的中間10位，
0001001000，即十進位的72.於是CPU就以此為下標在頁表中找相應的表項。表項值的高20位指向一個實體記憶體頁面，在後邊添上12個0就得到物
理頁面的開始地址。假設物理地址在0x620000的，線性地址的最低12位為0x368. 那麼test()函數的入口地址就為0x620000+0x368 = 0x620368
。

Copyright