Re: RFC: New multiboot2 memory map entry type

[Seth Goldberg]

On Nov 25, 2011, at 5:31 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> On 09.11.2011 06:25, Seth Goldberg wrote:
>> Hi,
>> 
>> The multiboot2 spec currently says the following regarding memory map 
>> entries (tag type 6 in the multiboot2 info tag stack):
>> 
>>             +-------------------+
>>     u64     | base_addr         |
>>     u64     | length            |
>>     u32     | type              |
>>     u32     | reserved          |
>>             +-------------------+
>> 
>>   `size' contains the size of current entry including this field
>> itself. It may be bigger than 24 bytes in future versions but is
>> guaranteed to be `base_addr' is the starting physical address. `length'
>> is the size of the memory region in bytes.  `type' is the variety of
>> address range represented, where a value of 1 indicates available RAM,
>> value of 3 indicates usable memory holding ACPI information, value of 4
>> indicates reserved memory which needs to be preserved on hibernation,
>> value of 5 indicates a memory which is occupied by defective RAM
>> modules and all other values currently indicated a reserved area.
>> `reserved' is set to `0' by bootloader and must be ignored by the OS
>> image.
>> 
>> 
>> The proposal is to add an additional type (value = 6) that denotes runtime 
>> memory that some firmware marks as required to be mapped to take advantage 
>> of services after the end of boot (UEFI is the canonical example).  Without 
>> this information, it's impossible for a multiboot2-compliant OS to set up 
>> proper mappings for this memory.
> Fine with it. Can you supply the patch for texinfo and GRUB?

Hi,

   I'm actually withdrawing this request in exchange for a multiboot2 info tag 
that includes the EFI memory map (as returned by GetMemoryMap()).  I think this 
is better because it's more complete and provides an OS with a much more 
complete set of map information (an array of EFI_MEMORY_DESCRIPTOR structures, 
as per the UEFI 2.0 spec) for UEFI systems (and considering the workarounds 
required to fully utilize UEFI, this is a necessity), so the proposal is (based 
on the http://bzr.savannah.gnu.org/r/grub/branches/multiboot2/ repo):

=== modified file 'doc/multiboot.texi'
--- doc/multiboot.texi  2011-12-24 04:13:58 +0000
+++ doc/multiboot.texi  2011-12-24 04:21:59 +0000
@@ -1127,6 +1127,20 @@
 
 This tag contains network information in the format specified as DHCP. It may b
e either a real DHCP reply or just the configuration info in the same format. Th
is tag appears once per card.
 
address@hidden UEFI Memory Map
address@hidden
address@hidden
+        +-------------------+
+u32     | type = 17         |
+u32     | size              |
+u32     | DescriptorSize    |
+u32     | DescriptorVersion |
+        | Memory Map        |
+        +-------------------+
address@hidden group
address@hidden example
+
+This tag contains the UEFI memory map (Memory Map is the buffer returned by the
 UEFI firmware call to GetMemoryMap()) and memory descriptor (the component unit
 of the Memory Map) size and version so that a compliant operating system can pr
operly decode the memory map.
 
 @node Examples
 @chapter Examples

=== modified file 'doc/multiboot2.h'
--- doc/multiboot2.h    2010-09-20 23:52:25 +0000
+++ doc/multiboot2.h    2011-12-24 04:23:31 +0000
@@ -361,6 +361,15 @@
   multiboot_uint8_t dhcpack[0];
 };
 
+struct multiboot_tag_uefi_mmap
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t descr_size;
+  multiboot_uint32_t descr_vers;
+  multiboot_uint8_t uefi_mmap[0];
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */