From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH 2/4] x86/nmi: enable local irqs in
	wait_for_nmis()
Date: Wed, 14 May 2014 15:38:20 +0100
Message-ID: <53737FDC.8000806@citrix.com>
References: <1400072299-2285-1-git-send-email-david.vrabel@citrix.com>
	<1400072299-2285-3-git-send-email-david.vrabel@citrix.com>
	<537392700200007800012373@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1WkaK8-0005xq-5r
	for xen-devel@lists.xenproject.org; Wed, 14 May 2014 14:38:24 +0000
In-Reply-To: <537392700200007800012373@mail.emea.novell.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: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 14/05/14 14:57, Jan Beulich wrote:
>>>> On 14.05.14 at 14:58, <david.vrabel@citrix.com> wrote:
>> --- a/xen/arch/x86/nmi.c
>> +++ b/xen/arch/x86/nmi.c
>> @@ -111,7 +111,14 @@ int nmi_active;
>>  
>>  static void __init wait_for_nmis(void *p)
>>  {
>> +    unsigned long flags;
>> +
>> +    local_save_flags(flags);
>> +    local_irq_enable();
>> +
>>      mdelay((10*1000)/nmi_hz); /* wait 10 ticks */
>> +
>> +    local_irq_restore(flags);
>>  }
> 
> This being the callback for on_selected_cpus(), i.e. called out of
> interrupt context, I don't think it is uniformly safe to enable
> interrupts here. The current behavior anyway is for the function
> to run with interrupts enabled on the boot CPU, and with interrupts
> disabled on the APs. So for this change to make a difference, the
> IRQ would need to be bound to one of the APs, and consequently
> the fix would be to force it onto the BP until boot progressed far
> enough.

The call function IPIs are handled with a direct apic vector so skip the
normal interrupt enabling path for irqs.  I can't see anywhere where
irqs are enabled in call_function_interrupt() (x86) and
smp_call_function_interrupt() (common).

David