Thinking about this more, it occurs to me it should be possible to set a watchpoint through IRIS which watches for accesses to the m5 device region. That may help solve this issue.
Gabe On Wed, Nov 13, 2019 at 8:12 PM Gabe Black <[email protected]> wrote: > Hi folks. I'm looking for a way to enable the m5 utility/pseudo > instructions with fast model CPUs, and it's a little more complicated than > I'd initially assumed. > > I knew there was a memory mapped mechanism to support the pseudo > instructions, and that that was added to enable those instructions in KVM > mode. That is done using the finalizePhysical method on the TLBs which > detects accesses within certain ranges, and then redirects them to memory > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. > > The problem with this approach and fast models is that, for starters, the > port to memory comes out of the fast model already collected from all the > cores that make up a cluster. It isn't possible as far as I can tell to > determine which core (and hence which context) a given request came from to > plumb up the "IPR" access correctly. > > Then beyond that, the accesses come out an AMBA flavor of TLM (the systemc > communication mechanism), and those have to be translate first to regular > TLM, and then to gem5's protocol using separate bridge objects. There isn't > anywhere to insert a call to the finalizePhysical call or equivalent to > intercept requests to the psuedo instruction device. > > One possible solution would be to use a mechanism called semihosting which > is supported by the fast models. Basically, using the SVC instruction with > a magic number (SVC is usually used for system calls) will trap into the > simulation mechanism. The value in R0 is supposed to say what service you > want (read from a file, write to stdout, etc), and then additional > parameters are in a blob pointed to by r1. The IRIS API, a debug API we're > using to implement ThreadContexts for the fast models, has an interface to > trap semihosting events, so it should be possible to run semihosting > instructions, capture them with the IRIS interface, and use that (which > knows what ThreadContext is relevant) to implement a call into the pseudo > instructions. > > This *should* work for fast model CPUs, and it shouldn't be difficult to > add into the native gem5 CPUs where we control what all the instructions > do. KVM, on the other hand, is a bit trickier. I've been digging around in > the KVM and QEMU source, and while QEMU says it supports semihosting, I > don't see anything that makes it look like it supports semihosting *and* > KVM at the same time. That may work through some magic I'm not seeing, but > if I can't find it I can't reimplement it in gem5 :-). > > It looks like KVM used to support a hypercall exit, but I see a change > from the Xen hypervisor guys that made KVM eat all hypercalls internally > and not forward any of them to userspace. They say to use KVM_EXIT_IO on > x86 and KVM_EXIT_MMIO on non-x86 systems to get the same effect. In either > case, I think that forces us into what we have now, where the m5 binary > uses magical addresses to do its work. I think we could switch to using an > IO port on x86 though, and a small window on ARM. In all cases we have > access to the relevant thread context so we don't need to worry about > having a big window for passing around parameters. > > > All this also brings up an idea I had a while ago where I wanted to unify > and generalize the pseudo instruction and system call catching code. In > both cases, gem5 is intercepting a particular instruction and then doing > something special, and it would be nice to have those work in the same way, > and to be able to add new types of calls into gem5 to, for instance, > emulate BIOS interrupts. The idea would be to have a system call call into > an actual stub, but then the stub would use the pseudo instruction > mechanism to call into gem5. gem5 would then know to do a system call or > whatever. This would remove one more difference between SE and FS mode > which would also be nice. > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
