RE: grub causing NVDIMMs to be treated as normal memory

[Elliott, Robert (Persistent Memory)]

> -----Original Message-----
> From: Andrei Borzenkov [mailto:address@hidden
> Sent: Thursday, November 26, 2015 9:58 PM
> To: Elliott, Robert (Persistent Memory) <address@hidden>; The
> development of GNU GRUB <address@hidden>;
> address@hidden; address@hidden
> Subject: Re: grub causing NVDIMMs to be treated as normal memory
> 
> 27.11.2015 02:24, Elliott, Robert (Persistent Memory) пишет:
> >
...
> > Note (a): The 088 and 148 ranges were merged into the
> > 010 and 0c8 usable ranges, as expected for this experiment.
> >
> > The NVDIMM drivers in the kernel don't load (nmem devices load,
> > but namespaces fail and no pmem devices show up):
...
> > That shows up as normal memory in /proc/iomem and elsewhere:
> > 100000000-1a7fffffff : System RAM
> >
> 
> May be it is too early in the morning, but could you explain whether
> the test outcome confirms the patch worked or not? :)

Yes, that all worked as expected.  This description was more
for the linux-nvdimm folks (trying to understand the impact of
the issue).

> > 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.