linux-kernel - Re: Query regarding pseudo nmi support on GIC V3 and request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2f41b2e8-925e-3869-da39-fd4ab28ca1b1@codeaurora.org>
Date:   Fri, 8 May 2020 16:36:42 +0530
From:   Neeraj Upadhyay <neeraju@...eaurora.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     julien.thierry.kdev@...il.com, linux-kernel@...r.kernel.org
Subject: Re: Query regarding pseudo nmi support on GIC V3 and request_nmi()

Hi Marc,

On 5/8/2020 4:15 PM, Marc Zyngier wrote:
> On Thu, 07 May 2020 17:06:19 +0100,
> Neeraj Upadhyay <neeraju@...eaurora.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; 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.

> We use pseudo-NMI to be able to profile (or detect lockups) within
> sections where normal interrupts cannot fire. If the interrupt can
> end-up on a random CPU (with an unrelated PMU or one that hasn't
> locked up), what have we achieved? Only confusion.
> 
> The whole point is that NMIs have to be tied to a given CPU. For
> SGI/PPI, this is guaranteed by construction. For SPIs, this means that
> the affinity cannot be changed from userspace. IRQF_PERCPU doesn't
> mean much in this context as we don't "broadcast" interrupts, but is
> an indication to the core kernel that the same interrupt cannot be
> taken on another CPU.
> 
> The short of it is that NMIs are only for per-CPU sources. For SPIs,
> that's for PMUs that use SPIs instead of PPIs. Don't use it for
> anything else.
> 

Thank you for the explanation!

> 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