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

[Will Deacon]

On Sun, Jul 26, 2026 at 07:35:20PM +0100, Kiryl Shutsemau wrote:
> 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@xxxxxxxxxx>
> > > > 
> > > > 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.

That's fair, I was really just trying to understand the direction. It
sounds like you will *eventually* move to FEAT_NMI, even if it's many
years away.

> 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.

I'm somewhat trying to predict the future here, but I wouldn't be
shocked if some whizz-bang new architecture feature interacted badly
with SDEI, either due to outdated specs or because of a fundamental
incompatability. In this case, I would like the option of being able to
make new hardware support mutually exclusive with SDEI rather than try
to hack around the mess. It sounds like that would be ok for you?

Will