On Wed, 3 Sep 1997, Chris Torek wrote:

> I am pushing for a similar (but slightly different flavor) change
> to the VM and pmap code for BSD/OS.
> 
> There are several things wrong here, and they mostly descend from
> a small but fundamental error in the VM code.  In particular, the
> type "vm_offset_t" should not exist at all.  (My standard question:
> what is this an offset *from*?  The very name is a lie; it is an
> absolute address.)
> 
> There need to be at least two, and maybe three, separate types:
> 
> 	- A "physical address" type (physadr_t).  This could be
> 	  (and should be on the sun3, sun4, sun4c, sun4m, etc) a
> 	  structured type; e.g., the sun4m has a 36-bit physical
> 	  address that can be viewed as a four-bit "space" and a
> 	  32-bit "address".  This might also carry around special
> 	  bits like "I am a device and need to be non-cached and
> 	  I cause side effects" (this is overloading the notion
> 	  of an address a bit, but by the time you are talking
> 	  about a *particular* physadr, as opposed to physadrs
> 	  in general, they do acquire these sorts of semantics).

I wholeheartedly agree with these sentiments, although I prefer the more
concise `pa_t'.

> 
> 	- A "virtual address" type.  This may need to be split into:
> 		- kernel virtual address (kva_t?)
> 		- user virtual address (uva_t?)
> 	  It helps keep code size and interface proliferation down
> 	  if these two are a single type, but for some 64-bit
> 	  machines, it might be better to split them, with the
> 	  kernel using only 32 bits of addressing.

Splitting address types into user addresses and kernel addresses is
probably not a good idea.  Think about uio routines; both source and
destination addresses could be either kernel or user addresses.

Jason Thorpe wrote:

>>Currently, a device's d_mmap entry point returns an overloaded value.
>>Within that value is the page frame number and some opaque information
>>used by some pmap's to identify the "space" in which that page frame
>>lives; a good example is the space identifiers used by the SPARC and
>>Sun 3 ports.

Now is the `space' a really a modifier of where the page frame lives, or a
a modifier of what is being accessed, therefore a component of the virtual
address?  For instance, on machines that support H/W byte flipping, the
endianness of a particular location (whether or not it needs flipping) can
be considered a component of the address space  (ASI_PRIMARY_LITTLE).  

>>        (1) Create a new machine-dependent VM type: vm_space_t.  This
>>            will be used only by machine-dependent code, but values
>>            will be transported through the MI VM system.  There will
>>            be one magic value: VM_SPACE_MEMORY, which will be the
>>            VM space value used for managed pages.

Here we come to the crux of the matter: is the `address space' a component
of the virtual address or a separate entity.  I maintain that the space is
part of the virtual address and therefore doing pointer aritmetic on
pointers to different address spaces is a questionable operation.  (Adding
a user address to an I/O space address gets you what?)

> Device mmap functions should also be able to make use of "big page"
> TLB entries.  I am not sure how this "ought" to be done, but at
> the least, the device mmap entry point must be able to view the
> overall mmap() call, rather than just receiving information one
> (small) page at a time.

I haven't looked into this yet, but it seems that could be handled by
allowing the device driver to allocate, or at least frob the virtual
address on the mmap() side, and then hooks are needed into the pmap system
to acually map in the ~big page".  Another interesting area of research
would be coallescing (sp?) a number of small pages into a single larger
page to reduce TLB impact of things like shared libraries. 

=========================================================================
Eduardo Horvath				eeh@btr.com
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier