Hi Gabe, I am actually about to post the same patchset (which is: removing the TLB from the CPU interface and make it interface with an MMU instead)
Giacomo From: Gabe Black via gem5-dev <[email protected]> Sent: 20 September 2020 04:44 To: gem5 Developer List <[email protected]> Cc: Gabe Black <[email protected]> Subject: [gem5-dev] Re: MMU object vs. DTB and ITB Oh, this will also absorb multilevel TLBs too, like how ARM has second level translation in some cases. This isn't really implemented in x86, but could also be used for it's multilevel translation in SVM and VT's nested page table schemes. Gabe On Sat, Sep 19, 2020 at 8:25 PM Gabe Black <[email protected]<mailto:[email protected]>> wrote: Hi folks. I've been thinking about how to rework the scanning-through-page-translation thing we currently do when translating a region of addresses through both the ITB and DTB. We currently do that one page at a time by trying one, and then the other. That requires knowing what "the" page size is, which introduces a dependence on the ISA and also constraints things to a single page size. One improvement that I think makes sense is to instead use an approach where you'd ask for a translation for a region and let whatever is translating for you decide how to break things up. Then it can use a single page size, the size of whatever the mapping is, a single byte, etc., as it sees fit without there ever needing to be a particular page size. This would fit mostly nicely with the idea of a range based for loop or generator object. One problem with this approach is how we try one TLB and then the other if we can't get a translation. With a range based for loop, there isn't a good way that I'm aware of to iterate over two different objects at the same time, and also there wouldn't be any coordination between the TLBs. For instance, what should happen in both have a translation? Or if they're to the same place, who's idea of the size of the step takes precedence? That led me to the idea of merging the TLBs into a single object called the MMU. This fits pretty well with the structure of actual hardware, and would also absorb the "UnifiedTLB" concept which was added to the CPU, since the structure of the TLBs would no longer be visible to the CPU. I think this makes a lot of sense and will probably take a stab at it this weekend, but since it's a structural shift that will be fairly visible in a lot of places I wanted to let everybody know a little ahead of time in case there are any big concerns. Gabe IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
