Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen

[Avi Kivity]

On 01/24/2012 03:18 PM, Anthony Liguori wrote:
> 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.

It's so that the device's post_load happens after the RAM was loaded.

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

I think that's too heavy a hammer.  Think about things like ivshmem. 
Does it really need to be a composite device?  If we keep going in this
direction the amount of know how needed to write a device for qemu will
be overwhelming.

RAM is a large array of bits.  We model an 32-bit register with a
uint32_t, memory_region_init_io(), and some vmstate.  We should be able
to do the same thing for RAM.

>
> 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.

-- 
error compiling committee.c: too many arguments to function