From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C063C04FE0 for ; Mon, 7 Aug 2023 11:24:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232462AbjHGLYE (ORCPT ); Mon, 7 Aug 2023 07:24:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232978AbjHGLXm (ORCPT ); Mon, 7 Aug 2023 07:23:42 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 12426423F; Mon, 7 Aug 2023 04:21:31 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DD8911FB; Mon, 7 Aug 2023 04:14:44 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.32.139]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 268F03F59C; Mon, 7 Aug 2023 04:13:59 -0700 (PDT) Date: Mon, 7 Aug 2023 12:13:56 +0100 From: Mark Rutland To: Marc Zyngier Cc: Douglas Anderson , Catalin Marinas , Will Deacon , Sumit Garg , Daniel Thompson , linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com, Chen-Yu Tsai , Ard Biesheuvel , Stephen Boyd , Peter Zijlstra , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Masayoshi Mizuma , "Rafael J . Wysocki" , Lecopzer Chen , Wei Li , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI Message-ID: References: <20230601213440.2488667-1-dianders@chromium.org> <20230601143109.v9.7.I2ef26d1b3bfbed2d10a281942b0da7d9854de05e@changeid> <7a295fcb4ff02542ff6835a77182fce8@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a295fcb4ff02542ff6835a77182fce8@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 07, 2023 at 12:08:06PM +0100, Marc Zyngier wrote: > On 2023-08-07 11:54, Mark Rutland wrote: > > On Mon, Aug 07, 2023 at 11:47:04AM +0100, Marc Zyngier wrote: > > > 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 > > > > > > > > > > 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 > > > > > Signed-off-by: Douglas Anderson > > > > > --- > > > > > > > > > > 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). > > > > Understood; Doug and I suggested two options for that: > > > > 1) Unify/mux the IPI_CPU_STOP and IPI_CPU_CRASH_STOP IPIs > > > > The only *intended* difference between the two is that > > IPI_CPU_CRASH_STOP > > calls crash_save_cpu() before trying to stop the CPU, but the > > implementations have diverged significantly for unrelated reasons. > > > > 2) Remove IPI_WAKEUP > > > > We only use IPI_WAKEUP for the ACPI parking protocol, and we could > > reuse > > another IPI (e.g. IPI_RESCHEDULE) to achieve the same thing witout a > > dedicated IPI. > > Sure. My concern is that we're papering over the fundamental problem, > which is that IPIs are limited resource, and that we're bound to pile > more stuff on them. > > I'm all for reclaiming the ones that can be merged, but we may ultimately > need a real fix for this. Sure; I will bear that in mind. Thanks, Mark.