Date: Sat, 19 Jan 2013 08:07:29 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r245577 - in head/sys: amd64/amd64 i386/i386 x86/x86 Message-ID: <20130119060729.GB2522@kib.kiev.ua> In-Reply-To: <201301181052.54464.jhb@freebsd.org> References: <201301172132.r0HLWQHD004835@svn.freebsd.org> <20130118040332.GT2522@kib.kiev.ua> <201301181052.54464.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--NctWKJLgDreUm1FS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > > >=20 > > > Log: > > > Don't attempt to use clflush on the local APIC register window. Va= rious > > > 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 clflus= h isn't > > > necessary anyway. > > > =20 > > > 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. >=20 > 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 overwritte= n 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. >=20 > > 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. >=20 > 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. --NctWKJLgDreUm1FS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ+jggAAoJEJDCuSvBvK1BmqoP/2BAK/anJZiO1yQ3aaFTi6Hp FK09zHXM8qQ5amiE4wZ+MiT2ZOtuUVZkQo8VccNU/H0YeBBbVNBq5S70mTXqsVVI 4ldskC5y9dNl/IipKMhddofD6SuBM0vLR2hezt6MN26NhgTaLYqGfnDokCy7TDBJ 1FBMQcERck21ktzMhlTBYVLk6rLkbj3S01un3H+fZPXPV+jdZr0J0ytt9ZL++eZC orsCtAZNM+Ztt8l+JWfZTjbpfEyZenR8yMqiLh/zUHWmx2cD9rX0t6AhnyfbnqeG m+mVggLG6nNoddrWhGGLsQZurp5jaY4wu1cRGiM23WRoVzqTEFhRW4awC16VKg0K P59qFrxeEBe15fX+wr4Rw7ConVyYr18uWwBCc8YB3N2anz74i9/88MrYZ8t+YVNW mzBM4f8W4RNUY6aWXcOuPH5HUeDAVPWV8vNqpzIpNL9XEWNhipNRrrIUzXgOPknk 4N2lDvJ1UdxT3H1KMv8B6NHNToXN+oa2NmD+VCnNe90BnZAJQqTM0/R1nPU35YAE lpeJY4wHvmfSwN9Y3a0BLJP0G+b4rrpFhyts7Vi2sKuZSF4V6UqSULD5q1wd7iHk jhLMTuQec/usg/0smu7VKqzrVKwuE/9kS7PcjmrPFy5xnja9F0OnmTy/5mFOiq/n iCNKuo5Lj8E8DNLn/40t =80tV -----END PGP SIGNATURE----- --NctWKJLgDreUm1FS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130119060729.GB2522>