From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: PCI Passthrough, error: The driver 'pci-stub' is occupying your device 0000:08:06.2 Date: Fri, 25 Feb 2011 15:31:48 -0800 Message-ID: <20110225233148.GF4988@sequoia.sous-sol.org> References: <20110222015119.GY9869@sequoia.sous-sol.org> <20110223001103.GZ9869@sequoia.sous-sol.org> <20110225000622.GB4988@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Chris Wright , Alex Williamson , kvm@vger.kernel.org, "Roedel, Joerg" To: James Neave Return-path: Received: from sous-sol.org ([216.99.217.87]:38574 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753054Ab1BYXcG (ORCPT ); Fri, 25 Feb 2011 18:32:06 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: * James Neave (roboj1m@gmail.com) wrote: > On Fri, Feb 25, 2011 at 11:02 PM, James Neave wro= te: > > On Fri, Feb 25, 2011 at 10:47 PM, James Neave w= rote: > >> On Fri, Feb 25, 2011 at 12:06 AM, Chris Wright wrote: > >>> * James Neave (roboj1m@gmail.com) wrote: > >>>> OK, here's my latest dmesg with amd_iommu_dump and debug with no= quiet > >>>> http://pastebin.com/JxEwvqRA > >>> > >>> Yeah, that's what I expected: > >>> > >>> [ =A0 =A00.724403] AMD-Vi: =A0 DEV_ALIAS_RANGE =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 devid: 08:00.0 flags: 00 devid_to: 00:14.4 > >>> [ =A0 =A00.724439] AMD-Vi: =A0 DEV_RANGE_END =A0 =A0 =A0 =A0 =A0 = devid: 08:1f.7 > >>> > >>> That basically says 08:00.0 - 08:1f.7 will show up as 00:14.4 (an= d > >>> should all go into same iommu domain). > >>> > >>>> I've just figured out a sequence of "echo DEV > PATH" commands t= o call > >>>> for 14.4 gets me past the "claimed by pci-stub" error and gets m= e to > >>>> the "failed to assign IRQ" error. > >>>> I'm going to narrow down the required sequence and then post it. > >>> > >>> Kind of afraid to ask, but does it include: > >>> > >>> (assuming 1002 4384 is the pci to pci bridge) > >>> echo 1002 4384 > /sys/bus/pci/drivers/pci-stub/new_id > >>> echo 0000:00:14.4 > /sys/bus/pci/drivers/pci-stub/unbind > >>> > >>> (this has the side effect of detaching the bridge from its domain= ) > >>> > >>> thanks, > >>> -chris > >>> > >> > >> Exact sequence is: > >> > >> echo "1002 4384" > /sys/bus/pci/drivers/pci-stub/new_id > >> echo "0000:00:14.4" > /sys/bus/pci/devices/0000:00:14.4/driver/unb= ind > >> > >> I take it this is a bad thing then? > >> > >>> I assume this means that 00:14.4 is still left claimed by pci-stu= b? > >> > >> Yes > >> > >>> How are you determining this? =A0The lspci paste above has pci-st= ub for all > >>> of them. =A0The easiest thing might be to start with manually dis= abling > >>> host driver and reassigning pci-stub to: 00:14.4, 08: 06.2,3 and = 0e.0 > >>> Then giving the guest only 08:06.1. > >> > >> I determined it by being half asleep and not reading it properly..= =2E >.< > >> You're right, all 5 devices were using pci-stub > >> > >>>> libvirtError: this function is not supported by the connection d= river: > >>>> Unable to reset PCI device 0000:00:14.4: no FLR, PM reset or bus= reset > >>>> available > >> > >>> Right, libvirt is more restrictive than qemu-kvm (forgot you were= using > >>> libvirt here). > >> > >> What does that libvirt error mean? I can't find a definition. > >> Am I limiting myself by using libvirt? Would not using it help and= how > >> would I go about not using it? > >> > >>> Trouble now is that > >>> with shared IRQ we don't have a good way to handle that right now= =2E > >> > >> Game over then? > >> I've tried assigning the USB devices before, I couldn't do it beca= use > >> qemu doesn't support USB2 devices. > >> I don't really understand where this IRQ conflict is, the firewire= and > >> the USB2 device share IRQ22 but I'm assigning them both to the VM? > >> Is that still a problem? > >> I don't suppose there's any way to change which IRQ they use in th= e > >> BIOS or with a command is there? > >> > >> I don't know if it means anything but this page: > >> > >> http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200 > >> > >> Has the lspci output for the HVR-2200 which mentions MSI and IRQ25= 5. > >> My knowledge it very limited on this subject so I don't know if th= at's > >> meaningless looking at the output from another person's lspci. > >> > >> Anything left to try? > >> > >> Regardless, many thanks for your help, > >> > >> James. > >> > > > > On the off chance I tried disabling the firewire in the BIOS, which > > leaves only my tuner card using IRQ 20, 21 and 22. > > No difference, still complains about IRQs: > > > > Using raw in/out ioport access (sysfs - Input/output error) > > Failed to assign irq for "hostdev0": Operation not permitted > > Perhaps you are assigning a device that shares an IRQ with another = device? > > > > It does say "Operation not permitted" and that only "perhaps" I am > > assigning a device that shares an IRQ. > > Perhaps IRQ conflict it not the problem? They really are sitting on > > their own. Another permissions problem perhaps? > > > > Regards, > > > > James. > > >=20 > I'm reading something about this error message being related to > libvirt and CAP_SYS_RAWIO? Depending on how new your libvirt is, you can force it to stop dropping capabilities. Look for the config item "clear_emulator_capabilities" in /etc/libvirt/qemu.conf. Setting this to 0 would verify that's the problem (and not a real shared irq...i thought i saw sharing on /proc/interrupts though). >=20 > http://www.mail-archive.com/kvm@vger.kernel.org/msg34338.html > http://www.google.co.uk/#hl=3Den&xhr=3Dt&q=3Dlibvirt+CAP_SYS_RAWIO&cp= =3D21&pf=3Dp&sclient=3Dpsy&aq=3Df&aqi=3D&aql=3D&oq=3Dlibvirt+CAP_SYS_RA= WIO&pbx=3D1&fp=3D2d8e3f69fec095f4 >=20 > "When I patch libvirt to not drop the capabilities, everything works > as expected." Well, that's a good point. We fixed that a while ago, but I'm not sure your kernel has that fix. 2.6.35.10-dmar (btw, random nitpick, dmar =3D=3D intel dma remapping en= gine, aka vt-d not amd iommu ;) This was fixed in 2.6.36, commit: 48bb09e KVM: remove CAP_SYS_RAWIO requirement from kvm_vm_ioctl_assign_= irq The last 2.6.35 stable release is 2.6.35.9 and does not have that fix. So unless your .10-dmar has it, you could patch it in. thanks, -chris