From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEg2m-0001SS-2O for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:53:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEg2f-0007AS-K8 for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:53:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEg2f-00079m-CG for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:53:17 -0400 Date: Mon, 13 Jul 2015 16:53:10 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150713155310.GH2492@work-vm> References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-24-git-send-email-dgilbert@redhat.com> <87y4ikjo1n.fsf@neno.neno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y4ikjo1n.fsf@neno.neno> Subject: Re: [Qemu-devel] [PATCH v7 23/42] MIGRATION_STATUS_POSTCOPY_ACTIVE: Add new migration state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, liang.z.li@intel.com, qemu-devel@nongnu.org, luis@cs.umu.se, amit.shah@redhat.com, pbonzini@redhat.com, david@gibson.dropbear.id.au * Juan Quintela (quintela@redhat.com) wrote: > "Dr. David Alan Gilbert (git)" wrote: > > From: "Dr. David Alan Gilbert" > > > > 'MIGRATION_STATUS_POSTCOPY_ACTIVE' is entered after migrate_start_postcopy > > > > 'migration_postcopy_phase' is provided for other sections to know if > > they're in postcopy. > > > > Signed-off-by: Dr. David Alan Gilbert > > Reviewed-by: David Gibson > > Reviewed-by: Eric Blake > > Reviewed-by: Juan Quintela > > > But (there is always a but....) > > > > @@ -358,6 +359,39 @@ MigrationInfo *qmp_query_migrate(Error **errp) > > > > get_xbzrle_cache_stats(info); > > break; > > + case MIGRATION_STATUS_POSTCOPY_ACTIVE: > > + /* Mostly the same as active; TODO add some postcopy stats */ > > + info->has_status = true; > > + info->has_total_time = true; > > + info->total_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME) > > + - s->total_time; > > + info->has_expected_downtime = true; > > + info->expected_downtime = s->expected_downtime; > > + info->has_setup_time = true; > > + info->setup_time = s->setup_time; > > + > > + info->has_ram = true; > > + info->ram = g_malloc0(sizeof(*info->ram)); > > + info->ram->transferred = ram_bytes_transferred(); > > + info->ram->remaining = ram_bytes_remaining(); > > + info->ram->total = ram_bytes_total(); > > + info->ram->duplicate = dup_mig_pages_transferred(); > > + info->ram->skipped = skipped_mig_pages_transferred(); > > + info->ram->normal = norm_mig_pages_transferred(); > > + info->ram->normal_bytes = norm_mig_bytes_transferred(); > > + info->ram->dirty_pages_rate = s->dirty_pages_rate; > > + info->ram->mbps = s->mbps; > > + > > + if (blk_mig_active()) { > > + info->has_disk = true; > > + info->disk = g_malloc0(sizeof(*info->disk)); > > + info->disk->transferred = blk_mig_bytes_transferred(); > > + info->disk->remaining = blk_mig_bytes_remaining(); > > + info->disk->total = blk_mig_bytes_total(); > > + } > > Can we have block migration active with postcopy? I would assume that > this would get disk corruption, no? Or if you preffer the other > question, what protects us from disk corruption? I think you can, I've not tried it; however I also think it should be safe. migration/block.c's block_save_pending always puts a value in the non_postcopiable_pending return value (and 0 in the postcopiable_pending); the migrate thread checks the non_postcopiable_pending size to decide when it can switch to postcopy, and performs a call to the complete method on each device before it does. Thus the block migration should be finished before we start doing the actual postcopy stage, and thus before the destination CPU starts running. A possibly harder question is what happens if block.c did implement postcopy and you had both block postcopy and ram postcopy active at the same time; again I think it should work but I'm not sure if one would starve the other. > Once here, I guess we can get the migrate_already_active() bit without > problem? I'm not sure of the question here; but the idea of migration_already_active() is just to avoid all of the open-coded checks for each possible state; now we've added anothe state they were getting messy. Dave > > Later, Juan. -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK