On 11/4/26 13:56, Chang S. Bae wrote:
> On 11/4/2026 10:23 AM, Chang S. Bae wrote:
>>
>> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
>> index e3660b8b8f38..11c965445bdc 100644
>> --- a/arch/x86/kernel/nmi.c
>> +++ b/arch/x86/kernel/nmi.c
>> @@ -553,7 +553,7 @@ DEFINE_IDTENTRY_RAW(exc_nmi)
>>           raw_atomic_long_inc(&nsp->idt_calls);
>>       if (arch_cpu_is_offline(smp_processor_id())) {
>> -        if (microcode_nmi_handler_enabled())
>> +        if (IS_ENABLED(CONFIG_MICROCODE_LATE_LOADING))
>>               microcode_offline_nmi_handler();
>>           return;
>>       }
>> @@ -715,7 +715,7 @@ DEFINE_FREDENTRY_NMI(exc_nmi)
>>       irqentry_state_t irq_state;
>>       if (arch_cpu_is_offline(smp_processor_id())) {
>> -        if (microcode_nmi_handler_enabled())
>> +        if (IS_ENABLED(CONFIG_MICROCODE_LATE_LOADING))
>>               microcode_offline_nmi_handler();
>>           return;
>>       }
> 
> There is a Sashiko comment on this:
> https://sashiko.dev/#/patchset/20261104182322.578066-1- 
> chang.seok.bae%40intel.com
> 
> I thought waking up soft-offlined SMT siblings with an NMI was benign. 
> Right now the path is not explicitly gated by the use_nmi flag even 
> though the underlying mechanism is NMI-based.

As looking more, this looks like a bug to me. NMIs are raised to those 
CPUs, but not handled because the static key is off. So I ended up with 
this patch: