On 03/18/2013 11:04 AM, Matt Fleming wrote:
> On 03/18/2013 03:32 PM, David Woodhouse wrote:
>> On Mon, 2013-03-18 at 15:16 +0000, Matt Fleming wrote:
>>>
>>> See,
>>>
>>> commit 53b87cf0 ("x86, mm: Include the entire kernel memory map in trampoline_pgd"),
>>> commit 185034e7 ("x86, efi: 1:1 pagetable mapping for virtual EFI calls"),
>>> commit da5a108d05b4 ("x86/kernel: remove tboot 1:1 page table creation code") and
>>> commit bd52276fa1d4 ("x86-64/efi: Use EFI to deal with platform wall clock (again)")
>>>
>>> and the two revert commits from Linus, be354f40 and 11520e5e.
>>
>> Thanks. That seems like a rather scary approach. I was thinking of just
>> setting up a dedicated kernel thread for making runtime services calls,
>> and giving it some "userspace" page tables with a 1:1 mapping. No
>> messing around with %cr3 directly.
>
> How would that work? Would it be a real, executable thread context as
> opposed to just an address space? In which case would we be passing data
> to this thread for it to execute on our behalf? One thing to be aware of
> is that sometimes we need to make EFI calls when the sky is falling,
> such as writing EFI variables in the pstore code paths when crashing.
> Scheduling things at that point may be difficult.
>
> Provided that you can still do things like that, it seems like a nice
> solution.
>
What is the point?
We don't need the scheduler to be involved, we just want to do a
temporary context switch. We can't preempt EFI anyway, so given that,
we are non-preemptable and switching %cr3 is fine.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
