最近分析龍芯KVM的實(shí)現(xiàn)，順便又粗看了遍MIPS的手冊(cè)，跟KVM相關(guān)的主要模塊包括：

CPU虛擬化

內(nèi)存虛擬化

IO虛擬化

目前龍芯上CPU虛擬化跟標(biāo)準(zhǔn)內(nèi)核差異不大，需要軟硬件配合支持，目前龍芯整體能支持。 內(nèi)核虛擬化是龍芯KVM方案的關(guān)鍵，直接決定了性能，這也是本文的源頭。 IO虛擬化，目前龍芯由于沒有自己的橋片，很難做什么，主要基于KVM中現(xiàn)有的virtio(半虛擬化)，這里也不關(guān)注。

結(jié)構(gòu)化TLB

龍芯的內(nèi)存管理機(jī)制，最核心的莫過于MIPS中結(jié)構(gòu)化TLB的相關(guān)處理。

MIPS的MMU架構(gòu)

通常，處理器的MMU架構(gòu)分兩類：

結(jié)構(gòu)化頁表。這也是X86和PowerPC使用的方式。就是我們熟悉的：基于頁表來做虛擬地址到物理地址的映射，當(dāng)然，這種方式下，也存在TLB，但僅作為頁表的緩存。地址翻譯過程描述為：當(dāng)CPU需要做訪存操作時(shí)，MMU先在TLB中查詢相應(yīng)條目，如果沒找到，就從頁表中查找。如果頁表中找到，則填充TLB，如果沒找到，則觸發(fā)缺頁異常。這一整套操作都由MMU硬件完成。

結(jié)構(gòu)化TLB。這是MIPS使用的方式。核心思想是：所有的地址翻譯都經(jīng)過TLB完成。結(jié)構(gòu)化TLB中也存在頁表，但這基本由軟件(操作系統(tǒng)內(nèi)核)使用和維護(hù)；地址翻譯過程描述為：當(dāng)CPU需要做訪存操作時(shí)，MMU從TLB中查找，當(dāng)TLB中沒找到時(shí)，直接觸發(fā)TLB Miss(也叫TLB Refill)異常，TLB Miss異常處理中(內(nèi)核實(shí)現(xiàn))，完成TLB的填充，通常的實(shí)現(xiàn)為：也維護(hù)X86中類似的頁表，從頁表中取相應(yīng)的條目，填充到TLB中，其中還涉及更復(fù)雜的二次異常的邏輯，后面單獨(dú)介紹。TLB的填充操作完全由軟件負(fù)責(zé)，當(dāng)然，硬件層面有一些輔助，用于提升性能，后面單獨(dú)介紹。如此設(shè)計(jì)，利弊明顯。

• 好處：硬件設(shè)計(jì)簡(jiǎn)單，軟件實(shí)現(xiàn)靈活性大。
• 壞處：性能可能不足(還是要分場(chǎng)景)？

TLB Miss中Page Fault

如前所述，結(jié)構(gòu)化TLB中，當(dāng)TLB中不存在映射時(shí)，從頁表中找。那么，當(dāng)頁表中也不存在，此時(shí)該怎么辦？換句話說，頁表中的條目是從哪里來的？顯然硬件不會(huì)自動(dòng)生成。

這里需要明確：

• MIPS硬件實(shí)現(xiàn)上，沒有X86中對(duì)應(yīng)的缺頁異常。
• MIPS MMU硬件不會(huì)去查頁表，只會(huì)查TLB
• 頁表內(nèi)容顯然需要軟件來維護(hù)。

MIPS Exception

MIPS中的異常(Exception，翻譯可能有不同)分為兩類：

高優(yōu)先級(jí)。即需要盡快處理的異常，每種異常都有一個(gè)專用的固定的異常入口，因此可以得到快速處理。包含3種：

• NMI、啟動(dòng)、重啟
• TLB Refill，即TLB Miss異常。
• Cache Error

普通優(yōu)先級(jí)。即General Exception，也稱其它異常，即除上述高優(yōu)先級(jí)異常之外的所有異常(由CP0的STATUS寄存器[6:2]區(qū)分，也稱ExcCode)，都?xì)w屬于此類，如中斷、TLB Load/Store/Modify異常、系統(tǒng)調(diào)用等，此類異常對(duì)應(yīng)同一個(gè)異常入口地址(處理接口)，然后在該處理接口中根據(jù)不同的異常類型，調(diào)用不同的處理接口，相當(dāng)于將事件進(jìn)行了二次轉(zhuǎn)發(fā)處理，所以，相對(duì)于前面的高優(yōu)先級(jí)異常，處理較慢。

