Arch Linux

mostlyharmless

Member

Registered: 2014-01-16

Posts: 72

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

Tried that, window does BSOD with error 7b, remove the device and it works again.

nbhs

Member

From: Montevideo, Uruguay

Registered: 2013-05-02

Posts: 402

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

Tried that, window does BSOD with error 7b, remove the device and it works again.

this one? https://msdn.microsoft.com/en-us/librar … 85%29.aspx, weird, works for me on 8.1

-device nec-usb-xhci,id=xhci -device usb-host,vendorid=0x046e,productid=0x530a,bus=xhci.0

Last edited by nbhs (2015-03-30 03:21:12)

Chaohong Hu

Member

Registered: 2014-12-29

Posts: 2

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

Is that possible to passthrough graphic card on a laptop? My laptop has a intel igd and a nvidia card.

If the answer is tricky or just impossible, please tell me why.

If some special laptops support passthrough, what is the features?

bierbauch

Member

Registered: 2015-03-28

Posts: 7

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

Is that possible to passthrough graphic card on a laptop? My laptop has a intel igd and a nvidia card.

If the answer is tricky or just impossible, please tell me why.

If some special laptops support passthrough, what is the features?

Interessting Question. Speaking from my experience gathered last Weekend with a desktop workstation I would say: Maybe!

It should be possible in theory but 3 things must allign for that to happen:
Intel CPU supports VT-d (i.e. i7 4500U)
Chipset supports VT-d (i.e. QM87)
and probably the most troubling:
The provided BIOS must support that option too ...

I would imagine 2 points of that list troublesome:
I pretty much never see what chipset is used in the product description.
The BIOS is pretty much never mentioned or looked at in tests and reviews, so without thinking too much about it I would say this could be a frustrating try and error phase ...

But this is just me talking. Have no practical experience. Never tried ...

tholin

Member

Registered: 2015-03-17

Posts: 7

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

I'm thinking about upgrading my Radeon HD 6770 to something more powerful. I don't like nvidia so the cards I'm considering with good price performance ratio are the following.
Radeon R9 270X
Radeon R9 285
Radeon R9 280
Any pros or cons to using any of them? Can anyone confirm that they work? What about the reset problem?

A new patch went into kernel 4.0 to work around the reset problem but it requires a switch between the cards and the root hub. My 16x lanes connect to some PLX PEX 8747 switches before the CPU root port so reset shouldn't be a problem for me?

I see that Powercolor, MSI and Sapphire got official UEFI GOP support lists for their cards but what about the other manufacturers? I can't find any lists, just speculations on forums.

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

I'm thinking about upgrading my Radeon HD 6770 to something more powerful. I don't like nvidia so the cards I'm considering with good price performance ratio are the following.
Radeon R9 270X
Radeon R9 285
Radeon R9 280
Any pros or cons to using any of them? Can anyone confirm that they work? What about the reset problem?

A new patch went into kernel 4.0 to work around the reset problem but it requires a switch between the cards and the root hub. My 16x lanes connect to some PLX PEX 8747 switches before the CPU root port so reset shouldn't be a problem for me?

I see that Powercolor, MSI and Sapphire got official UEFI GOP support lists for their cards but what about the other manufacturers? I can't find any lists, just speculations on forums.

I've heard that R9 285 is based on a new chip(so it's not rebadged 7xxx series card) and shouldn't have reset problems.
Aaand try preferring MSI or Powercolor or somebody else, because saphhire have some problems with UEFI too. Basically, if your card doesn't support UEFI natively, out of the box, then you have high chances of not getting it to work.

For stats you can check out that huge google spreadsheet from the op-post, but remember the "old" names of rebadged cards(i.e. 270x is 7970 if i recall properly).

Is that possible to passthrough graphic card on a laptop? My laptop has a intel igd and a nvidia card.

If the answer is tricky or just impossible, please tell me why.

If some special laptops support passthrough, what is the features?

