grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub causing NVDIMMs to be treated as normal memory


From: Andrei Borzenkov
Subject: Re: grub causing NVDIMMs to be treated as normal memory
Date: Fri, 27 Nov 2015 20:23:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]