linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
	akpm@linux-foundation.org, ard.biesheuvel@linaro.org,
	rppt@linux.ibm.com, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, ebiederm@xmission.com, horms@verge.net.au,
	takahiro.akashi@linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	linux-mm@kvack.org, wangkefeng.wang@huawei.com
Subject: Re: [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump
Date: Wed, 5 Jun 2019 17:32:04 +0100	[thread overview]
Message-ID: <51995efd-8469-7c15-0d5e-935b63fe2d9f@arm.com> (raw)
In-Reply-To: <20190507035058.63992-1-chenzhou10@huawei.com>

Hi!

On 07/05/2019 04:50, Chen Zhou wrote:
> We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough memory. Currently, crashkernel=Y@X can be used
> to reserve crashkernel above 4G, in this case, if swiotlb or DMA buffers
> are requierd, capture kernel will boot failure because of no low memory.

> When crashkernel is reserved above 4G in memory, kernel should reserve
> some amount of low memory for swiotlb and some DMA buffers. So there may
> be two crash kernel regions, one is below 4G, the other is above 4G.

This is a good argument for supporting the 'crashkernel=...,low' version.
What is the 'crashkernel=...,high' version for?

Wouldn't it be simpler to relax the ARCH_LOW_ADDRESS_LIMIT if we see 'crashkernel=...,low'
in the kernel cmdline?

I don't see what the 'crashkernel=...,high' variant is giving us, it just complicates the
flow of reserve_crashkernel().

If we called reserve_crashkernel_low() at the beginning of reserve_crashkernel() we could
use crashk_low_res.end to change some limit variable from ARCH_LOW_ADDRESS_LIMIT to
memblock_end_of_DRAM().
I think this is a simpler change that gives you what you want.


> Then
> Crash dump kernel reads more than one crash kernel regions via a dtb
> property under node /chosen,
> linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>.

Won't this break if your kdump kernel doesn't know what the extra parameters are?
Or if it expects two ranges, but only gets one? These DT properties should be treated as
ABI between kernel versions, we can't really change it like this.

I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
think the simplest thing to do is to add an 'linux,low-memory-range' that we
memblock_add() after memblock_cap_memory_range() has been called.
If its missing, or the new kernel doesn't know what its for, everything keeps working.


> Besides, we need to modify kexec-tools:
>   arm64: support more than one crash kernel regions(see [1])

> I post this patch series about one month ago. The previous changes and
> discussions can be retrived from:

Ah, this wasn't obvious as you've stopped numbering the series. Please label the next one
'v6' so that we can describe this as 'v5'. (duplicate numbering would be even more confusing!)


Thanks,

James


  parent reply	other threads:[~2019-06-05 16:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07  3:50 Chen Zhou
2019-05-07  3:50 ` [PATCH 1/4] x86: kdump: move reserve_crashkernel_low() into kexec_core.c Chen Zhou
2019-06-05 16:29   ` James Morse
2019-06-13 11:26     ` Chen Zhou
2019-06-12  8:45   ` Dave Young
2019-06-13 11:27     ` Chen Zhou
2019-05-07  3:50 ` [PATCH 2/4] arm64: kdump: support reserving crashkernel above 4G Chen Zhou
2019-06-05 16:29   ` James Morse
2019-06-13 11:27     ` Chen Zhou
2019-06-13 12:44       ` James Morse
2019-05-07  3:50 ` [PATCH 3/4] memblock: extend memblock_cap_memory_range to multiple ranges Chen Zhou
2019-05-07  3:50 ` [PATCH 4/4] kdump: update Documentation about crashkernel on arm64 Chen Zhou
2019-05-15  5:16   ` Bhupesh Sharma
2019-05-16  3:23     ` Chen Zhou
2019-05-15  5:06 ` [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump Bhupesh Sharma
2019-05-16  3:19   ` Chen Zhou
2019-06-03  2:24     ` Chen Zhou
2019-06-05 16:32 ` James Morse [this message]
2019-06-13 11:27   ` Chen Zhou
2019-06-13 12:43     ` James Morse

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=51995efd-8469-7c15-0d5e-935b63fe2d9f@arm.com \
    --to=james.morse@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenzhou10@huawei.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will.deacon@arm.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