From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 3/6] xen/arm: gic: Use the correct CPU ID Date: Fri, 20 Sep 2013 19:48:33 +0100 Message-ID: <523C9881.4010008@linaro.org> References: <1379510122-9467-1-git-send-email-julien.grall@linaro.org> <1379510122-9467-4-git-send-email-julien.grall@linaro.org> <523C63C9.1040708@linaro.org> <1379691897.8994.25.camel@hastur.hellion.org.uk> <523C7097.7000509@linaro.org> <1379693210.8994.29.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1379693210.8994.29.camel@hastur.hellion.org.uk> 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/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