[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH v2.1 10/12] spapr: CPU hotplug su
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH v2.1 10/12] spapr: CPU hotplug support |
Date: |
Fri, 6 May 2016 13:01:34 +0200 |
On Fri, 6 May 2016 15:44:10 +0530
Bharata B Rao <address@hidden> 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 <address@hidden> 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.
>
>