> Sorry I'm slow, are you saying that the I-Cache deals with virtual
> addresses only?

Basically, yes.  Virtually tagged, virtually indexed - those mean that
all the addresses the i-cache deals with are virtual addresses.

> So if 2 VA's mapped to the same PA, you could write to the first and
> it would sit in the cache for that address but VA 2 would not see it?

Potentially.  Indeed, VA 2 could write something else, and depending on
the order in which the dirty cache entries get pushed, the earlier
write could end up overwriting the later.  This would wreck all sorts
of things.

> Doesn't the caches implement some type of snoop-invalidate protocol?

Presumably not, or the problem wouldn't arise. :-)  But think about it:
how can it tell when to invalidate?  So it sees a write to VA X; since
the cache deals purely in virtual addresses, it has no way of telling
what other addresses in the cache may be double-mapped to the same real
memory as X.  (Actually, much of the cache it can tell can't be, since
the byte-within-page bits are different.  But flushing all bytes at the
same byte-within-page offset whenever a write occurs is both rather
expensive to do and gross overkill in neaerly all cases - it would mean
that you effective cache can't be much larger than a page.  And in any
case, what the cache _could_ do is irrelevant here; NetBSD has to deal
with what it _does_ do.)

> 1) We are dealing with Read Only code pages, So what if it's only in
> 2 places.

I'm not sure there is such a thing as a read-only page at this level.
The code had to get written to that page somehow.  (This may not
actually be an issue; I don't know the ARM md layers.)

> 2) How did it get in 2 places in the first place.  This is nothing
> more than a simple application.  Does NetBSD make a habit out of
> duplicating CODE pages.

It is almost certainly double-mapped to a kernel page in the filesystem
and/or UVM caches.  It may be double-mapped within the same process -
it probably isn't, but I expect it is hard and/or expensive to be sure
that it isn't.  (This would be a check that would have be done on a
significant fraction of all page faults; it can't be too expensive, or
the check alone will be a performance killer.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B