1、實驗7 分頁存儲器管理實驗性質：驗證設計 建議學時：2學時 一、實驗目的 l 學習i386處理器的二級頁表硬件機制，理解分頁存儲器管理原理。 l 查看EOS應用程序進程和系統進程的二級頁表映射信息，理解頁目錄和頁表的管理方式。 l 編程修改頁目錄和頁表的映射關系，理解分頁地址變換原理。 二、預備知識 閱讀本書第6章。了解i386處理器的二級頁表硬件機制，EOS操作系統的分頁存儲器管理方式，以及進程地址空間的內存分布。 三、實驗內容 3.1 準備實驗 按照下面的步驟準備本次實驗： 1. 啟動OS Lab。 2. 新建一個EOS應用程序項目。 3.2 查看EOS應用程序進程的頁目錄和頁表 使用OS

2、 Lab打開本實驗文件夾中的memory.c和getcr3.asm文件（將文件拖動到OS Lab窗口中釋放即可打開）。仔細閱讀這兩個文件中的源代碼和注釋，main函數的流程圖可以參見圖16-1。 按照下面的步驟查看EOS應用程序進程的頁目錄和頁表： 1. 使用memory.c文件中的源代碼替換之前創建的EOS應用程序項目中EOSApp.c文件中的源代碼。 2. 右鍵點擊“項目管理器”窗口中的“源文件”文件夾節點，在彈出的快捷菜單中選擇“添加”中的“添加新文件”。 3. 在彈出的“添加新文件”對話框中選擇“asm 源文件”模板。 4. 在“名稱”中輸入文件名稱“func”。 5. 點擊“添加”按

3、鈕添加并自動打開文件func.asm。 6. 將getcr3.asm文件中的源代碼復制到func.asm文件中。 7. 按F7生成修改后的EOS應用程序項目。 8. 按F5啟動調試。 9. 應用程序執行的過程中，會將該進程的二級頁表映射信息輸出到虛擬機窗口和OS Lab“輸出”窗口中，輸出內容如圖16-2（a）。 10. 將“輸出”窗口中的內容復制到一個文本文件中。 圖16-2：（a）EOS應用程序進程的二級頁表映射信息 （b）有應用程序進程時，系統進程的二級頁表映射信息 圖16-2（a）中第一行是CR3寄存器的值，也就是頁目錄所在的頁框號。第一列是頁目錄中有效的PDE，第二列是PDE映射的頁

4、表中有效的PTE（詳細的格式可以參考源代碼中的注釋）。注意，在標號為0x200的PDE對應的頁表中，所有的1024個PTE都是有效的，所以在圖中省略了一部分。 根據圖16-2（a）回答下面的問題： l 應用程序進程的頁目錄和頁表一共占用了幾個物理頁？頁框號分別是多少？ l 映射用戶地址空間（低2G）的頁表的頁框號是多少？該頁表有幾個有效的PTE，或者說有幾個物理頁用來裝載應用程序的代碼、數據和堆棧？頁框號分別是多少？ 3.3 查看應用程序進程和系統進程并發時的頁目錄和頁表 需要對EOS應用程序進行一些修改： 1. 結束之前的調試。 2. 取消EOSApp.c第121行語句的注釋（該行語句會等待

5、10秒）。 3. 按F7生成修改后的EOS應用程序項目。 4. 按F5啟動調試。 5. 在“Console-1”中會自動執行EOSApp.exe，創建該應用程序進程。利用其等待10秒的時間，按Ctrl+F2切換到“Console-2”。 6. 在“Console-2”中輸入命令“mm”后按回車，會將系統進程的二級頁表映射信息輸出到虛擬機窗口和OS Lab的“輸出”窗口，輸出內容如圖16-2（b）。注意，在圖16-2（b）中添加了一些空行，方便與圖16-2（a）比較。“Console-1”中的應用程序在等待10秒后，又會輸出和圖16-2（a）一致的內容。 7. 將“輸出”窗口中的內容復制到一個文

6、本文件中。 控制臺命令“mm”對應的源代碼在EOS內核項目ke/sysproc.c文件的ConsoleCmdMemoryMap函數中（第382行）。閱讀這部分源代碼后會發現，其與EOSApp.c文件中的源代碼基本類似。 結合圖16-2（a）和（b）回答下面的問題： l EOS啟動后系統進程是一直運行的，所以當創建應用程序進程后，系統中就同時存在了兩個進程，這兩個進程是否有各自的頁目錄？在頁目錄映射的頁表中，哪些是獨占的，哪些是共享的？分析其中的原因。 l 統計當應用程序進程和系統進程并發時，總共有多少物理頁被占用？ 應用程序結束后，在“Console-1”中再次輸入命令“mm”，查看在沒有應用

7、程序進程時，系統進程的頁目錄和頁表。將“輸出”窗口中的內容復制到一個文本文件中。將輸出的內容與圖16-2（b）比較，思考為什么系統進程（即內核地址空間）占用的物理頁會減少？（提示：創建應用程序進程時，EOS內核要為其創建PCB，應用程序結束時，內核要釋放PCB占用的內存。） 3.4 查看應用程序進程并發時的頁目錄和頁表 需要對EOS應用程序進行一些修改： 1. 結束之前的調試。 2. 取消EOSApp.c第201行語句的注釋（該行語句會等待10秒）。 3. 按F7生成修改后的EOS應用程序項目。 4. 按F5啟動調試。 5. 在“Console-1”中會自動執行EOSApp.exe，創建該應用

