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

Re: [Xen-devel] [PATCH 4/7] xen/arm: gic: Use the correct CPU ID



On Tue, 2013-09-10 at 17:45 +0100, Julien Grall wrote:
> On 09/10/2013 04:52 PM, Ian Campbell wrote:
> > On Tue, 2013-09-10 at 16:42 +0100, Julien Grall wrote:
> >> On 09/09/2013 02:28 PM, Ian Campbell wrote:
> >>> On Fri, 2013-08-30 at 14:30 +0100, Julien Grall wrote:
> >>>> The GIC mapping of CPU interfaces does not necessarily match the logical
> >>>> CPU numbering.
> >>>>
> >>>> When Xen wants to send an SGI to specific CPU, it needs to use the GIC 
> >>>> CPU ID.
> >>>> It can be retrieved from ITARGETSR0, in fact when this field is read, 
> >>>> the GIC
> >>>> will return a value that corresponds only to the processor reading the 
> >>>> register.
> >>>> So Xen can use the PPI 0 to initialize the mapping.
> >>>>
> >>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>> ---
> >>>>  xen/arch/arm/gic.c |   35 ++++++++++++++++++++++++++++-------
> >>>>  1 file changed, 28 insertions(+), 7 deletions(-)
> >>>>
> >>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >>>> index cadc258..4f3a8a5 100644
> >>>> --- a/xen/arch/arm/gic.c
> >>>> +++ b/xen/arch/arm/gic.c
> >>>> @@ -57,6 +57,27 @@ 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
> >>>> + */
> >>>> +#define NR_GIC_CPU_IF 8
> >>>> +static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly = {0xff};
> >>>
> >>> Isn't this mapping from logical cpus ids to gic cpus ids? IOW the size
> >>> of this array is the wrong way around?
> >>
> >> This array maps a logical cpu id (the index) to a gic cpus id. The size
> >> if correct, because Xen will allocate logical cpu id from 0 to 7.
> > 
> > Oh right, yes.
> > 
> > I think NR_CPUS (which should be 8 given the other limitations) is the
> > right size for this array.
> > 
> >>
> >>> Is what you want here is a per-cpu variable?
> >>
> >> Does per-cpu variable allow any cpu to retrieve data of another cpu? I
> >> didn't find a such function.
> > 
> > per_cpu(variable, cpu) will do it.
> 
> Is it fast ?

It looks up the cpus offset in an array and then adds it to the address
of variable before loading the result.

>  I think this solution is slower, because the mapping is
> used often used, mainly when an SGI is sent to another cpu.

I doubt it is measurable. 

Ian

> 
> >>
> >>>> +
> >>>> +static unsigned int gic_cpu_mask(const cpumask_t *cpumask)
> >>>> +{
> >>>> +    unsigned int cpu;
> >>>> +    unsigned int mask = 0;
> >>>> +
> >>>> +    for_each_cpu(cpu, cpumask)
> >>>> +    {
> >>>> +        ASSERT(cpu < NR_GIC_CPU_IF);
> >>>> +        mask |= gic_cpu_map[cpu];
> >>>
> >>> Further to above, can't cpu here be e.g. 0x100 for an a7 on a big.ITTLE
> >>> system?
> >>
> >> 0x100 is the hardware CPU id. Xen will allocate a logical cpu id from 0.
> > 
> > Right.
> > 
> > 
> 
> 



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


 


Rackspace

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