多數(shù)情形下（非嵌套），異常處理其實(shí)就相當(dāng)于一個(gè)伴隨模式切換的過程調(diào)用。異常的處理流程描述為：

異常發(fā)生后，MIPS置CP0寄存器Status[EXL] = 1，并將當(dāng)前PC值存入EPC(Exception PC，即指向發(fā)生異常的指令)。

從當(dāng)前指令流跳轉(zhuǎn)到異常處理接口。

MIPS硬件不負(fù)責(zé)保存上下文，因此需要軟件先保存上下文。

異常處理完成后，同樣由軟件負(fù)責(zé)恢復(fù)上下文，再執(zhí)行指令eret，從異常返回。

eret所作的操作為：將EPC/ErrorEPC的值置入PC，同時(shí)清除CP0_Status寄存器的EXL位。MIPS下，當(dāng)Status寄存器的EXL(exception)位為1，即表示處理器進(jìn)入異常處理，處于特權(quán)模式下。

需要注意：當(dāng)在異常處理過程中(Status[EXL] = 1)，又出現(xiàn)新異常時(shí)，CPU將不會(huì)重新設(shè)置EPC和CAUSE[BD]，當(dāng)新異常處理完成后，由于EPC之前沒有重置，就直接返回到發(fā)生異常原始指令處，在TLB Refill的情況下，通常返回用戶態(tài)。

頁表如何維護(hù)？

這是一個(gè)關(guān)鍵而且難以理解問題，每個(gè)進(jìn)程都有自己獨(dú)立的虛擬地址空間，即每個(gè)進(jìn)程都需要頁表，在X86中，MMU可以直接使用頁表(頁目錄地址寫到CR3寄存器中就可以了)，還可以通過page fault來動(dòng)態(tài)按需創(chuàng)建更新頁表項(xiàng)，但MIPS中沒有這樣的機(jī)制，怎么辦？

• 預(yù)先映射？即事先將頁表創(chuàng)建好，即靜態(tài)方式，那么映射2G的用戶態(tài)地址空間就需要4M大小的內(nèi)存?，F(xiàn)在內(nèi)存不值錢，多的是？但實(shí)際上進(jìn)程實(shí)際使用的內(nèi)存遠(yuǎn)比虛擬內(nèi)存小，這樣浪費(fèi)就有點(diǎn)過分了。

• 使用虛擬地址，動(dòng)態(tài)分配？主流MIPS中確實(shí)是這樣實(shí)現(xiàn)的。但這其中涉及一些關(guān)鍵問題：

  • 頁表使用的虛擬地址也需要做地址映射，而MIPS中，是基于TLB映射，而如果TLB中此時(shí)不存在此映射，顯然會(huì)再次觸發(fā)(由硬件觸發(fā))TLB Miss異常，說再次，是因?yàn)槲覀儺?dāng)前已經(jīng)在TLB Miss異常中了，嵌套了？此時(shí)如何處理，如何實(shí)現(xiàn)頁表的維護(hù)？

MIPS硬件在這里做了特殊設(shè)計(jì)：當(dāng)訪存發(fā)現(xiàn)TLB中不存在對(duì)應(yīng)地址映射時(shí)(此時(shí))，同時(shí)判斷CP0 Status寄存器的EXL位，如果為1,表示當(dāng)前已經(jīng)在異常處理中，此時(shí)，不再重復(fù)進(jìn)入TLB Refill異常(高優(yōu)先級(jí)異常，對(duì)應(yīng)異常編號(hào)為1)，而是直接進(jìn)入普通優(yōu)先級(jí)異常(通用異常，對(duì)應(yīng)異常編號(hào)為3)處理，同時(shí)會(huì)在CP0的STATUS寄存器[6:2]中填入相應(yīng)的ExcCode(頁表中不存在地址翻譯條目的情況，對(duì)應(yīng)的ExcCode為2，即TLB Load異常)，通用異常的處理接口中，會(huì)根據(jù)ExcCode調(diào)用相應(yīng)處理接口，其中對(duì)于缺頁的情況，會(huì)最終調(diào)用do_page_fault接口，實(shí)現(xiàn)內(nèi)存分配和頁表維護(hù)。

