On 2011-06-12 19:13, Avi Kivity wrote: > On 06/11/2011 12:05 PM, Jan Kiszka wrote: >> From: Jan Kiszka<jan.kis...@siemens.com> >> >> In case we load the vmstate during incoming migration, we start from a >> clean, default machine state as we went through system reset before. But >> if we load from a snapshot, the machine can be in any state. That can >> cause troubles if loading an older image which does not carry all state >> information the executing QEMU requires. Almost no device takes care of >> this scenario. >> >> However, fixing this is trivial. We just need to issue a system reset >> during loadvm as well. >> >> Signed-off-by: Jan Kiszka<jan.kis...@siemens.com> >> --- >> savevm.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/savevm.c b/savevm.c >> index 98b2422..5db01aa 100644 >> --- a/savevm.c >> +++ b/savevm.c >> @@ -2074,6 +2074,7 @@ int load_vmstate(const char *name) >> return -EINVAL; >> } >> >> + qemu_system_reset(); >> ret = qemu_loadvm_state(f); >> >> qemu_fclose(f); > > Should we suppress the reset event sent out on the monitor? After all, > it's the result of an internal implementation choice, not something the > user or the guest did.
We already issue this pattern during -loadvm or -incoming - or is the monitor not yet connected at this point? Jan
signature.asc
Description: OpenPGP digital signature
