Re: [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
On Wed, Jan 11, 2017 at 10:54:05AM +, Will Deacon wrote:
> On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote:
> > On Tue, Jan 10, 2017 at 11:32:48AM +, Will Deacon wrote:
> > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> > > > @@ -22,6 +25,7 @@
> > > > extern const unsigned char arm64_relocate_new_kernel[];
> > > > extern const unsigned long arm64_relocate_new_kernel_size;
> > > >
> > > > +static bool in_crash_kexec;
> > >
> > > Do you actually need this bool? Why not call kexec_crash_loaded() instead?
> >
> > The two have different meanings:
> > "in_crash_kexec" indicates that kdump is taking place, while
> > kexec_crash_loaded() tells us only whether crash dump kernel has been
> > loaded or not.
> >
> > It is crucial to distinguish them especially for machine_kexec()
> > which can be called on normal kexec even if kdump has been set up.
>
> Ah, I see. So how about just doing:
>
> if (kimage == kexec_crash_image)
>
> in machine_kexec?
Yeah, it should work.
Do you want to merge the following hunk,
or expect that I will re-send the whole patch series
(with other changes if any)?
-Takahiro AkASHI
> Will
===8<==
diff --git a/arch/arm64/kernel/machine_kexec.c
b/arch/arm64/kernel/machine_kexec.c
index 994fe0bc5cc0..c0fc3d458195 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -26,7 +26,6 @@
extern const unsigned char arm64_relocate_new_kernel[];
extern const unsigned long arm64_relocate_new_kernel_size;
-static bool in_crash_kexec;
static unsigned long kimage_start;
/**
@@ -154,7 +153,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)) &&
- !WARN_ON(in_crash_kexec));
+ !WARN_ON(kimage == kexec_crash_image));
reboot_code_buffer_phys = page_to_phys(kimage->control_code_page);
reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys);
@@ -206,8 +205,8 @@ void machine_kexec(struct kimage *kimage)
* relocation is complete.
*/
- cpu_soft_restart(!in_crash_kexec, reboot_code_buffer_phys, kimage->head,
- kimage_start, 0);
+ cpu_soft_restart(kimage != kexec_crash_image,
+ reboot_code_buffer_phys, kimage->head, kimage_start, 0);
BUG(); /* Should never get here. */
}
@@ -250,8 +249,6 @@ void machine_crash_shutdown(struct pt_regs *regs)
{
local_irq_disable();
- in_crash_kexec = true;
-
/* shutdown non-crashing cpus */
smp_send_crash_stop();
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Add +~800M crashkernel explaination
On 01/12/2017 at 03:35 AM, Robert LeBlanc wrote: > On Wed, Dec 14, 2016 at 4:17 PM, Xunlei Pang wrote: >> As I replied in another post, if you really want to detail the behaviour, >> should mention >> "crashkernel=size[KMG][@offset[KMG]]" with @offset[KMG] specified >> explicitly, after >> all, it's handled differently with no upper bound limitation, but doing this >> may put >> the first kernel at the risk of lacking low memory(some devices require >> 32bit DMA), >> must use it with care because the kernel will assume users are aware of what >> they >> are doing and make a successful reservation as long as the given range is >> available. > crashkernel=1024M@0x1000 > > I can't get the offset to work. It seems that it allocates the space > and loads the crash kernel, but I couldn't get it to actually boot > into the crash kernel. Does it work for you? I'm using the 4.9 kernel. Not sure what is the problem you met, but kdump kernel boots well using 4.9 on my x86_64 machine. Regards, Xunlei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] Add +~800M crashkernel explaination
On Wed, Dec 14, 2016 at 4:17 PM, Xunlei Pang wrote: > As I replied in another post, if you really want to detail the behaviour, > should mention > "crashkernel=size[KMG][@offset[KMG]]" with @offset[KMG] specified explicitly, > after > all, it's handled differently with no upper bound limitation, but doing this > may put > the first kernel at the risk of lacking low memory(some devices require 32bit > DMA), > must use it with care because the kernel will assume users are aware of what > they > are doing and make a successful reservation as long as the given range is > available. crashkernel=1024M@0x1000 I can't get the offset to work. It seems that it allocates the space and loads the crash kernel, but I couldn't get it to actually boot into the crash kernel. Does it work for you? I'm using the 4.9 kernel. Thanks Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote: > On Tue, Jan 10, 2017 at 11:32:48AM +, Will Deacon wrote: > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote: > > > @@ -22,6 +25,7 @@ > > > extern const unsigned char arm64_relocate_new_kernel[]; > > > extern const unsigned long arm64_relocate_new_kernel_size; > > > > > > +static bool in_crash_kexec; > > > > Do you actually need this bool? Why not call kexec_crash_loaded() instead? > > The two have different meanings: > "in_crash_kexec" indicates that kdump is taking place, while > kexec_crash_loaded() tells us only whether crash dump kernel has been > loaded or not. > > It is crucial to distinguish them especially for machine_kexec() > which can be called on normal kexec even if kdump has been set up. Ah, I see. So how about just doing: if (kimage == kexec_crash_image) in machine_kexec? Will ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCHv7 00/11] CONFIG_DEBUG_VIRTUAL for arm64
Hi, This is v7 of the patches to add CONFIG_DEBUG_VIRTUAL for arm64. This is a simple reordering of patches from v6 per request of Will Deacon for ease of merging support for arm which depends on this series. Laura Abbott (11): lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL mm/cma: Cleanup highmem check mm: Introduce lm_alias kexec: Switch to __pa_symbol mm/kasan: Switch to using __pa_symbol and lm_alias mm/usercopy: Switch to using lm_alias drivers: firmware: psci: Use __pa_symbol for kernel symbol arm64: Move some macros under #ifndef __ASSEMBLY__ arm64: Add cast for virt_to_pfn arm64: Use __pa_symbol for kernel symbols arm64: Add support for CONFIG_DEBUG_VIRTUAL arch/arm64/Kconfig| 1 + arch/arm64/include/asm/kvm_mmu.h | 4 +- arch/arm64/include/asm/memory.h | 66 +-- arch/arm64/include/asm/mmu_context.h | 6 +-- arch/arm64/include/asm/pgtable.h | 2 +- arch/arm64/kernel/acpi_parking_protocol.c | 3 +- arch/arm64/kernel/cpu-reset.h | 2 +- arch/arm64/kernel/cpufeature.c| 3 +- arch/arm64/kernel/hibernate.c | 20 +++--- arch/arm64/kernel/insn.c | 2 +- arch/arm64/kernel/psci.c | 3 +- arch/arm64/kernel/setup.c | 9 +++-- arch/arm64/kernel/smp_spin_table.c| 3 +- arch/arm64/kernel/vdso.c | 8 +++- arch/arm64/mm/Makefile| 2 + arch/arm64/mm/init.c | 12 +++--- arch/arm64/mm/kasan_init.c| 22 +++ arch/arm64/mm/mmu.c | 33 ++-- arch/arm64/mm/physaddr.c | 30 ++ arch/x86/Kconfig | 1 + drivers/firmware/psci.c | 2 +- include/linux/mm.h| 4 ++ kernel/kexec_core.c | 2 +- lib/Kconfig.debug | 5 ++- mm/cma.c | 15 +++ mm/kasan/kasan_init.c | 15 +++ mm/usercopy.c | 4 +- 27 files changed, 180 insertions(+), 99 deletions(-) create mode 100644 arch/arm64/mm/physaddr.c -- 2.7.4 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64
On Wed, Jan 04, 2017 at 02:30:50PM -0800, Florian Fainelli wrote: > On 01/04/2017 03:44 AM, Will Deacon wrote: > > On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote: > >> On 01/03/2017 02:56 PM, Florian Fainelli wrote: > >>> On 01/03/2017 09:21 AM, Laura Abbott wrote: > Happy New Year! > > This is a very minor rebase from v5. It only moves a few headers around. > I think this series should be ready to be queued up for 4.11. > >>> > >>> FWIW: > >>> > >>> Tested-by: Florian Fainelli > >>> > >> > >> Thanks! > >> > >>> How do we get this series included? I would like to get the ARM 32-bit > >>> counterpart included as well (will resubmit rebased shortly), but I have > >>> no clue which tree this should be going through. > >>> > >> > >> I was assuming this would go through the arm64 tree unless Catalin/Will > >> have an objection to that. > > > > Yup, I was planning to pick it up for 4.11. > > > > Florian -- does your series depend on this? If so, then I'll need to > > co-ordinate with Russell (probably via a shared branch that we both pull) > > if you're aiming for 4.11 too. > > Yes, pretty much everything in Laura's patch series is relevant, except > the arm64 bits. Ok, then. Laura -- could you please reorder your patches so that the non-arm64 bits come first? That way, I can put those on a separate branch and have it pulled by both arm64 and rmk, so that the prequisities are shared between the architectures. Thanks, Will ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
