Re: [PATCH] perf/x86/amd: Move NMI latency window to last-resort suppression

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 16, 2026 at 02:57:23PM +0800, Guanghui Feng wrote:
> The upstream amd_pmu_adjust_nmi_window() mitigation claims every NMI
> that arrives within a 100ms window opened after a PMC overflow. When no
> counter overflowed, the handler still returns NMI_HANDLED, which makes
> the NMI dispatch path take its "handled" exit. Everything that comes
> after the perf handler is then skipped: the NMI reason port, which may
> hold a latched SERR#/IOCHK# error, and all NMI_UNKNOWN handlers, such
> as hpwdt. As a result unrelated NMIs are silently dropped for the whole
> duration of the window.
> 
> Stop claiming NMIs from within the perf handler. When no counter
> overflowed there is nothing to claim, so always report NMI_DONE and let
> the remaining NMI sources be probed first. Defer the window check to the
> very end of the dispatch path, where it is used only as a last resort.
> 
> Introduce perf_nmi_window_active(), which reports whether the latency
> window opened by the last PMC overflow on this CPU is still open. It is
> called from unknown_nmi_error() only after all NMI_LOCAL handlers, the
> reason port and all NMI_UNKNOWN handlers failed to identify the NMI.
> Only then is the bogus "unknown NMI" report suppressed. A __weak
> fallback in arch/x86/kernel/nmi.c always returns false, so non-AMD
> platforms are unaffected.
> 
> nmi_stats.unknown is still incremented before the suppression, so the
> dropped NMIs remain observable through debugfs.

So the point was that AMD hardware was generating these 'spurious' PMIs
quite frequently, and hitting the reason port at any frequency from
multiple CPUs is a massive performance problem.

How are you not re-introducing that?