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

[Kiryl Shutsemau]

On Tue, Jul 28, 2026 at 11:25:37AM +0100, Will Deacon wrote:
> > 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.

Right, that's the plan.

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

Yes, that's fine by me.

I'd prefer that exclusivity at boot rather than compile time, so we can
keep a single kernel binary across the fleet. The delivery side
already works this way -- the arch selects one cross-CPU-NMI provider, so
it's a boot-time decision already.

The piece that isn't boot-time yet is the hardlockup detector that drives
all this. perf and buddy are mutually exclusive at compile time. We want
to use perf watchdog for FEAT_NMI while SDEI needs buddy.

But it is solvable.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov