Subject: Re: VM change for R4000
To: Jason Thorpe <thorpej@shagadelic.org>
From: Toru Nishimura <locore64@alkyltechnology.com>
List: port-mips
Date: 03/13/2005 10:58:02
Jason Thorpe commented;

> Another strategy you could use is to always access user pmaps via a 
> linear PTE array (recursively mapped like the Alpha VPT), and set up an 
> "APTEbase" for accessing non-current pmaps (like i386 does), just 
> arrange to have APTEbase at a virtual address such that all of the 
> mappings of that array are cache-compatible with PTEbase.  Then PTEbase 
> gets switched at context switch time.

It's been troublesome for me to handle non-current pmap.  What's the exact
condition AVPT is required to use?  My impression is in the most of case
non-current pmap ops are done by kernel_pmap() to reclaim dying process.
(change in cpu_wait() made a headache for my case...) VPT and AVPT have
4MB in size and naturally aligned and they always are compatible in VA
indexing.

> Unfortunately, it is very difficult to enforce at what VA a PA will be 
> mapped, and very hard to be that selective about PA if a VA has already 
> been selected.  Consider two different programs that map libc at 
> different addresses.

No, no.  Kernel MUST avoid that case in every effort.  NetBSD/mips kernel
allows dynld to map libc (and other dynamic libaries) in incompatible VA.
This is LATHAL.  It's the reason why any user process will die.  mmap()
system call has to return compatible addresses.  PLS refer the definition.
Kernel/VM is in charge to do the right thing.

Toru Nishimura/ALKYL Technology