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:
Ali Saidi
2013-01-07 13:05:33 -05:00
parent 5146a69835
commit 69d419f313
7 changed files with 126 additions and 1 deletions

View File

@@ -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;