From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpgDE-00082i-96 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:15:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpgD8-0002jX-A4 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:15:00 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:44428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpgD8-0002jO-4k for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:14:54 -0500 Received: by iahk25 with SMTP id k25so4559993iah.4 for ; Tue, 24 Jan 2012 05:14:52 -0800 (PST) Message-ID: <4F1EAEC7.5050304@codemonkey.ws> Date: Tue, 24 Jan 2012 07:14:47 -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> In-Reply-To: <4F1E91AF.9040402@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 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. A video card would have a Ram device via composition. 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. >> Onboard RAM is a very special case because it's extremely unusual. > > What's unusual (or even extremely unusual) about it? I don't see a > difference between a few billion bits of state and, say, the few bits of > state in an RTC device. Okay, but let's not get philosophical here :-) There are very few devices that have a DRAM chip that is mapped through a bar into the main address space and behaves (usually) like normal RAM. >> 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? Regards, Anthony Liguori