From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPhb-0006ue-09 for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:43:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKPhW-0002jb-6V for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:43:46 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPhV-0002jG-Tl for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:43:42 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u65CfaLI088583 for ; Tue, 5 Jul 2016 08:43:41 -0400 Received: from e28smtp08.in.ibm.com (e28smtp08.in.ibm.com [125.16.236.8]) by mx0a-001b2d01.pphosted.com with ESMTP id 23xa52q7et-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 05 Jul 2016 08:43:40 -0400 Received: from localhost by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 5 Jul 2016 18:13:37 +0530 Date: Tue, 5 Jul 2016 18:13:22 +0530 From: Bharata B Rao Reply-To: bharata@linux.vnet.ibm.com References: <1467693772-7391-1-git-send-email-bharata@linux.vnet.ibm.com> <1467693772-7391-3-git-send-email-bharata@linux.vnet.ibm.com> <20160705091551.544e1ae1@172-15-179-184.lightspeed.austtx.sbcglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160705091551.544e1ae1@172-15-179-184.lightspeed.austtx.sbcglobal.net> Message-Id: <20160705124322.GC25522@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v0 2/5] cpu: Optionally use arch_id instead of cpu_index in cpu vmstate_register() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, david@gibson.dropbear.id.au, groug@kaod.org, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com On Tue, Jul 05, 2016 at 09:15:51AM +0200, Igor Mammedov wrote: > On Tue, 5 Jul 2016 10:12:49 +0530 > Bharata B Rao wrote: > > > Introduce CPUState.prefer_arch_id_over_cpu_index and > > MachineClass.prefer_arch_id_over_cpu_index that allow target > > machines to optionally switch to using arch_id instead of cpu_index > > as instance_id in vmstate_register(). This will help allow successful > > migration in cases where holes are introduced in cpu_index range > > after CPU hot removals. > > > > Whether to use arch_id or cpu_index is based on machine type version > > and hence added MachineClass.prefer_arch_id_over_cpu_index. However > > the enforcement is via and during CPU creation and hence added > > CPUState.prefer_arch_id_over_cpu_index. So it becomes a two step > > process for the target to enable the use of arch_id: > > > > 1. Set MachineClass.prefer_arch_id_over_cpu_index. > > 2. Ensure CPUState.prefer_arch_id_over_cpu_index is set for all CPUs > > based on 1. above. > > > > Suggested-by: Igor Mammedov > > Signed-off-by: Bharata B Rao > > --- > > exec.c | 10 ++++++++-- > > include/hw/boards.h | 1 + > > include/qom/cpu.h | 4 ++++ > > 3 files changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/exec.c b/exec.c > > index 8ce8e90..7cc1d06 100644 > > --- a/exec.c > > +++ b/exec.c > > @@ -616,15 +616,21 @@ static void cpu_release_index(CPUState *cpu) > > bitmap_clear(cpu_index_map, cpu->cpu_index, 1); > > } > > > > +/* > > + * TODO: cpu_index and instance_id are of type int > > while .get_arch_id()is > > + * of type int64_t. What is the consequence of changing instance_id > > to int64_t ? > > + */ > ARM potentially could have get_arch_id() == MPIDR (return 64bit int) > that would get truncated in this case. > > I wonder if we could add "int CPUState::migration_id" and let machine > code set it to what it uses for stable cpu id and then cpu_realize > could call vmstate_register with it. Hmm how would that help ? instance_id argument to vmstate_register() is being treated as 32 bit integer as pointed by Greg earlier. If we want to use 64 bit arch_id/migration_id as instance_id arg in vmstate_register, shouldn't we be changing instance_id to 64 bit ? Regards, Bharata.