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