From: Don Slutz <dslutz@verizon.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
Don Slutz <dslutz@verizon.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86/nmi: Make external NMI injection reliably crash the host
Date: Tue, 26 Aug 2014 17:51:18 -0400 [thread overview]
Message-ID: <53FD0156.1010708@terremark.com> (raw)
In-Reply-To: <53FCBB10.6050108@citrix.com>
On 08/26/14 12:51, Andrew Cooper wrote:
> On 26/08/14 17:06, Don Slutz wrote:
>> On 08/26/14 06:10, Ross Lagerwall wrote:
>>> Change the watchdog handler to only "tick" if the corresponding perf
>>> counter has overflowed; otherwise, return false from the NMI handler to
>>> indicate that the NMI is not a watchdog tick and let the other handlers
>>> handle it. This allows externally injected NMIs to reliably crash the
>>> host rather than be swallowed by the watchdog handler.
>> If a crash kernel has been setup via kexec, does this change to
>> "crash host" ends up jumping into the crash kernel?
>>
>> -Don Slutz
> No - this has no change of behaviour as to how Xen proceeds after it has
> decided to panic().
>
> It does however change whether Xen decided to panic, depending on
> whether the NMI was a result of the watchdog, or some otherwise
> unidentified NMI.
>
> Basically, without this change, the "inject fatal NMI" option in most
> IPMI controllers doesn't work in combination with running the Xen
> watchdog. Only certain HP systems appear to set the IOCK bit in the
> system control port B when injecting an NMI. All other systems just
> send an NMI with no change to the control ports, which get eaten by the
> watchdog logic.
>
> This patch changes the watchdog logic to only consider an NMI as a
> watchdog tick if the perf counter confirms that it injected the NMI.
Well, that is useful information. Looks like I was not clear. I am reading
> as to how Xen proceeds after it has
> decided to panic().
As a yes, but you start with a no. And I am getting "crash host" to
mean "calls panic()".
-Don Slutz
> ~Andrew
next prev parent reply other threads:[~2014-08-26 21:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 10:10 [PATCH] x86/nmi: Make external NMI injection reliably crash the host Ross Lagerwall
2014-08-26 10:17 ` Andrew Cooper
2014-08-26 12:59 ` Jan Beulich
2014-08-26 15:26 ` Ross Lagerwall
2014-08-26 15:38 ` Jan Beulich
2014-08-27 11:14 ` Ross Lagerwall
2014-08-27 12:04 ` Jan Beulich
2014-08-26 16:06 ` Don Slutz
2014-08-26 16:51 ` Andrew Cooper
2014-08-26 21:51 ` Don Slutz [this message]
2014-08-26 23:01 ` 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=53FD0156.1010708@terremark.com \
--to=dslutz@verizon.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=ross.lagerwall@citrix.com \
--cc=xen-devel@lists.xen.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.