Linux MIPS Architecture development
 help / color / mirror / Atom feed
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: Wed, 21 Feb 2018 11:13:45 +0000	[thread overview]
Message-ID: <20180221111344.GH29460@jhogan-linux.mipstec.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202313480.3553@tp.orcam.me.uk>

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

On Tue, Feb 20, 2018 at 11:38:26PM +0000, Maciej W. Rozycki wrote:
> On Tue, 20 Feb 2018, James Hogan wrote:
> 
> > >  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.
> 
>  Forgive my dumbness, but I don't understand what's preventing the 1st 
> kernel from getting the alignment of the 2nd kernel (regardless of 
> whether the 2nd kernel has kexec enabled).  What prevents the 1st kernel 
> from interpreting the `p_align' value from the relevant program header 
> of the 2nd kernel before loading the segment the header describes?  It 
> has to load the header anyway or it wouldn't know how much data to load 
> and where from into the file, and how much BSS space to initialise.

The kernel doesn't always get an elf through kexec_load(2), but rather a
list of load segments. In any case though its not about knowing the
page size of 2nd kernel, its about kexec working with page size chunks.
See the comment in sanity_check_segment_list().

> 
>  Here's an example program header dump from `vmlinux':
> 
> $ readelf -l vmlinux

Yeh but its not a vmlinux, its a vmlinuz. Thats the whole point. Though
it sounds like you'd have the same problem with vmlinux too if you tried
reducing the page size, so perhaps its fine for compressed kernels to
just align to the page size of the 2nd kernel, so they're no worse than
vmlinux.

> 
> Elf file type is EXEC (Executable file)
> Entry point 0x80506e70
> There are 3 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   ABIFLAGS       0x4b02e8 0x805ac2e8 0x805ac2e8 0x00018 0x00018 R   0x8
>   LOAD           0x004000 0x80100000 0x80100000 0x534650 0x569710 RWE 0x4000
>   NOTE           0x4145a8 0x805105a8 0x805105a8 0x00024 0x00024 R   0x4
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .MIPS.abiflags
>    01     .text __ex_table .notes .rodata .MIPS.abiflags .pci_fixup __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver .data .init.text .init.data .exit.text .bss
>    02     .notes
> $ 
> 
> As you can see there's only one loadable segment (the usual case) and 
> its alignment is 0x4000, that is 16kiB.  So this kernel uses a page size 
> of 16kiB.

For malta_defconfig *vmlinuz* however (CONFIG_PAGE_SIZE_16KB=y), I get
this:
  LOAD           0x008320 0x80828320 0x80828320 0x35e580 0x8605a0 RWE 0x10000

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: Wed, 21 Feb 2018 11:13:45 +0000	[thread overview]
Message-ID: <20180221111344.GH29460@jhogan-linux.mipstec.com> (raw)
Message-ID: <20180221111345.fXqG0guzrQTIJvFwiqu27s8NYI79E5pYqO3TQ-Ko6wo@z> (raw)
In-Reply-To: <alpine.DEB.2.00.1802202313480.3553@tp.orcam.me.uk>

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

On Tue, Feb 20, 2018 at 11:38:26PM +0000, Maciej W. Rozycki wrote:
> On Tue, 20 Feb 2018, James Hogan wrote:
> 
> > >  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.
> 
>  Forgive my dumbness, but I don't understand what's preventing the 1st 
> kernel from getting the alignment of the 2nd kernel (regardless of 
> whether the 2nd kernel has kexec enabled).  What prevents the 1st kernel 
> from interpreting the `p_align' value from the relevant program header 
> of the 2nd kernel before loading the segment the header describes?  It 
> has to load the header anyway or it wouldn't know how much data to load 
> and where from into the file, and how much BSS space to initialise.

The kernel doesn't always get an elf through kexec_load(2), but rather a
list of load segments. In any case though its not about knowing the
page size of 2nd kernel, its about kexec working with page size chunks.
See the comment in sanity_check_segment_list().

> 
>  Here's an example program header dump from `vmlinux':
> 
> $ readelf -l vmlinux

Yeh but its not a vmlinux, its a vmlinuz. Thats the whole point. Though
it sounds like you'd have the same problem with vmlinux too if you tried
reducing the page size, so perhaps its fine for compressed kernels to
just align to the page size of the 2nd kernel, so they're no worse than
vmlinux.

> 
> Elf file type is EXEC (Executable file)
> Entry point 0x80506e70
> There are 3 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   ABIFLAGS       0x4b02e8 0x805ac2e8 0x805ac2e8 0x00018 0x00018 R   0x8
>   LOAD           0x004000 0x80100000 0x80100000 0x534650 0x569710 RWE 0x4000
>   NOTE           0x4145a8 0x805105a8 0x805105a8 0x00024 0x00024 R   0x4
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .MIPS.abiflags
>    01     .text __ex_table .notes .rodata .MIPS.abiflags .pci_fixup __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver .data .init.text .init.data .exit.text .bss
>    02     .notes
> $ 
> 
> As you can see there's only one loadable segment (the usual case) and 
> its alignment is 0x4000, that is 16kiB.  So this kernel uses a page size 
> of 16kiB.

For malta_defconfig *vmlinuz* however (CONFIG_PAGE_SIZE_16KB=y), I get
this:
  LOAD           0x008320 0x80828320 0x80828320 0x35e580 0x8605a0 RWE 0x10000

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-02-21 11:14 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
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 [this message]
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=20180221111344.GH29460@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