Subject: D cahe flush in cpu_lwp_fork()
To: None <port-mips@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: port-mips
Date: 12/08/2003 20:20:46
Hi,

There is the following code segment in cpu_lwp_fork()::vm_machdep.c

#ifdef MIPS3_PLUS
        /*
         * To eliminate virtual aliases created by pmap_zero_page(),
         * this cache flush operation is necessary.
         * VCED on kernel stack is not allowed.
         * XXXJRT Confirm that this is necessry, and/or fix 
         * XXXJRT pmap_zero_page().
         */
        if (CPUISMIPS3 && mips_sdcache_line_size)
                mips_dcache_wbinv_range((vaddr_t) l2->l_addr, USPACE);
#endif

I think it's wrong to flush Dcache pointed by l_addr since the storage (USPACE
of l2) is going to be filled _very first time_ by two memcpy() below.  The code
trys to wbinv() for never-written address range.

The person who added the code segment looks concerned about VCED.
I emphasis here 1) VCE makes sence in L2 equipped R4000 processors.  No
other MIPS processor does post VCE.  R10000 resolves VCE condition by
hardware.  2)  As Jason mentions, the fundamental issue lies where the USPACE
contents (two 4K pages) is pre-zeroed by pmap_zero_page(), but the routine
is designed to do the work by zeroing KSEG0 of PA.  It's b-o-g-u-s.   The right
solution is to fix pmap_zero_page() taking the target VA (l_addr in this case) into
account for VIPA cache machinary, however,  uvm_uarea_alloc() looks very naive
and there is much room to make things correct....

Toru Nishimura/ALKYL Technology