Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code

[Matt Fleming <matt@codeblueprint.co.uk>]

On Thu, 21 Jul, at 03:45:14PM, Andy Lutomirski wrote:
> 
> I looked at the code some more.  The boot services quirk is weird and
> maybe buggy.  trim_snb_memory uses memblock_reserve to reserve the
> bottom 1MB.  If efi_reserve_real_mode has already reserved that range,
> then trim_snb_memory's reservation will have no effect because the efi
> code will just free it later on.  The same issue will hit any code
> that reserves >1MB memory after efi has tried to temporarily reserve
> it.
 
Yeah, that looks like a bug. memblock_reserve() reference counting,
anyone?

> I don't have any great suggestions for cleaning it up.  Perhaps the
> efi code should instead skip adding boot services memory to the memory
> map in the first place and then add it late and hand any unreserved
> bits to the buddy allocator?

The issue is that some data required at runtime may be contained in
those boot services data regions; the EFI System Resource Table is a
good example or the ACPI BGRT table. esrt_init() happens pretty early
but efi_bgrt_init() is really late in boot because we need the ACPI
subsystem to have been brought up.

Fundamentally, you can't know whether you can use the boot services
regions for allocation until after SetVirtualAddressMap() has been
called (the original bug that required the reservation quirks occurs
at SVAM time) and after drivers have read the EFI config tables and
marked their regions as reserved.

I suppose we could rewrite the page table mapping for those precious
<1MB regions to coerce the firmware into accessing different pages
instead of the 1:1 addresses and copy the regions elsewhere. Maybe.
That assumes we don't hit other firmware bugs though.