It's spelled "available" instead of "aviable" :-)

Please also handle existing allocations. If those allocations represent free/usable memory after boot services has exited, then they are for all practical purposes "conventional memory".

Also: please make sure that KERNEL_PHYSICAL_BASE is covered by usable memory to begin with.

As such, we may have multiple memory descriptors that overlap with [2MB..2MB+nr_pages*PAGE_SIZE]. As long as they are free to use after boot services has exited, we're ok. We can only reduce the staging size if [2MB..2MB+delta] is usable when [2MB+delta..2MB+nr_pages*PAGE_SIZE] isn't.
We can reduce the staging area to delta/PAGE_SIZE. But if 2MB isn't usable, we cannot reduce (or put differently we have to reduce to 0).

Thanks! Will fix it. Not sure how I made the typo. :-)

Do you mean the existing allocations of the type EfiLoaderData?
IMHO, after boot services has exited, we can only write the memory of EfiLoaderData or EfiConventionalMemory. It's unsafe to write to memory of the other mem types.

In case 2MB isn't usable, IMHO the OS can't boot, since it's designed in the lds script that the kernel must begins with 2MB.

The current patch has made sure KERNEL_PHYSICAL_BASE is covered by a EfiConventionalMemory mem block.

So, IMO the new algorithm can be:

for each mem block:

if mem is not EfiConventionalMemory && mem if not EfiloaderData

continue;

if mem doesn't contain 2MB

continue;

mem1 = mem;
mem2 = mem1++; //i.e. next mem block's descriptor
while (mem2 is EfiConventionalMemory || mem2 is EfiloaderData)

if mem1.end == mem2.start {

	    ++mem2;
	    ++mem1;
  	} else {
	    break;

}

break;

//now we know [mem, mem1] contains no hole and the range's type is EfiConventionalMemory, or EfiLoaderData.
figure out available_pages
//reduce nr_pages if nr_pages is > available_pages.

This seems too complex to me and according to the screenshot in the bug,
the amount of EfiLoaderData memory is actually small and it's not adjacent to the EfiConventionalMemory block that covers 2MB.

So, if my above understanding is correct, IMHO we'd better leave the current simple algorithm as-is?

Note that at the loader/earliest kernel boot phase, we must consider two different types of addresses, physical and virtual. Kernel is linked at specific virtual address, and for the text segment of the kernel, it does not matter a bit which physical addresses back the virtual mappings, as far as the virtual mapping satisfies the expectation of linker. In principle, the physical pages do not need to be contiguous even.

The physical backing is, of course, important too, but it affects different things. In particular, vm_page_array[] pages must be correctly removed from the runs, for the physical addresses that are used to map kernel. Another place which should be adapted is the creation of the initial kernel page tables, in create_pagetables() pmap function. The function makes explicit assumption that the kernel is mapped by contig physical pages.

Another question is how the kernel comprehends the used physical pages to map it. Kernel could try to inspect the initial (loader) page table it is started with, but it needs some way to access memory by a physical addresses for that. Or loader might pass some additional table to inform kernel about initial mapping, to avoid the need to inspect the page table.

IIRC, the UEFI firmware enables protected mode with identity-mapped paging (i.e. VA==PA) , before the execution is transferred to FreeBSD's EFI loader. So here IMO I can treat VA==PA in the patch (it looks FreeBSD UEFI loader doesn't change the VA/PA mapping(?)).

I have to admit the fact that I don't know the loader very well and actually it's my first time to have the chance to read some of the code and try to make a patch for it. :-)

Please kindly elaborate a little more about the issues that you think exist in the patch and I am happy to dig more into them.

UEFI firmware is guaranteed to be executed with VA==PA indeed, but loader changes the mapping after ExitBootServices(), making each 2G VA mapped by low 2G physical.

I did not wrote anything about issues in your patch, rather, I tried to enumerate problems that must be handled to allow boot from arbitrary UEFI memory map.

@kib
Got it. Thanks a lot for sharing the details about the background! Yeah, I've realized the complexity of booting from arbitrary address, which would require a lot of really in-depth and long term work. So I'd like to use this patch as a temporary workaround for UEFI VM on Hyper-V. :-)