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