added inline comments.


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



To:, imp, jhb, will, kib, delphij, emaste,,,, marcel
Cc: freebsd-virtualization-list
_______________________________________________ mailing list
To unsubscribe, send any mail to 

Reply via email to