Re: [RFC PATCH 31/36] arm64: nmi: Add handling of superpriority interrupts as NMIs

[Jinjie Ruan <ruanjinjie@huawei.com>]

On 7/15/2026 12:24 AM, Vladimir Murzin wrote:
> On 7/10/26 11:13, Jinjie Ruan wrote:
>>> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>>> index a13653b228b7..de71d5a3a6a1 100644
>>> --- a/arch/arm64/kernel/entry-common.c
>>> +++ b/arch/arm64/kernel/entry-common.c
>>> @@ -525,8 +525,8 @@ asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs)
>>>  	arm64_debug_exc_context(CRITICAL_CONTEXT);
>>>  }
>>>  
>>> -static __always_inline void __el1_pnmi(struct pt_regs *regs,
>>> -				       void (*handler)(struct pt_regs *))
>>> +static __always_inline void __el1_nmi(struct pt_regs *regs,
>>> +				      void (*handler)(struct pt_regs *))
>>>  {
>>>  	arm64_exc_hwstate_t hwstate;
>>>  	irqentry_state_t state;
>>> @@ -545,7 +545,10 @@ static __always_inline void __el1_irq(struct pt_regs *regs,
>>>  
>>>  	state = arm64_enter_from_kernel_mode(regs);
>>>  
>>> -	arm64_unmask_exc_context(NONMI_CONTEXT);
>>> +	if (system_uses_nmi())
>>> +		arm64_unmask_exc_context(NOIRQ_CONTEXT);
>>> +	else
>>> +		arm64_unmask_exc_context(NONMI_CONTEXT);
>> This looks strange; whether it's a pseudo NMI or FEAT_NMI, the behavior
>> should be consistent.
> 
> Here is my understanding of how things behave.
> 
> No NMI support
> 
>   NONMI_CONTEXT and NOIRQ_CONTEXT are the same, so we cannot take any
>   IRQ while handling an IRQ. On return from the handler, we remain in
>   NOIRQ_CONTEXT. Easy.
> 
> pNMI
> 
>   We cannot distinguish between an NMI and an IRQ on exception entry,
>   so we have to postpone unmasking the IF bits until the interrupt
>   handler. In other words, we enter the interrupt handler in
>   NONMI_CONTEXT.
>   
>   In the handler:
> 
>     1. For an NMI, we handle the NMI and then drop to NOIRQ_CONTEXT.
> 
>     2. For an IRQ, we drop to NOIRQ_CONTEXT (allowing NMIs to preempt
>        the IRQ handler) and then handle the IRQ.
> 
>   In both cases, we return from the handler in NOIRQ_CONTEXT.
> 
> FEAT_NMI
> 
>   We can distinguish between an NMI and an IRQ on exception
>   entry. Thus, for an IRQ, we can immediately drop to NOIRQ_CONTEXT
>   before passing control to the IRQ handler, allowing NMIs to preempt
>   the IRQ handler. This corresponds to case 2 of the pNMI flow above.
> 
> 
> Perhaps above could be better expressed with:
> 
> if (gic_supports_pseudo_nmis())
> 	arm64_unmask_exc_context(NONMI_CONTEXT);
> else
> 	arm64_unmask_exc_context(NOIRQ_CONTEXT);

Making it this way is reasonable.I understand that only when handling an
IRQ can the masking of NMI be canceled, which is a special case for
pseudo-NMI.

Here, not clearing the DAIF.I bit might be to prevent pseudo-NMI
nesting? Because at the interrupt entry point, it is still unclear
whether this is a pseudo-NMI or an IRQ being handled.

Best regards,
Jinjie

> 
> 
> Have I missed anything?
> 
> Cheers
> Vladimir
>