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:58:46 +0000 [thread overview]
Message-ID: <20180220225845.GG29460@jhogan-linux.mipstec.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202249410.3553@tp.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Tue, Feb 20, 2018 at 10:53:19PM +0000, Maciej W. Rozycki wrote:
> On Tue, 20 Feb 2018, James Hogan wrote:
>
> > > > 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).
>
> As I say, I'm missing bits of context. If you say that a 64kiB-page
> kernel loads a 4kiB-page kernel, then the alignment for the latter is
> obviously 4kiB. So I repeat my question: why hardcode the alignment to
> 64kiB while we only need 4kiB in this case?
Because its the 1st kernel which is doing the kexec'ing of the 2nd
kernel. The 2nd kernel might not even have kexec enabled, but you still
might want to boot it using kexec.
The only alternative is for the kexec userland tools to be able to
automatically adjust the load segments to load a bit more before the
start of the kernel image so that its aligned, and i'm not sure how
universally safe that would be.
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:58:46 +0000 [thread overview]
Message-ID: <20180220225845.GG29460@jhogan-linux.mipstec.com> (raw)
Message-ID: <20180220225846.NOZMGe6fJ329e6pN_gElvGMAPoBp2zuU0sndQjXw25I@z> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202249410.3553@tp.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Tue, Feb 20, 2018 at 10:53:19PM +0000, Maciej W. Rozycki wrote:
> On Tue, 20 Feb 2018, James Hogan wrote:
>
> > > > 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).
>
> As I say, I'm missing bits of context. If you say that a 64kiB-page
> kernel loads a 4kiB-page kernel, then the alignment for the latter is
> obviously 4kiB. So I repeat my question: why hardcode the alignment to
> 64kiB while we only need 4kiB in this case?
Because its the 1st kernel which is doing the kexec'ing of the 2nd
kernel. The 2nd kernel might not even have kexec enabled, but you still
might want to boot it using kexec.
The only alternative is for the kexec userland tools to be able to
automatically adjust the load segments to load a bit more before the
start of the kernel image so that its aligned, and i'm not sure how
universally safe that would be.
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-02-20 22:59 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
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 [this message]
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=20180220225845.GG29460@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