1st level guest crashes on start of 2nd level guest in nested virtualisation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Nadav Har'El,

We are using qemu-kvm with nested virtualisation (two guest levels).
The 1st-level guest sporadicly crashes on start-up of 2nd level
guest (in BIOS). We have now found out that it always crashes with
parameter "no-kvm-irqchip" set.

Do you have any idea what the problem is? Any help?

Regards, Steffen


Host System:
- Ubuntu 10.10
- kernel 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:01:08 UTC 2011 x86_64 GNU/Linux
- QEMU emulator version 0.15.0 (qemu-kvm-0.15.0)
- kvm_kmod from git repository: commit c040fec91c95609c8a6b54ddd5ce952605a11850
          (Sun Aug 21 21:23:11 2011 -0700)
- kvm_kmod submodule linux: commit 902c502f0b0efec3a784a8ef65057298025e5e11
          (Fri Aug 26 08:04:19 2011 -0300)

Guest system (1st level):
- fresh installed Ubuntu 11.04
- QEMU emulator version 0.14.0 (qemu-kvm-0.14.0)
- kernel 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 GNU/Linux
- kvm modules from kernel above


Procedure to reproduce crash:

1. Activate nested virtualisation

2. Boot Qemu guest (1st level) system with given command

   qemu-system-x86_64 \
   -no-kvm-irqchip \
   -enable-kvm \
   -m 1G \
   -smp 1 \
   -drive file=vda.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 \
   -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 \
   -cpu host

3. Start 2nd lvel Qemu guest:
   qemu-system-x86_64

Result:

Qemu 1st level guest crashes with:

KVM: entry failed, hardware error 0x80000021

If you're runnning a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

RAX=000000000000008f RBX=0000000000000000 RCX=0000000000006ea6 RDX=0000000001000000
RSI=0000000000000000 RDI=000000000002000f RBP=0000000080000b00 RSP=ffff88003c189d00
R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
RIP=ffffffffa0112621 RFL=00023002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0018 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
FS =0000 00007f9c9d390700 ffffffff 00000000
GS =0000 ffff88003fc00000 000fffff 00000000
LDT=0000 0000000000000000 000fffff 00000000
TR =0040 ffff88003fc11880 00002087 00008b00 DPL=0 TSS64-busy
GDT=     ffff88003fc04000 0000007f
IDT=     ffffffff81bae000 00000fff
CR0=8005003b CR2=0000000000000000 CR3=000000003bdeb000 CR4=000026f0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
Code=01 00 00 48 8b 89 50 01 00 00 75 05 0f 01 c2 eb 03 0f 01 c3 <48> 87 0c 24 48 89 81 48 01 00 00 48 89 99 60 01 00 00 ff 34 24 8f 81 50 01 00 00 48 89 91

Tracing (trace-cmd record -b 20000 -e kvm) gives the following patterns:
   qemu-system-x86-15220 [001] 31572.340816: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340817: kvm_exit:             reason VMREAD rip 0xffffffffa010d06e
   qemu-system-x86-15220 [001] 31572.340818: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340821: kvm_exit:             reason VMWRITE rip 0xffffffffa010da4f
   qemu-system-x86-15220 [001] 31572.340821: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340822: kvm_exit:             reason VMWRITE rip 0xffffffffa010da4f
   qemu-system-x86-15220 [001] 31572.340822: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340822: kvm_exit:             reason VMWRITE rip 0xffffffffa010da4f
   qemu-system-x86-15220 [001] 31572.340823: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340823: kvm_exit:             reason VMWRITE rip 0xffffffffa010da4f
   qemu-system-x86-15220 [001] 31572.340823: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340824: kvm_exit:             reason VMWRITE rip 0xffffffffa010da4f
   qemu-system-x86-15220 [001] 31572.340824: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340825: kvm_exit:             reason VMRESUME rip 0xffffffffa011261e
   qemu-system-x86-15220 [001] 31572.340828: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340829: kvm_exit:             reason EXTERNAL_INTERRUPT rip 0xfebb
   qemu-system-x86-15220 [001] 31572.340831: kvm_userspace_exit:   reason KVM_EXIT_INTR (10)
   qemu-system-x86-15220 [001] 31572.340837: kvm_entry:            vcpu 0
   qemu-system-x86-15220 [001] 31572.340837: kvm_exit:             reason UNKOWN rip 0xffffffffa0112621
   qemu-system-x86-15220 [001] 31572.340838: kvm_userspace_exit:   reason KVM_EXIT_FAIL_ENTRY (9)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux