RFC: New multiboot2 memory map entry type

RFC: New multiboot2 memory map entry type

[Seth Goldberg]

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.

  --S

Re: RFC: New multiboot2 memory map entry type

[Vladimir 'φ-coder/phcoder' Serbinenko]

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?
>
>  --S
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

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.
 
+@subsection UEFI Memory Map
+@example
+@group
+        +-------------------+
+u32     | type = 17         |
+u32     | size              |
+u32     | DescriptorSize    |
+u32     | DescriptorVersion |
+        | Memory Map        |
+        +-------------------+
+@end group
+@end 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 */

Re: RFC: New multiboot2 memory map entry type

[Brendan Trotter]

Hi,

On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg <seth.goldberg@oracle.com> wrote:
>> On 09.11.2011 06:25, Seth Goldberg wrote:
>>> 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.

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

I think the multiboot memory map should be in a single, clear,
consistent and complete format; and shouldn't just be a "dumb" copy of
whatever each different type of firmware felt like providing; and a
multiboot OS should be able to use that single, clear, consistent and
complete memory map without caring about where it came from or what
type of firmware booted GRUB.

My recommendation would be "base_address, size, type, attributes,
NUMA_domain", where the multiboot specification determines the
meanings for "type" and the meanings of bits in the "attributes"
bit-field without any regard for any other specification; and where
the boot loader (GRUB) also uses the ACPI SRAT (or any other
information, if possible) to try to determine the NUMA domain that
each area belongs to (and any "hot-plug RAM" areas).

