[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ftca1z9k.wl-maz@kernel.org>
Date: Fri, 08 May 2020 11:45:11 +0100
From: Marc Zyngier <maz@...nel.org>
To: Neeraj Upadhyay <neeraju@...eaurora.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()
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?
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.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists