Hey Giacomo, Thanks for the patches! I think this is moving in the right direction. It looks like the C++ interface is getting much better, though there are still a few places to improve :).
However, I think we need to reconsider the python interface at this time too. Right now, we have the following "dependencies". To hook up the memory system, you have to know details about the internal CPU implementation. This in turn depends on the MMU implementation. This in turn depends on the TLB implementation. This in turn depends on the walker implementation (which also depends on the ISA!). To create a CPU correctly, the CPU also depends on the memory system (i.e., classic caches use "cpu_side" whereas Ruby (now) uses "in_port"). This also means that the transitive dependency described above also depends on the memory system implementation. (There's also the dependence on "cached" vs "uncached" ports in the CPU too... But I think this is a different issue.) These circular dependencies are not great. I think we should talk about which way we want the dependencies to flow, and then hide the implementation behind functions. By defining some functions in the Python SimObject description files, we can hide the implementation details (e.g., that an MMU has two child SimObjects called itb and dtb). In doing this, we can have *well defined* interfaces/APIs for the Python SimObjects instead of the mess of "duck typing" that we have right now. Given all of the changes in https://gem5-review.googlesource.com/c/public/gem5/+/34976 to the config files, I would prefer to hash this out before these changes go in, but I would also be open to waiting and going through some pain on the develop branch. However, if we're going to do this TLB refactor now, I think it's a requirement to also refactor the python interface before the 20.2 release. Cheers, Jason On Tue, Sep 22, 2020 at 8:48 AM Giacomo Travaglini < [email protected]> wrote: > Hey Jason, > > > > I have just posted the patchset: > > > > https://gem5-review.googlesource.com/c/public/gem5/+/34975/1 > > > > Supporting a multi-level TLB design was actually the reason why I started > implementing this. > > I am not at that point yet, but I believe we are getting closer now, > having a MMU hiding the TLB hierarchy to the rest of the cpu code. > > The remaining thing after this patches would be to move most TLB methods > to the MMU class and to make the TLB a simple passive translation cache. > That will allow us to stack them in any way we want > > > > Giacomo > > > > *From:* Jason Lowe-Power via gem5-dev <[email protected]> > *Sent:* 21 September 2020 16:02 > *To:* gem5 Developer List <[email protected]> > *Cc:* Jason Lowe-Power <[email protected]> > *Subject:* [gem5-dev] Re: MMU object vs. DTB and ITB > > > > We (well, mostly Ayaz) have also been looking at this interface. We've > been thinking more about x86 and RISC-V, but would also like to be kept up > to date! > > > > We were also thinking that many of the TLB/MMU concepts are shared between > ISAs (or are microarchitecture details). So, it would be nice to be able to > use the same multi-level TLB design for any ISA similar to how we can use > caches for any ISA. I'm not sure if this is something that's enabled by > your changes, Giacomo, or if it's something others think is important. > > > > Cheers, > > Jason > > > > On Mon, Sep 21, 2020 at 4:06 AM Gabe Black via gem5-dev <[email protected]> > wrote: > > 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 > > 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
