Date: Thu, 13 Feb 2014 09:37:52 +0100 From: "Simon Matter" <simon.matter@invoca.ch> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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" <simon.matter@invoca.ch> >> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9900c3808331cb78733d127bd2acbc52.squirrel>