Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1294382

arm64/efi handling of persistent memory

Show all headers | View raw

Similar to the questions about the arm64 efi boot stub
handing persistent memory, some of the arm64 kernel code 
looks fishy.

In arch/arm64/kernel/efi.c:

static int __init is_normal_ram(efi_memory_desc_t *md)
{
        if (md->attribute & EFI_MEMORY_WB)
                return 1;
        return 0;
}

static __init int is_reserve_region(efi_memory_desc_t *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:
        case EFI_PERSISTENT_MEMORY:
                return 0;
        default:
                break;
        }
        return is_normal_ram(md);
}

static __init void reserve_regions(void)
{
...
                if (is_normal_ram(md))
                        early_init_dt_add_memory_arch(paddr, size);

                if (is_reserve_region(md)) {
                        memblock_reserve(paddr, size);
...

static bool __init efi_virtmap_init(void)
{
...
                if (!is_normal_ram(md))
                        prot = __pgprot(PROT_DEVICE_nGnRE);
                else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
                         !PAGE_ALIGNED(md->phys_addr))
                        prot = PAGE_KERNEL_EXEC;
                else
                        prot = PAGE_KERNEL;

Concerns include:

1. is_normal_ram() will see the WB bit and return 1 regardless
of the type.  That seems similar to the arm EFI boot stub issue.
The three callers are shown above.

2. is_reserve_region() treating EFI_PERSISTENT_MEMORY the same
as EFI_CONVENTIONAL_MEMORY looks wrong.

3. We're contemplating working around the grub problem by
reporting EFI_RESERVED_MEMORY plus the NV attribute rather
than EFI_PERSISTENT_MEMORY.

If this is done, then is_reserve_region() will fall through
to is_normal_ram(), which will see the WB bit and return 1.
That seems backwards... but seems correct for persistent
memory, reporting it as a reserved region.  That might avoid the
the EFI_PERSISTENT_MEMORY handling problem (if the preceding
call to is_normal_ram() didn't already cause problems).

---
Robert Elliott, HPE Persistent Memory


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

arm64/efi handling of persistent memory "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2015-12-18 02:40 +0100
  Re: arm64/efi handling of persistent memory Leif Lindholm <leif.lindholm@linaro.org> - 2015-12-18 12:10 +0100
    Re: arm64/efi handling of persistent memory Mark Rutland <mark.rutland@arm.com> - 2015-12-18 12:50 +0100
      Re: arm64/efi handling of persistent memory Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-12-18 14:10 +0100
    Re: arm64/efi handling of persistent memory Mark Rutland <mark.rutland@arm.com> - 2015-12-18 13:00 +0100
      Re: arm64/efi handling of persistent memory Leif Lindholm <leif.lindholm@linaro.org> - 2015-12-18 13:20 +0100
      Re: arm64/efi handling of persistent memory Matt Fleming <matt@codeblueprint.co.uk> - 2015-12-18 14:30 +0100

csiph-web