On Tue, Oct 28, 2014 at 9:18 AM, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> wrote:
> Instead of reserving the memory regions based on which types we know
> need to be reserved, consider only regions of the following types as
> free for general use by the OS:
>
> EFI_LOADER_CODE
> EFI_LOADER_DATA
> EFI_BOOT_SERVICES_CODE
> EFI_BOOT_SERVICES_DATA
> EFI_CONVENTIONAL_MEMORY
>
> Note that this also fixes a problem with the original code, which would
> misidentify a EFI_RUNTIME_SERVICES_DATA region as not reserved if it
> does not have the EFI_MEMORY_RUNTIME attribute set. However, it is
> perfectly legal for the firmware not to request a virtual mapping for
> EFI_RUNTIME_SERVICES_DATA regions that contain configuration tables, in
> which case the EFI_MEMORY_RUNTIME attribute would not be set.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> ---
> arch/arm64/kernel/efi.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 95c49ebc660d..2e829148fb36 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -125,17 +125,17 @@ out:
> */
> static __init int is_reserve_region(efi_memory_desc_t *md)
> {
> - if (!is_normal_ram(md))
> + switch (md->type) {
> + case EFI_LOADER_CODE:
> + case EFI_LOADER_DATA:
> + case EFI_BOOT_SERVICES_CODE:
> + case EFI_BOOT_SERVICES_DATA:
> + case EFI_CONVENTIONAL_MEMORY:
> return 0;
> -
> - if (md->attribute & EFI_MEMORY_RUNTIME)
> - return 1;
> -
> - if (md->type == EFI_ACPI_RECLAIM_MEMORY ||
> - md->type == EFI_RESERVED_TYPE)
> - return 1;
> -
> - return 0;
> + default:
> + break;
> + }
> + return is_normal_ram(md);
> }
>
> static __init void reserve_regions(void)
> --
> 1.8.3.2
>
Acked-by: Roy Franz <roy.franz@xxxxxxxxxx>
Looks good, as I expect most new types of memory that are added will
need some special treatment, and shouldn't just
be added to the available general use memory.
--
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
