Subject: Re: uvm_page_physload
To: Nick Hudson <skrll@netbsd.org>
From: Chuck Cranor <chuck@ece.cmu.edu>
List: tech-kern
Date: 08/25/2006 22:52:27
hi-


>Is end/avail_end inclusive or not? The man page doesn't help much

>     uvm_page_physload(vaddr_t start, vaddr_t end, vaddr_t avail_start,
>     vaddr_t avail_end, int free_list);

>     ....

(shouldn't that be paddr_t rather than vaddr_t?)


the intent is that you pass in page frame numbers that can be loaded
directly into a struct vm_physseg.   the page frame numbers are exclusive
(see defn of 'struct vm_physseg' in uvm_page.h).

uvm_page_physload() is normally called by MD code.  if the MD code does
inclusive rather than exclusive you just lose a page at the end.

if I remember right, I think one of the reasons I did the start/avail_start
and end/avail_end thing was so that you could free kernel pages that you
only needed at startup (e.g. init code, device drivers that turned out
not to be used, etc.).   we don't actually do that, but uvm could support
it if we wanted to and the kernel memory was laid out properly.



> It would appear that most code assumes it's exclusive, but

>        if (atop(paddr) >= avail_start &&
>            atop(paddr) <= avail_end)
>                uvm_pagefree(&pgs[lcv]);

>I must be missing something.

that's a bug in the !VM_PHYSSEG_NOADD case.  but all ports 
define VM_PHYSSEG_NOADD because the "ADD" case was never completed.
(see the XXXCDC comment in uvm_page.c --- you need to update uvmexp
and somehow sync the pmap in order to do a uvm_page_physload() after
the VM has been inited.)

that (incomplete) code is there because I was thinking about
the case where you have a memory board that you want to add
to the VM at autoconfig time.  [must have been thinking about
mvme147 at the time...]


chuck