From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpiTZ-0006B7-3i for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:40:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpiTU-0002hW-On for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:40:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpiTU-0002hP-8n for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:39:56 -0500 Message-ID: <4F1ED0C3.7030008@redhat.com> Date: Tue, 24 Jan 2012 17:39:47 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F19AB66.8060901@siemens.com> <4F1D4974.4090003@siemens.com> <4F1D4E43.7000501@siemens.com> <4F1D80BA.1040504@siemens.com> <4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws> <4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.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: Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" On 01/24/2012 02:00 PM, Stefano Stabellini wrote: > On Tue, 24 Jan 2012, Avi Kivity wrote: > > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote: > > > >>> > > > >>> But viewing RAM as just another device, having Xen only restore a > > > >>> subset of > > > >>> devices should be a reasonable thing to do moving forward. > > > > > > I don't think modeling device memory (i.e. vga vram) as something > > > independent from the device (vga) is a good idea. Because it isn't. > > > > Right. We should have VMSTATE_RAM() to express the dependency. > > So if I understand correctly you are planning on removing the call to > vmstate_register_ram_global in hw/vga.c? I can't say I'm planning to do so, but that's the direction I think we need to go. > In that case it might be better if I wait for your "VMSTATE_RAM" patch > before I can send a new patch to save only non-RAM devices, because I > guess they will clash with one another. I don't understand what sense a patch to save non-RAM devices makes (or even, what non-RAM devices are). We have a special case here where Xen manages the RAM even though qemu thinks it does. IMO an if (xen) is the best way to express this specialness. -- error compiling committee.c: too many arguments to function