From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aydWL-0004kX-Dr for qemu-devel@nongnu.org; Fri, 06 May 2016 07:02:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aydW7-0001X3-Km for qemu-devel@nongnu.org; Fri, 06 May 2016 07:02:02 -0400 Date: Fri, 6 May 2016 13:01:34 +0200 From: Igor Mammedov Message-ID: <20160506130134.1416d79f@nial.brq.redhat.com> In-Reply-To: <20160506101410.GC16087@in.ibm.com> References: <1459413561-30745-1-git-send-email-bharata@linux.vnet.ibm.com> <1459413561-30745-11-git-send-email-bharata@linux.vnet.ibm.com> <20160506105721.7093b724@nial.brq.redhat.com> <20160506101410.GC16087@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2.1 10/12] spapr: CPU hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, afaerber@suse.de, pbonzini@redhat.com, mdroth@linux.vnet.ibm.com, david@gibson.dropbear.id.au On Fri, 6 May 2016 15:44:10 +0530 Bharata B Rao wrote: > On Fri, May 06, 2016 at 10:57:21AM +0200, Igor Mammedov wrote: > > On Thu, 31 Mar 2016 14:09:19 +0530 > > Bharata B Rao wrote: > > > > > Set up device tree entries for the hotplugged CPU core and use the > > > exising RTAS event logging infrastructure to send CPU hotplug notification > > > to the guest. > > > > perhaps you could reuse: > > > > [RFC,20/42] machine: add cpu-hotplug machine option > > http://patchwork.ozlabs.org/patch/617516/ > > > > to enable cpu hotplug explicitly, > > and by default machine would be hotplug less saving resources. > > We explicitly enable hotplug for specific machine type versions by > setting sPAPRMachineClass.dr_cpu_enabled. So we check it to ensure > that there are no DR connector objects (the resources needed for hotplug) > created for a machine that doesn't support CPU hotplug. Similar is > the case for memory hotplug. > > So you are suggesting that we switch from sAPPR specific check > (sPAPRMachineClass.dr_cpu_enabled) to the above MachineState.cpu_hotplug ? yep, i.e. make user explicitly say that he want cpu hotplug enabled. instead of allocating resources for it when user doesn't care about it. It saves some memory/io ports for x86, not sure what it would save for sPAPR, but at least one doesn't have to guess if hotplug is needed by looking at smp_cpus & max_cpus. > > Regards, > Bharata. > >