This is a move-over from a long-standing bug in the kvm sf-bugtracker. The id there is 1906272. Jes asked me to move this bug over here :) The problem is that the default kernel debian 4 x86 installs in qemu is a k7 optimized kernel which does not boot up after installation. Some investigation showed that this kernel uses MMX instructions to access MMIO regions. These instructions are not emulated by the instruction emulator and need to be added there. Here is the original bug text from the sf-bugtracker: Host: AMD Barcelona K10, F7/x64, KVM-62. Guest: Debian 4 (32-bit). Problem: When installing Debian 4 (32-bit) on KVM-AMD host, it installs "k7" kernel by default, and the resulting image is not bootable. It can be booted only with "-no-kvm". This problem can be avoided when installing on KVM-intel host, which uses "i686" kernel for Debian guests. This is because Debian's setup check for CPUID and setups the kernel, that best matches the current CPU. This kernel (i686) can be booted from kvm-intel or from kvm-amd without problems. Perhaps KVM-AMD doesn't emulate something K7 specific (3Dnow ?). I don't know what is the best solution to this problem, but I think using custom CPUID when installing Debian guests might do it. Any ideas? =================================================== (gdb) bt #0 0x0000003dd02c9117 in ioctl () from /lib64/libc.so.6 #1 0x000000000051bb29 in kvm_run (kvm=0x2a9b040, vcpu=0) at libkvm.c:850 #2 0x00000000004fda86 in kvm_cpu_exec (env=<value optimized out>) at /root/Linstall/kvm-62rc2/qemu/qemu-kvm.c:127 #3 0x00000000004fe5d5 in kvm_main_loop_cpu (env=0x2b82bb0) at /root/Linstall/kvm-62rc2/qemu/qemu-kvm.c:307 #4 0x00000000004110fd in main (argc=44675488, argv=<value optimized out>) at /root/Linstall/kvm-62rc2/qemu/vl.c:7862 =================================================== kvm statistics efer_reload 0 0 exits 11387804 324872 fpu_reload 1340894 296 halt_exits 0 0 halt_wakeup 0 0 host_state_reload 1340931 295 hypercalls 0 0 insn_emulation 10053389 323534 insn_emulation_fail 10009814 323534 invlpg 0 0 io_exits 1334757 1004 irq_exits 0 0 irq_window 0 0 largepages 0 0 mmio_exits 27231 0 mmu_cache_miss 20 0 mmu_flooded 0 0 mmu_pde_zapped 0 0 mmu_pte_updated 0 0 mmu_pte_write 0 0 mmu_recycled 0 0 -Alexey, 3.3.2008.
If this is still seen in a modern (3.2+ etc) kernel please update/re-open thanks
Joerg, how do you know this? "Some investigation showed that this kernel uses MMX instructions to access MMIO regions. These instructions are not emulated by the instruction emulator and need to be added there."
(In reply to Jidong Xiao from comment #2) > Joerg, how do you know this? > > "Some investigation showed that this kernel uses MMX instructions to access > MMIO regions. These instructions are not emulated by the instruction > emulator and need to be added there." AFAIR the stack-trace and instruction pointer of the crashing kernel pointed to an MMX instruction and the kernel was trying to access an MMIO region.