On Fri, 1 Jan 2016 09:17:48 +0530
Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
> On Wed, Dec 16, 2015 at 04:46:37PM +0100, Andreas Färber wrote:
> > Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> > > wrt CLI can't we do something like this?
> > >
> > > -device some-cpu-model,socket=x[,core=y[,thread=z]]
> >
> > That's problematic and where my x86 remodeling got stuck. It works fine
> > (more or less) to model sockets, cores and hyperthreads for -smp, but
> > doing it dynamically did not work well. How do you determine the
> > instance size a socket with N cores and M threads needs? Allocations in
> > instance_init are to be avoided with a view to hot-plug. So either we
> > have a fully determined socket object or we need to wire individual
> > objects on the command line. The latter has bad implications for
> > atomicity and thus hot-unplug. That leaves us with dynamic properties
> > doing allocations and reporting it via Error**, something I never
> > finished and could use reviewers and contributors.
> >
> > Anthony's old suggestion had been to use real socket product names like
> > Xeon-E5-4242 to get a 6-core, dual-thread socket, without parameters -
> > unfortunately I still don't see an easy way to define such a thing today
> > with the flexibility users will undoubtedly want.
> >
> > And since the question came up how to detect this, what you guys seem to
> > keep forgetting is that somewhere there also needs to be a matching
> > link<> property that determines what can be plugged, i.e. QMP qom-list.
> > link<>s are the QOM equivalent to qdev's buses. The object itself needs
> > to live in /machine/peripheral or /machine/peripheral-anon
> > (/machine/unattached is supposed to go away after the QOM conversion is
> > done!) and in a machine-specific place there will be a
> > /machine/cpu-socket[0] -> /machine/peripheral-anon/device[42]
> > link<x86_64-cpu-socket> property. It might just as well be
> > /machine/daughterboard-x/cpu-core[2] -> /machine/peripheral/cpu0.
> > (Gentle reminder of the s390 ipi modeling discussion that never came to
> > any conclusion iirc.)
> >
> > Note that I have not read this patch series yet, just some of the
> > alarming review comments.
>
> It has been more than an year since I posted the initial version of
> PowerPC sPAPR CPU hotplug patchset. I guess x86 CPU hotplug patchset
> existed even before that. Now we have patches for s390 CPU hotplug
> also on the list. Given this situation, will it be agreeable and
> feasible to follow Igor's suggestion and de-link the QOM part from the
> actual CPU hotplug work ? May be we can get these patchsets into 2.6 and
> work on QOM links subsequently ?
how about doing it in 2 series in parallel,
1st: a target specific cpu hotplug
2nd: QMP interface that would suite management needs to enumerate
existing/possible CPU objects at the granularity which targets
support from -device/device_add aspect
(i.e. focuses only on hotplug POV)
> Regards,
> Bharata.
>
>
