From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaRa0-0003Bu-6e for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:35:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaRZu-00043a-Ip for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:35:32 -0500 Received: from goliath.siemens.de ([192.35.17.28]:32172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaRZu-00043I-99 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 07:35:26 -0500 Message-ID: <4EE74684.7010708@siemens.com> Date: Tue, 13 Dec 2011 13:35:16 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com> <1323467645-24271-6-git-send-email-anthony.perard@citrix.com> <4EE3382D.80903@web.de> <4EE609BF.1070307@siemens.com> <4EE617BA.4030102@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] early_savevm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , Xen Devel , QEMU-devel On 2011-12-13 12:55, Stefano Stabellini wrote: > On Mon, 12 Dec 2011, Stefano Stabellini wrote: >>> Really, I think this is something inherently incompatible with the >>> current memory API. If Xen has this unfixable special "requirement" >>> (it's rather a design issue IMHO), adjust the API and adapt all devices. >>> Hot-fixing only a single one this way is no good idea long term. >> >> Fair enough. >> What about introducing a type of savevm state that is going to be >> restored before machine->init? >> This way we could save and restore our physmap and we could handle >> memory maps and allocations transparently. >> > > A bit more context to my suggestion: > > - we open the save state file and check the magic number and the > version number before machine->init(); > > - we add a new set of entries to the save state file that contains > early_savevm functions: they are called before machine->init(); > > - after reaching the end of the early_savevm functions we stop parsing > the save state file and we call machine->init(); > > - after machine->init() is completed we continue parsing the save state > file as usual. Hmm, just wondering if another use case for this early incoming migration step is transferring the machine configuration so that the receiver need not worry about synchronizing it out of band. That may help motivating this likely not trivial change. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: early_savevm Date: Tue, 13 Dec 2011 13:35:16 +0100 Message-ID: <4EE74684.7010708@siemens.com> References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com> <1323467645-24271-6-git-send-email-anthony.perard@citrix.com> <4EE3382D.80903@web.de> <4EE609BF.1070307@siemens.com> <4EE617BA.4030102@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: Anthony Perard , Xen Devel , QEMU-devel List-Id: xen-devel@lists.xenproject.org On 2011-12-13 12:55, Stefano Stabellini wrote: > On Mon, 12 Dec 2011, Stefano Stabellini wrote: >>> Really, I think this is something inherently incompatible with the >>> current memory API. If Xen has this unfixable special "requirement" >>> (it's rather a design issue IMHO), adjust the API and adapt all devices. >>> Hot-fixing only a single one this way is no good idea long term. >> >> Fair enough. >> What about introducing a type of savevm state that is going to be >> restored before machine->init? >> This way we could save and restore our physmap and we could handle >> memory maps and allocations transparently. >> > > A bit more context to my suggestion: > > - we open the save state file and check the magic number and the > version number before machine->init(); > > - we add a new set of entries to the save state file that contains > early_savevm functions: they are called before machine->init(); > > - after reaching the end of the early_savevm functions we stop parsing > the save state file and we call machine->init(); > > - after machine->init() is completed we continue parsing the save state > file as usual. Hmm, just wondering if another use case for this early incoming migration step is transferring the machine configuration so that the receiver need not worry about synchronizing it out of band. That may help motivating this likely not trivial change. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux