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

[Juergen Gross]

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:
> > >
> > > Commit-ID:     1c1046581f1a3809e075669a3df0191869d96dd1
> > > Gitweb:
> > > https://git.kernel.org/tip/1c1046581f1a3809e075669a3df0191869d96dd1
> > > Author:        Juergen Gross <jgross@xxxxxxxx>
> > > AuthorDate:    Tue, 14 Sep 2021 11:41:08 +02:00
> > > Committer:     Borislav Petkov <bp@xxxxxxx>
> > > CommitterDate: Thu, 16 Sep 2021 12:38:05 +02:00
> > >
> > > 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.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature