From: Xin Li <xin@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>,
"H. Peter Anvin" <hpa@zytor.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 v2 1/6] x86/irq: Add enumeration of NMI source reporting CPU feature
Date: Tue, 11 Jun 2024 19:32:54 -0700 [thread overview]
Message-ID: <de99f490-8b8d-4ae9-9f87-e0336e563aba@zytor.com> (raw)
In-Reply-To: <20240611165457.156364-2-jacob.jun.pan@linux.intel.com>
On 6/11/2024 9:54 AM, Jacob Pan wrote:
> The lack of a mechanism to pinpoint the origins of Non-Maskable Interrupts
> (NMIs) necessitates that the NMI vector 2 handler consults each NMI source
> handler individually. This approach leads to inefficiencies, delays, and
> the occurrence of unnecessary NMIs, thereby also constraining the potential
> applications of NMIs.
>
> A new CPU feature, known as NMI source reporting, has been introduced as
> part of the Flexible Return and Event Delivery (FRED) spec. This feature
> enables the NMI vector 2 handler to directly obtain information about the
> NMI source from the FRED event data.
>
> The functionality of NMI source reporting is tied to the FRED. Although it
> is enumerated by a unique CPUID feature bit, it cannot be turned off
> independently once FRED is activated.
>
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> v2: Removed NMI source from static CPU ID dependency table (HPA)
> ---
> arch/x86/Kconfig | 9 +++++++++
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/disabled-features.h | 8 +++++++-
> arch/x86/kernel/traps.c | 4 +++-
> 4 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1d7122a1883e..b8b15f20b94e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -511,12 +511,21 @@ config X86_CPU_RESCTRL
> config X86_FRED
> bool "Flexible Return and Event Delivery"
> depends on X86_64
> + select X86_NMI_SOURCE
> help
> When enabled, try to use Flexible Return and Event Delivery
> instead of the legacy SYSCALL/SYSENTER/IDT architecture for
> ring transitions and exception/interrupt handling if the
> system supports it.
>
> +config X86_NMI_SOURCE
Lets reuse X86_FRED instead of adding another hard config option. See
below.
> + def_bool n
> + help
> + Once enabled, information on NMI originator/source can be provided
> + via FRED event data. This makes NMI processing more efficient in that
> + NMI handler does not need to check for every possible source at
> + runtime when NMI is delivered.
> +
> config X86_BIGSMP
> bool "Support for big SMP systems with more than 8 CPUs"
> depends on SMP && X86_32
...
> diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
> index c492bdc97b05..3856c4737d65 100644
> --- a/arch/x86/include/asm/disabled-features.h
> +++ b/arch/x86/include/asm/disabled-features.h
> @@ -123,6 +123,12 @@
> # define DISABLE_FRED (1 << (X86_FEATURE_FRED & 31))
> #endif
>
> +#ifdef CONFIG_X86_NMI_SOURCE
> +# define DISABLE_NMI_SOURCE 0
> +#else
> +# define DISABLE_NMI_SOURCE (1 << (X86_FEATURE_NMI_SOURCE & 31))
> +#endif
> +
> #ifdef CONFIG_KVM_AMD_SEV
> #define DISABLE_SEV_SNP 0
> #else
> @@ -145,7 +151,7 @@
> #define DISABLED_MASK10 0
> #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \
> DISABLE_CALL_DEPTH_TRACKING|DISABLE_USER_SHSTK)
> -#define DISABLED_MASK12 (DISABLE_FRED|DISABLE_LAM)
> +#define DISABLED_MASK12 (DISABLE_FRED|DISABLE_LAM|DISABLE_NMI_SOURCE)
> #define DISABLED_MASK13 0
> #define DISABLED_MASK14 0
> #define DISABLED_MASK15 0
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 4fa0b17e5043..465f04e4a79f 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -1427,8 +1427,10 @@ early_param("fred", fred_setup);
>
> void __init trap_init(void)
> {
> - if (cpu_feature_enabled(X86_FEATURE_FRED) && !enable_fred)
> + if (cpu_feature_enabled(X86_FEATURE_FRED) && !enable_fred) {
> setup_clear_cpu_cap(X86_FEATURE_FRED);
> + setup_clear_cpu_cap(X86_FEATURE_NMI_SOURCE);
> + }
With this, no need to add DISABLE_NMI_SOURCE to disabled-features.h:
1) If FRED is not available, NMI source won't be too.
2) If FRED is available but not enabled, all features relying on FRED
should be cleared. We probably should move the feature bits clearing
code into a static function when more such features are added in future.
>
> /* Init cpu_entry_area before IST entries are set up */
> setup_cpu_entry_areas();
Thanks!
Xin
next prev parent reply other threads:[~2024-06-12 2:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 16:54 Jacob Pan
2024-06-11 16:54 ` [PATCH v2 1/6] x86/irq: Add enumeration of NMI source reporting CPU feature Jacob Pan
2024-06-12 2:32 ` Xin Li [this message]
2024-06-12 2:50 ` H. Peter Anvin
2024-06-12 3:04 ` Xin Li
2024-06-21 23:00 ` Sohil Mehta
2024-06-28 5:00 ` Jacob Pan
2024-06-21 22:23 ` Sohil Mehta
2024-06-21 23:46 ` Jacob Pan
2024-06-22 1:08 ` Sohil Mehta
2024-06-27 22:23 ` Jacob Pan
2024-06-27 23:20 ` Sohil Mehta
2024-06-11 16:54 ` [PATCH v2 2/6] x86/irq: Extend NMI handler registration interface to include source Jacob Pan
2024-06-24 23:16 ` Sohil Mehta
2024-06-28 4:56 ` Jacob Pan
2024-06-11 16:54 ` [PATCH v2 3/6] x86/irq: Factor out common NMI handling code Jacob Pan
2024-06-11 16:54 ` [PATCH v2 4/6] x86/irq: Process nmi sources in NMI handler Jacob Pan
2024-06-11 18:41 ` H. Peter Anvin
2024-06-12 21:54 ` Jacob Pan
2024-06-24 23:38 ` Sohil Mehta
2024-06-24 23:53 ` Sohil Mehta
2024-06-11 16:54 ` [PATCH v2 5/6] perf/x86: Enable NMI source reporting for perfmon Jacob Pan
2024-06-11 19:10 ` H. Peter Anvin
2024-06-12 20:27 ` Jacob Pan
2024-06-11 16:54 ` [PATCH v2 6/6] x86/irq: Enable NMI source on IPIs delivered as NMI Jacob Pan
2024-06-12 2:04 ` Sean Christopherson
2024-06-12 2:55 ` Re: Xin Li
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=de99f490-8b8d-4ae9-9f87-e0336e563aba@zytor.com \
--to=xin@zytor.com \
--cc=andi.kleen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.