On 7 November 2018 at 17:15, Nathan Wallace <1758...@bugs.launchpad.net> wrote: > I am also able to reproduce this bug. The problem is that when hvf is > enabled, qemu will attempt to execute the xgetbv instruction, which > isn't supported on my processor (Intel Xeon X5670). > > Here is a stack trace from lldb; the behavior is 100% reproducible for > me. > > nathan@Nathans-Mac-Pro:~/src/qemu/qemu-3.0.0/x86_64-softmmu > $ lldb -- qemu-system-x86_64 --accel hvf > (lldb) target create "qemu-system-x86_64" > runCurrent executable set to 'qemu-system-x86_64' (x86_64). > (lldb) settings set -- target.run-args "--accel" "hvf" > (lldb) run > Process 27479 launched: > '/Users/nathan/src/qemu/qemu-3.0.0/x86_64-softmmu/qemu-system-x86_64' (x86_64) > Process 27479 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = > EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) > frame #0: 0x00000001001bca3a qemu-system-x86_64`xgetbv(xcr=0) at > x86_cpuid.c:34 > 31 { > 32 uint32_t eax, edx; > 33 > -> 34 __asm__ volatile ("xgetbv" > 35 : "=a" (eax), "=d" (edx) > 36 : "c" (xcr)); > 37 > Target 0: (qemu-system-x86_64) stopped.
Sergio -- looks like this is the result of your code in hvf-utils/x86_cpuid.c, which assumes xgetbv is present on the host CPU. It looks like tcg/i386/tcg-target.inc.c has some code which uses xgetbv but has some better guards on it to avoid the undef -- looks like there's a bit you need to check in another cpuid field... thanks -- PMM