[PATCH 2/3] lib: sbi: Enable Smrnmi extension handler

[Anup Patel]

On Tue, Mar 10, 2026 at 7:58 AM Nicholas Piggin <npiggin at gmail.com> wrote:
>
> On Mon, Feb 02, 2026 at 03:26:33PM +0000, Radim Krcmar wrote:
> > 2026-01-29T00:13:42-08:00, Nylon Chen <nylon.chen at sifive.com>:
> > > Enable the Smrnmi extension by:
> > > 1. Adding sbi_rnmi_vector_init() to allocate per-HART RNMI context and enable RNMI via MNSTATUS.NMIE
> > > 2. Saving and restoring CSR_MNSCRATCH and CSR_MNSTATUS across non-retentive suspend/resume
> > > 3. Calling sbi_rnmi_vector_init() from the cold and warm init paths
> > >
> > > Co-developed-by: Zong Li <zong.li at sifive.com>
> > > Signed-off-by: Zong Li <zong.li at sifive.com>
> > > Suggested-by: Nick Hu <nick.hu at sifive.com>
> > > Suggested-by: Samuel Holland <samuel.holland at sifive.com>
> > > Signed-off-by: Nylon Chen <nylon.chen at sifive.com>
> > > Signed-off-by: Yong-Xuan Wang <yongxuan.wang at sifive.com>
> > > ---
> > > diff --git a/include/sbi/sbi_platform.h b/include/sbi/sbi_platform.h
> > > @@ -149,6 +149,15 @@ struct sbi_platform_operations {
> > >                     unsigned long log2len);
> > >     /** platform specific pmp disable on current HART */
> > >     void (*pmp_disable)(unsigned int n);
> > > +   /**
> > > +    * Platform-specific helper to program the RNMI trap vector.
> > > +    *
> > > +    * The core will call this from sbi_rnmi_vector_init() with the
> > > +    * firmware RNMI handler entry address (rnmi_handler) and the
> > > +    * cold_boot flag. Platforms that support Smrnmi should implement
> > > +    * this; others can leave it NULL.
> > > +    */
> >
> > If the hart supports Smrnmi, then it begins with nmstatus.NMIE=0, which
> > means that any exception is going to enter a critical state.
> > The platform must somehow support Smrnmi to be useful, and I think it
> > would be better not to do it behind opensbi's back.
> >
> > If the platform wants to handle Smrnmi itself, it can hide Smrnmi from
> > opensbi, so I think the requirement here would be better as MUST.
> >
> > > +   int (*set_rnmi_trap_vector)(uintptr_t handler_addr, bool cold_boot);
> > > diff --git a/lib/sbi/sbi_init.c b/lib/sbi/sbi_init.c
> > > @@ -273,6 +273,10 @@ static void __noreturn init_coldboot(struct sbi_scratch *scratch, u32 hartid)
> > >     if (rc)
> > >             sbi_hart_hang();
> > >
> > > +   rc = sbi_rnmi_vector_init(scratch, true);
> >
> > Are we sure that earlier opensbi code won't try to trigger a trap before
> > this point?  OpenSBI would fail to boot if it did...
>
> This appears to come right after sbi_hart_init() which does a bunch of
> CSR detection using traps, so I'm not sure if it can work.

Why not ?

>
> Evgeny (+cc) has been doing a lot of work to enable Smrnmi on Ascalon
> and unfortunately we did not see there is this duplicate work happening
> upstream. His changes also has a few other things such as RNMI exception
> vector setting, permits a platform specific handler, and has an Ascalon
> platform implementation.

This is exactly why upstreaming should be prioritized so that people
can leverage each others work.

>
> So I asked him to post what he has. The intention is not to disregard
> this series, but to just show what he has. Hopefully the best of both
> can be used.
>
> Thanks,
> Nick
>
> --
> opensbi mailing list
> opensbi at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi

Regards,
Anup