Re: Query regarding pseudo nmi support on GIC V3 and request_nmi()

[Marc Zyngier <maz@kernel.org>]

On Fri, 8 May 2020 16:36:42 +0530
Neeraj Upadhyay <neeraju@codeaurora.org> wrote:

> Hi Marc,
> 
> On 5/8/2020 4:15 PM, Marc Zyngier wrote:
> > On Thu, 07 May 2020 17:06:19 +0100,
> > Neeraj Upadhyay <neeraju@codeaurora.org> wrote:  
> >>
> >> Hi,
> >>
> >> I have one query regarding pseudo NMI support on GIC v3; from what I
> >> could understand, GIC v3 supports pseudo NMI setup for SPIs and PPIs.
> >> However the request_nmi() in irq framework requires NMI to be per cpu
> >> interrupt source (it checks for IRQF_PERCPU). Can you please help
> >> understand this part, how SPIs can be configured as NMIs, if there is
> >> a per cpu interrupt source restriction?  
> > 
> > Let me answer your question by another question: what is the semantic
> > of a NMI if you can't associate it with a particular CPU?
> >  
> 
> I was actually thinking of a use case, where, we have a watchdog
> interrupt (which is a SPI), which is used for detecting software
> hangs and cause device reset; If that interrupt's current cpu
> affinity is on a core, where interrupts are disabled, we won't be
> able to serve it; so, we need to group that interrupt as an fiq; 

Linux doesn't use Group-0 interrupts, as they are strictly secure
(unless your SoC doesn't have EL3, which I doubt).

> I was thinking, if its feasible to mark that interrupt as pseudo NMI
> and route it to EL1 as irq. However, looks like that is not the
> semantic of a NMI and we would need something like pseudo NMI ipi for
> this.

Sending a NMI IPI from another NMI handler? Even once I've added these,
there is no way this will work for that particular scenario. Just look
at the restrictions we impose on NMIs.

Frankly, if all you need to do is to reset the SoC, use EL3 firmware.
That is what it is for.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...