Suggested types would be:
 - reserved (includes "unknown", areas used by legacy devices, ROMs, APICs, etc)
 - usable RAM (combines "AddressRangeMemory", "EfiConventionalMemory",
"EfiBootServicesCode", "EfiBootServicesData")
 - ACPI reclaimable (OS can reuse after it has finished with all ACPI tables)
 - boot code reclaimable (OS can reuse after it has finished with all
multi-boot information)
 - boot module reclaimable (used to store the kernel and any modules
that were loaded with the kernel)
 - preserved (combines "ACPI NVS", "EfiRuntimeServiceCode",
"EfiRuntimeServicesData" and "EfiPalCode")
 - faulty RAM
 - not-present RAM (area reserved for "hot-add")
 - unused (the only type of area that is suitable for use for memory
mapped PCI devices)
 - unusable (not used, but can't be used for memory mapped PCI devices either)

Suggested attribute flags would be:
- uncached (same as UEFI spec)
- write combining (same as UEFI spec)
- write-through (same as UEFI spec)
- write back (same as UEFI spec)
- uncached exportable (same as UEFI spec)
- write protectable (same as UEFI spec)
- read protectable (same as UEFI spec)
- execute protectable (same as UEFI spec)
- runtime (same as UEFI spec)
- volatile (same as ACPI spec)
- slow (same as ACPI spec)
- errorLog (same as ACPI spec)
- is hot-plug (e.g. either "usable RAM" that may be unplugged or "not
present" RAM that may be plugged in)
- has NUMA domain (NUMA domain field is valid if this flag is set)

In addition, multiboot should guarantee that the memory map:
- is sorted in order from lowest base address to highest base address
- contains no overlapping areas
- contains no adjacent areas of the same type, attributes and NUMA domain
- contains no unmentioned holes (every byte in the 64-bit physical
address space is accounted for; for example, a "32-bit physical
addresses only" system would have a massive 1757500617114 GiB area
marked as "unusable" at the top of the 64-bit physical address space).

Note: on 80x86, determining the size of the physical address space
that the system supports involves using "CPUID.function 0x80000008" if
present (and working around the errata for Pentium 4 (family = 0xF,
model = 3) which incorrectly reports support for 40-bit physical
addresses when it only supports 36-bit physical addresses). If this
CPUID function isn't supported then check feature flags to see if
PSE36 or PAE is supported and assume 36-bit if they are, and assume
32-bit if they aren't (or if CPUID itself isn't supported).

The boot loader (GRUB) would do the best it can with available
information. For example, for an ancient PC BIOS system that doesn't
even support "int 0x15, eax=0xE820" it might use "int 0x12" to get one
usable RAM area (from zero to the start of the EBDA), then assume the
area immediately above that up to 0x00100000 is "reserved", then use
other old BIOS functions to determine if there's more RAM above
0x00100000, then have an assumed "unusable" area (in case the old BIOS
functions didn't report all extended memory), then have an assumed
"unused" area up to about 0xFE000000, then have an assumed "reserved"
area up to 0xFFFFFFFF (in case of APICs, ROM, etc), then have an
assumed "unusable" area for everything above that. After that it would
split "usable RAM" entries to create new "boot code reclaimable" and
"boot module reclaimable entries. Obviously the memory map will
contain more information (and less "conservative assumptions") if the
firmware provides more/better information to the boot loader.


Cheers,

Brendan

Re: RFC: New multiboot2 memory map entry type

[Seth Goldberg]

Hi,

  In a perfect world, I agree that would be enough, but sometimes an is needs to know, specifically, the UEFI-defined map itself to work around firmware bugs.  I see no reason why both your proposal and mine couldn't coexist.

  --S

On Dec 23, 2011, at 10:37 PM, Brendan Trotter <btrotter@gmail.com> wrote:

> Hi,
> 
> On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg <seth.goldberg@oracle.com> wrote:
>>> On 09.11.2011 06:25, Seth Goldberg wrote:
>>>> 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.
> 
>>   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):
> 
> I think the multiboot memory map should be in a single, clear,
> consistent and complete format; and shouldn't just be a "dumb" copy of
> whatever each different type of firmware felt like providing; and a
> multiboot OS should be able to use that single, clear, consistent and
> complete memory map without caring about where it came from or what
> type of firmware booted GRUB.
> 
> My recommendation would be "base_address, size, type, attributes,
> NUMA_domain", where the multiboot specification determines the
> meanings for "type" and the meanings of bits in the "attributes"
> bit-field without any regard for any other specification; and where
> the boot loader (GRUB) also uses the ACPI SRAT (or any other
> information, if possible) to try to determine the NUMA domain that
> each area belongs to (and any "hot-plug RAM" areas).
> 
> Suggested types would be:
> - reserved (includes "unknown", areas used by legacy devices, ROMs, APICs, etc)
> - usable RAM (combines "AddressRangeMemory", "EfiConventionalMemory",
> "EfiBootServicesCode", "EfiBootServicesData")
> - ACPI reclaimable (OS can reuse after it has finished with all ACPI tables)
> - boot code reclaimable (OS can reuse after it has finished with all
> multi-boot information)
> - boot module reclaimable (used to store the kernel and any modules
> that were loaded with the kernel)
> - preserved (combines "ACPI NVS", "EfiRuntimeServiceCode",
> "EfiRuntimeServicesData" and "EfiPalCode")
> - faulty RAM
> - not-present RAM (area reserved for "hot-add")
> - unused (the only type of area that is suitable for use for memory
> mapped PCI devices)
> - unusable (not used, but can't be used for memory mapped PCI devices either)
> 
> Suggested attribute flags would be:
> - uncached (same as UEFI spec)
> - write combining (same as UEFI spec)
> - write-through (same as UEFI spec)
> - write back (same as UEFI spec)
> - uncached exportable (same as UEFI spec)
> - write protectable (same as UEFI spec)
> - read protectable (same as UEFI spec)
> - execute protectable (same as UEFI spec)
> - runtime (same as UEFI spec)
> - volatile (same as ACPI spec)
> - slow (same as ACPI spec)
> - errorLog (same as ACPI spec)
> - is hot-plug (e.g. either "usable RAM" that may be unplugged or "not
> present" RAM that may be plugged in)
> - has NUMA domain (NUMA domain field is valid if this flag is set)
> 
> In addition, multiboot should guarantee that the memory map:
> - is sorted in order from lowest base address to highest base address
> - contains no overlapping areas
> - contains no adjacent areas of the same type, attributes and NUMA domain
> - contains no unmentioned holes (every byte in the 64-bit physical
> address space is accounted for; for example, a "32-bit physical
> addresses only" system would have a massive 1757500617114 GiB area
> marked as "unusable" at the top of the 64-bit physical address space).
> 
> Note: on 80x86, determining the size of the physical address space
> that the system supports involves using "CPUID.function 0x80000008" if
> present (and working around the errata for Pentium 4 (family = 0xF,
> model = 3) which incorrectly reports support for 40-bit physical
> addresses when it only supports 36-bit physical addresses). If this
> CPUID function isn't supported then check feature flags to see if
> PSE36 or PAE is supported and assume 36-bit if they are, and assume
> 32-bit if they aren't (or if CPUID itself isn't supported).
> 
> The boot loader (GRUB) would do the best it can with available
> information. For example, for an ancient PC BIOS system that doesn't
> even support "int 0x15, eax=0xE820" it might use "int 0x12" to get one
> usable RAM area (from zero to the start of the EBDA), then assume the
> area immediately above that up to 0x00100000 is "reserved", then use
> other old BIOS functions to determine if there's more RAM above
> 0x00100000, then have an assumed "unusable" area (in case the old BIOS
> functions didn't report all extended memory), then have an assumed
> "unused" area up to about 0xFE000000, then have an assumed "reserved"
> area up to 0xFFFFFFFF (in case of APICs, ROM, etc), then have an
> assumed "unusable" area for everything above that. After that it would
> split "usable RAM" entries to create new "boot code reclaimable" and
> "boot module reclaimable entries. Obviously the memory map will
> contain more information (and less "conservative assumptions") if the
> firmware provides more/better information to the boot loader.
> 
> 
> Cheers,
> 
> Brendan
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: RFC: New multiboot2 memory map entry type

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 24.12.2011 08:45, Seth Goldberg wrote:
> Hi,
>
>    In a perfect world, I agree that would be enough, but sometimes an is needs to know, specifically, the UEFI-defined map itself to work around firmware bugs.  I see no reason why both your proposal and mine couldn't coexist.
This information is used in 2 different parts:
- First it's used for doing EFI calls. For at SetVirtualMap you need 
original map and not some more convenient representation. The code using 
these calls need to know EFI in any case and as such receiving a map in 
EFI-way shouldn't be a problem
- Early in boot one needs to know which physical memory is occupied and 
which virtual memory should be left out to allow problemless mapping 
later when using firmware-specific code. So we need to mark them somehow 
in memory map as "Writable, firmware X is here both physically or 
virtually either don't erase it and reserve virtual space or renounce 
using firmware X", in this case X=EFI. The above mentionned bugs means 
that bootservices memory will need to be marked so as well.
So I'd recommend having both in different tags, one will be used by 
firmware-independent code and another by firmware-specific code.
>    --S
>
> On Dec 23, 2011, at 10:37 PM, Brendan Trotter<btrotter@gmail.com>  wrote:
>
>> Hi,
>>
>> On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg<seth.goldberg@oracle.com>  wrote:
>>>> On 09.11.2011 06:25, Seth Goldberg wrote:
>>>>> 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.
>>>    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):
>> I think the multiboot memory map should be in a single, clear,
>> consistent and complete format; and shouldn't just be a "dumb" copy of
>> whatever each different type of firmware felt like providing; and a
>> multiboot OS should be able to use that single, clear, consistent and
>> complete memory map without caring about where it came from or what
>> type of firmware booted GRUB.
>>
>> My recommendation would be "base_address, size, type, attributes,
>> NUMA_domain", where the multiboot specification determines the
>> meanings for "type" and the meanings of bits in the "attributes"
>> bit-field without any regard for any other specification; and where
>> the boot loader (GRUB) also uses the ACPI SRAT (or any other
>> information, if possible) to try to determine the NUMA domain that
>> each area belongs to (and any "hot-plug RAM" areas).
>>
>> Suggested types would be:
>> - reserved (includes "unknown", areas used by legacy devices, ROMs, APICs, etc)
>> - usable RAM (combines "AddressRangeMemory", "EfiConventionalMemory",
>> "EfiBootServicesCode", "EfiBootServicesData")
>> - ACPI reclaimable (OS can reuse after it has finished with all ACPI tables)
>> - boot code reclaimable (OS can reuse after it has finished with all
>> multi-boot information)
>> - boot module reclaimable (used to store the kernel and any modules
>> that were loaded with the kernel)
>> - preserved (combines "ACPI NVS", "EfiRuntimeServiceCode",
>> "EfiRuntimeServicesData" and "EfiPalCode")
>> - faulty RAM
>> - not-present RAM (area reserved for "hot-add")
>> - unused (the only type of area that is suitable for use for memory
>> mapped PCI devices)
>> - unusable (not used, but can't be used for memory mapped PCI devices either)
>>
>> Suggested attribute flags would be:
>> - uncached (same as UEFI spec)
>> - write combining (same as UEFI spec)
>> - write-through (same as UEFI spec)
>> - write back (same as UEFI spec)
>> - uncached exportable (same as UEFI spec)
>> - write protectable (same as UEFI spec)
>> - read protectable (same as UEFI spec)
>> - execute protectable (same as UEFI spec)
>> - runtime (same as UEFI spec)
>> - volatile (same as ACPI spec)
>> - slow (same as ACPI spec)
>> - errorLog (same as ACPI spec)
>> - is hot-plug (e.g. either "usable RAM" that may be unplugged or "not
>> present" RAM that may be plugged in)
>> - has NUMA domain (NUMA domain field is valid if this flag is set)
>>
>> In addition, multiboot should guarantee that the memory map:
>> - is sorted in order from lowest base address to highest base address
>> - contains no overlapping areas
>> - contains no adjacent areas of the same type, attributes and NUMA domain
>> - contains no unmentioned holes (every byte in the 64-bit physical
>> address space is accounted for; for example, a "32-bit physical
>> addresses only" system would have a massive 1757500617114 GiB area
>> marked as "unusable" at the top of the 64-bit physical address space).
>>
>> Note: on 80x86, determining the size of the physical address space
>> that the system supports involves using "CPUID.function 0x80000008" if
>> present (and working around the errata for Pentium 4 (family = 0xF,
>> model = 3) which incorrectly reports support for 40-bit physical
>> addresses when it only supports 36-bit physical addresses). If this
>> CPUID function isn't supported then check feature flags to see if
>> PSE36 or PAE is supported and assume 36-bit if they are, and assume
>> 32-bit if they aren't (or if CPUID itself isn't supported).
>>
>> The boot loader (GRUB) would do the best it can with available
>> information. For example, for an ancient PC BIOS system that doesn't
>> even support "int 0x15, eax=0xE820" it might use "int 0x12" to get one
>> usable RAM area (from zero to the start of the EBDA), then assume the
>> area immediately above that up to 0x00100000 is "reserved", then use
>> other old BIOS functions to determine if there's more RAM above
>> 0x00100000, then have an assumed "unusable" area (in case the old BIOS
>> functions didn't report all extended memory), then have an assumed
>> "unused" area up to about 0xFE000000, then have an assumed "reserved"
>> area up to 0xFFFFFFFF (in case of APICs, ROM, etc), then have an
>> assumed "unusable" area for everything above that. After that it would
>> split "usable RAM" entries to create new "boot code reclaimable" and
>> "boot module reclaimable entries. Obviously the memory map will
>> contain more information (and less "conservative assumptions") if the
>> firmware provides more/better information to the boot loader.
>>
>>
>> Cheers,
>>
>> Brendan
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: RFC: New multiboot2 memory map entry type

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7861 bytes --]


  Does that mean you are OK with the addition of the tag I proposed? :).

  Thanks,
  --S

Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:

> On 24.12.2011 08:45, Seth Goldberg wrote:
>> Hi,
>>
>>    In a perfect world, I agree that would be enough, but sometimes an is 
>> needs to know, specifically, the UEFI-defined map itself to work around 
>> firmware bugs.  I see no reason why both your proposal and mine couldn't 
>> coexist.
> This information is used in 2 different parts:
> - First it's used for doing EFI calls. For at SetVirtualMap you need original 
> map and not some more convenient representation. The code using these calls 
> need to know EFI in any case and as such receiving a map in EFI-way shouldn't 
> be a problem
> - Early in boot one needs to know which physical memory is occupied and which 
> virtual memory should be left out to allow problemless mapping later when 
> using firmware-specific code. So we need to mark them somehow in memory map 
> as "Writable, firmware X is here both physically or virtually either don't 
> erase it and reserve virtual space or renounce using firmware X", in this 
> case X=EFI. The above mentionned bugs means that bootservices memory will 
> need to be marked so as well.
> So I'd recommend having both in different tags, one will be used by 
> firmware-independent code and another by firmware-specific code.
>>    --S
>> 
>> On Dec 23, 2011, at 10:37 PM, Brendan Trotter<btrotter@gmail.com>  wrote:
>> 
>>> Hi,
>>> 
>>> On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg<seth.goldberg@oracle.com> 
>>> wrote:
>>>>> On 09.11.2011 06:25, Seth Goldberg wrote:
>>>>>> 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.
>>>>    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):
>>> I think the multiboot memory map should be in a single, clear,
>>> consistent and complete format; and shouldn't just be a "dumb" copy of
>>> whatever each different type of firmware felt like providing; and a
>>> multiboot OS should be able to use that single, clear, consistent and
>>> complete memory map without caring about where it came from or what
>>> type of firmware booted GRUB.
>>> 
>>> My recommendation would be "base_address, size, type, attributes,
>>> NUMA_domain", where the multiboot specification determines the
>>> meanings for "type" and the meanings of bits in the "attributes"
>>> bit-field without any regard for any other specification; and where
>>> the boot loader (GRUB) also uses the ACPI SRAT (or any other
>>> information, if possible) to try to determine the NUMA domain that
>>> each area belongs to (and any "hot-plug RAM" areas).
>>> 
>>> Suggested types would be:
>>> - reserved (includes "unknown", areas used by legacy devices, ROMs, APICs, 
>>> etc)
>>> - usable RAM (combines "AddressRangeMemory", "EfiConventionalMemory",
>>> "EfiBootServicesCode", "EfiBootServicesData")
>>> - ACPI reclaimable (OS can reuse after it has finished with all ACPI 
>>> tables)
>>> - boot code reclaimable (OS can reuse after it has finished with all
>>> multi-boot information)
>>> - boot module reclaimable (used to store the kernel and any modules
>>> that were loaded with the kernel)
>>> - preserved (combines "ACPI NVS", "EfiRuntimeServiceCode",
>>> "EfiRuntimeServicesData" and "EfiPalCode")
>>> - faulty RAM
>>> - not-present RAM (area reserved for "hot-add")
>>> - unused (the only type of area that is suitable for use for memory
>>> mapped PCI devices)
>>> - unusable (not used, but can't be used for memory mapped PCI devices 
>>> either)
>>> 
>>> Suggested attribute flags would be:
>>> - uncached (same as UEFI spec)
>>> - write combining (same as UEFI spec)
>>> - write-through (same as UEFI spec)
>>> - write back (same as UEFI spec)
>>> - uncached exportable (same as UEFI spec)
>>> - write protectable (same as UEFI spec)
>>> - read protectable (same as UEFI spec)
>>> - execute protectable (same as UEFI spec)
>>> - runtime (same as UEFI spec)
>>> - volatile (same as ACPI spec)
>>> - slow (same as ACPI spec)
>>> - errorLog (same as ACPI spec)
>>> - is hot-plug (e.g. either "usable RAM" that may be unplugged or "not
>>> present" RAM that may be plugged in)
>>> - has NUMA domain (NUMA domain field is valid if this flag is set)
>>> 
>>> In addition, multiboot should guarantee that the memory map:
>>> - is sorted in order from lowest base address to highest base address
>>> - contains no overlapping areas
>>> - contains no adjacent areas of the same type, attributes and NUMA domain
>>> - contains no unmentioned holes (every byte in the 64-bit physical
>>> address space is accounted for; for example, a "32-bit physical
>>> addresses only" system would have a massive 1757500617114 GiB area
>>> marked as "unusable" at the top of the 64-bit physical address space).
>>> 
>>> Note: on 80x86, determining the size of the physical address space
>>> that the system supports involves using "CPUID.function 0x80000008" if
>>> present (and working around the errata for Pentium 4 (family = 0xF,
>>> model = 3) which incorrectly reports support for 40-bit physical
>>> addresses when it only supports 36-bit physical addresses). If this
>>> CPUID function isn't supported then check feature flags to see if
>>> PSE36 or PAE is supported and assume 36-bit if they are, and assume
>>> 32-bit if they aren't (or if CPUID itself isn't supported).
>>> 
>>> The boot loader (GRUB) would do the best it can with available
>>> information. For example, for an ancient PC BIOS system that doesn't
>>> even support "int 0x15, eax=0xE820" it might use "int 0x12" to get one
>>> usable RAM area (from zero to the start of the EBDA), then assume the
>>> area immediately above that up to 0x00100000 is "reserved", then use
>>> other old BIOS functions to determine if there's more RAM above
>>> 0x00100000, then have an assumed "unusable" area (in case the old BIOS
>>> functions didn't report all extended memory), then have an assumed
>>> "unused" area up to about 0xFE000000, then have an assumed "reserved"
>>> area up to 0xFFFFFFFF (in case of APICs, ROM, etc), then have an
>>> assumed "unusable" area for everything above that. After that it would
>>> split "usable RAM" entries to create new "boot code reclaimable" and
>>> "boot module reclaimable entries. Obviously the memory map will
>>> contain more information (and less "conservative assumptions") if the
>>> firmware provides more/better information to the boot loader.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Brendan
>>> 
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>> 
>
>
> -- 
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>