New version attached

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