Implement a multi-Level TLB hierarchy


This ticket is about enabling users to compose/model a customizable multilevel TLB hierarchy in gem5.
At the moment the generic (arch agnostic) interface in gem5 is exposing a single instruction TLB and data TLB to the cpu models. Any cpu code requiring translation services is in charge of selecting the approriate TLB (ITB when fetching instructions, DTB for Load/Stores).
The TLB object is not modelling a simple translation cache; it is actually modelling a TLB + MMU (e.g. doing permission checking and issuing page table walks through the walker, if any)

This solution has the following shortcomings:

  1. The design is assuming two different TLBs for instruction and data translations. It is not allowing a unified TLB solution

  2. TLB structures shouldn't be exposed to the cpu code, which is simply requesting translation services to the MMU

  3. By modelling a "real world" TLB + MMU it is not possible to stack multiple TLBs and hence to create a multilvel hierarchy.

We are proposing to address these shortcomings by adding a new MMU object in gem5, and to make the cpu/arch code interact directly to the MMU rather than with the first level tlbs (formerly known as itb/dtb).
The MMU model will then be in charge of issuing translation/invalidations request to the appropriate TLBs and to trigger page table walks in case of TLB misses.

A possible MMU/TLB structure (in python) could be something like:

Where every TLB contains a pointer to the next level. This is a pointer based solution, which is probably the fastest one. Another solution could involve the use of specialized ports for communications between TLBs

To summarize,
The task will be considered completed once these options will be exposed to user via the config script:

  • Allowing to stack multiple level of TLBs for both stage1 and stage2 translations (for VZ enabled ISAs)

  • Allowing to unified TLBs, where both instruction and data


Jason Lowe-Power
April 20, 2021, 3:52 PM

I’m working on the gem5 21.1 roadmap. Is there any active development here? It’s still important to us, but we don’t have any active development right now ourselves.

Giacomo Travaglini
November 4, 2020, 5:04 PM

Hi Mike: there is a fix ready to be merged

mike upton
November 4, 2020, 4:58 PM

It seems like the nightly for MIPS just broke based on the ARM commit.

I am happy to fix but need a pointer as to where code moved around to.

Giacomo Travaglini
October 1, 2020, 3:23 PM

This is great Jason; part of this task involves moving code from TheISA::TLB to TheISA::MMU; I will definitely do that for the ArmTLB, but I am probably not the best person for doing this for RISC-V and X86

Jason Lowe-Power
October 1, 2020, 3:05 PM

I just tagged this 20.2. Seems reasonable . We’re willing to put some effort into the X86 and RISC-V implementations on this end.


Giacomo Travaglini


Giacomo Travaglini




Epic Name

Implement a multi-Level TLB hierarchy

Fix versions