Subject: Re: CVS commit: src/sys/arch/mips
To: None <port-mips@netbsd.org>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-mips
Date: 03/06/2005 23:39:07
In article <000d01c52193$28ca8fc0$0e00a8c0@paq6>
locore64@alkyltechnology.com wrote:

> Q. why virtual alias can happen in R4000 VIPT cache?
> A. because NetBSD/mips pmap.c produces it.  It's plain wrong.

(just for confirmation)
Which part does actually produce it?
Obviously pmap_zero_page(9) and pmap_copy_page(9) do,
but are there any other functions?
Besides, could options MIPS3_NO_PV_UNCACHED
(which seems not so good for me though) prevent it?

BTW, I'm afraid that UNCACHED mapping used in !MIPS3_NO_PV_UNCACHED
case doesn't help cache/memory consistency (though it might
prevent VCE) if any data is written through UNCACHED mappings.

As I wrote in the previous post, pool(9) and mem(4) also
use KSEG0 for pages allocated by uvm_pagealloc(9).
Shouldn't we use KSEG0 for them, or we should just
invalidate cache for such KSEG0 VA before freeing
them by uvm_pagefree(9)?

bus_dmamem_map(9) may also use KSEG0, but I'm not sure
such pages will be accessed via KSEG2 later.

> Q. how we can avoid virtual alias for R4000 VIPT cache?
> Use a special rule to bind VA and PA to prevent virtual alias.

Does this mean we have to make some changes in MI UVM?
pmap_prefer() is enough or not?

(sorry I haven't checked details of your new pmap.c yet)
---
Izumi Tsutsui