Feedback-ID: ieff94742:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-206-g57c8fdedf8-fm-20230227.001-g57c8fded
Mime-Version: 1.0
Message-Id: <5454ba91-c7f8-49fc-af76-ebb85d20742a@app.fastmail.com>
In-Reply-To: <ZAG5fvRl4Z+3vGfS@linux.ibm.com>
References: <20210601075354.5149-2-rppt@kernel.org>
 <162274330352.29796.17521974349959809425.tip-bot2@tip-bot2>
 <7d344756-aec4-4df2-9427-da742ef9ce6b@app.fastmail.com>
 <ZAG5fvRl4Z+3vGfS@linux.ibm.com>
Date:   Mon, 06 Mar 2023 16:33:16 -0800
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Mike Rapoport" <rppt@linux.ibm.com>
Cc:     "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        "Borislav Petkov" <bp@suse.de>, "Hugh Dickins" <hughd@google.com>,
        "the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [tip: x86/urgent] x86/setup: Always reserve the first 1M of RAM
Content-Type: text/plain
Precedence: bulk

On Fri, Mar 3, 2023, at 1:10 AM, Mike Rapoport wrote:
> Hi Andy,
>
> On Wed, Mar 01, 2023 at 07:51:43PM -0800, Andy Lutomirski wrote:
>> On Thu, Jun 3, 2021, at 11:01 AM, tip-bot2 for Mike Rapoport wrote:
>> >
>> > x86/setup: Always reserve the first 1M of RAM
>> >
>
> ...
>
>> +       /*
>> +        * Unconditionally reserve the entire fisrt 1M, see comment in
>> +        * setup_arch().
>> +        */
>> +       memblock_reserve(0, SZ_1M);
>> 
>> 
>> But this runs even if we just failed to allocate a trampoline on the
>> first try, again dooming the kernel to panic.
>> 
>> I real the commit message and the linked bug, and I'm having trouble
>> finding evidence of anything actually fixed by this patch.  Can we just
>> revert it?  If not, it would be nice to get a fixup patch that genuinely
>> cleans this up -- the whole structure of the code (first, try to allocate
>> trampoline, then free boot services, then try again) isn't really
>> conducive to a model where we *don't* free boot services < 1M.
> 
> Currently, the second attempt to set_real_mode_mem() in
> efi_free_boot_services() does not allocate from memblock anyway but reuses
> memory freed from EFI services. Could be that failure to boot caused by
> another failing reservation?

I'm not actually sure what's wrong per se.  Certainly efi=debug will utterly break my quirk, but other than that, I would have expected it to still work on a more careful reading.

Anyway, I have a fixup series that works in a VM that i'll test in a bit.

> 
>> Discovered by my delightful laptop, which does not boot with this patch applied.
>
> Do you have early_printk() visible? 

Yes, but I haven't found a smoking gun yet.

> 
>> --Andy
>
> -- 
> Sincerely yours,
> Mike.