From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Neave Subject: Re: PCI Passthrough, error: The driver 'pci-stub' is occupying your device 0000:08:06.2 Date: Mon, 21 Feb 2011 20:31:42 +0000 Message-ID: References: <20110207132641.GD2665@redhat.com> <1297705728.14733.50.camel@x201> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:54942 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349Ab1BUUcD convert rfc822-to-8bit (ORCPT ); Mon, 21 Feb 2011 15:32:03 -0500 Received: by qwd7 with SMTP id 7so2329759qwd.19 for ; Mon, 21 Feb 2011 12:32:02 -0800 (PST) In-Reply-To: <1297705728.14733.50.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Feb 14, 2011 at 5:48 PM, Alex Williamson wrote: > On Sat, 2011-02-12 at 16:04 +0000, James Neave wrote: >> On Tue, Feb 8, 2011 at 10:17 AM, James Neave wro= te: >> > On Tue, Feb 8, 2011 at 9:59 AM, Kenni Lund wrote: >> >> 2011/2/7 Daniel P. Berrange : >> >>> On Sat, Feb 05, 2011 at 04:34:01PM +0000, James Neave wrote: >> >>>> Hi, >> >>>> >> >>>> I'm trying to pass a NOVA-T-500 TV Tuner card through to a gust= VM. >> >>>> I'm getting the error "The driver 'pci-stub' is occupying your = device >> >>>> 0000:08:06.2" >> >>> >> >>> This is a rather misleading error message. It is *expected* that >> >>> pci-stub will occupy the device. Unfortunately the rest of the >> >>> error messages QEMU is printing aren't much help either, but >> >>> ultimately something is returning -EBUSY in the PCI device assig= n >> >>> step >> >> >> >> James, as far as I remember, I had the same issue when I set up m= y >> >> system. Looking at my current (working) boot-script, apparently I= 've >> >> added a 4th line which removes the pci-stub again as a >> >> workaround....and it works: >> >> >> >> echo "4444 0016" > /sys/bus/pci/drivers/pci-stub/new_id >> >> echo "0000:04:08.0" > /sys/bus/pci/drivers/ivtv/unbind >> >> echo "0000:04:08.0" > /sys/bus/pci/drivers/pci-stub/bind >> >> echo "4444 0016" > /sys/bus/pci/drivers/pci-stub/remove_id >> >> >> >> Best regards >> >> Kenni >> >> >> > >> > Hi Kenni, >> > >> > Can I get a bit more information on "boot-script" please? Which fi= le >> > exaclty have you put this in? Did you write your own service scrip= t >> > and put it in init.d? >> > >> > I've tried this: >> > >> > echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id >> > echo 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbin= d >> > echo 0000:01:00.0 > /sys/bus/pci/drivers/pci-stub/bind >> > >> > I'll try it again with the fourth line added, manually before I st= art the VM. >> > >> > How come yours is 'echo "PCI" > /sys/bus/drivers/DRIVERNAME/unbind= ' >> > and mine is echo "PCI" > /sys/bus/pci/devices/PCI/driver/unbind >> > >> > Obviously one looks up which driver is being used by the PCI id, b= ut >> > how do I look up which driver my PCI card is using? >> > >> > Thanks, >> > >> > James. >> > >> >> Hi, >> >> OK, adding the fourth line does nothing, changing the second line to >> "driver" rather than "device" does nothing, including in combination >> with fourth line there/not there. > > Yep, the last line is just removing the id from pci-stub, it doesn't > change anything about devices that are already bound to it. =C2=A0dri= ver vs > device are just different ways to get to the same thing. > >> So I'm still stuck, can anybody else help? >> Perhaps point me to a guide on how to compile the latest qemu-kvm >> against my kernel? > > I don't know why you're getting -EBUSY for this device, but maybe we = can > start from a clean slate and see if it helps. =C2=A0Here's what I wou= ld > suggest: > > echo "0000:08:06.0" > /sys/bus/pci/devices/0000:08:06.0/driver/unbind > echo "0000:08:06.1" > /sys/bus/pci/devices/0000:08:06.1/driver/unbind > echo "0000:08:06.2" > /sys/bus/pci/devices/0000:08:06.2/driver/unbind > echo "0000:08:0e.0" > /sys/bus/pci/devices/0000:08:0e.0/driver/unbind > > Note we have to knock out the firewire because it shares an interrupt > with the ehci device you're trying to assign. =C2=A0We want to remove= the USB > controller entirely from the host. =C2=A0Your dmesg indicates the hos= t is > still seeing the device via the uhci ports, and isn't happy about it. > You can ignore pci-stub for the moment, it's just a way to keep drive= rs > from claiming the device, it's not required for device assignment. =C2= =A0Now, > instead of only trying to assign the ehci, let's move the whole usb > controller to the guest: > > -device pci-assign,host=3D08:06.0,addr=3D5.0 \ > -device pci-assign,host=3D08:06.1,addr=3D5.1 \ > -device pci-assign,host=3D08:06.2,addr=3D5.2 > > (slot 5 on the guest is arbitrary, pick something else if you need to= ) > If that works, then you can bind all those devices to pci-stub and it > should still work. > > Alex Hi, Sorry about the slow reply, I hosed all of my PCs fiddling with compiling the latest qemu, took me a while to put it all back together again in between work! I'm afraid I use virtmanager, although I guess using the "add pci device" function is the same as -device pci-assign? It does seem to add it to the command line that gets written out to the log files in /var/log/libvirt/qemu. Nevertheless, I've tried that and still not luck, the log output is similar, with one extra line: http://pastebin.com/MJ6aqjNq Using raw in/out ioport access (sysfs - Input/output error) Here's the dmesg output: http://pastebin.com/AE1euUN1 I'm going to google that new line and consider trying the libvirt ppa that accompanies the qemu-kvm ppa I'm using. Many Thanks, James.