RE: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > 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




[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux