From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [RFC PATCH v1 01/10] xen/arm: make secondary gic
 init as notifier call
Date: Sat, 22 Mar 2014 13:54:04 +0000
Message-ID: <532D95FC.9080804@linaro.org>
References: <1395238631-2024-1-git-send-email-vijay.kilari@gmail.com>	<1395238631-2024-2-git-send-email-vijay.kilari@gmail.com>	<1395422138.25521.44.camel@kazak.uk.xensource.com>
	<CALicx6swjBERTFfYQ65s3XFj0+rwQUOiAWrMpO17p5pfQOF12g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CALicx6swjBERTFfYQ65s3XFj0+rwQUOiAWrMpO17p5pfQOF12g@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Vijay Kilari <vijay.kilari@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Cc: Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>, Vijaya Kumar K <vijaya.kumar@caviumnetworks.com>, xen-devel@lists.xen.org, Stefano Stabellini <stefano.stabellini@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hello Vijay,

On 22/03/14 08:32, Vijay Kilari wrote:
> On Fri, Mar 21, 2014 at 10:45 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2014-03-19 at 19:47 +0530, vijay.kilari@gmail.com wrote:
>>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>>
>>> make gic init for secondary cpus as notifier call
>>> instead calling directly from secondary boot for
>>> each cpu.
>>
>>> This makes secondary gic init generic and runtime.
>>
>> s/and/at/ perhaps? Otherwise I can't make sense of what you are trying
>> to say.
>>
>   OK, I will rephrase it.
>>
>>> +static struct notifier_block gic_cpu_nb = {
>>> +    .notifier_call = gic_init_secondary_cpu,
>>> +    .priority = 100
>>>
>> In wondering what 100 was, I notice that the other similar uses have a
>> "/* Highest priority */" comment, please add one here too.
>>
>> I notice that the percpu stuff (cpu_percpu_nfb) is also priority == 100,
>> which makes me suspect that they will run in arbitrary order, which
>> makes me uncomfortable, not least because at least gic_{cpu,hyp}_init
>> both touch per-cpu data structures.
>>
>> Ah, I see the percpu stuff is a CPU_UP_PREPARE notifier, so has already
>> happened. Good. It does make me wonder if it is wise to do something as
>> critical as interrupt controller setup in a notifier. Do you think this
>> is necessary for some reason?
>>
>     Yes, I kept it at highest priority thinking that it is critical.
>      from the comment in include/xen/cpu.h, CPU_STARTING suits because
>      gic_{cpu,hyp}_init should run on new cpu.
>
>        /* CPU_STARTING: CPU nearly online. Runs on new CPU, irqs still
> disabled. */
>
>      Is there any difference with Xen compared to kernel? that suggest me to use
>      CPU_UP_PREPARE?

CPU_UP_PREPARE notifiers are called from the boot CPU. Here we want to 
call GIC init on the newly booted CPU.

So CPU_STARTING is fine.

Regards,

-- 
Julien Grall