mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: Xin Li <xin@zytor.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Sean Christopherson" <seanjc@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>,
	"Zhang Rui" <rui.zhang@intel.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Jacob Pan <jacob.pan@linux.microsoft.com>,
	Andi Kleen <ak@linux.intel.com>, Kai Huang <kai.huang@intel.com>,
	"Sandipan Das" <sandipan.das@amd.com>,
	<linux-perf-users@vger.kernel.org>, <linux-edac@vger.kernel.org>,
	<kvm@vger.kernel.org>, <linux-pm@vger.kernel.org>,
	<linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 4/9] x86/nmi: Assign and register NMI-source vectors
Date: Tue, 3 Jun 2025 13:22:26 -0700	[thread overview]
Message-ID: <67683e00-48fa-4aa8-91ff-8726a5374675@intel.com> (raw)
In-Reply-To: <e978e1fb-d88e-4789-bd33-367281dfa0ad@intel.com>

On 6/3/2025 10:23 AM, Dave Hansen wrote:
> On 5/13/25 13:37, Sohil Mehta wrote:
> ...
>> + * Vector 2 is reserved for external NMIs related to the Local APIC -
>> + * LINT1. Some third-party chipsets may send NMI messages with a
>> + * hardcoded vector of 2, which would result in bit 2 being set in the
>> + * NMI-source bitmap.
> 
> This doesn't actually say what problem this causes. Is this better?
> 
> 	Third-party chipsets send NMI messages with a fixed vector of 2.
> 	Using vector 2 for some other purpose would cause confusion
> 	between those Local APIC messages and the other purpose. Avoid
> 	using it.
> 

Yes, that is better. Though, the behavior of these external NMIs isn't
expected to consistent across all third-parties.

Third-party chipsets may send NMI messages with a fixed vector of 2.
Using vector 2 for some other purpose would cause confusion between
those external NMI messages and the other purpose. Avoid using it.


>> + * The vectors are in no particular priority order. Add new vector
>> + * assignments sequentially in the list below.
>> + */
>> +#define NMIS_VECTOR_NONE	0	/* Reserved - Set for all unidentified sources */
>> +#define NMIS_VECTOR_TEST	1	/* NMI selftest */
>> +#define NMIS_VECTOR_EXTERNAL	2	/* Reserved - Match External NMI vector 2 */
>> +#define NMIS_VECTOR_SMP_STOP	3	/* Panic stop CPU */
>> +#define NMIS_VECTOR_BT		4	/* CPU backtrace */
>> +#define NMIS_VECTOR_KGDB	5	/* Kernel debugger */
>> +#define NMIS_VECTOR_MCE		6	/* MCE injection */
>> +#define NMIS_VECTOR_PMI		7	/* PerfMon counters */
>> +
>> +#define NMIS_VECTORS_MAX	16	/* Maximum number of NMI-source vectors */
> 
> Would an enum fit here?
> 

I had experimented using an enum, but I avoided that approach because
the source bitmap would also be visible to users/developers. For
example, patch 9 includes it in the "unknown NMI" print. I am planning
to add it to trace_nmi_handler() as well.

With an enum, it's harder to figure out the exact sources when let's say
the source bitmap is printed as 0x0090.

enum nmi_source_vector {
    NMIS_VECTOR_NONE,
    NMIS_VECTOR_TEST,
    NMIS_VECTOR_EXTERNAL,
    NMIS_VECTOR_SMP_STOP,
    NMIS_VECTOR_BT,
    NMIS_VECTOR_KGDB,
    NMIS_VECTOR_MCE,
    NMIS_VECTOR_PMI,
    ...,
    NMIS_VECTOR_COUNT
};

Users would have to convert the enum back to numbers to make sense of
the bitmap. It isn't bad but feels inconvenient.

> You could also add a:
> 
> 	NMIS_VECTOR_COUNT
> 
> as the last entry and then just:
> 
> 	BUILD_BUG_ON(NMIS_VECTOR_COUNT >= 16);
> 
> somewhere.
> 
> I guess it's a little annoying that you need NMIS_VECTOR_EXTERNAL to
> have a fixed value of 2, but I do like way the enum makes the type explicit.
> 

Yeah, fixing the external vector makes the enum annoying to use.

We could probably define an enum in this unusual way to keep the table
consistent and help users quickly refer bit offsets. But I am not sure
if this is any better than the current macros.

enum nmi_source_vector {
    NMIS_VECTOR_NONE        = 0,
    NMIS_VECTOR_TEST        = 1,
    NMIS_VECTOR_EXTERNAL    = 2,
    NMIS_VECTOR_SMP_STOP    = 3,
    NMIS_VECTOR_BT          = 4,
    NMIS_VECTOR_KGDB        = 5,
    NMIS_VECTOR_MCE         = 6,
    NMIS_VECTOR_PMI         = 7
};

Any suggestions?

