Re: [PATCH][EFI] Run EFI in physical mode

From: H. Peter Anvin
Date: Sun Aug 15 2010 - 23:29:47 EST


No, it should not be dynamic; rather we should unify all the users who need a 1:1 map and just keep that page table set around.

"huang ying" <huang.ying.caritas@xxxxxxxxx> wrote:

>On Sat, Aug 14, 2010 at 3:18 AM, Takao Indoh <indou.takao@xxxxxxxxxxxxxx> wrote:
>> diff -Nurp linux-2.6.35.org/arch/x86/kernel/efi_64.c linux-2.6.35/arch/x86/kernel/efi_64.c
>> --- linux-2.6.35.org/arch/x86/kernel/efi_64.c  2010-08-01 18:11:14.000000000 -0400
>> +++ linux-2.6.35/arch/x86/kernel/efi_64.c    2010-08-13 14:39:25.819105004 -0400
>> @@ -39,7 +39,9 @@
>> Â#include <asm/fixmap.h>
>>
>> Âstatic pgd_t save_pgd __initdata;
>> -static unsigned long efi_flags __initdata;
>> +static unsigned long efi_flags;
>> +static pgd_t efi_pgd[PTRS_PER_PGD] __page_aligned_bss;
>> +static unsigned long save_cr3;
>>
>> Âstatic void __init early_mapping_set_exec(unsigned long start,
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âunsigned long end,
>> @@ -98,6 +100,19 @@ void __init efi_call_phys_epilog(void)
>> Â Â Â Âearly_runtime_code_mapping_set_exec(0);
>> Â}
>>
>> +void efi_call_phys_prelog_in_physmode(void)
>> +{
>> + Â Â Â local_irq_save(efi_flags);
>> + Â Â Â save_cr3 = read_cr3();
>> + Â Â Â write_cr3(virt_to_phys(efi_pgd));
>> +}
>> +
>> +void efi_call_phys_epilog_in_physmode(void)
>> +{
>> + Â Â Â write_cr3(save_cr3);
>> + Â Â Â local_irq_restore(efi_flags);
>> +}
>
>efi_flags and save_cr3 should be per-CPU, because they now will be
>used after SMP is enabled.
>
>efi_pgd should be dynamically allocated instead of statically
>allocated, because EFI may be not enabled on some platform.
>
>And I think it is better to unify early physical mode with run-time
>physical mode. Just allocate the page table with early page allocator
>(lmb?).
>
>Best Regards,
>Huang Ying
>

--
Sent from my mobile phone. Please pardon any lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/