Well, some notebooks(i've stumbled with lenovo myself) may have weird nvidia optimus technology, which broke everything up. The laptop that i've observed had unknown header 7f in lspci when the nvidia card is offline, and NoSoftRst+ when the card is online. Hell, that machine even couldn't go to STR and back without having that card broken. I highly doubt that VFIO will work on that setup.

Second problem is video output! As you might know, all video outputs, including the screen itself, are switched between intel and discrete gpu. How does that switch works - almost nobody knows, because it is a highly proprietary stuff. Ask guys with bumblebee, there are problems of getting it to work just like it's supposed to work. This problem applies to intel-amd(WORST COMBINATION EVER, hello rare hybrid drivers) and amd-amd notebooks too.

You can construct or buy and external pci-e 16x slot in kind of dock-station way, connecting it somewhere like pcmcia or inside to mini-pci-e or somewhere else, and plug a desktop GPU. That way it should work good, but you'll need too connect an external screen to it, or try fiddling with nvidia optimus(or some alike from AMD).

Conclusion: I wouldn't even bother. We have problems on desktops, and you're bringing a whole new opportunity to suffer from proprietary hardware&software.

P.S. I'm not sure if AMD-NVIDIA notebooks even exist on this planet. And it's not some eurocom notebooks, which are whatever you want.

Last edited by Duelist (2015-03-30 13:07:42)

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

A new patch went into kernel 4.0 to work around the reset problem but it requires a switch between the cards and the root hub.

What patch is this?

---

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

tholin

Member

Registered: 2015-03-17

Posts: 7

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

A new patch went into kernel 4.0 to work around the reset problem but it requires a switch between the cards and the root hub.

What patch is this?

Well, you wrote it.

commit d84f31744643e2c439466d513ebc1bc81c4d9186
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Fri Nov 21 11:24:14 2014 -0700

PCI: Mark AMD/ATI VGA devices that don't reset on D3hot->D0 transition

Some AMD/ATI GPUs report NoSoftRst- to indicate that they perform a reset
when software transitions them from D3hot to D0, but there is no apparent
effect on the device: the monitor remains synced and the framebuffer
contents are retained.

Callers of pci_reset_function() don't necessarily have a way to validate
whether a reset was effective, so we don't want to rely on NoSoftRst if
it's known to be inaccurate.  Returning an error in such cases appears to
be the better option.  For users like vfio-pci, this allows the driver to
escalate to the bus reset interfaces.

If a device lives on the root bus, there's really no further
escalation path, so we exempt PM reset as potentially better than
nothing.

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e52356a..31e7972 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3042,6 +3042,27 @@ static void quirk_no_bus_reset(struct pci_dev *dev)
  */
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset);
 
+static void quirk_no_pm_reset(struct pci_dev *dev)
+{
+       /*
+        * We can't do a bus reset on root bus devices, but an ineffective
+        * PM reset may be better than nothing.
+        */
+       if (!pci_is_root_bus(dev->bus))
+               dev->dev_flags |= PCI_DEV_FLAGS_NO_PM_RESET;
+}
+
+/*
+ * Some AMD/ATI GPUS (HD8570 - Oland) report that a D3hot->D0 transition
+ * causes a reset (i.e., they advertise NoSoftRst-).  This transition seems
+ * to have no effect on the device: it retains the framebuffer contents and
+ * monitor sync.  Advertising this support makes other layers, like VFIO,
+ * assume pci_reset_function() is viable for this device.  Mark it as
+ * unavailable to skip it when testing reset methods.
+ */
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+                              PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset);
+

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

A new patch went into kernel 4.0 to work around the reset problem but it requires a switch between the cards and the root hub.

What patch is this?

Well, you wrote it.

commit d84f31744643e2c439466d513ebc1bc81c4d9186

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

---

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

tholin

Member

Registered: 2015-03-17

Posts: 7

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

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

That's disappointing. Which cards are affected? Just the Bonaire XT (HD7790) or all the GCN 1.1 based cards? Are the GCN 1.2 based R9 285 unaffected like Duelist suggested?

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

That's disappointing. Which cards are affected? Just the Bonaire XT (HD7790) or all the GCN 1.1 based cards? Are the GCN 1.2 based R9 285 unaffected like Duelist suggested?

Dunno

---

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

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

What patch is this?

Well, you wrote it.

commit d84f31744643e2c439466d513ebc1bc81c4d9186

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

