Arch Linux

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I've just ran the test from your website and I don't see the type 3, an EFI ROM. I'm very surprised as to why not as this is a brand new card, UEFI is written on the box and stated on the website.

Thanks for the heads up with the re-install.

Edit: Just found there is a BIOS selection switch physically on the card! Will dismantle and switch to the other BIOS and test again.

http://www.sapphiretech.com/presentatio … &psn&lid=1

[root@i7-4770s rom-parser]# ./rom-parser /root/r9-290.rom
Valid ROM signature found @0h, PCIR offset 238h
        PCIR: type 0, vendor: 1002, device: 67b1, class: 030000
        PCIR: revision 0, vendor revision: f2a
        Last image

That's disappointing.  The MSI "Gaming" version updated in February seems to have an update with EFI support, try that if you dare.

http://www.techpowerup.com/vgabios/inde … del=R9+290

BTW, I pushed a tiny fix to rom-parser that makes it scan that one correctly, otherwise it gets lost with a bogus match.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

gneville

Member

Registered: 2014-04-02

Posts: 27

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I found a physical switch on the card that I had to move over. I've flicked it and booted back up again.

I now see the "type 3"

[root@i7-4770s rom-parser]# ./rom-parser /root/r9-290-uefi.rom
Valid ROM signature found @0h, PCIR offset 238h
        PCIR: type 0, vendor: 1002, device: 67b1, class: 030000
        PCIR: revision 0, vendor revision: f2a
Valid ROM signature found @10000h, PCIR offset 1ch
        PCIR: type 3, vendor: 1002, device: 67b1, class: 030000
        PCIR: revision 0, vendor revision: 0
                EFI: Signature Valid
        Last image

The good news is, I now see a TianoCore BIOS screen via my HDMI port, so I can successfully passthrough my graphics card

I'll install windows from fresh and see if everything works, then once confirmed it does, I'll be looking to move on to Kernel 3.17 without the i915 patches.

Fingers Crossed & Thanks for the help!

That's disappointing.  The MSI "Gaming" version updated in February seems to have an update with EFI support, try that if you dare.

http://www.techpowerup.com/vgabios/inde … del=R9+290

BTW, I pushed a tiny fix to rom-parser that makes it scan that one correctly, otherwise it gets lost with a bogus match.

Last edited by gneville (2014-09-04 21:03:37)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I found a physical switch on the card that I had to move over. I've flicked it and booted back up again.

I now see the "type 3"

[root@i7-4770s rom-parser]# ./rom-parser /root/r9-290-uefi.rom
Valid ROM signature found @0h, PCIR offset 238h
        PCIR: type 0, vendor: 1002, device: 67b1, class: 030000
        PCIR: revision 0, vendor revision: f2a
Valid ROM signature found @10000h, PCIR offset 1ch
        PCIR: type 3, vendor: 1002, device: 67b1, class: 030000
        PCIR: revision 0, vendor revision: 0
                EFI: Signature Valid
        Last image

Very strange, but I'm glad you found it.  The web seems to indicate the switch is for "quiet" or "uber" mode.  Any idea if it's just the "uber" mode that doesn't support EFI?  Which is default?

The good news is, I now see a TianoCore BIOS screen via my HDMI port, so I can successfully passthrough my graphics card

I'll install windows from fresh and see if everything works, then once confirmed it does, I'll be looking to move on to Kernel 3.17 without the i915 patches.

Good luck

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

zsph

Member

Registered: 2014-09-04

Posts: 9

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hello. I'm desperadly looking for help. I have a typical problem, that seem to happed to many people in this thread. Unfortunately I cannot overcome it. I don't see any seabios output on the screen attached to the card.

My hardware:
MB: Asus P8Z77-V LK, firmware 1402
CPU: Core i7 3770 (not the one with K)
GPU: Asus NVIDIA GTX 770 DirectCU II OC (inserted in the most top pci-e slot)

Software:
Debian Testing (don't kick me please)
3.16 Kernel with "acs override" & "i915 vga arbiter" & "vga arbitrer" patches
qemu: latest master from git://git.qemu.org/qemu.git
seabios: latest master from git://git.seabios.org/seabios.git

kernel config:

CONFIG_VFIO_IOMMU_TYPE1=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VFIO_PCI_VGA=y
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y

Boot args (I tried all possible combinations):

intel_iommu=on i915.enable_hd_vgaarb=1 pcie_acs_override=downstream vfio_iommu_type1.allow_unsafe_interrupts=1 pci-stub.ids=10de:1184,10de:0e0a

cat /etc/modprobe.d/blacklist.conf 
blacklist nouveau
blacklist nvidia
blacklist i915

I previously didn't have i915 blacklisted, no effect. I use nouveau driver, so I don't have nvidia binary installed, but I blacklist it anyway. I'm just really trying everything.

lspci -nn | grep NVIDIA
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 770] [10de:1184] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)

