qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] vm state save/restore question


From: Benjamin Herrenschmidt
Subject: [Qemu-devel] vm state save/restore question
Date: Sat, 09 Jun 2012 20:53:12 +1000

Hi folks !

I'm looking at sorting out the state save/restore of target-ppc (which
means understanding in general how it works in qemu :-)

So far I've somewhat figured out that there's the "old way" where we
just provide a "bulk" save/restore function pair, and the "new way"
where we have nicely tagged field lists etc...

x86 seems to use the later for the CPU state, ppc is a mess and uses the
former with interesting incompatible format change depending on how qemu
is build :-) So I think that's one area I need to fix.

However, another issue I have, I'm not sure how to fix properly:

When using the "spapr" machine model (pseries), which is in effect a
paravirtualized model, the MMU hash table isn't part of the guest
memory. It's either somewhere in qemu own memory (full emu) or in the
host kernel (kvm) and it's accessed via hcalls.

Now, that's per-se is fine, I can add a pair of save/restore hooks in
spapr to handle it (in fact using the "old" scheme here makes sense
since it's a potentially big bulk of memory unless I find a way to
represent that with the new "structured" way, but that's a detail).

I will probably need some new ioctl's with the kernel to be able to dump
the kvm one in a state useful for a saved image, but here too nothing we
don't know how to do, but that's fine too, we'll have more vcpu state we
need to properly sort out for save/restore with kvm, we'll deal with it
eventually.

The problem I have is in fact with full emu on restore. After I've
re-allocated the hash table, loaded it from disk, etc... I need to
update some data in the vcpu env.

IE. The vcpu has a pointer to the "external hash" (and it's size) which
it uses to perform translation and that needs to be restored.

cpu_load/save isn't a good place to do that of course since that code
knows nothing about the spapr stuff, besides I don't think I have any
ordering guarantee between those vs. my spapr htab save/load.

What I'd need is something in spapr that can be used to "resync" bits of
the cpu state with the external htab that gets run after everything is
loaded and before emulation restarts.

Any idea how to do that properly ? I suppose I could also try to iterate
all the vcpu's after loading the hash table & update the fields but not
only that's gross ... I also don't know how to do it :-)

Cheers,
Ben.
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]