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

Re: [Xen-devel] [Qemu-devel] early_savevm

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?


Anthony Liguori

Xen-devel mailing list



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