From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpik5-0005U6-8v for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:57:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpijz-0005BG-Gn for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:57:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpijz-0005BC-8q for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:56:59 -0500 Message-ID: <4F1ED4BF.20505@redhat.com> Date: Tue, 24 Jan 2012 17:56: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> <4F1E91AF.9040402@redhat.com> <4F1EAEC7.5050304@codemonkey.ws> In-Reply-To: <4F1EAEC7.5050304@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 , "qemu-devel@nongnu.org" , Stefano Stabellini On 01/24/2012 03:14 PM, Anthony Liguori wrote: > On 01/24/2012 05:10 AM, Avi Kivity wrote: >> On 01/23/2012 07:18 PM, Anthony Liguori wrote: >>> Generally speaking, RAM is an independent device in most useful cases. >> >> Can you give examples? Do you mean a subdevice with composition, or a >> really independent device? > > I expect we'll have one Ram device. It's size will be configurable. > One Ram device will hang off of the machine which would be the main ram. We'll also have a hotpluggable variant which talks to some GPIOs. A motherboard may support multiple slots with such devices. > A video card would have a Ram device via composition. IMO, overkill. > > The important consideration about reset is how it propagates. My > expectation is that we'll propagate reset through the composition tree > in a preorder transversal. That means in the VGA device reset > function, it's child device (Ram) has not been reset yet. Doesn't depth first make more sense? A bus is considered reset after all devices in the bus have been reset. > >>> We really should view RAM as just another device so I don't like the >>> idea of propagating a global concept of "when RAM is restored" because >>> that treats it specially compared to other devices. >> >> Agree. In fact the first step has been taken as now creating a RAM >> region with memory_region_init_ram() doesn't register it for migration. >> The next step would be a VMSTATE_RAM() to make it part of the containing >> device. > > That's not necessary (or wise). > > Let's not confuse a Ram device with a MemoryRegion. They are separate > things and should be treated as separate things. I thought we > discussed that MemoryRegions are stateless (or at least, there state > is all derived) and don't need to be serialized? Well, the actual bits in memory are state. All other attributes are indeed derived. I just think that making any device that has a bit of RAM a composed device is overkill. What do we gain from it? The cost is not trivial. -- error compiling committee.c: too many arguments to function