鴻蒙內核源碼分析：關于內存涉及的C7,C2,C13三個寄存器

ARM-CP15協處理器

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

先拆解一段匯編代碼

上來看段匯編，讀懂內核源碼不會點匯編是不行的 , 但不用發怵，沒那么恐怖，由淺入深, 內核其實挺好玩的。見于 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：為指令執行的條件碼。當cond忽略時指令為無條件執行。
Opcode_1：協處理器的特定操作碼. 對于CP15寄存器來說，opcode1=0
Rd：作為源寄存器的ARM寄存器，其值將被傳送到協處理器寄存器中，或者將協處理器寄存器的值傳送到該寄存器里面 ,通常為R0
CRn：作為目標寄存器的協處理器寄存器，其編號是C~C15。
CRm：協處理器中附加的目標寄存器或源操作數寄存器。如果不需要設置附加信息，將CRm設置為c0，否則結果未知
Opcode_2：可選的協處理器特定操作碼。（用來區分同一個編號的不同物理寄存器，當不需要提供附加信息時，指定為0

這句匯編的指令字面意思是: 將ARM寄存器R0的數據寫到CP15中編號為7的寄存器中，值由外面傳進來。

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

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

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

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

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

CP15有哪些寄存器

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

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

TTB寄存器(Translation table base)

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

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

mmu上下文

只被這一個函數調用。毫無疑問LOS_ArchMmuContextSwitch是關鍵函數。

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寄存器的狀態值
    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切到內核空間的ID
    ISB;
    OsArmWriteTtbr0(ttbr);//通過r0寄存器將進程頁面基址寫入TTB
    ISB;
    OsArmWriteTtbcr(ttbcr);//寫入TTB狀態位
    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");
}

再看下那些地方會調用LOS_ArchMmuContextSwitch，下圖一目了然。

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

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

//調度算法-進程切換
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) {//獲取當前進程的任務數量
#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));//斷言進程不是阻塞狀態
    newProcess->processStatus |= OS_PROCESS_STATUS_RUNNING;//設置進程狀態為運行狀態

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

#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
    }
}

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

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

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

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

TLB（translation lookaside buffer）

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

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

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

2. 虛擬地址是程序的地址邏輯地址，也就是喂給CPU的地址，必須經過MMU的轉換后變成物理內存才能取到真正的指令和數據。

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

asid寄存器

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

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

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

最后一個函數留給大家，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