Arg. Unfortunately it looks like you can only set watchpoints based on virtual addresses, not physical addresses. I may still have to go the semihosting hook route, and that means yet another flavor of m5 binary. I think something I'm going to try to tackle is coming up with a way to detect what mechanism to use from within the simulation, which is actually pretty tricky since it may change across checkpoints, CPU switches, etc. Perhaps some sort of coprocessor register or something? It will almost certainly need to be ISA specific.
Gabe On Thu, Nov 14, 2019 at 1:38 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Hi Gabe, > > > It's good that you've found a solution. > Just so you know, semihosting is already implemented in gem5-arm, so it > would be easy to extend it > in order to support pseudo instructions. > > Giacomo > ------------------------------ > *From:* gem5-dev <gem5-dev-boun...@gem5.org> on behalf of Gabe Black < > gabebl...@google.com> > *Sent:* 14 November 2019 04:55 > *To:* gem5 Developer List <gem5-dev@gem5.org> > *Subject:* Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo > instructions, and system calls > > 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 <gabebl...@google.com> 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 > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