Huh? The behaviour you've described i've observed on HD7750 when i force-off'd the guest machine. I thought it was logical for it to behave like that. Like, the machine is killed, and the device is left in the last state it was.

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Well, you wrote it.

commit d84f31744643e2c439466d513ebc1bc81c4d9186

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

Huh? The behaviour you've described i've observed on HD7750 when i force-off'd the guest machine. I thought it was logical for it to behave like that. Like, the machine is killed, and the device is left in the last state it was.

It might be useful for debugging, but it's not intended.  We really want to return the device to the host in a similar state that we received it.  It's also nice that the monitor will turn off if the VM isn't running.  Not to mention that the data in the framebuffer is guest state that we shouldn't just leave laying around if we can help it.

---

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

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

Yep, that's the one I was afraid you were looking at.  This is only a fix for a limited number of devices that expose that they do a reset on transition from D3hot to D0.  My HD8570 is one such card.  It mostly makes the finishing reset-on-close work so the screen turns off rather than leaving the last image displayed by the guest.  This does not fix the reset problem on cards like the HD7790 or various R7/9 cards that can't even manage to reboot the guest within the same instance of the VM.  We still do not have a solution for that reset problem.

Huh? The behaviour you've described i've observed on HD7750 when i force-off'd the guest machine. I thought it was logical for it to behave like that. Like, the machine is killed, and the device is left in the last state it was.

It might be useful for debugging, but it's not intended.  We really want to return the device to the host in a similar state that we received it.  It's also nice that the monitor will turn off if the VM isn't running.  Not to mention that the data in the framebuffer is guest state that we shouldn't just leave laying around if we can help it.

Okay, i know that this feature is good, but you've said "only for selected devices". But reading the patch seems like every ATI device will be reset. Is it true? If so - that's neat.

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Okay, i know that this feature is good, but you've said "only for selected devices". But reading the patch seems like every ATI device will be reset. Is it true? If so - that's neat.

We've been resetting devices as they're released for a while (v3.17), it's not AMD specific.  What we're doing in this commit is simply blacklisting PM reset for the small population of AMD GPUs that claim to support it (NoSoftRst-).  Most GPUs, AMD or otherwise, do not claim to support PM reset, so there's no change.  When there are no function-level resets available for a device, the device remains tagged as dirty and when vfio-pci has the opportunity to do a bus reset, it will.  For this to work, all of the devices affected by a bus reset need to be bound to vfio-pci.  For instance, if you don't assign the audio function to the VM and leave it bound to pci-stub, this would be a reason to bind it to vfio-pci instead.

---

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

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

Okay, i know that this feature is good, but you've said "only for selected devices". But reading the patch seems like every ATI device will be reset. Is it true? If so - that's neat.

We've been resetting devices as they're released for a while (v3.17), it's not AMD specific.  What we're doing in this commit is simply blacklisting PM reset for the small population of AMD GPUs that claim to support it (NoSoftRst-).  Most GPUs, AMD or otherwise, do not claim to support PM reset, so there's no change.  When there are no function-level resets available for a device, the device remains tagged as dirty and when vfio-pci has the opportunity to do a bus reset, it will.  For this to work, all of the devices affected by a bus reset need to be bound to vfio-pci.  For instance, if you don't assign the audio function to the VM and leave it bound to pci-stub, this would be a reason to bind it to vfio-pci instead.

Thanks for clarification. Aaand my GPU is affected by this patch, it reports NoSoftRst- but doesn't reset. Well, half a year waiting untill 4.0 will be released..

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

syshack

Member

Registered: 2015-03-24

Posts: 5

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

i'v filed a bugzia,pls check,thx. ( https://bugzilla.redhat.com/show_bug.cgi?id=1206006)
if need more details,let me know and i will provid as soon as possible.

im sorry ，i make a stupid mistake. the fails caused by power shortage.

Glad you got it working

Thank you and erganzi!

tritron4

Member

Registered: 2012-04-14

Posts: 153

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

I just received Creative Labs Sound Blaster Audigy2 ZS PCI Sound Card and I had no issues passing it to windows 8.1

lersek

Member

Registered: 2015-03-15

Posts: 38

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

... for win7 ... although I put -smp 6, the 440fx/ovmf/Uefi version reports only two processors.

That seems to be a limitation of Windows 7.

http://en.wikipedia.org/wiki/Windows_7#Processor_limits

You can try experimenting with the -smp sub-options. I think plain

-smp 6

says "six single-core, single-thread processors", and that is beyond the Windows 7 limitation. Try to pass "two triple-core, single-thread processors" instead, with

-smp sockets=2,cores=3,threads=1

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

... for win7 ... although I put -smp 6, the 440fx/ovmf/Uefi version reports only two processors.

That seems to be a limitation of Windows 7.

http://en.wikipedia.org/wiki/Windows_7#Processor_limits

You can try experimenting with the -smp sub-options. I think plain

-smp 6

says "six single-core, single-thread processors", and that is beyond the Windows 7 limitation. Try to pass "two triple-core, single-thread processors" instead, with

-smp sockets=2,cores=3,threads=1

I used to have -smp 4 and it worked just fine with win7, showing four cores with one thread each in one socket. Now i have libvirt, and "<vcpu placement='static'>4</vcpu>" and it works fine with(or without) OVMF and win7.

Also, check it out:

I might be able to dig out some more info on this machine. All i know - this is a server machine, obviously.

UPD:
Table of testing:
S_C_T_Number of windows cores
2_2_1_4 (two sockets, two cores per socket, one thread per core, four logical cpus as seen by windows)
2_4_1_8
4_1_1_2
4_4_1_8

Weird, as wikipedia states that the limit is one socket, not two. OH. RIGHT. I've forgot what edition of windowns i have. I should go to hell for this...

Last edited by Duelist (2015-03-31 20:19:17)

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

dante82

Member

Registered: 2015-03-31

Posts: 7

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

Hi there,

I finally got to the point of succeeding in passing through my graphics card using the marvelous step-by-step guide in the first comment, thanks for keeping this also updated!!!

However, I'm experiencing heavy lags after installing the NVidia graphics card driver. I already tried the 340.52 version that doesn't have the error 43 issue. I don't experience these lags without the graphics driver (fallback to system drivers). I googled for that issue but couldn't find any leap to follow. Any ideas from the audience?

My setup is passing through a GeForce 750Ti on a Windows 8.1 64Bit VM with the following qemu call:

sudo qemu-system-x86_64 \
-enable-kvm -cpu host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
-M q35 \
-m 4096 -smp 2 \
-device vfio-pci,host=01:00.0,x-vga=on \
-device vfio-pci,host=01:00.1 \
-device vfio-pci,host=03:00.0 \
-device virtio-scsi-pci,id=scsi \
-drive file=/mnt/vir-pool/virtio-win-0.1-100.iso,id=virtiocd,if=none -device ide-cd,bus=ide.1,drive=virtiocd \
-drive file=/mnt/vir-pool/kvm-win7.img,id=disk,format=raw,if=none -device scsi-hd,drive=disk \
-net nic,model=virtio,macaddr=52:54:00:00:00:01 -net bridge,br=br0 \
-vnc :1 -vga none

PureTryOut

Member

Registered: 2014-09-23

Posts: 64

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

So somehow I managed to break it again, after it's been working great for a while.

My main graphics card (a GTX980) broke, so I sent it to RMA. In the process of de-terming what was wrong with my pc (before I found out it was the GPU), i've reinstalled my Arch Host and switched to the linux-ovmf kernel in the AUR. I've gotten it back yesterday and plugged everything in again. Added the correct video card (a GTX770) to pci-stub again.

lspci -nn

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 05)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 770] [10de:1184] (rev a1)
02:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio Controller [10de:0e0a] (rev a1)
04:00.0 Network controller [0280]: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter [14e4:43b1] (rev 03)

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on pci-stub.ids=8086:153b,14e4:43b1,10de:1184,10de:0e0a"

As my motherboard has 2 ethernet slots, i've also passthroughed(?) the ethernet adapter and the wireless adapter for Bluetooth.