8、程序進程。利用其等待10秒的時間，按Ctrl+F2切換到“Console-2”。 6. 在“Console-2”中輸入“eosapp”后按回車，再執行一個EOSApp.exe。 7. 由EOSApp.exe創建的兩個并發進程會先后在各自的控制臺和OS Lab“輸出”窗口中，輸出各自的二級頁表映射信息。輸出的內容如圖16-3。 8. 將“輸出”窗口中的內容復制到一個文本文件中。 圖16-3：（a）應用程序進程1的二級頁表映射信息 （b）應用程序進程2的二級頁表映射信息結合圖16-3（a）和（b）回答下面的問題： l 觀察這兩個進程的用戶地址空間，可以得出結論：同一個應用程序創建的兩個并發的進程，

9、它們的用戶虛擬地址空間完全相同，而映射的物理頁完全不同，從而保證相同的行為（執行過程）可以在獨立的空間內完成。 假設進程1的0x41E和0x41F物理頁保存了應用程序的可執行代碼，由于可執行代碼是不變的、只讀的，現在假設優化過的EOS允許進程2共享進程1的保存了可執行代碼的物理頁，嘗試結合圖16-3寫出此時進程2用戶地址空間的映射信息。并說明共享可執行代碼的物理頁能帶來哪些好處。 l 統計當兩個應用程序進程并發時，總共有多少物理頁被占用？有更多的進程同時運行呢？根據之前的操作方式，嘗試在更多的控制臺中啟動應用程序來驗證自己的想法。如果進程的數量足夠多，物理內存是否會用盡，如何解決該問題？ 3.

10、5 在二級頁表中映射新申請的物理頁 下面通過編程的方式，從EOS操作系統內核中申請兩個未用的物理頁，將第一個物理頁當作頁表，映射基址為0xE0000000的4M虛擬地址空間，然后將第二個物理頁分別映射到基址為0xE0000000和0xE0001000的4K虛擬地址空間。從而驗證下面的結論： l 雖然進程可以訪問4G虛擬地址空間，但是只有當一個虛擬地址通過二級頁表映射關系能夠映射到實際的物理地址時，該虛擬地址才能夠被訪問，否則會觸發異常。 l 所有未用的物理頁都是由EOS操作系統內核統一管理的，使用時必須向內核申請。 l 為虛擬地址映射物理頁時，必須首先為頁目錄安裝頁表，然后再為頁表安裝物理頁。

11、并且只有在刷新快表后，對頁目錄和頁表的更改才能生效。 l 不同的虛擬地址可以映射相同的物理頁，從而實現共享。 首先驗證第一個結論： 1. 新建一個 EOS Kernel項目。 2. 從“項目管理器”打開ke/sysproc.c文件。 3. 打開本實驗文件夾中的MapNewPage.c文件（將文件拖動到OS Lab窗口中釋放即可）。 4. 在sysproc.c文件的ConsoleCmdMemoryMap函數中找到“關中斷”的代碼行（第413行），將MapNewPage.c文件中的代碼插入到“關中斷”代碼行的后面。 5. 按F7生成該內核項目。 6. 按F5啟動調試。 7. 在EOS控制臺中輸入命

12、令“mm”后按回車。 8. OS Lab會彈出一個調試異常對話框，選擇“是”調試異常。 9. 黃色箭頭指向訪問虛擬地址0xE0000000的代碼行。由于該虛擬地址沒有映射物理內存（圖16-2和圖16-3中都未映射該虛擬地址），所以對該虛擬地址的訪問會觸發異常。 10. 結束此次調試，然后刪除或者注釋會觸發異常的該行代碼。 按照下面的步驟驗證其它結論： 1. 按F7生成該內核項目。 2. 按F5啟動調試。 3. 在EOS控制臺中輸入命令“mm”后按回車。 4. 在OS Lab的“輸出”窗口中查看執行的結果，并將“輸出”窗口中的內容復制到一個文本文件中。 結合插入的源代碼和執行的結果理解上面的結論

13、。注意，在代碼中修改了虛擬地址0xE0000000處的內存的值，然后從虛擬地址0xE0001000處讀取到了相同的值，原因是這兩處虛擬地址映射到了相同的物理頁。四、思考與練習 1. 觀察之前輸出的頁目錄和頁表的映射關系，可以看到頁目錄的第0x300個PDE映射的頁框號就是頁目錄本身，說明頁目錄被復用為了頁表。而恰恰就是這種映射關系決定了4K的頁目錄映射在虛擬地址空間的0xC0300000-0xC0300FFF,4M的頁表映射在0xC0000000-0xC03FFFFF。現在，假設修改了頁目錄，使其第0x100個PDE映射的頁框號是頁目錄本身，此時頁目錄和頁表會映射在4G虛擬地址空間的什么位置呢

14、？說明計算方法。 2. 修改EOSApp.c中的源代碼，通過編程的方式統計并輸出用戶地址空間占用的內存數目。 3. 修改EOSApp.c中的源代碼，通過編程的方式統計并輸出頁目錄和頁表的數目。注意頁目錄被復用為頁表。 4. 在EOS啟動時，軟盤引導扇區被加載到從0x7C00開始的512個字節的物理內存中，計算一下其所在的物理頁框號，然后根據物理內存與虛擬內存的映射關系得到其所在的虛擬地址。修改EOSApp.c中的源代碼，嘗試將軟盤引導扇區所在虛擬地址的512個字節值打印出來，與boot.lst文件中的指令字節碼進行比較，驗證計算的虛擬地址是否正確。 5. 既然所有1024個頁表（共4M）映射在虛擬地址空間的0xC0000000-