Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

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 ?

Regards,
Bharata.