Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!shelby!riacs!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Re: Translating 64-bit addresses
Message-ID: <10490@dog.ee.lbl.gov>
Date: 1 Mar 91 23:26:33 GMT
References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> <PCG.91Feb28183457@odin.cs.aber.ac.uk>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 52
X-Local-Date: Fri, 1 Mar 91 15:26:33 PST

In article <PCG.91Feb28183457@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk
(Piercarlo Grandi) writes:
>Actually the Mach page table code is *designed* to work also with
>inverted page tables, something that is not that true with other common
>Unix kernels (even if 4.3BSD was hacked to work on the RT too).

I suspect you have neither read the code nor written a pmap module.
(I have now done some of both....)

The Mach code demands two kinds of support from a `pmap module' (the
thing that implements address-space operations on any given machine):

	pmap_enter, pmap_remove, pmap_protect, pmap_change_wiring,
	pmap_extract:

All of these receive a `pmap' pointer (where a `pmap' is something
you define on your own) and a virtual address (and, for pmap_enter,
a starting physical address) and require that you map or unmap or
protect that virtual address, or return the corresponding physical
address.

This requires a way to go from virtual to physical, per process
(i.e., a forward map).

	pmap_remove_all, pmap_copy_on_write, pmap_clear_modify,
	pmap_clear_refernce, pmap_is_modified, pmap_is_referenced,
	other miscellaneous functions:

These receive a physical address and must return information, or
remove mappings, or copy, about/to/from the corresponding physical
address.  pmap_remove_all, for instance, must locate each virtual
address that maps to the given physical page and remove that mapping
(as if pmap_remove() were called).

This requires a way to go from physical to virtual, for all processes
that share that physical page (i.e., an inverted page table, of sorts).

Note that, although the VM layer has all the forward map information in
machine independent form, the pmap module is expected to maintain the
same information in machine-dependent form.  This is almost certainly a
mistake; the information should appear in one place or the other.
(Which place is best is dictated by the hardware.)  (Note that all
pmap_extract does is obtain a virtual-to-physical mapping that could be
found by simulating a pagein.)  The reverse map maintained in hardware
inverted page tables typically lacks some information the pager will
require, and thus cannot be used to store everything; I suspect
(although I have not penetrated this far yet) the VM layer code `fits'
better with this situation, i.e., keeps just what it needs and leaves
the rest to the pmap module and/or hardware.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov