Some more rambling commments;
> Colour match between VPN and PFN is *must*
There are two cases when colour match rule does matter; 1. new physical page is assigned for a given va. -> just make sure to choose matched PFN with VPN. 2. kernel double maps another va, which may be KVA or UVA. -> just make sure to choose a matched va. -> for example, vmapbuf() is responsible to do it right. Infamous "SOSEND_NO_LOAN" option fails into the second case. ipc_socket.c is apparently ignorant about KVA colour matching. It ends up with potential VIPT alias by choosing conflicting KVA to make double map. The most common usage of mmap(2) is like; va = mmap((void *)0, ... ); Kernel is free to choose and return va which fits at "colour boundary." If conflicting va is given in the 1st argument, mmap neglects the hint value and choose matched va which may or may not be close to the hint. For each port, it's just ok to tell UVM the number of colour at boot time. In PIPT system, the number is one, which makes whole VM logic works just as before. In VIPT system, determine the number of colour from cache size and way count to tell. No pmap fixup code is necessary. I would emphasis here that whole VIPT issue lies in MI part of VM, which is unware of colour match scheme and makes VIPT alias by itself, not in VM MD part. Toru Nishimura / ALKYL Technology
