Re: [PATCH] MIPS: add nmi_enter() + nmi_exit() to nmi_exception_handler()

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, Jan 12, 2016 at 01:03:18AM +0000, Maciej W. Rozycki wrote:

> On Mon, 9 Nov 2015, Ralf Baechle wrote:
> 
> > > > diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> > > > index fdb392b..efcedd4 100644
> > > > --- a/arch/mips/kernel/traps.c
> > > > +++ b/arch/mips/kernel/traps.c
> > > > @@ -1856,12 +1856,14 @@ void __noreturn nmi_exception_handler(struct pt_regs *regs)
> > > >  {
> > > >         char str[100];
> > > >
> > > > +       nmi_enter();
> > > >         raw_notifier_call_chain(&nmi_chain, 0, regs);
> > > >         bust_spinlocks(1);
> > > >         snprintf(str, 100, "CPU%d NMI taken, CP0_EPC=%lx\n",
> > > >                  smp_processor_id(), regs->cp0_epc);
> > > >         regs->cp0_epc = read_c0_errorepc();
> > > >         die(str, regs);
> > > > +       nmi_exit();
> > > >  }
> > > >
> > > >  #define VECTORSPACING 0x100    /* for EI/VI mode */
> > > > --
> > > > 2.6.0.rc2.230.g3dd15c0
> > > >
> > > 
> > > Any comments/concerns about this patch?
> > 
> > Is NMI on your systems actually recoverable?  I never bothered with
> > nmi_enther / nmi_exit and other fine details of the NMI implementations
> > because as defined by the MIPS architecture an NMI may be pretty destructive
> > and closer to a reset than what other architectures describer as their NMI.
> > Think what's going to happen if it hits during any phase when $k0 / $k1
> > are active.
> 
>  We could do better though, by having a register stash area defined 
> somewhere in low memory (0x0-0x7fff) -- of course if physical memory is 
> actually available there in a given system.  Remember that setting 
> CP0.Status.ERL makes KUSEG identity mapped, making it possible to access 
> its beginning off $zero and save all GPRs in a non-destructive manner.
> 
>  That is however assuming we can take control at all in the first place as 
> the NMI vector is hardwired and points to a ROM location in a typical 
> system.

NMIs don't nest; the system is lost if it receives another NMI before the
state of the first is saved.  It's currently up to the system to avoid that
probably by yes masking the non-maskable interrupt.

ErrorEPC is also used by cache errors so an NMI following a cache error
exception before state has been saved might be fatal.

These are scenarios that are taken care of by CISC architectures but on a
purebred RISC they're up to system implementors.

  Ralf