Jon Doron <arilou@xxxxxxxxx> writes: > Hello, > > I'm experiencing a regression in which I cannot start a HyperV VM, So you are able to start Hyper-V on KVM but when you try to launch a VM this happens? > the > issue started in v4.19 and I it exists on the latest available kernel > I got from (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories) > > My system is a Fedora 29 (x64) and the VM is a Server 2016 with HyperV > and VBS enabled, here is a snippet of my QEMU run command: > qemu-system-x86_64 \ > -machine q35 \ > -cpu > host,hv-relaxed,hv_spinlocks=0x2000,hv_time,+vmx,invtsc,-hypervisor \ Just wondering (and this is likely unrelated to your issue) - why are you hiding 'hypervisor' flag from Hyper-V? Normally, this should not be needed. > -drive id=drive_image1,if=virtio,cache=none,aio=threads,format=qcow2,file=./VMs/2016.qcow2 > \ > -enable-kvm \ > -m 8G \ > -no-hpet \ > -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ > -usbdevice tablet \ > -vnc 0.0.0.0:1 -k en-us \ > -net user,smb=/tmp/ \ > -net nic,model=virtio \ > -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 \ > -device virtio-serial \ > -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 > > To enable VBS I had to enroll the keys in the BIOS in order to enable SecureBoot > > The kernel I tried now is: 4.20.16-200.fc29.x86_64 Would it be possible to give the latest upstream (e.b. 5.1-rc2) a spin? It would be really helpful to check that we're not missing any backports in 4.20 before we start diving into this issue. > > The crash from dmesg is: > kernel: Virtual processor ID = 0x0001 > kernel: PLE Gap=00000080 Window=00001000 > kernel: EPT pointer = 0x000000015defb05e > kernel: TPR Threshold = 0x00 > kernel: TSC Offset = 0xffffff7fb064e3f6 > kernel: IDTVectoring: info=00000000 errcode=00000000 > kernel: reason=80000021 qualification=0000000000000000 > kernel: VMExit: intr_info=80000306 errcode=00000000 ilen=00000002 > kernel: VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 > kernel: ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000 > kernel: EntryControls=000153ff ExitControls=008fefff > kernel: PinBased=0000007f CPUBased=b5a06dfe SecondaryExec=0012f4eb > kernel: *** Control State *** > kernel: EFER = 0x0000000000000d01 PAT = 0x0407050600070106 > kernel: RIP = 0xffffffffc09c89b1 RSP = 0xffffb25709abfcd0 > kernel: *** Host State *** > kernel: Interruptibility = 00000008 ActivityState = 00000000 > kernel: BndCfgS = 0x0000000000000000 > kernel: DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 > kernel: EFER = 0x0000000000000000 PAT = 0x0606050400070106 > kernel: TR: sel=0x0030, attr=0x0008b, limit=0x00000067, > base=0xfffff80005182000 > kernel: IDTR: limit=0x0000ffff, > base=0xfffff800050d6040 > kernel: LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > base=0x0000000000000000 > kernel: GDTR: limit=0x0000ffff, > base=0xfffff800050d8000 > kernel: GS: sel=0x0020, attr=0x0c093, limit=0xffffffff, > base=0xfffff800050d9000 > kernel: FS: sel=0x0020, attr=0x0c093, limit=0xffffffff, > base=0x0000000000000000 > kernel: ES: sel=0x0020, attr=0x0c093, limit=0xffffffff, > base=0x0000000000000000 > kernel: SS: sel=0x0020, attr=0x0c093, limit=0xffffffff, > base=0x0000000000000000 > kernel: DS: sel=0x0020, attr=0x0c093, limit=0xffffffff, > base=0x0000000000000000 > kernel: CS: sel=0x0010, attr=0x0a09b, limit=0xffffffff, > base=0x0000000000000000 > kernel: Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > kernel: RFLAGS=0x00000002 DR7 = 0x0000000000000400 > kernel: RSP = 0xffffe80000210fc0 RIP = 0xfffff80004d16125 > kernel: CR3 = 0x000000000039d000 > kernel: CR4: actual=0x0000000000002648, shadow=0x0000000000000648, > gh_mask=ffffffffffffe871 > kernel: CR0: actual=0x0000000080010031, shadow=0x0000000080010031, > gh_mask=fffffffffffffff7 > kernel: *** Guest State *** Does it stop here? I suppose you should have something printed after this line. -- Vitaly
