aboutsummaryrefslogtreecommitdiff
path: root/target-ppc
diff options
context:
space:
mode:
authorMichael R. Hines <mrhines@us.ibm.com>2013-07-22 10:01:57 -0400
committerJuan Quintela <quintela@redhat.com>2013-07-23 13:06:37 +0200
commit29ae8a4133082e16970c9d4be09f4b6a15034617 (patch)
tree2a211519af389ec6cabe5628ded968ec93f4c305 /target-ppc
parentd58f574bf39796ed2396dfd1e308352fbb03f944 (diff)
rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
As described in the previous patch, until now, the MIG_STATE_SETUP state was not really a 'formal' state. It has been used as a 'zero' state (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning into this state when the QMP migration command was called. Instead we want to introduce MIG_STATE_NONE, which is our starting state in the state machine, and then immediately transition into the MIG_STATE_SETUP state when the QMP migrate command is issued. In order to do this, we must delay the transition into MIG_STATE_ACTIVE until later in the migration_thread(). This is done to be able to timestamp the amount of time spent in the SETUP state for proper accounting to the user during an RDMA migration. Furthermore, the management software, until now, has never been aware of the existence of the SETUP state whatsoever. This must change, because, timing of this state implies that the state actually exists. These two patches cannot be separated because the 'query_migrate' QMP switch statement needs to know how to handle this new state transition. Reviewed-by: Juan Quintela <quintela@redhat.com> Tested-by: Michael R. Hines <mrhines@us.ibm.com> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
Diffstat (limited to 'target-ppc')
0 files changed, 0 insertions, 0 deletions