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

[Konstantin Belousov]

On Fri, Jan 18, 2013 at 10:52:54AM -0500, John Baldwin wrote:
> 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.
So VIAs are bug-to-bug compatible with Intels ? Weird.

Regarding reverting of the VM workaround, I am not sure. It could
be tried, but as I remember, the cause of the workaround were AMD
processors and some hypervisors. It was long time ago, it might indeed
be that it worth a try.

> 
> > 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?
I noted this for completeness. You did the change in the
pmap_invalidate_cache_range(), and not in the pmap_mapdev*. The KPI
becomes somewhat rough due to inequality of the two cache flush methods
now.

But I definitely do not insist, since the ony real user of _pages() right
now is GEM, which only calls it on the real physical memory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130119/524edafb/attachment.sig>