From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YICrq-0007Ay-Ui for qemu-devel@nongnu.org; Mon, 02 Feb 2015 04:00:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YICrl-0004wE-SZ for qemu-devel@nongnu.org; Mon, 02 Feb 2015 04:00:26 -0500 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:36985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YICrl-0004va-A0 for qemu-devel@nongnu.org; Mon, 02 Feb 2015 04:00:21 -0500 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Feb 2015 14:30:16 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 1AFCD1258044 for ; Mon, 2 Feb 2015 14:31:15 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t1290C1K20054176 for ; Mon, 2 Feb 2015 14:30:12 +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 t12909c6012812 for ; Mon, 2 Feb 2015 14:30:11 +0530 Date: Mon, 2 Feb 2015 14:30:08 +0530 From: Bharata B Rao Message-ID: <20150202090008.GA3066@in.ibm.com> References: <1420697420-16053-1-git-send-email-bharata@linux.vnet.ibm.com> <54CA71F6.8060405@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54CA71F6.8060405@suse.de> Subject: Re: [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: imammedo@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On Thu, Jan 29, 2015 at 06:46:30PM +0100, Andreas Färber wrote: > Hi, > > Am 08.01.2015 um 07:10 schrieb Bharata B Rao: > > This patchset enables CPU and memory hotplug support for PowerPC guests. > > > > Changes in this patchset (v1): > > > > - Based on top of Michael Roth's tree > > (https://github.com/mdroth/qemu/commits/spapr-hotplug-core) which serves > > as base for his PCI hotplug patches too. > > - Switched to device_add/del semantics instead of cpu-add. > > Please don't forget to CC me on this. As previously discussed with Jason > and Christian for s390x, there's certain topology modeling questions > still unsolved for device-based QOM CPU hot-plug. I have an RFC in the > works (again) that hopefully gets us a step closer. I think you are referring to this discussion: http://lists.gnu.org/archive/html/qemu-devel/2013-09/msg00778.html Looking forward to your above mentioned RFC. > > > - Supporting CPU hot unplug now. > > - Added patches to enable memory hotplug. > > - Added ibm,dynamic-reconfiguration-memory support which is needed for > > memory hotplug. > > > > v0 - http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00752.html > > > > CPU hotplug > > ----------- > > - Works with BE guest, has issues with LE guest. Has been tested on BE host > > only. > > - Adding a core (and all its threads) in response to device_add command. > > Similarly removing a core via device_del will remove all the threads. > > Earlier discussions concluded that hot-plug needs to happen on a socket > level, not core. If you're assuming the socket to have one core (as we > were planning for s390x), that doesn't make much of a difference > number-wise, but it does in modeling terms. Think what you can > physically plug onto the mainboard, that's the granularity that > realized=true/false is going to operate on. A virtual socket may well > correspond to a thread on some socket/node of the host, but you cannot > add threads to a core or cores to a chip at runtime. In PowerPC, guests conform to PAPR specifications and hence the hotplug behaviour with the real hardware will not matter. For pseries guests we add CPUs in core granularity. By default if we don't specify sockets= explicitly, the guest comes with as many sockets as there are cores with 1 core per socket. However we can have a guest that has multiple cores in a socket too. Hence if you have a CPU hotplug model where a socket is added at a time, I can't see any issues of supporting that with PowerPC hotplug. Based on the existing topology, we could hotplug as many cores in the socket as needed. However I would like to hear from others who understand PowerPC architecture to see if there are any caveats with this model. Regards, Bharata.