FYI I base that not on anything in the documentation (it's never mentioned), but the fact that if I pick an address space that's physical, I get a vague "that didn't work" error from the fast models.
Gabe On Thu, Nov 14, 2019 at 5:45 PM Gabe Black <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> on behalf of Gabe Black < >> [email protected]> >> *Sent:* 14 November 2019 04:55 >> *To:* gem5 Developer List <[email protected]> >> *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 <[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 >> 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] http://m5sim.org/mailman/listinfo/gem5-dev