I set my intel GPU as primary in bios. I can successfully bind NVIDIA using the script in the first post:

sudo /usr/bin/vfio-bind 0000:01:00.0 0000:01:00.1

This looks ok:

ls -l /sys/bus/pci/drivers/vfio-pci/
total 0
lrwxrwxrwx 1 root root    0 Sep  5 00:09 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root    0 Sep  5 00:09 0000:01:00.1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1
--w------- 1 root root 4096 Sep  5 00:09 bind
lrwxrwxrwx 1 root root    0 Sep  5 00:09 module -> ../../../../module/vfio_pci
--w------- 1 root root 4096 Sep  4 23:31 new_id
--w------- 1 root root 4096 Sep  5 00:09 remove_id
--w------- 1 root root 4096 Sep  4 23:31 uevent
--w------- 1 root root 4096 Sep  5 00:09 unbind

No errors here:

dmesg |dmesg | grep -i -e pci-stub -e vfio -e iommu -e dmar # (some lines skipped)
[    0.000000] Intel-IOMMU: enabled
[    0.079612] dmar: Host address width 36
[    0.079614] dmar: DRHD base: 0x000000fed90000 flags: 0x0
[    0.079621] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.079622] dmar: DRHD base: 0x000000fed91000 flags: 0x1
[    0.079625] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.079626] dmar: RMRR base: 0x000000bc5b3000 end: 0x000000bc5c4fff
[    0.079627] dmar: RMRR base: 0x000000bf000000 end: 0x000000cf1fffff
[    0.079697] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.560480] DMAR: No ATSR found
[    0.560500] IOMMU 0 0xfed90000: using Queued invalidation
[    0.560500] IOMMU 1 0xfed91000: using Queued invalidation
[    0.560501] IOMMU: Setting RMRR:
[    0.560510] IOMMU: Setting identity map for device 0000:00:02.0 [0xbf000000 - 0xcf1fffff]
[    0.561572] IOMMU: Setting identity map for device 0000:00:14.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561587] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561600] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561608] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.561613] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.561786] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-vfio-ally #1
[    0.561801]  [<ffffffff813e50b6>] ? intel_iommu_add_device+0x36/0x200
[    0.561803]  [<ffffffff813da240>] ? bus_set_iommu+0x50/0x50
[    0.561805]  [<ffffffff813da260>] ? add_iommu_group+0x20/0x50
[    0.561808]  [<ffffffff813da22e>] ? bus_set_iommu+0x3e/0x50
[    0.561811]  [<ffffffff8192ac05>] ? intel_iommu_init+0x4fe/0x582
[    0.561814]  [<ffffffff818ec7de>] ? pci_iommu_init+0xe/0x37
[    0.588450] VFIO - User Level meta-driver version: 0.3
[    8.299028] pci-stub: add 10DE:1184 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    8.299042] pci-stub 0000:01:00.0: claimed by stub
[    8.299049] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    8.299149] vboxpci: IOMMU found
[    8.392654] [drm] DMAR active, disabling use of stolen memory

Then I run qemu as

sudo ~/qemu.git/x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-M q35 \
-m 1024 \
-cpu host \
-smp 1,sockets=1,cores=1,threads=1 \
-bios ~/seabios.git/out/bios.bin \
-L ~/seabios.git/out/ -L ~/seabios.git/out/bios.bin \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1

I see SDL qemu window but no signal on HDMI or DVI output of NVIDIA. I can still see these messages in dmesg when starting qemu:

[   44.915488] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900
[   71.971217] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900
[  495.033377] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900

I googled, read mail lists but nothing helpfull. This is SOS, please help.

---

Asus P8Z77-V LK, Core i7 3770, Asus NVIDIA GTX 770 DirectCU II OC, Debian x64, EFI, Kernel 3.16 + i915 arbiter patch.
3DMark11: bare metal P10231 vs vfio P10039: 98% of performance!

siddharta

Member

Registered: 2014-05-03

Posts: 30

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hello. I'm desperadly looking for help. I have a typical problem, that seem to happed to many people in this thread. Unfortunately I cannot overcome it. I don't see any seabios output on the screen attached to the card.

My hardware:
MB: Asus P8Z77-V LK, firmware 1402
CPU: Core i7 3770 (not the one with K)
GPU: Asus NVIDIA GTX 770 DirectCU II OC (inserted in the most top pci-e slot)

Software:
Debian Testing (don't kick me please)
3.16 Kernel with "acs override" & "i915 vga arbiter" & "vga arbitrer" patches
qemu: latest master from git://git.qemu.org/qemu.git
seabios: latest master from git://git.seabios.org/seabios.git

kernel config:

CONFIG_VFIO_IOMMU_TYPE1=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VFIO_PCI_VGA=y
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y

Boot args (I tried all possible combinations):

intel_iommu=on i915.enable_hd_vgaarb=1 pcie_acs_override=downstream vfio_iommu_type1.allow_unsafe_interrupts=1 pci-stub.ids=10de:1184,10de:0e0a

cat /etc/modprobe.d/blacklist.conf 
blacklist nouveau
blacklist nvidia
blacklist i915

I previously didn't have i915 blacklisted, no effect. I use nouveau driver, so I don't have nvidia binary installed, but I blacklist it anyway. I'm just really trying everything.

lspci -nn | grep NVIDIA
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 770] [10de:1184] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)

