Re: RFC: New multiboot2 memory map entry type

[Brendan Trotter]

Hi,

On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg <address@hidden> 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