From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: <paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
<aou@eecs.berkeley.edu>, <samuel.holland@sifive.com>,
<conor.dooley@microchip.com>, <takakura@valinux.co.jp>,
<linux-kernel@vger.kernel.org>, <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH] RISC-V: Implement kgdb_roundup_cpus() to enable IPI KGDB Roundup
Date: Sat, 20 Jul 2024 15:26:48 +0800 [thread overview]
Message-ID: <333494b6-b128-3804-b8f7-03f61dbca9d7@huawei.com> (raw)
In-Reply-To: <20240719-8841a9a99566e15c9bd1ff3d@orel>
On 2024/7/19 23:14, Andrew Jones wrote:
> On Fri, Jul 19, 2024 at 04:12:10PM GMT, Jinjie Ruan wrote:
>> Until now, the generic weak kgdb_roundup_cpus() has been used for kgdb on
>> RISCV. A custom one allows to debug CPUs that are stuck with interrupts
>> disabled.
>
> This confuses me since we're using an IPI for the roundup. How does that
> work on CPUs stuck with interrupts disabled? I think this text comes
> from the commit message for the arm64 patch, but arm64 does the roundup
> with a pseudo-NMI.
Sorry, you are right, this commit message is indeed from arm64, and it
will be more useful with IPI as NMI support, where it will work on CPUs
stuck with interrupts disabled.
>
>> And using an IPI is better than the generic one since it avoids
>> the potential situation described in the generic kgdb_call_nmi_hook().
>
> This is true.
>
>>
>> After this patch, the kgdb test show that:
>> # echo g > /proc/sysrq-trigger
>> [2]kdb> btc
>> btc: cpu status: Currently on cpu 2
>> Available cpus: 0-1(-), 2, 3(-)
>> Stack traceback for pid 0
>> 0xffffffff81c13a40 0 0 1 0 - 0xffffffff81c14510 swapper/0
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.10.0-g3120273055b6-dirty #51
>> Hardware name: riscv-virtio,qemu (DT)
>> Call Trace:
>> [<ffffffff80006c48>] dump_backtrace+0x28/0x30
>> [<ffffffff80fceb38>] show_stack+0x38/0x44
>> [<ffffffff80fe6a04>] dump_stack_lvl+0x58/0x7a
>> [<ffffffff80fe6a3e>] dump_stack+0x18/0x20
>> [<ffffffff801143fa>] kgdb_cpu_enter+0x682/0x6b2
>> [<ffffffff801144ca>] kgdb_nmicallback+0xa0/0xac
>> [<ffffffff8000a392>] handle_IPI+0x9c/0x120
>> [<ffffffff800a2baa>] handle_percpu_devid_irq+0xa4/0x1e4
>> [<ffffffff8009cca8>] generic_handle_domain_irq+0x28/0x36
>> [<ffffffff800a9e5c>] ipi_mux_process+0xe8/0x110
>> [<ffffffff806e1e30>] imsic_handle_irq+0xf8/0x13a
>> [<ffffffff8009cca8>] generic_handle_domain_irq+0x28/0x36
>> [<ffffffff806dff12>] riscv_intc_aia_irq+0x2e/0x40
>> [<ffffffff80fe6ab0>] handle_riscv_irq+0x54/0x86
>> [<ffffffff80ff2e4a>] call_on_irq_stack+0x32/0x40
>>
>> Rebased on Ryo Takakura's "RISC-V: Enable IPI CPU Backtrace" patch.
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/riscv/kernel/smp.c | 27 +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
>> index 9b047899791c..c180a647a30e 100644
>> --- a/arch/riscv/kernel/smp.c
>> +++ b/arch/riscv/kernel/smp.c
>> @@ -13,6 +13,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/module.h>
>> #include <linux/kexec.h>
>> +#include <linux/kgdb.h>
>> #include <linux/percpu.h>
>> #include <linux/profile.h>
>> #include <linux/smp.h>
>> @@ -35,6 +36,7 @@ enum ipi_message_type {
>> IPI_IRQ_WORK,
>> IPI_TIMER,
>> IPI_CPU_BACKTRACE,
>> + IPI_KGDB_ROUNDUP,
>> IPI_MAX
>> };
>>
>> @@ -115,6 +117,7 @@ void arch_irq_work_raise(void)
>>
>> static irqreturn_t handle_IPI(int irq, void *data)
>> {
>> + unsigned int cpu = smp_processor_id();
>> int ipi = irq - ipi_virq_base;
>>
>> switch (ipi) {
>> @@ -128,7 +131,7 @@ static irqreturn_t handle_IPI(int irq, void *data)
>> ipi_stop();
>> break;
>> case IPI_CPU_CRASH_STOP:
>> - ipi_cpu_crash_stop(smp_processor_id(), get_irq_regs());
>> + ipi_cpu_crash_stop(cpu, get_irq_regs());
>> break;
>> case IPI_IRQ_WORK:
>> irq_work_run();
>> @@ -141,8 +144,11 @@ static irqreturn_t handle_IPI(int irq, void *data)
>> case IPI_CPU_BACKTRACE:
>> nmi_cpu_backtrace(get_irq_regs());
>> break;
>> + case IPI_KGDB_ROUNDUP:
>> + kgdb_nmicallback(cpu, get_irq_regs());
>> + break;
>> default:
>> - pr_warn("CPU%d: unhandled IPI%d\n", smp_processor_id(), ipi);
>> + pr_warn("CPU%d: unhandled IPI%d\n", cpu, ipi);
>> break;
>> }
>>
>> @@ -209,6 +215,7 @@ static const char * const ipi_names[] = {
>> [IPI_IRQ_WORK] = "IRQ work interrupts",
>> [IPI_TIMER] = "Timer broadcast interrupts",
>> [IPI_CPU_BACKTRACE] = "CPU backtrace interrupts",
>> + [IPI_KGDB_ROUNDUP] = "KGDB roundup interrupts",
>> };
>>
>> void show_ipi_stats(struct seq_file *p, int prec)
>> @@ -339,3 +346,19 @@ void arch_trigger_cpumask_backtrace(const cpumask_t *mask, int exclude_cpu)
>> {
>> nmi_trigger_cpumask_backtrace(mask, exclude_cpu, riscv_backtrace_ipi);
>> }
>> +
>> +#ifdef CONFIG_KGDB
>> +void kgdb_roundup_cpus(void)
>> +{
>> + int this_cpu = raw_smp_processor_id();
>> + int cpu;
>> +
>> + for_each_online_cpu(cpu) {
>> + /* No need to roundup ourselves */
>> + if (cpu == this_cpu)
>> + continue;
>> +
>> + send_ipi_single(cpu, IPI_KGDB_ROUNDUP);
>> + }
>> +}
>> +#endif
>> --
>> 2.34.1
>>
>
> Other than the commit message, the patch looks good to me, so
>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
>
> but I guess we should extend this and the CPU backtrace support to use
> NMIs when we have support for them.
Yes, arm64 has done what you said, now both CPU Backtrace and KGDB
Roundup on arm64 have swiched to NMI smoothly.
>
> Thanks,
> drew
prev parent reply other threads:[~2024-07-20 7:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-19 8:12 Jinjie Ruan
2024-07-19 15:14 ` Andrew Jones
2024-07-20 7:26 ` Jinjie Ruan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=333494b6-b128-3804-b8f7-03f61dbca9d7@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samuel.holland@sifive.com \
--cc=takakura@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®