Re: grub causing NVDIMMs to be treated as normal memory

[Andrei Borzenkov <arvidjaar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]

27.11.2015 16:55, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> New version attached
> 

For completeness, there is lsmmap, but it is cosmetic.

What about multiboot(2)? It lists possible memory types. Do they
constitute binding API?

#define MULTIBOOT_MEMORY_AVAILABLE              1
#define MULTIBOOT_MEMORY_RESERVED               2
#define MULTIBOOT_MEMORY_ACPI_RECLAIMABLE       3
#define MULTIBOOT_MEMORY_NVS                    4
#define MULTIBOOT_MEMORY_BADRAM                 5


>>>      GRUB_MEMORY_COREBOOT_TABLES = 16,
>>>      GRUB_MEMORY_CODE = 20,
>>>      /* This one is special: it's used internally but is never reported
>>>>>> 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?
>>> 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?
>>
>> I think it is better to leave it as is as long as those values can be reserved.
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]