Bug 30402 - Debian 4 fails to boot in KVM
Summary: Debian 4 fails to boot in KVM
Status: RESOLVED OBSOLETE
Alias: None
Product: Virtualization
Classification: Unclassified
Component: kvm (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: virtualization_kvm
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-03 14:30 UTC by Joerg Roedel
Modified: 2014-05-20 21:22 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.38-rc7
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Joerg Roedel 2011-03-03 14:30:59 UTC
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.
Comment 1 Alan 2012-08-17 15:09:42 UTC
If this is still seen in a modern (3.2+ etc) kernel please update/re-open thanks
Comment 2 Jidong Xiao 2014-05-20 21:04:43 UTC
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."
Comment 3 Joerg Roedel 2014-05-20 21:22:25 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.