From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpMK9-0003ov-Fm for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:00:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpMK1-0006Te-WA for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:00:48 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:39616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpMK1-0006TZ-Ml for qemu-devel@nongnu.org; Mon, 23 Jan 2012 11:00:41 -0500 Received: by ggnr1 with SMTP id r1so851319ggn.4 for ; Mon, 23 Jan 2012 08:00:41 -0800 (PST) Message-ID: <4F1D8423.2090603@codemonkey.ws> Date: Mon, 23 Jan 2012 10:00:35 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F19AB66.8060901@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Jan Kiszka , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Avi Kivity On 01/23/2012 04:47 AM, Stefano Stabellini wrote: > On Fri, 20 Jan 2012, Jan Kiszka wrote: >> On 2012-01-20 18:20, Stefano Stabellini wrote: >>> Hi all, >>> this is the fourth version of the Xen save/restore patch series. >>> We have been discussing this issue for quite a while on #qemu and >>> qemu-devel: >>> >>> >>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2 >>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2 >>> >>> >>> A few different approaches were proposed to achieve the goal >>> of a working save/restore with upstream Qemu on Xen, however after >>> prototyping some of them I came up with yet another solution, that I >>> think leads to the best results with the less amount of code >>> duplications and ugliness. >>> Far from saying that this patch series is an example of elegance and >>> simplicity, but it is closer to acceptable anything else I have seen so >>> far. >>> >>> What's new is that Qemu is going to keep track of its own physmap on >>> xenstore, so that Xen can be fully aware of the changes Qemu makes to >>> the guest's memory map at any time. >>> This is all handled by Xen or Xen support in Qemu internally and can be >>> used to solve our save/restore framebuffer problem. >>> >>> > From the Qemu common code POV, we still need to avoid saving the guest's >>> ram when running on Xen, and we need to avoid resetting the videoram on >>> restore (that is a benefit to the generic Qemu case too, because it >>> saves few cpu cycles). >> >> For my understanding: Refraining from the memset is required as the >> already restored vram would then be overwritten? > > Yep > >> Or what is the ordering >> of init, RAM restore, and initial device reset now? > > RAM restore (done by Xen) > > physmap rebuild (done by xen_hvm_init in qemu) > pc_init() > qemu_system_reset() > load_vmstate() That's your problem. You don't want to do load_vmstate(). You just want to load the device model, not RAM. You should have a separate load_device_state() function and mark anything that is RAM as RAM when doing savevm registration. Better yet, mark devices as devices since that's what you really care about. Regards, Anthony Liguori