lkml.org 
[lkml]   [2018]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd
Date
> > > For the short term, could we simply make your changes dependent on
> > > efi != old_map? That gives us some time to fix the old_map case properly.
> >
> > Yes, I think we could and it should work but I hesitated to propose it
> > because (as you already noted) it's a short term fix and not the right fix.
> >
>
> What is the status here?

Making the unmapping code conditional on !old_map is ready and I will send it out.
I am working on unmapping boot services code/data when old_map is enabled
and ran into issues with memblock and direct mapping in kernel. Will post those details
in a separate thread.

>
> > Alternatively, we could also evaluate if we need to support efi=old_map case
> going further.
> > I thought dropping it would be a bad idea because it changes kernel
> > user visible interface (because it's a kernel command line argument) and never
> brought it up.
> > Not sure what Thomas, Ingo or Linus might think about dropping a
> > kernel command line argument.
> >
>
> Dropping a command line argument is not a problem in itself, unless anyone is
> actively using it :-)
>
> As far as I can tell, the SGI x86 UV platforms still rely on this, so we're stuck with
> it for the foreseeable future.

Thanks (also Boris) for the info. Makes sense why we need efi=old_map.

>
> This means we need a fixes that makes your unmapping code conditional on
> !old_memmap. Do you have an ETA for that?

Sure! I will do some more testing and if it works as expected, will send it before this Sunday.

Regards,
Sai
\
 
 \ /
  Last update: 2018-12-21 18:53    [W:0.071 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site