On Thu, 19 Feb 1998 15:45:42 -0500 
 "Gordon W. Ross" <gwr@mc.com> wrote:

 > It appears that UVM does not support pmap_next_page() as it
 > was used with the old MACHINE_NONCONTIG pmap interface, and
 > one feature of that interface appears to have been lost:
 > 
 > The ability to reserve some physical pages.

It certainly does... works fine on e.g. the Alpha and hp300.

 > For example, all Sun3 machines (not Sun3X, but plain old Sun3)
 > have contiguous memory, and I would prefer represent that memory
 > with a single segment in the MACHINE_NEW_NONCONTIG support code.
 > Now, the problem is that on the Sun3/50 there are some pages of
 > physical memory that must be considered "in use" (by video) and
 > which need to be somehow marked as "already allocated" when the
 > initial list of free pages is created.  In the old VM code that
 > could be done by arranging for pmap_next_page() to not return
 > any of the page indicies of the reserved pages.

But representing it as a "hole" is more-or-less the correct thing to
do.  It is a hole in the compliment of managed pages.

That is what pmap_next_page() effectively did.  On systems where you
don't need to reserve this memory, it's easy; just one vm_physseg_load()
call.  On systems that do, two vm_physseg_load() calls, skipping the
pages you need to reserve.  Your crash dump writing code can still treat
it as a single contiguous chunk of memory, if you like.

 > I would rather not represent the video ram as a "hole" (with two
 > physical RAM segments) because it really is memory (not a hole)
 > and calling it a hole makes the physical memory size wrong, etc.

In the case of vm_physseg_load(), you're talking about managed pages,
not necessarily physical memory holes.  On the Alpha, for example, there
is memory used by the PALcode which is off-limits to system software.
This is memory, and you'd like to be able to read it, and write it out
in a crash dump, but it is not to be loaded into the VM system as a managed
page.

Perhaps I don't see what you find so distasteful about to vm_physseg_load()
calls?

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939