Arch Linux

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

Gentooist in me speaks again: "Nope. If you're missing some dependencies, make could just say something "oh, you don't have that software, well, i'll just drop it's support out completely" and continue building. Moreover, in gentoo there's a feature called USE-flags to specifically tell the toolchain that you want some select features."

And also, you can check your iptables.

Well , I'll build em packages again using yaourt . How can I save the build log for examining it later ?

Oh , and I don't use iptaples or any other firewalls for the time being , so its not the cause for this issue .

Cheers !

As you might have guessed, i'm not so familiar with arch's build system or whatever you've used(gentoo uses ebuilds where it's almost always just make $MAKE_OPTS, LFS uses plain make and make install, fedora uses rpmbuild which uses, if i remember right some special environment for make install call), i can't help you with extracting the build log. It's just a general advice to examine the build log when you change nothing but the compiler's version and something breaks.

If you haven't configured your kernel manually, you certainly do have iptables(or it's alternatives) and netfilter installed, so it doesn't hurt to check or even flush them all and see if it works.
"iptables --flush -t filter" should work, if i remember right.

---

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.

supertrampx

Member

Registered: 2015-06-07

Posts: 11

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

I have checked MSI enable on my GTx 970. In linux it reports MSI: enable-    in windows when I view the connection type pci, i see the card after driver install using msi.

I am getting this error occasionally after a freeze and vm crashes, usually when I am installing, or accessing the graphics card.

qemu-system-x86_64: vfio_err_notifier_handler(0000:04:00.0) Unrecoverable error detected.  Please collect any data possible and then kill the guest

any thoughts or ideas?

You got a fatal AER error.  Are you overclocking?  You can boot the host with pci=noaer to disable it, but that's no guarantee that the you're not still getting bus errors.

I am not overclocking. I will try the recommended pci=noaer tag.

also quick note, I found this response by another SR-2 Classified user on another forum perhaps it is of relevance?

"
Long answer: There is a bug in the NF200 PCIe bridges that will prevent you from allocating more than about 2.5GB of RAM (possibly less, depending on the hardware you have in the machine) to each VM.

It can be worked around if you are using the latest bleeding edge QEMU (used by both Xen and KVM). I've been running such a system for years, long before the required QEMU feature was added, but I had to bodge a patch onto hvmloader to make it mark all the low RAM between 1GB and 4GB as reserved to make it work. Otherwise when the VM accesses the RAM that overlaps with the PCI IOMEM region (aperture) it will trample the real IOMEM region, which will crash the machine, and if it is the disk controller's IOMEM it is trampling, it can corrupt your data, too."

Tips on how to reserve this ram, or patch the kernel to reserve it would be excellent!
Thanks in advanced, a fix on this would be awesome!
Passthrough works great, but freezes often due to these AER bugs

Last edited by supertrampx (2015-06-22 11:57:12)

Blind Tree Frog

Member

Registered: 2013-12-31

Posts: 27

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

Long answer: There is a bug in the NF200 PCIe bridges that will prevent you from allocating more than about 2.5GB of RAM (possibly less, depending on the hardware you have in the machine) to each VM.

I'm going off memory of something that I noted but didn't look into too closely, but I think I did see this  occurring before I switched to Q35... that would explain why the available memory never looked right.

Edit:
self clarification if nothing else.... not saying that I have a nf200 pcie, just saying that that sounded similar to what I remember seeing.  So it's at least calming to me to see that it could have been related to the machine type I was using and misconfigured PCI root stuff.  Perhaps it was something else entirely.

Last edited by Blind Tree Frog (2015-06-22 14:37:40)

Blind Tree Frog

Member

Registered: 2013-12-31

Posts: 27

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

@Duelist :

I am certain that if there were problems with the building proccess , the whole thing would throw and error and ask if you would like to start from the begining .

Gentooist in me speaks again: "Nope. If you're missing some dependencies, make could just say something "oh, you don't have that software, well, i'll just drop it's support out completely" and continue building. Moreover, in gentoo there's a feature called USE-flags to specifically tell the toolchain that you want some select features."

