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
