On 01/19/2014 04:13 AM, The PowerTool wrote:
I'm trying to pass-through my VGA card to a guest session.

I found:  http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM - which is very frustrating because there's no date on the documentation.  I suspect it's old.  It does clearly say that you must have VT-d support for pci pass-through.  It then goes on to say "Some work towards allowing this ["software pass-through"] were done, but the code never made it into KVM".  If this is old is there now support for PCI pass-through on hardware that doesn't support VT-d?

No. Kvm does not support PCI passthrough in any form on hardware that doesn't support VT-d; it is too unsafe. Apparently Xen supports it in PV mode, but this too is completely unsafe.

As far as passing through a VGA device. This is the complete bleeding edge of PCI device passthrough, and is difficult to the point of being practically impossible in many/most cases, especially for older VGA cards that weren't written with that idea in mind. Here is the page I was pointed to by Alex Williamson, who may have the most information on this topic:

   https://bbs.archlinux.org/viewtopic.php?id=162768


I have a HP p7-1456c which has:

Intel Core i5-3330 Processor (VT-x=yes, VT-d=yes)
http://ark.intel.com/products/65509/Intel-Core-i5-3330-Processor-6M-Cache-up-to-3_20-GHz

on a MB: H-Joshua-H61-UATX (with specs that say *nothing* about virtualization)
http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&lc=en&docname=c03135925#N98

and the H-Joshua-H61-UATX uses the Intel H61 Express Chipset (VT-d=No)
http://ark.intel.com/products/52806/Intel-BD82H61-PCH?q=intel%20h61%20express%20chipset

On the KVM how to assign devices page it provides a way to verify IOMMU support on Intel:

]# dmesg | grep -e DMAR -e IOMMU
[    0.000000] ACPI: DMAR 00000000d8d29460 000B0 (v01 HPQOEM SLIC-CPC 00000001 INTL 00000001)
[    0.023074] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.023078] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.023151] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1

Does this mean I do have VT-d/IOMMU support???

I was told to look for this line on Intel hosts:

 "PCI-DMA: Intel(R) Virtualization Technology for Directed I/O"


I attempted to follow the basic instructions to pass through my VGA card:

*very* unlikely to work, unless you're lucky enough to have one of the few cards that has had their "quirks" worked out.


]$ lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09)

Then added to my domain definition:

    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>

With that added code I consistently get "Connection to guest failed" messages and the guest fails to start.

/var/log/libvirt/qemu is empty.  No log.

So my 1st question is can I do this given my hardware?  If the answer is "yes" then this is where I'm stuck.

Additionally, I tried:

]$ virsh nodedev-detach pci_0000_00_02_0
error: Failed to detach device pci_0000_00_02_0
error: Failed to add PCI device ID '8086 0152' to pci-stub: Permission denied

Are you running virsh as root? Is this your only VGA card?


My thinking was simply to verify if I could manually detach the device.  I couldn't find a reference searching for this error.  Any help would be greatly appreciated!

You haven't indicated what distro/version you're running, but on some versions of Fedora at least, you need to configure libvirt to run qemu processes as root rather than the qemu user (that wouldn't have caused a problem with nodedev-detach though, although a problem with selinux could have).

I would suggest trying your experiment after 1) assuring that you're running virsh as root, 2) disabling selinux if your system has it, 3) setting the user/group in /etc/libvirt/qemu.conf to "root" and restarting libvirtd. However, since I think it's highly unlikely that you'll be successful in any case, I hesitate to use up your time doing that.

Good luck.