Nuclear memory (virtual address entries) in a TLB?

Question

Linux is the OS, and ARM is the processor mentioned in this context.

Does the TLB contain virtual kernel and user addresses? Kernel memory starts at 0xc000_0000 and goes to 0xFFFF_FFFF where the first 3 GB belong to user space. Between context switching between processes, the TLB is cleared.

Does the TLB contain both virtual kernel addresses and user space?

Kernel memory (virtual) directly corresponds to physical memory (only an offset using 0xc000_0000 will give us a physical address). Do I need to have kernel memory (virtual) in a TLB (if you say that it is present in a TLB)? It should only have a user space address.

Answer 1

The main reason that we have a virtual translation to a physical address in modern processors is to make more efficient and controlled use of memory, which allows us to:

• Allocate any physical memory, RAM (contiguous or not) and make it available anywhere in the virtual address space (contiguous or not) without wasting memory on fragmentation.
• Expand physical memory, RAM, disk, or other memory.
• Make certain parts of the address space only readable or not executable, or only for the kernel, etc. etc. and protect them from unauthorized or erroneous access.
• Separate application memory from each other to further improve protection, security, and reliability.
• Share memory. ...

And the page tables do their best.

You want to be able to map and expand physical memory in a virtual address space in the kernel, and usually this translation mechanism works throughout the system. Of course, the translation comes at a price, since now you need to consult and maintain page tables, and this will lead to a performance hit. But all is not lost:

• TLBs alleviate this problem to a certain extent. They cache translations.
• Larger pages (e.g. ARMv7-A large pages and sections ) help more, as they need fewer TLB entries per unit of translated memory.
• There are things like global pages . When you switch between applications and need to clear the current TLB, you can avoid invalidating global pages from the TLB by performing Invalidate TLB entries by ASID match using the ASID application. If you mark kernel pages as global, you will not invalidate their translations, and the kernel itself will not suffer from unnecessary invalid TLBs.

See, for example, the ARM® ARM®v7-A and ARM®v7-R edition Architecture Reference Guide for detailed information on the ARM Virtual Memory System Architecture (VMSA), page tables, TLBs, etc.

Answer 2

There are two types of virtual addresses that the Linux kernel uses:

• What you already mentioned in the line "The core of memory (virtual) directly corresponds to physical memory (only an offset from 0xC000_0000 will give us a physical address). This displays the adjacent physical addresses.
• Using vmalloc.

The first is done using MACRO:

 include/asm-x86/page_32.h #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET) #define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET)) 

_pa (x) performs virtual and physical translation. Please note that this translation occurs at compile time. Translation of the spreadsheet page does not occur. The last sentence is very important.

On the other hand, using the second method, you can allocate memory that is contiguous in virtual memory, but may not be so in physical memory. Now, in this case, the first access to the virtual address requires a full translation of the page table. The question is, who does this?

In the case of CISC machines (for example, x86), the MMU (hardware) does this in case of missing TLB (first access to the virtual address) and updates the page table. For virtual kernel addresses (obtained through vmalloc), they are saved as TLB entries. They are called global records, and when the process context switches, they are mostly ignored and not reddened like the rest of the process address records. However, when you do vfree to free the associated virtual memory, these entries are deleted.

In the case of a RISC machine (for example, MIPS), the translation of the page is processed by the software. After skipping TLB, the hardware throws an exception. The descriptor trap runs in kernel mode to translate and update TLBs using special instructions. After returning from the trap handler, the same line of code is executed and TLB crashes.

Refer to: http://pages.cs.wisc.edu/~remzi/OSFEP/vm-tlbs.pdf

The bottom line is that not all kernel addresses are mapped as you described. For your case, physical addresses are generated at compile time. So why add a TLB entry. For addresses from vmalloc there are TLB entries. When a context switch occurs between processes, the entire TLB does not need to be cleared, and the global entries made by the vmalloc core can be saved. When you use vfree, the corresponding global entries are cleared.