On Fri, Nov 27, 2015 at 2:08 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote: > What about this patch for the passing of pram?
It is incomplete. You need to handle make_efi_memtype() as well as efiemu where I am not sure what is the right thing to do (and we probably have zero chance to test it in real life anyway). > 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; > + > + Extra empty line. > 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_PERSISTENT is probably more clear. > 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