Re: [Qemu-devel] [PATCH 6/8] spapr: init CPUState->cpu_index with index relative to core-id

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

On Fri, Jul 22, 2016 at 01:23:01PM +1000, David Gibson wrote:
> On Thu, Jul 21, 2016 at 05:54:37PM +0200, Igor Mammedov wrote:
> > It will enshure that cpu_index for a given cpu stays the same
> > regardless of the order cpus has been created/deleted and so
> > it would be possible to migrate QEMU instance with out of order
> > created CPU.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> 
> So, this isn't quite right (it wasn't right in my version either).
> 
> The problem occurs when smp_threads < kvmppc_smt_threads().  That is,
> when the requested threads-per-core is less than the hardware's
> maximum number of threads-per-core.
> 
> The core-id values are assigned essentially as i *
> kvmppc_smt_threads(), meaning the patch below will leave gaps in the
> cpu_index values and the last ones will exceed max_cpus, causing other
> problems.

This would lead to hotplug failures as cpu_dt_id is still being
derived from non-contiguous cpu_index resulting in wrong enumeration
of CPU nodes in DT.

For -smp 8,threads=4 we see the following CPU nodes in DT

PowerPC,POWER8@0 PowerPC,POWER8@10

which otherwise should have been

PowerPC,POWER8@0 PowerPC,POWER8@8

The problem manifests as drmgr failure.

Greg's patchset that moved cpu_dt_id setting to machine code and that
derived cpu_dt_id from core-id for sPAPR would be needed to fix this I guess.

Regards,
Bharata.