> On 2011-12-03 12:57:30, Steve Reinhardt wrote: > > src/cpu/DummyChecker.py, line 1 > > <http://reviews.m5sim.org/r/910/diff/2/?file=15591#file15591line1> > > > > What's this DummyChecker object for? > > Geoffrey Blake wrote: > In short, the DummyChecker allows checkpoints and fast forwarding to work > by setting up the ports the real checker will need when it is switched in > with the detailed model.
Can you explain in a little more detail why this is needed? What happens when you try and restore a checkpoint to a system with a checker when you don't have a DummyChecker in there to begin with? > On 2011-12-03 12:57:30, Steve Reinhardt wrote: > > src/cpu/thread_context.hh, line 127 > > <http://reviews.m5sim.org/r/910/diff/2/?file=15617#file15617line127> > > > > I agree with Gabe here... you're always doing things like: > > > > if (cpu->getCheckerCpuPtr()) { > > cpu->getCheckerITBPtr()->foo(); > > cpu->getCheckerDTBPtr()->foo(); > > } > > > > so why don't you just do: > > > > CPU *checker = cpu->getCheckerCpuPtr(); > > if (checker) { > > checker->getITBPtr()->foo; > > checker->getDTBPtr()->foo; > > } > > > > which seems just as clear (if not clearer) and avoids the need for > > these extra methods. > > > > Geoffrey Blake wrote: > This wouldn't be too painful of a fix just for the Checker. The checker > is a special case. > > But as to which is clearer, its a wash in my opinion as everywhere in the > code base the ITB/DTB pointers are accessed via the ThreadContext object and > not a Cpu object so the Checker will always stand out as being special. I'm not clear on your comment... I used CPU in the example, but I think you can do exactly the same thing with ThreadContext, right? > On 2011-12-03 12:57:30, Steve Reinhardt wrote: > > src/mem/bus.cc, line 480 > > <http://reviews.m5sim.org/r/910/diff/2/?file=15618#file15618line480> > > > > I agree with Andreas here... from Geoff's description, I think the real > > bug he's facing is that the ARM config he's using doesn't have a default > > responder on the I/O bus. There should be something out there that if > > nothing else sends an error response packet back to the requester. The > > requester can then decide if it wants to panic and terminate the simulation > > or not. > > > > If blindly accessing the default port when it's not set is causing us > > to segfault on a null pointer, then we should require that every bus has a > > default responder at config time. We have at least one dummy/bad address > > device just for this purpose. > > Geoffrey Blake wrote: > The error is not that the request is bad. Its the order in which the > memory objects are searched and the end conditions for a functional access. > Putting a default responder on the IOBus and having it respond to a > functional access will just cause the bug to occur from a different place. > Would a better solution be putting a default responder that ignores > functional accesses on the IOBus so they can pass through to the memory bus? > That way if the address is truly bad, the badaddr_responder on the membus > will cause the simulation to panic and stop. OK, I think I see the problem... I think the issue is that the IOCache snoops on the membus, and can contain any address, so it always has to be probed; and caches by default forward functional requests they don't satisfy to the other side, so that (for example) a check in an L2 will cause the request to get forwarded up to its corresponding L1(s) if necessary. The trick is that normally in the latter case the L2 is the default responder; the IOCache/IOBus case is special because the IOCache is not the default responder. If this is the problem, then what you need is to put a default responder on the IOBus, but set its address range to restrict it to the I/O address range, and then set the use_default_range flag on the IOBus. That should prevent the default responder from responding to functional requests that don't map to the I/O bus. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/910/#review1720 ----------------------------------------------------------- On 2011-11-28 10:07:14, Geoffrey Blake wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/910/ > ----------------------------------------------------------- > > (Updated 2011-11-28 10:07:14) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > CheckerCPU: Re-factor CheckerCPU to be compatible with current gem5 > > Brings the CheckerCPU back to a functioning state allowing FS and SE mode > checking of the O3CPU. These changes have only been tested with the > ARM ISA. Other ISAs will potentially require modification. > > > Diffs > ----- > > build_opts/ARM_wCHECKER_FS PRE-CREATION > build_opts/ARM_wCHECKER_SE PRE-CREATION > src/arch/arm/isa.cc 62dee0c98d53 > src/arch/arm/isa/insts/m5ops.isa 62dee0c98d53 > src/arch/arm/isa/insts/misc.isa 62dee0c98d53 > src/arch/arm/table_walker.hh 62dee0c98d53 > src/arch/arm/table_walker.cc 62dee0c98d53 > src/arch/arm/tlb.hh 62dee0c98d53 > src/arch/arm/tlb.cc 62dee0c98d53 > src/arch/arm/utility.cc 62dee0c98d53 > src/cpu/BaseCPU.py 62dee0c98d53 > src/cpu/CheckerCPU.py 62dee0c98d53 > src/cpu/DummyChecker.py PRE-CREATION > src/cpu/SConscript 62dee0c98d53 > src/cpu/base.cc 62dee0c98d53 > src/cpu/base_dyn_inst.hh 62dee0c98d53 > src/cpu/base_dyn_inst_impl.hh 62dee0c98d53 > src/cpu/checker/cpu.hh 62dee0c98d53 > src/cpu/checker/cpu.cc 62dee0c98d53 > src/cpu/checker/cpu_impl.hh 62dee0c98d53 > src/cpu/checker/thread_context.hh 62dee0c98d53 > src/cpu/dummy_checker_builder.cc PRE-CREATION > src/cpu/o3/O3CPU.py 62dee0c98d53 > src/cpu/o3/O3Checker.py 62dee0c98d53 > src/cpu/o3/checker_builder.cc 62dee0c98d53 > src/cpu/o3/commit_impl.hh 62dee0c98d53 > src/cpu/o3/cpu.hh 62dee0c98d53 > src/cpu/o3/cpu.cc 62dee0c98d53 > src/cpu/o3/dyn_inst_impl.hh 62dee0c98d53 > src/cpu/o3/fetch_impl.hh 62dee0c98d53 > src/cpu/o3/iew_impl.hh 62dee0c98d53 > src/cpu/o3/lsq_unit_impl.hh 62dee0c98d53 > src/cpu/o3/thread_context.hh 62dee0c98d53 > src/cpu/o3/thread_context_impl.hh 62dee0c98d53 > src/cpu/simple/BaseSimpleCPU.py 62dee0c98d53 > src/cpu/simple/base.hh 62dee0c98d53 > src/cpu/simple/base.cc 62dee0c98d53 > src/cpu/simple_thread.hh 62dee0c98d53 > src/cpu/thread_context.hh 62dee0c98d53 > src/mem/bus.cc 62dee0c98d53 > > Diff: http://reviews.m5sim.org/r/910/diff > > > Testing > ------- > > Successfully runs gzip in SE mode. Successfully boots linux kernel in FS > mode. Works with checkpoints and fast-forwarding. Testing with buggy O3CPUs > to test checker's capabilities. > > > Thanks, > > Geoffrey > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
