qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bharata B Rao
Subject: Re: [Qemu-devel] [PATCH 6/8] spapr: init CPUState->cpu_index with index relative to core-id
Date: Fri, 22 Jul 2016 11:40:03 +0530
User-agent: Mutt/1.6.1 (2016-04-27)

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 <address@hidden>
> 
> 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,address@hidden PowerPC,address@hidden

which otherwise should have been

PowerPC,address@hidden PowerPC,address@hidden

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]