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 <imamm...@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.
