In message <Pine.GSO.3.95.990315180314.6160A-100000@jericho>"Eduardo E. Horvath" writes

>If your VAC has no ASID support you have several additional problems
>depending on the md VM implementation. 

Thats not what I meant. My understanding, from previous discussions
with Mark, is that some ARM cores (strongarm) have ASIDs and selective
flush for dat references, but do not have selective (by ASID) for the
I-cache.  On context switch, you gotta flush the entire I-cache.

There's a win here in not doing the flush at all for kernel threads
that never return to userspace. 

For kernel threads that may exit back to userspace, then
pmap_activate() and usrret can conspire to elimiate the flush until
its acutally needed.


>  First, this only works if the
>kernel address space does not overlap the user address space, otherwise
>there's no way to identify cached user data from cached kernel data (not
>really an issue with the MIPS MMU design, is it?) 

Nope. Not sure about arm32.

 Also, if any PROM code
>needs to be executed you have the same problem.

Again, not on mips, dunno about arm. m68040s have that funky
transparent-translation mapping which gets around this.

> And if it's a writeback
>cache, the cache must by flushed before mappings are removed from the MMU.

Yes. the mips pmap code I referred to does just that.  i find it helps
to avoid saying `flush', but to say `force writeback' and `invalidate'
(or both), to avoid ambiguity.

>I'd hate to think of what would happen if the page scanner demaps a page
>that the VAC has dirty data for....

Nasty things.  (on mips, late TLB faults, which on r4000 trip a
silicon bug if you get them from kernel mode, which is why the mips
kernel bcopy/memcpy/memmove has to be in assembler).

You better hope you get back the same virtual-to-physical mapping as
before the pmap tries to purge it. at least on mips that's guaranteed
unless the page gets paged out in the meantime.  There's goo in the
mips pmap which forces writeback of cache lines to handle this case.

(Mmm -- yuck. i wonder if we DTRT if some other process accesses the
same physical page, via a different VA, before the first process
faults and references the page. Or am I thinking of old Mach-VM
semantics?  Michael? Do the pmap and UVM use distinct bits for this?)


There's even nastier goo to handle writing back of the segmap for such
pages, too.  (at least I think so, i can never keep that particuar
case straight.  Believe whatever Michael Hitch says.)