[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9057390e-1a15-43e7-b4bc-803651b951ed@intel.com>
Date: Mon, 24 Jun 2024 16:16:52 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>, X86 Kernel <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...el.com>, "H. Peter Anvin" <hpa@...or.com>, "Ingo
Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
<linux-perf-users@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>
CC: Andi Kleen <andi.kleen@...el.com>, Xin Li <xin3.li@...el.com>
Subject: Re: [PATCH v2 2/6] x86/irq: Extend NMI handler registration interface
to include source
On 6/11/2024 9:54 AM, Jacob Pan wrote:
> Add a source vector argument to register_nmi_handler() such that designated
> NMI originators can leverage NMI source reporting feature. For those who
> do not use NMI source reporting, 0 (unknown) is used as the source vector. NMI
> source vectors (up to 16) are pre-defined.
>
What determines whether a source supports the new reporting vs some that
don't? It might be useful to add that reasoning to the commit message as
well.
I am guessing there is some connection to NMI_LOCAL based on
use_nmi_source() definition but I am not sure.
Also, would it be worthwhile to split this patch into 2? One part that
extents the register_nmi_handler() API and another that allocates the
source vectors to certain sources.
> +static inline bool use_nmi_source(unsigned int type, struct nmiaction *a)
> +{
> + return (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) &&
> + type == NMI_LOCAL && a->source_vec);
> +}
> +
Sohil
Powered by blists - more mailing lists