amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs

[John Baldwin]

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" <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
> >> 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