graphic: 0.966
arm: 0.908
kernel: 0.902
debug: 0.895
architecture: 0.888
device: 0.888
semantic: 0.869
performance: 0.859
boot: 0.858
PID: 0.824
user-level: 0.813
ppc: 0.801
register: 0.796
permissions: 0.779
peripherals: 0.753
files: 0.722
socket: 0.706
mistranslation: 0.656
vnc: 0.654
assembly: 0.587
virtual: 0.578
network: 0.493
VMM: 0.489
hypervisor: 0.469
risc-v: 0.441
TCG: 0.426
i386: 0.333
KVM: 0.166
x86: 0.068

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.