From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Jan Beulich <JBeulich@novell.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH, RFC] x86: move trampoline location
Date: Wed, 10 Feb 2010 09:36:42 +0000 [thread overview]
Message-ID: <C7982EAA.9AF6%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <4B71754B020000780002E78A@vpn.id2.novell.com>
On 09/02/2010 13:46, "Jan Beulich" <JBeulich@novell.com> wrote:
> A partner of ours is reporting boot failures (Xen not even emitting a
> single message) over iSCSI on new (UEFI based) systems. After
> pointing at their BIOS initially I finally remembered to take a look
> at the memory map a native kernel booted this way see - and voila, the
> BIOS reports memory starting at 0x8d000 as reserved. Xen, however,
> places about 12k of (trampoline) data at 0x8c000.
>
> Not having got testing feedback on the below patch yet, I still wanted
> to raise the question whether for 4.0 we should go with a simplistic
> fix like this, or whether we shouldn't really determine the trampoline
> location dynamically (i.e. honoring the E820 data) since it obviously
> cannot be excluded that other BIOSes might reserve even more of the
> space below 640k.
Looks fine to me, for 4.0.0 and 3.4.3. I'm not sure whether dynamic
placement based on E820 info is worthwhile. If all systems have an available
region from about address 0x0 up to some delta below EBDA etc, then why not
statically place the trampoline/reloc code to account for the largest such
delta ever observed? The main danger in going to lower addresses I think is
some bootloaders stick multiboot structures down there, which would get
obliterated by our 32-bit relocator.
-- Keir
prev parent reply other threads:[~2010-02-10 9:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 13:46 [PATCH, RFC] x86: move trampoline location Jan Beulich
2010-02-10 9:36 ` Keir Fraser [this message]
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=C7982EAA.9AF6%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).