From: Baoquan He <bhe@redhat.com>
To: chenzhou <chenzhou10@huawei.com>
Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org,
catalin.marinas@arm.com, bhsharma@redhat.com,
huawei.libin@huawei.com, guohanjun@huawei.com, will@kernel.org,
corbet@lwn.net, mingo@redhat.com, dyoung@redhat.com,
John.P.donnelly@oracle.com, arnd@arndb.de, xiexiuqi@huawei.com,
horms@verge.net.au, tglx@linutronix.de,
linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
james.morse@arm.com, prabhakar.pkin@gmail.com,
nsaenzjulienne@suse.de
Subject: Re: [PATCH v13 6/8] arm64: kdump: reimplement crashkernel=X
Date: Wed, 11 Nov 2020 21:54:48 +0800 [thread overview]
Message-ID: <20201111135448.GF8486@MiWiFi-R3L-srv> (raw)
In-Reply-To: <23389389-2855-50fd-25b7-4f7d4246bf0c@huawei.com>
On 11/11/20 at 09:27pm, chenzhou wrote:
> Hi Baoquan,
...
> >> #ifdef CONFIG_CRASH_DUMP
> >> static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index 1c0f3e02f731..c55cee290bbb 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -488,6 +488,10 @@ static void __init map_mem(pgd_t *pgdp)
> >> */
> >> memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
> >> #ifdef CONFIG_KEXEC_CORE
> >> + if (crashk_low_res.end)
> >> + memblock_mark_nomap(crashk_low_res.start,
> >> + resource_size(&crashk_low_res));
> >> +
> >> if (crashk_res.end)
> >> memblock_mark_nomap(crashk_res.start,
> >> resource_size(&crashk_res));
> >> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> >> index d39892bdb9ae..cdef7d8c91a6 100644
> >> --- a/kernel/crash_core.c
> >> +++ b/kernel/crash_core.c
> >> @@ -321,7 +321,7 @@ int __init parse_crashkernel_low(char *cmdline,
> >>
> >> int __init reserve_crashkernel_low(void)
> >> {
> >> -#ifdef CONFIG_X86_64
> >> +#if defined(CONFIG_X86_64) || defined(CONFIG_ARM64)
> > Not very sure if a CONFIG_64BIT checking is better.
> If doing like this, there may be some compiling errors for other 64-bit kernel, such as mips.
> >
> >> unsigned long long base, low_base = 0, low_size = 0;
> >> unsigned long low_mem_limit;
> >> int ret;
> >> @@ -362,12 +362,14 @@ int __init reserve_crashkernel_low(void)
> >>
> >> crashk_low_res.start = low_base;
> >> crashk_low_res.end = low_base + low_size - 1;
> >> +#ifdef CONFIG_X86_64
> >> insert_resource(&iomem_resource, &crashk_low_res);
> >> +#endif
> >> #endif
> >> return 0;
> >> }
> >>
> >> -#ifdef CONFIG_X86
> >> +#if defined(CONFIG_X86) || defined(CONFIG_ARM64)
> > Should we make this weak default so that we can remove the ARCH config?
> The same as above, some arch may not support kdump, in that case, compiling errors occur.
OK, not sure if other people have better idea, oterwise, we can leave with it.
Thanks for telling.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-11 13:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 7:44 [PATCH v13 0/8] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2020-10-31 7:44 ` [PATCH v13 1/8] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN Chen Zhou
2020-11-11 1:38 ` Baoquan He
2020-11-11 13:26 ` chenzhou
2020-11-12 7:58 ` Mike Rapoport
2020-11-12 8:12 ` chenzhou
2020-10-31 7:44 ` [PATCH v13 2/8] x86: kdump: make the lower bound of crash kernel reservation consistent Chen Zhou
2020-10-31 7:44 ` [PATCH v13 3/8] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel() Chen Zhou
2020-10-31 7:44 ` [PATCH v13 4/8] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c Chen Zhou
2020-11-12 8:11 ` Mike Rapoport
2020-11-12 13:01 ` chenzhou
2020-10-31 7:44 ` [PATCH v13 5/8] arm64: kdump: introduce some macroes for crash kernel reservation Chen Zhou
2020-10-31 7:44 ` [PATCH v13 6/8] arm64: kdump: reimplement crashkernel=X Chen Zhou
2020-11-11 1:59 ` Baoquan He
2020-11-11 13:27 ` chenzhou
2020-11-11 13:54 ` Baoquan He [this message]
2020-11-12 8:25 ` Mike Rapoport
2020-11-12 8:36 ` Baoquan He
2020-11-12 13:11 ` chenzhou
2020-10-31 7:44 ` [PATCH v13 7/8] arm64: kdump: add memory for devices by DT property linux, usable-memory-range Chen Zhou
2020-10-31 7:44 ` [PATCH v13 8/8] kdump: update Documentation about crashkernel Chen Zhou
2020-11-09 12:34 ` [PATCH v13 0/8] support reserving crashkernel above 4G on arm64 kdump chenzhou
2020-11-11 3:01 ` Baoquan He
2020-11-11 13:29 ` chenzhou
2020-11-11 19:41 ` Bhupesh SHARMA
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=20201111135448.GF8486@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=John.P.donnelly@oracle.com \
--cc=arnd@arndb.de \
--cc=bhsharma@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=chenzhou10@huawei.com \
--cc=corbet@lwn.net \
--cc=dyoung@redhat.com \
--cc=guohanjun@huawei.com \
--cc=horms@verge.net.au \
--cc=huawei.libin@huawei.com \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nsaenzjulienne@suse.de \
--cc=prabhakar.pkin@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=xiexiuqi@huawei.com \
/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).