I set my intel GPU as primary in bios. I can successfully bind NVIDIA using the script in the first post:

sudo /usr/bin/vfio-bind 0000:01:00.0 0000:01:00.1

This looks ok:

ls -l /sys/bus/pci/drivers/vfio-pci/
total 0
lrwxrwxrwx 1 root root    0 Sep  5 00:09 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root    0 Sep  5 00:09 0000:01:00.1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1
--w------- 1 root root 4096 Sep  5 00:09 bind
lrwxrwxrwx 1 root root    0 Sep  5 00:09 module -> ../../../../module/vfio_pci
--w------- 1 root root 4096 Sep  4 23:31 new_id
--w------- 1 root root 4096 Sep  5 00:09 remove_id
--w------- 1 root root 4096 Sep  4 23:31 uevent
--w------- 1 root root 4096 Sep  5 00:09 unbind

No errors here:

dmesg |dmesg | grep -i -e pci-stub -e vfio -e iommu -e dmar # (some lines skipped)
[    0.000000] Intel-IOMMU: enabled
[    0.079612] dmar: Host address width 36
[    0.079614] dmar: DRHD base: 0x000000fed90000 flags: 0x0
[    0.079621] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.079622] dmar: DRHD base: 0x000000fed91000 flags: 0x1
[    0.079625] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.079626] dmar: RMRR base: 0x000000bc5b3000 end: 0x000000bc5c4fff
[    0.079627] dmar: RMRR base: 0x000000bf000000 end: 0x000000cf1fffff
[    0.079697] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.560480] DMAR: No ATSR found
[    0.560500] IOMMU 0 0xfed90000: using Queued invalidation
[    0.560500] IOMMU 1 0xfed91000: using Queued invalidation
[    0.560501] IOMMU: Setting RMRR:
[    0.560510] IOMMU: Setting identity map for device 0000:00:02.0 [0xbf000000 - 0xcf1fffff]
[    0.561572] IOMMU: Setting identity map for device 0000:00:14.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561587] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561600] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbc5b3000 - 0xbc5c4fff]
[    0.561608] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.561613] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.561786] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-vfio-ally #1
[    0.561801]  [<ffffffff813e50b6>] ? intel_iommu_add_device+0x36/0x200
[    0.561803]  [<ffffffff813da240>] ? bus_set_iommu+0x50/0x50
[    0.561805]  [<ffffffff813da260>] ? add_iommu_group+0x20/0x50
[    0.561808]  [<ffffffff813da22e>] ? bus_set_iommu+0x3e/0x50
[    0.561811]  [<ffffffff8192ac05>] ? intel_iommu_init+0x4fe/0x582
[    0.561814]  [<ffffffff818ec7de>] ? pci_iommu_init+0xe/0x37
[    0.588450] VFIO - User Level meta-driver version: 0.3
[    8.299028] pci-stub: add 10DE:1184 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    8.299042] pci-stub 0000:01:00.0: claimed by stub
[    8.299049] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    8.299149] vboxpci: IOMMU found
[    8.392654] [drm] DMAR active, disabling use of stolen memory

Then I run qemu as

sudo ~/qemu.git/x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-M q35 \
-m 1024 \
-cpu host \
-smp 1,sockets=1,cores=1,threads=1 \
-bios ~/seabios.git/out/bios.bin \
-L ~/seabios.git/out/ -L ~/seabios.git/out/bios.bin \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1

I see SDL qemu window but no signal on HDMI or DVI output of NVIDIA. I can still see these messages in dmesg when starting qemu:

[   44.915488] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900
[   71.971217] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900
[  495.033377] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x900

I googled, read mail lists but nothing helpfull. This is SOS, please help.

This would probably not be the root cause of your issue, but i915 shouldn't have to be blacklisted, you probably don't need allow_unsafe_interrupts=1 nor the other VGA arbiter patch, only the i915 vgaarb patch. Have a look at aw's blog vfio.blogspot.com in the FAQ post.
edit: also, depending on your exact situation, your video card may already be in its own VFIO group. If that's the case and you're not passing other devices that are co-habiting a VFIO group with other devices that you don't want to pass to the guest then you don't need the ACS override patch either. You can search this thread for a script called lsgroups.sh that presents this nicely.

Last edited by siddharta (2014-09-04 21:51:32)

gneville

Member

Registered: 2014-04-02

Posts: 27

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

It just seems on the Sapphire Radeon R9 290 that the Default BIOS is legacy and the other switch is for UEFI. Don't think there is a quiet and uber mode on this card.

http://www.hardwareluxx.com/index.php/r … -x-oc.html

Very strange, but I'm glad you found it.  The web seems to indicate the switch is for "quiet" or "uber" mode.  Any idea if it's just the "uber" mode that doesn't support EFI?  Which is default?

siddharta

Member

Registered: 2014-05-03

Posts: 30

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Interestingly enough, after installing closed source nvidia drivers in the guest instead of nouveau, the host no longer hangs on guest reboot, nor do I have the same behaviour after shutdown and restart of the guest (QEMU throwing "invalid rom contents" error followed by the host locking up unless QEMU is terminated). The guest doesn't seem to come back up properly after a reboot or shutdown, however I can't see what is going on now (connected to the host over SSH) so I'll see that tomorrow. The guest doesn't respond but doesn' crash the host either which is a step in the right direction, dmesg doesn't list any errors/warnings either. There are slight differences  between the nouveau and nvidia proprietary drivers in the

lspci -vvv -s 02:00.0

output taken after shutting down the guest, I can post them if it would be of interest.

I actually had a similar experience with an AMD 5450 card - host hanging after reboot with the radeon open source drivers installed in the guest, but working fine with the closed source fglrx drivers on the guest.

As to swapping the card around physically to see whether the ACS override is required, I have another (physically) x16 slot but it's not possible to install the nvidia card there due to the size of the heatsink on the card. Thanks.

edit: removed quote

Last edited by siddharta (2014-09-04 23:02:50)

zsph

Member

Registered: 2014-09-04

Posts: 9

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Thank you for prompt reply.

This would probably not be the root cause of your issue, but i915 shouldn't have to be blacklisted, you probably don't need allow_unsafe_interrupts=1 nor the other VGA arbiter patch, only the i915 vgaarb patch. Have a look at aw's blog vfio.blogspot.com in the FAQ post.

edit: also, depending on your exact situation, your video card may already be in its own VFIO group. If that's the case and you're not passing other devices that are co-habiting a VFIO group with other devices that you don't want to pass to the guest then you don't need the ACS override patch either. You can search this thread for a script called lsgroups.sh that presents this nicely.

I found the script, the card is the only member in its group:

### Group 13 ###
    01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)
    01:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)

Is there a chance that without unnecessary patches and boot args the outcome can be different? I will certainly try, it just takes hours to rebuild

---

Asus P8Z77-V LK, Core i7 3770, Asus NVIDIA GTX 770 DirectCU II OC, Debian x64, EFI, Kernel 3.16 + i915 arbiter patch.
3DMark11: bare metal P10231 vs vfio P10039: 98% of performance!

siddharta

Member

Registered: 2014-05-03

Posts: 30

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Is there a chance that without unnecessary patches and boot args the outcome can be different? I will certainly try, it just takes hours to rebuild

You can remove the allow unsafe interrupts and acs override boot parameters (this will disable the acs override patch) but to remove the non-i915 VGA arbiter patch you'll need to rebuild the kernel, unless there is a parameter to disable it (look at the patch notes, I'm not sure). The first two will likely not improve matters but removing the non-i915 VGA arbiter patch could possibly solve your issue, I'm not certain though. Do keep the i915 vgaarb patch and the corresponding boot parameter, that one is not optional if using Intel igfx on the host on kernel below 3.17.

gneville

Member

Registered: 2014-04-02

Posts: 27

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

aw, everything is looking good for UEFI booting. The only thing I can't do is restart the Windows8 Guest, this just causes a booting loop, but this was similar to before whereby I have to apply the fixes found in this blog - http://blog.ktz.me/?p=219

I've moved up to Linux 3.17 RC3 Kernel and removed the "i915.enable_hd_vgaarb=1"

My prompt is now:

intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pci-stub.ids=1002:67b1,1002:aac8 quiet

I successfully have my Intel chipset outputting XBMC whilst my AMD R9 290 is outputting Windows.

It just seems on the Sapphire Radeon R9 290 that the Default BIOS is legacy and the other switch is for UEFI. Don't think there is a quiet and uber mode on this card.

http://www.hardwareluxx.com/index.php/r … -x-oc.html

Very strange, but I'm glad you found it.  The web seems to indicate the switch is for "quiet" or "uber" mode.  Any idea if it's just the "uber" mode that doesn't support EFI?  Which is default?

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Is there a chance that without unnecessary patches and boot args the outcome can be different? I will certainly try, it just takes hours to rebuild

You can remove the allow unsafe interrupts and acs override boot parameters (this will disable the acs override patch) but to remove the non-i915 VGA arbiter patch you'll need to rebuild the kernel, unless there is a parameter to disable it (look at the patch notes, I'm not sure). The first two will likely not improve matters but removing the non-i915 VGA arbiter patch could possibly solve your issue, I'm not certain though. Do keep the i915 vgaarb patch and the corresponding boot parameter, that one is not optional if using Intel igfx on the host on kernel below 3.17.

