From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YY7Yc-0005Se-7B for qemu-devel@nongnu.org; Wed, 18 Mar 2015 02:34:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YY7YY-0003Kf-VH for qemu-devel@nongnu.org; Wed, 18 Mar 2015 02:34:22 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:36685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YY7YY-0003KI-Bh for qemu-devel@nongnu.org; Wed, 18 Mar 2015 02:34:18 -0400 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Mar 2015 12:04:13 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 105AE125805C for ; Wed, 18 Mar 2015 12:05:42 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2I6Y7bZ5308542 for ; Wed, 18 Mar 2015 12:04:07 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2I6UeY2024844 for ; Wed, 18 Mar 2015 12:00:41 +0530 Date: Wed, 18 Mar 2015 12:04:04 +0530 From: Bharata B Rao Message-ID: <20150318063403.GE21610@in.ibm.com> References: <1426247796-1657-1-git-send-email-bharata@linux.vnet.ibm.com> <20150318004959.GO5741@voom.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150318004959.GO5741@voom.redhat.com> Subject: Re: [Qemu-devel] [RFC v0 PATCH] cpus: Convert cpu_index into a bitmap Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: zhugh.fnst@cn.fujitsu.com, qemu-devel@nongnu.org, agraf@suse.de, Bharata B Rao , imammedo@redhat.com, afaerber@suse.de On Wed, Mar 18, 2015 at 11:49:59AM +1100, David Gibson wrote: > On Fri, Mar 13, 2015 at 05:26:36PM +0530, Bharata B Rao wrote: > > From: Bharata B Rao > > > > Currently CPUState.cpu_index is monotonically increasing and a newly > > created CPU always gets the next higher index. The next available > > index is calculated by counting the existing number of CPUs. This is > > fine as long as we only add CPUs, but there are architectures which > > are starting to support CPU removal too. For an architecture like PowerPC > > which derives its CPU identifier (device tree ID) from cpu_index, the > > existing logic of generating cpu_index values causes problems. > > > > With the currently proposed method of handling vCPU removal by parking > > the vCPU fd in QEMU > > (Ref: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02604.html), > > generating cpu_index this way will not work for PowerPC. > > > > This patch changes the way cpu_index is handed out by maintaining > > a bit map of the CPUs that tracks both addition and removal of CPUs. > > > > I am not sure if this is the right and an acceptable approach. The > > alternative is to do something similar for PowerPC alone and not > > depend on cpu_index. > > > > I have tested this with out-of-the-tree patches for CPU hot plug and > > removal on x86 and sPAPR PowerPC. > > How does this interact with the tweaking of cpu indexes that spapr > does in order to configure the guest SMT mode on POWER7 and POWER8 > systems? I am not changing the mapping of cpu_index to cpu_dt_id. So nothing should be change. Can you please point me to the piece of tweaking code that you are referring to above ? Regards, Bharata.