Bug 1016748

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.