Re: grub causing NVDIMMs to be treated as normal memory

[Vladimir 'φ-coder/phcoder' Serbinenko]

What about this patch for the passing of pram?
diff --git a/grub-core/mmap/efi/mmap.c b/grub-core/mmap/efi/mmap.c
index 900a4d6..0c03c5d 100644
--- a/grub-core/mmap/efi/mmap.c
+++ b/grub-core/mmap/efi/mmap.c
@@ -118,6 +118,12 @@ grub_efi_mmap_iterate (grub_memory_hook_t hook,
void *hook_data,
                GRUB_MEMORY_NVS, hook_data);
          break;

+       case GRUB_EFI_PERSISTENT_MEMORY:
+         hook (desc->physical_start, desc->num_pages * 4096,
+               GRUB_MEMORY_PRAM, hook_data);
+         break;
+
+
        default:
          grub_printf ("Unknown memory type %d, considering reserved\n",
                       desc->type);
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index 24a05c5..2bbfe34 100644
--- a/include/grub/efi/api.h
+++ b/include/grub/efi/api.h
@@ -476,6 +476,7 @@ enum grub_efi_memory_type
     GRUB_EFI_MEMORY_MAPPED_IO,
     GRUB_EFI_MEMORY_MAPPED_IO_PORT_SPACE,
     GRUB_EFI_PAL_CODE,
+    GRUB_EFI_PERSISTENT_MEMORY,
     GRUB_EFI_MAX_MEMORY_TYPE
   };
 typedef enum grub_efi_memory_type grub_efi_memory_type_t;
diff --git a/include/grub/memory.h b/include/grub/memory.h
index 083cfb6..1003a9c 100644
--- a/include/grub/memory.h
+++ b/include/grub/memory.h
@@ -30,6 +30,7 @@ typedef enum grub_memory_type
     GRUB_MEMORY_ACPI = 3,
     GRUB_MEMORY_NVS = 4,
     GRUB_MEMORY_BADRAM = 5,
+    GRUB_MEMORY_PRAM = 7,
     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?
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

signature.asc
Description: OpenPGP digital signature