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