From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 13 08:38:02 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 204F94A4; Thu, 13 Feb 2014 08:38:02 +0000 (UTC) Received: from ns1.invoca.ch (mx1.invoca.ch [157.161.91.34]) by mx1.freebsd.org (Postfix) with ESMTP id A616918C8; Thu, 13 Feb 2014 08:38:01 +0000 (UTC) Received: from xxl.bi.corp.invoca.ch (cust.static.46-14-177-70.swisscomdata.ch [46.14.177.70]) by ns1.invoca.ch (Postfix) with ESMTP id 1C06C240B1; Thu, 13 Feb 2014 09:37:53 +0100 (CET) Received: from webmail.bi.corp.invoca.ch (localhost [127.0.0.1]) by xxl.bi.corp.invoca.ch (Postfix) with ESMTP id 98896438F0; Thu, 13 Feb 2014 09:37:52 +0100 (CET) Received: from 192.168.10.25 (SquirrelMail authenticated user simix) by webmail.bi.corp.invoca.ch with HTTP; Thu, 13 Feb 2014 09:37:52 +0100 Message-ID: <9900c3808331cb78733d127bd2acbc52.squirrel@webmail.bi.corp.invoca.ch> In-Reply-To: <201402121718.26615.jhb@freebsd.org> References: <201402120740.s1C7e1Mn005809@freefall.freebsd.org> <201402121423.48285.jhb@freebsd.org> <18f55baf8a13457d3d6a89fc4f4ffc61.squirrel@webmail.bi.corp.invoca.ch> <201402121718.26615.jhb@freebsd.org> Date: Thu, 13 Feb 2014 09:37:52 +0100 Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs From: "Simon Matter" To: "John Baldwin" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Thu, 13 Feb 2014 12:41:51 +0000 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 08:38:02 -0000 > 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. Regards, Simon