From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpiX3-0007Kc-VD for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:43:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpiWy-00033q-Tm for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:43:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpiWy-00033b-M2 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:43:32 -0500 Message-ID: <4F1ED19C.6060507@redhat.com> Date: Tue, 24 Jan 2012 17:43:24 +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> <4F1EAFC1.6040204@codemonkey.ws> In-Reply-To: <4F1EAFC1.6040204@codemonkey.ws> 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: Anthony Liguori Cc: Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , Stefano Stabellini , "qemu-devel@nongnu.org" On 01/24/2012 03:18 PM, Anthony Liguori wrote: > On 01/24/2012 05:13 AM, 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. > > No, VMSTATE has nothign to do with reset. It's so that the device's post_load happens after the RAM was loaded. > > Ram should be a device and then you can hook up ram through the > composition tree. I think that's too heavy a hammer. Think about things like ivshmem. Does it really need to be a composite device? If we keep going in this direction the amount of know how needed to write a device for qemu will be overwhelming. RAM is a large array of bits. We model an 32-bit register with a uint32_t, memory_region_init_io(), and some vmstate. We should be able to do the same thing for RAM. > > But reset is going to propagate preorder, not postorder, so this isn't > going to help anyway. > > Postorder initialization doesn't make a whole lot of sense when you > think about the semantics of it. -- error compiling committee.c: too many arguments to function