Translation Lookaside Buffer maintenance

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