Re: [PATCH v5 0/4] arm64: cross-CPU NMI via SDEI

[Kiryl Shutsemau <kas@kernel.org>]

On Sun, Jul 26, 2026 at 02:55:49PM +0100, Will Deacon wrote:
> On Thu, Jul 09, 2026 at 05:16:37PM +0100, Kiryl Shutsemau wrote:
> > On Mon, Jun 29, 2026 at 04:07:14PM +0100, Kiryl Shutsemau wrote:
> > > From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> > > 
> > > A class of debug/observability features needs to interrupt a CPU that has
> > > its interrupts locally masked: the all-CPU backtrace behind sysrq-l /
> > > RCU-stall / hung-task / hard-lockup dumps, and crash_smp_send_stop()
> > > capturing a stuck CPU's state into the vmcore. On arm64 these need a
> > > mechanism that reaches a CPU spinning with DAIF masked, which a normal IPI
> > > cannot.
> > 
> > Gentle ping. Any feedback?
> > 
> > I'm looking forward to finding an upstreamable solution to the problem.
> 
> This is all pretty small, self-contained and it's useful to you, so I'm
> inclined to merge it.

Thanks!

> However, the one vague concern I have is about the direction of SDEI in
> the future. AFAIK, the TF-A implementation is known to have issues, it's
> not supported at all by R-FA and I worry that the spec is going to fall
> behind the architecture, particularly as FEAT_NMI becomes available.
> 
> So it would be good to understand what we're signing up to maintain here.
> Kiryl, do you see an (eventual) migration over to FEAT_NMI, giving us a
> path to deprecating SDEI altogether, or do you think the two will live
> alongside each other for the forseeable future?

Realistically, the foreseeable future.

FEAT_NMI is the endgame and a machine that has it needs none of this,
but non-FEAT_NMI parts stay in fleets for many years, so I can't
honestly give you a date for dropping SDEI.

While this change is pretty self-contained, I understand that SDEI infra
maintenance can be a burden.

Is there anything on the wider SDEI infrastructure that would lower the
maintenance burden or keep it more out of your way -- consolidation,
tighter isolation, docs, help carrying it? If there's work there that
makes SDEI more palatable to keep while non-FEAT_NMI parts are in
service, I'm glad to take it on.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov