From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh7qh-0000wb-Ca for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:28:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sh7qf-0000p4-Jf for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:28:38 -0400 Received: from gate.crashing.org ([63.228.1.57]:40002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh7qf-0000op-Ai for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:28:37 -0400 Message-ID: <1340148512.28143.52.camel@pasglop> From: Benjamin Herrenschmidt Date: Wed, 20 Jun 2012 09:28:32 +1000 In-Reply-To: <87y5nij3r6.fsf@elfo.mitica> References: <1339239192.24838.84.camel@pasglop> <1339241642.24838.92.camel@pasglop> <5DD2FF44-F27E-49C4-AF2C-2EF95341DF6E@suse.de> <87lijjjqk5.fsf@elfo.mitica> <1340137841.28143.34.camel@pasglop> <874nq6kj3m.fsf@elfo.mitica> <1340146833.28143.50.camel@pasglop> <87y5nij3r6.fsf@elfo.mitica> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] vm state save/restore question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Alexander Graf , "qemu-devel@nongnu.org Developers" On Wed, 2012-06-20 at 01:11 +0200, Juan Quintela wrote: > > > I am confident I can come up with something as far as the kernel and > > qemu <-> kernel interface goes. I need to get my head around the details > > on how to implement that two stage save process in qemu though and the > > corresponding restore which will need to read both snapshots and apply > > the diff before shooting it back to the kernel. > > > > BTW. Does migration in pure qemu (full system emu) works similarily, ie, > > two stage ? If it does I can easily prototype everything there. > > It does, but I have no clue how the hashed page tables are implemented > on ppc, i.e. if there is anything specific for bare metal. Alex? We support the paravirtualized -M pseries in full emu as well, in which case the hashed page table is handled by qemu itself who implements the H_ENTER & co hypercalls. So it's very similar, except that qemu doesn't have to ask the kernel to get a snapshot :-) So I can flush out the storage format and two stage process inside qemu, and then bother with the kvm/kernel interface. Normal "bare metal" operation in qemu (or even KVM "PR") doesn't require this as in that case the hash table is just a normal part of the guest memory, it's only an issue when doing paravirtualized guest such as pseries (aka PAPR). Cheers, Ben.