I have done pci passthrough successfully with my current setup a few times before but have decided to follow Wendell’s “Duel Boot” setup as it adds the benefit of booting from the Windows as bare metal.
I have Ubuntu 18.10 and Windows 10 installed on separate SSDs. Windows was initially installed as legacy and converted to UEFI using mbr2gpt. I went through the process of creating the VM and adding the windows drive as a SATA device.
When attempting to boot the VM, windows then crashes with it’s blue screen prompt “windows has encountered an error and needs to restart”. It then of course sticks in the cycle of crashing and rebooting. The bare metal windows boots just fine when tested after this.
I have tried the VM as both i440fx and Q35 chipset but no difference. At the moment the windows was a default install with only the R9 390 graphics drivers installed. I thought maybe the host GPU, the 610 was probably causing problems and disabled it on the windows bare metal but no luck.
*Virt manager and OVMF were installed from the default repos. All configuration on VM were made through virt manager this time around.
I am not sure if I am overlooking something pretty simple.
two things you can do to get more stable performace …
Your hypervisor is running as a system session and not a user session. This can be verified by clicking, then hovering over the session in virt-manager. If you are accidentally running it as a user session, you must open a new connection by clicking “File” > “Add Connection…”, then select the option from the drop-down menu station “QEMU/KVM” and not “QEMU/KVM user session”.
In the “CPUs” section, change your CPU model to “host-passthrough”. If it is not in the list, you will have to type it by hand. This will ensure that your CPU is detected properly, since it causes libvirt to expose your CPU capabilities exactly as they are instead of only those it recognizes (which is the preferred default behavior to make CPU behavior easier to reproduce). Without it, some applications may complain about your CPU being of an unknown model.
It works without virt-manager too. qemu-system-x86_64 -cpu help
Also I did almost the same today as you did.
I have windows installed on /dev/sda and I can access it directly via qemu, like this … qemu-system-x86_64 -enable-kvm -bios "/usr/share/edk2-ovmf/OVMF.fd" -hda "/dev/sda" -m "8096" -smp "8"
keep in mind that this is for test reasons and it could harm your installation, cause I haven’t figured how to set raw filesystem without probing.
Still no luck with this duel boot. I notice that when Windows does it’s blue screen of death, a boot of the bare metal after tries to attempt a recovery. It still boots fine with bare metal though, once I select the “do nothing and boot option”.
So I tried looking into Windows event viewer to see if I could get any indication of what the problem may be but my time was set incorrectly on windows, so trying to comb through the logs at the moment. Not much errors so far besides activation errors…although I am not activated
I then followed the CPU tune setup from Wendell’s guide:
The next step was to install the VFIO drivers. The approach I took to this was to just create a disk image set as VFIO, with the VFIO ISO connected on my virtual cdrom. Installed VFIO drivers through device manager, shutdown VM then delete the disk image I just created. I then changed my 2 pass-through HDDS from SATA to VFIO and then booted the VM without issues. I had read about this method some time back on a forum but unfortunately I cannot recall where the post came from.
*Just something to note when referring to the first link, I did upgrade my Windows version to 1806 before attempting the duel boot. Windows had installed as MBR by default and I needed to use mbr2gpt to convert the install to GPT or basically reinstall Windows 10 with boot mode set to UEFI only. Mbr2GPT was only available from 1806 I believe. I don’t know if it would have worked on the earlier version of windows without the MSRs option.