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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v4 0/6] save/restore on Xen Date: Mon, 23 Jan 2012 10:00:35 -0600 Message-ID: <4F1D8423.2090603@codemonkey.ws> References: <4F19AB66.8060901@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Jan Kiszka , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Avi Kivity List-Id: xen-devel@lists.xenproject.org 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