Overview What is memory management? Virtual and physical addresses The Memory Management Unit (MMU) Address spaces in AArch64 Controlling address translation Translation granule Translation Lookaside Buffer maintenance Address translation instructions Check your knowledge Related information Next steps
Translation Lookaside Buffer maintenance
The Translation Lookaside Buffers (TLBs) cache recently used translations. This caching allows the translations to be reused by subsequent lookups without needing to reread the tables.
Note: The TLBs are caches of translations, not caches of the translation tables. The difference is subtle. Several register fields control how the translation table entries are interpreted. What is in a TLB entry is the interpretation of the translation table entry given the configuration at the point that the tables were walked. In the Arm Architecture Reference Manual (Arm ARM), such register fields are described as 'permitted to be cached in a TLB'.
If you change a translation table entry, or the controls that affect how entries are interpreted, then you need to invalidate the affected entries in the TLB. If you do not invalidate those entries, then the processor might continue to use the old translation.
The processor is not permitted to cache a translation into the TLBs that results in any of the following faults:
- A translation fault (unmapped address).
- An address size fault (address outside of range).
- An access flag fault.
As a result, you do not need to issue a TLB invalidate when mapping an address for the first time. However, you do need to issue a TLB invalidate if you want to do any of the following:
- Unmap an address
Take an address that was previously valid or mapped and mark it as faulting.
- Change the mapping of an address
Change the output address or any of the attributes. For example, change an address from read-only to read-write permissions.
- Change the way the tables are interpreted
This is less common. But, for example, if the granule size was changed, then the interpretation of the tables also changes. Therefore, a TLB invalidate would be necessary.
Format of a TLB operation
The TLBI instruction is used to invalidate entries in the TLBs. The syntax of this instruction is:
TLBI < type >< level >{IS|OS} {, < xt >}
Where:
- < type > Which entries to invalidate.
All - All entries
VA - Entry matching VA and ASID in Xt
VAA - Entry matching VA in Xt, for any ASID
ASID - Any entry matching the ASID in Xt
and many more
- < level > Which address space to operate on.
E1 = EL0/1 virtual address space
E2 = EL2 virtual address space
E3 = EL3 virtual address space
- < IS|OS > Whether an operation is Inner Shareable (IS) or Outer Shareable (OS).
When IS is added to the operation, it is broadcast to the other cores in the Inner Shareable domain.
When OS is added to the operation, it is broadcast to the other cores in the Outer Shareable domain (Added in Armv8.4-A).
- < Xt >Which address or ASID to operate on.
Only used for operations by address or ASID.
Consider, for example, an Operating System (OS) that is updating an entry in its kernel translation tables. A typical TLB invalidate sequence would look like this:
STR X1, [X5] // Write to translation table entry DSB ISH // Barrier instructions – not covered in this guide TLBI VAAE1IS , X0 // Invalidate VA specified by X0, in EL0/1 // virtual address space for all ASIDs DSB ISH // Barrier instructions – not covered in this guide ISB // Synchronize context on this processor