From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Xuz-0004Xo-9P for qemu-devel@nongnu.org; Thu, 08 Sep 2011 02:16:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1Xuw-0004eY-VG for qemu-devel@nongnu.org; Thu, 08 Sep 2011 02:16:57 -0400 Received: from [222.73.24.84] (port=57213 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Xuv-0004V9-Da for qemu-devel@nongnu.org; Thu, 08 Sep 2011 02:16:54 -0400 Message-ID: <4E685D85.6030806@cn.fujitsu.com> Date: Thu, 08 Sep 2011 14:15:33 +0800 From: Wen Congyang MIME-Version: 1.0 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> <20110907115223.GD9337@redhat.com> In-Reply-To: <20110907115223.GD9337@redhat.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Isaku Yamahata , Avi Kivity , qemu-devel@nongnu.org At 09/07/2011 07:52 PM, Michael S. Tsirkin Write: > 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. Yes, the PCI device shoulde not use IRQ0. I debug qemu's code, and find the PCI_INTERRUPT_LINE register is not set by qemu: ============= Hardware watchpoint 6: ((uint8_t *) 0x164e410)[0x3c] Old value = 0 '\000' New value = 10 '\n' pci_default_write_config (d=0x1653ed0, addr=60, val=10, l=1) at /home/wency/source/qemu/hw/pci.c:1115 1115 d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */ Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-md5-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 db4-4.7.25-16.el6.x86_64 (gdb) bt #0 pci_default_write_config (d=0x1653ed0, addr=60, val=10, l=1) at /home/wency/source/qemu/hw/pci.c:1115 #1 0x00000000004d5827 in pci_host_config_write_common (pci_dev=0x1653ed0, addr=60, limit=256, val=10, len=1) at /home/wency/source/qemu/hw/pci_host.c:54 #2 0x00000000004d5939 in pci_data_write (s=0x15f95a0, addr=2147502140, val=10, len=1) at /home/wency/source/qemu/hw/pci_host.c:75 #3 0x00000000004d5b19 in pci_host_data_write (handler=0x15f9570, addr=3324, val=10, len=1) at /home/wency/source/qemu/hw/pci_host.c:125 #4 0x000000000063ee06 in ioport_simple_writeb (opaque=0x15f9570, addr=3324, value=10) at /home/wency/source/qemu/rwhandler.c:48 #5 0x0000000000470db9 in ioport_write (index=0, address=3324, data=10) at ioport.c:81 #6 0x00000000004717bc in cpu_outb (addr=3324, val=10 '\n') at ioport.c:273 #7 0x00000000005ef25d in kvm_handle_io (port=3324, data=0x7ffff7ff8000, direction=1, size=1, count=1) at /home/wency/source/qemu/kvm-all.c:834 #8 0x00000000005ef7e6 in kvm_cpu_exec (env=0x13da0d0) at /home/wency/source/qemu/kvm-all.c:976 #9 0x00000000005c1a7b in qemu_kvm_cpu_thread_fn (arg=0x13da0d0) at /home/wency/source/qemu/cpus.c:661 #10 0x00000032864077e1 in start_thread () from /lib64/libpthread.so.0 #11 0x00000032858e68ed in clone () from /lib64/libc.so.6 ============= If I put ivshmem on bus 0, the PCI_INTERRUPT_LINE register can be set. So I guess this register is set by bios. I use the newest seabios, and PCI_INTERRUPT_LINE register is not set if the deivce is not on bus0. # lspci -vv 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Subsystem: Red Hat, Inc Qemu virtual machine Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 01:01.0 RAM memory: Red Hat, Inc Device 1110 Subsystem: Red Hat, Inc Device 1100 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR-