From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:51814)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RpgHA-0001km-98
	for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:19:05 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RpgH9-0003bR-4n
	for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:19:04 -0500
Received: from mail-gx0-f173.google.com ([209.85.161.173]:32880)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RpgH9-0003bN-0P
	for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:19:03 -0500
Received: by ggnr1 with SMTP id r1so1497085ggn.4
	for <qemu-devel@nongnu.org>; Tue, 24 Jan 2012 05:19:02 -0800 (PST)
Message-ID: <4F1EAFC1.6040204@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:18:57 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
In-Reply-To: <4F1E923D.2090208@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Gerd Hoffmann <kraxel@redhat.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

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.

Ram should be a device and then you can hook up ram through the composition tree.

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.

Regards,

Anthony Liguori

>