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. Here's an example program header dump from `vmlinux': $ readelf -l 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. Maciej
