From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Matt Fleming <matt@codeblueprint.co.uk>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Leif Lindholm <leif.lindholm@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Matt Fleming <matt.fleming@intel.com>,
Mark Rutland <mark.rutland@arm.com>,
Mark Salter <msalter@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Denys Vlasenko <dvlasenk@redhat.com>,
Brian Gerst <brgerst@gmail.com>
Subject: Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions
Date: Sun, 27 Sep 2015 12:40:14 +0200 [thread overview]
Message-ID: <20150927104014.GA7631@pd.tnic> (raw)
In-Reply-To: <20150927070644.GC26125@gmail.com>
On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote:
> Could we please re-list all the arguments pro and contra of 1:1 physical mappings,
> in a post that also explains the background so that more people can chime in, not
> just people versed in EFI internals? It's very much possible that a bad decision
> was made.
The main reason why we did the additional, top-down mapping was kexec
kernel wanting to use UEFI runtime facilities too and the braindead
design of SetVirtualAddressMap() being callable only once per system
boot. So we had to have stable mappings which are valid in the kexec-ed
kernel too.
But this was long time ago and I most certainly have forgotten all the
details.
And now I'm wondering why didn't we do the 1:1 thing and rebuild the
exact same EFI pagetable in the kexec-ed kernel? Because when we do
an EFI call, we switch to the special pagetable so why didn't we make
the kexec-ed kernel rebuild the 1:1 pagetable which it can use for EFI
calls...
Hmm, again, I've forgotten a lot of details so I'm sure Matt will come
in and say "No, you can't do that because..."
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2015-09-27 10:15 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 22:02 [GIT PULL 0/2] EFI urgent fixes Matt Fleming
2015-09-25 22:02 ` [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime Matt Fleming
2015-09-26 5:56 ` Ingo Molnar
2015-09-26 6:44 ` Ard Biesheuvel
2015-09-26 13:43 ` Matt Fleming
2015-09-27 7:03 ` Ingo Molnar
2015-09-28 6:49 ` Ard Biesheuvel
2015-09-28 8:22 ` Ingo Molnar
2015-09-28 9:51 ` Ard Biesheuvel
2015-09-29 9:12 ` Ingo Molnar
2015-09-29 10:41 ` Ard Biesheuvel
2015-09-29 14:18 ` Matt Fleming
2015-09-29 13:52 ` Matt Fleming
2015-09-26 17:01 ` Andy Lutomirski
2015-09-26 17:20 ` H. Peter Anvin
2015-09-26 18:15 ` Ard Biesheuvel
2015-09-26 19:49 ` H. Peter Anvin
2015-09-26 19:57 ` Matt Fleming
2015-09-26 20:09 ` Ard Biesheuvel
2015-09-26 20:19 ` H. Peter Anvin
2015-09-27 16:30 ` Andy Lutomirski
2015-09-27 18:06 ` Matthew Garrett
2015-09-28 6:16 ` Ingo Molnar
2015-09-28 6:41 ` Matthew Garrett
2015-09-29 21:58 ` Laszlo Ersek
2015-09-30 9:30 ` Ard Biesheuvel
2015-09-30 16:43 ` Andy Lutomirski
2015-09-30 17:24 ` James Bottomley
2015-09-30 0:54 ` H. Peter Anvin
2015-09-26 19:55 ` Matt Fleming
2015-09-27 6:50 ` Ingo Molnar
2015-10-01 12:48 ` [tip:core/urgent] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down tip-bot for Matt Fleming
2015-10-02 9:44 ` Matt Fleming
2015-09-25 22:02 ` [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions Matt Fleming
2015-09-26 6:01 ` Ingo Molnar
2015-09-26 7:08 ` Ard Biesheuvel
2015-09-27 7:06 ` Ingo Molnar
2015-09-27 10:40 ` Borislav Petkov [this message]
2015-09-28 6:20 ` Ingo Molnar
2015-09-29 9:31 ` Dave Young
2015-09-29 10:24 ` Borislav Petkov
2015-09-29 14:36 ` Matt Fleming
2015-09-30 0:56 ` H. Peter Anvin
2015-09-30 8:33 ` Borislav Petkov
2015-09-30 1:03 ` H. Peter Anvin
2015-09-30 1:16 ` Andy Lutomirski
2015-09-30 1:19 ` H. Peter Anvin
2015-09-30 4:24 ` Ard Biesheuvel
2015-10-01 10:44 ` Ingo Molnar
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=20150927104014.GA7631@pd.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=brgerst@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=matt.fleming@intel.com \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=msalter@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.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).