From owner-svn-src-head@FreeBSD.ORG Sat Jan 19 06:07:34 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3ECA4A1B; Sat, 19 Jan 2013 06:07:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8F857C29; Sat, 19 Jan 2013 06:07:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0J67TMZ078114; Sat, 19 Jan 2013 08:07:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0J67TMZ078114 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0J67TEV078113; Sat, 19 Jan 2013 08:07:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Jan 2013 08:07:29 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: svn commit: r245577 - in head/sys: amd64/amd64 i386/i386 x86/x86 Message-ID: <20130119060729.GB2522@kib.kiev.ua> References: <201301172132.r0HLWQHD004835@svn.freebsd.org> <20130118040332.GT2522@kib.kiev.ua> <201301181052.54464.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NctWKJLgDreUm1FS" Content-Disposition: inline In-Reply-To: <201301181052.54464.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 06:07:34 -0000 --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--