Messages in this thread | | | Date | Mon, 7 Aug 2023 11:54:27 +0100 | From | Mark Rutland <> | Subject | Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI |
| |
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.
Thanks, Mark.
| |