From: Jack Steiner <steiner@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: tglx@linutronix.de, hpa@zytor.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Cyrill Gorcunov <gorcunov@gmail.com>
Subject: Re: [PATCH] x86, UV: Fix NMI handler for UV platforms
Date: Mon, 21 Mar 2011 11:56:08 -0500 [thread overview]
Message-ID: <20110321165608.GA12718@sgi.com> (raw)
In-Reply-To: <20110321161425.GC23614@elte.hu>
On Mon, Mar 21, 2011 at 05:14:25PM +0100, Ingo Molnar wrote:
>
> * Jack Steiner <steiner@sgi.com> wrote:
>
> > This fixes a problem seen on UV systems handling NMIs from the node controller.
> > The original code used the DIE notifier as the hook to get to the UV NMI
> > handler. This does not work if performance counters are active - the hw_perf
> > code consumes the NMI and the UV handler is not called.
>
> Sigh:
Agree. X86 architecture does not make it easy to use NMIs from multiple sources.
>
> > --- linux.orig/arch/x86/kernel/traps.c 2011-03-21 09:05:43.000000000 -0500
> > +++ linux/arch/x86/kernel/traps.c 2011-03-21 09:13:01.306555675 -0500
> > @@ -57,6 +57,7 @@
> > #include <asm/mce.h>
> >
> > #include <asm/mach_traps.h>
> > +#include <asm/uv/uv.h>
> >
> > #ifdef CONFIG_X86_64
> > #include <asm/x86_init.h>
> > @@ -397,13 +398,16 @@ unknown_nmi_error(unsigned char reason,
> > static notrace __kprobes void default_do_nmi(struct pt_regs *regs)
> > {
> > unsigned char reason = 0;
> > + int handled;
> >
> > /*
> > * CPU-specific NMI must be processed before non-CPU-specific
> > * NMI, otherwise we may lose it, because the CPU-specific
> > * NMI can not be detected/processed on other CPUs.
> > */
> > - if (notify_die(DIE_NMI, "nmi", regs, 0, 2, SIGINT) == NOTIFY_STOP)
> > + handled = uv_handle_nmi(regs, reason);
> > + if (notify_die(DIE_NMI, "nmi", regs, 0, 2, SIGINT) == NOTIFY_STOP ||
> > + handled)
> > return;
>
> Such code is extremely ugly. Please *reduce* the number of is_uv_system() type
> of hacks in core x86 code, not increase it!
>
> Any reason why a higher priority for the UV NMI handler cannot solve the 'perf
> eats the NMI' problem?
Yes. I tried that.
If the UV handler needs to know if hwperf is active in order to know whether or not
to return NOTIFY_STOP:
- if the UV NMI handler returns NOTIFY_STOP and hw_perf is active, hw_perf will miss
and NMI & counter sometimes stop working.
- if the UV NMI handler does not return NOTIFY_STOP and hw_perf is not active,
we get the "dazed" messages.
A cleaner solution would be to hide the platform specific NMI action in a x86_platform_ops
such as (untested):
Index: linux/arch/x86/include/asm/x86_init.h
===================================================================
--- linux.orig/arch/x86/include/asm/x86_init.h 2011-03-18 11:29:08.000000000 -0500
+++ linux/arch/x86/include/asm/x86_init.h 2011-03-21 11:52:36.413496546 -0500
@@ -153,6 +153,7 @@ struct x86_platform_ops {
void (*iommu_shutdown)(void);
bool (*is_untracked_pat_range)(u64 start, u64 end);
void (*nmi_init)(void);
+ int (*nmi_handler)(void *regs);
int (*i8042_detect)(void);
};
Index: linux/arch/x86/kernel/apic/x2apic_uv_x.c
===================================================================
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c 2011-03-21 11:40:36.000000000 -0500
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c 2011-03-21 11:45:14.134555108 -0500
@@ -115,6 +115,7 @@ static int __init uv_acpi_madt_oem_check
early_get_apic_pnode_shift();
x86_platform.is_untracked_pat_range = uv_is_untracked_pat_range;
x86_platform.nmi_init = uv_nmi_init;
+ x86_platform.nmi_handler = uv_nmi_handler;
if (!strcmp(oem_table_id, "UVL"))
uv_system_type = UV_LEGACY_APIC;
else if (!strcmp(oem_table_id, "UVX"))
Index: linux/arch/x86/kernel/traps.c
===================================================================
--- linux.orig/arch/x86/kernel/traps.c 2011-03-21 11:40:36.000000000 -0500
+++ linux/arch/x86/kernel/traps.c 2011-03-21 11:52:21.057498053 -0500
@@ -55,6 +55,8 @@
#include <asm/desc.h>
#include <asm/i387.h>
#include <asm/mce.h>
+#include <asm/x86_init.h>
+
#include <asm/mach_traps.h>
@@ -397,13 +399,16 @@ unknown_nmi_error(unsigned char reason,
static notrace __kprobes void default_do_nmi(struct pt_regs *regs)
{
unsigned char reason = 0;
+ int handled;
/*
* CPU-specific NMI must be processed before non-CPU-specific
* NMI, otherwise we may lose it, because the CPU-specific
* NMI can not be detected/processed on other CPUs.
*/
- if (notify_die(DIE_NMI, "nmi", regs, 0, 2, SIGINT) == NOTIFY_STOP)
+ handled = x86_platform.nmi_handler(regs);
+ if (notify_die(DIE_NMI, "nmi", regs, 0, 2, SIGINT) == NOTIFY_STOP ||
+ handled)
return;
/* Non-CPU-specific NMI: NMI sources can be processed on any CPU */
Index: linux/arch/x86/kernel/x86_init.c
===================================================================
--- linux.orig/arch/x86/kernel/x86_init.c 2011-03-18 11:29:08.000000000 -0500
+++ linux/arch/x86/kernel/x86_init.c 2011-03-21 11:53:26.849496085 -0500
@@ -89,6 +89,7 @@ struct x86_cpuinit_ops x86_cpuinit __cpu
};
static void default_nmi_init(void) { };
+static int default_nmi_handler(void *regs) { return 1; };
static int default_i8042_detect(void) { return 1; };
struct x86_platform_ops x86_platform = {
@@ -98,6 +99,7 @@ struct x86_platform_ops x86_platform = {
.iommu_shutdown = iommu_shutdown_noop,
.is_untracked_pat_range = is_ISA_range,
.nmi_init = default_nmi_init,
+ .nmi_handler = default_nmi_handler,
.i8042_detect = default_i8042_detect
};
next prev parent reply other threads:[~2011-03-21 16:57 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 16:01 [PATCH] x86, UV: Fix NMI handler for UV platforms Jack Steiner
2011-03-21 16:14 ` Ingo Molnar
2011-03-21 16:26 ` Cyrill Gorcunov
2011-03-21 16:43 ` Cyrill Gorcunov
2011-03-21 17:00 ` Cyrill Gorcunov
2011-03-21 17:08 ` Jack Steiner
2011-03-21 17:19 ` Cyrill Gorcunov
2011-03-21 17:34 ` Jack Steiner
2011-03-21 17:48 ` Cyrill Gorcunov
2011-03-21 17:55 ` Cyrill Gorcunov
2011-03-21 18:15 ` Cyrill Gorcunov
2011-03-21 18:24 ` Jack Steiner
2011-03-21 17:53 ` Don Zickus
2011-03-21 17:51 ` Don Zickus
2011-03-21 18:00 ` Cyrill Gorcunov
2011-03-21 18:22 ` Jack Steiner
2011-03-21 19:37 ` Don Zickus
2011-03-21 20:37 ` Jack Steiner
2011-03-22 17:11 ` Jack Steiner
2011-03-22 18:44 ` Don Zickus
2011-03-22 20:02 ` Jack Steiner
2011-03-22 21:25 ` Jack Steiner
2011-03-22 22:02 ` Cyrill Gorcunov
2011-03-23 13:36 ` Jack Steiner
2011-03-22 22:05 ` Don Zickus
2011-03-23 16:32 ` Jack Steiner
2011-03-23 17:53 ` Don Zickus
2011-03-23 20:00 ` Don Zickus
2011-03-23 20:41 ` Cyrill Gorcunov
2011-03-23 20:45 ` Cyrill Gorcunov
2011-03-23 21:22 ` Don Zickus
2011-03-23 20:46 ` Jack Steiner
2011-03-23 21:23 ` Don Zickus
2011-03-24 17:09 ` Jack Steiner
2011-03-24 18:43 ` Don Zickus
2011-03-21 16:56 ` Jack Steiner [this message]
2011-03-21 18:05 ` Ingo Molnar
2011-03-21 19:23 ` [PATCH V2] " Jack Steiner
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=20110321165608.GA12718@sgi.com \
--to=steiner@sgi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.