[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
>
signature.asc
Description: OpenPGP digital signature
- RE: grub causing NVDIMMs to be treated as normal memory, (continued)
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/25
- Re: grub causing NVDIMMs to be treated as normal memory, Andrei Borzenkov, 2015/11/25
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/26
- Re: grub causing NVDIMMs to be treated as normal memory, Andrei Borzenkov, 2015/11/26
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/26
- Re: grub causing NVDIMMs to be treated as normal memory, Andrei Borzenkov, 2015/11/26
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/27
- Re: grub causing NVDIMMs to be treated as normal memory, Vladimir 'φ-coder/phcoder' Serbinenko, 2015/11/27
- Re: grub causing NVDIMMs to be treated as normal memory, Andrei Borzenkov, 2015/11/27
- Re: grub causing NVDIMMs to be treated as normal memory, Vladimir 'φ-coder/phcoder' Serbinenko, 2015/11/27
- Re: grub causing NVDIMMs to be treated as normal memory,
Andrei Borzenkov <=
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/28
- RE: grub causing NVDIMMs to be treated as normal memory, Elliott, Robert (Persistent Memory), 2015/11/30