Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier

["Williams, Dan J" <dan.j.williams@intel.com>]

On Wed, 2021-09-22 at 17:18 +0000, tip-bot2 for Juergen Gross wrote:
> The following commit has been merged into the x86/urgent branch of
> tip:
> 
> Commit-ID:     8aa83e6395ce047a506f0b16edca45f36c1ae7f8
> Gitweb:       
> https://git.kernel.org/tip/8aa83e6395ce047a506f0b16edca45f36c1ae7f8
> Author:        Juergen Gross <jgross@suse.com>
> AuthorDate:    Mon, 20 Sep 2021 14:04:21 +02:00
> Committer:     Borislav Petkov <bp@suse.de>
> CommitterDate: Tue, 21 Sep 2021 09:52:08 +02:00
> 
> x86/setup: Call early_reserve_memory() earlier

Hi,

I got a report from Anjaneya that starting with the v5.15 kernel he can
no longer use the "efi=nosoftreserve" kernel command line parameter to
suppress "soft reservation" behavior. Recall that "soft reserved" is
the Linux designation for memory that is marked with the EFI "Special
Purpose" attribute.

By inspection, this commit looks like the source of the problem because
early_reserve_memory() now runs before parse_early_param(). I suspect
that this also affects memmap= since it is also an early_param(). I'll
verify that tomorrow when I'm more awake, but wanted to give a heads up
in the meantime.


> 
> Commit in Fixes introduced early_reserve_memory() to do all needed
> initial memblock_reserve() calls in one function. Unfortunately, the call
> of early_reserve_memory() is done too late for Xen dom0, as in some
> cases a Xen hook called by e820__memory_setup() will need those memory
> reservations to have happened already.
> 
> Move the call of early_reserve_memory() before the call of
> e820__memory_setup() in order to avoid such problems.
> 
> Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> Cc: stable@vger.kernel.org
> Link: https://lkml.kernel.org/r/20210920120421.29276-1-jgross@suse.com
> ---
>  arch/x86/kernel/setup.c | 26 ++++++++++++++------------
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 79f1641..40ed44e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -830,6 +830,20 @@ void __init setup_arch(char **cmdline_p)
>  
>         x86_init.oem.arch_setup();
>  
> +       /*
> +        * Do some memory reservations *before* memory is added to memblock, so
> +        * memblock allocations won't overwrite it.
> +        *
> +        * After this point, everything still needed from the boot loader or
> +        * firmware or kernel text should be early reserved or marked not RAM in
> +        * e820. All other memory is free game.
> +        *
> +        * This call needs to happen before e820__memory_setup() which calls the
> +        * xen_memory_setup() on Xen dom0 which relies on the fact that those
> +        * early reservations have happened already.
> +        */
> +       early_reserve_memory();
> +
>         iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
>         e820__memory_setup();
>         parse_setup_data();
> @@ -876,18 +890,6 @@ void __init setup_arch(char **cmdline_p)
>  
>         parse_early_param();
>  
> -       /*
> -        * Do some memory reservations *before* memory is added to
> -        * memblock, so memblock allocations won't overwrite it.
> -        * Do it after early param, so we could get (unlikely) panic from
> -        * serial.
> -        *
> -        * After this point everything still needed from the boot loader or
> -        * firmware or kernel text should be early reserved or marked not
> -        * RAM in e820. All other memory is free game.
> -        */
> -       early_reserve_memory();
> -
>  #ifdef CONFIG_MEMORY_HOTPLUG
>         /*
>          * Memory used by the kernel cannot be hot-removed because Linux