Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Aug 2023 12:13:56 +0100
From:   Mark Rutland <mark.rutland@arm.com>
To:     Marc Zyngier <maz@kernel.org>
Cc:     Douglas Anderson <dianders@chromium.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Sumit Garg <sumit.garg@linaro.org>,
        Daniel Thompson <daniel.thompson@linaro.org>,
        linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com,
        Chen-Yu Tsai <wens@csie.org>, Ard Biesheuvel <ardb@kernel.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-arm-kernel@lists.infradead.org,
        kgdb-bugreport@lists.sourceforge.net,
        Masayoshi Mizuma <msys.mizuma@gmail.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Lecopzer Chen <lecopzer.chen@mediatek.com>,
        Wei Li <liwei391@huawei.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI
Message-ID: <ZNDR9C8711K5EoNW@FVFF77S0Q05N.cambridge.arm.com>
References: <20230601213440.2488667-1-dianders@chromium.org>
 <20230601143109.v9.7.I2ef26d1b3bfbed2d10a281942b0da7d9854de05e@changeid>
 <ZNDHZLGds0DTN6zg@FVFF77S0Q05N.cambridge.arm.com>
 <a030019c7c5887d54b97054ed7d9af12@kernel.org>
 <ZNDNY_JfUxXm2vR5@FVFF77S0Q05N.cambridge.arm.com>
 <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

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 <sumit.garg@linaro.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@linaro.org>
> > > > > Signed-off-by: Douglas Anderson <dianders@chromium.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).
> > 
> > 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.