> 
>>  static int __init register_nmi_cpu_backtrace_handler(void)
>>  {
>> -	register_nmi_handler(NMI_LOCAL, nmi_cpu_backtrace_handler, 0, "arch_bt", 0);
>> +	register_nmi_handler(NMI_LOCAL, nmi_cpu_backtrace_handler, 0, "arch_bt", NMIS_VECTOR_BT);
>>  	return 0;
>>  }
> 
> ... Oh you replaced _most_ of the random 0's in this patch. That helps
> for sure.

There are still quite a few places left with an extra 0 at the end.
Explicitly using NMIS_VECTOR_NONE for them should be useful.


> ret = register_nmi_handler(NMI_LOCAL, perf_ibs_nmi_handler, 0, "perf_ibs", 0);
> register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST, "hv_nmi_unknown", 0);
> retval = register_nmi_handler(NMI_UNKNOWN, kgdb_nmi_handler, 0, "kgdb", 0);
> if (register_nmi_handler(NMI_UNKNOWN, uv_handle_nmi, 0, "uv", 0))
> if (register_nmi_handler(NMI_LOCAL, uv_handle_nmi_ping, 0, "uvping", 0))
> register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes", 0);
> rv = register_nmi_handler(NMI_UNKNOWN, ipmi_nmi, 0, "ipmi", 0);
> rc = register_nmi_handler(NMI_SERR, ecclog_nmi_handler, 0, IGEN6_NMI_NAME, 0);
> retval = register_nmi_handler(NMI_UNKNOWN, hpwdt_pretimeout, 0, "hpwdt", 0);
> retval = register_nmi_handler(NMI_SERR, hpwdt_pretimeout, 0, "hpwdt", 0);
> retval = register_nmi_handler(NMI_IO_CHECK, hpwdt_pretimeout, 0, "hpwdt", 0);






  reply	other threads:[~2025-06-03 20:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13 20:37 [PATCH v6 0/9] x86: Add support for NMI-source reporting with FRED Sohil Mehta
2025-05-13 20:37 ` [PATCH v6 1/9] x86/fred, KVM: VMX: Pass event data to the FRED entry point from KVM Sohil Mehta
2025-05-14 14:15   ` Sean Christopherson
2025-05-14 21:34     ` Sohil Mehta
2025-05-16  1:15       ` Sean Christopherson
2025-06-02 20:45         ` Sohil Mehta
2025-05-13 20:37 ` [PATCH v6 2/9] x86/cpufeatures: Add the CPUID feature bit for NMI-source reporting Sohil Mehta
2025-05-13 20:37 ` [PATCH v6 3/9] x86/nmi: Extend the registration interface to include the NMI-source vector Sohil Mehta
2025-06-03  7:23   ` Xin Li
2025-06-03 17:35     ` Sohil Mehta
2025-06-03 17:07   ` Dave Hansen
2025-06-03 18:02     ` Sohil Mehta
2025-06-03 18:19       ` Dave Hansen
2025-06-03 20:24         ` Sohil Mehta
2025-05-13 20:37 ` [PATCH v6 4/9] x86/nmi: Assign and register NMI-source vectors Sohil Mehta
2025-06-03 16:34   ` Xin Li
2025-06-03 21:45     ` Sohil Mehta
2025-06-04 15:28     ` H. Peter Anvin
2025-06-11 21:34       ` Sohil Mehta
2025-06-03 17:23   ` Dave Hansen
2025-06-03 20:22     ` Sohil Mehta [this message]
2025-06-03 21:54       ` Dave Hansen
2025-06-03 22:33         ` Sohil Mehta
2025-06-04 15:22     ` H. Peter Anvin
2025-05-13 20:37 ` [PATCH v6 5/9] x86/nmi: Add support to handle NMIs with source information Sohil Mehta
2025-06-03 16:53   ` Xin Li
2025-05-13 20:38 ` [PATCH v6 6/9] x86/nmi: Prepare for the new NMI-source vector encoding Sohil Mehta
2025-05-13 20:38 ` [PATCH v6 7/9] x86/nmi: Enable NMI-source for IPIs delivered as NMIs Sohil Mehta
2025-05-13 20:38 ` [PATCH v6 8/9] perf/x86: Enable NMI-source reporting for perfmon Sohil Mehta
2025-06-03 16:57   ` Xin Li
2025-05-13 20:38 ` [PATCH v6 9/9] x86/nmi: Print source information with the unknown NMI console message Sohil Mehta
2025-06-03 16:55   ` Xin Li
2025-06-04  1:55     ` Sohil Mehta
2025-06-04  2:41       ` Xin Li
2025-06-04 15:41       ` H. Peter Anvin
2025-06-11 21:39         ` Sohil Mehta
2025-06-04 15:29     ` H. Peter Anvin

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=67683e00-48fa-4aa8-91ff-8726a5374675@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jacob.pan@linux.microsoft.com \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rui.zhang@intel.com \
    --cc=sandipan.das@amd.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®