From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYSI5-00006B-SJ for qemu-devel@nongnu.org; Thu, 19 Mar 2015 00:42:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYSI2-0000Gg-Kt for qemu-devel@nongnu.org; Thu, 19 Mar 2015 00:42:41 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:36898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYSI2-0000GL-9M for qemu-devel@nongnu.org; Thu, 19 Mar 2015 00:42:38 -0400 Date: Thu, 19 Mar 2015 15:43:23 +1100 From: David Gibson Message-ID: <20150319044323.GW5741@voom.redhat.com> References: <1426247796-1657-1-git-send-email-bharata@linux.vnet.ibm.com> <20150318004959.GO5741@voom.redhat.com> <20150318063403.GE21610@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="28wbjzzu+2Xmo01Z" Content-Disposition: inline In-Reply-To: <20150318063403.GE21610@in.ibm.com> Subject: Re: [Qemu-devel] [RFC v0 PATCH] cpus: Convert cpu_index into a bitmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: zhugh.fnst@cn.fujitsu.com, qemu-devel@nongnu.org, agraf@suse.de, Bharata B Rao , imammedo@redhat.com, afaerber@suse.de --28wbjzzu+2Xmo01Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 18, 2015 at 12:04:04PM +0530, Bharata B Rao wrote: > 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 > > >=20 > > > 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 Pow= erPC > > > which derives its CPU identifier (device tree ID) from cpu_index, the > > > existing logic of generating cpu_index values causes problems. > > >=20 > > > 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.h= tml), > > > generating cpu_index this way will not work for PowerPC. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > I have tested this with out-of-the-tree patches for CPU hot plug and > > > removal on x86 and sPAPR PowerPC. > >=20 > > 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? >=20 > 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 ? Ah, I thought it actually adjusted the cpu_index values, rather than mapping them to different cpu_dt_id values. Maybe it used to, or maybe I just misremembered. Never mind, should be fine. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --28wbjzzu+2Xmo01Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVClPrAAoJEGw4ysog2bOSuFMP/RlVvZReq5OVSzGml0pt54UE G4DROoZ6Q6xRaqStUjhaE0bAfyvkEK71ErxT/AOFb5u2WTaOp3lFotR3PXMngXJL 58lLw4i802mDhan+G6/H3t3SQJRGMl+wjzdFz91i1aMmdSDi4Oyi3Thwb3QDhWZp h97gABX91ndZtjrTnMdzGTlKPW3oBJvutKZqhoGr1PHdFBduDykz5pAkUVqY824o nEbmTBypTClqqpUfkqgb1Qr+wtWrTgdBg2+xnFrrm6ZIbl5j8MnaTd2L15GCirdx kEs7CeMLl9U5diWOM59c+msnzdw10KCcZ2zPnPD+kCyPX2tDMwq2ihvqfjITEKh/ ZYWMIYzIGfTbSkIJgl6NxjmHuNvTqZFZ4R+w3rgWUQkVb+L0cKp/IwMx6vJqLrEb i+MMiq3w79edUlbdXdrvjCKlG5PuaGbOg4aPrl66sl0AdrzVQMhwgXI9PhXa4JR8 s2Sjz1IwIarXUVPOE8XXIbCmNabHH25oXrtJ5A3oueEnKxB+CR7/XX88zN03XPS8 vMWcw+B8WUDTOQ7qmkrORjijATYYupmht2BrOPCVuyfps/IZ6txBXa4UE9k/GiVd R5inyQbVuC+/jmZO603Aqw1ujYT9pTiCpP1YcrUAeoTPkZmKXZqeT9fZIavvD+vD WtFil9Jda7opCvfUY1U4 =kNCH -----END PGP SIGNATURE----- --28wbjzzu+2Xmo01Z--