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
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Reply via email to