[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen staging] x86/mkelf32: pad load segment to 2Mb boundary



commit 4fb075201f54b16c0800af0107162461a93065fb
Author:     Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Mon Aug 18 10:42:24 2025 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Aug 18 10:42:24 2025 +0200

    x86/mkelf32: pad load segment to 2Mb boundary
    
    In order to legitimately set up initial mappings past _end[], we need
    to make sure that the entire mapped range is inside a RAM region.
    Therefore we need to inform the bootloader (or alike) that our allocated
    size is larger than just the next SECTION_ALIGN-ed boundary past _end[].
    
    This allows dropping a command line option from the tool, which was
    introduced to work around a supposed linker bug, when the problem was
    really Xen's.
    
    While adjusting adjacent code, correct the argc check to also cover the
    case correctly when --notes was passed.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
---
 xen/arch/x86/Makefile       |  3 +--
 xen/arch/x86/boot/mkelf32.c | 18 +++++++++++-------
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5aab30a0c4..9d67ea7cd4 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -130,8 +130,7 @@ orphan-handling-$(call ld-option,--orphan-handling=warn) += 
--orphan-handling=wa
 
 $(TARGET): TMP = $(dot-target).elf32
 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
-       $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) 
$(XEN_IMG_OFFSET) \
-                      `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__2M_rwdata_end$$/0x\1/p'`
+       $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) 
$(XEN_IMG_OFFSET)
        od -t x4 -N 8192 $(TMP)  | grep 1badb002 > /dev/null || \
                { echo "No Multiboot1 header found" >&2; false; }
        od -t x4 -N 32768 $(TMP) | grep e85250d6 > /dev/null || \
diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index f0f406687c..373ba4ddd5 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -248,7 +248,6 @@ static void do_read(int fd, void *data, int len)
 
 int main(int argc, char **argv)
 {
-    uint64_t   final_exec_addr;
     uint32_t   loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
     char      *inimage, *outimage;
     int        infd, outfd;
@@ -261,22 +260,24 @@ int main(int argc, char **argv)
     Elf64_Ehdr in64_ehdr;
     Elf64_Phdr in64_phdr;
 
-    if ( argc < 5 )
+    if ( argc < 4 )
     {
+    help:
         fprintf(stderr, "Usage: mkelf32 [--notes] <in-image> <out-image> "
-                "<load-base> <final-exec-addr>\n");
+                "<load-base>\n");
         return 1;
     }
 
     if ( !strcmp(argv[1], "--notes") )
     {
+        if ( argc < 5 )
+            goto help;
         i = 2;
         num_phdrs = 2;
     }
     inimage  = argv[i++];
     outimage = argv[i++];
     loadbase = strtoul(argv[i++], NULL, 16);
-    final_exec_addr = strtoull(argv[i++], NULL, 16);
 
     infd = open(inimage, O_RDONLY);
     if ( infd == -1 )
@@ -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.
+     */
+    mem_siz = ((uint32_t)in64_phdr.p_memsz + (1U << 20) - 1) & (-1U << 20);
 
     note_sz = note_base = offset = 0;
     if ( num_phdrs > 1 )
--
generated by git-patchbot for /home/xen/git/xen.git#staging



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.