Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page table mappings

[Ingo Molnar <mingo@kernel.org>]

* Andy Lutomirski <luto@amacapital.net> wrote:

> >> I mean the one in efi_call_virt.  Why would the spec mandate a TLB flush at 
> >> all?  EFI runtime services have no business touching the paging structures 
> >> directly.  Heck, the 32-bit ones don't even know the *format* of the paging 
> >> structures.
> >
> > Right, and it would necessitate copying out arguments because the firmware 
> > won't understand where/how the kernel has mapped things.
> >
> > No firmware is going to be doing that.
> 
> Just so I understand correctly: could we get away with putting the EFI virtual 
> runtime mappings at positive (user) addresses for 64-bit UEFI, or is there some 
> reason that we need the high bit set?
> 
> If we could use positive addresses, then we could use the existing use_mm 
> infrastructure directly with no funny business at all except to the extent that 
> we might need to use unusual APIs to set up the VMAs (if we use real VMAs) in 
> the first place.  (We could cheat and allocate a single monstrous VM_MIXEDMAP or 
> VM_PFNMAP vma with a .fault handler that always fails.)  If we have to use 
> negative addresses, then we'll always be stuck with a funny pgd, but we could 
> still probably use use_mm instead of manually fiddling with cr3.

Would be nice to get an answer to these questions. The more we isolate firmware 
execution into 'regular' MM concepts, the more robust it all becomes.

> Some day I want to experiment with calling runtime services at CPL 3, too :)

That would be an interesting isolation method as well ...

Thanks,

	Ingo