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 <address@hidden> wrote:

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