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

[Neeraj Upadhyay]

Hi Marc,

On 5/8/2020 5:57 PM, Marc Zyngier wrote:
> On Fri, 8 May 2020 16:36:42 +0530
> Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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).

Yes, we handle that watchdog interrupt as a Group-0 interrupt, which is 
handled as fiq in EL3.

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

Sending a pseudo NMI IPI (to EL1) from fiq handler (which runs in EL3); 
I will check, but do you think, that might not work?

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

Before triggering SoC reset, we want to collect certain  EL1 debug 
information like stack trace for CPUs and other debug information.

> Thanks,
>
> 	M.

Thanks
Neeraj

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of the Code Aurora Forum, hosted by The Linux Foundation