svn commit: r245577 - in head/sys: amd64/amd64 i386/i386 x86/x86

John Baldwin jhb at freebsd.org
Fri Jan 18 17:13:11 UTC 2013


On Thursday, January 17, 2013 11:03:32 pm Konstantin Belousov wrote:
> On Thu, Jan 17, 2013 at 09:32:26PM +0000, John Baldwin wrote:
> > Author: jhb
> > Date: Thu Jan 17 21:32:25 2013
> > New Revision: 245577
> > URL: http://svnweb.freebsd.org/changeset/base/245577
> > 
> > Log:
> >   Don't attempt to use clflush on the local APIC register window.  Various
> >   CPUs exhibit bad behavior if this is done (Intel Errata AAJ3, hangs on
> >   Pentium-M, and trashing of the local APIC registers on a VIA C7).  The
> >   local APIC is implicitly mapped UC already via MTRRs, so the clflush isn't
> >   necessary anyway.
> >   
> >   MFC after:	2 weeks
> I am curious, was there a case where the clflush was really executed
> on the LAPIC register window with the pristine HEAD code ? I think
> that there is no Intel processors which support clflush instruction
> and do not have self-snoop.

The VIA CPUs.  I had a submitter report that a clflush against the local APIC
range would sometimes cause the entire local APIC range to get overwritten with
a single cacheline (repeated throughout the window).  Also, in theory we could
perhaps stop masking CLFLUSH in VM's when SS is masked.

> On the other hand, please note that the same change could be due for the
> pmap_invalidate_cache_pages(). Unlike pmap_invalidate_cache_range(),
> _pages() uses clflush unconditionally on purpose, since it is intended
> for devices which do not snoop.

Hmm, maybe.  I'm not sure that call is ever used on the local APIC since the
relevant page should already be UC from the boot-time call?

-- 
John Baldwin


More information about the svn-src-head mailing list