Re: RFC: New multiboot2 memory map entry type

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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