summaryrefslogtreecommitdiff
path: root/util/m5
diff options
context:
space:
mode:
authorJoel Hestness <jthestness@gmail.com>2016-04-15 12:34:02 -0500
committerJoel Hestness <jthestness@gmail.com>2016-04-15 12:34:02 -0500
commit39e10ced035a7e1f53673fc998741f8b6067135d (patch)
tree481fd83c90f869034215115504d8eb5128e9a384 /util/m5
parentedbf748181bdd3ac86838e7c55d98a336b285e01 (diff)
downloadgem5-39e10ced035a7e1f53673fc998741f8b6067135d.tar.xz
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.
Diffstat (limited to 'util/m5')
0 files changed, 0 insertions, 0 deletions