[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a030019c7c5887d54b97054ed7d9af12@kernel.org>
Date: Mon, 07 Aug 2023 11:47:04 +0100
From: Marc Zyngier <maz@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Douglas Anderson <dianders@...omium.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Sumit Garg <sumit.garg@...aro.org>,
Daniel Thompson <daniel.thompson@...aro.org>,
linux-perf-users@...r.kernel.org, ito-yuichi@...itsu.com,
Chen-Yu Tsai <wens@...e.org>, Ard Biesheuvel <ardb@...nel.org>,
Stephen Boyd <swboyd@...omium.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel@...ts.infradead.org,
kgdb-bugreport@...ts.sourceforge.net,
Masayoshi Mizuma <msys.mizuma@...il.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Lecopzer Chen <lecopzer.chen@...iatek.com>,
Wei Li <liwei391@...wei.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI
On 2023-08-07 11:28, Mark Rutland wrote:
> On Thu, Jun 01, 2023 at 02:31:51PM -0700, Douglas Anderson wrote:
>> From: Sumit Garg <sumit.garg@...aro.org>
>>
>> Let's use the debug IPI for rounding up CPUs in kgdb. When the debug
>> IPI is backed by an NMI (or pseudo NMI) then this will let us debug
>> even hard locked CPUs. When the debug IPI isn't backed by an NMI then
>> this won't really have any huge benefit but it will still work.
>>
>> Signed-off-by: Sumit Garg <sumit.garg@...aro.org>
>> Signed-off-by: Douglas Anderson <dianders@...omium.org>
>> ---
>>
>> Changes in v9:
>> - Remove fallback for when debug IPI isn't available.
>> - Renamed "NMI IPI" to "debug IPI" since it might not be backed by
>> NMI.
>>
>> arch/arm64/kernel/ipi_debug.c | 5 +++++
>> arch/arm64/kernel/kgdb.c | 14 ++++++++++++++
>> 2 files changed, 19 insertions(+)
>
> This looks fine to me, but I'd feel a bit happier if we had separate
> SGIs for
> the backtrace and the KGDB callback as they're logically unrelated.
Well, we're a bit stuck here.
We have exactly *one* spare SGI with GICv3, as we lose 8 of them
to the secure side. One possibility would be to mux some of the
lesser used IPIs onto two SGIs (one with standard priority, and
one with NMI priority).
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists