ruby: Fix block_on behavior
authorJoel Hestness <jthestness@gmail.com>
Fri, 15 Apr 2016 17:34:02 +0000 (12:34 -0500)
committerJoel Hestness <jthestness@gmail.com>
Fri, 15 Apr 2016 17:34:02 +0000 (12:34 -0500)
commit39e10ced035a7e1f53673fc998741f8b6067135d
tree481fd83c90f869034215115504d8eb5128e9a384
parentedbf748181bdd3ac86838e7c55d98a336b285e01
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.
src/mem/ruby/slicc_interface/AbstractController.cc
src/mem/ruby/slicc_interface/AbstractController.hh
src/mem/ruby/system/Sequencer.cc