From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Daniel Smith" <dpsmith@apertussolutions.com>,
"Frediano Ziglio" <frediano.ziglio@cloud.com>
Subject: Xen.efi "must be loaded below 4Gb"
Date: Thu, 2 Jan 2025 16:26:28 +0000 [thread overview]
Message-ID: <0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com> (raw)
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
next reply other threads:[~2025-01-02 16:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-02 16:26 Andrew Cooper [this message]
2025-01-02 16:30 ` Xen.efi "must be loaded below 4Gb" Marek Marczykowski-Górecki
2025-01-02 16:41 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b4d4fa4-7d8e-444e-a4a0-f2dc677178a5@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=dpsmith@apertussolutions.com \
--cc=frediano.ziglio@cloud.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.