在TLB Refill過程中再次發(fā)生的TLB miss，通常也稱為TLB Load/Store異常，此時(shí)處理流程跟TLB refill是不同的。過程類似于X86中的缺頁異常。

缺頁后如何更新TLB

如前面所述，當(dāng)在異常處理過程中(Status[EXL] = 1)，又出現(xiàn)新異常時(shí)，CPU將不會(huì)重新設(shè)置EPC和CAUSE[BD]，當(dāng)新異常處理完成后，由于EPC之前沒有重置，就直接返回到發(fā)生異常原始指令處。

也就是說，當(dāng)TLB Refill過程中再次發(fā)生TLB miss(實(shí)現(xiàn)了類似X86中的缺頁異常的功能，完成頁表維護(hù))，進(jìn)行處理后，會(huì)直接返回最初發(fā)送TLB Refill異常的地方，而不會(huì)回到第二次TLB Miss發(fā)生的地方，也就是說，雖然頁表更新成功了，但TLB中還沒有填入相應(yīng)的映射呢，那頁表中的內(nèi)容是如何寫到TLB中的呢？

答案是：又一次異常。當(dāng)返回最初發(fā)生TLB Refill異常的指令后，會(huì)重新執(zhí)行原來的指令，此時(shí)由于TLB中仍沒有相應(yīng)的映射條目，所以硬件會(huì)再次觸發(fā)TLB Refill異常，而此時(shí)，頁表中的條目已經(jīng)準(zhǔn)備好了，異常處理中會(huì)直接從頁表refill到TLB。

MIPS地址翻譯全過程

再次完整梳理一遍MIPS地址翻譯的全過程：

當(dāng)CPU做訪存操作時(shí)，MMU硬件會(huì)自動(dòng)到TLB中尋找相應(yīng)的映射條目。

如果映射條目存在，則直接取出做映射，得到物理地址，這是最快的路徑。

如果條目不存在，則MMU硬件觸發(fā)TLB Refill(也稱TLB Miss)異常，跳轉(zhuǎn)到固定的高優(yōu)先級(jí)異常入口地址處理，其中是內(nèi)核填入的處理接口，會(huì)通過Context寄存器讀取位于內(nèi)存中的頁表中對(duì)應(yīng)的條目，

• 如果頁表中相應(yīng)映射條目存在，則直接讀取，并填入TLB(這些操作由軟件，也就是內(nèi)核完成)。
• 由于頁表本身也是通過虛擬地址映射的(通常kseg2段)，所以其自身也需要通過TLB映射，而此時(shí)異常處理接口中會(huì)通過頁表的虛擬地址來做訪存操作，如果頁表不存在相應(yīng)映射條目，則MMU硬件會(huì)再次觸發(fā)TLB Miss異常。
• 由于MIPS硬件上做了特殊處理，對(duì)于在異常中(Status[EXL] = 1)再次發(fā)生異常的情況，不會(huì)重新進(jìn)入，而會(huì)進(jìn)入General exception的處理，并設(shè)置ExcCode為2。
• General exception處理中，會(huì)根據(jù)ExcCode，條用相應(yīng)的處理接口，此時(shí)對(duì)應(yīng)為handle_tlbl。
• 在handle_tlbl中，會(huì)根據(jù)情況條用do_page_fault接口更新和維護(hù)頁表。
• General exception處理完成后，直接返回到第一次發(fā)生TLB Refill異常的地址，重新執(zhí)行原來觸發(fā)異常的指令，此時(shí)會(huì)再次觸發(fā)TLB Refill異常，然后從頁表refill相應(yīng)的條目到TLB。至此，處理結(jié)束。

可以看出，在最糟糕的情況下(頁表和TLB中都不存在相應(yīng)映射條目)，會(huì)觸發(fā)3次異常，才能完成TLB Refill(而X86的page fault只需要一次異常)，這樣的性能能好么？

實(shí)踐證明，其實(shí)還不錯(cuò)。最糟糕的情況相對(duì)比較少～

原文地址：?http://happyseeker.github.io/kernel/2016/12/27/mips-TLB-miss.html

總結(jié)

以上是生活随笔為你收集整理的Mips TLB miss异常的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。