On Mon, Feb 01, 2016 at 10:41:58AM +0100, Igor Mammedov wrote:
[...]
> >
> > How exactly would you migrate a machine today, if you do the
> > following?
> >
> > $ qemu-system-x86_64 -smp 8,sockets=2,cores=2,threads=2,maxcpus=16
> > (QMP) cpu-add id=15
> isn't it the same broken topology?
> sockets*cores*threads != maxcpus
> But if you ask if it's possible to migrate machine with non-sequentially
> hotplugged CPUs than answer is no it's not possible with cpu-add.
I was asking about migration with non-sequential hotplugged CPUs
(e.g. with -smp 8,sockets=4,cores=2,threads=2,maxcpus=16).
[...]
> > > > >
> > > > > Perhaps this check should be enforced per target/machine if
> > > > > arch requires it.
> > > >
> > > > It is. Please see the patch. It introduces a validate_smp_config
> > > > method.
> > > >
> > > > But we need your input to clarify if
> > > > validate_smp_config_generic() is safe for pc-2.6 too.
> > > it breaks migration as it could prevent target from starting if
> > > there is hotplugged CPUs on source side.
> >
> > It looks like this is a problem only if the machine allows
> > hotplug of individual threads. What if we just add this to the
> > beginning of validate_smp_config_generic():
> >
> > if (mc->hot_add_cpu && max_cpus > smp_cpus) {
> It would break migration after hotplugging CPUs upto max_cpus
> and then trying to migrate.
>
> Also when we move x86 to device_add that will regress since
> hot_add_cpu() won't be used in that case.
>
> I think there is not much point enforcing restrictions
> in this patch as generic. We should leave hook empty and allow
> target to override it. Then SPAPR could enforce it's own limit
> on partial cores.
Agreed. It looks like we won't get rid of thread-based CPU
hotplug in x86 in the foreseable future.
--
Eduardo
