From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4 0/6] save/restore on Xen Date: Tue, 24 Jan 2012 17:56:47 +0200 Message-ID: <4F1ED4BF.20505@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F1EAEC7.5050304@codemonkey.ws> 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: Anthony Liguori Cc: Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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