Assuming the Makefile was written with such support. (as a general statement... i didn't pay attention to what we are building right now)

nlamember

Member

Registered: 2015-06-22

Posts: 1

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

Hello everyone, Could anybody help me with my problem? Here is the situation: 1. Compute Node [Ubuntu 14.04.02, KVM, Kilo] with Nvidia Tesla K40 I passed it by using this method: https://wiki.openstack.org/wiki/Pci_passthrough I download all drivers and CUDA libraries + I compiled all sample files succesfully. However when I run them they run but in the end the do not finish . For example run log of deviceQuery:
----------------------------------------------
deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
Detected 1 CUDA Capable device(s) Device 0: "Tesla K40m"
//INFO ABOUT IT
Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >

deviceQuery,
CUDA Driver = CUDART,
CUDA Driver Version = 7.0,
CUDA Runtime Version = 7.0,
NumDevs = 1,
Device0 = Tesla K40m
Result = PASS
|
--------------------------------------
And then it just hangs, only option is to ctrl+c. Moreover I installed everything on host too and there it finished sucessfully without any problems. Any help will be appreciated.

dmesg on VM says only:
[ 1475.225692] nvidia 0000:00:08.0: irq 51 for MSI/MSI-X
dmesg on host:
kernel: [ 2897.503162] vfio-pci 0000:02:00.0: irq 324 for MSI/MSI-X

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

I've heard some news about XenGT(or KVMGT or whatever) in linux 4.1, but lkml doesn't hint me on details.
Can anyone give me a brief info about it's state? Does anybody knows about it?

Oh, and also, since we all need some very robust input to our VMs, there's a new way of doing this: virtio-input. If i understand correctly, it's inside 4.1 release now.

Last edited by Duelist (2015-06-22 14:16:25)

---

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.

PrinzipDesSees

Member

Registered: 2015-06-04

Posts: 5

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

I finally got the x-vga working with a wrapper script, it was the stupidest ninja typo ever.

Many thanks @aw for all the information in the vfio blogspot and to OP and aw with info and explanation in this thread! Finally everything works like a charm.

@Denso

<bla>
And here in the gentoo handbook in english:
https://wiki.gentoo.org/wiki/Handbook:A … g_features

PORT_LOGDIR saves the entire logs into the specified path
The options with elog allow for filtering specific logclasses and further things.
</bla>

oops right, yaourt is from arch, not gentoo, I have mistaken it with the other package manager in gentoo. Ignore this.

EDIT:

@Duelist
That seems very interesting, I'll post here if I find something specific about it.

Here something on the xen mailinglist, seems they havent got it into the official kernel yet but there is a link to multiple github repos containing preview code.
They have also done a demo patch for using the thing on qemu. It seems however that this only works for intel graphics currently.
http://lists.xen.org/archives/html/xen- … 01848.html

They renamed the thing to Intel GVT
https://01.org/xen/blogs/wangbo85/2015/ … e-q12015-0

Last edited by PrinzipDesSees (2015-06-22 14:39:06)

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

@Denso

And here in the gentoo handbook in english:
https://wiki.gentoo.org/wiki/Handbook:A … g_features

PORT_LOGDIR saves the entire logs into the specified path
The options with elog allow for filtering specific logclasses and further things.

Dude, i'm certainly sure he uses arch, so your gentoo-specific advice is a bit off.
A gentooist in me spoke because the first thing you do when something breaks in gentoo is reading the build log. Same thing for LFS, so considering the fact he compiled his QEMU with a cutting-edge fresh GCC and stumbled into problems - maybe build log would be useful to check.

---

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

Long answer: There is a bug in the NF200 PCIe bridges that will prevent you from allocating more than about 2.5GB of RAM (possibly less, depending on the hardware you have in the machine) to each VM.

It can be worked around if you are using the latest bleeding edge QEMU (used by both Xen and KVM). I've been running such a system for years, long before the required QEMU feature was added, but I had to bodge a patch onto hvmloader to make it mark all the low RAM between 1GB and 4GB as reserved to make it work. Otherwise when the VM accesses the RAM that overlaps with the PCI IOMEM region (aperture) it will trample the real IOMEM region, which will crash the machine, and if it is the disk controller's IOMEM it is trampling, it can corrupt your data, too."

Tips on how to reserve this ram, or patch the kernel to reserve it would be excellent!
Thanks in advanced, a fix on this would be awesome!
Passthrough works great, but freezes often due to these AER bugs

This sounds like exactly what ACS and IOMMU groups are meant to protect.  Researching the NF200, it looks like it's specifically designed to optimize peer-to-peer traffic *without* forwarding it upstream and therefore without IOMMU interaction.  Can I assume that you need to use the ACS override patch to even assign devices behind the NF200 to separate VMs?

---

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

CharlieBra7o

Member

Registered: 2014-03-01

Posts: 20

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

Finally got VGA passthrough working stably with 4.1.0 kernel, VFI-PCI, OVMF ROM and manually loaded VGA ROM with EFI support. Thanks to aw's amazing blogspot posts

One issue, however, remains:
I'm trying to passthrough a X-Fi (PCI-E) sound card, since I just can't get sound passed through to the on-board sound card linux uses...
So I added the sound card (06:00.0 - alone in an IOMMU group) to the vfio-pci module and added the device in the virt-manager GUI (just like I do with the graphics card). After the OS (Win 8.1) installation and first boot the sound works fine with the built-in drivers. However, after installing the official X-Fi drivers for Win 8.1, my system seems to run into trouble handling the IRQ ("irq 18: nobody cared [...] Disabling IRQ #18"). The Windows loading screen then takes 2 minutes after the IRQ issue comes up (on first boot it takes more like 5 secs...).

Here is some (cropped to the essential info) output describing the problem and determining where the IRQ belongs to:

dmesg > http://ix.io/jeY (see the block [Jun22 16:33] at the very bottom)
/proc/interrupts > http://ix.io/jf0 (IRQ #18 handles the vfio-pci interrupt for the sound card, which is 06:00.1)
lspci -v > http://ix.io/jeZ (this are all the devices registered to IRQ #18)

Rebooting the host and reloading the vfio-pci kernel module don't produce different behavior, neither does uninstalling the X-Fi drivers again and/or installing the ones from windows update. I also reinstalled Win 8.1 like 4 times now, and everything happens exactly the same way. I don't really get what's going on there... :\

Last edited by CharlieBra7o (2015-06-22 17:34:58)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Finally got VGA passthrough working stably with 4.1.0 kernel, VFI-PCI, OVMF ROM and manually loaded VGA ROM with EFI support. Thanks to aw's amazing blogspot posts

One issue, however, remains:
I'm trying to passthrough a X-Fi (PCI-E) sound card, since I just can't get sound passed through to the on-board sound card linux uses...
So I added the sound card (06:00.0 - alone in an IOMMU group) to the vfio-pci module and added the device in the virt-manager GUI (just like I do with the graphics card). After the OS (Win 8.1) installation and first boot the sound works fine with the built-in drivers. However, after installing the official X-Fi drivers for Win 8.1, my system seems to run into trouble handling the IRQ ("irq 18: nobody cared [...] Disabling IRQ #18"). The Windows loading screen then takes 2 minutes after the IRQ issue comes up (on first boot it takes more like 5 secs...).

Here is some (cropped to the essential info) output describing the problem and determining where the IRQ belongs to:

dmesg > http://ix.io/jeY (see the block [Jun22 16:33] at the very bottom)
/proc/interrupts > http://ix.io/jf0 (IRQ #18 handles the vfio-pci interrupt for the sound card, which is 06:00.1)
lspci -nnk > http://ix.io/jeZ (this are all the devices )

Rebooting the host and reloading the vfio-pci kernel module don't produce different behavior, neither does uninstalling the X-Fi drivers again and/or installing the ones from windows update. I also reinstalled Win 8.1 like 4 times now, and everything happens exactly the same way. I don't really get what's going on there... :\

Probably broken INTx masking on the sound card.  You can try using the nointxmask=1 option to vfio-pci, which can be kind of difficult to manage because you'll need to get exclusive interrupts for everything, or you could try something like this to just require an exclusive interrupt for the sound card:

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c6dc1df..e0e6cb3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3051,6 +3051,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, 0x0030,
                         quirk_broken_intx_masking);
 DECLARE_PCI_FIXUP_HEADER(0x1814, 0x0601, /* Ralink RT2800 802.11n PCI */
                         quirk_broken_intx_masking);
