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

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

On Fri, 2013-09-20 at 13:44 +0100, Julien Grall wrote:
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index b969d23..4061691 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -57,6 +57,29 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
> >  
> >  static unsigned nr_lrs;
> >  
> > +/* The GIC mapping of CPU interfaces does not necessarily match the
> > + * logical CPU numbering. Let's use mapping as returned by the GIC
> > + * itself
> > + */
> > +static DEFINE_PER_CPU(u8, gic_cpu_id);
> > +
> Following the discussion on another thread
> (http://lists.xen.org/archives/html/xen-devel/2013-09/msg02072.html), we
> need to initialize each CPU ID to 0xff by default, to be able to bring
> up secondary CPUs with an SGI (send_SGI_mask).

We may as well use the send_SGI_allbutself mechanism, which doesn't rely
on knowing and target ids.

> But as I understand, per_cpu area for a give area is initialized in
> cpu_up and there is no way to give a default value. So user could call
> send_SGI_mask to early function and use an invalid CPU area.

If we need to go down this path then I would write something like
        cpu_online(cpu) ? this_cpu(thing, cpu) :  0xff
but I don't think we need to because we can easily avoid the problem.

> IMHO, this solution is too fragile and I would like to use the same
> solution as my first version (ie with an array of 8 cells).

I think cpu bring up should use allbutself and the other callers can
reasonable be restricted to only operate on cpus which are up and
therefore have a valid mask already allocated and initialised.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.