Hi, On Sat, Dec 24, 2011 at 3:01 PM, Seth Goldberg <seth.goldb...@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
