From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn8X7-0003w5-VX for qemu-devel@nongnu.org; Fri, 16 Oct 2015 13:11:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn8X4-0002Y9-Ov for qemu-devel@nongnu.org; Fri, 16 Oct 2015 13:11:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn8X4-0002Y2-JO for qemu-devel@nongnu.org; Fri, 16 Oct 2015 13:11:06 -0400 Date: Fri, 16 Oct 2015 18:11:00 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20151016171100.GJ2622@work-vm> References: <008b01d101be$0228d720$067a8560$@samsung.com> <20151009152942.GF2702@work-vm> <00b801d1059e$d6d4ffb0$847eff10$@samsung.com> <20151013110527.GB2555@work-vm> <00b201d107e3$ac36acd0$04a40670$@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201d107e3$ac36acd0$04a40670$@samsung.com> Subject: Re: [Qemu-devel] Live migration sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin Cc: peter.maydell@linaro.org, quintela@redhat.com, marc.zyngier@arm.com, 'QEMU' , amit.shah@redhat.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org * Pavel Fedin (p.fedin@samsung.com) wrote: > Hello! > > > Some thoughts: > > a) There is a migration state notifier list - see add_migration_state_change_notifier (spice > > calls it) > > - but I don't think it's called in the right places for your needs; we > > could add some more places that gets called. > > I am now trying to add one more state, something like MIGRATION_STATUS_FINISHING. It would mean that CPUs are stopped. > Can you explain me migration code a bit? Where is iteration loop, and where are CPUs stopped? I am looking at migration.c but > cannot say that i understand some good portion of it. :) The outgoing side of migration comes into migrate_fd_connect which does all the setup and then starts 'migration_thread'. The big while loop in there does most of the work, and on each loop normally ends up calling either qemu_savevm_state_iterate or migration_completion migration_completion calls vm_stop_force_state to stop the CPU, and then qemu_savevm_state_complete to save all the remaining devices out. Dave > > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK