graphic: 0.160
semantic: 0.151
debug: 0.110
other: 0.105
device: 0.098
PID: 0.076
boot: 0.067
performance: 0.052
permissions: 0.051
files: 0.041
vnc: 0.029
socket: 0.027
network: 0.019
KVM: 0.014
debug: 0.833
boot: 0.038
PID: 0.034
KVM: 0.020
other: 0.014
files: 0.011
performance: 0.010
device: 0.007
semantic: 0.007
graphic: 0.006
network: 0.006
socket: 0.005
permissions: 0.005
vnc: 0.003

qemu-system-arm segfaults without KVM on ARM

I'm running on Odroid-XU, Debian Jessie armhf
qemu built from today's head d7d3d6092cb7edc75dc49fb90c86dd5425ab4805

sudo  qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb
audio: Could not init `oss' audio driver
Uncompressing Linux... done, booting the kernel.
Segmentation fault

If I run under GDB, the linux guest instance panics or hangs -- the behaviour is variable run to run.

If I do:
sudo  qemu-system-arm --enable-kvm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb

then the guest boots as expected.

I tried to get a backtrace by allowinghte SEGV to dump core, and using gdb to inspect it:
Core was generated by `qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id='.
Program terminated with signal 11, Segmentation fault.
#0  0xb53399c0 in ?? ()
(gdb) bt
#0  0xb53399c0 in ?? ()
Cannot access memory at address 0x28
#1  0x0016d87e in cpu_tb_exec (
    tb_ptr=0xc786fe90 <Address 0xc786fe90 out of bounds>, cpu=0x24450d8)
    at /mnt/qemu/cpu-exec.c:67
#2  cpu_arm_exec (env=<optimized out>) at /mnt/qemu/cpu-exec.c:642
#3  0x00000000 in ?? ()

This is a two year old bug which doesn't have an attached repro case and I haven't seen QEMU segfault like this, so I'm going to assume we've fixed this bug. Please reopen if you still have a problem with a newer QEMU, and provide a link to the guest binary that demonstrates the crash.