Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 20 Sep 2021 12:46:56 +0300
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     Juergen Gross <jgross@suse.com>
Cc:     Borislav Petkov <bp@alien8.de>, Mike Galbraith <efault@gmx.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
        marmarek@invisiblethingslab.com, Borislav Petkov <bp@suse.de>,
        stable@vger.kernel.org, x86@kernel.org
Subject: Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier
Message-ID: <YUhYkKDe364BGb2f@linux.ibm.com>
References: <20210914094108.22482-1-jgross@suse.com>
 <163178944634.25758.17304720937855121489.tip-bot2@tip-bot2>
 <4422257385dbee913eb5270bda5fded7fbb993ab.camel@gmx.de>
 <YUdwMm9ncgNuuN4f@zn.tnic>
 <d315decb-2c95-da81-e8e9-9e4a44252656@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d315decb-2c95-da81-e8e9-9e4a44252656@suse.com>
Precedence: bulk

Hi,

On Mon, Sep 20, 2021 at 08:00:31AM +0200, Juergen Gross wrote:
> On 19.09.21 19:15, Borislav Petkov wrote:
> > On Sun, Sep 19, 2021 at 06:55:16PM +0200, Mike Galbraith wrote:
> > > On Thu, 2021-09-16 at 10:50 +0000, tip-bot2 for Juergen Gross wrote:
> > > > The following commit has been merged into the x86/urgent branch of
> > > > tip:
> > > > 
> > > > x86/setup: Call early_reserve_memory() earlier
> > > 
> > > This commit rendered tip toxic to my i4790 desktop box and i5-6200U
> > > lappy.  Boot for both is instantly over without so much as a twitch.
> > > 
> > > Post bisect revert made both all better.
> > 
> > I had a suspicion that moving stuff around like that would not just
> > simply work in all cases, as our boot order is very lovely and fragile.
> > 
> > And it booted just fine on my machines here.
> > 
> > ;-\
> > 
> > Anyway, commit zapped from the x86/urgent lineup. We'll have to have a
> > third try later.
> > 
> 
> How will that try look like? I'm seeing the following alternatives:
> 
> 1. Just revert a799c2bd29d19c565 ("x86/setup: Consolidate early memory
>    reservations").
> 
> 2. Try to move the call of early_reserve_memory() just before the call
>    of e820__memory_setup().
> 
> 3. Split early_reserve_memory() into two parts, with the first part
>    doing the memblock_reserve() calls for the kernel text, initrd and
>    page 0 right at the start of setup_arch(), and the second part for
>    the rest at the same place it is handled now.
> 
> 4. Analyze why Mike's systems fail to boot and try to fix his issue(s)
>    (probably via one of the above ways).
> 
> Looking at the calls done in early_reserve_memory() I have my doubts
> that memblock_x86_reserve_range_setup_data() will work before
> early_ioremap_init() has been called, as it is using early_memremap().
> This would suggest variant 2 could be a working solution.
> 
> In case I'm wrong with my doubts I'd prefer variant 3.

I actually prefer variant 2 to keep the early memory reservations together
as much as possible. 

I tend to agree with your doubts about
memblock_x86_reserve_range_setup_data(), but it should be fine to move
early_reserve_memory() just before e820__memory_setup().
  
Anyway, I'd like to understand why Mike's systems fail before moving on
with the fixes.

-- 
Sincerely yours,
Mike.