[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 Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |