Messages in this thread | | | Date | Mon, 06 Mar 2023 16:33:16 -0800 | From | "Andy Lutomirski" <> | Subject | Re: [tip: x86/urgent] x86/setup: Always reserve the first 1M of RAM |
| |
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.
| |