Received-SPF: pass (google.com: domain of linux-kernel+bounces-210839-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 11 Jun 2024 19:50:22 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
To: Xin Li <xin@zytor.com>, 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: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_1/6=5D_x86/irq=3A_Add_enumera?=
 =?US-ASCII?Q?tion_of_NMI_source_reporting_CPU_feature?=
User-Agent: K-9 Mail for Android
In-Reply-To: <de99f490-8b8d-4ae9-9f87-e0336e563aba@zytor.com>
References: <20240611165457.156364-1-jacob.jun.pan@linux.intel.com> <20240611165457.156364-2-jacob.jun.pan@linux.intel.com> <de99f490-8b8d-4ae9-9f87-e0336e563aba@zytor.com>
Message-ID: <34E0974A-45E0-4E98-9384-3A19D01ECF1E@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On June 11, 2024 7:32:54 PM PDT, Xin Li <xin@zytor=2Ecom> wrote:
>On 6/11/2024 9:54 AM, Jacob Pan wrote:
>> The lack of a mechanism to pinpoint the origins of Non-Maskable Interru=
pts
>> (NMIs) necessitates that the NMI vector 2 handler consults each NMI sou=
rce
>> handler individually=2E This approach leads to inefficiencies, delays, =
and
>> the occurrence of unnecessary NMIs, thereby also constraining the poten=
tial
>> applications of NMIs=2E
>>=20
>> A new CPU feature, known as NMI source reporting, has been introduced a=
s
>> part of the Flexible Return and Event Delivery (FRED) spec=2E This feat=
ure
>> enables the NMI vector 2 handler to directly obtain information about t=
he
>> NMI source from the FRED event data=2E
>>=20
>> The functionality of NMI source reporting is tied to the FRED=2E Althou=
gh it
>> is enumerated by a unique CPUID feature bit, it cannot be turned off
>> independently once FRED is activated=2E
>>=20
>> Signed-off-by: Jacob Pan <jacob=2Ejun=2Epan@linux=2Eintel=2Ecom>
>> ---
>> v2: Removed NMI source from static CPU ID dependency table (HPA)
>> ---
>>   arch/x86/Kconfig                         | 9 +++++++++
>>   arch/x86/include/asm/cpufeatures=2Eh       | 1 +
>>   arch/x86/include/asm/disabled-features=2Eh | 8 +++++++-
>>   arch/x86/kernel/traps=2Ec                  | 4 +++-
>>   4 files changed, 20 insertions(+), 2 deletions(-)
>>=20
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 1d7122a1883e=2E=2Eb8b15f20b94e 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=2E
>>   +config X86_NMI_SOURCE
>
>Lets reuse X86_FRED instead of adding another hard config option=2E See
>below=2E
>
>> +	def_bool n
>> +	help
>> +	  Once enabled, information on NMI originator/source can be provided
>> +	  via FRED event data=2E 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=2E
>> +
>>   config X86_BIGSMP
>>   	bool "Support for big SMP systems with more than 8 CPUs"
>>   	depends on SMP && X86_32
>
>=2E=2E=2E
>
>> diff --git a/arch/x86/include/asm/disabled-features=2Eh b/arch/x86/incl=
ude/asm/disabled-features=2Eh
>> index c492bdc97b05=2E=2E3856c4737d65 100644
>> --- a/arch/x86/include/asm/disabled-features=2Eh
>> +++ b/arch/x86/include/asm/disabled-features=2Eh
>> @@ -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_UN=
RET| \
>>   			 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=2Ec b/arch/x86/kernel/traps=2Ec
>> index 4fa0b17e5043=2E=2E465f04e4a79f 100644
>> --- a/arch/x86/kernel/traps=2Ec
>> +++ b/arch/x86/kernel/traps=2Ec
>> @@ -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=2Eh:
>
>1) If FRED is not available, NMI source won't be too=2E
>2) If FRED is available but not enabled, all features relying on FRED
>should be cleared=2E We probably should move the feature bits clearing
>code into a static function when more such features are added in future=
=2E
>
>>     	/* Init cpu_entry_area before IST entries are set up */
>>   	setup_cpu_entry_areas();
>
>Thanks!
>    Xin

And even if we did, FRED should not *select* NMI_SOURCE; the dependency go=
es the other way=2E