diff options
author | Andreas Sandberg <andreas@sandberg.pp.se> | 2014-04-03 11:22:49 +0200 |
---|---|---|
committer | Andreas Sandberg <andreas@sandberg.pp.se> | 2014-04-03 11:22:49 +0200 |
commit | 838bcd3b19d2b6375957be986f1dca1803a2b3ce (patch) | |
tree | 8a41affe532df0812a2542c404cc3c0b73b4b420 /src/mem/protocol | |
parent | e553a7bfa7f0eb47b78632cd63e6e1e814025c9a (diff) | |
download | gem5-838bcd3b19d2b6375957be986f1dca1803a2b3ce.tar.xz |
sim: Add the ability to lock and migrate between event queues
We need the ability to lock event queues to enable device accesses
across threads. The serviceOne() method now takes a service lock prior
to handling a new event. By locking an event queue, a different
thread/eq can effectively execute in the context of the locked event
queue. To simplify temporary event queue migrations, this changeset
introduces the EventQueue::ScopedMigration class that unlocks the
current event queue, locks a new event queue, and updates the current
event queue variable.
In order to prevent deadlocks, event queues need to be released when
waiting on barriers. This is implemented using the
EventQueue::ScopedRelease class. An instance of this class is, for
example, used in the BaseGlobalEvent class to release the event queue
when waiting on the synchronization barrier.
The intended use for this functionality is when devices need to be
accessed across thread boundaries. For example, when fast-forwarding,
it might be useful to run devices and CPUs in separate threads. In
such a case, the CPU locks the device queue whenever it needs to
perform IO. This functionality is primarily intended for KVM.
Note: Migrating between event queues can lead to non-deterministic
timing. Use with extreme care!
--HG--
extra : rebase_source : 23e3a741a1fd73861d1339782dbbe1bc76285315
Diffstat (limited to 'src/mem/protocol')
0 files changed, 0 insertions, 0 deletions