From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAFF0-00059o-8X for qemu-devel@nongnu.org; Wed, 01 Jul 2015 06:27:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAFEx-0002QP-26 for qemu-devel@nongnu.org; Wed, 01 Jul 2015 06:27:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAFEw-0002QJ-MM for qemu-devel@nongnu.org; Wed, 01 Jul 2015 06:27:38 -0400 From: Juan Quintela In-Reply-To: <1435313380-12857-3-git-send-email-lizhijian@cn.fujitsu.com> (Li Zhijian's message of "Fri, 26 Jun 2015 18:09:40 +0800") References: <1435313380-12857-1-git-send-email-lizhijian@cn.fujitsu.com> <1435313380-12857-3-git-send-email-lizhijian@cn.fujitsu.com> Date: Wed, 01 Jul 2015 12:27:36 +0200 Message-ID: <87616418br.fsf@neno.neno> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v2 2/2] migration: extend migration_bitmap Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Li Zhijian Cc: amit.shah@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org Li Zhijian wrote: > Prevously, if we hotplug a device(e.g. device_add e1000) during > migration is processing in source side, qemu will add a new ram > block but migration_bitmap is not extended. > In this case, migration_bitmap will overflow and lead qemu abort > unexpectedly. > > Signed-off-by: Li Zhijian > Signed-off-by: Wen Congyang > --- > exec.c | 5 +++++ > include/exec/exec-all.h | 1 + > migration/ram.c | 15 +++++++++++++++ > 3 files changed, 21 insertions(+) > > diff --git a/exec.c b/exec.c > index f7883d2..1702544 100644 > --- a/exec.c > +++ b/exec.c > @@ -1401,6 +1401,11 @@ static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp) > } > } > > + new_ram_size = MAX(old_ram_size, > + (new_block->offset + new_block->max_length) >> TARGET_PAGE_BITS); > + if (new_ram_size > old_ram_size) { > + migration_bitmap_extend(old_ram_size, new_ram_size); > + } > /* Keep the list sorted from biggest to smallest block. Unlike QTAILQ, > * QLIST (which has an RCU-friendly variant) does not have insertion at > * tail, so save the last element in last_block. > diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h > index 2573e8c..dd9be44 100644 > --- a/include/exec/exec-all.h > +++ b/include/exec/exec-all.h > @@ -385,4 +385,5 @@ static inline bool cpu_can_do_io(CPUState *cpu) > return cpu->can_do_io != 0; > } > > +void migration_bitmap_extend(ram_addr_t old, ram_addr_t new); Had to protect this one with #if !defined(CONFIG_USER_ONLY) void migration_bitmap_extend(ram_addr_t old, ram_addr_t new); #endif > #endif > diff --git a/migration/ram.c b/migration/ram.c > index 4754aa9..3e16ef8 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1063,6 +1063,21 @@ static void reset_ram_globals(void) > > #define MAX_WAIT 50 /* ms, half buffered_file limit */ > > +void migration_bitmap_extend(ram_addr_t old, ram_addr_t new) > +{ > + qemu_mutex_lock(&migration_bitmap_mutex); > + if (migration_bitmap) { > + unsigned long *old_bitmap = migration_bitmap, *bitmap; > + bitmap = bitmap_new(new); > + bitmap_copy(bitmap, old_bitmap, old); > + bitmap_set(bitmap, old, new - old); > + atomic_rcu_set(&migration_bitmap, bitmap); > + migration_dirty_pages += new - old; > + synchronize_rcu(); > + g_free(old_bitmap); > + } > + qemu_mutex_unlock(&migration_bitmap_mutex); > +} > > /* Each of ram_save_setup, ram_save_iterate and ram_save_complete has > * long-running RCU critical section. When rcu-reclaims in the code