I sure hope that removing the other VGA arbiter patch doesn't make a difference, that's upstream now.  IIRC, you do need to not blacklist i915 if you're using VGA-mode assignment.  We need the i915 driver to participate in arbitration and it likely does make a difference.  The ACS override patch shouldn't matter if it's not enabled.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

aw, everything is looking good for UEFI booting. The only thing I can't do is restart the Windows8 Guest, this just causes a booting loop, but this was similar to before whereby I have to apply the fixes found in this blog - http://blog.ktz.me/?p=219

Is it really a boot loop or is it a ~1min delay in rebooting?  (see the Aug 28th update on the blog)

I've moved up to Linux 3.17 RC3 Kernel and removed the "i915.enable_hd_vgaarb=1"

My prompt is now:

intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pci-stub.ids=1002:67b1,1002:aac8 quiet

I successfully have my Intel chipset outputting XBMC whilst my AMD R9 290 is outputting Windows.

Great, another satisfied OVMF customer

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

mdx

Member

Registered: 2014-09-02

Posts: 1

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Hi all,

After finally getting my Win7 guest up and running, I'm not able to install Windows updates without breaking the guest OS.

I've done this a few times, without any anti-virus software and the result has been the same:
1. Install Win7 (latest attempt using X17-24209.iso), install latest virtio network driver from Redhat and reboot several times: OK
2. Install critical updates using Windows Update and reboot: Guest boots in "Startup Repair" mode, sometimes several times in a loop but is unable to repair --> OS bricked

I'm using qemu-git from aur.
Has anyone experienced this issue?

friedcpu

Member

Registered: 2014-09-03

Posts: 3

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

This is really driving me crazy, there must be a way to passthrough your primary PCI device (slot 1) without onboard graphics (X79) and use the host as headless

My details are in post #2638 on page 106.

Has anyone successfully done this? I have recently found in dmesg this

pci 0000:01:00.0: Boot video device

even after disabling the framebuffer, could this be whats causing it?

thank you
FriedCPU

Last edited by friedcpu (2014-09-05 08:10:33)

gneville

Member

Registered: 2014-04-02

Posts: 27

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I'm using qemu from git that I pulled down on 29th Aug.

qemu:  2.1.50 (git-290814)
libvirt:   1.2.9 (git-290814)
Kernel: 3.17.0-1-mainline (RC3)
bios:    OVMF TianoCore (svn 16059)
Kernel Boot params:

intel_iommu=on pci-stub.ids=1002:67b1,1002:aac8 quiet

After rebooting the machine comes up with the windows splash screen whilst booting and then reboots so I see the Tianocore BIOS screen again. Windows then goes in to it's recovery screen.

I have applied this patch to my qemu: https://lists.gnu.org/archive/html/qemu … 00767.html as it helped out before in other areas, maybe I shouldn't have?

Is it really a boot loop or is it a ~1min delay in rebooting?  (see the Aug 28th update on the blog)

Last edited by gneville (2014-09-05 09:35:40)

zsph

Member

Registered: 2014-09-04

Posts: 9

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

OMG now I see seabios on HDMI output, what a relief! Thank you guys so much.

Now I use i915 vga arbiter patch only and reduced boot args to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on i915.enable_hd_vgaarb=1 pci-stub.ids=10de:1184,10de:0e0a"

and I removed i915 from blacklist.

It's time to install Windows.

Last edited by zsph (2014-09-05 11:50:44)

---

Asus P8Z77-V LK, Core i7 3770, Asus NVIDIA GTX 770 DirectCU II OC, Debian x64, EFI, Kernel 3.16 + i915 arbiter patch.
3DMark11: bare metal P10231 vs vfio P10039: 98% of performance!

tuxuser

Member

Registered: 2014-08-23

Posts: 8

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

I implemented this a couple of weeks ago on a Mint 17 install so I just wanted to chime in and say thanks for all the info contributed to this thread.  It actually inspired me to finally test out Arch which is running quite well I might add )

I believe most people are using pci-stub as builtin, but for those using pci-stub as a module this information may prove helpful.  Basically when I discovered that the MODULES line for mkinitcpio.conf did not allow for module options the next step I took was to include the respective module options file.

Ex:

[root@archost ~]# grep pci /etc/mkinitcpio.conf
MODULES="pci_stub"
FILES="/etc/modprobe.d/pci_stub.conf"

[root@archost ~]# cat /etc/modprobe.d/pci_stub.conf 
options pci_stub ids=10de:1183,10de:0e0a,8086:1e20

Another thing is that those of you that are passing through Nvidia might find that Nouveau can be quite the ninja even though you feel sure you've done everything to get it blacklisted.  You might be better of just building the kernel without Nouveau support or a quick hack would be to rename the module and rebuild your initial ramdisk

tuxuser

Member

Registered: 2014-08-23

