grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/4] efi: Fix requests to allocate GRUB_MEMORY_AVAILABLE


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH 2/4] efi: Fix requests to allocate GRUB_MEMORY_AVAILABLE
Date: Mon, 18 Nov 2013 17:58:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 13.11.2013 03:26, Josh Triplett wrote:
> EFI firmware refuses to allocate memory of type
> GRUB_EFI_CONVENTIONAL_MEMORY, because that indicates a block of
> available memory that other allocations (or the OS) would then step on.
> Map GRUB_MEMORY_AVAILABLE to GRUB_EFI_LOADER_CODE instead.
> ---
> 
> ChangeLog entry:
> 
> 2013-11-13  Josh Triplett  <address@hidden>
> 
>       * grub-core/mmap/efi/mmap.c (make_efi_memtype): Map
>         GRUB_MEMORY_AVAILABLE to GRUB_EFI_LOADER_CODE rather than
>         GRUB_EFI_CONVENTIONAL_MEMORY.  EFI firmware refuses to allocate
>         memory of type GRUB_EFI_CONVENTIONAL_MEMORY, because that
>         indicates a block of available memory that other allocations (or
>         the OS) would then step on.
> 
"allocating" with type GRUB_MEMORY_AVAILABLE isn't actually allocating
but declaring a new chunk of available memory not discovered by
firmware. Up until now we've never actually needed it
>  grub-core/mmap/efi/mmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/grub-core/mmap/efi/mmap.c b/grub-core/mmap/efi/mmap.c
> index a77efe8..e6cd185 100644
> --- a/grub-core/mmap/efi/mmap.c
> +++ b/grub-core/mmap/efi/mmap.c
> @@ -146,7 +146,7 @@ make_efi_memtype (int type)
>        return GRUB_EFI_UNUSABLE_MEMORY;
>  
>      case GRUB_MEMORY_AVAILABLE:
> -      return GRUB_EFI_CONVENTIONAL_MEMORY;
> +      return GRUB_EFI_LOADER_CODE;
>  
>      case GRUB_MEMORY_ACPI:
>        return GRUB_EFI_ACPI_RECLAIM_MEMORY;
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]