linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>,
	X86 Kernel <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	linux-perf-users@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi.kleen@intel.com>, Xin Li <xin3.li@intel.com>
Subject: Re: [PATCH 2/6] x86/irq: Extend NMI handler registration interface to include source
Date: Wed, 29 May 2024 13:59:51 -0700	[thread overview]
Message-ID: <746fecd5-4c79-42f9-919e-912ec415e73f@zytor.com> (raw)
In-Reply-To: <20240529203325.3039243-3-jacob.jun.pan@linux.intel.com>

On 5/29/24 13:33, Jacob Pan wrote:
> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 13aea8fc3d45..b8388bc00cde 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -105,6 +105,27 @@
>   
>   #define NR_VECTORS			 256
>   
> +/*
> + * The NMI senders specify the NMI source vector as an 8bit integer in their
> + * vector field with NMI delivery mode. A local APIC receiving an NMI will
> + * set the corresponding bit in a 16bit bitmask, which is accumulated until
> + * the NMI is delivered.
> + * When a sender didn't specify an NMI source vector the source vector will
> + * be 0, which will result in bit 0 of the bitmask being set. For out of
> + * bounds vectors >= 16 bit 0 will also be set.
> + * When bit 0 is set, system software must invoke all registered NMI handlers
> + * as if NMI source feature is not enabled.
> + */
> +#define NMI_SOURCE_VEC_UNKNOWN		0
> +#define NMI_SOURCE_VEC_PMI		1	/* PerfMon counters */
> +#define NMI_SOURCE_VEC_IPI_BT		2	/* CPU backtrace */
> +#define NMI_SOURCE_VEC_IPI_MCE		3	/* MCE injection */
> +#define NMI_SOURCE_VEC_IPI_KGDB		4
> +#define NMI_SOURCE_VEC_IPI_REBOOT	5	/* Crash reboot */
> +#define NMI_SOURCE_VEC_IPI_SMP_STOP	6	/* Panic stop CPU */
> +#define NMI_SOURCE_VEC_IPI_TEST		7	/* For remote and local IPIs*/
> +#define NR_NMI_SOURCE_VECTORS		8
> +

I would avoid using vector 2; it is at least remotely possible that some 
third-party chipset sends NMI messages with a hardcoded vector of 2. As 
long as you don't actively need that slot, it is better to avoid it.

Even better is to set the LINT1 (= external NMI) vector to 2 and treat 
bit 2 as "other"; use vector 2 for anything that you don't have an 
explicit vector for. You can treat a received bit 2 the same as bit 0, 
except that you can explicitly trust that any event assigned an explicit 
vector number is *NOT* triggered and so do not need to be polled.

I would also recommend sorting these in order of decreasing importance 
(other than 0 and 2). Although the current intent is there to be 16 
vectors indefinitely, defensive design would be to consider that number 
to be potentially variable (up to 64, obviously). Since any out-of-range 
vector will set bit 0, the code will still Just Work[TM].

	-hpa

  reply	other threads:[~2024-05-29 21:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 20:33 [PATCH 0/6] Add support for NMI source reporting Jacob Pan
2024-05-29 20:33 ` [PATCH 1/6] x86/irq: Add enumeration of NMI source reporting CPU feature Jacob Pan
2024-05-29 20:49   ` H. Peter Anvin
2024-05-30 16:19     ` Jacob Pan
2024-05-30 20:39       ` Jacob Pan
2024-05-29 20:33 ` [PATCH 2/6] x86/irq: Extend NMI handler registration interface to include source Jacob Pan
2024-05-29 20:59   ` H. Peter Anvin [this message]
2024-05-30 17:49     ` Jacob Pan
2024-05-29 20:33 ` [PATCH 3/6] x86/irq: Factor out common NMI handling code Jacob Pan
2024-05-29 20:33 ` [PATCH 4/6] x86/irq: Process nmi sources in NMI handler Jacob Pan
2024-05-29 20:47   ` H. Peter Anvin
2024-05-30 16:10     ` Jacob Pan
2024-05-29 21:12   ` H. Peter Anvin
2024-05-30 17:52     ` Jacob Pan
2024-05-29 20:33 ` [PATCH 5/6] perf/x86: Enable NMI source reporting for perfmon Jacob Pan
2024-05-29 20:33 ` [PATCH 6/6] x86/irq: Enable NMI source on IPIs delivered as NMI Jacob Pan

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=746fecd5-4c79-42f9-919e-912ec415e73f@zytor.com \
    --to=hpa@zytor.com \
    --cc=andi.kleen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.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;
as well as URLs for NNTP newsgroup(s).