From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2/4] x86/nmi: enable local irqs in wait_for_nmis()
Date: Wed, 14 May 2014 15:38:20 +0100 [thread overview]
Message-ID: <53737FDC.8000806@citrix.com> (raw)
In-Reply-To: <537392700200007800012373@mail.emea.novell.com>
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
next prev parent reply other threads:[~2014-05-14 14:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 12:58 [PATCH 0/4] x86/nmi: improve NMI watchdog test David Vrabel
2014-05-14 12:58 ` [PATCH 1/4] x86/nmi: remove spurious local_irq_enable from check_nmi_watchdog() David Vrabel
2014-05-14 13:25 ` Jan Beulich
2014-05-14 13:31 ` David Vrabel
2014-05-14 13:53 ` Jan Beulich
2014-05-15 11:40 ` Tim Deegan
2014-05-14 12:58 ` [PATCH 2/4] x86/nmi: enable local irqs in wait_for_nmis() David Vrabel
2014-05-14 13:57 ` Jan Beulich
2014-05-14 14:38 ` David Vrabel [this message]
2014-05-14 14:45 ` Jan Beulich
2014-05-15 11:55 ` Tim Deegan
2014-05-14 12:58 ` [PATCH 3/4] x86/nmi: wait for all CPUs in check_nmi_watchdog() David Vrabel
2014-05-14 13:59 ` Jan Beulich
2014-05-14 14:09 ` David Vrabel
2014-05-14 14:33 ` Jan Beulich
2014-05-14 14:09 ` Andrew Cooper
2014-05-15 11:47 ` Tim Deegan
2014-05-14 12:58 ` [PATCH 4/4] x86/nmi: be less verbose when testing the NMI watchdog David Vrabel
2014-05-15 11:48 ` Tim Deegan
2014-05-14 13:03 ` [PATCH 0/4] x86/nmi: improve NMI watchdog test Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53737FDC.8000806@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).