All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.