From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <Wei.Liu2@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Request to revert superpage adjustments
Date: Fri, 11 Mar 2016 05:06:45 -0700 [thread overview]
Message-ID: <56E2C2E502000078000DB945@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56E28E61.5060003@citrix.com>
>>> On 11.03.16 at 10:22, <andrew.cooper3@citrix.com> wrote:
> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
> exposes a bug in all Syslinux variants, including ISOlinux and
> PXELinux, causing a failure to boot.
>
> Xen currently requires its bootloader to decompress it, and place it at
> the 1MB physical boundary. The alignment adjustments changed the size
> of the decompressed (post mkelf32) image from 2.2MB to 7.1MB. These
> restrictions should be fixed independently of this exposed bug. The
> physical range between 0x100000 and 0x10fffe is prime clobbering space
> for buggy BIOSes once the A20 line has been disabled (see c/s 1ed76797),
> and if any reserved memory exists between 1MB and 1MB+sizeof(xen), the
> bootloader wont be able to place Xen at its linked address.
>
> Grub and iPXE work perfectly well when booting Xen, which is why this is
> now clearly a Syslinux issue (all versions I cared to test, including
> 4.x and 6.3 are broken). However, it clobbers any ability for XenServer
> to do testing, as we PXEBoot our servers for install. I expect a lot of
> other people will encounter issues once the 4.7 RCs get tested.
>
> Please revert c/s cf393624 and the following change (c/s 53aa3dde) which
> depends upon the former, until I can work around the existing
> restrictions. After the restrictions are resolved, the patches can go
> back in, but I am fairly sure I will not have time to resolve the issues
> in the 4.7 timeframe.
I'm kind of hesitant to do a wholesale revert, for two reasons:
1) The change would still be useful for xen.efi, which is relocatable
already anyway.
2) I cannot currently see how you mean to address the issue:
Even if you made our binary decompress itself, that would only
paper over the issue, and (based on your description) only until
even the compressed image exceeds a certain size. Nor would
that deal with avoiding reserved regions not too far above 1Mb,
since at best the main payload can be relocatable (but certainly
not the binary seen by the boot loader, as at least multiboot1
doesn't support anything like that).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-11 12:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 9:22 Request to revert superpage adjustments Andrew Cooper
2016-03-11 12:06 ` Jan Beulich [this message]
2016-03-11 13:21 ` Andrew Cooper
2016-03-11 14:13 ` Jan Beulich
2016-03-11 14:35 ` Konrad Rzeszutek Wilk
2016-03-11 18:10 ` Daniel Kiper
2016-03-11 14:44 ` 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=56E2C2E502000078000DB945@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=Wei.Liu2@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xen.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 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).