Duel Boot process?

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.

Hardware - Ryzen 1700X, Asrock Taichi 370, Nvidia 610 (host), R9 390(Guest)

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.

<domain type='kvm'>
  <name>win10</name>
  <uuid>8cc73d6b-ca5b-4b6d-84c5-314ed2a32544</uuid>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-cosmic'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
    <vmport state='off'/>
  </features>
  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='allow'>EPYC-IBPB</model>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sdd'/>
      <target dev='sda' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sde'/>
      <target dev='sdb' bus='sata'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/141092881092710A/ISOs/Win10_1607_English_x64.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:8b:5e:93'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x2e' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x2e' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x046d'/>
        <product id='0xc52b'/>
      </source>
      <address type='usb' bus='0' port='1'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Will it be pistil’s then?

2 Likes

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.

this text is from the arch wiki https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

It works without virt-manager too.
qemu-system-x86_64 -cpu help
for example.

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.

1 Like

I did modify the CPU to host passthrough after posting but no luck. Also confirmed that it is running as a system session.

Is your setup booting properly?

You mean via qemu ?
Yes , it does. The screen is a bit small but that can be changed.
The auto-probe changed one bit on the filesystem, but still I can run Windows without harm done.

Duel: a prearranged combat between two persons, fought with deadly weapons according to an accepted code of procedure

So you want your Ubuntu to fight your Win 10?

Dual: composed or consisting of two people, items, parts, etc. together, two, double, couple.

3 Likes

:rofl:: That’s what it was referred to as…to differentiate from a regular dual boot I guess

1 Like

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 :thinking:

Look into netsh trace thru boot(nice way to find boot slowdowns)
I use bing and theres a few sites under search netsh trace boot

OK, I finally managed to get back to this. Thanks to the following post I was able to get the VM to boot:

*I basically added “kvm.ignore_msrs=1” to my grub parameters and got it to work.
https://patchwork.kernel.org/patch/42605/

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.

<domain type='kvm'>
  <name>win10</name>
  <uuid>9639211b-8cd4-4418-bfd9-eb5ee187c0db</uuid>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <iothreads>4</iothreads>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
    <vcpupin vcpu='4' cpuset='4'/>
    <vcpupin vcpu='5' cpuset='5'/>
    <vcpupin vcpu='6' cpuset='6'/>
    <vcpupin vcpu='7' cpuset='7'/>
    <iothreadpin iothread='1' cpuset='0-1'/>
    <iothreadpin iothread='2' cpuset='2-3'/>
    <iothreadpin iothread='3' cpuset='4-5'/>
    <iothreadpin iothread='4' cpuset='6-7'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-q35-2.12'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
    </hyperv>
    <vmport state='off'/>
  </features>
  <cpu mode='host-passthrough' check='none'>
    <topology sockets='1' cores='4' threads='2'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <timer name='hypervclock' present='yes'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/141092881092710A/ISOs/virtio-win-0.1.126.iso'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdd'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sde'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x8'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-to-pci-bridge'>
      <model name='pcie-pci-bridge'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x9'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0xa'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0xb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0xc'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0xd'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:f0:c0:10'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x2e' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x2e' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x046d'/>
        <product id='0xc52b'/>
      </source>
      <address type='usb' bus='0' port='1'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
  </devices>
</domain>

As I understand it “duel booting” is Wendell’s coined term for dual booting between windows and Linux - for example - whereas one of them (windows) can be mounted as a guest on the Linux host as is via KVM. Correct?
My question here is what are the limitations?

  • can the windows and linux partitions be on the same physical device?
  • can windows software raid-1 be used natively and still imported by kvm/qemu?

Unfortunately, I have never tried any of those scenarios. In my case I passed two of the physical HDDs through to make things easier. One was the OS drive and the other for storage, steam games etc. I am also not sure how performance would be if both host and guest were on the same drive. If the groupings had permitted I would have passed through one of the sata controllers.

I really can’t say if the windows software raid would still work properly. I never had any issues with passing through my two drives as both drive letters etc remained the same. As it is software raid maybe it should work once both members of the raid are passed to the VM but hopefully someone more knowledgeable can chime in on this.