Messages in this thread | | | Subject | Re: Query regarding pseudo nmi support on GIC V3 and request_nmi() | From | Neeraj Upadhyay <> | Date | Fri, 8 May 2020 18:09:00 +0530 |
| |
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
| |