ARM-CP15協(xié)處理器

ARM處理器使用協(xié)處理器15(CP15)的寄存器來控制cache、TCM和存儲器管理。CP15的寄存器只能被MRC和MCR（Move to Coprocessor from ARM Register ）指令訪問，包含16個32位的寄存器，其編號為0~15。本篇重點講解其中的 C7,C2,C13三個寄存器。

先拆解一段匯編代碼

上來看段匯編，讀懂內(nèi)核源碼不會點匯編是不行的 , 但不用發(fā)怵，沒那么恐怖，由淺入深, 內(nèi)核其實挺好玩的。見于 arm.h，里面全是這些玩意。

#define DSB __asm__ volatile("dsb" ::: "memory")
#define ISB __asm__ volatile("isb" ::: "memory")
#define DMB __asm__ volatile("dmb" ::: "memory")

STATIC INLINE VOID OsArmWriteBpiallis(UINT32 val)
{
    __asm__ volatile("mcr p15, 0, %0, c7,c1,6" ::"r"(val));
    __asm__ volatile("isb" ::: "memory");
}

cond：為指令執(zhí)行的條件碼。當(dāng)cond忽略時指令為無條件執(zhí)行。
Opcode_1：協(xié)處理器的特定操作碼. 對于CP15寄存器來說，opcode1=0
Rd：作為源寄存器的ARM寄存器，其值將被傳送到協(xié)處理器寄存器中，或者將協(xié)處理器寄存器的值傳送到該寄存器里面 ,通常為R0
CRn：作為目標寄存器的協(xié)處理器寄存器，其編號是C~C15。
CRm：協(xié)處理器中附加的目標寄存器或源操作數(shù)寄存器。如果不需要設(shè)置附加信息，將CRm設(shè)置為c0，否則結(jié)果未知
Opcode_2：可選的協(xié)處理器特定操作碼。（用來區(qū)分同一個編號的不同物理寄存器，當(dāng)不需要提供附加信息時，指定為0

這句匯編的指令字面意思是: 將ARM寄存器R0的數(shù)據(jù)寫到CP15中編號為7的寄存器中，值由外面?zhèn)鬟M來。

例如 OsArmWriteBpiallis(0)做了4個動作

1.把0值寫入R0寄存器，注意這個寄存器是ARM即CPU的寄存器，::"r"(val)意思代表向GCC編譯器聲明，會修改R0寄存器的值，改之前提前打好招呼，都是紳士文明人。其實編譯器的功能是非常強大的，不僅僅是大家普遍認為的只是編譯代碼的工具而已。

2.volatile的意思還是告訴編譯器，不要去優(yōu)化這段代碼，原封不動的生成目標指令。

3."isb" ::: "memory" 還是告訴編譯器內(nèi)存的內(nèi)容可能被更改了，需要無效所有Cache，并訪問實際的內(nèi)容，而不是Cache！

4.再把R0的值寫入到C7中，C7是CP15協(xié)處理器的寄存器。C7寄存器是負責(zé)什么的？對照下面的表。

CP15有哪些寄存器

這句話真正的意思是：關(guān)閉高速緩存和寫緩存控制！，其他部分寄存器下面會講，先有個大概印象。

mmu從哪里獲取 page table 的信息？答案是: TTB

TTB寄存器(Translation table base)

參考上表可知TTB寄存器是CP15協(xié)處理器的C2寄存器，存頁表的基地址，即一級映射描述符表的基地址。圍繞著TTB鴻蒙提供了以下讀取函數(shù)。簡單說就是內(nèi)核從外面不斷的修改和讀取寄存器值，而MMU只會直接通過硬件讀取這個寄存器的值，以達到MMU獲取不一樣的頁表進行進程虛擬地址和物理地址的轉(zhuǎn)換。還記得嗎？每個進程的頁表都是獨立的！

那么什么情況下會修改里面的值呢？換頁表意味著mmu在進行上下文的切換！還是直接看代碼吧。

mmu上下文

只被這一個函數(shù)調(diào)用。毫無疑問LOS_ArchMmuContextSwitch是關(guān)鍵函數(shù)。

typedef struct ArchMmu {
    LosMux              mtx;            /**< arch mmu page table entry modification mutex lock */
    VADDR_T             *virtTtb;       /**< translation table base virtual addr */
    PADDR_T             physTtb;        /**< translation table base phys addr */
    UINT32              asid;           /**< TLB asid */
    LOS_DL_LIST         ptList;         /**< page table vm page list */
} LosArchMmu;

