FreeBSD Guest crash on boot due to xsave instruction issue

[Jesse Pretorius]

When trying to boot a working FreeBSD 9.1/9.2 guest on a kvm/qemu host with the following command:

kvm -m 256 -cdrom FreeBSD-9.2-RELEASE-amd64-disc1.iso -drive file=FreeBSD-9.2-RELEASE-amd64.qcow2,if=virtio -net nic,model=virtio -net user -nographic -vnc :10 -enable-kvm -balloon virtio -cpu core2duo,+xsave

The FreeBSD Guest will kernel crash on boot with the following error:

panic: CPU0 does not support X87 or SSE: 0

When launching the guest without the cpu flags, it works just fine.

This bug has been resolved in source: https://lkml.org/lkml/2014/2/22/58

Can this fix be included in Precise ASAP!

[Serge Hallyn (serge-hallyn)]

Thanks for reporting this bug. Given the lkml.org fix, I assume this is in fact a kernel bug, so assigning it as such.

This is presumably fix-released in utopic, but SRU-able to precise and trusty's backport kernels. I'm not clearn on how that process works, so leaving it like this.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1285708

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Chris J Arges (arges)]

$ git tag --contains 56c103ec040b1944c8866f79aa768265c0dd2986
v3.15-rc1

The patch in question is already in 3.16 / Utopic.

I can reproduce this easily in Trusty.

[Chris J Arges (arges)]

As a workaround use the 'host' cpu type so the proper bits are enabled:
 -cpu host,+xsave

[Paolo Bonzini (bonzini)]

You don't need "+xsave", "-cpu host" just works.

The bug is invalid. You are requesting a CPU that doesn't exist (a core2duo that supports XSAVE), and the guest's behavior is probably not going to be well defined.

[Jesse Pretorius (jesse-pretorius)]

Quite right - our workaround was to switch to using the host capabilities instead of the compatibility fallback. However, the decision for a compatibility fallback was automatically made and included the above combination. I don't know where that bug should sit.

[Chris J Arges (arges)]

Testing with the identified patch doesn't solve the issue, in addition looking at the cpu flags (core2duo +xsave) this may not be a valid configuration since xsave assumes additional features will be there (instead of creating an older cpu model with xsave.) Therefore I believe this is a configuration issue.

The comment above in #4 assumes your host has the correct cpu features, you can always run something like:
kvm -cpu host,+xsave,check to check if are issues with the host plus additional features settings. In addition I've been able to use '-cpu SandyBridge,+xsave' and this also works.

Marking this 'Won't Fix' as there is a clear workaround (use another CPU model), and this configuration may not be valid.

Thanks

[Chris J Arges (arges)]

I should have refreshed my browser before commenting. : ) Thanks Jesse and Paolo.