From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh7aq-0006Ej-Ae for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:12:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sh7ao-0004yd-Hn for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:12:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh7ao-0004y6-A4 for qemu-devel@nongnu.org; Tue, 19 Jun 2012 19:12:14 -0400 From: Juan Quintela In-Reply-To: <1340146833.28143.50.camel@pasglop> (Benjamin Herrenschmidt's message of "Wed, 20 Jun 2012 09:00:33 +1000") 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> Date: Wed, 20 Jun 2012 01:11:57 +0200 Message-ID: <87y5nij3r6.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] vm state save/restore question Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Alexander Graf , "qemu-devel@nongnu.org Developers" Benjamin Herrenschmidt wrote: > On Wed, 2012-06-20 at 00:55 +0200, Juan Quintela wrote: >> >> This was going to be my question. >> >> If we can do something like: send hash register, and get a bitmap of >> the >> ones that get changed, we should be good. Perhaps we need something >> "interesting" like removing old entries (no clue if they got just >> overwritten, or how they are replaced), and we should be good. > > Right, we can do an initial "snapshot" and have the kernel start > tracking changes from there. On the final step, we can then request from > the kernel a new snapshot with a dirty bitmap. > > Or we can be even simpler, just do two snapshots and have qemu diff them > itself :-) > > 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? Later, Juan.