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.
pgpN84s262L3O.pgp
Description: PGP signature
