amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
jhb at freebsd.org
Wed Feb 12 22:19:44 UTC 2014
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 at invoca.ch>
> >> To: bug-followup at FreeBSD.org
> >> Cc: simon.matter at 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
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?
More information about the freebsd-amd64