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....@citrix.com> Thanks, Roger.
