Description of the problem: I run once the VM using ovirt and got following error: KVM: entry failed, hardware error 0x7 RAX=000000000000000f RBX=ffff88003e00c920 RCX=000000000000038f RDX=0000000000000007 RSI=000000000000000f RDI=000000000000038f RBP=ffff88003c2b1b08 RSP=ffff88003c2b1b08 R8 =0000000000000018 R9 =0000000000000000 R10=ffff88003c2b18a0 R11=0000000000000005 R12=ffff88003e00cc48 R13=ffff88003e00c920 R14=ffff88003e00cb44 R15=0000000000000001 RIP=ffffffff81041fca RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 000fffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0000 0000000000000000 ffffffff 00c00000 DS =0000 0000000000000000 000fffff 00000000 FS =0000 0000000000000000 000fffff 00000000 GS =0000 ffff88003e000000 000fffff 00000000 LDT=0000 0000000000000000 000fffff 00000000 TR =0040 ffff88003e011500 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff88003e00a000 0000007f IDT= ffffffff81e4c000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=0000000001c0c000 CR4=000407f0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 The bug seems to be related to: https://bugzilla.redhat.com/show_bug.cgi?id=892240 I am having the same issue for following config: host: kernel 3.11.2-201.fc19.x86_64 qemu-kvm 1.4.2 kvm module nested virtualization = Y cpu sandybridge guest L1: cpuflags copied from host config kernel 3.11.2-201.fc19.x86_64 qemu-kvm 1.4.2 module kvm_intel loaded. guest L2: boot
Hi Piotr, As we speak, I'm running some nested virt tests. I have a working environment with these versions: (same for both L0 and L1): $ uname -r; rpm -q qemu-kvm libvirt-daemon-kvm 3.12.0-0.rc3.git1.2.fc21.x86_64 qemu-kvm-1.4.2-7.fc19.x86_64 libvirt-daemon-kvm-1.0.5.5-1.fc19.x86_64 Can you try with the above versions and see if you can reproduce? (The referenced bug also indicates it's working with the newest bits.)
*** This bug has been marked as a duplicate of bug 922075 ***
Cole, Is this really a dupe of 922075? I can't see how, maybe I'm wrong, but I just saw the above trace while doing a different test elsewhere. ---------------------------------------------- . . . [ 0.227029] smpboot: Total of 1 processors activated (4589.28 BogoMIPS) [ 0.230086] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. KVM: entry failed, hardware error 0x7 RAX=00000000000000ff RBX=ffff88034a00cc00 RCX=000000000000038f RDX=0000000000000007 RSI=00000000000000ff RDI=000000000000038f RBP=ffff880338b37a20 RSP=ffff880338b37a20 R8 =00000007000000ff R9 =0000000000000001 R10=ffffffff81e5cb20 R11=0000000000000000 R12=ffff88034a00cf28 R13=ffff88034a00cc00 R14=ffff88034a00ce24 R15=0000000000000001 RIP=ffffffff8105f5ca RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 000fffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0000 0000000000000000 ffffffff 00c00000 DS =0000 0000000000000000 000fffff 00000000 FS =0000 0000000000000000 000fffff 00000000 GS =0000 ffff88034a000000 000fffff 00000000 LDT=0000 0000000000000000 000fffff 00000000 TR =0040 ffff88034a1d2d80 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff88034a00a000 0000007f IDT= ffffffffff4fb000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=0000000001e10000 CR4=001407f0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000fffe0ff0 DR7=0000000000000400 EFER=0000000000000d01 . . . ----------------------------------------------
I hit the above with: 3.16.0-0.rc1.git2.1.fc21.x86_64 qemu-2.0.0-4.fc21.x86_64 libvirt-daemon-kvm-1.2.5-2.fc21.x86_64 While booting a L1 guest (Fedora 20).
Unduplicating. This is a different bug.
If you look at Appendix C "VMX BASIC EXIT REASONS" in the following enormous document: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf then it *may* be that 0x7 means: "Interrupt window. At the beginning of an instruct ion, RFLAGS.IF was 1; events were not blocked by STI or by MOV SS; and the “interrupt-window exiting” VM-execution control was 1" Suggest try using nmi_watchdog=0 on the command line.
Or maybe it means "VM entry with invalid control field(s)" http://marc.info/?l=qemu-devel&m=136610756803155&w=2
Just noticed this again: L0 (RHEL7) --- uname -r; rpm -qa | grep -i qemu-kvm-rhev 3.10.0-160.el7.x86_64 qemu-kvm-rhev-2.1.2-7.el7.x86_64 L1 (F21) -- $ uname -r; rpm -qa | grep -i qemu-system-x86 3.17.2-300.fc21.x86_64 qemu-system-x86-2.1.2-6.fc21.x86_64 -------------- $ virsh list Id Name State ---------------------------------------------------- 2 guestfs-j88smjqibqndog7p paused 3 guestfs-rw3nd7znmvg2fjep paused $ ~/.cache/libvirt/qemu/log/guestfs-j88smjqibqndog7p.log [. . .] LC_ALL=C PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/kashyapc/.local/bin:/home/kashyapc/bin:/usr/local/sbin:/usr/sbin:/sbin HOME =/home/kashyapc USER=kashyapc LOGNAME=kashyapc QEMU_AUDIO_DRV=none TMPDIR=/var/tmp /bin/qemu-kvm -name guestfs-j88smjqibqndog7p -S -machine pc-i440fx- 2.1,accel=kvm,usb=off -cpu host -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid c52db31c-bc5c-4247-b65a-2be658772976 -nographic -n o-user-config -nodefaults -device sga -chardev socket,id=charmonitor,path=/home/kashyapc/.config/libvirt/qemu/lib/guestfs-j88smjqibqndog7p.monitor,ser ver,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot - no-acpi -boot strict=on -kernel /var/tmp/.guestfs-1000/appliance.d/kernel -initrd /var/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 TERM=screen -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/tmp/libguestfsA2qwWs/devnull1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=writeback -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/tmp/libguestfsA2qwWs/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -chardev socket,id=charserial0,path=/tmp/libguestfsA2qwWs/console.sock -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/tmp/libguestfsA2qwWs/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on Domain id=2 is tainted: custom-argv KVM: entry failed, hardware error 0x7 RAX=000000000000000f RBX=0000000000000000 RCX=000000000000038f RDX=0000000000000000 RSI=000000000000000f RDI=000000000000038f RBP=ffff88001ee4faa0 RSP=ffff88001ee4faa0 R8 =0000000000000000 R9 =ffff88001f00cf60 R10=ffff88001ee4fa48 R11=0000000000000005 R12=000000000000038f R13=ffffffff81809390 R14=0000000000000000 R15=ffff88001f00ca40 RIP=ffffffff8105b8ca RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 000fffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0000 0000000000000000 ffffffff 00c00000 DS =0000 0000000000000000 000fffff 00000000 FS =0000 0000000000000000 000fffff 00000000 GS =0000 ffff88001f000000 000fffff 00000000 LDT=0000 0000000000000000 000fffff 00000000 TR =0040 ffff88001f012040 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff88001f00a000 0000007f IDT= ffffffffff56b000 00000fff CR0=8005003b CR2=00000000ffffffff CR3=0000000001c14000 CR4=000007f0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=20 48 89 f8 48 09 f0 5d c3 90 55 89 f0 89 f9 48 89 e5 0f 30 <31> c0 5d c3 66 90 55 89 f9 48 89 e5 0f 33 48 89 d7 89 c1 48 c1 e7 20 48 89 f8 48 09 c8 5d
This is consistently reproducible with Fedora 21's current stable Kernel (3.17.3-300.fc21.x86_64) on both L0 and L1, with CPU host-passthrough on L1 (i.e. QEMU CLI having '-cpu host') However, this cannot be reproduced with Rawhide versions of Kernel, libvirt, QEMU: $ uname -r; rpm -q qemu-system-x86 libvirt-daemon-kvm 3.18.0-0.rc6.git0.1.fc22.x86_64 qemu-system-x86-2.2.0-0.1.rc1.fc22.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Has anyone seen this on f23? This bug has been quiet for a while...
I am on F22 and have not seen this issue lately.
Thanks, I'll close then. If anyone is still hitting issues, please reopen
I have not seen this for a long while either.