[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <abe358694e06a6076fb5838d1231eee6@kernel.org>
Date: Tue, 20 Oct 2020 13:32:03 +0100
From: Marc Zyngier <maz@...nel.org>
To: Daniel Thompson <daniel.thompson@...aro.org>
Cc: Sumit Garg <sumit.garg@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Mark Rutland <mark.rutland@....com>,
julien.thierry.kdev@...il.com,
Douglas Anderson <dianders@...omium.org>,
Jason Wessel <jason.wessel@...driver.com>,
Masayoshi Mizuma <msys.mizuma@...il.com>,
ito-yuichi@...itsu.com, kgdb-bugreport@...ts.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/5] arm64: Add framework to turn IPI as NMI
On 2020-10-20 13:25, Daniel Thompson wrote:
> On Tue, Oct 20, 2020 at 04:52:43PM +0530, Sumit Garg wrote:
[...]
>> So in general, IPI as a normal IRQ is still useful for debugging but
>> it can't debug a core which is stuck in deadlock with interrupts
>> disabled.
>>
>> And since we choose override default implementations for pseudo NMI
>> support, we need to be backwards compatible for platforms which don't
>> possess pseudo NMI support.
>
> Do the fallback implementations require a new IPI? The fallbacks
> could rely on existing mechanisms such as the smp_call_function
> family.
Indeed. I'd be worried of using that mechanism for NMIs, but normal
IPIs should stick to the normal cross-call stuff.
The jury is still out on why this is a good idea, given that it
doesn't work in the only interesting case (deadlocked CPUs).
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists