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
