From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpIjf-00079r-1S for qemu-devel@nongnu.org; Mon, 23 Jan 2012 07:10:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpIjZ-00078c-C1 for qemu-devel@nongnu.org; Mon, 23 Jan 2012 07:10:54 -0500 Received: from thoth.sbs.de ([192.35.17.2]:27366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpIjZ-00078C-1I for qemu-devel@nongnu.org; Mon, 23 Jan 2012 07:10:49 -0500 Message-ID: <4F1D4E43.7000501@siemens.com> Date: Mon, 23 Jan 2012 13:10:43 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F19AB66.8060901@siemens.com> <4F1D4974.4090003@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" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Avi Kivity On 2012-01-23 12:59, Stefano Stabellini wrote: > On Mon, 23 Jan 2012, Jan Kiszka wrote: >>>> 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? > > Consider that this only happens with non-MMIO device memory, in practice > only videoram. > Vmware VGA does not memset the videoram in the reset handler, while QXL > already has the following: > > /* pre loadvm reset must not touch QXLRam. This lives in > * device memory, is migrated together with RAM and thus > * already loaded at this point */ > if (!loadvm) { > qxl_reset_state(d); > } Yes, but QEMU restores the RAM _after_ device reset, not before it. That's the problem with the Xen way - it is against the current QEMU standard. 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 13:10:43 +0100 Message-ID: <4F1D4E43.7000501@siemens.com> References: <4F19AB66.8060901@siemens.com> <4F1D4974.4090003@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" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Avi Kivity List-Id: xen-devel@lists.xenproject.org On 2012-01-23 12:59, Stefano Stabellini wrote: > On Mon, 23 Jan 2012, Jan Kiszka wrote: >>>> 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? > > Consider that this only happens with non-MMIO device memory, in practice > only videoram. > Vmware VGA does not memset the videoram in the reset handler, while QXL > already has the following: > > /* pre loadvm reset must not touch QXLRam. This lives in > * device memory, is migrated together with RAM and thus > * already loaded at this point */ > if (!loadvm) { > qxl_reset_state(d); > } Yes, but QEMU restores the RAM _after_ device reset, not before it. That's the problem with the Xen way - it is against the current QEMU standard. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux