-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3149/
-----------------------------------------------------------

(Updated Oct. 16, 2015, 1:55 p.m.)


Review request for Default.


Changes
-------

Move default_entry creation after check per Brandon's suggestion.


Repository: gem5


Description (updated)
-------

Changeset 11169:0a83a8d08c9e
---------------------------
ruby: Fix block_on behavior

Ruby's controller block_on behavior aimed to block MessageBuffer requests into
SLICC controllers when a Locked_RMW was in flight. Unfortunately, this
functionality only partially works: When non-Locked_RMW memory accesses are
issued to the sequencer to an address with an in-flight Locked_RMW, the
sequencer may pass those accesses through to the controller. At the controller,
a number of incorrect activities can occur depending on the protocol. In
MOESI_hammer, for example, an intermediate IFETCH will cause an L1D to L2
transfer, which cannot be serviced, because the block_on functionality blocks
the trigger queue, resulting in a deadlock. Further, if an intermediate store
arrives (e.g. from a separate SMT thread), the sequencer allows the request
through to the controller, and the atomicity of the Locked_RMW may be broken.

To avoid these problems, disallow the Sequencer from passing any memory
accesses to the controller besides Locked_RMW_Write when a Locked_RMW is in-
flight.


Diffs (updated)
-----

  src/mem/ruby/slicc_interface/AbstractController.cc 207d6f2f1d53 
  src/mem/ruby/system/Sequencer.cc 207d6f2f1d53 
  src/mem/ruby/slicc_interface/AbstractController.hh 207d6f2f1d53 

Diff: http://reviews.gem5.org/r/3149/diff/


Testing
-------

Considered many other potential solutions on gem5-gpu email list, which seem
unlikely to function as desired:
https://groups.google.com/forum/#!topic/gem5-gpu-dev/RQv4SxIKv7g

Found reproducible version of the IFETCH bug with gem5 11139:bd894d2bdd7c 
(using the xsave disable patch in this email thread:  
http://comments.gmane.org/gmane.comp.emulators.m5.devel/24558 )

Reproducible command line: ../build/X86_MOESI_hammer/gem5.opt --outdir=$outdir 
../configs/example/fs.py --ruby --cpu-type=detailed --caches --num-cpus=4 
--script ../configs/boot/hack_back_ckpt.rcS --kernel 
../../full_system_files/binaries/x86_64-vmlinux-2.6.28.4-smp

Verified that the patch fixes the reproducible bug and tested that booting
Linux works with O3CPU and numerous other system configurations.


Thanks,

Joel Hestness

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to