diff options
author | Andreas Sandberg <andreas.sandberg@arm.com> | 2017-03-28 13:50:06 +0000 |
---|---|---|
committer | Andreas Sandberg <andreas.sandberg@arm.com> | 2017-04-03 16:38:26 +0000 |
commit | 31199bba53493bcfb4d130d8c739d698d21b5dd5 (patch) | |
tree | ea3d3a24ee0575f1a7098f7fddb90552c194f353 /ext/iostream3/TODO | |
parent | 9a13acaa367769c38859342de9bc35aac59a6710 (diff) | |
download | gem5-31199bba53493bcfb4d130d8c739d698d21b5dd5.tar.xz |
sim: Handle cases where Drainable::resume() creates objects
There are cases where Drainable objects need to create new objects in
Drainable::resume(). In such cases, the local drain state will be
inherited from the DrainManager. We currently set the state to Running
as soon as we start resuming the simulator. This means that new
objects are created in the Running state rather than the Drained
state, which the resume code assumes. Depending on the traversal order
in DrainManager::resume(), this sometimes triggers a panic because the
object being resumed is in the wrong state.
This change introduces a new drain state, Resuming, that the
DrainManager enters as soon as it starts resuming the
simulator. Objects that are created while resuming are created in this
state. Such objects are then resumed in a subsequent pass over the
list of Drainable objects that need to be resumed. Once all objects
have been resumed, the simulator enters the Running state.
Change-Id: Ieee8645351ffbdec477e9cd2ff86fc795e459617
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2600
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Weiping Liao <weipingliao@google.com>
Diffstat (limited to 'ext/iostream3/TODO')
0 files changed, 0 insertions, 0 deletions