Re: [PATCH 2/3] x86/boot: Drop move_memory() and use memcpy() directly

2021-12-09 Thread Jan Beulich
On 09.12.2021 20:58, Andrew Cooper wrote: > On 07/12/2021 12:03, Jan Beulich wrote: >> On 07.12.2021 11:53, Andrew Cooper wrote: >>> @@ -1243,7 +1196,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) >>> * data until after we have switched to the relocated >>> pagetables!

Re: [PATCH 2/3] x86/boot: Drop move_memory() and use memcpy() directly

2021-12-09 Thread Andrew Cooper
On 07/12/2021 12:03, Jan Beulich wrote: > On 07.12.2021 11:53, Andrew Cooper wrote: >> @@ -1243,7 +1196,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) >> * data until after we have switched to the relocated >> pagetables! >> */ >> barrier(); >>

Re: [PATCH 2/3] x86/boot: Drop move_memory() and use memcpy() directly

2021-12-07 Thread Jan Beulich
On 07.12.2021 11:53, Andrew Cooper wrote: > @@ -1243,7 +1196,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 -

[PATCH 2/3] x86/boot: Drop move_memory() and use memcpy() directly

2021-12-07 Thread Andrew Cooper
The way move_memory() sets up the virtual mappings means that there are always two non-overlapping regions. The virtual layout means that memmove()'s forward/backwards check doesn't do what the caller intends, as the check ought to be performed in physical space rather than virtual. Luckily both