Posts: 8

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Here are a couple of notes about dual monitor usage on the passthrough card to the windows vm.  That includes making the monitor automatically switch outputs and also automatically starting the vm on boot.
NOTE:  in this situation I do not run Xorg nor do I make use of libvirt.  This is just how I like it

I boot Arch to text console and that is using the vga connection on the onboard intel HD video to what I consider my secondary monitor.  I also have a DVI connection hooked up to this same monitor that is connected to the second dvi port on the passthrough card.  The first DVI port on the passthrough card connects to my primary monitor.

Normally on a monitor with multiple inputs I could issue a 'vbetool dpms off' and that would cause the monitor to toggle to the next active input (in this case the windows vm).  For whatever reason vbetool isn't working for me is this setup.

So I added the following code to my vm start script:

# set console screen blank to occur in the next 30 seconds (a delay that allows the vm to start sending a signal to its secondary display)
chmod +w /sys/module/kernel/parameters/consoleblank
echo 30 > /sys/module/kernel/parameters/consoleblank

# wait 60 seconds (in the background) then revert the blanking interval back to the standard 10 minutes
(sleep 60 && echo 600 > /sys/module/kernel/parameters/consoleblank) &

...

screen -d -m -S myvm qemu-system-x86_64 ...

...

So the end result is that 30 seconds later both monitors are displaying vm output.

Now about auto booting.  My start script actually makes use of certain components that make this work:
1) GNU screen (screen -d -m -S myvm ...) to invoke qemu and detach
this makes it service friendly while still allowing you to reattach and issue Qemu monitor commands as needed

2) qemu is passed the following extra parameters: -nographic and -echr 2
echr 2 changes the qemu hot key from CTRL - A to CTRL - B and that is because GNU screen also uses CTRL - A

# cat /etc/systemd/system/myvm.service

[Unit]
Description=myvm
After=network.target

[Service]
Type=forking
ExecStart=/root/myvm.sh

[Install]
WantedBy=multi-user.target

EDIT:  It's worth mentioning that not all monitors will automatically search for the next input with a signal.  And qemu monitor could be set up for telnet access if you don't want to mess with GNU screen.

Last edited by tuxuser (2014-09-07 00:36:20)

redger

Member

Registered: 2014-02-26

Posts: 15

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

A quick note to anyone running VGA Passthrough on Ubuntu Trusty .....

I added

-nodefaults

to the start command and saw minimum frame rates in my test case go from <20 to >40 .. a Huge performance increase for a very minor change.

I only added the parameter after I noticed that the libvirt generated command ran much faster .. and eventually narrowed the difference down to this one parameter

ymmv

risho

Member

Registered: 2011-09-06

Posts: 44

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

rig:

ASRock Z97 Extreme6
Intel 4790K
hostgpu:intel
passthrough card:Nvidia GTX580

i am useing the pkgbuild for the kernel on page 1. I am using qemu and seabios from the repo. i am using the vfio-bind script on page 1 and i have nouveau blacklisted.

mkinitcpio modules:

i915 kvm kvm_intel pci-stub

syslinux.cfg relevant information

LABEL arch-qemu
   MENU LABEL Arch Qemu
   LINUX ../vmlinuz-linux-mainline
   APPEND root=/dev/sda1 rootflags=subvol=__active/rootvol intel_iommu=on i915.enable_hd_vgaarb=1 pcie_acs_override=downstream pci-stub.ids=10de:1080,10de:0e09 rw
   INITRD ../initramfs-linux-mainline.img

something to note when i have "intel_iommu=on" active on my kernel parameters it says something to the effect of "DRHD handling fault status reg 3" and then stalls for a while while booting, but then when i disable it it boots just fine.
here's a picture: http://i.imgur.com/whwRVgF.jpg

lspci

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)                                                                        
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller                                                                                              
00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1                                                                                        
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V                                                                                                      
00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
00:1c.2 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 (rev d0)
00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0)
00:1c.6 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 7 (rev d0)
00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1
00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family Z97 LPC Controller
00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 580] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)
02:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
05:00.0 PCI bridge: ASMedia Technology Inc. Device 1184
06:01.0 PCI bridge: ASMedia Technology Inc. Device 1184
06:03.0 PCI bridge: ASMedia Technology Inc. Device 1184
06:05.0 PCI bridge: ASMedia Technology Inc. Device 1184
06:07.0 PCI bridge: ASMedia Technology Inc. Device 1184
07:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller with HyperDuo (rev 11)
08:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
09:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
0a:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
0b:00.0 USB controller: ASMedia Technology Inc. Device 1142

lspci -n

