Re: [Xen-devel] [PATCH v3 3/6] xen/arm: gic: Use the correct CPU ID

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 09/20/2013 05:06 PM, Ian Campbell wrote:
> On Fri, 2013-09-20 at 16:58 +0100, Julien Grall wrote:
> > On 09/20/2013 04:44 PM, Ian Campbell wrote:
> > > On Fri, 2013-09-20 at 16:03 +0100, Julien Grall wrote:
> > >
> > > > +static unsigned int gic_cpu_mask(const cpumask_t *cpumask)
> > > > +{
> > > > +    unsigned int cpu;
> > > > +    unsigned int mask = 0;
> > > > +    cpumask_t possible_mask;
> > > > +
> > > > +    cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
> > > Based on the other subconversation doesn't this need to be online_mask?
> > > Or is the cpu area setup for cpus which are possible but not online?
> > cpu area is initialized a little bit before the cpu is bring up:
> >    * initialize per cpu data (via the notifier_call_chain CPU_UP_PREPARE)
> >    * signal the cpu to boot (__cpu_up)
> >    ...
> >    * call start_secondary
> >        * initialize the gic cpu interface (gic_cpu_init)
> >        * route ppis (which used gic_cpu_mask)
> >        * set the cpu online
> >
> > If we use the cpu online mask, Xen won't be able to route the different
> > ppis to the processor.
> >
> > > Should the check (whichever it is) be an assertion?
> > If we stay with the cpu_possible_map, I think we are fine without an
> > assertion.
> OK.
>
> OOI where in the above is the cpu_possible_map setup? Quite a bit before
> the CPU_UP_PREPARE hook I think? It shouldn't be a problem, just
> interested...
With this patch series, it's initialized by init_cpus_maps.

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel