<div dir="ltr"><div>About the way how to test VM configuration changes:</div><div> </div>From my experience on Win8.1 I could enable hyper-v feature without vendor_id flags as long as there is no hardware changes happening in the system. Once windows gets an update or I change VM devices - boom. Windows does the hardware rescan and without vendor_id flag I'm getting a crash.<div> </div><div>So, it looks like your system is pretty much in this unstable state where any windows update or configuration change will trigger hardware reconfiguration and corresponding crash. I'm not a expert in the matter, so I can be wrong ;)</div><div> </div><div>The bottom line - small VM configuration changes can cause windows to reconfigure all the devices and the follow up crashes can be caused by unrelated changes done before hand. Installing windows update without a crash can be a good sign that your current configuration has no issues.</div> <div class="gmail_quote"><div dir="ltr">On Sun, May 15, 2016 at 10:38 PM Torbjorn Jansson <<a href="mailto:torbjorn.jansson@mbox200.swipnet.se">torbjorn.jansson@mbox200.swipnet.se</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-05-15 13:57, Okky Hendriansyah wrote: > On Sun, May 15, 2016 at 6:28 PM, Torbjorn Jansson < > <a href="mailto:torbjorn.jansson@mbox200.swipnet.se" target="_blank">torbjorn.jansson@mbox200.swipnet.se</a>> wrote: > ... > >> /usr/local/bin/qemu-system-x86_64 -machine accel=kvm -name win10 -S >> -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu core2duo,kvm=off -drive >> file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on >> -drive >> file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 >> -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid >> 098e9157-b878-4882-9c7a-22bd334920c1 -nographic -no-user-config -nodefaults >> -chardev >> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win10.monitor,server,nowait >> -mon chardev=charmonitor,id=monitor,mode=control -rtc >> base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard >> -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global >> PIIX4_PM.disable_s4=1 -boot strict=on -device >> ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device >> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 >> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 >> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 >> -drive >> file=/mnt/store/virt/vms/Win10.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 >> -device >> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 >> -drive >> file=/mnt/store/virt/isos/virtio-win-0.1.117.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw >> -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev >> tap,fd=24,id=hostnet0,vhost=on,vhostfd=27 -device >> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:48:26,bus=pci.0,addr=0x3 >> -device usb-host,hostbus=5,hostaddr=6,id=hostdev0 -device >> vfio-pci,host=05:00.0,id=hostdev1,bus=pci.0,addr=0x2 -device >> vfio-pci,host=05:00.1,id=hostdev2,bus=pci.0,addr=0x4 -device >> vfio-pci,host=03:00.0,id=hostdev3,bus=pci.0,addr=0x5 -device >> vfio-pci,host=03:00.1,id=hostdev4,bus=pci.0,addr=0x9 -device >> vfio-pci,host=04:00.0,id=hostdev5,bus=pci.0,addr=0xa -device >> vfio-pci,host=04:00.1,id=hostdev6,bus=pci.0,addr=0xb -device >> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on >> > > I see that you already disable KVM CPUID in your working config. I noticed > that your CPU model is core2duo. What happens if you change that to > host-passthrough in virt-manager? Please try to boot without changing > anything beside core2duo to host-passthrough. If it can boot, verify that > it recognizes in System info. If it does not detect your i5-3470, try > running the Display Driver Utility. [1] > ... > i changed cpu model to host-passthru and i can confirm that device manager have the expected cpu model. after than turned on the hyperv settings and it again crashed. but after a bit of testing it turns out this works (=doesn't crash): <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> <kvm> <hidden state='on'/> </kvm> ... <timer name='hypervclock' present='yes'/> if i change kvm hidden state to off, it crashes with system thread exception. as it is above it boots and seems to work, haven't done any extensive testing yet. i have checked the qemu command line and can confirm it contains hv_vendor_id and some other hv_ settings. _______________________________________________ vfio-users mailing list <a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a> </blockquote></div></div>