To me it seems everything is correct here. However:
dmesg | grep pci-stub

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-vfio root=UUID=5ff3e9bb-e7b1-494f-8e42-6c5a1f8e7aa6 rw quiet intel_iommu=on pci-stub.ids=8086:153b,14e4:43b1,10de:1184,10de:0e0a i915.enable_hd_vgaarb=1
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-vfio root=UUID=5ff3e9bb-e7b1-494f-8e42-6c5a1f8e7aa6 rw quiet intel_iommu=on pci-stub.ids=8086:153b,14e4:43b1,10de:1184,10de:0e0a i915.enable_hd_vgaarb=1
[    0.451397] pci-stub: add 8086:153B sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.451402] pci-stub 0000:00:19.0: claimed by stub
[    0.451405] pci-stub: add 14E4:43B1 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.451409] pci-stub 0000:04:00.0: claimed by stub
[    0.451411] pci-stub: add 10DE:1184 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.451415] pci-stub 0000:02:00.0: claimed by stub
[    0.451417] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.451421] pci-stub 0000:02:00.1: claimed by stub
[    3.153520] pci-stub 0000:02:00.0: enabling device (0000 -> 0003)

So everything seems correctly blocked by pci-stub, except for 02:00.0 (which is the graphics card itself, not the audio). Somehow it re-enables itself?

Also /etc/vfio-pci.cfg:

DEVICES="0000:00:19.0 0000:02:00.0 0000:02:00.1 0000:04:00.0"

Now when I run the VM script it gives the following error:

qemu-system-x86_64: -device vfio-pci,host=02:00.0,x-vga=on: vfio: error no iommu_group for device
qemu-system-x86_64: -device vfio-pci,host=02:00.0,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,x-vga=on: Device 'vfio-pci' could not be initialized

The script:

QEMU_AUDIO_DRV=pa qemu-system-x86_64 -L . -enable-kvm -m 8096 -cpu host,kvm=off -smp 6,sockets=1,cores=6,threads=1 -vga none \
-device vfio-pci,host=02:00.0,x-vga=on -device vfio-pci,host=02:00.1 -device vfio-pci,host=00:19.0 -device vfio-pci,host=04:00.0 \
-device virtio-scsi-pci,id=scsi -drive file=/dev/sdb,id=ssddisk,format=raw,if=none -device scsi-hd,drive=ssddisk \
-usb -usbdevice host:0738:2215 -usbdevice host:13d3:3404 -usbdevice host:2516:0011 -usbdevice host:1532:0033 -soundhw hda

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Now when I run the VM script it gives the following error:

qemu-system-x86_64: -device vfio-pci,host=02:00.0,x-vga=on: vfio: error no iommu_group for device

That means the IOMMU is not enabled.  Maybe it's not enabled in the kernel config.

---

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

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

Hi there,

I finally got to the point of succeeding in passing through my graphics card using the marvelous step-by-step guide in the first comment, thanks for keeping this also updated!!!

However, I'm experiencing heavy lags after installing the NVidia graphics card driver. I already tried the 340.52 version that doesn't have the error 43 issue. I don't experience these lags without the graphics driver (fallback to system drivers). I googled for that issue but couldn't find any leap to follow. Any ideas from the audience?

My setup is passing through a GeForce 750Ti on a Windows 8.1 64Bit VM with the following qemu call:

sudo qemu-system-x86_64 \
-enable-kvm -cpu host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
-M q35 \
-m 4096 -smp 2 \
-device vfio-pci,host=01:00.0,x-vga=on \
-device vfio-pci,host=01:00.1 \
-device vfio-pci,host=03:00.0 \
-device virtio-scsi-pci,id=scsi \
-drive file=/mnt/vir-pool/virtio-win-0.1-100.iso,id=virtiocd,if=none -device ide-cd,bus=ide.1,drive=virtiocd \
-drive file=/mnt/vir-pool/kvm-win7.img,id=disk,format=raw,if=none -device scsi-hd,drive=disk \
-net nic,model=virtio,macaddr=52:54:00:00:00:01 -net bridge,br=br0 \
-vnc :1 -vga none

Any messages in dmesg maybe? Like IO_PAGE_FAULT?
What motherboard and CPU do you have?

And, aw, wasn't there some problem with one of hyper-v extensions and nvidia?

Last edited by Duelist (2015-03-31 21:22:34)

---

The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

And, aw, wasn't there some problem wioth one of hyper-v extensions and nvidia?

I didn't feel like looking it up, I assume they're using the version that detects KVM, but not Hyper-V

---

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