[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D368D488-6D4E-4590-8E98-A7D7CD5E7F20@zytor.com>
Date: Thu, 08 May 2025 13:23:04 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Peter Zijlstra <peterz@...radead.org>, Sohil Mehta <sohil.mehta@...el.com>
CC: x86@...nel.org, linux-kernel@...r.kernel.org, Xin Li <xin@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>, Tony Luck <tony.luck@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Brian Gerst <brgerst@...il.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Jacob Pan <jacob.pan@...ux.microsoft.com>,
Andi Kleen <ak@...ux.intel.com>, Kai Huang <kai.huang@...el.com>,
Nikolay Borisov <nik.borisov@...e.com>,
linux-perf-users@...r.kernel.org, linux-edac@...r.kernel.org,
kvm@...r.kernel.org, linux-pm@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/9] x86/nmi: Add support to handle NMIs with source information
On May 8, 2025 5:15:44 AM PDT, Peter Zijlstra <peterz@...radead.org> wrote:
>On Wed, May 07, 2025 at 02:48:34PM -0700, Sohil Mehta wrote:
>> On 5/7/2025 2:14 AM, Peter Zijlstra wrote:
>> > On Tue, May 06, 2025 at 06:21:41PM -0700, Sohil Mehta wrote:
>> >>
>> >> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
>> >> index a1d672dcb6f0..183e3e717326 100644
>> >> --- a/arch/x86/kernel/nmi.c
>> >> +++ b/arch/x86/kernel/nmi.c
>> >
>> >> static int nmi_handle(unsigned int type, struct pt_regs *regs)
>> >> {
>> >> struct nmi_desc *desc = nmi_to_desc(type);
>> >> + unsigned long source_bitmap = 0;
>> >
>> > unsigned long source = ~0UL;
>> >
>>
>> Thanks! This makes the logic even simpler by getting rid of
>> match_nmi_source(). A minor change described further down.
>>
>> Also, do you prefer "source" over "source_bitmap"? I had it as such to
>> avoid confusion between source_vector and source_bitmap.
>
>Yeah, I was lazy typing. Perhaps just call it bitmap then?
>
>> >> nmi_handler_t ehandler;
>> >> struct nmiaction *a;
>> >> int handled=0;
>> >> @@ -148,16 +164,40 @@ static int nmi_handle(unsigned int type, struct pt_regs *regs)
>> >>
>> >> rcu_read_lock();
>> >>
>> >> + /*
>> >> + * Activate NMI source-based filtering only for Local NMIs.
>> >> + *
>> >> + * Platform NMI types (such as SERR and IOCHK) have only one
>> >> + * handler registered per type, so there is no need to
>> >> + * disambiguate between multiple handlers.
>> >> + *
>> >> + * Also, if a platform source ends up setting bit 2 in the
>> >> + * source bitmap, the local NMI handlers would be skipped since
>> >> + * none of them use this reserved vector.
>> >> + *
>> >> + * For Unknown NMIs, avoid using the source bitmap to ensure all
>> >> + * potential handlers have a chance to claim responsibility.
>> >> + */
>> >> + if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL)
>> >> + source_bitmap = fred_event_data(regs);
>> >
>> > if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL) {
>> > source = fred_event_data(regs);
>> > if (source & BIT(0))
>> > source = ~0UL;
>> > }
>> >
>>
>> Looks good, except when fred_event_data() returns 0. I don't expect it
>> to happen in practice. But, maybe with new hardware and eventually
>> different hypervisors being involved, it is a possibility.
>>
>> We can either call it a bug that an NMI happened without source
>> information. Or be extra nice and do this:
>>
>> if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL) {
>> source = fred_event_data(regs);
>> if (!source || (source & BIT(0)))
>> source = ~0UL;
>> }
>
>Perhaps also WARN about the !source case?
A 0 should be interpreted such that NMI source is not available, e.g. due to a broken hypervisor or similar.
Powered by blists - more mailing lists