Re: [PATCH v2 1/2] x86/mkelf32: pad load segment to 2Mb boundary

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Aug 14, 2025 at 09:02:35AM +0200, Jan Beulich wrote:
> On 12.08.2025 18:18, Roger Pau Monné wrote:
> > On Mon, Aug 11, 2025 at 12:49:57PM +0200, Jan Beulich wrote:
> >> @@ -339,9 +340,12 @@ int main(int argc, char **argv)
> >>      (void)lseek(infd, in64_phdr.p_offset, SEEK_SET);
> >>      dat_siz = (uint32_t)in64_phdr.p_filesz;
> >>  
> >> -    /* Do not use p_memsz: it does not include BSS alignment padding. */
> >> -    /*mem_siz = (uint32_t)in64_phdr.p_memsz;*/
> >> -    mem_siz = (uint32_t)(final_exec_addr - in64_phdr.p_vaddr);
> >> +    /*
> >> +     * We don't pad .bss in the linker script, but during early boot we map
> >> +     * the Xen image using 2M pages.  To avoid running into adjacent non-RAM
> >> +     * regions, pad the segment to the next 2M boundary.
> > 
> > Won't it be easier to pad in the linker script?  We could still have
> > __bss_end before the padding, so that initialization isn't done to the
> > extra padding area.  Otherwise it would be helpful to mention why the
> > padding must be done here (opposed to being done in the linker
> > script).
> 
> The way the linker script currently is written doesn't lend itself to do
> the padding there: It would either mean to introduce an artificial
> padding section (which I'd dislike), or it would result in _end[] and
> __2M_rwdata_end[] also moving, which pretty clearly we don't want. Maybe
> there are other options that I simply don't see.

We could move both _end and __2M_rwdata_end inside the .bss section,
but that's also ugly IMO.  I would probably prefer the extra padding
section.

> A further complication would be xen.efi's .reloc, which we don't want to
> needlessly move either. That may be coverable by pr-processor
> conditionals, but I wanted to mention the aspect nevertheless.

Yeah, we could make the extra padding section depend on pre-processor
checks.  I think I would prefer the usage of such extra section rather
than mangling the elf program headers afterwards, but since we are
already doing it:

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.