Mips TLB Miss exception

The recent analysis of the implementation of Godson KVM, by the way and coarse look at the manual of MIPS, with the main KVM-related modules include: CPU Virtualization memory Virtualization of IO

The current godson on the CPU virtualization and the standard kernel difference is small, need hardware and software with support, the current godson overall can support. Kernel virtualization is the key to the Godson KVM scheme, which directly determines the performance, which is also the source of this article. IO virtualization, the current godson because there is no own bridge, it is difficult to do what, mainly based on the existing KVM Virtio (semi-virtualization), here is also not concerned. Structured TLB

Godson's memory management mechanism, the most core of MIPS in the structure of the relevant processing TLB. the MMU architecture of MIPS

Typically, the processor's MMU architecture is divided into two categories:

Structured page table. This is also the way X86 and PowerPC are used. We are familiar with: Based on the page table to do the virtual address to the physical address mapping, of course, in this way, there are also TLB, but only as a cache of page tables. The address translation process is described as: when the CPU needs to do a visit operation, MMU first in the TLB query the appropriate entries, if not found, from the page table to find. If found in the page table, the TLB is populated, and if it is not found, the fault is triggered. This whole set of operations is done by the MMU hardware.

Structured tlb. This is the way MIPS are used. The core idea is that all address translations are done by a TLB. The page table also exists in the structured TLB. However, this is basically used and maintained by the software (operating system kernel); The address translation process is described as: when the CPU needs to do an access operation, MMU from the TLB, and when it is not found in the TLB, directly triggers the TLB Miss (also called a TLB refill) exception, the TLB Miss Exception handling (kernel implementation), the completion of the TLB fill, usually implemented by: also maintain a similar page table in X86, from the page table to the corresponding entries, fill in the TLB, which also involves more complex two of the exception logic, described separately. The fill operation of the TLB is entirely the responsibility of the software, of course, there are some ancillary hardware level to improve performance, described separately. So designed, the pros and cons obvious. Benefits: The hardware design is simple, the software realizes the flexibility is big. Disadvantage: The performance may be insufficient (or to divide the scene). page Fault in TLB Miss

As mentioned earlier, in a structured TLB, when a mapping does not exist in the TLB, it is found from the page table. So what to do when it doesn't exist in the page table. In other words, where does the entry from the page table come from? Obviously the hardware is not automatically generated.

Here need to be clear: MIPS hardware implementation, there is no X86 in the corresponding page faults. MIPS MMU Hardware does not look up the page table, only the TLB page table content obviously needs the software to maintain. MIPS Exception

The exceptions in MIPS (Exception, translations may be different) fall into two categories: high priority. The exception that needs to be handled as soon as possible, each exception has a dedicated fixed exception entry, so it can be processed quickly. Contains 3 types: NMI, boot, restart TLB refill, or TLB Miss exception. Cache Error Normal priority. That is, General Exception, also known as other exceptions, that is, except for the above high priority exception of all exceptions (by the CP0 status register [6:2], also known as Exccode), all belong to this class, such as interrupts, TLB Load/store/modify exception, System calls, etc., this type of exception corresponds to the same exception entry address (processing interface), and then in the processing interface according to different exception types, call different processing interface, equivalent to two times the event forwarding processing, so, relative to the previous high priority exception, processing slower.

In most cases (not nested), exception handling is actually equivalent to a procedure call that accompanies a mode switch. The processing process for the exception is described as:

After the anomaly occurs, MIPS CP0 registers STATUS[EXL] = 1, and the current PC value is deposited into the EPC (Exception pc, which points to the instruction that the exception occurred).

Jumps from the current instruction stream to the exception handling interface.

The MIPS hardware is not responsible for saving the context, so the software needs to save the context first.

After the exception is processed, the software is also responsible for recovering the context, then executing the instruction Eret, returning from the exception.

The Eret action is to place the EPC/ERROREPC value into the PC while clearing the EXL bit of the Cp0_status register. MIPS, when the status register ExL (exception) bit is 1, that means the processor into exception handling, in privileged mode.

Note: When a new exception occurs during exception handling (STATUS[EXL] = 1), the CPU will not reset the EPC and CAUSE[BD], and when the new exception is processed, it is returned directly to the exception's original instruction, as the EPC has not been reset before, in the TLB In the case of refill, the user state is usually returned. How the page table is maintained.

This is a key and difficult to understand problem, each process has its own virtual address space, that is, each process requires a page table, in X86, MMU can directly use the Page table (page directory address to CR3 register), you can also through page fault dynamically create Update page table entries on demand. But there is no such mechanism in MIPS, how to do.

