Searched hist:10153 (Results 1 - 4 of 4) sorted by relevance
| /gem5/src/sim/ | ||
| H A D | global_event.hh | 10153:936a3a8006f6 Thu Apr 03 05:22:00 EDT 2014 Andreas Sandberg <andreas@sandberg.pp.se> 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! |
| H A D | simulate.cc | 10153:936a3a8006f6 Thu Apr 03 05:22:00 EDT 2014 Andreas Sandberg <andreas@sandberg.pp.se> 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! |
| H A D | eventq.cc | 10153:936a3a8006f6 Thu Apr 03 05:22:00 EDT 2014 Andreas Sandberg <andreas@sandberg.pp.se> 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! |
| H A D | eventq.hh | 10153:936a3a8006f6 Thu Apr 03 05:22:00 EDT 2014 Andreas Sandberg <andreas@sandberg.pp.se> 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! |
Completed in 33 milliseconds