[Differential] D9686: fix UEFI VM's bootup on Hyper-V (i.e. Hyper-V Generation-2 VM)

[kib (Konstantin Belousov)]

kib added inline comments.

INLINE COMMENTS

> decui_microsoft.com wrote in copy.c:79-84
> 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.

REVISION DETAIL
  https://reviews.freebsd.org/D9686

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: decui_microsoft.com, imp, jhb, will, kib, delphij, emaste, sepherosa_gmail.com, honzhan_microsoft.com, howard0su_gmail.com, marcel
Cc: freebsd-virtualization-list