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

[Neeraj Upadhyay <neeraju@codeaurora.org>]

Hi Marc,

On 5/8/2020 5:57 PM, Marc Zyngier wrote:
> 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).

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