Re: [PATCH V5 05/12] migration: preserve suspended runstate

[Fabiano Rosas]

Steve Sistare <steven.sistare@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.sistare@oracle.com>

Reviewed-by: Fabiano Rosas <farosas@suse.de>