// mmu 上下文切換
VOID LOS_ArchMmuContextSwitch(LosArchMmu *archMmu)
{
    UINT32 ttbr;
    UINT32 ttbcr = OsArmReadTtbcr();//讀取TTB寄存器的狀態(tài)值
    if (archMmu) {
        ttbr = MMU_TTBRx_FLAGS | (archMmu->physTtb);//進程TTB物理地址值
        /* enable TTBR0 */
        ttbcr &= ~MMU_DESCRIPTOR_TTBCR_PD0;//使能TTBR0
    } else {
        ttbr = 0;
        /* disable TTBR0 */
        ttbcr |= MMU_DESCRIPTOR_TTBCR_PD0;
    }

    /* from armv7a arm B3.10.4, we should do synchronization changes of ASID and TTBR. */
    OsArmWriteContextidr(LOS_GetKVmSpace()->archMmu.asid);//這里先把asid切到內(nèi)核空間的ID
    ISB;
    OsArmWriteTtbr0(ttbr);//通過r0寄存器將進程頁面基址寫入TTB
    ISB;
    OsArmWriteTtbcr(ttbcr);//寫入TTB狀態(tài)位
    ISB;
    if (archMmu) {
        OsArmWriteContextidr(archMmu->asid);//通過R0寄存器寫入進程標識符至C13寄存器
        ISB;
    }
}
// c13 asid(Adress Space ID)進程標識符
STATIC INLINE VOID OsArmWriteContextidr(UINT32 val)
{
    __asm__ volatile("mcr p15, 0, %0, c13,c0,1" ::"r"(val));
    __asm__ volatile("isb" ::: "memory");
}

再看下那些地方會調(diào)用LOS_ArchMmuContextSwitch，下圖一目了然。

有四個地方會切換mmu上下文

第一：通過調(diào)度算法，被選中的進程的空間改變了，自然映射頁表就跟著變了，需要切換mmu上下文，還是直接看代碼。代碼不是很多，就都貼出來了，都加了注釋，不記得調(diào)度算法的可去系列篇中看鴻蒙內(nèi)核源碼分析(調(diào)度機制篇)，里面有詳細的闡述。

//調(diào)度算法-進程切換
STATIC VOID OsSchedSwitchProcess(LosProcessCB *runProcess, LosProcessCB *newProcess)
{
    if (runProcess == newProcess) {
        return;
    }

#if (LOSCFG_KERNEL_SMP == YES)
    runProcess->processStatus = OS_PROCESS_RUNTASK_COUNT_DEC(runProcess->processStatus);
    newProcess->processStatus = OS_PROCESS_RUNTASK_COUNT_ADD(newProcess->processStatus);

    LOS_ASSERT(!(OS_PROCESS_GET_RUNTASK_COUNT(newProcess->processStatus) > LOSCFG_KERNEL_CORE_NUM));
    if (OS_PROCESS_GET_RUNTASK_COUNT(runProcess->processStatus) == 0) {//獲取當(dāng)前進程的任務(wù)數(shù)量
#endif
        runProcess->processStatus &= ~OS_PROCESS_STATUS_RUNNING;
        if ((runProcess->threadNumber > 1) && !(runProcess->processStatus & OS_PROCESS_STATUS_READY)) {
            runProcess->processStatus |= OS_PROCESS_STATUS_PEND;
        }
#if (LOSCFG_KERNEL_SMP == YES)
    }
#endif
    LOS_ASSERT(!(newProcess->processStatus & OS_PROCESS_STATUS_PEND));//斷言進程不是阻塞狀態(tài)
    newProcess->processStatus |= OS_PROCESS_STATUS_RUNNING;//設(shè)置進程狀態(tài)為運行狀態(tài)

    if (OsProcessIsUserMode(newProcess)) {//用戶模式下切換進程mmu上下文
        LOS_ArchMmuContextSwitch(&newProcess->vmSpace->archMmu);//新進程->虛擬空間中的->Mmu部分入?yún)?
    }

#ifdef LOSCFG_KERNEL_CPUP
    OsProcessCycleEndStart(newProcess->processID, OS_PROCESS_GET_RUNTASK_COUNT(runProcess->processStatus) + 1);
#endif /* LOSCFG_KERNEL_CPUP */

    OsCurrProcessSet(newProcess);//將進程置為 g_runProcess

    if ((newProcess->timeSlice == 0) && (newProcess->policy == LOS_SCHED_RR)) {//為用完時間片或初始進程分配時間片
        newProcess->timeSlice = OS_PROCESS_SCHED_RR_INTERVAL;//重新分配時間片，默認 20ms
    }
}

這里再啰嗦一句，系列篇中已經(jīng)說了兩個上下文切換了，一個是這里的因進程切換引起的mmu上下文切換，還一個是因task切換引起的CPU的上下文切換，還能想起來嗎？

第二：是加載ELF文件的時候會切換mmu，一個嶄新的進程誕生了，具體將在 鴻蒙內(nèi)核源碼分析(啟動加載篇) 會細講，敬請關(guān)注系列篇動態(tài)。

其余是虛擬空間回收和刷新空間的時候，這個就自己看代碼去吧。

mmu是如何快速的通過虛擬地址找到物理地址的呢？答案是：TLB,注意上面還有個TTB，一個是寄存器, 一個是cache,別搞混了。

TLB（translation lookaside buffer）

