Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755508AbaA1SAQ (ORCPT ); Tue, 28 Jan 2014 13:00:16 -0500 Received: from mail-ea0-f180.google.com ([209.85.215.180]:36501 "EHLO mail-ea0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754970AbaA1SAO (ORCPT ); Tue, 28 Jan 2014 13:00:14 -0500 Message-ID: <52E7F02A.7010508@linaro.org> Date: Tue, 28 Jan 2014 18:00:10 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10 MIME-Version: 1.0 To: Stefano Stabellini CC: Ian Campbell , "linux-kernel@vger.kernel.org" , David Vrabel , "patches@linaro.org" , xen-devel@lists.xenproject.org, Boris Ostrovsky , linux-arm-kernel@lists.infradead.org Subject: Re: [Xen-devel] [PATCH] arm/xen: Initialize event channels earlier References: <1390920842-21886-1-git-send-email-julien.grall@linaro.org> <52E7EA78.5020305@linaro.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/28/2014 05:46 PM, Stefano Stabellini wrote: > On Tue, 28 Jan 2014, Julien Grall wrote: >>>> +static int xen_cpu_notification(struct notifier_block *self, >>>> + unsigned long action, >>>> + void *hcpu) >>>> +{ >>>> + int cpu = (long)hcpu; >>>> + >>>> + switch (action) { >>>> + case CPU_UP_PREPARE: >>>> + xen_percpu_init(cpu); >>>> + break; >>>> + case CPU_STARTING: >>>> + xen_interrupt_init(); >>>> + break; >>> >>> Is CPU_STARTING guaranteed to be called on the new cpu only? >> >> Yes. >> >>> If so, why not call both xen_percpu_init and xen_interrupt_init on >>> CPU_STARTING? >> >> Just in case that xen_vcpu is used somewhere else by a cpu notifier >> callback CPU_STARTING. We don't know which callback is called first. > > Could you please elaborate a bit more on the problem you are trying to > describe? We want to make sure that the vcpu is registered correctly. If not, we can't skip it and avoid xen to have a "dead" VCPU to schedule due to BUG_ON. I agree that now we have a BUG_ON in the middle of xen_percpu_init, but it's possible to return an error. In this case Linux will skip this cpu and continue to boot. >>> As it stands I think you introduced a subtle change (that might be OK >>> but I think is unintentional): xen_percpu_init might not be called from >>> the same cpu as its target anymore. >> >> No, xen_percpu_init and xen_interrupt_init are called on the boot cpu at >> the end of xen_guest_init. > > Is CPU_UP_PREPARE guaranteed to be called on the target cpu? I think > not, therefore you would be executing xen_percpu_init for cpu1 on cpu0. > I don't see any issue to execute xen_percpu_init for cpu1 on cpu0, all the code is taking directly the vcpu ID to initialize. -- Julien Grall -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/