Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

On Wed, Mar 16, 2016 at 04:48:50PM +0100, Igor Mammedov wrote:
> On Wed, 16 Mar 2016 09:18:03 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> 
> > On Mon, Mar 14, 2016 at 10:47:28AM +0100, Igor Mammedov wrote:
> > > On Fri, 11 Mar 2016 10:24:29 +0530
> > > Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> > >   
> > > > Hi,
> > > > 
> > > > This is the next version of "Core based CPU hotplug for PowerPC sPAPR" that
> > > > was posted at
> > > > https://lists.gnu.org/archive/html/qemu-ppc/2016-03/msg00081.html
> > > > 
> > > > device_add semantics
> > > > --------------------
> > > > For -smp 16,sockets=1,cores=2,threads=8,maxcpus=32
> > > > (qemu) device_add spapr-cpu-core,id=core2,core=16,cpu_model=host[,threads=8]  
> > > do you plan to allow user to hotplug different cpu_models?
> > > If not it would be better to hide cpu_model from user
> > > and set it from machine pre_plug handler.  
> > 
> > In my earlier implementations I derived cpu model from -cpu and threads from
> > -smp,threads= commandline options and never exposed them to device_add
> > command.
> > 
> > Though we don't support heterogenous systems (different cpu models and/or
> > threads) now, it was felt that it should be easy enough to support such
> > systems if required in future, that's how cpu_model and threads became
> > options for device_add.
> > 
> > One of the things that David felt was missing from my earlier QMP query
> > command (and which is true in your QMP query implementation also) is that
> > we aren't exporting cpu_model at all, at least for not-yet-plugged cores.
> > So should we include that or let management figure that out since it
> > would already know about the CPU model.
> 1.
> so since you are not planning supporting heterogeneous setup yet,
> I'd suggest to refrain from making user to provide cpu_model at
> device_add time. Instead make machine code to set it for cores it
> creates before core.realize() (yet another use for pre_plug()).
> 
> That way mgmt doesn't have to figure out what cpu_model to set at
> device_add time and doesn't have find out what property to use for it.

Yes.. of course you could also do the same thing for nr_threads, so
I'm wondering whether there's a good argument to keep one in
pre_plug() and one in query-hotpluggable-cpus.

> 2.
> If you still insist on providing cpu_model property at
> device_add time, you'd better extend QMP command query-hotpluggable-cpus
> to provide it in 'props' list along with valid value.

Yes, that's definitely true.

> But I'd go with #1 as questions of using cpu_model-s vs QOM types and
> discovery of mapping of cpu-model to QOM types is not clear yet
> and need to be discussed further.

Hm, I suppose so.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]