From patchwork Tue Jun 21 17:57:28 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luiz Capitulino X-Patchwork-Id: 101356 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B2754B6F7B for ; Wed, 22 Jun 2011 04:57:30 +1000 (EST) Received: from localhost ([::1]:34799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ68c-00048s-RL for incoming@patchwork.ozlabs.org; Tue, 21 Jun 2011 14:57:27 -0400 Received: from eggs.gnu.org ([140.186.70.92]:41206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Cr-0004LQ-Eu for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5Cl-0000rc-IF for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:57:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Ck-0000rR-T5 for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:57:39 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5LHvcsX013457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 13:57:38 -0400 Received: from localhost (ovpn-113-137.phx2.redhat.com [10.3.113.137]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p5LHvbxD003223; Tue, 21 Jun 2011 13:57:37 -0400 From: Luiz Capitulino To: aliguori@us.ibm.com Date: Tue, 21 Jun 2011 14:57:28 -0300 Message-Id: <1308679048-4441-4-git-send-email-lcapitulino@redhat.com> In-Reply-To: <1308679048-4441-1-git-send-email-lcapitulino@redhat.com> References: <1308679048-4441-1-git-send-email-lcapitulino@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Cc: Jan Kiszka , qemu-devel@nongnu.org Subject: [Qemu-devel] [PATCH 3/3] Reset system before loadvm X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org From: Jan Kiszka 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. Hardly any 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 Signed-off-by: Luiz Capitulino --- savevm.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/savevm.c b/savevm.c index 939845c..8139bc7 100644 --- a/savevm.c +++ b/savevm.c @@ -2073,6 +2073,7 @@ int load_vmstate(const char *name) return -EINVAL; } + qemu_system_reset(VMRESET_SILENT); ret = qemu_loadvm_state(f); qemu_fclose(f);