Re: [Qemu-devel] early_savevm

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/13/2011 05:55 AM, 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.


I don't think this is a good idea.  We shouldn't present an ad-hoc mechanism to 
configure devices in the device state.

I think this is fundamentally a Xen problem.  Where QEMU locates the buffer it 
uses to represent video RAM is entirely its own business.

What are ya'll doing that necessitates doing something special with video RAM?

Regards,

Anthony Liguori