lkml.org 
[lkml]   [2016]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Map in physical addresses in efi_map_region_fixed
On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> (Cc'ing Boris and Dave)
>
> On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > This is a simple change to add in the physical mappings as well as the
> > virtual mappings in efi_map_region_fixed. The motivation here is to
> > get access to EFI runtime code that is only available via the 1:1
> > mappings on a kexec'd kernel.

So I don't understand: the whole jumping through hoops so that we have
stable virtual mappings just so that the kexec-ed kernel can call EFI
runtime, is now useless?!

What if the physical address is occupied by the kexec kernel?

Why do you guys need the physical mapping all of a sudden?

Your patch is basically rendering all the effort moot and we could've
saved ourselves all that trouble of doing all that virtual address
mapping and done the 1:1 thing.

Which really is probably simpler since we have an EFI-specific page
table and running EFI in the kexec-ed kernel would mean basically
recreating it.

What am I missing?

commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c
Author: Borislav Petkov <bp@suse.de>
Date: Thu Oct 31 17:25:08 2013 +0100

x86/efi: Runtime services virtual mapping

We map the EFI regions needed for runtime services non-contiguously,
with preserved alignment on virtual addresses starting from -4G down
for a total max space of 64G. This way, we provide for stable runtime
services addresses across kernels so that a kexec'd kernel can still use
them.

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

\
 
 \ /
  Last update: 2016-09-17 09:56    [W:0.141 / U:2.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site