|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] x86/EFI: don't apply relocations to l{2, 3}_bootmap
>>> On 19.08.16 at 12:34, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/08/16 08:50, Jan Beulich wrote:
>> Other than claimed in commit 2ce5963727's ("x86: construct the
>> {l2,l3}_bootmap at compile time") the initialization of the two page
>> tables doesn't take care of everything without furher adjustment: The
>> compile time initialization obviously requires base relocations, and
>> those get processed after efi_arch_memory_setup(). Hence without
>> additional care the correctly initialized values may then get wrongly
>> "adjusted" again. Except the two table from being subject to base
>> relocation.
>
> Do you mean Exempt? "Except the two tables" doesn't parse.
Hmm, my dictionary tells me that "except" can be used as a verb,
and it also tells me that I rather don't mean "exempt".
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -47,11 +47,23 @@ static void __init efi_arch_relocate_ima
>>
>> for ( base_relocs = __base_relocs_start; base_relocs <
>> __base_relocs_end; )
>> {
>> - unsigned int i, n;
>> + unsigned int i = 0, n;
>>
>> n = (base_relocs->size - sizeof(*base_relocs)) /
>> sizeof(*base_relocs->entries);
>> - for ( i = 0; i < n; ++i )
>> +
>> + /*
>> + * Relevant l{2,3}_bootmap entries get initialized explicitly in
>> + * efi_arch_memory_setup(), so we must not apply relocations there.
>> + * l2_identmap's first slot, otoh, should be handled normally, as
>
> And l3 surely?
Generally yes, but the comment refers to efi_arch_memory_setup(),
which only touches l2_identmap[]. I.e. I'm trying to answer the
reasonably to raise question why it doesn't need special casing here
despite that function touching it.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |