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