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?
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 attempted to follow the basic instructions to pass through my VGA card:
]$ 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
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!
Thank you!
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 > deniedAre 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.
Oops! I blame Microsoft. I use Hotmail and am very, very unhappy that MS
bought them out which leaves me stuck with Outlook, which sucks. I've
always just hit reply in the past and it's worked. Now I'm going to
have to be careful to make sure my replies go where I expect them.
Thank you very much for the information. I was really hoping to consolidate
systems but that apparently won't happen in the near future. So that means
I'll be focusing my efforts on getting my Spacewalk server updated and then
upgrading from F18 to F20 or 21. Yep, I was very aware of F18 dropping and
thankful for the one brief delay.
I'll be taking a look at it again once I upgrade to the current Fedora. If
that doesn't work I'll wait and keep an eye on posts and when things
look better probably get new hardware (which will likely be the requirement).
Thanks, again!
Date: Thu, 23 Jan 2014 11:37:02 +0200
From: laine@laine.org
To: thepowertool_sc@hotmail.com
Subject: Re: [libvirt-users] PCI Passthrough
On 01/21/2014 05:32 PM, The PowerTool
wrote:
Laine,
Thank you very much for your response.
I took a look at the first link you provide (archlinux). Key
items that caught my attention (in order):
1. "Intel IGDs won't work"--I have Intel integrated video
2. "NOTE: THIS IS EXPERIMENTAL SO IT MIGHT NOT WORK FOR YOU"
(self-explanatory)
One additional note: When I received the "permission denied"
error I had the same thought as you. I was unaware of the issue
you outlined with libvirt needing to be configured to run as
root on some versions of Fedora. Still, as root I did
successfully detach my video card... at least that's how it
appeared given the monitor went no-signal and then displayed a
strange pattern. The system wouldn't ping and failed to respond
to ssh attempts. I had to reboot to recover. I tried a second
experiment where I first started a ssh session and then detached
(from the host). Going back to the 2nd system the ssh session
stopped responding.
Actually that's probably more of an indication that your kernel just
doesn't properly handle having the primary video device disappear
midstream. You may have different results if you connected two video
cards to a system, and tried to passthrough the secondary (it still
probably wouldn't work, but it would likely fail in a different
way).
That leads me to believe it's not fully baked,
something critically fails, and it's not going to work for me
at-least at my current levels.
Alex Williamson gave a talk at this year's KVM Forum (in October)
about the difficulties of making VGA passthrough work, and it was
truly frightening; there are just too many strange, undocumented
backdoors in the devices that are required by the drivers for proper
operation.
In my mind this whole area just has too great of a likelihood of
total failure without possibility of making it work in a reasonable
time frame.
To answer your question: I'm running Fedora 18.
F18 was definitely one of the releases that was broken wrt PCI
passthrough requiring qemu to be run as root. I don't recall if the
kernel guys ever fixed it in that version or not. I pestered them
about it for months, then finally gave up.
BTW, you know that F18 has just gone end-of-life, right? This means
no more updates of any type, even security updates. You can actually
upgrade your F18 machine to F19, and F19 to F20, using the "fedup"
package (I haven't tried using fedup to go directly from F18 to F20,
but I suppose you could look into it). *A lot* has changed in
virtualization in the last year, and as a bonus, you'll be covered
for security fixes for another year.
Is there a place where I can follow updates and see PCI
pass-through mature so I'll know when next to try?
Well, you could try the qemu-devel mailing list, but it's pretty
high traffic, and very few of the messages would be on this
particular topic. That *is* the place where any discussion would
take place, though.
Thank you, again, for your help!
BTW, it's best to keep all messages on the list rather than private
replies. That way someone else with better information may reply
(and people very often get busy and disappear for several days/weeks
at a time, so it's better to not rely on a response from a single
person)