Pre-mapped. That is, the page table is created in advance, that is, static mode, then map 2G user-State address space requires 4M size of memory. Now the memory is not worth much. But in fact, the process actually uses much less memory than virtual memory, so the waste is a bit excessive.

Use virtual addresses to dynamically assign. This is true of mainstream MIPS. But this involves a number of key issues: the virtual address used by the page table also needs to be addressed, while MIPS is based on a TLB mapping, and if this mapping does not exist in the TLB at this time, it is clear that the TLB (triggered by hardware) Miss exception, again, because we are currently in the TLB The miss exception is nested. How to handle this, how to implement the maintenance of the page table.

The MIPS hardware has a special design here: when there is no corresponding address mapping in the Access Discovery TLB (at this point), and the EXL bit of the CP0 status register is judged, if 1 indicates that it is currently in exception handling, then the TLB refill exception (high priority exception) is no longer repeated. The corresponding exception number is 1), instead, it goes directly into the normal priority exception (general exception, corresponding to the exception number 3), while the corresponding Exccode is filled in the CP0 status register [6:2] (the page table does not have an address translation entry, the corresponding Exccode is 2, that is, the TLB Load exception), the common exception of the processing interface, according to Exccode call the corresponding processing interface, which for the case of page faults, will eventually call the Do_page_fault interface, memory allocation and page table maintenance.

The TLB miss, which occurs again in the TLB refill process, is often referred to as a TLB Load/store exception, at which time the processing flow differs from the TLB refill. The process is similar to the page faults in X86. How to update TLB after page faults

As mentioned earlier, when a new exception occurs during exception handling (STATUS[EXL] = 1), the CPU will not reset the EPC and CAUSE[BD], and when the new exception is processed, it is returned directly to the exception's original instruction because the EPC has not been reset before.

That is, when the TLB refill occurs again, the TLB Miss (which implements the function of the page-fault exception in X86, completes the sheet-table maintenance), and, after processing, returns directly to the place where the TLB refill exception was originally sent, rather than back to where the second TLB miss occurred, That is, although the page table update was successful, the corresponding mapping in the TLB has not been filled in, so how does the content in the page table be written to the TLB?

The answer is: another anomaly. When an instruction that initially occurs with a TLB refill exception is returned, the original instruction is rerun, and the hardware triggers the TLB refill exception again because there is still no corresponding mapping entry in the TLB, and the entries in the page table are ready. Exception handling is directly refill from the page table to the TLB. The whole process of MIPS address translation

Once again, the whole process of MIPS address translation: When the CPU is doing an interview operation, the MMU hardware automatically looks for the corresponding mapping entry in the TLB. If the mapping entry exists, it is taken directly out of the map to get the physical address, which is the fastest path. If the entry does not exist, the MMU hardware triggers the TLB refill (also known as TLB Miss) exception, jumps to the fixed high-priority exception entry address, where the kernel fills in the processing interface that reads the corresponding entry in the page table in memory through the context register. If the corresponding mapping entry in the page table exists, read directly and fill in the TLB (these operations are done by the software, i.e. the kernel). Because the page table itself is also mapped through virtual addresses (usually KSEG2 segments), so it itself needs to be mapped by TLB, and at this point the exception handling interface will be through the virtual address of the page table to do the visit operation, if the page table does not exist the corresponding mapping entries, then the MMU hardware will trigger the TLB Miss exception again. Due to the special processing of MIPS hardware, the exception in the exception (STATUS[EXL] = 1) will not re-enter, and will enter the general exception processing, and set the Exccode to 2. General exception processing, according to Exccode, bar with the corresponding processing interface, this time corresponds to HANDLE_TLBL. In Handle_tlbl, the page table is updated and maintained with the Do_page_fault interface according to the situation bar. When the general exception process completes, it returns directly to the address of the first occurrence of the TLB refill exception, executes the instruction that originally triggered the exception, triggers the TLB refill exception again, and then refill the corresponding entry from the page table to the TLB. At this point, the processing is over.

As you can see, in the worst-case scenario (where the mapping entry does not exist in both the page table and the TLB), a 3-time exception is triggered to complete the TLB refill (and the X86 page fault only need one exception), so performance is good.

Practice has proved, actually good. The worst-case scenario is relatively small.

Original address: http://happyseeker.github.io/kernel/2016/12/27/mips-TLB-miss.html