[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.