+DECLARE_PCI_FIXUP_HEADER(0x1102, 0x000b, quirk_broken_intx_masking);
 /*
  * Realtek RTL8169 PCI Gigabit Ethernet Controller (rev 10)
  * Subsystem: Realtek RTL8169/8110 Family PCI Gigabit Ethernet NIC

(the -nn part of you lspci didn't seem to take, so double check that vendor:device ID).

You might also read the article on my blog about getting devices to use MSI, that's usually the better option for something as latency sensitive as audio anyway.

---

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

Denso

Member

Registered: 2014-08-30

Posts: 179

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

oops right, yaourt is from arch, not gentoo, I have mistaken it with the other package manager in gentoo. Ignore this.

No problem man , thanks for spending the time looking for this !

Dude, i'm certainly sure he uses arch

For me , Arch is the only Linux out there .

Anyway , I'll try downgrading to GCC 4.9 and see if it would fix those issues . I'll keep you posted !

Edit : Sigh , isn't there a "Legacy" repo for Arch ?

Edit 2 :

So I finally captured the build log (GCC 5.1) , it threw a lot of warnings :

nbd.c: In function 'nbd_trip':
nbd.c:1321:15: warning: 'request.len' may be used uninitialized in this function [-Wmaybe-uninitialized]
         ret = blk_read(exp->blk,
               ^
nbd.c:1385:54: warning: 'request.from' may be used uninitialized in this function [-Wmaybe-uninitialized]
         ret = blk_co_discard(exp->blk, (request.from + exp->dev_offset)
                                                      ^
nbd.c:1291:18: warning: 'request.handle' may be used uninitialized in this function [-Wmaybe-uninitialized]
     reply.handle = request.handle;
                  ^
nbd.c:1354:26: warning: 'request.type' may be used uninitialized in this function [-Wmaybe-uninitialized]
         if (request.type & NBD_CMD_FLAG_FUA) {
                          ^
block/vmdk.c: In function 'vmdk_open_desc_file.isra.12':
block/vmdk.c:848:39: warning: 'extent' may be used uninitialized in this function [-Wmaybe-uninitialized]
             extent->flat_start_offset = flat_offset << 9;
                                       ^
block/vmdk.c:776:17: note: 'extent' was declared here
     VmdkExtent *extent;
                 ^
block/vmdk.c: In function 'vmdk_open_vmdk4':
block/vmdk.c:701:24: warning: 'extent' may be used uninitialized in this function [-Wmaybe-uninitialized]
     extent->has_marker = le32_to_cpu(header.flags) & VMDK4_FLAG_MARKER;
                        ^
block/vmdk.c: In function 'vmdk_open_sparse':
block/vmdk.c:513:9: warning: 'extent' may be used uninitialized in this function [-Wmaybe-uninitialized]
     ret = vmdk_init_tables(bs, extent, errp);
         ^
block/vmdk.c:492:17: note: 'extent' was declared here
     VmdkExtent *extent;
                 ^
hw/input/adb.c: In function 'adb_poll':
hw/input/adb.c:81:23: warning: array subscript is above array bounds [-Warray-bounds]
         d = s->devices[i];
                       ^
hw/usb/hcd-ohci.c: In function 'ohci_service_ed_list.part.6':
hw/usb/hcd-ohci.c:414:26: warning: array subscript is above array bounds [-Warray-bounds]
         if ((ohci->rhport[i].ctrl & OHCI_PORT_PES) == 0) {
                          ^
hw/usb/hcd-ohci.c:414:26: warning: array subscript is above array bounds [-Warray-bounds]
         if ((ohci->rhport[i].ctrl & OHCI_PORT_PES) == 0) {
                          ^
slirp/mbuf.c: In function 'm_cat':
slirp/mbuf.c:136:1: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
 m_cat(struct mbuf *m, struct mbuf *n)
 ^
slirp/mbuf.c:158:11: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
         if(m->m_size>size) return;
           ^
slirp/socket.c: In function 'soread':
slirp/socket.c:193:5: warning: 'n' may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (n == 2 && nn == iov[0].iov_len) {
     ^
In file included from /usr/lib/glib-2.0/include/glibconfig.h:9:0,
                 from /usr/include/glib-2.0/glib/gtypes.h:32,
                 from /usr/include/glib-2.0/glib/galloca.h:32,
                 from /usr/include/glib-2.0/glib.h:30,
                 from /tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/include/glib-compat.h:19,
                 from /tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/include/qemu-common.h:43,
                 from slirp/socket.c:8:
slirp/socket.c: In function 'soreadbuf':
/usr/include/glib-2.0/glib/gmacros.h:240:39: warning: 'iov.iov_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
 #define MIN(a, b)  (((a) < (b)) ? (a) : (b))
                                       ^
slirp/socket.c:215:15: note: 'iov.iov_len' was declared here
  struct iovec iov[2];
               ^
slirp/socket.c: In function 'sorecvoob':
slirp/socket.c:193:5: warning: 'n' may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (n == 2 && nn == iov[0].iov_len) {
     ^
slirp/socket.c:153:6: note: 'n' was declared here
  int n, nn;
      ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c: In function 'get_real_device':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:649:44: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
     pci_dev->dev.config[1] = (id & 0xff00) >> 8;
                                            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c: In function 'assign_failed_examine':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:771:12: warning: 'device_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return g_strdup_printf(
            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:771:12: warning: 'vendor_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
In file included from /tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c:23:0:
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c: In function 'disas_tas':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/tcg/tcg-op.h:58:5: warning: 'addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
     tcg_gen_op2(&tcg_ctx, opc, GET_TCGV_I32(a1), GET_TCGV_I32(a2));
     ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c:1507:10: note: 'addr' was declared here
     TCGv addr;
          ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-sh4/helper.c: In function 'superh_cpu_get_phys_page_debug':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-sh4/helper.c:527:12: warning: 'physical' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return physical;
            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-sh4/helper.c: In function 'superh_cpu_get_phys_page_debug':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-sh4/helper.c:527:12: warning: 'physical' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return physical;
            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c: In function 'get_real_device':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:649:44: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
     pci_dev->dev.config[1] = (id & 0xff00) >> 8;
                                            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c: In function 'assign_failed_examine':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:771:12: warning: 'device_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return g_strdup_printf(
            ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/hw/i386/kvm/pci-assign.c:771:12: warning: 'vendor_id' may be used uninitialized in this function [-Wmaybe-uninitialized]
In file included from /tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c:23:0:
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c: In function 'disas_tas':
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/tcg/tcg-op.h:58:5: warning: 'addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
     tcg_gen_op2(&tcg_ctx, opc, GET_TCGV_I32(a1), GET_TCGV_I32(a2));
     ^
/tmp/yaourt-tmp-root/aur-qemu-git/src/qemu/target-m68k/translate.c:1507:10: note: 'addr' was declared here
     TCGv addr;
          ^

libtool: warning: remember to run 'libtool --finish /usr/lib'
libtool: warning: 'libcacard.la' has not been installed in '/usr/lib'

Anyone can make any sense of these ? and wether they're related to the bridged networking issues I'm having ?

Thanks !

Last edited by Denso (2015-06-22 17:52:02)

CharlieBra7o

Member

Registered: 2014-03-01

Posts: 20

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

(the -nn part of you lspci didn't seem to take, so double check that vendor:device ID).

Actually it was just -v. I just mistyped it coz I typed "-nnk" about 1000 times the last few days Edited my post accordingly...

You might also read the article on my blog about getting devices to use MSI, that's usually the better option for something as latency sensitive as audio anyway.

I just tried MSI. The card supports it (according to lspci -v), and it gets enabled (/proc/interrupts and devmgmt.msc tell me that) after I set the DWORD in the registry. But with MSI there is still no sound... Even trying to (re)install the sound drivers with MSI enabled doesn't work - the problem is, that every driver I install (tried 3 different ones), deletes or sets the MSI DWORD to 0, so INTx is used again, resulting in no sound... Is there a trick to this?

The weirdest thing, however, is, that the sound works fine right after the installation (when MSI is turned OFF). Doesn't make any sense to me at all...

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

@CharlieBra7o

Maybe the card doesn't really work with MSI either, interrupts are surprisingly difficult for hardware to get right.  I'd pursue the broken intx masking path if MSI doesn't immediately work.

---

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

Denso

Member

Registered: 2014-08-30

Posts: 179

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

Hi everyone !

I removed the qemu-git package and installed the pre-compiled package from the Extra repository , and everything is working like it should !

So it surely has something to do with GCC 5 .

Regards .

Volle

Member

From: Stuttgart, Germany

Registered: 2013-12-05

Posts: 48

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

Hey guys,

thanks for all this info in this thread but before i start to try this out i've got one question:
Is there a way to still render the guest in the qemu window?
I'm asking since i want to use this on my notebook without an additional screen connected.

Greetings
Chris

Blind Tree Frog

Member

Registered: 2013-12-31

Posts: 27

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

Hey guys,

thanks for all this info in this thread but before i start to try this out i've got one question:
Is there a way to still render the guest in the qemu window?
I'm asking since i want to use this on my notebook without an additional screen connected.

Greetings
Chris

Have multiple profiles for the same machine and you should get that (ie: same hard drive, different launch parameters).  That said, I'm fairly certain that Windows will not appreciate you doing this at all (since it doesn't like the hardware changing from under it).  Linux may not either, but I don't know offhand how much it will complain.

Volle

Member

From: Stuttgart, Germany

Registered: 2013-12-05

Posts: 48

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

Have multiple profiles for the same machine and you should get that (ie: same hard drive, different launch parameters).  That said, I'm fairly certain that Windows will not appreciate you doing this at all (since it doesn't like the hardware changing from under it).  Linux may not either, but I don't know offhand how much it will complain.

I think you didn't get me right
What i want to do is that i never use a screen and only use the vm in a window ...
But i was reading Alex Williamson's blog (RTFM) and found my answer: no...

I think i misread this forum post (post #10 in https://forums.virtualbox.org/viewtopic … 7&t=64298)
I know its about virtualbox and not qemu but they should be similar.

So no vgpu passthrough for me :<

Thanks anyways

Chris

Blind Tree Frog

Member

Registered: 2013-12-31

Posts: 27

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

I think you didn't get me right
What i want to do is that i never use a screen and only use the vm in a window ...
But i was reading Alex Williamson's blog (RTFM) and found my answer: no...

I think i misread this forum post (post #10 in https://forums.virtualbox.org/viewtopic … 7&t=64298)
I know its about virtualbox and not qemu but they should be similar.

So no vgpu passthrough for me :<

There is a reason that I didn't get you... that makes no sense in context of this discussion

Yeah, no you just want to run QEMU (or Virtualbox, or VMWare) normally and ignore the passthrough stuff.   Technically if you had a second video card I guess you could run passthrough on it and then use VNC to push it to a window on your host, but then you are back to the host's graphics and lose any advantage of the guest having his own card.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Technically if you had a second video card I guess you could run passthrough on it and then use VNC to push it to a window on your host, but then you are back to the host's graphics and lose any advantage of the guest having his own card.

That's not at all true, using an assigned GPU is a huge advantage for guest graphics, even if using something like a TightVNC server in the guest to connect.  Local connections via VNC also get the benefit that we have many Gbps of throughput using the internal bridge.  There are several videos on youtube using this model where games run a quite playable frame rates.

If your guest is Win8+, it's also possible to use both an assigned GPU and emulated graphics.  You can get 3D rendering into the emulated window, but the performance is significantly slower in this model.  The better approach is to use the emulated graphics for boot, disable it for the guest OS, and connect via guest VNC once running.  If you can't use that emulated + assigned GPU model, then you lose access to the VM until the guest VNC server is running.  This can work too, but if Windows ever wants to go into recovery mode, you'd need to remove the assigned GPU and add an emulated VGA to interact.

The more troubling problem in a laptop is that the secondary graphics in a hybrid laptop is rarely as isolated as a discrete GPU on a desktop.  As far as I'm aware, few, if any, have made it work.  The GPU ROM is often embedded in ACPI, so likely needs to be extracted by doing a dump, disassemble, and encoding of the ROM table.  Even then, mystery Code 43s seem to plaque dual graphics laptop users.

---

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

Volle

Member

From: Stuttgart, Germany

Registered: 2013-12-05

Posts: 48

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

There is a reason that I didn't get you... that makes no sense in context of this discussion

Yeah, no you just want to run QEMU (or Virtualbox, or VMWare) normally and ignore the passthrough stuff.   Technically if you had a second video card I guess you could run passthrough on it and then use VNC to push it to a window on your host, but then you are back to the host's graphics and lose any advantage of the guest having his own card.

I've got a notebook with an Intel HD chip and an Nvidia 940M
Host: arch using the Intel HD chip rendering the desktop
Guest: win8.1 using the Nvidia 940M

My intention was running a game on the Guest (since there is 'no' game support in linux yet)

[edit]
ninja'd by aw.
Yes this exactly what i want to do!
I'll give it a try (like you explained) maybe i can get it to work ....

thanks

Last edited by Volle (2015-06-23 13:11:57)

Blind Tree Frog

Member

Registered: 2013-12-31

Posts: 27

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

Technically if you had a second video card I guess you could run passthrough on it and then use VNC to push it to a window on your host, but then you are back to the host's graphics and lose any advantage of the guest having his own card.

That's not at all true, using an assigned GPU is a huge advantage for guest graphics, even if using something like a TightVNC server in the guest to connect.  Local connections via VNC also get the benefit that we have many Gbps of throughput using the internal bridge.  There are several videos on youtube using this model where games run a quite playable frame rates.

yes, "any advantage" was the wrong choice of words.  The guest still gets hardware acceleration, but there is a performance hit from the VNC interface between machines

Duelist

Member

Registered: 2014-09-22

Posts: 358

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

Did something happen to kraxel.org RPM git repo? My DNF seems to fail to update. I haven't investigated that yet.

Cannot download edk2/edk2.git-ovmf-x64-0-20150623.b1070.g37fe82e.noarch.rpm

Hmm, the rpm is in place, it's named differently:....b1071/g3cd2484
Seems like a successful build occured when i've ran dnf update.

Last edited by Duelist (2015-06-23 15:03:27)

---

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

Did something happen to kraxel.org RPM git repo? My DNF seems to fail to update. I haven't investigated that yet.

Hmm.. Seems like jenkins feels itself bad - there's a jenkins spec, there's an ovmf build target, but

Cannot download edk2/edk2.git-ovmf-x64-0-20150623.b1070.g37fe82e.noarch.rpm

I'm not so familiar with jenkins, but something is broken.

Your repo data is out of date https://www.kraxel.org/repos/jenkins/edk2/

---

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

Did something happen to kraxel.org RPM git repo? My DNF seems to fail to update. I haven't investigated that yet.

Hmm.. Seems like jenkins feels itself bad - there's a jenkins spec, there's an ovmf build target, but

Cannot download edk2/edk2.git-ovmf-x64-0-20150623.b1070.g37fe82e.noarch.rpm

I'm not so familiar with jenkins, but something is broken.

Your repo data is out of date https://www.kraxel.org/repos/jenkins/edk2/

Yeah, i was right, i was trying to update the minute new build have appeared.

---

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.