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:
The design is assuming two different TLBs for instruction and data translations. It is not allowing a unified TLB solution
TLB structures shouldn't be exposed to the cpu code, which is simply requesting translation services to the MMU
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
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
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.
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.
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
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.