From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 4/7] xen/arm: gic: Use the correct CPU ID Date: Tue, 10 Sep 2013 17:45:03 +0100 Message-ID: <522F4C8F.3080806@linaro.org> References: <1377869433-15385-1-git-send-email-julien.grall@linaro.org> <1377869433-15385-5-git-send-email-julien.grall@linaro.org> <1378733314.19967.130.camel@kazak.uk.xensource.com> <522F3DE3.7050504@linaro.org> <1378828360.10928.35.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1378828360.10928.35.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, patches@linaro.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 >>>> --- >>>> 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 ? I think this solution is slower, because the mapping is used often used, mainly when an SGI is sent to another cpu. >> >>>> + >>>> +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. > > -- Julien Grall