[U-Boot] [PATCH v2] efi_loader: Reserve unaccessible memory

[Alexander Graf]

On 30.11.18 19:32, Heinrich Schuchardt wrote:
> On 11/30/18 2:11 AM, Alexander Graf wrote:
>> On some systems, not all RAM may be usable within U-Boot. Maybe the
>> memory maps are incomplete, maybe it's used as workaround for broken
>> DMA. But whatever the reason may be, a platform can say that it does
>> not wish to have its RAM accessed above a certain address by defining
>> board_get_usable_ram_top().
>>
>> In the efi_loader world, we ignored that hint, mostly because very few
>> boards actually have real restrictions around this.
>>
>> So let's honor the board's wish to not access high addresses during
>> boot time. The best way to do so is by indicating the respective pages
>> as "allocated by firmware". That way, Operating Systems will still
>> use the pages after boot, but before boot no allocation will use them.
>>
>> Reported-by: Baruch Siach <baruch at tkos.co.il>
>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - Reserve banks that start above ram_top
>>   - Improve inline comments
>>   - Fix 32bit target with ram_top = 0 (>=4G)
>> ---
>>  include/common.h            | 11 +++++++++++
>>  lib/efi_loader/efi_memory.c | 32 +++++++++++++++++++++++++++++---
>>  2 files changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/common.h b/include/common.h
>> index 3f69943887..8f295c2f30 100644
>> --- a/include/common.h
>> +++ b/include/common.h
>> @@ -106,6 +106,17 @@ int mdm_init(void);
>>  void board_show_dram(phys_size_t size);
>>  
>>  /**
>> + * Get the uppermost pointer that is valid to access
>> + *
>> + * Some systems may not map all of their address space. This function allows
>> + * boards to indicate what their highest support pointer value is for DRAM
>> + * access.
>> + *
>> + * @param total_size	Size of U-Boot (unused?)
>> + */
>> +ulong board_get_usable_ram_top(ulong total_size);
>> +
>> +/**
>>   * arch_fixup_fdt() - Write arch-specific information to fdt
>>   *
>>   * Defined in arch/$(ARCH)/lib/bootm-fdt.c
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> index f225a9028c..3392af59a1 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -551,8 +551,13 @@ efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
>>  
>>  __weak void efi_add_known_memory(void)
>>  {
>> +	u64 ram_top = board_get_usable_ram_top(0) & ~EFI_PAGE_MASK;
>>  	int i;
>>  
>> +	/* Fix for 32bit targets with ram_top at 4G */
>> +	if (!ram_top)
>> +		ram_top = U32_MAX;
> 
> Why don't you set ram_top to (1 << 32)? ram_top is u64 anyway. We do not
> want something ending with 0xfff to be passed to efi_add_memory_map.

Ugh, yes. Of course. And obviously that's 0x100000000ULL to make sure it
works fine on 32bit :).

> Are we sure there will never be 64bit machines with a memory bank ending
> at 1 << 64? What would be the value of ram_end and ram_top in such a case?

I think we can be pretty sure of that, yes :). No machine today even
comes close to that many physical address bits supported.


Alex