Steve Sistare <steven.sist...@oracle.com> writes: > A guest that is migrated in the suspended state automaticaly wakes and > continues execution. This is wrong; the guest should end migration in > the same state it started. The root cause is that the outgoing migration > code automatically wakes the guest, then saves the RUNNING runstate in > global_state_store(), hence the incoming migration code thinks the guest is > running and continues the guest if autostart is true. > > Simply deleting the call to qemu_system_wakeup_request() on the outgoing > side, to migrate the vm in state suspended, does not solve the problem. > The old vm_stop_force_state does little if the vm is suspended, so the cpu > clock remains running, and runstate notifiers for the stop transition are > not called (and were not called on transition to suspended). Stale cpu > timers_state is saved to the migration stream, causing time errors in the > guest when it wakes from suspend. State that would have been modified by > runstate notifiers is wrong. > > The new version of vm_stop_force_state solves the outgoing problems, by > completely stopping a vm in the suspended state. > > On the incoming side for precopy, compute the desired new state from global > state received, and call runstate_restore, which will partially > resume the vm if the state is suspended. A future system_wakeup monitor > request will cause the vm to resume running. > > On the incoming side for postcopy, apply the the same restore logic found > in precopy. > > Signed-off-by: Steve Sistare <steven.sist...@oracle.com>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
