From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpIPv-00022u-PZ for qemu-devel@nongnu.org; Mon, 23 Jan 2012 06:50:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpIPp-000431-Rg for qemu-devel@nongnu.org; Mon, 23 Jan 2012 06:50:31 -0500 Received: from thoth.sbs.de ([192.35.17.2]:18890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpIPp-00042t-Ea for qemu-devel@nongnu.org; Mon, 23 Jan 2012 06:50:25 -0500 Message-ID: <4F1D4974.4090003@siemens.com> Date: Mon, 23 Jan 2012 12:50:12 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F19AB66.8060901@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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: "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Avi Kivity On 2012-01-23 11:47, 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() Hmm, are you sure that this is the only case where a device init or reset handler writes to already restored guest memory? Preloading the RAM this way is a non-standard scenario for QEMU, thus conceptually fragile. Does restoring happen before QEMU is even started, or can this point be controlled from QEMU? 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: [PATCH v4 0/6] save/restore on Xen Date: Mon, 23 Jan 2012 12:50:12 +0100 Message-ID: <4F1D4974.4090003@siemens.com> References: <4F19AB66.8060901@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: "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Avi Kivity List-Id: xen-devel@lists.xenproject.org On 2012-01-23 11:47, 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() Hmm, are you sure that this is the only case where a device init or reset handler writes to already restored guest memory? Preloading the RAM this way is a non-standard scenario for QEMU, thus conceptually fragile. Does restoring happen before QEMU is even started, or can this point be controlled from QEMU? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux