Re: [PATCH v2 1/2] arm64: sdei: Run the event handler on the kernel vectors

[Catalin Marinas]

On Thu, Nov 05, 2026 at 12:08:33PM +0000, Kiryl Shutsemau wrote:
> @@ -1065,10 +1067,27 @@ __sdei_handler(struct pt_regs *regs, struct sdei_registered_event *arg)
>  	else if (cpu_has_pan())
>  		set_pstate_pan(0);
>  
> +	/*
> +	 * With KPTI, VBAR_EL1 holds the trampoline vectors from the return to
> +	 * EL0 until the next exception from EL0 maps the kernel. They only
> +	 * handle exceptions from EL0: an exception taken here would run their
> +	 * empty current-EL half and never come back. Switch to the kernel
> +	 * vectors. The IRQ-like resume keeps using the interrupted VBAR, so it
> +	 * still goes through the trampoline.
> +	 */
> +	vbar = read_sysreg(vbar_el1);
> +	if (arm64_kernel_unmapped_at_el0() &&
> +	    vbar == (unsigned long)__this_cpu_read(this_cpu_vector)) {
> +		write_sysreg((unsigned long)vectors, vbar_el1);
> +		isb();
> +	}

Sashiko had a comment that the above should be raw_cpu_read() since with
preempt debugging and pseudo-NMIs, irqs_disabled() is false here and the
check in __this_cpu_read() will warn.

Thinking about it, further down on the irqentry_nmi_enter() ->
lockdep_hardirqs_off() we'll hit the irqs_disabled() issue again. We
could just do a raw_local_irq_save/restore() around this function.
Unnecessary for DAIF but useful with pseudo-NMIs.

Alternatively, __sdei_asm_handler() could save/restore PMR and change
the priorities similar to the kernel_entry code. Actually, this may be
better since do_sdei_event() also checks regs_irqs_disabled() and we
don't have any regs->pmr populated.

Worth a separate patch to fix SDEI handling with pseudo-NMI on and no
changes to __this_cpu_read() above needed. So, for this patch:

Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>

(I'll probably queue it for -rc but waiting to see if there are more
comments)

-- 
Catalin