On Wed, 21 Feb 2018, James Hogan wrote: > > 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(). So this is 1st kernel's page size AFAICT. And I can see `struct kexec_segment' drops ELF program header information, sigh. > > 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. Well, even if compressed you need to preserve the original structures somehow so that once uncompressed the memory image is the same as if `vmlinux' was loaded directly. > > 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 Hmm, now you've left me stumped, so I'll shut up. Maciej
