From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypr5e-0004ZI-Vs for qemu-devel@nongnu.org; Wed, 06 May 2015 00:37:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypr5Z-0006lO-OV for qemu-devel@nongnu.org; Wed, 06 May 2015 00:37:46 -0400 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:58960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypr5Z-0006l3-3v for qemu-devel@nongnu.org; Wed, 06 May 2015 00:37:41 -0400 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 May 2015 14:37:38 +1000 Date: Wed, 6 May 2015 10:06:40 +0530 From: Bharata B Rao Message-ID: <20150506043640.GJ18380@in.ibm.com> References: <1429858066-12088-1-git-send-email-bharata@linux.vnet.ibm.com> <1429858066-12088-8-git-send-email-bharata@linux.vnet.ibm.com> <20150505014730.GF14090@voom.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150505014730.GF14090@voom.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v3 07/24] cpu: Prepare Socket container type Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: mdroth@linux.vnet.ibm.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, imammedo@redhat.com, afaerber@suse.de On Tue, May 05, 2015 at 11:47:30AM +1000, David Gibson wrote: > On Fri, Apr 24, 2015 at 12:17:29PM +0530, Bharata B Rao wrote: > > From: Andreas Färber > > > > Signed-off-by: Andreas Färber > > Signed-off-by: Bharata B Rao > > So, how to organize this generically is still under discussion. For > now, I don't think this generic outline is really worth it. In any > case I can't really take it through my tree. > > What I'd suggest instead is just implementing the POWER core device in > the ppc specific code. As the generic socket vs. core vs. whatever > stuff clarifies, that POWER core device might become a "virtual > socket" or CM or whatever, but I think we'll be able to keep the > external interface compatible with the right use of aliases. > > In the meantime it should at least give us a draft we can experiment > with on Power without requiring new generic infrastructure. Makes sense, I will switch to the semantics that I had in v1 where I enabled CPU hotplug for POWER8 using device_add. (qemu) device_add POWER8-powerpc64-cpu,id=XXX Regards, Bharata.