DragonFly BSD
DragonFly kernel List (threaded) for 2010-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: 64-bit vkernel


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 25 Jan 2010 08:10:45 -0800 (PST)

:...
:known until run-time. So the vkernel needs to deal with virtual 
:addresses as seen by the kernel, virtual addresses as seen by the 
:"hardware" and physical addresses. The greatest inconvenience is that 
:you cannot treat the kernel pmap and user pmaps in a uniform way.
:I'd like to propose the following:
:When servicing VM faults in ranges governed by virtual page tables, the 
:actual virtual address to be used for the vpagetable translation, and 
:not the offset from the beginning of the range.
:This change will remove the two classes of virtual addresses that now 
:exist, but it breaks the assumption that faults are serviced based on VM 
:object and page index within the object. This only matters to the 
:vkernel, because it is the only kind of process that uses 
:vpagetable-mapped regions.
:Do you have any thoughts on what I propose?
:
:Regards,
:   Jordan Gordeev

    The issue has to do with the vkernel not having a boot loader.
    So the vkernel binary is loaded as a normal ELF program by the
    normal rtelf-elf, libc, etc code.  This portion of the vkernel,
    along with any incidental malloc()'s done by libc and friends,
    does not use the mapped vpagetable area.

    I'm not sure what you are proposing in terms of coding.  Are
    you talking about changing the KernelPTA calculation in the
    vkernel code and the related pmaps?  If so I think it is a good
    idea.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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