qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR
Date: Wed, 16 Mar 2016 16:48:50 +0100

On Wed, 16 Mar 2016 09:18:03 +0530
Bharata B Rao <address@hidden> 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 <address@hidden> 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.

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.

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.


> 
> Regards,
> Bharata.
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]