x86/EFI: don't apply relocations to l{2,3}_bootmap
authorJan Beulich <jbeulich@suse.com>
Fri, 19 Aug 2016 15:03:33 +0000 (17:03 +0200)
committerJan Beulich <jbeulich@suse.com>
Fri, 19 Aug 2016 15:03:33 +0000 (17:03 +0200)
Other than claimed in commit 2ce5963727's ("x86: construct the
{l2,l3}_bootmap at compile time") the initialization of the two page
tables doesn't take care of everything without furher adjustment: The
compile time initialization obviously requires base relocations, and
those get processed after efi_arch_memory_setup(). Hence without
additional care the correctly initialized values may then get wrongly
"adjusted" again. Except the two table from being subject to base
relocation.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com>
xen/arch/x86/efi/efi-boot.h

index 1fa9e474266ca79fb41fc4b17c7630503659ccca..2ae4de12e5f6f2eadcbb7ebf2148fa04392f0fc0 100644 (file)
@@ -47,11 +47,23 @@ static void __init efi_arch_relocate_image(unsigned long delta)
 
     for ( base_relocs = __base_relocs_start; base_relocs < __base_relocs_end; )
     {
-        unsigned int i, n;
+        unsigned int i = 0, n;
 
         n = (base_relocs->size - sizeof(*base_relocs)) /
             sizeof(*base_relocs->entries);
-        for ( i = 0; i < n; ++i )
+
+        /*
+         * Relevant l{2,3}_bootmap entries get initialized explicitly in
+         * efi_arch_memory_setup(), so we must not apply relocations there.
+         * l2_identmap's first slot, otoh, should be handled normally, as
+         * efi_arch_memory_setup() won't touch it (xen_phys_start should
+         * never be zero).
+         */
+        if ( xen_phys_start + base_relocs->rva == (unsigned long)l3_bootmap ||
+             xen_phys_start + base_relocs->rva == (unsigned long)l2_bootmap )
+            i = n;
+
+        for ( ; i < n; ++i )
         {
             unsigned long addr = xen_phys_start + base_relocs->rva +
                                  (base_relocs->entries[i] & 0xfff);