o3: Fix issue with LLSC ordering and speculation
This patch unlocks the cpu-local monitor when the CPU sees a snoop to a locked address. Previously we relied on the cache to handle the locking for us, however some users on the gem5 mailing list reported a case where the cpu speculatively executes a ll operation after a pending sc operation in the pipeline and that makes the cache monitor valid. This should handle that case by invaliding the local monitor.
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
/*
|
||||
* Copyright (c) 2010-2011 ARM Limited
|
||||
* Copyright (c) 2010-2012 ARM Limited
|
||||
* All rights reserved
|
||||
*
|
||||
* The license below extends only to copyright in the software and shall
|
||||
@@ -435,6 +435,18 @@ LSQUnit<Impl>::checkSnoop(PacketPtr pkt)
|
||||
cacheBlockMask = ~(bs - 1);
|
||||
}
|
||||
|
||||
// Unlock the cpu-local monitor when the CPU sees a snoop to a locked
|
||||
// address. The CPU can speculatively execute a LL operation after a pending
|
||||
// SC operation in the pipeline and that can make the cache monitor the CPU
|
||||
// is connected to valid while it really shouldn't be.
|
||||
for (int x = 0; x < cpu->numActiveThreads(); x++) {
|
||||
ThreadContext *tc = cpu->getContext(x);
|
||||
bool no_squash = cpu->thread[x]->noSquashFromTC;
|
||||
cpu->thread[x]->noSquashFromTC = true;
|
||||
TheISA::handleLockedSnoop(tc, pkt, cacheBlockMask);
|
||||
cpu->thread[x]->noSquashFromTC = no_squash;
|
||||
}
|
||||
|
||||
// If this is the only load in the LSQ we don't care
|
||||
if (load_idx == loadTail)
|
||||
return;
|
||||
|
||||
Reference in New Issue
Block a user