lspci -n
00:00.0 0600: 8086:0c00 (rev 06)
00:01.0 0604: 8086:0c01 (rev 06)
00:01.1 0604: 8086:0c05 (rev 06)
00:02.0 0300: 8086:0412 (rev 06)
00:03.0 0403: 8086:0c0c (rev 06)
00:14.0 0c03: 8086:8cb1
00:16.0 0780: 8086:8cba
00:19.0 0200: 8086:15a1
00:1a.0 0c03: 8086:8cad
00:1b.0 0403: 8086:8ca0
00:1c.0 0604: 8086:8c90 (rev d0)
00:1c.2 0604: 8086:8c94 (rev d0)
00:1c.3 0604: 8086:8c96 (rev d0)
00:1c.6 0604: 8086:8c9c (rev d0)
00:1d.0 0c03: 8086:8ca6
00:1f.0 0601: 8086:8cc4
00:1f.2 0106: 8086:8c82
00:1f.3 0c05: 8086:8ca2
01:00.0 0300: 10de:1080 (rev a1)
01:00.1 0403: 10de:0e09 (rev a1)
02:00.0 0c03: 1912:0014 (rev 03)
04:00.0 0200: 10ec:8168 (rev 11)
05:00.0 0604: 1b21:1184
06:01.0 0604: 1b21:1184
06:03.0 0604: 1b21:1184
06:05.0 0604: 1b21:1184
06:07.0 0604: 1b21:1184
07:00.0 0106: 1b4b:9130 (rev 11)
08:00.0 0106: 1b21:0612 (rev 02)
09:00.0 0280: 168c:0030 (rev 01)
0a:00.0 0106: 1b21:0612 (rev 02)
0b:00.0 0c03: 1b21:1142

