[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.
>
>
- Re: [Qemu-devel] [RFC PATCH v2 6/9] spapr: CPU core device, (continued)
- [Qemu-devel] [RFC PATCH v2 7/9] spapr: CPU hotplug support, Bharata B Rao, 2016/03/10
- [Qemu-devel] [RFC PATCH v2 8/9] xics, xics_kvm: Handle CPU unplug correctly, Bharata B Rao, 2016/03/10
- [Qemu-devel] [RFC PATCH v2 9/9] spapr: CPU hot unplug support, Bharata B Rao, 2016/03/10
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, Igor Mammedov, 2016/03/14
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, Bharata B Rao, 2016/03/15
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR,
Igor Mammedov <=
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, David Gibson, 2016/03/17
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, Bharata B Rao, 2016/03/17
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, David Gibson, 2016/03/20
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, Igor Mammedov, 2016/03/21
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, David Gibson, 2016/03/21
- Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR, Igor Mammedov, 2016/03/22