svn commit: r198341 - in head/sys: amd64/amd64 arm/arm arm/mv i386/i386 i386/xen ia64/ia64 kern mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/sparc64 sun4v/sun4v vm

[Marius Strobl]

On Sun, Oct 25, 2009 at 02:37:40PM -0700, Marcel Moolenaar wrote:
> 
> On Oct 25, 2009, at 1:25 PM, Marius Strobl wrote:
> >
> >Do you have a simple test case demonstrating the need for
> >I-cache synchronisation?
> 
> I typically use GDB. If breakpoints aren't being hit or
> next isn't behaving correctly, you typically have an
> I-cache problem. If you get to run GDB, you probably
> already know whether it's needed, because processes
> tend to die with random signals at startup when the
> architecture needs explicit I-cache coherency logic
> and the kernel doesn't have it. A special case I would
> say is executing from a memory disk. The I/O path
> contains bcopy() operations, which dirty the D-cache
> and trigger I-cache coherency bugs pretty well.
> 
> I didn't have issues with that on my Netra, so I didn't
> implement pmap_sync_icache for sparc64. This is not to
> say that it's absolutely not needed, just that GDB didn't
> expose problems. If sparc64 has some of the same kluges
> powerpc had, then I-cache coherency is handled in some
> other (most likely a sub-optimal) way.
> 

The cheetah-class CPUs, i.e. USIII and later, take care of
I$ coherency themselves, unlike the spitfire ones (see also
cheetah_icache_page_inval() vs. spitfire_icache_page_inval()).
So your Netra 20/T4 shouldn't exhibit such problems while
spitfire-based machines likely require the I$ to be flushed.
I currently can't think of any existing code which would
ensure I$ consistency after the writes have been performed,
not even as a side-effect. The proper solution probalby is to
make pmap_sync_icache() a wrapper around icache_page_inval().

Marius