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

Simon Matter simon.matter at
Thu Jan 23 23:10:02 UTC 2014

>Number:         186061
>Category:       amd64
>Synopsis:       FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 23 23:10:01 UTC 2014
>Originator:     Simon Matter
>Release:        10.0-RELEASE
Invoca Systems
FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root at  amd64
I've installed FreeBSD 10.0-RELEASE as KVM guest on a CentOS 6.5 system. It all works well but as soon as some load hits the FreeBSD guest, the virtual instance just reboots.
Install CentOS 6.5 x86_64 on a HP Microserver (or any other AMD family 10h box like a DL585 G7).
Create a KVM guest and install FreeBSD 10 on it.
Start some applications on the guest and wait a moment, it will soon boot again.

1) There is no panic on the guest, it just gets virtually switched off and on again.
2) Both x86 archs are affected, i386 and amd64 both crash the same way.
After the guest has rebooted, dmesg on the host shows this nice message:

KVM: Guest triggered AMD Erratum 383

Looking at the FreeBSD kernel code it's clear that the kernel usually detects and deals with AMD Erratum 383 nicely. However, in the situation as a KVM guest, this doesn't work anymore. To make migration of guest between different CPU families possible, Qemu-KVM reports a different family to the guest than the real CPU has. The effect is that the kernels auto detection simply doesn't work anymore.

The first thing that came to mind is why not make workaround_erratum383 tunable via sysctl?

But maybe it's better to improve auto detection? I found three places where auto detection takes place:

in mca_setup()
  723         if (cpu_vendor_id == CPU_VENDOR_AMD &&
  724             CPUID_TO_FAMILY(cpu_id) == 0x10 && amd10h_L1TP)
  725                 workaround_erratum383 = 1;

in pmap_init()
  759         if (vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD &&
  760             CPUID_TO_FAMILY(cpu_id) == 0x10)
  761                 workaround_erratum383 = 1;

in pmap_init()
 1012         if (vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD &&
 1013             CPUID_TO_FAMILY(cpu_id) == 0x10)
 1014                 workaround_erratum383 = 1;

Wouldn't it make sense to change these so that workaround_erratum383 == 1 if

a) cpu_vendor_id == CPU_VENDOR_AMD && CPUID_TO_FAMILY(cpu_id) == 0x10)


b) vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD

is true?

I don't understand mca_setup() nor pmap_init() but it seems workaround_erratum383 should always be enabled if
a) CPU vendor is AMD and CPU family is 10h
b) we are a guest VM and CPU vendor is AMD (no matter which family)

Thanks for looking into it!



More information about the freebsd-amd64 mailing list