From: Huang Ying <ying.huang@intel.com>
To: Don Zickus <dzickus@redhat.com>
Cc: Robert Richter <robert.richter@amd.com>,
"mingo@elte.hu" <mingo@elte.hu>,
"andi@firstfloor.org" <andi@firstfloor.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>
Subject: Re: [PATCH 4/5] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU
Date: Thu, 21 Oct 2010 10:53:57 +0800 [thread overview]
Message-ID: <1287629637.19320.63.camel@yhuang-dev> (raw)
In-Reply-To: <20101021023752.GB12086@redhat.com>
On Thu, 2010-10-21 at 10:37 +0800, Don Zickus wrote:
> On Thu, Oct 21, 2010 at 09:25:09AM +0800, Huang Ying wrote:
> > On Thu, 2010-10-21 at 09:18 +0800, Don Zickus wrote:
> > > On Thu, Oct 21, 2010 at 08:40:07AM +0800, Huang Ying wrote:
> > > > On Wed, 2010-10-20 at 22:27 +0800, Don Zickus wrote:
> > > > > I thought the point of this patch was to remove that restriction in the
> > > > > nmi handler, which would allow future patches to re-route these NMIs to
> > > > > another cpu, thus finally allowing people to hot-remove the bsp cpu, no?
> > > >
> > > > Yes. We just want to make it possible to hot-remove the bsp cpu. Because
> > > > IOAPIC is configurable, I think it is possible to configure IOAPIC to
> > > > send PCI SERR NMI to one CPU while IOCK NMI to another CPU. Why not
> > > > support this situation too? It does not harm anything but performance to
> > >
> > > Why would we want to? It seems simpler to have one cpu dedicated to
> > > handling the external NMIs.
> >
> > If we can guarantee that these NMIs will be only sent to one CPU, I am
> > fine with trylock.
>
> I guess I assumed the BIOS would only use the bsp CPU for the NMI, which
> would be passed on to the kernel. Otherwise what happens if an NMI
> happens while the kernel is still bringing up the first cpu and it is
> routed to another CPU or if we boot with MAX_CPUS=1?
After CPU hot-remove (should go through BIOS), BIOS may route the NMI to
other CPU I think. That should have no above issues. The question here
is that, BIOS will route different NMIs to one CPU or several CPUs?
Best Regards,
Huang Ying
next prev parent reply other threads:[~2010-10-21 2:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-16 2:22 [PATCH 0/5] x86, NMI: give NMI handler a face-lift Don Zickus
2010-10-16 2:22 ` [PATCH 1/5] x86, NMI: Add NMI symbol constants and rename memory parity to PCI SERR Don Zickus
2010-10-16 16:36 ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16 2:22 ` [PATCH 2/5] x86, NMI: Add touch_nmi_watchdog to io_check_error delay Don Zickus
2010-10-16 16:36 ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16 2:22 ` [PATCH 3/5] x86, NMI: Rewrite NMI handler Don Zickus
2010-10-16 16:36 ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16 17:29 ` Peter Zijlstra
2010-10-16 18:20 ` Ingo Molnar
2010-10-16 18:40 ` Anca Emanuel
2010-10-17 0:46 ` Don Zickus
2010-10-17 10:42 ` Peter Zijlstra
2010-10-18 3:06 ` Huang Ying
2010-10-18 8:24 ` Peter Zijlstra
2010-10-16 2:22 ` [PATCH 4/5] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU Don Zickus
2010-10-16 16:37 ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-19 15:07 ` [PATCH 4/5] " Robert Richter
2010-10-19 16:25 ` Robert Richter
2010-10-19 18:37 ` Don Zickus
2010-10-20 0:23 ` Huang Ying
2010-10-20 10:03 ` Robert Richter
2010-10-21 0:46 ` Huang Ying
2010-10-20 14:27 ` Don Zickus
2010-10-21 0:40 ` Huang Ying
2010-10-21 1:18 ` Don Zickus
2010-10-21 1:25 ` Huang Ying
2010-10-21 2:37 ` Don Zickus
2010-10-21 2:53 ` Huang Ying [this message]
2010-10-16 2:22 ` [PATCH 5/5] x86, NMI: Remove do_nmi_callback logic Don Zickus
2010-10-16 16:37 ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-19 15:03 ` [PATCH 5/5] " Robert Richter
2010-10-19 16:01 ` Don Zickus
2010-10-19 16:23 ` Robert Richter
2010-10-19 15:01 ` [PATCH 0/5] x86, NMI: give NMI handler a face-lift Robert Richter
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=1287629637.19320.63.camel@yhuang-dev \
--to=ying.huang@intel.com \
--cc=andi@firstfloor.org \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
/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