From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWRCs-0004gT-VY for qemu-devel@nongnu.org; Tue, 14 Jun 2011 06:50:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWRCm-0001Ay-Rx for qemu-devel@nongnu.org; Tue, 14 Jun 2011 06:50:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWRCm-0001Ag-Jr for qemu-devel@nongnu.org; Tue, 14 Jun 2011 06:50:44 -0400 Message-ID: <4DF73CFF.3070403@redhat.com> Date: Tue, 14 Jun 2011 13:50:39 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DF32FC6.3040607@web.de> <4DF4F3CB.1070408@redhat.com> <4DF6FD6D.6020109@web.de> In-Reply-To: <4DF6FD6D.6020109@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Reset system before loadvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Luiz Capitulino On 06/14/2011 09:19 AM, Jan Kiszka wrote: > On 2011-06-12 19:13, Avi Kivity wrote: > > On 06/11/2011 12:05 PM, Jan Kiszka wrote: > >> 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. 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. > > >> + 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? I believe it is not. But regardless, we shouldn't add more incorrect behaviour. -- error compiling committee.c: too many arguments to function