Re: [Qemu-ppc] [PATCH RFC] spapr: disintricate core-id from DT semantics

[Greg Kurz]

Le Mon, 25 Jul 2016 16:01:31 +1000,
David Gibson <address@hidden> a écrit :

> On Fri, Jul 22, 2016 at 01:10:36PM +0200, Greg Kurz wrote:
> > The goal of this patch is to have a stable core-id which does not depend
> > on any DT related semantics, which involve non-obvious computations on
> > modern PowerPC server cpus.
> > 
> > With this patch, the DT core id is computed on-demand as:
> > 
> >        (core-id / smp_threads) * smt
> > 
> > where smt is the number of threads per core in the host.
> > 
> > This formula should be consolidated in a helper since it is needed in
> > several places.  
> 
> It's a little odd you node this but don't do so.
> 

I was too busy packing for holidays already :) and I think the consolidation
work can be addressed in followup patches.

Cheers from Brittany, under the rain.

--
Greg

> > Other uses for core-id includes: compute a stable cpu_index (which
> > allows random order hotplug/unplug without breaking migration) and
> > NUMA.
> > 
> > Signed-off-by: Greg Kurz <address@hidden>
> > ---
> > 
> > It was first suggested here:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01727.html
> > 
> > and as option 1) in the following discussion on IRC:
> > 
> > <dwg> imammedo, basically the options are: 1) change core-ids to be
> >  0, 1, .. n and compute cpu_index as core_id * threads + thread#, or
> >  2) leave core-ids as they are and calculate cpu_index as
> >  core-id / smt * threads + thread#
> > 
> > It is based on David's ppc-for-2.7 branch (commit bb6268f35f457).
> > 
> > It is lightly tested but I could at least do in-order
> > hotplug/unplug.  
> 
> I think this is basically the right approach, and I've applied to
> ppc-for-2.7.  Here's my plan for what to do about all this id stuff:
> 
>   1. Merge this to ppc-for-2.7 (done)
>   2. Assuming there are now show-stoppers in testing, send a pull
>      request tomorrow
>   3. Once this is merged, try to get Igor's series (or a respin of it)
>      in ASAP.
> 
> I'm hoping that will give us good-enough hotplug for 2.7.
> 
> In the 2.8 timeframe, I want to:
>   4. Disconnect KVM vcpu ID from dt_id, instead calculate it from (now
>      stable) cpu_index
>   5. Remove dt_id as a cpu field - instead just compute DT ids from
>      the (now stable) cpu_index when we build the DT
>   6. (for new machine type versions) Change DT ID assignment, so it
>       no longer depends on kvmppc_smt_threads().  The current scheme
>       means that migration between hosts with different native SMT
>       values won't work, which is unfortunate.  I suspect there may be
>       other problems with any real situation where that's the case,
>       but nontheless it's a silly restriction.
> 
> Nice to have but bigger scope things for 2.8:
>   7. Update archs to they *all* call cpu_exec_init() / cpu_exec_exit()
>      at realize / unrealize time instead of init / finalize time.
>   8. Update all archs and machines to use stable cpu_index
>

pgp0my6HlxMbp.pgp
Description: Signature digitale OpenPGP