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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

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.

Jan