Re: [PATCH 04/10] arm64/efi: reserve regions of type ACPI_MEMORY_NVS

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

 



On 22 October 2014 18:15, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> On Wed, Oct 22, 2014 at 03:21:47PM +0100, Ard Biesheuvel wrote:
>> Memory regions of type ACPI_MEMORY_NVS should be preserved
>> by the OS, so make sure we reserve them at boot.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>> ---
>>  arch/arm64/kernel/efi.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
>> index 95c49ebc660d..71ea4fc0aa8a 100644
>> --- a/arch/arm64/kernel/efi.c
>> +++ b/arch/arm64/kernel/efi.c
>> @@ -132,6 +132,7 @@ static __init int is_reserve_region(efi_memory_desc_t *md)
>>               return 1;
>>
>>       if (md->type == EFI_ACPI_RECLAIM_MEMORY ||
>> +         md->type == EFI_ACPI_MEMORY_NVS ||
>>           md->type == EFI_RESERVED_TYPE)
>>               return 1;
>
> Shouldn't we also filter out EFI_UNUSABLE_MEMORY? Or does that happen
> elsewhere?
>

Yes, good point.

> Perhaps instead we should invert this logic and assume memory should be
> reserved if not EfiLoaderCode, EfiLoaderData, EfiBootServicesCode,
> EfiBootServicesData, or EfiConventionalMemory. That looks to be what x86
> does.
>

That would make it more robust against new types in future spec
changes, I suppose, although that would seem unlikely.

I am happy to change the patch to take that approach instead, if
others agree that it is preferable?

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux