From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 13 20:24:48 2014 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F473F40 for ; Thu, 13 Feb 2014 20:24:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43A3A1E4D for ; Thu, 13 Feb 2014 20:24:48 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4406AB9DD; Thu, 13 Feb 2014 15:24:47 -0500 (EST) From: John Baldwin To: Simon Matter Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs Date: Thu, 13 Feb 2014 15:13:15 -0500 Message-ID: <7414161.UG9iHGaKt6@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <9900c3808331cb78733d127bd2acbc52.squirrel@webmail.bi.corp.invoca.ch> References: <201402120740.s1C7e1Mn005809@freefall.freebsd.org> <201402121718.26615.jhb@freebsd.org> <9900c3808331cb78733d127bd2acbc52.squirrel@webmail.bi.corp.invoca.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Feb 2014 15:24:47 -0500 (EST) Cc: freebsd-amd64@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:24:48 -0000 On Thursday, February 13, 2014 09:37:52 AM Simon Matter wrote: > > On Wednesday, February 12, 2014 4:04:53 pm Simon Matter wrote: > >> > On Wednesday, February 12, 2014 2:40:01 am Simon Matter wrote: > >> >> The following reply was made to PR amd64/186061; it has been noted by > >> >> GNATS. > >> >> > >> >> From: "Simon Matter" > >> >> To: bug-followup@FreeBSD.org > >> >> Cc: simon.matter@invoca.ch > >> >> Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on > >> > >> GNU/Linux > >> > >> >> on > >> >> > >> >> AMD family 10h CPUs > >> >> > >> >> Date: Wed, 12 Feb 2014 08:30:51 +0100 > >> >> > >> >> ------=_20140212083051_97180 > >> >> Content-Type: text/plain; charset="iso-8859-1" > >> >> Content-Transfer-Encoding: 8bit > >> >> > >> >> As noted by John Baldwin the change to mca.c is not needed. Attached > >> >> > >> >> patch > >> >> > >> >> is what I'm using now with success. > >> >> > >> >> BTW: setting vm.pmap.pg_ps_enabled="0" in loader.conf does also > >> >> > >> >> mitigate > >> >> > >> >> the issue but I guess it's not the optimal solution. > >> > > >> > Talking with Alan Cox, we do think the right fix is to change the test > >> > >> to > >> > >> > enable the workaround. However, we'd rather not penalize VM's on > >> > >> other > >> > >> I'm afraid that will not work in all situations, no matter how good the > >> tests are (see below why I think so). So as a last resort, I suggest > >> that > >> it should be possible to enable the "AMD Erratum 383" workaround via > >> loader.conf. > > > > I think you misunderstand. We would only use flags that are never set > > on an AMD 10h CPU, so they can never be set in a KVM guest that would > > ever migrate to an AMD 10h CPU. If those flags are present, we know that > > we would _not_ need the workaround. If none of those flags are present, > > we would enable the workaround. Does that make sense? > > OK, I think I understand now. Unfortunately I don't know enough about CPU > flags to know how well this could work. If I understand correctly, KVM can > also emulate some CPU features which are not implemented in the real CPU. > If that's true then it becomes quite complicated I guess. > > What about having a sysctl flag so that the workaround can be enabled > manually? Wouldn't that make sense for cases where auto detection doesn't > work well. I think that is probably a good idea, yes. -- John Baldwin