mem-ruby: Fix fast-forward when using the backing store.

While the up-to-date data may reside in any agent of Ruby's memory
hierarchy, there's an optional backing store in Ruby that provides
a 'correct' view of the physical memory. When it is enabled by the
user, every Ruby memory access will update this global memory view
as well upon finishing.

The issue is that Ruby's atomic access, used in fast-forward, does
not currently access the backing store, leading to data
incorrectness. More specifically, at the very beginning stage of the
simulation, a loader loads the program into the backing store using
functional accesses. Then the program starts execution with
fast-forward enabled, using atomic accesses for faster simulation. But
because atomic access only accesses the real memory hierarchy, the CPU
fetches incorrect instructions.

The fix is simple. Just make Ruby's atomic access update the backing
store as well as the real physical memory.

Change-Id: I2541d923e18ea488d383097ca7abd4124e47e59b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26343
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Onur Kayıran <onur.kayiran@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>

diff --git a/src/mem/ruby/system/RubyPort.cc b/src/mem/ruby/system/RubyPort.cc
index 800046e101c4852880c8467058336b8de14a65a3..a6cee054a63ba81d341635ea750f52fdfc03289d 100644 (file)
--- a/src/mem/ruby/system/RubyPort.cc
+++ b/src/mem/ruby/system/RubyPort.cc
@@ -339,7 +339,10 @@ RubyPort::MemSlavePort::recvAtomic(PacketPtr pkt)
     RubySystem *rs = ruby_port->m_ruby_system;
     AbstractController *directory =
         rs->m_abstract_controls[id.getType()][id.getNum()];
-    return directory->recvAtomic(pkt);
+    Tick latency = directory->recvAtomic(pkt);
+    if (access_backing_store)
+        rs->getPhysMem()->access(pkt);
+    return latency;
 }
 
 void