From: Matt Fleming <matt@codeblueprint.co.uk>
To: Peter Jones <pjones@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromium.org>,
Junjie Mao <eternal.n08@gmail.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
Date: Thu, 12 Feb 2015 14:59:42 +0000 [thread overview]
Message-ID: <20150212145942.GE4665@codeblueprint.co.uk> (raw)
In-Reply-To: <20150211162958.GA18062@fenchurch.internal.datastacks.com>
On Wed, 11 Feb, at 11:29:58AM, Peter Jones wrote:
>
> From grub's point of view I'm not sure why we'd care - the pages kernel
> and initramfs land in are both from the Boot Services allocator, so if the
> machine doesn't support high addresses, they won't be there.
It's not that some implementations don't "support" higher addresses,
it's that the EFI_FILE_PROTOCOL is buggy and it corrupts the memory when
reading into it; you can allocate it just fine. At least, that's what I
remember from the limited investigation I performed.
But since grub doesn't use EFI_FILE_PROTOCOL, we should be cool.
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-02-12 14:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 2:03 [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G Yinghai Lu
2015-02-05 3:25 ` Dave Young
2015-02-05 5:25 ` Yinghai Lu
2015-02-05 6:09 ` Dave Young
2015-02-18 7:29 ` Yinghai Lu
2015-02-09 18:27 ` Matt Fleming
2015-02-09 20:23 ` Yinghai Lu
[not found] ` <CAE9FiQUFO4yfEVgGZ9U0Q-RaokFor1gMbKJ7As2vvqGVkqrDbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-11 15:55 ` Matt Fleming
2015-02-11 15:55 ` Matt Fleming
2015-02-11 16:29 ` Peter Jones
2015-02-12 14:59 ` Matt Fleming [this message]
2015-02-11 6:11 ` Baoquan He
2015-02-18 7:22 ` Yinghai Lu
2015-02-18 11:29 ` Baoquan He
2015-02-18 19:47 ` Yinghai Lu
2015-02-20 2:13 ` Baoquan He
2015-02-20 3:35 ` Yinghai Lu
2015-02-20 9:28 ` Baoquan He
2015-02-20 23:53 ` Yinghai Lu
2015-02-21 2:49 ` Baoquan He
2015-02-21 20:00 ` Yinghai Lu
2015-02-22 13:18 ` Baoquan He
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=20150212145942.GE4665@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=corbet@lwn.net \
--cc=eternal.n08@gmail.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=pjones@redhat.com \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.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.