From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpkWV-0006tL-R9 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 12:51:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpkWR-0005pd-Dl for qemu-devel@nongnu.org; Tue, 24 Jan 2012 12:51:11 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:46313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpkWR-0005pR-B4 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 12:51:07 -0500 Received: by ggnr1 with SMTP id r1so1741236ggn.4 for ; Tue, 24 Jan 2012 09:51:06 -0800 (PST) Message-ID: <4F1EEF85.1020900@codemonkey.ws> Date: Tue, 24 Jan 2012 11:51:01 -0600 From: Anthony Liguori 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> <4F1ED4BF.20505@redhat.com> In-Reply-To: <4F1ED4BF.20505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Stefano Stabellini On 01/24/2012 09:56 AM, Avi Kivity wrote: > 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. Yup. And boards can subclass the Ram device in order to be able to restrict the valid RAM sizes. -m just becomes an analysis to set the ram size for a ram device. The infrastructure around RAMBlock, etc. would go away as each RAMBlock would correspond to a Ram device. >> A video card would have a Ram device via composition. > > IMO, overkill. I think it's a lot of refactoring to get there and it's not the most critical infrastructure changes we have coming up, but I think it would be nice to get there eventually. > >> >> 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? Yes, it would be depth first, but you're looking for a preorder and post order hook. In otherwords: void do_reset(DeviceState *dev) { dev->pre_reset(dev); // this is preorder do_reset_all(dev->children); dev->post_reset(dev); // this is postorder } The PCI bus overloads the reset handler and does a post-order reset. I guess I can rationalize it after all but it's not entirely clear to me that a pre_reset hook isn't necessary too. > 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. The cost of composition is pretty trivial. struct VGADevice { DeviceState parent; Ram vga_ram; }; static void vga_device_initfn(Object *obj) { VGADevice *vga = VGA(obj); object_property_add_child(obj, "vram", (Object *)&vga_ram, TYPE_RAM, NULL); } Now a user can control the VGA ram size by accessing vga/vram.size = 16M. Regards, Anthony Liguori