From: James Hogan <james.hogan@mips.com>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: Huacai Chen <chenhc@lemote.com>,
Ralf Baechle <ralf@linux-mips.org>,
"Steven J . Hill" <Steven.Hill@cavium.com>,
<linux-mips@linux-mips.org>, Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>
Subject: Re: [PATCH V2 08/12] MIPS: Align kernel load address to 64KB
Date: Tue, 20 Feb 2018 22:25:42 +0000 [thread overview]
Message-ID: <20180220222542.GF29460@jhogan-linux.mipstec.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202206490.3553@tp.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
On Tue, Feb 20, 2018 at 10:14:39PM +0000, Maciej W. Rozycki wrote:
> On Mon, 19 Feb 2018, James Hogan wrote:
>
> > > KEXEC assume kernel align to PAGE_SIZE, and 64KB is the largest
> > > PAGE_SIZE.
> >
> > Please expand, maybe referring to sanity_check_segment_list() which does
> > the actual check. Maybe something like this:
> >
> > Kexec needs the new kernel's load address to be aligned on a page
> > boundary (see sanity_check_segment_list()), but on MIPS the default
> > vmlinuz load address is only explicitly aligned to 16 bytes.
> >
> > Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
> > the alignment calculated by calc_vmlinuz_load_addr to 64KB.
>
> But why does it have to be hardcoded? Shouldn't it be inherited from
> the image being loaded? I'm missing bits of context here, but that
> would be either CONFIG_PAGE_SIZE_* settings or the ELF program header's
> `p_align' value, depending on how this code operates. Wasting say 60kB
> of memory on smaller systems due to excessive alignment might not be a
> good idea.
I presume there's nothing to stop a kernel with 64KB pages (and hence
requiring 64KB alignment of load sections) loading a new kernel with 4KB
pages (which is the one we're looking at).
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@mips.com>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: Huacai Chen <chenhc@lemote.com>,
Ralf Baechle <ralf@linux-mips.org>,
"Steven J . Hill" <Steven.Hill@cavium.com>,
linux-mips@linux-mips.org, Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>
Subject: Re: [PATCH V2 08/12] MIPS: Align kernel load address to 64KB
Date: Tue, 20 Feb 2018 22:25:42 +0000 [thread overview]
Message-ID: <20180220222542.GF29460@jhogan-linux.mipstec.com> (raw)
Message-ID: <20180220222542.r_QqKXE4Epya6MFW36MZLS9741raR18ZWWVYWCAxGQc@z> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202206490.3553@tp.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
On Tue, Feb 20, 2018 at 10:14:39PM +0000, Maciej W. Rozycki wrote:
> On Mon, 19 Feb 2018, James Hogan wrote:
>
> > > KEXEC assume kernel align to PAGE_SIZE, and 64KB is the largest
> > > PAGE_SIZE.
> >
> > Please expand, maybe referring to sanity_check_segment_list() which does
> > the actual check. Maybe something like this:
> >
> > Kexec needs the new kernel's load address to be aligned on a page
> > boundary (see sanity_check_segment_list()), but on MIPS the default
> > vmlinuz load address is only explicitly aligned to 16 bytes.
> >
> > Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
> > the alignment calculated by calc_vmlinuz_load_addr to 64KB.
>
> But why does it have to be hardcoded? Shouldn't it be inherited from
> the image being loaded? I'm missing bits of context here, but that
> would be either CONFIG_PAGE_SIZE_* settings or the ELF program header's
> `p_align' value, depending on how this code operates. Wasting say 60kB
> of memory on smaller systems due to excessive alignment might not be a
> good idea.
I presume there's nothing to stop a kernel with 64KB pages (and hence
requiring 64KB alignment of load sections) loading a new kernel with 4KB
pages (which is the one we're looking at).
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-02-20 22:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-27 3:12 [PATCH V2 00/12] MIPS: Loongson: new features and improvements Huacai Chen
2018-01-27 3:12 ` [PATCH V2 01/12] MIPS: Loongson: Add Loongson-3A R3.1 basic support Huacai Chen
2018-01-27 3:12 ` [PATCH V2 02/12] MIPS: Loongson64: Define and use some CP0 registers Huacai Chen
2018-02-15 11:36 ` James Hogan
2018-01-27 3:12 ` [PATCH V2 03/12] MIPS: Loongson-3: Enable Store Fill Buffer at runtime Huacai Chen
2018-02-15 12:43 ` James Hogan
2018-01-27 3:19 ` [PATCH V2 04/12] MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3 Huacai Chen
2018-02-19 22:19 ` James Hogan
2018-01-27 3:20 ` [PATCH V2 05/12] MIPS: Loongson fix name confict - MEM_RESERVED Huacai Chen
2018-01-27 3:21 ` [PATCH V2 06/12] MIPS: Ensure pmd_present() returns false after pmd_mknotpresent() Huacai Chen
2018-01-27 3:22 ` [PATCH V2 07/12] MIPS: Add __cpu_full_name[] to make CPU names more human-readable Huacai Chen
2018-01-27 3:22 ` [PATCH V2 08/12] MIPS: Align kernel load address to 64KB Huacai Chen
2018-02-19 23:07 ` James Hogan
2018-02-20 22:14 ` Maciej W. Rozycki
2018-02-20 22:14 ` Maciej W. Rozycki
2018-02-20 22:25 ` James Hogan [this message]
2018-02-20 22:25 ` James Hogan
2018-02-20 22:53 ` Maciej W. Rozycki
2018-02-20 22:53 ` Maciej W. Rozycki
2018-02-20 22:58 ` James Hogan
2018-02-20 22:58 ` James Hogan
2018-02-20 23:38 ` Maciej W. Rozycki
2018-02-20 23:38 ` Maciej W. Rozycki
2018-02-21 11:13 ` James Hogan
2018-02-21 11:13 ` James Hogan
2018-02-26 12:41 ` Maciej W. Rozycki
2018-02-26 12:41 ` Maciej W. Rozycki
2018-01-27 3:22 ` [PATCH V2 09/12] MIPS: Loongson: Add kexec/kdump support Huacai Chen
2018-02-19 23:54 ` James Hogan
2018-01-27 3:22 ` [PATCH V2 10/12] MIPS: Loongson: Make CPUFreq usable for Loongson-3 Huacai Chen
2018-01-27 3:23 ` [PATCH V2 11/12] MIPS: Loongson-3: Fix CPU UART irq delivery problem Huacai Chen
2018-02-20 21:49 ` James Hogan
2018-01-27 3:23 ` [PATCH V2 12/12] MIPS: Loongson: Introduce and use WAR_LLSC_MB Huacai Chen
2018-02-20 22:21 ` James Hogan
2018-02-21 10:09 ` Maciej W. Rozycki
2018-02-21 10:09 ` Maciej W. Rozycki
2018-02-21 11:43 ` James Hogan
2018-02-20 21:42 ` [PATCH V2 10/12] MIPS: Loongson: Make CPUFreq usable for Loongson-3 James Hogan
2018-02-15 11:05 ` [PATCH V2 00/12] MIPS: Loongson: new features and improvements James Hogan
2018-02-28 2:23 ` Huacai Chen
2018-02-28 10:03 ` James Hogan
2018-03-01 2:35 ` Huacai Chen
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=20180220222542.GF29460@jhogan-linux.mipstec.com \
--to=james.hogan@mips.com \
--cc=Steven.Hill@cavium.com \
--cc=chenhc@lemote.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@mips.com \
--cc=ralf@linux-mips.org \
--cc=wuzhangjin@gmail.com \
--cc=zhangfx@lemote.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