Re: [Xen-devel] early_savevm

[Jan Kiszka <jan.kiszka@xxxxxxxxxxx>]

On 2011-12-13 12:55, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Stefano Stabellini wrote:
>>> Really, I think this is something inherently incompatible with the
>>> current memory API. If Xen has this unfixable special "requirement"
>>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
>>> Hot-fixing only a single one this way is no good idea long term.
>>
>> Fair enough.
>> What about introducing a type of savevm state that is going to be
>> restored before machine->init?
>> This way we could save and restore our physmap and we could handle
>> memory maps and allocations transparently.
>>
> 
> A bit more context to my suggestion:
> 
> - we open the save state file and check the magic number and the
> version number before machine->init();
> 
> - we add a new set of entries to the save state file that contains
> early_savevm functions: they are called before machine->init();
> 
> - after reaching the end of the early_savevm functions we stop parsing
> the save state file and we call machine->init();
> 
> - after machine->init() is completed we continue parsing the save state
> file as usual.

Hmm, just wondering if another use case for this early incoming
migration step is transferring the machine configuration so that the
receiver need not worry about synchronizing it out of band. That may
help motivating this likely not trivial change.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel