[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: New multiboot2 memory map entry type

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: RFC: New multiboot2 memory map entry type
Date: Tue, 03 Jan 2012 20:29:09 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Icedove/3.1.16

On 24.12.2011 08:45, Seth Goldberg wrote:

   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.

On Dec 23, 2011, at 10:37 PM, Brendan Trotter<address@hidden>  wrote:


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 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.



Grub-devel mailing list
Grub-devel mailing list

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]