From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1GfR-0008LZ-Rd for qemu-devel@nongnu.org; Wed, 07 Sep 2011 07:51:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1GfQ-0004I7-EN for qemu-devel@nongnu.org; Wed, 07 Sep 2011 07:51:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1GfQ-0004Hv-5O for qemu-devel@nongnu.org; Wed, 07 Sep 2011 07:51:44 -0400 Date: Wed, 7 Sep 2011 14:52:23 +0300 From: "Michael S. Tsirkin" Message-ID: <20110907115223.GD9337@redhat.com> References: <4E4D2C9F.6040805@redhat.com> <4E4DF0A0.6000108@cn.fujitsu.com> <4E4E808C.4000205@redhat.com> <4E51C945.6070103@cn.fujitsu.com> <4E51F5FD.4030905@redhat.com> <4E6045E0.2090701@cn.fujitsu.com> <4E6335E4.6040705@redhat.com> <4E658E2F.6050302@cn.fujitsu.com> <4E65CF9E.20004@redhat.com> <4E66F56D.9070709@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E66F56D.9070709@cn.fujitsu.com> Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Kevin Wolf , Isaku Yamahata , Avi Kivity , qemu-devel@nongnu.org On Wed, Sep 07, 2011 at 12:39:09PM +0800, Wen Congyang wrote: > At 09/06/2011 03:45 PM, Avi Kivity Write: > > On 09/06/2011 06:06 AM, Wen Congyang wrote: > >> > Use the uio driver - > >> > http://docs.blackfin.uclinux.org/kernel/generated/uio-howto/. You > >> just > >> > mmap() the BAR from userspace and play with it. > >> > >> When I try to bind ivshmem to uio_pci_generic, I get the following > >> messages: > >> uio_pci_generic 0000:01:01.0: No IRQ assigned to device: no support > >> for interrupts? > >> > > > > No idea what this means. > > PCI 3.0 6.2.4 > For x86 based PCs, the values in this register correspond to IRQ numbers (0-15) of the standard dual > 8259 configuration. The value 255 is defined as meaning "unknown" or "no connection" to the interrupt > controller. Values between 15 and 254 are reserved. > > The register is interrupt line. > > I read the config of this device, the interrupt line is 0. It means that it uses the IRQ0. > > The following is the uio_pci_generic's code: > static int __devinit probe(struct pci_dev *pdev, > const struct pci_device_id *id) > { > struct uio_pci_generic_dev *gdev; > int err; > > err = pci_enable_device(pdev); > if (err) { > dev_err(&pdev->dev, "%s: pci_enable_device failed: %d\n", > __func__, err); > return err; > } > > if (!pdev->irq) { > dev_warn(&pdev->dev, "No IRQ assigned to device: " > "no support for interrupts?\n"); > pci_disable_device(pdev); > return -ENODEV; > } > ... > } > > This function will be called when we write 'domain:bus:slot.function' to /sys/bus/pci/drivers/uio_pci_generic/bind. > pdev->irq is 0, it means the device uses IRQ0. But we refuse it. I do not why. > > To Michael S. Tsirkin > This code is writen by you. Do you know why you check whether pdev->irq is 0? > > Thanks > Wen Congyang > > > Well I see this in linux: /* * Read interrupt line and base address registers. * The architecture-dependent code can tweak these, of course. */ static void pci_read_irq(struct pci_dev *dev) { unsigned char irq; pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &irq); dev->pin = irq; if (irq) pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq); dev->irq = irq; } Thus a device without an interrupt pin will get irq set to 0, and this seems the right way to detect such devices. I don't think PCI devices really use IRQ0 in practice, its probably used for PC things. More likely the system is misconfigured. Try lspci -vv to see what went wrong. -- MST