TLB是硬件上的一個cache，因為頁表一般都很大，并且存放在內(nèi)存中，所以處理器引入MMU后，讀取指令、數(shù)據(jù)需要訪問兩次內(nèi)存：首先通過查詢頁表得到物理地址，然后訪問該物理地址讀取指令、數(shù)據(jù)。為了減少因為MMU導(dǎo)致的處理器性能下降，引入了TLB，可翻譯為“地址轉(zhuǎn)換后援緩沖器”，也可簡稱為“快表”。簡單地說，TLB就是頁表的Cache，其中存儲了當(dāng)前最可能被訪問到的頁表項，其內(nèi)容是部分頁表項的一個副本。只有在TLB無法完成地址翻譯任務(wù)時，才會到內(nèi)存中查詢頁表，這樣就減少了頁表查詢導(dǎo)致的處理器性能下降。詳細看

照著圖說吧，步驟是這樣的。

1.圖中的page table的基地址就是上面TTB寄存器值，整個page table非常大,有多大接下來會講,所以只能存在內(nèi)存里，TTB中只是存一個開始位置而已。

2. 虛擬地址是程序的地址邏輯地址，也就是喂給CPU的地址，必須經(jīng)過MMU的轉(zhuǎn)換后變成物理內(nèi)存才能取到真正的指令和數(shù)據(jù)。

3.TLB是page table的迷你版，MMU先從TLB里找物理頁，找不到了再從page table中找，從page table中找到后會放入TLB中，注意這一步非常非常的關(guān)鍵。因為page table是屬于進程的會有很多個，而TLB只有一個，不放入就會出現(xiàn)多個進程的page table都映射到了同一個物理頁框而不自知。一個物理頁同時只能被一個page table所映射。但除了TLB的唯一性外，要做到不錯亂還需要了一個東西，就是進程在映射層面的唯一標識符 -asid。

asid寄存器

asid(Adress Space ID) 進程標識符，屬于CP15協(xié)處理器的C13號寄存器，ASID可用來唯一標識進程，并為進程提供地址空間保護。當(dāng)TLB試圖解析虛擬頁號時，它確保當(dāng)前運行進程的ASID與虛擬頁相關(guān)的ASID相匹配。如果不匹配，那么就作為TLB失效。除了提供地址空間保護外，ASID允許TLB同時包含多個進程的條目。如果TLB不支持獨立的ASID，每次選擇一個頁表時（例如，上下文切換時），TLB就必須被沖刷（flushed）或刪除，以確保下一個進程不會使用錯誤的地址轉(zhuǎn)換。

TLB頁表中有一個bit來指明當(dāng)前的entry是global(nG=0，所有process都可以訪問)還是non-global(nG=1，only本process允許訪問)。如果是global類型，則TLB中不會tag ASID；如果是non-global類型，則TLB會tag上ASID，且MMU在TLB中查詢時需要判斷這個ASID和當(dāng)前進程的ASID是否一致，只有一致才證明這條entry當(dāng)前process有權(quán)限訪問。

看到了嗎？如果每次mmu上下文切換時，把TLB全部刷新已保證TLB中全是新進程的映射表，固然是可以，但效率太低了?。?！進程的切換其實是秒級亞秒級的，地址的虛實轉(zhuǎn)換是何等的頻繁啊，怎么會這么現(xiàn)實呢，真實的情況是TLB中有很多很多其他進程占用的物理內(nèi)存的記錄還在，當(dāng)然他們對物理內(nèi)存的使用權(quán)也還在。所以當(dāng)應(yīng)用程序 new了10M內(nèi)存以為是屬于自己的時候，其實在內(nèi)核層面根本就不屬于你，還是別人在用，只有你用了1M的那一瞬間真正1M物理內(nèi)存才屬于你，而且當(dāng)你的進程被其他進程切換后，很大可能你用的那1M也已經(jīng)不在物理內(nèi)存中了，已經(jīng)被置換到硬盤上了。明白了嗎？只關(guān)注應(yīng)用開發(fā)的同學(xué)當(dāng)然可以說這關(guān)我鳥事，給我的感覺有就行了，但想熟悉內(nèi)核的同學(xué)就必須要明白，這是每分每秒都在發(fā)生的事情。

最后一個函數(shù)留給大家，asid是如何分配的?

/* allocate and free asid */
status_t OsAllocAsid(UINT32 *asid)
{
    UINT32 flags;
    LOS_SpinLockSave(&g_cpuAsidLock, &flags);
    UINT32 firstZeroBit = LOS_BitmapFfz(g_asidPool, 1UL << MMU_ARM_ASID_BITS);
    if (firstZeroBit >= 0 && firstZeroBit < (1UL << MMU_ARM_ASID_BITS)) {
        LOS_BitmapSetNBits(g_asidPool, firstZeroBit, 1);
        *asid = firstZeroBit;
        LOS_SpinUnlockRestore(&g_cpuAsidLock, flags);
        return LOS_OK;
    }

    LOS_SpinUnlockRestore(&g_cpuAsidLock, flags);
    return firstZeroBit;
}

編輯：hfy