qemu.sh(the op's script with my card put in and the cpu changed

qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
-smp 6,sockets=1,cores=3,threads=2 \
-bios /usr/share/qemu/bios.bin -vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1

and i'm getting output

No protocol specified
Could not initialize SDL(No available video device) - exiting

then for some reason after a while i ran that qemu.sh and i got the output

qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/16: Device or resource busy
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 16
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

any ideas on whats going on?

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

rig:

ASRock Z97 Extreme6
Intel 4790K
hostgpu:intel
passthrough card:Nvidia GTX580

i am useing the pkgbuild for the kernel on page 1. I am using qemu and seabios from the repo. i am using the vfio-bind script on page 1 and i have nouveau blacklisted.

mkinitcpio modules:

i915 kvm kvm_intel pci-stub

syslinux.cfg relevant information

LABEL arch-qemu
   MENU LABEL Arch Qemu
   LINUX ../vmlinuz-linux-mainline
   APPEND root=/dev/sda1 rootflags=subvol=__active/rootvol intel_iommu=on i915.enable_hd_vgaarb=1 pcie_acs_override=downstream pci-stub.ids=10de:1080,10de:0e09 rw
   INITRD ../initramfs-linux-mainline.img

something to note when i have "intel_iommu=on" active on my kernel parameters it says something to the effect of "DRHD handling fault status reg 3" and then stalls for a while while booting, but then when i disable it it boots just fine.
here's a picture: http://i.imgur.com/whwRVgF.jpg

You need to run 3.17-rc or disable the Marvell controller.  That device is known to use an invalid PCIe requester ID for DMA.  3.17 includes DMA alias support to enable support for these devices.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

risho

Member

Registered: 2011-09-06

Posts: 44

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

##what patches do i need for 3.17?##

EDIT:

I'm going to try to see if i can get it working at all first before i start messing with compiling different kernels, though i really do appreciate the info. I've decided to just manually remove the device and it's working fine now.

I'm still getting

No protocol specified
Could not initialize SDL(No available video device) - exiting

edit 2:

i'm a dope. i was running it as root

not running it as root is giving me the error

qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/15: Permission denied
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 15
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

Last edited by risho (2014-09-07 06:47:48)

tuxuser

Member

Registered: 2014-08-23

Posts: 8

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

@risho Maybe take a look at your iommu groups using the lsgroup script that aw provided on page 30 or so?  Also you can use lspci -nn to combine the output instead of a seperate lspci / lspci -n run.

Mardok45

Member

Registered: 2014-08-10

Posts: 5

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

The R9 270X is just a 7870 card rebranded and overclocked, regardless any video card can be passed through its just a PCI redirect afaik. Its upto the guest to support the video card.

More important than the video card is how are you running CPU/RAM, are you using cgroups and hugetlbfs?

Thanks for the information, if I can't get my nVidia card to work, I'll probably get this.  More information below.

Add kvm=off to the -cpu parameter list to make current Nvidia driver not get Code 43.  Also add hv_time to enable hypver-v enlightened time keeping.  Older kernels can have poor performance if the game makes use of debug registers, run something new.  Hugepages, pinning, and vCPU model tuning also help.  All of this is documented in the very, very long thread.

This worked, but I'm no longer using QEMU.  More information below.

@mardok45 check your cpu config

    <topology sockets='1' cores='4' threads='1'/>

if u set 2 cores 2 threads dota works 2x slower, also check your cpu model, hvtime option... etc... host cpufreq settings....

I think I was not setting the right CPU topology and the performance was better after tweaking it, but I'm not on QEMU anymore.  More information below.

I played around with this for about a month and found out a lot of information.

First things first, the hardware.  If you plan on using this for games, not only should you make sure the CPU and motherboard support IOMMU/VT-x&VT-d, you should pick out a motherboard that either:

* You can alter the primary display in your motherboards BIOS or it can pick its primary display depending on which GPU slot is plugged in to a montior.
or
* Has at least two PCI-E slots that work at x16.
AND
Make sure you have at least one AMD GPU or a nVidia Quadro.  In my case, I have on old ATI 4850 and a Radeon HD 7470.

I forgot what kind of specs my motherboard had, and found out later that the second PCI-E slot operates at x8 speeds.  Not good for gaming.  That explains why Dota 2 was having rendering problems. 

So I thought, "Okay, just plug my nVidia card into the first slot so it'll operate at x16 speeds."  Well, I don't know for sure, but I think that because the nVidia GPU was bootstrapped when I turned the physical machine on, it couldn't re-bootstrap itself when I passed it through to the DomU.  This caused it to just display nothing.

But here's where it gets really weird; my AMD cards don't suffer from this problem.  Both of my Radeon cards have no problem being in the primary display, and then being passed through to the DomU.  They display just fine.  Does anyone else have the same experience?

My motherboard can either set the primary display to a PCI or PCI-E slot, so I'm going to try to get my hands on a PCI GPU and set the primary display to the PCI slot.  I'm hoping this will cause the nVidia GPU to not get bootstrapped and it can then be passed through to the DomU with no problems.  It had no problems being passed through when it was in the x8 slot, so I'm fairly confident it'll work.

Now moving on to the software.  I'm using Gentoo for the host, but it's just a personal preferance of mine.  You can accomplish this with any distribution.  At first, I was using QEMU.  I had no problems with a Linux guest, but Windows was a different story.

Right off the bat, the Windows installation took an unusually long time.  The Windows 7 installer would get hung on 0% for over an hour before files started getting copied over.  It's not due to performance on anything and I can't explain why it does this.

Then I had to go through the Windows updates.  This was scary because Windows would just become unbootable.  I cannot explain this to you.  For whatever reason, at some point during updates, Windows would just become completely unbootable.  It goes straight into the "Fix Windows boot problems" prompt and it cannot fix itself.  If anyone can shed some light on this, please do because it has caused so many headaches.

When I switched to Xen 4.4, I've had zero problems with Windows.  Zero, nada, zilch.  It works... almost perfectly.

Now you have the problem with the GPU, and it's not Window's fault.  You have to eject the card before you reboot it, and I cannot figure out how to automate this.  If anyone does, can you explain how?  I've tried the automated eject as destribed here, and it didn't work for me: http://blog.ktz.me/?p=219.  So if anyone has a suggestion, I would love to hear it.

Now there's one detail left: sound.  At first, I tried straight-up ALSA/dmix and gave it a sound card with a config like this:

builder='hvm'
device_model_override = "/usr/bin/qemu-system-x86_64"
memory = 3072
vcpus=6
name = "windows"
vif = ['']
disk = ['phy:/dev/system/windows,hda,w']
acpi = 1
stdvga=1
usbdevice='tablet'
boot="dc"
sdl=0
serial='pty'
vnc=1
vnclisten="0.0.0.0"
xen_platform_pci=1
viridian=1
apic=1
gfx_passthru=0
pci=['01:00.0', '01:00.1', '00:12.0', '00:12.2']
on_poweroff='destroy'
on_reboot='destroy'
on_crash='destroy'
soundhw='hda'

This worked fine for Linux, but Windows's sound was crackly.  I cannot explain why.  So I set up PulseAudio by running system-wide and adding the root user to the pulse and pulse-access groups (which you really shouldn't do, but I had no other choice), and now sound works great.

So there you have it.  The only thing that's left for me to do is to test the nVidia setup as I described above and get a KVM switch, then I'll have the perfect setup.  If anyone has any suggestions or comments, please give me a shout.

Last edited by Mardok45 (2014-09-07 18:21:40)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Now moving on to the software.  I'm using Gentoo for the host, but it's just a personal preferance of mine.  You can accomplish this with any distribution.  At first, I was using QEMU.  I had no problems with a Linux guest, but Windows was a different story.

Right off the bat, the Windows installation took an unusually long time.  The Windows 7 installer would get hung on 0% for over an hour before files started getting copied over.  It's not due to performance on anything and I can't explain why it does this.

Then I had to go through the Windows updates.  This was scary because Windows would just become unbootable.  I cannot explain this to you.  For whatever reason, at some point during updates, Windows would just become completely unbootable.  It goes straight into the "Fix Windows boot problems" prompt and it cannot fix itself.  If anyone can shed some light on this, please do because it has caused so many headaches.

I'd guess this likely has a lot to do with the QEMU Q35 machine and AHCI.  It's terrible.  Regardless of how many times I mention to just use 440FX and give examples of doing it, people continue to use Q35 when they don't need to.  Xen uses a 440FX model.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users