From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdJIF-0005oZ-VL for qemu-devel@nongnu.org; Sat, 09 Jun 2012 06:53:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdJIE-0003pX-2w for qemu-devel@nongnu.org; Sat, 09 Jun 2012 06:53:19 -0400 Received: from gate.crashing.org ([63.228.1.57]:49967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdJID-0003pQ-MT for qemu-devel@nongnu.org; Sat, 09 Jun 2012 06:53:17 -0400 Message-ID: <1339239192.24838.84.camel@pasglop> From: Benjamin Herrenschmidt Date: Sat, 09 Jun 2012 20:53:12 +1000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: [Qemu-devel] vm state save/restore question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alexander Graf 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.