I think gem5 would benefit from it for the same reason SystemC simulations do, namely speeding up simulations when doing fast forwarding (perhaps with a binary translating CPU... hypothetically...). It would also be very nice to enable software development for not-yet-existing hardware that has gem5 models available. Then gem5 users could do both software development and performance evaluation in parallel and only have to build models once. This is very nice when large bodies of software need to be written to support a bit of hardware, for instance if they have large complex drivers, need application level support, etc. It would also be great not to have to wait for hours for android to boot to get to the interesting part of a simulation or when debugging at a guest software level.
Gabe On Thu, Mar 14, 2019 at 6:41 AM Dr. Matthias Jung <jun...@eit.uni-kl.de> wrote: > Hi Gabe, > > one of the main reasons for DMI is to speedup simulations, similar to the > temporal decoupling in TLM LT or debug transport in order to make the > boot-loading. AFAIK DMI is mainly used in virtual platforms that target > software development and not hardware architecture design space > explorations, because you skip interconnects, caches etc. In commercial > tools you can just switch on or switch off DMI and therefore you can have a > nice trade-off between speed and accuracy by using the same models. > > Since gem5 is mainly there for computer-system architecture research, I’m > not sure if the DMI feature is really required. From a TLM2 perspective, > even if a TLM target model included in gem5 offers DMI, the gem5 core model > (initiator) does not have to use it, right? Do you have any concrete use > case where you could exploit DMI? > > For KVM: maybe somebody with KVM experience should comment that. > > Best regards, > Matthias > > > Am 28.02.2019 um 06:13 schrieb Gabe Black <gabebl...@google.com>: > > > > Hi folks. TLM is a communication protocol/mechanism built on top of > > systemc. It supports a mechanism called DMI which stands for direct > memory > > interface. The idea is that an entity sending a request into the system > can > > ask if the target can give it a pointer it can use to directly access > that > > memory in the future. The target, if it supports that sort of thing, > > returns a descriptor which describes a region of memory that can be > > accessed in that way. If that needs to be invalidated in the future, then > > there's another mechanism the target can use to communicate back to the > > sender telling it to throw away that descriptor. > > > > The way this mechanism is implemented in TLM is a bit less than ideal > since > > every request has a field that says whether the requester wants to know > > about DMI, and so the target has to perform an extra check on all the > > requests in case someone is asking when that's useful to communicate > only a > > very small fraction of the time, perhaps only once during an entire > > simulation. > > > > Aside from that though, this mechanism has some nice properties. First, > it > > avoids having to globally identify what a memory is or where it is for a > > particular simulation. A memory is just a thing on the other end of a > > request that may let you get at it directly if you ask nicely. Also, if > > there's something in the way that would get messed up if you skipped over > > it, say a cache, it can block those requests from getting through to > > targets. This could be useful for KVM for instance, when it's collecting > > regions to act as RAM for the virtual machine. > > > > I haven't fully figured out what a good way to avoid the check-every-time > > problem of the systemc mechanism, and ideally whatever I/we come up with > > will be compatible enough to be bridged effectively, but I'm thinking > some > > sort of explicit additional call like getAddrRanges which would propogate > > through the hierarchy at specific points, either to a specific address or > > as a broadcast. > > > > I know some folks have looked at gem5's memory system protocol and > > systemc's TLM before, for instance either to try making gem5 use TLM > > natively, or for the systemc TLM bridges. What do you think about adding > > this sort of mechainsm to gem5? Are there any pitfalls to avoid, known > > issues to figure out, suggested avenues to explore, etc? Please let me > > know. This is likely something I'm going to want to pursue in the next > few > > weeks. > > > > Gabe > > _______________________________________________ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
