There should be a 30ms delay at that point, but if it is confused about the TSC frequency, that delay may be longer. Is that the entire serial log, or is there more before that? It would be nice to know what it thinks the TSC frequency is.

The line that says "Running inside a VM; adjusting spinout timeout to 180 seconds" would suggest that KVM implements enough of our backdoor interface to make it look like we're running under a VMware hypervisor. When we're running in this environment, we use the backdoor to get the host TSC frequency. I suspect that KVM doesn't implement the "GETMHZ" backdoor call, so we are confused about the TSC frequency. The 30ms delay turns into ... 30 hours? 30 years?

Since they implement GETVERSION, they fool us into thinking that we're running in a VMware VM. However, they do not implement GETHZ or GETMHZ, so we probably end up getting garbage back for the TSC frequency. It doesn't look like there's an option to disable our backdoor port, but it does look like it is enabled only for kvm (not for Xen).

I think you'll have to change qemu to disable our backdoor port and recompile. It should be as simple as this one-line change to hw/i386/pc_piix.c:

The faulting instruction is xsetbv. I don't think %rax should be zero here, but I believe that at this point %edx:%eax should be a legal value obtained from cpuid leaf 0xd.

Is it possible that kvm reports xsave support without supporting cpuid leaf 0xd? Can you dump out the CPUID data for a kvm VM on this host (a linux VM would be fine)? I can cook up a program to do so if necessary.