> On 2011-11-28 10:37:35, Andreas Hansson wrote: > > src/mem/bus.cc, line 480 > > <http://reviews.m5sim.org/r/910/diff/2/?file=15618#file15618line480> > > > > Why? This seems odd to me. If it is a response then someone responded > > during the snooping. If the destination port is the same as the source we > > have a loop. Why should it not continue if it is the default port? > > > > Is this not working around an issue located somewhere else? > > Geoffrey Blake wrote: > This workaround is due to the recursive nature of a functional access, > and the presence of coherent I/O in FS mode. If a functional access goes all > the way out to the membus, it will first access the snooping devices hanging > off the membus, which is the iocache. It has an active address range for the > ARM realview test setups I'm using as 0x0-256MB. If the iocache does not > satisfy the request it will send the functional access onto the iobus and > probably not find a device to satisfy the access thereby sending it to the > default port which is effectively a null pointer, crashing the simulation > when accessed. The Checker setup does exercise the functional memory access > path heavily though. Thinking about it now, I'm surprised this hasn't been > hit before in normal operation. > > Ali is probably better suited to offer an opinion on a better solution to > this as he's pretty familiar with the I/O setup in M5. > > Andreas Hansson wrote: > Sorry, but I am still not seeing the bigger picture here. A CPU (in this > case checker?) makes an access to an address that does not exist in the > system? Why would that ever be right? The only reason it would end up at an > unconnected default port is if the address is used incorrectly as far as I > can tell. Am I missing something? >
The Checker makes functional accesses only into the memory system to see if it is seeing the same state as the O3. These functional accesses visit every memory object that could potentially hold the value the access is looking for by doing a breadth first search of the memory hierarchy tree as defined by the busses and stops the search once the request is satisfied. The fix in question is just telling the functional access to stop looking along a search path when no memory object attached to a bus can satisfy its request. So it is not making an access to a non-existent address, but the order it searched the tree of memory objects had the request searching the io devices off the iobus first instead of searching the physmem object which would have satisfied the request in this particular case. If an actual access, such as a timing access ends up in this state, it will cause the simulator to panic as it is an actual error. Does this clarify what this particular piece of code is doing? - Geoffrey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/910/#review1694 ----------------------------------------------------------- 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
