5ede3d6497
Before this commit: * SEV events were not waking neither WFE (wrong) nor futex WAIT (correct) * locked memory events (LLSC) due to LDXR and STXR were waking up both WFE (correct) and futex WAIT (wrong) This commit fixes all wrong behaviours mentioned above. The fact that LLSC events were waking up futexes leads to deadlocks, as shown in the test case described at: https://gem5.atlassian.net/browse/GEM5-537 because threads woken up by SVE are not removed from the waiter list for the futex address they are sleeping on. A previous fix atttempt was done at: 1531b56d605d47252dc0620bb3e755b7cf84df97 in which only sleeping threads are woken up. But that is not sufficient, because the futex sleeping thread that was being wrongly woken up on SEV can start to sleep on a second futex. As an example, consider the case where 4 threads are fighting over two critical sections protected by futex1 and futex2 addresses. In this case, one thread wakes up the other thread after it is done with the section. Suppose the following sequence of events: * thread1 is awake and all others are suspended on futex1 * thread1 SEV wakes thread2 from the futex1 while in the critical region 1. This is the wrong behaviour that this patch prevents, because now thread2 is still in the sleeper list for futex1 * thread1 then futex wakes tread3, then proceeds to critical region 2. * thread3 wakes up, but because thread2 has critical region, it sleeps again. * thread2 finishes its work, futex wakes thread3, and then proceeds to futex2 When it reaches futex2, thread1 is still working there, so it sleeps on futex2. * thread3 futex wakes thread2, because it is still wrongly on the sleeper list of futex1. But thread2 is in futex2 now. If it weren't for this mistake, it should have awaken the final thread4 instead. Outcome: thread4 sleeps forever, no other thread ever wakes it, because all other threads have woken from futex1 and awoken another thread. The problem is fixed by adding the waitingTcs unordered_set FutexMap, which is basically an inverse map to FutexMap, which tracks (addr, tgid) -> ThreadContext. This allows us allow to quickly check if a given ThreadContext is waiting on a futex in any address. Then the SEV wakeup code path now checks if the thread is k Change-Id: Icec5e30b041f53e5aa3b6e0d291e77bc0e865984 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29777 Reviewed-by: Jason Lowe-Power <power.jg@gmail.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Jason Lowe-Power <power.jg@gmail.com> Maintainer: Brandon Potter <Brandon.Potter@amd.com> Tested-by: kokoro <noreply+kokoro@google.com>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.