RE: grub causing NVDIMMs to be treated as normal memory

[Elliott, Robert (Persistent Memory)]

> -----Original Message-----
> From: address@hidden [mailto:grub-devel-
> address@hidden On Behalf Of Vladimir 'f-
> coder/phcoder' Serbinenko
> Sent: Friday, November 27, 2015 5:08 AM
> To: The development of GNU GRUB <address@hidden>
> Subject: Re: grub causing NVDIMMs to be treated as normal memory
> 
> What about this patch for the passing of pram?
...
> --- a/include/grub/memory.h
> +++ b/include/grub/memory.h
> @@ -30,6 +30,7 @@ typedef enum grub_memory_type
>      GRUB_MEMORY_ACPI = 3,
>      GRUB_MEMORY_NVS = 4,
>      GRUB_MEMORY_BADRAM = 5,
> +    GRUB_MEMORY_PRAM = 7,

linux chose to use these abbreviations:
* PMEM for the ACPI standard type 7 
* PRAM for the non-standard type 12

You might want to use the same.

>      GRUB_MEMORY_COREBOOT_TABLES = 16,
>      GRUB_MEMORY_CODE = 20,
>      /* This one is special: it's used internally but is never
> reported


The patch works; UEFI type 14 ends up mapped into E820 type 7. With 
linux kernel 4.4rc2 with CONFIG_EFI_STUB disabled:
* UEFI memory map:
  * efi: mem51: [Persistent Memory  |   |  |NV|  |  |  |  |   |WB|WT|WC|UC] 
range=[0x0000000880000000-0x0000000c7fffffff] (34 GiB for 16 GiB)
  * efi: mem52: [Persistent Memory  |   |  |NV|  |  |  |  |   |WB|WT|WC|UC] 
range=[0x0000001480000000-0x0000001a7fffffff] (82 GiB for 24 GiB)
* E820 entries in bios_params at startup:
  * bp: [mem 0x0000000880000000-0x0000000c7fffffff] persistent (type 7)
  * bp: [mem 0x0000001480000000-0x0000001a7fffffff] persistent (type 7)


A few more places that might need fixes:

grub-core/commands/lsmmap.c 
* names[] array - as Andre mentioned
* you might want to decode e820 type 12 there too, providing more
  visibility in case it's a legacy BIOS system that still reports
  the pre-standard e820 type 12.

grub-core/efiemu/mm.c:
* efiemu_alloc_requests reqorder[] - add GRUB_EFI_PERSISTENT_MEMORY
  (although we don't want to encourage ever allocating these
   ranges, UNUSABLE_MEMORY is already there)
* fill_hook - map GRUB_MEMORY_PMEM to GRUB_EFI_PERSISTENT_MEMORY
* grub_efiemu_mmap_iterate - handle GRUB_EFI_PERSISTENT_MEMORY.
  Also, this function includes MAX_MEMORY_TYPE in the case statement
  and doesn't have a default case... it should treat all the reserved
  types the same, not handle that one differently
* grub_efiemu_mmap_sort_and_uniq priority[] - add
  GRUB_EFI_PERSISTENT_MEMORY
* I would not bother translating e820 type 12 here 

grub-core/mmap/efi/mmap.c:
* make_efi_memtype - map GRUB_MEMORY_PMEM to GRUB_EFI_PERSISTENT_MEMORY


> >>> Note (b): The internal GRUB_MEMORY_CODE (20) value is
> >>> leaking through to the E820 table.
> >>>
> >>> That appears to be from this patch on 2013-10-14:
> >>>   6de9ee86 Pass-through unknown E820 types
> >>
> >> If we are discussing ACPI 6.0 systems here, it explicitly says
> that
> >> values above 12 should be treated as reserved. Does it cause
> >> problems?
> >
> > All undefined values are reserved for future standardization;
> > the meaning they might have in the future is unpredictable.
> >
> > Software compatible with ACPI 6.0 is supposed to treat them as
> > reserved, but software compatible with a future version of ACPI
> > might interpret them as having some different meaning that isn't
> > compatible with GRUB_MEMORY_CODE.
> >
> > Some companies used e820 type 12 to mean persistent memory without
> > getting that assigned by the ACPI WG, so that value was
> > contaminated.  We should probably mark 20 as contaminated too,
> > given this issue.
> >
> I see now that we have leaked 16 (coreboot tables) as well. Could we
> mark 16 as contaminated as well?

Yes, if it is possible for that to make it to e820.  If there is
some reason that cannot happen, then we don't need to worry about
that value.

I will prepare an ACPI WG proposal to mark those values as "OEM
defined", since the problem has been there for several years.

> For memory code: should we just pass reserved in linux e820 or is it
> better to keep doing this bug given possible reliance on it by other
> software?

If you can define a standard meaning for 16 and 20, that'd be more
useful than marking them as OEM defined.  There will always be a mix
of software that interprets it as unusable vs. follows this new
advice.

---
Robert Elliott, HPE Persistent Memory