Re: Xen.efi "must be loaded below 4Gb"

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 02/01/2025 4:30 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 02, 2025 at 04:26:28PM +0000, Andrew Cooper wrote:
>> Hello,
>>
>> Forwarding a bug report from IRC from before Christmas:
>>
>> ---
>> bit of a random question, but: has anyone had any luck booting efi
>> builds of Xen? over the last year or so I've tried 4.18 and 4.19, Alpine
>> and Fedora builds, and on a Dell PowerEdge R430 and an Optiplex 7010
>> Plus, and in every case received an error that "Xen must be loaded below
>> 4Gb"
>> ---
>>
>> The Xen.efi path does expect to be loaded below 4G, and does give up
>> rather than relocating itself.
>>
>> Right now, I'm aware of at least one blocker to xen.efi being able to
>> relocate itself, and that is because it populates the MB1 metadata with
>> physical pointers into the ebmalloc[] region, which is in .bss.  
> What about not touching anything MB1-related in the EFI boot path? MB1
> can't possibly work on EFI, right?

All paths in Xen currently convert bootloader data in MB1 format to
__start_xen().

Then (as of the start of the Hyperlaunch series), __start_xen()
transforms it into struct boot_info.

While it might not sound like it, this was the right course of action
(IMO) for the Hyperlaunch series; there was simply too many things
needing untangling in the boot path to do it all in one go.

>> Fallout
>> related to this was the subject of c/s 0fe607b2a1 "x86/boot: Fix PVH
>> boot during boot_info transition period" and a protective ASSERT() included.
>>
>> The ProperFix(tm) is to remove ebmalloc(), and the scratch space in the
>> trampoline, and instead have a range in initdata to stash the bootloader
>> metadata, and use virtual pointers rather than physical.  This also
>> avoids us double/triple handling the bootloader metadata, simplifying
>> all aspects of the startup logic.
> This obviously would be better
>

The end goal IMO is to have each boot path fill in struct boot_info
directly, but they need somewhere to stash the metadata, and preferably
not in the trampoline.

A 64k region in initdata ought to be sufficient, and anyone needing to
be more fancy can see about stea^W borrowing the BRK infrastructure from
Linux.

~Andrew