From: Baoquan He <bhe@redhat.com>
To: vgoyal@redhat.com, hpa@zytor.com, yinghai@kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
takahiro.akashi@linaro.org, ebiederm@xmission.com,
dyoung@redhat.com, prudo@linux.vnet.ibm.com
Subject: Re: [PATCH 0/2] Kexec_file: Load kernel at top of system ram
Date: Fri, 23 Mar 2018 16:38:58 +0800 [thread overview]
Message-ID: <20180323083858.GB25740@localhost.localdomain> (raw)
In-Reply-To: <20180322153802.0763bb46978c0c1a3d3f11c0@linux-foundation.org>
On 03/22/18 at 03:38pm, Andrew Morton wrote:
> On Thu, 22 Mar 2018 11:37:20 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> > The current kexec_file ignores kexec_buf.top_down value when call
> > arch_kexec_walk_mem() to allocate memory for loading kernel/initrd
> > stuffs. This is not supposed to be what kexec_buf.top_down is used
> > for.
>
> OK, but why is this a problem? When fixing a bug, please fully
> describe the user-visible effects of that bug. That helps others
> understand the importance of the fix, whether it should be backported
> into various kernels, etc.
The problem is the current kexec file loading has different behaviour
with the old kexec loading. In kexec loading, user space kexec_tools
utility does most of job, it searches in /proc/iomem to try to find a
memory region from top to down to load kernel. Therefore with the kexec
loading, x86_64 bzImage kernel are all loaded at top of System RAM.
However, the kexec file loading just searches for available memory
region in iomem resource from bottom to top, then try to allocate from
top to down in that region. E.g on my testing system with 2G memory as
below, the kexec loading will put kernel near 0x000000013fffffff, while
kexec file loading will put kernel near 0x000000003ffddfff. There's no
bug reported yet, just we need consider it when take care of the kexec
collaboration with other kernel components like kaslr/hotplug etc, and
also the consistentency between the different kexec interface.
[Mar23 15:13] Linux version 4.16.0-rc3+ (bhe@localhost.localdomain) (gcc version
[ +0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.16.0-rc3+ root=UUID=be8f8e3a-9
[ +0.000000] x86/fpu: x87 FPU will use FXSAVE
[ +0.000000] e820: BIOS-provided physical RAM map:
[ +0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ +0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ +0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ +0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffddfff] usable
[ +0.000000] BIOS-e820: [mem 0x000000003ffde000-0x000000003fffffff] reserved
[ +0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ +0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ +0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
I searched on internet and found the original patches posted for adding
bzImage 64 support into the old kexec loading, which is located in user
space kexec_tools utility made by Yinghai, and Vivek and hpa reviewed
patches. Still I didn't found out why kernel has to be put at top of
system RAM. I guess low memory are reserved for system usage mostly,
putting kexec kernel at top is safer and no need to exclude those resereved
regions by system or firmware which we may not find out all of them, but
not very sure about it.
Hi Yinghai, Vivek, hpa,
Do you know why we load kexec kernel at top of system RAM when do
x86_64 bzImage loading?
Thanks
Baoquan
prev parent reply other threads:[~2018-03-23 8:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 3:37 [PATCH 0/2] Kexec_file: Load kernel at top of system ram Baoquan He
2018-03-22 3:37 ` [PATCH 1/2] resource: add walk_system_ram_res_rev() Baoquan He
2018-03-22 22:29 ` Andrew Morton
2018-03-23 0:58 ` Baoquan He
2018-03-23 2:06 ` Andrew Morton
2018-03-23 3:10 ` Baoquan He
2018-03-23 20:06 ` Andrew Morton
2018-03-24 13:33 ` Baoquan He
2018-03-24 16:13 ` Wei Yang
2018-03-26 14:30 ` Baoquan He
2018-03-26 15:04 ` Wei Yang
2018-03-22 3:37 ` [PATCH 2/2] kexec_file: Load kernel at top of system RAM if required Baoquan He
2018-03-22 22:38 ` [PATCH 0/2] Kexec_file: Load kernel at top of system ram Andrew Morton
2018-03-23 8:38 ` Baoquan He [this message]
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=20180323083858.GB25740@localhost.localdomain \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=prudo@linux.vnet.ibm.com \
--cc=takahiro.akashi@linaro.org \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.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