[xen stable-4.20] x86/mkelf32: Actually pad load segment to 2 MiB boundary

[patchbot@xxxxxxx]

commit ad5d9554482739052a4a70711b21e48c02a515d1
Author:     Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
AuthorDate: Mon Apr 20 12:39:07 2026 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Apr 20 12:39:07 2026 +0200

    x86/mkelf32: Actually pad load segment to 2 MiB boundary
    
    Fix the code which tries to pad the load segment to 2 MiB but only pads
    it to a 1 MiB boundary.
    
    This manifests as a page fault while scrubbing RAM during boot on certain
    systems.
    
    Xen fails to mark itself as reserved in the E820 (due to spanning multiple
    regions), but does restrict the permissions in the directmap.  The region of
    RAM containing Xen is handed to physical memory manager as available for 
use,
    and scrubbing hit the directmap protections.
    
    Fixes: 4fb075201f54 ("x86/mkelf32: pad load segment to 2Mb boundary")
    Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 5416c455f656af9ff3ed7f26dcd5cbf70b254f23
    master date: 2026-04-17 18:15:54 +0100
---
 xen/arch/x86/boot/mkelf32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index 373ba4ddd5..469d1ba0af 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -345,7 +345,7 @@ int main(int argc, char **argv)
      * 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);
+    mem_siz = ((uint32_t)in64_phdr.p_memsz + (1U << 21) - 1) & (-1U << 21);
 
     note_sz = note_base = offset = 0;
     if ( num_phdrs > 1 )
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.20