From: Yuan Yao Date: Sun, 23 Feb 2020 22:16:03 +0000 (-0500) Subject: mem-ruby: Fix fast-forward when using the backing store. X-Git-Tag: v20.0.0.0~351 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f5e1e1b854499aa11ec1aba1b8fd60a32be0ea50;p=gem5.git 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 Reviewed-by: Onur Kayıran Maintainer: Jason Lowe-Power Tested-by: kokoro --- diff --git a/src/mem/ruby/system/RubyPort.cc b/src/mem/ruby/system/RubyPort.cc index 800046e10..a6cee054a 100644 --- 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