sim-se: don't wake up SE futex syscalls on ARM events

sim-se: don't wake up SE futex syscalls on ARM events

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>