[libvirt-users] PCI Passthrough

[Laine Stump]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140121/5479d9a4/attachment.htm>