We can relocate Xen by reading out of the virtual mapping that we're executing
on, and write directly into the directmap.  In fact, this removes one
dependency on Xen being "at 0" (the XEN_IMG_OFFSET passed as src) for
relocation to occur.

This removes all the temporary pagetable handling under the covers of
move_memory(), and results in a forward copy rather than a chunked backwards
copy (caused by move_memory() always constructing src and dst in a way to
trigger memmove() to copy backwards).

With the penultimate caller of move_memory() dropped, clean up the API.  Drop
the keep boolean, folding in 0 from the final caller, and drop the return
address which has been unused since c/s 0b76ce20de85 ("x86/setup: don't
relocate the VGA hole.") in 2007.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>

v2-ish:
 * Split out previous series.  This was the "easy to shuffle" work that still
   gets a win.  Everything else I'm going to rework differently, so will have
   to be deferred for now.
---
 xen/arch/x86/setup.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6bb5bc7c84be..4102aae76dde 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -425,8 +425,8 @@ void *__init bootstrap_map(const module_t *mod)
     return ret;
 }
 
-static void *__init move_memory(
-    uint64_t dst, uint64_t src, unsigned int size, bool keep)
+static void __init move_memory(
+    uint64_t dst, uint64_t src, unsigned int size)
 {
     unsigned int blksz = BOOTSTRAP_MAP_LIMIT - BOOTSTRAP_MAP_BASE;
     unsigned int mask = (1L << L2_PAGETABLE_SHIFT) - 1;
@@ -463,13 +463,8 @@ static void *__init move_memory(
         src += sz;
         size -= sz;
 
-        if ( keep )
-            return size ? NULL : d + doffs;
-
         bootstrap_map(NULL);
     }
-
-    return NULL;
 }
 
 #undef BOOTSTRAP_MAP_LIMIT
@@ -1277,7 +1272,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
              * data until after we have switched to the relocated pagetables!
              */
             barrier();
-            move_memory(e, XEN_IMG_OFFSET, _end - _start, 1);
+            memcpy(__va(__pa(_start)), _start, _end - _start);
 
             /* Walk idle_pg_table, relocating non-leaf entries. */
             pl4e = __va(__pa(idle_pg_table));
@@ -1334,8 +1329,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
                    "1" (__va(__pa(cpu0_stack))), "2" (STACK_SIZE / 8)
                 : "memory" );
 
-            bootstrap_map(NULL);
-
             printk("New Xen image base address: %#lx\n", xen_phys_start);
         }
 
@@ -1361,7 +1354,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
             {
                 move_memory(end - size + headroom,
                             (uint64_t)mod[j].mod_start << PAGE_SHIFT,
-                            mod[j].mod_end, 0);
+                            mod[j].mod_end);
                 mod[j].mod_start = (end - size) >> PAGE_SHIFT;
                 mod[j].mod_end += headroom;
                 mod[j].reserved = 1;
-- 
2.11.0

On 09.12.2022 22:42, Andrew Cooper wrote:
> We can relocate Xen by reading out of the virtual mapping that we're executing
> on, and write directly into the directmap.  In fact, this removes one
> dependency on Xen being "at 0" (the XEN_IMG_OFFSET passed as src) for
> relocation to occur.
> 
> This removes all the temporary pagetable handling under the covers of
> move_memory(), and results in a forward copy rather than a chunked backwards
> copy (caused by move_memory() always constructing src and dst in a way to
> trigger memmove() to copy backwards).
> 
> With the penultimate caller of move_memory() dropped, clean up the API.  Drop
> the keep boolean, folding in 0 from the final caller, and drop the return
> address which has been unused since c/s 0b76ce20de85 ("x86/setup: don't
> relocate the VGA hole.") in 2007.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>