Xen.efi "must be loaded below 4Gb"

Xen.efi "must be loaded below 4Gb"

[Andrew Cooper]

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.  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.

~Andrew

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

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

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?

> 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

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrew Cooper]

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