From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v26 2/7] arm64: kdump: implement machine_crash_shutdown()
Date: Tue, 20 Sep 2016 16:36:35 +0900 [thread overview]
Message-ID: <20160920073634.GC30248@linaro.org> (raw)
In-Reply-To: <57DC067B.3050003@arm.com>
On Fri, Sep 16, 2016 at 03:49:31PM +0100, James Morse wrote:
> On 16/09/16 04:21, AKASHI Takahiro wrote:
> > On Wed, Sep 14, 2016 at 07:09:33PM +0100, James Morse wrote:
> >> On 07/09/16 05:29, AKASHI Takahiro wrote:
> >>> Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus
> >>> and save registers' status in per-cpu ELF notes before starting crash
> >>> dump kernel. See kernel_kexec().
> >>> Even if not all secondary cpus have shut down, we do kdump anyway.
> >>>
> >>> As we don't have to make non-boot(crashed) cpus offline (to preserve
> >>> correct status of cpus at crash dump) before shutting down, this patch
> >>> also adds a variant of smp_send_stop().
>
> >>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> >>> index 04744dc..a908958 100644
> >>> --- a/arch/arm64/include/asm/kexec.h
> >>> +++ b/arch/arm64/include/asm/kexec.h
> >>> @@ -40,7 +40,46 @@
> >>> static inline void crash_setup_regs(struct pt_regs *newregs,
> >>> struct pt_regs *oldregs)
> >>> {
> >>> - /* Empty routine needed to avoid build errors. */
> >>> + if (oldregs) {
> >>> + memcpy(newregs, oldregs, sizeof(*newregs));
> >>> + } else {
> >>> + u64 tmp1, tmp2;
> >>> +
> >>> + __asm__ __volatile__ (
> >>> + "stp x0, x1, [%2, #16 * 0]\n"
> >>> + "stp x2, x3, [%2, #16 * 1]\n"
> >>> + "stp x4, x5, [%2, #16 * 2]\n"
> >>> + "stp x6, x7, [%2, #16 * 3]\n"
> >>> + "stp x8, x9, [%2, #16 * 4]\n"
> >>> + "stp x10, x11, [%2, #16 * 5]\n"
> >>> + "stp x12, x13, [%2, #16 * 6]\n"
> >>> + "stp x14, x15, [%2, #16 * 7]\n"
> >>> + "stp x16, x17, [%2, #16 * 8]\n"
> >>> + "stp x18, x19, [%2, #16 * 9]\n"
> >>> + "stp x20, x21, [%2, #16 * 10]\n"
> >>> + "stp x22, x23, [%2, #16 * 11]\n"
> >>> + "stp x24, x25, [%2, #16 * 12]\n"
> >>> + "stp x26, x27, [%2, #16 * 13]\n"
> >>> + "stp x28, x29, [%2, #16 * 14]\n"
> >>> + "mov %0, sp\n"
> >>> + "stp x30, %0, [%2, #16 * 15]\n"
> >>> +
> >>> + "/* faked current PSTATE */\n"
> >>> + "mrs %0, CurrentEL\n"
> >>> + "mrs %1, DAIF\n"
> >>> + "orr %0, %0, %1\n"
> >>> + "mrs %1, NZCV\n"
> >>> + "orr %0, %0, %1\n"
> >>> +
> >>
> >> What about SPSEL? While we don't use it, it is correctly preserved for
> >> everything except a CPU that calls panic()...
> >
> > My comment above might be confusing, but what I want to fake
> > here is "spsr" as pt_regs.pstate is normally set based on spsr_el1.
> > So there is no corresponding field of SPSEL in spsr.
>
> Here is my logic, I may have missed something obvious, see what you think:
>
> SPSR_EL{1,2} shows the CPU mode 'M' in bits 0-4, From aarch64 bit 4 is always 0.
> From the register definitions in the ARM-ARM C5.2, likely values in 0-3 are:
> 0100 EL1t
> 0101 EL1h
> 1000 EL2t
> 1001 EL2h
>
> I'm pretty sure this least significant bit is what SPSEL changes, so it does get
> implicitly recorded in SPSR.
> CurrentEL returns a value in bits 0-3, of which 0-1 are RES0, so we lose the
> difference between EL?t and EL?h.
OK.
SPSel will be added assuming that CurrentEL is never 0 here.
>
> >
> >>
> >>> + /* pc */
> >>> + "adr %1, 1f\n"
> >>> + "1:\n"
> >>> + "stp %1, %0, [%2, #16 * 16]\n"
> >>> + : "=r" (tmp1), "=r" (tmp2), "+r" (newregs)
> >>> + :
> >>> + : "memory"
>
> Do you need the memory clobber? This asm only modifies values in newregs.
What about this (including the change above):
| "/* faked current PSTATE */\n"
| "mrs %0, CurrentEL\n"
| "mrs %1, SPSEL\n"
| "orr %0, %0, %1\n"
| "mrs %1, DAIF\n"
| "orr %0, %0, %1\n"
| "mrs %1, NZCV\n"
| "orr %0, %0, %1\n"
| /* pc */
| "adr %1, 1f\n"
| "1:\n"
| "stp %1, %0, [%2, #16 * 16]\n"
| : "+r" (tmp1), "+r" (tmp2)
| : "r" (newregs)
| : "memory"
>
> >>> + );
> >>> + }
> >>> }
> >>>
> >>> #endif /* __ASSEMBLY__ */
>
>
> >>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>
> >>> +#ifdef CONFIG_KEXEC_CORE
> >>> +void smp_send_crash_stop(void)
> >>> +{
> >>> + cpumask_t mask;
> >>> + unsigned long timeout;
> >>> +
> >>> + if (num_online_cpus() == 1)
> >>> + return;
> >>> +
> >>> + cpumask_copy(&mask, cpu_online_mask);
> >>> + cpumask_clear_cpu(smp_processor_id(), &mask);
> >>> +
> >>> + atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
> >>> +
> >>> + pr_crit("SMP: stopping secondary CPUs\n");
> >>> + smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
> >>> +
> >>> + /* Wait up to one second for other CPUs to stop */
> >>> + timeout = USEC_PER_SEC;
> >>> + while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
> >>> + udelay(1);
> >>> +
> >>> + if (atomic_read(&waiting_for_crash_ipi) > 0)
> >>> + pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
> >>> + cpumask_pr_args(cpu_online_mask));
> >>> +}
> >>> +#endif
> >>
> >> This is very similar to smp_send_stop() which also has the timeout. Is it
> >> possible to merge them? You could use in_crash_kexec to choose the IPI type.
> >
> > Yeah, we could merge them along with ipi_cpu_(crash_)stop().
> > But the resulting code would be quite noisy if each line
> > is switched by "if (in_crash_kexec)."
> > Otherwise, we may have one big "if" like:
> > void smp_send_stop(void)
> > {
> > if (in_crash_kexec)
> > ...
> > else
> > ...
> > }
> > It seems to me that it is not much different from the current code.
> > What do you think?
>
> Hmm, yes, its too fiddly to keep the existing behaviour of both.
>
> The problems are ipi_cpu_stop() doesn't call cpu_die(), (I can't see a good
> reason for this, but more archaeology is needed), and ipi_cpu_crash_stop()
> doesn't modify the online cpu mask.
>
> I don't suggest we do this yet, but it could be future cleanup if it's proved to
> be safe:
> smp_send_stop() is only called from: machine_halt(), machine_power_off(),
> machine_restart() and panic(). In all those cases the CPUs are never expected to
> come back, so we can probably merge the IPIs. This involves modifying the
> online cpu mask during kdump, (which I think is fine as it uses the atomic
> bitops so we won't get blocked on a lock), and promoting in_crash_kexec to some
> atomic type.
>
> But I think we should leave it as it is for now,
Sure.
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
next prev parent reply other threads:[~2016-09-20 7:36 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 4:29 [PATCH v26 0/7] arm64: add kdump support AKASHI Takahiro
2016-09-07 4:29 ` [PATCH v26 1/7] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-09-22 10:23 ` Matthias Bruger
2016-09-23 8:37 ` AKASHI Takahiro
2016-09-07 4:29 ` [PATCH v26 2/7] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2016-09-14 18:09 ` James Morse
2016-09-15 8:13 ` Marc Zyngier
2016-09-16 3:21 ` AKASHI Takahiro
2016-09-16 14:49 ` James Morse
2016-09-20 7:36 ` AKASHI Takahiro [this message]
2016-09-07 4:29 ` [PATCH v26 3/7] arm64: kdump: add kdump support AKASHI Takahiro
2016-09-16 14:50 ` James Morse
2016-09-20 7:46 ` AKASHI Takahiro
2016-09-22 15:50 ` Matthias Brugger
2016-09-07 4:29 ` [PATCH v26 4/7] arm64: kdump: add VMCOREINFO's for user-space coredump tools AKASHI Takahiro
2016-09-16 16:04 ` James Morse
2016-09-07 4:29 ` [PATCH v26 5/7] arm64: kdump: enable kdump in the arm64 defconfig AKASHI Takahiro
2016-09-07 4:29 ` [PATCH v26 6/7] arm64: kdump: update a kernel doc AKASHI Takahiro
2016-09-16 16:08 ` James Morse
2016-09-20 8:27 ` AKASHI Takahiro
2016-09-26 17:21 ` Matthias Brugger
2016-09-07 4:32 ` [PATCH v26 7/7] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-09-16 13:03 ` Rob Herring
2016-09-07 4:37 ` [PATCH v26 0/7] arm64: add kdump support AKASHI Takahiro
2016-09-16 16:04 ` James Morse
2016-09-16 20:17 ` Ard Biesheuvel
2016-09-19 16:05 ` James Morse
2016-09-19 16:10 ` Ard Biesheuvel
2016-09-21 7:42 ` AKASHI Takahiro
2016-09-21 7:33 ` AKASHI Takahiro
2016-10-03 7:54 ` Manish Jaggi
2016-10-03 11:04 ` AKASHI Takahiro
2016-10-03 12:41 ` Manish Jaggi
2016-10-04 2:56 ` AKASHI Takahiro
2016-10-04 9:46 ` James Morse
2016-10-04 10:05 ` Manish Jaggi
2016-10-04 10:53 ` James Morse
2016-10-04 13:23 ` Manish Jaggi
2016-10-05 5:48 ` AKASHI Takahiro
2016-10-05 5:41 ` AKASHI Takahiro
2016-10-04 10:18 ` Mark Rutland
2016-10-17 15:41 ` Ruslan Bilovol
2016-10-18 6:26 ` AKASHI Takahiro
2016-11-01 12:19 ` Ruslan Bilovol
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=20160920073634.GC30248@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).