ARMLinux TLB miss processing process

Under the ARM architecture, the work after a TLB miss is mostly completed by hardware page table walk. Under special circumstances, the hardware page table walk can be turned off. At this time, the CPU will generate a translation fault after a TLB miss, and the remaining work will be taken over by the OS to complete the exception handling of the translation fault.

By default, after a TLB miss occurs,The hardware page table walk automatically starts scanning the pagetable in memory. If the corresponding PTE (page table entry) is found, the TLB entry is automatically refilled. If not found, a page fault exception is issued, and then the OS takes over to handle the page fault. There is a do_page_fault function in the kernel, which swaps pages from the hard disk into the memory, updates the page table, and then re-executes the instruction where the TLB miss occurred. The hardware page table walk is re-executed to complete the TLB refilling.

What we are concerned about here is the handling routine after TLB miss occurs after hardware pagetable walk is disabled. If this happens, the ARM CPU will issue a translation fault (If translation table walks are disabled, for example, PD0 or EPD0 is set to 1 for TTBR0, or PD1 or EPD1 isset to 1 for TTBR1, the processor returns a Translation fault. See cortex-A15TRM p 5-5). The OS handles this exception as follows.

First, after a translation fault occurs, the CPU will issue an abort exception and then jump to the exception address (for example, if an instruction prefetch abort exception occurs, jump to 0x00000010) for execution. The address stores a jump instruction (W(b) vector_pabt + stubs_offset). Then, through judgment, if the instruction that caused the exception is in usr mode, it jumps to the __pabt_usr function for execution. There is a jump instruction bl CPU_PABORT_HANDLER in this function. CPU_PABORT_HANDLER is a macro definition. For ARMv7, the definition is: #define CPU_PABORT_HANDLER v7_pabort,

The values ​​of the IFSR and IFAR registers are read in the v7_pabort function:

//pabort-v7.S

/*

*Function: v6_pabort

*

*Params : r0 = address of aborted instruction

*

*Returns : r0 = address of abort

* : r1 = IFSR

*

*Purpose : obtain information about current prefetch abort.

*/

.align 5

ENTRY(v7_pabort)

mrc p15,0, r0, c6, c0, 2 @ get IFAR

mrc p15,0, r1, c5, c0, 1 @ get IFSR

mov pc,lr

ENDPROC(v7_pabort)

IFAR stores the instruction address where the exception occurred, and IFSR stores a 32-bit number, some of which indicate the exception type, etc. (refer to Cortex-A15TRM p4-76)

The remaining work is to call the corresponding function (do_PrefetchAbort——>do_translation_fault) for processing according to the information extracted from the above two registers. The operation after OS takes over is (do_translation_fault function). First, determine whether the instruction that caused TLBmiss is a user instruction or a system instruction. If it is a system instruction, the remaining work is to operate the page global directory (pgd), page parent directory (pud), and page middle directory (pmd); if it is a user instruction, call the do_page_fault function, and the remaining work is the page fault processing process, which is judged according to different situations, including permission check, page allocation, sending SIGSEGV signal to the process, directly killing the process, etc. Regardless of the operation, OS does not refill TLB.

The page fault processing process is as follows: when fetching data or instructions, if the address of the instruction or data does not exist, an abort exception occurs.

Take the exception of instruction fetch as an example. After the instruction prefetch abort exception occurs, the CPU automatically jumps to 0x0000000C (which can be configured to 0xfffffffc, not considered here) for execution. The address is a jump instruction (W(b) vector_pabt + stubs_offset). Then, through judgment, if the instruction where the exception occurs is in usr mode, it jumps to the __pabt_usr function for execution. There is a jump instruction bl CPU_PABORT_HANDLER in this function. CPU_PABORT_HANDLER is a macro definition. For ARMv7, the definition is: #defineCPU_PABORT_HANDLER v7_pabort. The values ​​of the IFSR and IFAR registers are read in the v7_pabort function:

//pabort-v7.S

/*

* Function: v6_pabort

*

* Params : r0 = address ofaborted instruction

*

* Returns : r0 = address of abort

* : r1 = IFSR

*

* Purpose : obtain information aboutcurrent prefetch abort.

*/

 

.align 5

ENTRY(v7_pabort)

mrc p15, 0, r0, c6, c0, 2 @ get IFAR

mrc p15, 0, r1, c5, c0, 1 @ get IFSR

mov pc, lr

ENDPROC(v7_pabort)

IFAR stores the instruction address where the exception occurred, and IFSR stores a 32-bit number, some of which indicate the exception type, etc. (refer to Cortex-A15 TRM p4-76)

The remaining work is to call the corresponding function (do_PrefetchAbort——>do_page_fault) for processing based on the information extracted from the above two registers.