svn commit: r262411 - head/sys/arm/arm

[Ian Lepore]

On Fri, 2014-03-07 at 17:21 +0200, Konstantin Belousov wrote:
> On Wed, Mar 05, 2014 at 06:22:47AM -0700, Ian Lepore wrote:
> > On Wed, 2014-03-05 at 13:54 +0200, Konstantin Belousov wrote:
> > > On Sun, Feb 23, 2014 at 10:52:48PM +0000, Ian Lepore wrote:
> > > > Author: ian
> > > > Date: Sun Feb 23 22:52:48 2014
> > > > New Revision: 262411
> > > > URL: http://svnweb.freebsd.org/changeset/base/262411
> > > > 
> > > > Log:
> > > >   If the L2 cache type is PIPT, pass a physical address for a flush.
> > > >   
> > > >   While this is technically more correct, I don't think it much matters,
> > > >   because the only thing in the tree that calls cpu_flush_dcache() is md(4)
> > > >   and I'm > 99% sure it's bogus that it does so; md has no ability to do
> > > >   anything that can perturb data cache coherency.
> > > 
> > > Yes, md(4) does not break data cache coherency, but I think that
> > > Marcel added the flush to ensure instruction cache coherency.  The
> > > intent was to ensure that harward-architecture machines would
> > > see up-to-date memory content when fetching instructions after
> > > read on md(4).
> > 
> > Oh.  If that's necessary on ia64, it seems like ia64/elf_machdep.c would
> > be the place to do the flush.
> 
> I am not sure about ia64, it was needed for PowerPC, I think.
> The issue is not limited to the module loads, so elf_machdep.c cannot
> solve the problem.

The part of the commit message for r192323 about ARM is just wrong.  I
don't know enough about the other platforms mentioned in there to
comment on those, but the flush call which that commit message bills as
avoiding pessimization just maximially pessimizes things on ARM.

-- Ian