Oh, nice. I got sidetracked with some other things I wanted to rearrange first, so I haven't actually started on the MMU part :-). Please add me as a reviewer!
Gabe On Mon, Sep 21, 2020 at 1:17 AM Giacomo Travaglini < [email protected]> wrote: > 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]> 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
