All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 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.