| Message ID | cover.1466702804.git.geoff@infradead.org |
|---|---|
| State | New |
| Headers | show |
Hi On 23/06/16 18:54, Geoff Levand wrote: > From: James Morse <james.morse@arm.com> > > Hibernate relies on cpu hotplug to prevent secondary cores executing > the kernel text while it is being restored. > > Add a call to cpus_are_stuck_in_kernel() to determine if there are > CPUs not counted by 'num_online_cpus()', and prevent hibernate in this > case. > > Fixes: 82869ac57b5 ("arm64: kernel: Add support for hibernate/suspend-to-disk") > Signed-off-by: James Morse <james.morse@arm.com> > --- > arch/arm64/kernel/hibernate.c | 6 ++++++ > 1 file changed, 6 insertions(+) ... this patch isn't necessary for kexec, it wired up the helper function you have in patch 2 for hibernate. Please drop this in any future posting! Thanks, James
Hi Geoff, On 23/06/16 18:54, Geoff Levand wrote: > Add three new files, kexec.h, machine_kexec.c and relocate_kernel.S to the > arm64 architecture that add support for the kexec re-boot mechanism > (CONFIG_KEXEC) on arm64 platforms. > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c > new file mode 100644 > index 0000000..e2904c4 > --- /dev/null > +++ b/arch/arm64/kernel/machine_kexec.c > +/** > + * machine_kexec_prepare - Prepare for a kexec reboot. > + * > + * Called from the core kexec code when a kernel image is loaded. > + * Forbid loading a kexec kernel if we have no way of hotplugging cpus or cpus > + * are stuck in the kernel. This avoids a panic once we hit machine_kexec(). > + */ > +int machine_kexec_prepare(struct kimage *kimage) > +{ > + kimage_start = kimage->start; > + > + if (kimage->type != KEXEC_TYPE_CRASH) { > + if (cpus_are_stuck_in_kernel()) { > + pr_err("Can't kexec: failed CPUs are stuck in the kernel.\n"); We may want to change the word 'failed' here, the helper function now also covers systems that boot secondary processors with spin tables that are stuck in the secondary_holding_pen: > "Can't kexec: secondary CPUs are stuck in the kernel.\n" > + return -EBUSY; > + } > + > + if (num_online_cpus() > 1) { > + if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) { > + /* any_cpu as we don't mind being preempted */ > + int any_cpu = raw_smp_processor_id(); > + > + if (cpu_ops[any_cpu]->cpu_die) > + return 0; > + } > + > + pr_err("Can't kexec: no mechanism to offline secondary CPUs.\n"); > + return -EBUSY; > + } This if() {} hunk isn't necessary with the version of cpus_are_stuck_in_kernel() you have in patch 2. This logic is the '|| smp_spin_tables' part of that helper function. (hibernate needed it too) > + } > + > + return 0; > +} > + [ ... ] > +/** > + * machine_kexec - Do the kexec reboot. > + * > + * Called from the core kexec code for a sys_reboot with LINUX_REBOOT_CMD_KEXEC. > + */ > +void machine_kexec(struct kimage *kimage) > +{ > + phys_addr_t reboot_code_buffer_phys; > + void *reboot_code_buffer; > + > + /* > + * New cpus may have become stuck_in_kernel after we loaded the image. > + */ > + BUG_ON(cpus_are_stuck_in_kernel() && (num_online_cpus() > 1)); BUG_ON(cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)); Thanks, James
Hi Catalin, On 27/06/16 15:39, Catalin Marinas wrote: > On Mon, Jun 27, 2016 at 12:18:42PM +0100, James Morse wrote: >> This if() {} hunk isn't necessary with the version of cpus_are_stuck_in_kernel() >> you have in patch 2. This logic is the '|| smp_spin_tables' part of that helper >> function. (hibernate needed it too) > > I can make the changes locally but just to be clear I understand what > you meant, here's the diff on top of Geoff's patch: Ah, I see my 'if() {}' comment is ambiguous as there are two ... > > ----8<------------------------- > > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c > index 945ce326654c..bc96c8a7fc79 100644 > --- a/arch/arm64/kernel/machine_kexec.c > +++ b/arch/arm64/kernel/machine_kexec.c > @@ -68,24 +68,9 @@ int machine_kexec_prepare(struct kimage *kimage) > > kexec_image_info(kimage); > > - if (kimage->type != KEXEC_TYPE_CRASH) { > - if (cpus_are_stuck_in_kernel()) { > - pr_err("Can't kexec: failed CPUs are stuck in the kernel.\n"); > - return -EBUSY; > - } > - > - if (num_online_cpus() > 1) { > - if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) { > - /* any_cpu as we don't mind being preempted */ > - int any_cpu = raw_smp_processor_id(); > - > - if (cpu_ops[any_cpu]->cpu_die) > - return 0; > - } > - > - pr_err("Can't kexec: no mechanism to offline secondary CPUs.\n"); > - return -EBUSY; > - } > + if (kimage->type != KEXEC_TYPE_CRASH && cpus_are_stuck_in_kernel()) { > + pr_err("Can't kexec: CPUs are stuck in the kernel.\n"); > + return -EBUSY; > } > > return 0; > @@ -163,7 +148,7 @@ void machine_kexec(struct kimage *kimage) > /* > * New cpus may have become stuck_in_kernel after we loaded the image. > */ > - BUG_ON(cpus_are_stuck_in_kernel() && (num_online_cpus() > 1)); > + BUG_ON(cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)); > > reboot_code_buffer_phys = page_to_phys(kimage->control_code_page); > reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys); > Yes, that's what I meant, thanks Catalin. The 'num_online_cpus() > 1' is still needed as disable_nonboot_cpus() called via machine_shutdown() may have failed and this is where we check. (we can't return an error from either path). Geoff, I assume you agree? Thanks, James
Hi, On Mon, 2016-06-27 at 12:04 +0100, James Morse wrote: > ... this patch isn't necessary for kexec, it wired up the helper > function you > have in patch 2 for hibernate. > > Please drop this in any future posting! It seems both your patches I had went in for -rc5, so they're gone now from my master. -Geoff
Hi, On Mon, 2016-06-27 at 17:29 +0100, James Morse wrote: > On 27/06/16 15:39, Catalin Marinas wrote: > > @@ -163,7 +148,7 @@ void machine_kexec(struct kimage *kimage) > > > > > > /* > > > > > > * New cpus may have become stuck_in_kernel after we loaded the image. > > > > > > */ > > -> > > > BUG_ON(cpus_are_stuck_in_kernel() && (num_online_cpus() > 1)); > > +> > > > BUG_ON(cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)); > > > > > > > > reboot_code_buffer_phys = page_to_phys(kimage->control_code_page); > > > > > > reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys); > > > > Yes, that's what I meant, thanks Catalin. > > The 'num_online_cpus() > 1' is still needed as disable_nonboot_cpus() called via > machine_shutdown() may have failed and this is where we check. (we can't return > an error from either path). > > Geoff, I assume you agree? Yes, we should do a final check, and abort the reboot if if we have more than a single cpu running. -Geoff
Hi Geoff, On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > AKASHI Takahiro (7): > arm64: kdump: reserve memory for crash dump kernel > arm64: limit memory regions based on DT property, usable-memory > arm64: kdump: implement machine_crash_shutdown() > arm64: kdump: add kdump support > arm64: kdump: add VMCOREINFO's for user-space coredump tools > arm64: kdump: enable kdump in the arm64 defconfig > arm64: kdump: update a kernel doc > > Geoff Levand (4): > arm64: Add back cpu reset routines > arm64/kexec: Add core kexec support > arm64/kexec: Enable kexec in the arm64 defconfig > arm64/kexec: Add pr_debug output > > James Morse (3): > arm64: hibernate: Don't hibernate on systems with stuck CPUs > arm64: smp: Add function to determine if cpus are stuck in the kernel > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and merged patches 3-6, with the amendments that James mentioned. The kdump patches, including the "Documentation" one from James require more review, testing and acks by the corresponding maintainers (kdump, DT). You also don't seem to have added a s-o-b for those patches (since you are submitting them; unless you plan to let Akashi-san submit them in the future). Thanks.
Hi Catalin, On Mon, 2016-06-27 at 18:00 +0100, Catalin Marinas wrote: > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > AKASHI Takahiro (7): > > arm64: kdump: reserve memory for crash dump kernel > > arm64: limit memory regions based on DT property, usable-memory > > arm64: kdump: implement machine_crash_shutdown() > > arm64: kdump: add kdump support > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > arm64: kdump: enable kdump in the arm64 defconfig > > arm64: kdump: update a kernel doc > > > > Geoff Levand (4): > > arm64: Add back cpu reset routines > > arm64/kexec: Add core kexec support > > arm64/kexec: Enable kexec in the arm64 defconfig > > arm64/kexec: Add pr_debug output > > > > James Morse (3): > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > merged patches 3-6, with the amendments that James mentioned. > > The kdump patches, including the "Documentation" one from James require > more review, testing and acks by the corresponding maintainers (kdump, > DT). You also don't seem to have added a s-o-b for those patches (since > you are submitting them; unless you plan to let Akashi-san submit them > in the future). I'll workout the merge plan for the rest of the patches with Takahiro. If they come through me I'll add an SOB. Thanks for the review. -Geoff
Hi Catalin, On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > Hi Geoff, > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > AKASHI Takahiro (7): > > arm64: kdump: reserve memory for crash dump kernel > > arm64: limit memory regions based on DT property, usable-memory > > arm64: kdump: implement machine_crash_shutdown() > > arm64: kdump: add kdump support > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > arm64: kdump: enable kdump in the arm64 defconfig > > arm64: kdump: update a kernel doc > > > > Geoff Levand (4): > > arm64: Add back cpu reset routines > > arm64/kexec: Add core kexec support > > arm64/kexec: Enable kexec in the arm64 defconfig > > arm64/kexec: Add pr_debug output > > > > James Morse (3): > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > merged patches 3-6, with the amendments that James mentioned. > > The kdump patches, including the "Documentation" one from James require > more review, testing and acks by the corresponding maintainers (kdump, > DT). I see what you mean, but even for Geoff's kexec part, the maintainer (Eric) have not given his ack. > You also don't seem to have added a s-o-b for those patches (since > you are submitting them; unless you plan to let Akashi-san submit them > in the future). Basically Geoff has not reviewed nor tested kdump part, and so I'm not sure that adding his s-o-b is appropriate. Anyhow, I will post my future version of kdump by myself as kexec has been queued in for-next/core. Thanks, -Takahiro AKASHI > Thanks. > > -- > Catalin
On Wed, Jun 29, 2016 at 09:54:15AM +0900, AKASHI Takahiro wrote: > On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > > AKASHI Takahiro (7): > > > arm64: kdump: reserve memory for crash dump kernel > > > arm64: limit memory regions based on DT property, usable-memory > > > arm64: kdump: implement machine_crash_shutdown() > > > arm64: kdump: add kdump support > > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > > arm64: kdump: enable kdump in the arm64 defconfig > > > arm64: kdump: update a kernel doc > > > > > > Geoff Levand (4): > > > arm64: Add back cpu reset routines > > > arm64/kexec: Add core kexec support > > > arm64/kexec: Enable kexec in the arm64 defconfig > > > arm64/kexec: Add pr_debug output > > > > > > James Morse (3): > > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > > merged patches 3-6, with the amendments that James mentioned. > > > > The kdump patches, including the "Documentation" one from James require > > more review, testing and acks by the corresponding maintainers (kdump, > > DT). > > I see what you mean, but even for Geoff's kexec part, the maintainer > (Eric) have not given his ack. I just assumed he won't object ;). The only generic change is the KEXEC_ARCH_AARCH64 in the uapi/linux/kexec.h file and the value chosen matches EM_AARCH64. The kdump patches make such changes to Documentation and I would like those acked by the kdump and DT maintainers. Pratyush Anand also had comments on the kdump patches in v19, so it's fair to wait for him to complete the reviewing of the latest series. > > You also don't seem to have added a s-o-b for those patches (since > > you are submitting them; unless you plan to let Akashi-san submit them > > in the future). > > Basically Geoff has not reviewed nor tested kdump part, and > so I'm not sure that adding his s-o-b is appropriate. It is appropriate. See the "Developer's Certificate of Origin" in Documentation/SubmittingPatches. A s-o-b from Geoff doesn't necessarily mean that he reviewed the patches but that he has the right to pass them on under the open source license indicated in the file (and AFAICT it is legally binding but IANAL). > Anyhow, I will post my future version of kdump by myself as kexec has > been queued in for-next/core. Thanks.
On Wed, Jun 29, 2016 at 10:20:50AM +0100, Catalin Marinas wrote: > On Wed, Jun 29, 2016 at 09:54:15AM +0900, AKASHI Takahiro wrote: > > On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > > > AKASHI Takahiro (7): > > > > arm64: kdump: reserve memory for crash dump kernel > > > > arm64: limit memory regions based on DT property, usable-memory > > > > arm64: kdump: implement machine_crash_shutdown() > > > > arm64: kdump: add kdump support > > > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > > > arm64: kdump: enable kdump in the arm64 defconfig > > > > arm64: kdump: update a kernel doc > > > > > > > > Geoff Levand (4): > > > > arm64: Add back cpu reset routines > > > > arm64/kexec: Add core kexec support > > > > arm64/kexec: Enable kexec in the arm64 defconfig > > > > arm64/kexec: Add pr_debug output > > > > > > > > James Morse (3): > > > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > > > > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > > > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > > > merged patches 3-6, with the amendments that James mentioned. > > > > > > The kdump patches, including the "Documentation" one from James require > > > more review, testing and acks by the corresponding maintainers (kdump, > > > DT). > > > > I see what you mean, but even for Geoff's kexec part, the maintainer > > (Eric) have not given his ack. > > I just assumed he won't object ;). The only generic change is the > KEXEC_ARCH_AARCH64 in the uapi/linux/kexec.h file and the value chosen > matches EM_AARCH64. > > The kdump patches make such changes to Documentation and I would like > those acked by the kdump and DT maintainers. OK, I asked the corresponding maintainers to review them. > Pratyush Anand also had comments on the kdump patches in v19, so it's > fair to wait for him to complete the reviewing of the latest series. I think that it was my mistake that I referred to makedumpfile-related VMCOREINFO's in my patch. Since I'm not a user nor author of makedumpfile command for arm64, my changes should have been minimized, exluding any non-mandatory symbols. (Patch#13/14 is necessary for me to verify generated vmcore files with crash utility.) So I asked Pratyush to post his kernel patch based on his own requirements as he wants. I believe it's fair enough. > > > You also don't seem to have added a s-o-b for those patches (since > > > you are submitting them; unless you plan to let Akashi-san submit them > > > in the future). > > > > Basically Geoff has not reviewed nor tested kdump part, and > > so I'm not sure that adding his s-o-b is appropriate. > > It is appropriate. See the "Developer's Certificate of Origin" in > Documentation/SubmittingPatches. A s-o-b from Geoff doesn't necessarily > mean that he reviewed the patches but that he has the right to pass them > on under the open source license indicated in the file (and AFAICT it is > legally binding but IANAL). > > > Anyhow, I will post my future version of kdump by myself as kexec has > > been queued in for-next/core. > > Thanks. Since I've got no comments on kdump patches and had no updates so far, I don't plan to post v21 this week (at this point). (I will add "reviewed-by James" to patch#7/14 in future releases.) Thanks, -Takahiro AKASHI > -- > Catalin
On 06/23/16 at 05:54pm, Geoff Levand wrote: > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > This patch adds arch specific descriptions about kdump usage on arm64 > to kdump.txt. > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > --- > Documentation/kdump/kdump.txt | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > index 88ff63d..5d6da09 100644 > --- a/Documentation/kdump/kdump.txt > +++ b/Documentation/kdump/kdump.txt > @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > a remote system. > > Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > -s390x and arm architectures. > +s390x, arm and arm64 architectures. > > When the system kernel boots, it reserves a small section of memory for > the dump-capture kernel. This ensures that ongoing Direct Memory Access > @@ -249,6 +249,12 @@ Dump-capture kernel config options (Arch Dependent, arm) > > AUTO_ZRELADDR=y > > +Dump-capture kernel config options (Arch Dependent, arm64) > +---------------------------------------------------------- > + > +1) Currently, kvm will not be enabled on the dump-capture kernel even > + if it is configured. > + > Extended crashkernel syntax > =========================== > > @@ -305,6 +311,8 @@ Boot into System Kernel > kernel will automatically locate the crash kernel image within the > first 512MB of RAM if X is not given. > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of ~ Why square brackets here, is it different than other arch? Except for this, it looks good to me. Thanks Baoquan > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > Load the Dump-capture Kernel > ============================ > @@ -327,6 +335,8 @@ For s390x: > - Use image or bzImage > For arm: > - Use zImage > +For arm64: > + - Use vmlinux or Image > > If you are using a uncompressed vmlinux image then use following command > to load dump-capture kernel. > @@ -370,6 +380,9 @@ For s390x: > For arm: > "1 maxcpus=1 reset_devices" > > +For arm64: > + "1 maxcpus=1 reset_devices" > + > Notes on loading the dump-capture kernel: > > * By default, the ELF headers are stored in ELF64 format to support > -- > 2.5.0 > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
On 06/23/16 at 05:54pm, Geoff Levand wrote: > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > This patch adds arch specific descriptions about kdump usage on arm64 > to kdump.txt. > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > --- > Documentation/kdump/kdump.txt | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > index 88ff63d..5d6da09 100644 > --- a/Documentation/kdump/kdump.txt > +++ b/Documentation/kdump/kdump.txt > @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > a remote system. > > Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > -s390x and arm architectures. > +s390x, arm and arm64 architectures. > > When the system kernel boots, it reserves a small section of memory for > the dump-capture kernel. This ensures that ongoing Direct Memory Access > @@ -249,6 +249,12 @@ Dump-capture kernel config options (Arch Dependent, arm) > > AUTO_ZRELADDR=y > > +Dump-capture kernel config options (Arch Dependent, arm64) > +---------------------------------------------------------- > + > +1) Currently, kvm will not be enabled on the dump-capture kernel even > + if it is configured. > + > Extended crashkernel syntax > =========================== > > @@ -305,6 +311,8 @@ Boot into System Kernel > kernel will automatically locate the crash kernel image within the > first 512MB of RAM if X is not given. > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > Load the Dump-capture Kernel > ============================ > @@ -327,6 +335,8 @@ For s390x: > - Use image or bzImage > For arm: > - Use zImage > +For arm64: > + - Use vmlinux or Image > > If you are using a uncompressed vmlinux image then use following command > to load dump-capture kernel. > @@ -370,6 +380,9 @@ For s390x: > For arm: > "1 maxcpus=1 reset_devices" > > +For arm64: > + "1 maxcpus=1 reset_devices" > + > Notes on loading the dump-capture kernel: > > * By default, the ELF headers are stored in ELF64 format to support Looks good to me. Acked-by: Dave Young <dyoung@redhat.com> Thanks Dave
Hi Takahiro, On 30/06/2016:10:46:04 AM, AKASHI Takahiro wrote: > On Wed, Jun 29, 2016 at 10:20:50AM +0100, Catalin Marinas wrote: > > On Wed, Jun 29, 2016 at 09:54:15AM +0900, AKASHI Takahiro wrote: > > > On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > > > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > > > > AKASHI Takahiro (7): > > > > > arm64: kdump: reserve memory for crash dump kernel > > > > > arm64: limit memory regions based on DT property, usable-memory > > > > > arm64: kdump: implement machine_crash_shutdown() > > > > > arm64: kdump: add kdump support > > > > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > > > > arm64: kdump: enable kdump in the arm64 defconfig > > > > > arm64: kdump: update a kernel doc > > > > > > > > > > Geoff Levand (4): > > > > > arm64: Add back cpu reset routines > > > > > arm64/kexec: Add core kexec support > > > > > arm64/kexec: Enable kexec in the arm64 defconfig > > > > > arm64/kexec: Add pr_debug output > > > > > > > > > > James Morse (3): > > > > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > > > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > > > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > > > > > > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > > > > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > > > > merged patches 3-6, with the amendments that James mentioned. > > > > > > > > The kdump patches, including the "Documentation" one from James require > > > > more review, testing and acks by the corresponding maintainers (kdump, > > > > DT). > > > > > > I see what you mean, but even for Geoff's kexec part, the maintainer > > > (Eric) have not given his ack. > > > > I just assumed he won't object ;). The only generic change is the > > KEXEC_ARCH_AARCH64 in the uapi/linux/kexec.h file and the value chosen > > matches EM_AARCH64. > > > > The kdump patches make such changes to Documentation and I would like > > those acked by the kdump and DT maintainers. > > OK, I asked the corresponding maintainers to review them. > > > Pratyush Anand also had comments on the kdump patches in v19, so it's > > fair to wait for him to complete the reviewing of the latest series. > > I think that it was my mistake that I referred to makedumpfile-related > VMCOREINFO's in my patch. > Since I'm not a user nor author of makedumpfile command for arm64, > my changes should have been minimized, exluding any non-mandatory symbols. > (Patch#13/14 is necessary for me to verify generated vmcore files > with crash utility.) > So I asked Pratyush to post his kernel patch based on his own requirements > as he wants. > I believe it's fair enough. Sorry for delayed response. I am agreeing to this patchset. makedumpfile would also be able to work by directly reading page table entries for all virtual addresses. I have tested this patchset with Mustang and both kexec and kdump works. So, you can add Tested-by: Pratyush Anand <panand@redhat.com> Thanks for all the work on kexec/kdump. ~Pratyush > > > > > You also don't seem to have added a s-o-b for those patches (since > > > > you are submitting them; unless you plan to let Akashi-san submit them > > > > in the future). > > > > > > Basically Geoff has not reviewed nor tested kdump part, and > > > so I'm not sure that adding his s-o-b is appropriate. > > > > It is appropriate. See the "Developer's Certificate of Origin" in > > Documentation/SubmittingPatches. A s-o-b from Geoff doesn't necessarily > > mean that he reviewed the patches but that he has the right to pass them > > on under the open source license indicated in the file (and AFAICT it is > > legally binding but IANAL). > > > > > Anyhow, I will post my future version of kdump by myself as kexec has > > > been queued in for-next/core. > > > > Thanks. > > Since I've got no comments on kdump patches and had no updates > so far, I don't plan to post v21 this week (at this point). > (I will add "reviewed-by James" to patch#7/14 in future releases.) > > Thanks, > -Takahiro AKASHI > > > -- > > Catalin > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Dave, Boaquan, Thank you for your reviewing. On Thu, Jun 30, 2016 at 05:00:45PM +0800, Baoquan He wrote: > On 06/23/16 at 05:54pm, Geoff Levand wrote: > > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > > This patch adds arch specific descriptions about kdump usage on arm64 > > to kdump.txt. > > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > --- > > Documentation/kdump/kdump.txt | 15 ++++++++++++++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > index 88ff63d..5d6da09 100644 > > --- a/Documentation/kdump/kdump.txt > > +++ b/Documentation/kdump/kdump.txt > > @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > > a remote system. > > > > Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > > -s390x and arm architectures. > > +s390x, arm and arm64 architectures. > > > > When the system kernel boots, it reserves a small section of memory for > > the dump-capture kernel. This ensures that ongoing Direct Memory Access > > @@ -249,6 +249,12 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > > AUTO_ZRELADDR=y > > > > +Dump-capture kernel config options (Arch Dependent, arm64) > > +---------------------------------------------------------- > > + > > +1) Currently, kvm will not be enabled on the dump-capture kernel even > > + if it is configured. > > + > > Extended crashkernel syntax > > =========================== > > > > @@ -305,6 +311,8 @@ Boot into System Kernel > > kernel will automatically locate the crash kernel image within the > > first 512MB of RAM if X is not given. > > > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > ~ Why square brackets here, is it > different than other arch? I want to clearly indicate that "@X" is optional, and that, when you explicitly specify it, X must be properly aligned. I think that "[..]" notation is quite common. Thanks, -Takahiro AKASHI > > Except for this, it looks good to me. > > Thanks > Baoquan > > > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > > > Load the Dump-capture Kernel > > ============================ > > @@ -327,6 +335,8 @@ For s390x: > > - Use image or bzImage > > For arm: > > - Use zImage > > +For arm64: > > + - Use vmlinux or Image > > > > If you are using a uncompressed vmlinux image then use following command > > to load dump-capture kernel. > > @@ -370,6 +380,9 @@ For s390x: > > For arm: > > "1 maxcpus=1 reset_devices" > > > > +For arm64: > > + "1 maxcpus=1 reset_devices" > > + > > Notes on loading the dump-capture kernel: > > > > * By default, the ELF headers are stored in ELF64 format to support > > -- > > 2.5.0 > > > > > > > > _______________________________________________ > > kexec mailing list > > kexec@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec
On 07/01/16 at 04:37pm, AKASHI Takahiro wrote: > Dave, Boaquan, > > Thank you for your reviewing. > > On Thu, Jun 30, 2016 at 05:00:45PM +0800, Baoquan He wrote: > > On 06/23/16 at 05:54pm, Geoff Levand wrote: > > > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > > > > This patch adds arch specific descriptions about kdump usage on arm64 > > > to kdump.txt. > > > > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > --- > > > Documentation/kdump/kdump.txt | 15 ++++++++++++++- > > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > > index 88ff63d..5d6da09 100644 > > > --- a/Documentation/kdump/kdump.txt > > > +++ b/Documentation/kdump/kdump.txt > > > @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > > > a remote system. > > > > > > Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > > > -s390x and arm architectures. > > > +s390x, arm and arm64 architectures. > > > > > > When the system kernel boots, it reserves a small section of memory for > > > the dump-capture kernel. This ensures that ongoing Direct Memory Access > > > @@ -249,6 +249,12 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > > > > AUTO_ZRELADDR=y > > > > > > +Dump-capture kernel config options (Arch Dependent, arm64) > > > +---------------------------------------------------------- > > > + > > > +1) Currently, kvm will not be enabled on the dump-capture kernel even > > > + if it is configured. And here, could you say more about it? > > > + > > > Extended crashkernel syntax > > > =========================== > > > > > > @@ -305,6 +311,8 @@ Boot into System Kernel > > > kernel will automatically locate the crash kernel image within the > > > first 512MB of RAM if X is not given. > > > > > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > > ~ Why square brackets here, is it > > different than other arch? > > I want to clearly indicate that "@X" is optional, and that, when you explicitly > specify it, X must be properly aligned. > I think that "[..]" notation is quite common. Yes, I see that. Just that has been noted in "Extended crashkernel syntax" section, and adding "[]" is not consistent with other places where "crashkernel=Y@X" is referred to in this section. Just feel it's a little redundent. Anyway it's not very critical, and Dave has acked it, I am fine if you want to keep it. Thanks Baoquan > > Thanks, > -Takahiro AKASHI > > > > > Except for this, it looks good to me. > > > > Thanks > > Baoquan > > > > > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > > > > > Load the Dump-capture Kernel > > > ============================ > > > @@ -327,6 +335,8 @@ For s390x: > > > - Use image or bzImage > > > For arm: > > > - Use zImage > > > +For arm64: > > > + - Use vmlinux or Image > > > > > > If you are using a uncompressed vmlinux image then use following command > > > to load dump-capture kernel. > > > @@ -370,6 +380,9 @@ For s390x: > > > For arm: > > > "1 maxcpus=1 reset_devices" > > > > > > +For arm64: > > > + "1 maxcpus=1 reset_devices" > > > + > > > Notes on loading the dump-capture kernel: > > > > > > * By default, the ELF headers are stored in ELF64 format to support > > > -- > > > 2.5.0 > > > > > > > > > > > > _______________________________________________ > > > kexec mailing list > > > kexec@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/kexec
Baoquan, On Fri, Jul 01, 2016 at 03:45:05PM +0800, Baoquan He wrote: > On 07/01/16 at 04:37pm, AKASHI Takahiro wrote: > > Dave, Boaquan, > > > > Thank you for your reviewing. > > > > On Thu, Jun 30, 2016 at 05:00:45PM +0800, Baoquan He wrote: > > > On 06/23/16 at 05:54pm, Geoff Levand wrote: > > > > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > > > > > > This patch adds arch specific descriptions about kdump usage on arm64 > > > > to kdump.txt. > > > > > > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > > --- > > > > Documentation/kdump/kdump.txt | 15 ++++++++++++++- > > > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > > > index 88ff63d..5d6da09 100644 > > > > --- a/Documentation/kdump/kdump.txt > > > > +++ b/Documentation/kdump/kdump.txt > > > > @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > > > > a remote system. > > > > > > > > Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > > > > -s390x and arm architectures. > > > > +s390x, arm and arm64 architectures. > > > > > > > > When the system kernel boots, it reserves a small section of memory for > > > > the dump-capture kernel. This ensures that ongoing Direct Memory Access > > > > @@ -249,6 +249,12 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > > > > > > AUTO_ZRELADDR=y > > > > > > > > +Dump-capture kernel config options (Arch Dependent, arm64) > > > > +---------------------------------------------------------- > > > > + > > > > +1) Currently, kvm will not be enabled on the dump-capture kernel even > > > > + if it is configured. > > And here, could you say more about it? On non-VHE (Virtualization Host Environment) system, the kernel, which normally runs in EL1 mode, must be started in EL2 mode to enable kvm, but the current code uses cpu pm notifier to reset CPU state to EL2 and we have no chance to do that on panic. I will clarify this in kdump.txt. > > > > + > > > > Extended crashkernel syntax > > > > =========================== > > > > > > > > @@ -305,6 +311,8 @@ Boot into System Kernel > > > > kernel will automatically locate the crash kernel image within the > > > > first 512MB of RAM if X is not given. > > > > > > > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > > > ~ Why square brackets here, is it > > > different than other arch? > > > > I want to clearly indicate that "@X" is optional, and that, when you explicitly > > specify it, X must be properly aligned. > > I think that "[..]" notation is quite common. > > Yes, I see that. Just that has been noted in "Extended crashkernel > syntax" section, and adding "[]" is not consistent with other places > where "crashkernel=Y@X" is referred to in this section. Just feel it's > a little redundent. Anyway it's not very critical, and Dave has acked > it, I am fine if you want to keep it. Thanks, -Takahiro AKASHI > Thanks > Baoquan > > > > > Thanks, > > -Takahiro AKASHI > > > > > > > > Except for this, it looks good to me. > > > > > > Thanks > > > Baoquan > > > > > > > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > > > > > > > Load the Dump-capture Kernel > > > > ============================ > > > > @@ -327,6 +335,8 @@ For s390x: > > > > - Use image or bzImage > > > > For arm: > > > > - Use zImage > > > > +For arm64: > > > > + - Use vmlinux or Image > > > > > > > > If you are using a uncompressed vmlinux image then use following command > > > > to load dump-capture kernel. > > > > @@ -370,6 +380,9 @@ For s390x: > > > > For arm: > > > > "1 maxcpus=1 reset_devices" > > > > > > > > +For arm64: > > > > + "1 maxcpus=1 reset_devices" > > > > + > > > > Notes on loading the dump-capture kernel: > > > > > > > > * By default, the ELF headers are stored in ELF64 format to support > > > > -- > > > > 2.5.0 > > > > > > > > > > > > > > > > _______________________________________________ > > > > kexec mailing list > > > > kexec@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/kexec
On Fri, Jul 01, 2016 at 08:09:57AM +0530, Pratyush Anand wrote: > Hi Takahiro, > > On 30/06/2016:10:46:04 AM, AKASHI Takahiro wrote: > > On Wed, Jun 29, 2016 at 10:20:50AM +0100, Catalin Marinas wrote: > > > On Wed, Jun 29, 2016 at 09:54:15AM +0900, AKASHI Takahiro wrote: > > > > On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > > > > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > > > > > AKASHI Takahiro (7): > > > > > > arm64: kdump: reserve memory for crash dump kernel > > > > > > arm64: limit memory regions based on DT property, usable-memory > > > > > > arm64: kdump: implement machine_crash_shutdown() > > > > > > arm64: kdump: add kdump support > > > > > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > > > > > arm64: kdump: enable kdump in the arm64 defconfig > > > > > > arm64: kdump: update a kernel doc > > > > > > > > > > > > Geoff Levand (4): > > > > > > arm64: Add back cpu reset routines > > > > > > arm64/kexec: Add core kexec support > > > > > > arm64/kexec: Enable kexec in the arm64 defconfig > > > > > > arm64/kexec: Add pr_debug output > > > > > > > > > > > > James Morse (3): > > > > > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > > > > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > > > > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > > > > > > > > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > > > > > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > > > > > merged patches 3-6, with the amendments that James mentioned. > > > > > > > > > > The kdump patches, including the "Documentation" one from James require > > > > > more review, testing and acks by the corresponding maintainers (kdump, > > > > > DT). > > > > > > > > I see what you mean, but even for Geoff's kexec part, the maintainer > > > > (Eric) have not given his ack. > > > > > > I just assumed he won't object ;). The only generic change is the > > > KEXEC_ARCH_AARCH64 in the uapi/linux/kexec.h file and the value chosen > > > matches EM_AARCH64. > > > > > > The kdump patches make such changes to Documentation and I would like > > > those acked by the kdump and DT maintainers. > > > > OK, I asked the corresponding maintainers to review them. > > > > > Pratyush Anand also had comments on the kdump patches in v19, so it's > > > fair to wait for him to complete the reviewing of the latest series. > > > > I think that it was my mistake that I referred to makedumpfile-related > > VMCOREINFO's in my patch. > > Since I'm not a user nor author of makedumpfile command for arm64, > > my changes should have been minimized, exluding any non-mandatory symbols. > > (Patch#13/14 is necessary for me to verify generated vmcore files > > with crash utility.) > > So I asked Pratyush to post his kernel patch based on his own requirements > > as he wants. > > I believe it's fair enough. > > Sorry for delayed response. > I am agreeing to this patchset. makedumpfile would also be able to work by > directly reading page table entries for all virtual addresses. So are you going to add a physical address of swapper_pg_dir? Do you see any visible speed down of makedumpfile? > I have tested this patchset with Mustang and both kexec and kdump works. So, you > can add > Tested-by: Pratyush Anand <panand@redhat.com> Thanks, -Takahiro AKASHI > Thanks for all the work on kexec/kdump. > > ~Pratyush > > > > > > > > You also don't seem to have added a s-o-b for those patches (since > > > > > you are submitting them; unless you plan to let Akashi-san submit them > > > > > in the future). > > > > > > > > Basically Geoff has not reviewed nor tested kdump part, and > > > > so I'm not sure that adding his s-o-b is appropriate. > > > > > > It is appropriate. See the "Developer's Certificate of Origin" in > > > Documentation/SubmittingPatches. A s-o-b from Geoff doesn't necessarily > > > mean that he reviewed the patches but that he has the right to pass them > > > on under the open source license indicated in the file (and AFAICT it is > > > legally binding but IANAL). > > > > > > > Anyhow, I will post my future version of kdump by myself as kexec has > > > > been queued in for-next/core. > > > > > > Thanks. > > > > Since I've got no comments on kdump patches and had no updates > > so far, I don't plan to post v21 this week (at this point). > > (I will add "reviewed-by James" to patch#7/14 in future releases.) > > > > Thanks, > > -Takahiro AKASHI > > > > > -- > > > Catalin > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 04/07/2016:04:14:09 PM, AKASHI Takahiro wrote: > On Fri, Jul 01, 2016 at 08:09:57AM +0530, Pratyush Anand wrote: > > Hi Takahiro, > > > > On 30/06/2016:10:46:04 AM, AKASHI Takahiro wrote: > > > On Wed, Jun 29, 2016 at 10:20:50AM +0100, Catalin Marinas wrote: > > > > On Wed, Jun 29, 2016 at 09:54:15AM +0900, AKASHI Takahiro wrote: > > > > > On Mon, Jun 27, 2016 at 06:00:39PM +0100, Catalin Marinas wrote: > > > > > > On Thu, Jun 23, 2016 at 05:54:47PM +0000, Geoff Levand wrote: > > > > > > > AKASHI Takahiro (7): > > > > > > > arm64: kdump: reserve memory for crash dump kernel > > > > > > > arm64: limit memory regions based on DT property, usable-memory > > > > > > > arm64: kdump: implement machine_crash_shutdown() > > > > > > > arm64: kdump: add kdump support > > > > > > > arm64: kdump: add VMCOREINFO's for user-space coredump tools > > > > > > > arm64: kdump: enable kdump in the arm64 defconfig > > > > > > > arm64: kdump: update a kernel doc > > > > > > > > > > > > > > Geoff Levand (4): > > > > > > > arm64: Add back cpu reset routines > > > > > > > arm64/kexec: Add core kexec support > > > > > > > arm64/kexec: Enable kexec in the arm64 defconfig > > > > > > > arm64/kexec: Add pr_debug output > > > > > > > > > > > > > > James Morse (3): > > > > > > > arm64: hibernate: Don't hibernate on systems with stuck CPUs > > > > > > > arm64: smp: Add function to determine if cpus are stuck in the kernel > > > > > > > Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec > > > > > > > > > > > > I dropped patch 1 (hibernate), cherry-picked patch 2 from mainline > > > > > > ("cpus stuck in the kernel", already pushed by Will to 4.7-rc5) and > > > > > > merged patches 3-6, with the amendments that James mentioned. > > > > > > > > > > > > The kdump patches, including the "Documentation" one from James require > > > > > > more review, testing and acks by the corresponding maintainers (kdump, > > > > > > DT). > > > > > > > > > > I see what you mean, but even for Geoff's kexec part, the maintainer > > > > > (Eric) have not given his ack. > > > > > > > > I just assumed he won't object ;). The only generic change is the > > > > KEXEC_ARCH_AARCH64 in the uapi/linux/kexec.h file and the value chosen > > > > matches EM_AARCH64. > > > > > > > > The kdump patches make such changes to Documentation and I would like > > > > those acked by the kdump and DT maintainers. > > > > > > OK, I asked the corresponding maintainers to review them. > > > > > > > Pratyush Anand also had comments on the kdump patches in v19, so it's > > > > fair to wait for him to complete the reviewing of the latest series. > > > > > > I think that it was my mistake that I referred to makedumpfile-related > > > VMCOREINFO's in my patch. > > > Since I'm not a user nor author of makedumpfile command for arm64, > > > my changes should have been minimized, exluding any non-mandatory symbols. > > > (Patch#13/14 is necessary for me to verify generated vmcore files > > > with crash utility.) > > > So I asked Pratyush to post his kernel patch based on his own requirements > > > as he wants. > > > I believe it's fair enough. > > > > Sorry for delayed response. > > I am agreeing to this patchset. makedumpfile would also be able to work by > > directly reading page table entries for all virtual addresses. > > So are you going to add a physical address of swapper_pg_dir? NO, I think, I can take it for-granted that swapper_pg_dir will always lie in identity mapped region. So, I will use __pa() macro only to translate swapper_pg_dir. Rest all virtual addresses will be translated using page table entries. > Do you see any visible speed down of makedumpfile? I will take back my comment here. Its almost negligible. About 2 Sec slower when whole dump process took around 2m 44 S. ~Pratyush
Hi Geoff, I am wondering if you could comment on the kexec-tools patches for kexec on arm64 and if you think it would be appropriate to merge them at this time. Thanks
Hi Simon, On Fri, 2016-07-15 at 13:17 +0900, Simon Horman wrote: > I am wondering if you could comment on the kexec-tools patches > for kexec on arm64 and if you think it would be appropriate to merge > them at this time. I'm working to clean up my kexec-tools patches now, and should be posting a series that add arm64 reboot within the next few days. -Geoff
This series adds the core support for kexec re-boot and kdump on ARM64. This version of the series combines Takahiro's kdump patches with my kexec patches. Please consider all patches for inclusion. Takahiro has done some extensive testing for this version with various configurations af endian, image format, memory options and layouts, etc. To load a second stage kernel and execute a kexec re-boot or to work with kdump on ARM64 systems a series of patches to kexec-tools [2], which have not yet been merged upstream, are needed. Please update to the latest if you have been using an older version. To examine vmcore (/proc/vmcore), you should use - gdb v7.7 or later (only useful for non-KASLR kernel) - crash utility master branch (coming v7.1.6 or later) For crash KASLR/CONFIG_RANDOMIZE_BASE support see [3]. [1] https://git.kernel.org/cgit/linux/kernel/git/geoff/linux-kexec.git [2] https://git.kernel.org/cgit/linux/kernel/git/geoff/kexec-tools.git [3] https://www.redhat.com/archives/crash-utility/2016-May/msg00078.html Changes for v20 (June 23, 2016, 25m): o Rebase to Linux-4.7-rc4. o Add missing break statement in kexec_list_flush. o Add a check for a return value of parse_crashkernel(). o Fix a wrong check against misalignment of allocated crash kernel region. Changes for v19 (June 16, 2016, 25m): o Rebase to Linux-4.7-rc3. o Added more VMCOREINFO's (VA_BITS, PHYS_OFFSET). o Remove some unneeded included files. o Remove kmap() usage. o Remove kexec_is_dtb() routine. o Change #ifdef to IS_ENABLED(CONFIG_HOTPLUG_CPU). o Fix kexec_list_flush() to flush all list entries. o Use ENTRY(arm64_relocate_new_kernel). o Remove unused segment start in arm64_relocate_new_kernel. Changes for v18 (June 9, 2016, 25m): o Rebase to Linux-4.7-rc2. o Change ret to br in __cpu_soft_restart(). o Add cpu_install_idmap() call and hyp checks to cpu_soft_restart(). o Don't return from HVC_SOFT_RESTART. Changes for v17 (June 9, 2016, 25m): o Rebase to Linux-4.7-rc2. o Change ret to br in __cpu_soft_restart(). o Add cpu_install_idmap() call to cpu_soft_restart(). Changes for v17 (June 3, 2016, 25m): o Rebase to Linux-4.7-rc1. o Added one VMCOREINFO parameter to vmcore for crash utility. o Added a check for CPUs stuck in kernel. o Re-implemented cpu_soft_restart() to be executed only in hyp-stub. o Added some kernel documentation about added device tree properties. o Fixed a returned value of pstate in crash_setup_regs(). Now return a faked pstate since we have no way to get the current pstate. Changes for v16 (Apr 14, 2016, 23m): o Rebase to Linux-4.6-rc3. o Don't try to explicitly enter EL2 at machine_kexec() when VHE in use o Add unreachable() in case of ipi_cpu_crash_stop() o Add more "#ifdef" to eliminate code unused when !CONFIG_KEXEC_CORE o Fix a build error around ipi_cpu_crash_stop() when !CONFIG_HOTPLUG_CPU o Revert "arm64: Add new hcall HVC_CALL_FUNC" o Revert "Convert hcalls to use HVC immediate value" (replaced by James' "hyp/kvm: Extend hyp-stub API to allow function calls at EL2") Modified by James: o Add missing icache maintenance + isb to __kvm_hyp_reset() o Rework kvm cpu hotplug for VHE Added by James: o arm64: head.S: el2_setup() to accept sctlr_el1 as an argument o arm64: hyp/kvm: Extend hyp-stub API to allow function calls at EL2 o arm64: kvm: Move lr save/restore from do_el2_call into EL1 o arm64: kvm: Move the do_el2_call macro to a header file Changes for v15 (Mar 14, 2016, 22m): o Rebase to Linux-4.5. o Remove DEBUG conditional in 'Add pr_debug output'. Changes for v14 (Mar 4, 2016, 22m): o Rebase to Linux-4.5-rc6. o Rename setup_mm_for_reboot to cpu_install_idmap. o kdump: leave non-boot cpus online at crash dump As we don't have to make non-boot (crashed) cpus offline at crash dump, this patch adds a variant of smp_send_stop(). o kdump: use a new device-tree property, "linux,elfcorehdr", instead of traditional "elfcorehdr=" kernel parameter o limit memory regions based on DT property, "usable-memory", instead of "mem=" kernel parameter o kdump: fix a build error when !CONFIG_KEXEC_CORE o kvm: use generic kvm_call_hyp() interface instead of kvm_cpu_reset() o kvm: initialize only a primary cpu at init_hyp_mode() Changes for v13 (Jan 15, 2016, 20m): o Rebase to Linux-4.4. o Remove align directive from cpu_reset.c. o Use inline C wrapper for cpu_soft_restart. o Revert the new image d-cache flush changes of v10. o Add SCTLR cleanup patch. o Change pr_devel to pr_debug. o Call flush_icache_range() for reboot_code_buffer. o Add .ltorg directive to arm64_relocate_new_kernel. o Make new asm macro copy_page. o Change cache maintenence from inner-shareable to non-shareable. o Rename KEXEC_ARCH_ARM64 to KEXEC_ARCH_AARCH64. o arm64: kvm: allows kvm cpu hotplug - remove some garbage code from kvm_host.h o arm64: kdump: reserve memory for crash dump kernel - change CONFIG_KEXEC to CONFIG_KEXEC_CORE - don't panic on crash kernel alloc failure (thanks to Mark Salter, RH) o arm64: kdump: implement machine_crash_shutdown() - change "boot/non-boot cpu" to "crashing/non-crashing cpu" - introduce is_in_crash_kexec() for readability - re-introduce machine_kexec_mask_interrupts(), as arch/arm has, to discard unexpected interrupts - call crash_save_cpu() before making cpus offline to avoid a possible race (thanks to Pratyush Anand/Mark Salter, RH) o arm64: kdump: update a kernel doc - clarify that we support "Image" format as well as vmlinux in kdump.txt o arm64: kdump: relax BUG_ON() if more than one cpus are still active - change a warning message at the failure of shooting down non-crahsing cpus Changes for v12 (Nov 24, 2015, 18m): o No changes, rebase to Linux-4.4-rc2. Changes for v11 (Nov 6, 2015, 18m): o Rebase to Linux-4.3. o Move the new image d-cache flush from arm64_relocate_new_kernel to machine_kexec. o Pass values to arm64_relocate_new_kernel in registers, not in global variables. o Fixups to setting the sctlr_el1 and sctlr_el2 flags. Changes for v10 (Oct 18, 2015, 17m): o Rebase to Linux-4.3-rc6. o Move tcr_set_idmap_t0sz to assembler.h. o Add back simplified cpu_reset routines. o Combine kexec + kdump patches. Changes for v9 (Apr 7, 2015, 11m): o Use new upstream flag IND_FLAGS. Changes for v8 (Mar 19, 2015, 10m): o Rebase to Linux-4.0-rc4. o Re-boot using purgatory only. Changes for v7 (Jan 16, 2015, 8m): o Rebase to Linux-3.19-rc4. o Change from ESR_EL2_ to ESR_ELx_. o Remove work-arounds for EFI systems. Changes for v6 (Dec 2, 2014, 7m): o Rebase to Linux-3.18-rc2 Changes for v5 (Nov 16, 2014, 6m): Changes for v4 (Oct 3, 2014, 5m): Changes for v3 (Sept 23, 2014, 4m): Changes for v2 (Sep 9, 2014, 4m): o Rebase to Linux-3.17-rc4. o Move macros from proc-macros.S to assembler.h. o Convert hcalls to use ISS field. o Add new hcall HVC_CALL_FUNC. o Add EL2 switch to soft_restart. First submission v1 (May 13, 2014): o Based on Linux-3.15-rc4. -Geoff The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e: Linux 4.7-rc4 (2016-06-19 21:30:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/geoff/linux-kexec.git kexec-v20 for you to fetch changes up to e212cd53fdf9d09923408eb906fe0228d22432a9: Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec (2016-06-23 10:01:38 -0700) ---------------------------------------------------------------- AKASHI Takahiro (7): arm64: kdump: reserve memory for crash dump kernel arm64: limit memory regions based on DT property, usable-memory arm64: kdump: implement machine_crash_shutdown() arm64: kdump: add kdump support arm64: kdump: add VMCOREINFO's for user-space coredump tools arm64: kdump: enable kdump in the arm64 defconfig arm64: kdump: update a kernel doc Geoff Levand (4): arm64: Add back cpu reset routines arm64/kexec: Add core kexec support arm64/kexec: Enable kexec in the arm64 defconfig arm64/kexec: Add pr_debug output James Morse (3): arm64: hibernate: Don't hibernate on systems with stuck CPUs arm64: smp: Add function to determine if cpus are stuck in the kernel Documentation: dt: usable-memory and elfcorehdr nodes for arm64 kexec Documentation/devicetree/bindings/chosen.txt | 28 +++ Documentation/kdump/kdump.txt | 15 +- arch/arm64/Kconfig | 21 ++ arch/arm64/configs/defconfig | 2 + arch/arm64/include/asm/hardirq.h | 2 +- arch/arm64/include/asm/kexec.h | 87 ++++++++ arch/arm64/include/asm/smp.h | 16 ++ arch/arm64/include/asm/virt.h | 5 + arch/arm64/kernel/Makefile | 3 + arch/arm64/kernel/cpu-reset.S | 54 +++++ arch/arm64/kernel/cpu-reset.h | 34 ++++ arch/arm64/kernel/crash_dump.c | 71 +++++++ arch/arm64/kernel/hibernate.c | 6 + arch/arm64/kernel/hyp-stub.S | 10 +- arch/arm64/kernel/machine_kexec.c | 288 +++++++++++++++++++++++++++ arch/arm64/kernel/relocate_kernel.S | 130 ++++++++++++ arch/arm64/kernel/setup.c | 7 +- arch/arm64/kernel/smp.c | 79 ++++++++ arch/arm64/mm/init.c | 154 ++++++++++++++ include/uapi/linux/kexec.h | 1 + 20 files changed, 1009 insertions(+), 4 deletions(-) create mode 100644 arch/arm64/include/asm/kexec.h create mode 100644 arch/arm64/kernel/cpu-reset.S create mode 100644 arch/arm64/kernel/cpu-reset.h create mode 100644 arch/arm64/kernel/crash_dump.c create mode 100644 arch/arm64/kernel/machine_kexec.c create mode 100644 arch/arm64/kernel/relocate_kernel.S