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: David Gibson
Subject: Re: [Qemu-devel] [PATCH 6/8] spapr: init CPUState->cpu_index with index relative to core-id
Date: Fri, 22 Jul 2016 17:14:33 +1000
User-agent: Mutt/1.6.2 (2016-07-01)

On Fri, Jul 22, 2016 at 11:40:03AM +0530, Bharata B Rao wrote:
> 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.

Which "This" are you referring to?

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

No, it shouldn't be necessary to fix it.  But we certainly do want to
clean this stuff up.  I'm not terribly convinced by the current
approach in Greg's series though.  I'd actually prefer to remove
cpu_dt_id from the cpustate entirely and instead work it out from the
(now stable) cpu index when we go to construct the device tree.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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