From: Alexey G <x1917x@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Igor Druzhinin <igor.druzhinin@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs
Date: Fri, 9 Feb 2018 00:37:22 +1000 [thread overview]
Message-ID: <20180209003722.000026da@gmail.com> (raw)
In-Reply-To: <a411177c-a3ce-ff0a-f609-ef53d60a7a88@citrix.com>
On Thu, 8 Feb 2018 12:40:41 +0000
Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>- Perf/Oprofile. This is currently mutually exclusive with Xen using
>the watchdog, but needn't be and hopefully won't be in the future.
>
>>
>> Most of the time we deal with watchdog NMIs, while all others should
>> be somewhat rare. The thing is, we actually need to read I/O port
>> 61h on system NMIs only.
>>
>> If the main problem lies in a flow of SMIs due to reading port 61h on
>> every NMI watchdog tick -- why not to avoid reading it?
>>
>> There are at least 2 ways to check if the NMI was due to a watchdog
>> tick:
>> - LAPIC (SDM states that "When a performance monitoring counters
>> interrupt is generated, the mask bit for its associated LVT entry is
>> set")
>> - perf MSR overflow bit
>>
>> So, if we detect it was a NMI due to a watchdog using these
>> methods (early in the NMI handler), we can avoid touching the port
>> 61h and thus triggering SMI I/O trap on it.
>
>The problem is having multiple NMIs arriving. Like all other edge
>triggered interrupts, extra arrivals get dropped. By skipping the 0x61
>read if we believe it was a watchdog NMI, we've opened a race condition
>where we will completely miss the system NMI.
There shouldn't be any problem I think. NMIs don't need to be cleared
with EOI and it's a common practice to handle NMIs one-by-one (as a NMI
handler is not reentrant in a typical scenario).
Execution of SMI doesn't cause a pending (blocked) NMI to get dropped,
similar mechanisms might be employed for a single NMI which arrived in
blocked-by-NMI state. Otherwise the whole thing will break -- merely
handling arbitrary NMI will be enough to miss any other NMIs. This is a
too obvious flaw. So normally it should be just a matter which NMI of
two will be serviced first.
This assumption can be verified empirically by requesting the chipset
to send an external NMI while serving a watchdog NMI and checking if it
arrive later on.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-08 14:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 21:18 [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs Igor Druzhinin
2018-02-06 3:10 ` Alexey G
2018-02-06 14:21 ` Andrew Cooper
2018-02-06 17:08 ` Alexey G
2018-02-06 17:21 ` Igor Druzhinin
2018-02-06 18:17 ` Alexey G
2018-02-06 19:50 ` Igor Druzhinin
2018-02-07 6:35 ` Alexey G
2018-02-06 14:10 ` Andrew Cooper
2018-02-06 16:07 ` Jan Beulich
2018-02-06 16:14 ` Igor Druzhinin
2018-02-06 16:23 ` Jan Beulich
2018-02-06 16:27 ` Igor Druzhinin
2018-02-06 16:29 ` Igor Druzhinin
2018-02-06 21:51 ` Igor Druzhinin
2018-02-07 9:13 ` Jan Beulich
2018-02-07 13:01 ` Igor Druzhinin
2018-02-07 13:08 ` Jan Beulich
2018-02-07 13:24 ` Andrew Cooper
2018-02-07 15:06 ` Jan Beulich
2018-02-07 17:08 ` Andrew Cooper
2018-02-08 9:12 ` Jan Beulich
2018-02-08 12:18 ` Andrew Cooper
2018-02-13 9:03 ` Jan Beulich
2018-02-07 13:54 ` Igor Druzhinin
2018-02-08 6:37 ` Alexey G
2018-02-08 10:47 ` Igor Druzhinin
2018-02-08 12:32 ` Alexey G
2018-02-08 12:40 ` Andrew Cooper
2018-02-08 14:37 ` Alexey G [this message]
2018-02-08 15:00 ` Andrew Cooper
2018-02-08 15:28 ` Alexey G
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=20180209003722.000026da@gmail.com \
--to=x1917x@gmail.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=igor.druzhinin@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 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).