From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables
Date: Fri, 19 Aug 2016 06:57:16 -0600 [thread overview]
Message-ID: <57B71E4C02000078001076CB@prv-mh.provo.novell.com> (raw)
In-Reply-To: <aa9e18cb-a5a9-a7a4-c25e-1f0b5b268a5c@citrix.com>
>>> On 19.08.16 at 14:39, <andrew.cooper3@citrix.com> wrote:
> On 19/08/16 08:52, Jan Beulich wrote:
>> Page tables get pre-populated with physical addresses which, due to
>> living inside the Xen image, will never exceed 32 bits in width. That
>> in turn results in the tool generating the relocations to produce
>> 32-bit relocations for them instead of the 64-bit ones needed for
>> relocating virtual addresses. Hence instead of special casing page
>> tables in the processing of 64-bit relocations, let's be more rigid
>> and refuse them (as being indicative of something else having gone
>> wrong in the build process).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Is it an ABI requirement to use the minimal available relocation? It is
> certainly suboptimal to use a 64bit relocation when a 32bit one would
> do, but I wouldn't bet that it is unconditional avoided by all toolchains.
What ABI? The tool in question is one of our own making. And the
way relocations get generated it's hard to tell those that have to
be 32-bit (in early boot code and trampoline code) from those that
may as well be 64-bit ones (in page tables).
> It is currently the case that Xen needs to live below 4GB physical, so
> from that point of view a 64bit relocation will not be required in the
> pagetables.
And even if Xen didn't itself have this requirement, the EFI loader
would always put us below 4Gb.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-08-19 12:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 7:39 [PATCH 0/3] x86/EFI: boot adjustments Jan Beulich
2016-08-19 7:50 ` [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap Jan Beulich
2016-08-19 10:34 ` Andrew Cooper
2016-08-19 12:05 ` Jan Beulich
2016-08-19 7:51 ` [PATCH 2/3] x86/EFI: be cautious about being handed control with CR4.PGE enabled Jan Beulich
2016-08-19 12:26 ` Andrew Cooper
2016-08-19 7:52 ` [PATCH 3/3] x86/EFI: don't accept 64-bit base relocations on page tables Jan Beulich
2016-08-19 12:39 ` Andrew Cooper
2016-08-19 12:57 ` Jan Beulich [this message]
2016-08-30 16:35 ` Andrew Cooper
2016-08-31 12:28 ` Jan Beulich
2016-08-31 12:32 ` Andrew Cooper
2016-08-31 13:03 ` Jan Beulich
2016-08-30 16:18 ` Ping: " Jan Beulich
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=57B71E4C02000078001076CB@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@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.