| Message ID | 20110704094358.GA10960@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Jul 04, 2011 at 12:43:59PM +0300, Michael S. Tsirkin wrote: > +/* Mapping mandated by PCI-to-PCI Bridge architecture specification, > + * revision 1.2 */ > +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */ > +static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num) > +{ > + return (irq_num + PCI_SLOT(dev->devfn) + irq_num) % PCI_NUM_PINS; ^^^^^^^ ^^^^^^^ Typo. There are 2 irq_num.
On Tue, Jul 05, 2011 at 10:29:36PM +0900, Isaku Yamahata wrote: > On Mon, Jul 04, 2011 at 12:43:59PM +0300, Michael S. Tsirkin wrote: > > +/* Mapping mandated by PCI-to-PCI Bridge architecture specification, > > + * revision 1.2 */ > > +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */ > > +static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num) > > +{ > > + return (irq_num + PCI_SLOT(dev->devfn) + irq_num) % PCI_NUM_PINS; > ^^^^^^^ ^^^^^^^ > Typo. There are 2 irq_num. Good catch, thanks. > -- > yamahata
At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: > This adds support for a standard pci to pci bridge, > enabling support for more than 32 PCI devices in the system. > To use, specify the device id as a 'bus' option. > Example: > -device pci-bridge,id=bridge1 \ > -netdev user,id=u \ > -device ne2k_pci,id=net2,bus=bridge1,netdev=u > > TODO: device hotplug support. I try this patch, and found that when I use pci bridge, qemu will core dump. Here is my command line: /usr/local2/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 512 -name vm1 -drive file=/var/lib/libvirt/images/vm1.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writethrough -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc 0.0.0.0:1 -device pci-bridge,id=bridge1,bus=pci.0,addr=0x08.0x0 -netdev user,id=u -device ne2k_pci,id=net2,bus=bridge1,netdev=u Here is the backtrace: Core was generated by `/usr/local2/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 512 -name vm1 -dri'. Program terminated with signal 11, Segmentation fault. #0 0x0000000000438e34 in memory_region_add_subregion_common (mr=0x0, offset=49152, subregion=0x1de5d58) at /home/wency/source/qemu/memory.c:1152 1152 QTAILQ_FOREACH(other, &mr->subregions, subregions_link) { Missing separate debuginfos, use: debuginfo-install SDL-1.2.14-2.el6.x86_64 celt051-0.5.1.3-0.el6.x86_64 cyrus-sasl-gssapi-2.1.23-8.el6.x86_64 cyrus-sasl-lib-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 glib2-2.22.5-6.el6.x86_64 glibc-2.12-1.25.el6.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64 libX11-1.3-2.el6.x86_64 libXau-1.0.5-1.el6.x86_64 libaio-0.3.107-10.el6.x86_64 libattr-2.4.44-4.el6.x86_64 libcom_err-1.41.12-7.el6.x86_64 libcurl-7.19.7-26.el6.x86_64 libgcrypt-1.4.5-5.el6.x86_64 libgpg-error-1.7-3.el6.x86_64 libidn-1.18-2.el6.x86_64 libjpeg-6b-46.el6.x86_64 libpng-1.2.44-1.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 libssh2-1.2.2-7.el6.x86_64 libtasn1-2.3-3.el6.x86_64 libuuid-2.17.2-12.el6.x86_64 libxcb-1.5-1.el6.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64 nspr-4.8.7-1.el6.x86_64 nss-3.12.9-9.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64 nss-util-3.12.9-1.el6.x86_64 openldap -2.4.23-15.el6.x86_64 openssl-1.0.0-10.el6.x86_64 pixman-0.18.4-1.el6_0.1.x86_64 spice-server-0.8.0-1.el6.x86_64 zlib-1.2.3-25.el6.x86_64 (gdb) bt #0 0x0000000000438e34 in memory_region_add_subregion_common (mr=0x0, offset=49152, subregion=0x1de5d58) at /home/wency/source/qemu/memory.c:1152 #1 0x0000000000439090 in memory_region_add_subregion_overlap (mr=0x0, offset=49152, subregion=0x1de5d58, priority=1) at /home/wency/source/qemu/memory.c:1194 #2 0x00000000005c55fe in pci_update_mappings (d=0x1de5900) at /home/wency/source/qemu/hw/pci.c:1063 #3 0x00000000005c5982 in pci_default_write_config (d=0x1de5900, addr=4, val=0, l=2) at /home/wency/source/qemu/hw/pci.c:1121 #4 0x00000000005cbfbf in pci_host_config_write_common (pci_dev=0x1de5900, addr=4, limit=256, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:54 #5 0x00000000005cc0d1 in pci_data_write (s=0x1da2b90, addr=2147549188, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:75 #6 0x00000000005cc2b1 in pci_host_data_write (handler=0x1da2b60, addr=3324, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:125 #7 0x000000000042c884 in ioport_simple_writew (opaque=0x1da2b60, addr=3324, value=1) at /home/wency/source/qemu/rwhandler.c:50 #8 0x0000000000499e85 in ioport_write (index=1, address=3324, data=1) at ioport.c:81 #9 0x000000000049a8e1 in cpu_outw (addr=3324, val=1) at ioport.c:280 #10 0x0000000000433c5d in kvm_handle_io (port=3324, data=0x7f0b30f86000, direction=1, size=2, count=1) at /home/wency/source/qemu/kvm-all.c:837 #11 0x00000000004341c8 in kvm_cpu_exec (env=0x1b7fc70) at /home/wency/source/qemu/kvm-all.c:976 #12 0x000000000040da99 in cpu_exec_all () at /home/wency/source/qemu/cpus.c:1102 #13 0x00000000005b60c4 in main_loop () at /home/wency/source/qemu/vl.c:1392 #14 0x00000000005baa49 in main (argc=20, argv=0x7ffffa6b5a38, envp=0x7ffffa6b5ae0) at /home/wency/source/qemu/vl.c:3356 If I do not attach any device on bus bridge1, qemu can work nice. Thanks Wen Congyang > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > --- > Makefile.objs | 2 +- > hw/pci_bridge_dev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 71 insertions(+), 1 deletions(-) > create mode 100644 hw/pci_bridge_dev.c > > diff --git a/Makefile.objs b/Makefile.objs > index cea15e4..9e82b12 100644 > --- a/Makefile.objs > +++ b/Makefile.objs > @@ -174,7 +174,7 @@ hw-obj-y += vl.o loader.o > hw-obj-$(CONFIG_VIRTIO) += virtio.o virtio-console.o > hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o > hw-obj-y += fw_cfg.o > -hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o > +hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o > hw-obj-$(CONFIG_PCI) += msix.o msi.o > hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o > hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o > diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c > new file mode 100644 > index 0000000..c7ab5ad > --- /dev/null > +++ b/hw/pci_bridge_dev.c > @@ -0,0 +1,70 @@ > +/* > + * Standard PCI Bridge Device > + * > + * Copyright (c) 2011 Red Hat Inc. Author: Michael S. Tsirkin <mst@redhat.com> > + * > + * http://www.pcisig.com/specifications/conventional/pci_to_pci_bridge_architecture/ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, see <http://www.gnu.org/licenses/>. > + */ > + > +#include "pci_bridge.h" > +#include "pci_ids.h" > +#include "pci_internals.h" > + > +#define REDHAT_PCI_VENDOR_ID 0x1b36 > +#define PCI_BRIDGE_DEV_VENDOR_ID REDHAT_PCI_VENDOR_ID > +#define PCI_BRIDGE_DEV_DEVICE_ID 0x1 > + > +/* Mapping mandated by PCI-to-PCI Bridge architecture specification, > + * revision 1.2 */ > +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */ > +static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num) > +{ > + return (irq_num + PCI_SLOT(dev->devfn) + irq_num) % PCI_NUM_PINS; > +} > + > +static int pci_bridge_dev_initfn(PCIDevice *dev) > +{ > + PCIBridge *br = DO_UPCAST(PCIBridge, dev, dev); > + br->map_irq = pci_bridge_dev_map_irq_fn; > + /* If we don't specify the name, the bus will be addressed as <id>.0, where > + * id is the parent id. But it seems more natural to address the bus using > + * the parent device name. */ > + if (dev->qdev.id && *dev->qdev.id) { > + br->bus_name = dev->qdev.id; > + } > + return pci_bridge_initfn(dev); > +} > + > +static PCIDeviceInfo pci_bridge_dev_info = { > + .qdev.name = "pci-bridge", > + .qdev.desc = "Standard PCI Bridge", > + .qdev.size = sizeof(PCIBridge), > + .qdev.reset = pci_bridge_reset, > + .is_bridge = 1, > + .config_write = pci_bridge_write_config, > + .init = pci_bridge_dev_initfn, > + .exit = pci_bridge_exitfn, > + .vendor_id = PCI_BRIDGE_DEV_VENDOR_ID, > + .device_id = PCI_BRIDGE_DEV_DEVICE_ID, > + .class_id = PCI_CLASS_BRIDGE_PCI, > +}; > + > +static void pci_bridge_dev_register(void) > +{ > + pci_qdev_register(&pci_bridge_dev_info); > +} > + > +device_init(pci_bridge_dev_register);
On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote: > This adds support for a standard pci to pci bridge, > enabling support for more than 32 PCI devices in the system. > To use, specify the device id as a 'bus' option. > Example: > -device pci-bridge,id=bridge1 \ > -netdev user,id=u \ > -device ne2k_pci,id=net2,bus=bridge1,netdev=u BTW, I just noticed that -device ne2k_pci,? does not list the bus option. Any idea why?
"Michael S. Tsirkin" <mst@redhat.com> writes: > On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote: >> This adds support for a standard pci to pci bridge, >> enabling support for more than 32 PCI devices in the system. >> To use, specify the device id as a 'bus' option. >> Example: >> -device pci-bridge,id=bridge1 \ >> -netdev user,id=u \ >> -device ne2k_pci,id=net2,bus=bridge1,netdev=u > > BTW, I just noticed that -device ne2k_pci,? does > not list the bus option. Any idea why? Looking... qdev_device_help() shows only device properties, not bus properties. I'd call that a bug.
On Mon, Sep 05, 2011 at 10:17:01AM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > > On Mon, Jul 04, 2011 at 12:43:58PM +0300, Michael S. Tsirkin wrote: > >> This adds support for a standard pci to pci bridge, > >> enabling support for more than 32 PCI devices in the system. > >> To use, specify the device id as a 'bus' option. > >> Example: > >> -device pci-bridge,id=bridge1 \ > >> -netdev user,id=u \ > >> -device ne2k_pci,id=net2,bus=bridge1,netdev=u > > > > BTW, I just noticed that -device ne2k_pci,? does > > not list the bus option. Any idea why? > > Looking... qdev_device_help() shows only device properties, not bus > properties. I'd call that a bug. Hmm, but is "bus" a bus property? Care fixing all these?
Hi, >> Looking... qdev_device_help() shows only device properties, not bus >> properties. I'd call that a bug. > > Hmm, but is "bus" a bus property? It isn't. bus= is handled by qdev core (id= too). addr= actually is a (pci) bus property. cheers, Gerd
On Mon, Sep 05, 2011 at 11:53:11AM +0200, Gerd Hoffmann wrote: > Hi, > > >>Looking... qdev_device_help() shows only device properties, not bus > >>properties. I'd call that a bug. > > > >Hmm, but is "bus" a bus property? > > It isn't. bus= is handled by qdev core (id= too). addr= actually > is a (pci) bus property. > > cheers, > Gerd At the moment the help text is wrong: -device driver[,prop[=value][,...]] add device (based on driver) prop=value,... sets driver properties use -device ? to print all possible drivers use -device driver,? to print all possible properties We also need documentation for properties and devices, but that's a separate problem.
Gerd Hoffmann <kraxel@redhat.com> writes: > Hi, > >>> Looking... qdev_device_help() shows only device properties, not bus >>> properties. I'd call that a bug. >> >> Hmm, but is "bus" a bus property? > > It isn't. bus= is handled by qdev core (id= too). addr= actually is > a (pci) bus property. bus is indeed treated specially, but the user doesn't care. The help text should cover it just like any "normal" property.
At 11/01/2011 04:44 PM, Michael S. Tsirkin Write: > On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote: >> Hi, Michael S. Tsirkin >> >> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write: >>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote: >>>> Hi, Michael S. Tsirkin >>>> >>>> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: >>>>> This adds support for a standard pci to pci bridge, >>>>> enabling support for more than 32 PCI devices in the system. >>>>> To use, specify the device id as a 'bus' option. >>>>> Example: >>>>> -device pci-bridge,id=bridge1 \ >>>>> -netdev user,id=u \ >>>>> -device ne2k_pci,id=net2,bus=bridge1,netdev=u >>>>> >>>>> TODO: device hotplug support. >>>> >>>> Do you have any plan to implement this? >>> >>> I think this will be needed before merging the bridge code. >> >> What will you plan to support? >> >> 1. all PCI-to-PCI bridge is not hotpluggable. >> host bridge >> | >> --------------------- >> | | >> bridge bridge <= *not* hotpluggable >> | | >> ----------- ------------ >> | | | | >> slot slot slot slot <= hotplug here >> >> >> 2. PCI-to-PCI bridge is hotpluggable. >> bridge >> | >> ------------------- >> | | >> bridge on slot bridge on slot <= hot-plug here >> | | >> ------- ------- >> | | | | >> slot slot slot slot <= hot-plug here >> >>> >>>> I read the qemu's code, and find that qemu uses PIIX4_PM to support >>>> pci device hot plugging on PCI bus 0. How to support it on the other >>>> bus? Add PIIX4_PM to each PCI bus or implement a new power management? >>>> >>>> Thanks >>>> Wen Congyang >>> >>> There are many valid options. One is shpc interface. >>> I started looking into this but got preempted by other >>> tasks. Hope to get back to this at some point. >> >> Some old OS does not support shpc. So I think it's better to use ACPI to do it. >> >> Currently, we get which device is removed or inserted by reading the I/O port >> 0xae00(length: 8 bytes), and _EJ0 method uses I/O port 0xae08(length: 4 bytes). >> How do we determine this I/O address? Is there any spec to describe it? >> >> Thanks >> Wen Congyang > > Can we discuss these questions on the mailing list? No problem. I have cced qemu mailing list. Thanks Wen Congyang
On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote: > At 11/01/2011 04:44 PM, Michael S. Tsirkin Write: > > On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote: > >> Hi, Michael S. Tsirkin > >> > >> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write: > >>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote: > >>>> Hi, Michael S. Tsirkin > >>>> > >>>> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: > >>>>> This adds support for a standard pci to pci bridge, > >>>>> enabling support for more than 32 PCI devices in the system. > >>>>> To use, specify the device id as a 'bus' option. > >>>>> Example: > >>>>> -device pci-bridge,id=bridge1 \ > >>>>> -netdev user,id=u \ > >>>>> -device ne2k_pci,id=net2,bus=bridge1,netdev=u > >>>>> > >>>>> TODO: device hotplug support. > >>>> > >>>> Do you have any plan to implement this? > >>> > >>> I think this will be needed before merging the bridge code. > >> > >> What will you plan to support? > >> > >> 1. all PCI-to-PCI bridge is not hotpluggable. > >> host bridge > >> | > >> --------------------- > >> | | > >> bridge bridge <= *not* hotpluggable > >> | | > >> ----------- ------------ > >> | | | | > >> slot slot slot slot <= hotplug here > >> > >> > >> 2. PCI-to-PCI bridge is hotpluggable. > >> bridge > >> | > >> ------------------- > >> | | > >> bridge on slot bridge on slot <= hot-plug here > >> | | > >> ------- ------- > >> | | | | > >> slot slot slot slot <= hot-plug here It seems easier to start with a non hotpluggable bridge. I'm still trying to understand how is bridge hotplug supposed to work under ACPI, which wants all devices described in a static page. > >>> > >>>> I read the qemu's code, and find that qemu uses PIIX4_PM to support > >>>> pci device hot plugging on PCI bus 0. How to support it on the other > >>>> bus? Add PIIX4_PM to each PCI bus or implement a new power management? > >>>> > >>>> Thanks > >>>> Wen Congyang > >>> > >>> There are many valid options. One is shpc interface. > >>> I started looking into this but got preempted by other > >>> tasks. Hope to get back to this at some point. > >> > >> Some old OS does not support shpc. So I think it's better to use ACPI to do it. Yes, but ACPI can drive SHPC. > >> Currently, we get which device is removed or inserted by reading the I/O port > >> 0xae00(length: 8 bytes), and _EJ0 method uses I/O port 0xae08(length: 4 bytes). > >> How do we determine this I/O address? Is there any spec to describe it? I don't think so. > >> Thanks > >> Wen Congyang > > > > Can we discuss these questions on the mailing list? > > No problem. > I have cced qemu mailing list. > > Thanks > Wen Congyang
At 11/01/2011 07:48 PM, Michael S. Tsirkin Write: > On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote: >> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write: >>> On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote: >>>> Hi, Michael S. Tsirkin >>>> >>>> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write: >>>>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote: >>>>>> Hi, Michael S. Tsirkin >>>>>> >>>>>> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: >>>>>>> This adds support for a standard pci to pci bridge, >>>>>>> enabling support for more than 32 PCI devices in the system. >>>>>>> To use, specify the device id as a 'bus' option. >>>>>>> Example: >>>>>>> -device pci-bridge,id=bridge1 \ >>>>>>> -netdev user,id=u \ >>>>>>> -device ne2k_pci,id=net2,bus=bridge1,netdev=u >>>>>>> >>>>>>> TODO: device hotplug support. >>>>>> >>>>>> Do you have any plan to implement this? >>>>> >>>>> I think this will be needed before merging the bridge code. >>>> >>>> What will you plan to support? >>>> >>>> 1. all PCI-to-PCI bridge is not hotpluggable. >>>> host bridge >>>> | >>>> --------------------- >>>> | | >>>> bridge bridge <= *not* hotpluggable >>>> | | >>>> ----------- ------------ >>>> | | | | >>>> slot slot slot slot <= hotplug here >>>> >>>> >>>> 2. PCI-to-PCI bridge is hotpluggable. >>>> bridge >>>> | >>>> ------------------- >>>> | | >>>> bridge on slot bridge on slot <= hot-plug here >>>> | | >>>> ------- ------- >>>> | | | | >>>> slot slot slot slot <= hot-plug here > > It seems easier to start with a non hotpluggable bridge. > I'm still trying to understand how is bridge hotplug > supposed to work under ACPI, which wants all devices > described in a static page. We can load ACPI SSDT dynamically. But I do not know whether guest OS supports it. > >>>>> >>>>>> I read the qemu's code, and find that qemu uses PIIX4_PM to support >>>>>> pci device hot plugging on PCI bus 0. How to support it on the other >>>>>> bus? Add PIIX4_PM to each PCI bus or implement a new power management? >>>>>> >>>>>> Thanks >>>>>> Wen Congyang >>>>> >>>>> There are many valid options. One is shpc interface. >>>>> I started looking into this but got preempted by other >>>>> tasks. Hope to get back to this at some point. >>>> >>>> Some old OS does not support shpc. So I think it's better to use ACPI to do it. > > Yes, but ACPI can drive SHPC. Yes. But if we implement SHPC, we should also to implement ACPI. > >>>> Currently, we get which device is removed or inserted by reading the I/O port >>>> 0xae00(length: 8 bytes), and _EJ0 method uses I/O port 0xae08(length: 4 bytes). >>>> How do we determine this I/O address? Is there any spec to describe it? > > I don't think so. If we support hotplug behind PCI-to-PCI bridge, there are more than 32 slots that can be hotpluggable. How do we know which device is remove or inserted? The I/O region 0xae00 (length: 8bytes) only supports 32 slots. Thanks Wen Congyang > >>>> Thanks >>>> Wen Congyang >>> >>> Can we discuss these questions on the mailing list? >> >> No problem. >> I have cced qemu mailing list. >> >> Thanks >> Wen Congyang >
On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote: > At 11/01/2011 04:44 PM, Michael S. Tsirkin Write: > > On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote: > >> Hi, Michael S. Tsirkin > >> > >> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write: > >>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote: > >>>> Hi, Michael S. Tsirkin > >>>> > >>>> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: > >>>>> This adds support for a standard pci to pci bridge, > >>>>> enabling support for more than 32 PCI devices in the system. > >>>>> To use, specify the device id as a 'bus' option. > >>>>> Example: > >>>>> -device pci-bridge,id=bridge1 \ > >>>>> -netdev user,id=u \ > >>>>> -device ne2k_pci,id=net2,bus=bridge1,netdev=u > >>>>> > >>>>> TODO: device hotplug support. > >>>> > >>>> Do you have any plan to implement this? > >>> > >>> I think this will be needed before merging the bridge code. > >> > >> What will you plan to support? > >> > >> 1. all PCI-to-PCI bridge is not hotpluggable. > >> host bridge > >> | > >> --------------------- > >> | | > >> bridge bridge <= *not* hotpluggable > >> | | > >> ----------- ------------ > >> | | | | > >> slot slot slot slot <= hotplug here > >> > >> > >> 2. PCI-to-PCI bridge is hotpluggable. > >> bridge > >> | > >> ------------------- > >> | | > >> bridge on slot bridge on slot <= hot-plug here > >> | | > >> ------- ------- > >> | | | | > >> slot slot slot slot <= hot-plug here > >> If P2P bridge hotplug is supported, pci bus numbering needs refinement for numbering bus sparsely. > >>>> I read the qemu's code, and find that qemu uses PIIX4_PM to support > >>>> pci device hot plugging on PCI bus 0. How to support it on the other > >>>> bus? Add PIIX4_PM to each PCI bus or implement a new power management? > >>>> > >>>> Thanks > >>>> Wen Congyang > >>> > >>> There are many valid options. One is shpc interface. > >>> I started looking into this but got preempted by other > >>> tasks. Hope to get back to this at some point. > >> > >> Some old OS does not support shpc. So I think it's better to use ACPI to do it. Out of curiosity, what OS do you have in mind? > >> Currently, we get which device is removed or inserted by reading the I/O port > >> 0xae00(length: 8 bytes), and _EJ0 method uses I/O port 0xae08(length: 4 bytes). > >> How do we determine this I/O address? Is there any spec to describe it? As Michael already stated, we can support shpc with acpi. What's the point of enhancing adhoc qemu specific hotplug controller instead of shpc? We've suffered from its adhoc interface, I think. thanks, > >> Thanks > >> Wen Congyang > > > > Can we discuss these questions on the mailing list? > > No problem. > I have cced qemu mailing list. > > Thanks > Wen Congyang >
At 11/02/2011 10:15 AM, Isaku Yamahata Write: > On Tue, Nov 01, 2011 at 04:49:08PM +0800, Wen Congyang wrote: >> At 11/01/2011 04:44 PM, Michael S. Tsirkin Write: >>> On Tue, Nov 01, 2011 at 09:27:25AM +0800, Wen Congyang wrote: >>>> Hi, Michael S. Tsirkin >>>> >>>> At 09/26/2011 03:08 PM, Michael S. Tsirkin Write: >>>>> On Mon, Sep 26, 2011 at 02:18:15PM +0800, Wen Congyang wrote: >>>>>> Hi, Michael S. Tsirkin >>>>>> >>>>>> At 07/04/2011 05:43 PM, Michael S. Tsirkin Write: >>>>>>> This adds support for a standard pci to pci bridge, >>>>>>> enabling support for more than 32 PCI devices in the system. >>>>>>> To use, specify the device id as a 'bus' option. >>>>>>> Example: >>>>>>> -device pci-bridge,id=bridge1 \ >>>>>>> -netdev user,id=u \ >>>>>>> -device ne2k_pci,id=net2,bus=bridge1,netdev=u >>>>>>> >>>>>>> TODO: device hotplug support. >>>>>> >>>>>> Do you have any plan to implement this? >>>>> >>>>> I think this will be needed before merging the bridge code. >>>> >>>> What will you plan to support? >>>> >>>> 1. all PCI-to-PCI bridge is not hotpluggable. >>>> host bridge >>>> | >>>> --------------------- >>>> | | >>>> bridge bridge <= *not* hotpluggable >>>> | | >>>> ----------- ------------ >>>> | | | | >>>> slot slot slot slot <= hotplug here >>>> >>>> >>>> 2. PCI-to-PCI bridge is hotpluggable. >>>> bridge >>>> | >>>> ------------------- >>>> | | >>>> bridge on slot bridge on slot <= hot-plug here >>>> | | >>>> ------- ------- >>>> | | | | >>>> slot slot slot slot <= hot-plug here >>>> > > If P2P bridge hotplug is supported, pci bus numbering needs refinement > for numbering bus sparsely. > > >>>>>> I read the qemu's code, and find that qemu uses PIIX4_PM to support >>>>>> pci device hot plugging on PCI bus 0. How to support it on the other >>>>>> bus? Add PIIX4_PM to each PCI bus or implement a new power management? >>>>>> >>>>>> Thanks >>>>>> Wen Congyang >>>>> >>>>> There are many valid options. One is shpc interface. >>>>> I started looking into this but got preempted by other >>>>> tasks. Hope to get back to this at some point. >>>> >>>> Some old OS does not support shpc. So I think it's better to use ACPI to do it. > > Out of curiosity, what OS do you have in mind? Windows. IIRC, Windows supports SHPC after vista. > > >>>> Currently, we get which device is removed or inserted by reading the I/O port >>>> 0xae00(length: 8 bytes), and _EJ0 method uses I/O port 0xae08(length: 4 bytes). >>>> How do we determine this I/O address? Is there any spec to describe it? > > As Michael already stated, we can support shpc with acpi. > What's the point of enhancing adhoc qemu specific hotplug controller > instead of shpc? > We've suffered from its adhoc interface, I think. Do you mean I/O region 0xae00, 0xae08 is not standard. It can work only with qemu. Thanks Wen Congyang > > thanks, > >>>> Thanks >>>> Wen Congyang >>> >>> Can we discuss these questions on the mailing list? >> >> No problem. >> I have cced qemu mailing list. >> >> Thanks >> Wen Congyang >> >
diff --git a/Makefile.objs b/Makefile.objs index cea15e4..9e82b12 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -174,7 +174,7 @@ hw-obj-y += vl.o loader.o hw-obj-$(CONFIG_VIRTIO) += virtio.o virtio-console.o hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o hw-obj-y += fw_cfg.o -hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o +hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o hw-obj-$(CONFIG_PCI) += msix.o msi.o hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c new file mode 100644 index 0000000..c7ab5ad --- /dev/null +++ b/hw/pci_bridge_dev.c @@ -0,0 +1,70 @@ +/* + * Standard PCI Bridge Device + * + * Copyright (c) 2011 Red Hat Inc. Author: Michael S. Tsirkin <mst@redhat.com> + * + * http://www.pcisig.com/specifications/conventional/pci_to_pci_bridge_architecture/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, see <http://www.gnu.org/licenses/>. + */ + +#include "pci_bridge.h" +#include "pci_ids.h" +#include "pci_internals.h" + +#define REDHAT_PCI_VENDOR_ID 0x1b36 +#define PCI_BRIDGE_DEV_VENDOR_ID REDHAT_PCI_VENDOR_ID +#define PCI_BRIDGE_DEV_DEVICE_ID 0x1 + +/* Mapping mandated by PCI-to-PCI Bridge architecture specification, + * revision 1.2 */ +/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */ +static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num) +{ + return (irq_num + PCI_SLOT(dev->devfn) + irq_num) % PCI_NUM_PINS; +} + +static int pci_bridge_dev_initfn(PCIDevice *dev) +{ + PCIBridge *br = DO_UPCAST(PCIBridge, dev, dev); + br->map_irq = pci_bridge_dev_map_irq_fn; + /* If we don't specify the name, the bus will be addressed as <id>.0, where + * id is the parent id. But it seems more natural to address the bus using + * the parent device name. */ + if (dev->qdev.id && *dev->qdev.id) { + br->bus_name = dev->qdev.id; + } + return pci_bridge_initfn(dev); +} + +static PCIDeviceInfo pci_bridge_dev_info = { + .qdev.name = "pci-bridge", + .qdev.desc = "Standard PCI Bridge", + .qdev.size = sizeof(PCIBridge), + .qdev.reset = pci_bridge_reset, + .is_bridge = 1, + .config_write = pci_bridge_write_config, + .init = pci_bridge_dev_initfn, + .exit = pci_bridge_exitfn, + .vendor_id = PCI_BRIDGE_DEV_VENDOR_ID, + .device_id = PCI_BRIDGE_DEV_DEVICE_ID, + .class_id = PCI_CLASS_BRIDGE_PCI, +}; + +static void pci_bridge_dev_register(void) +{ + pci_qdev_register(&pci_bridge_dev_info); +} + +device_init(pci_bridge_dev_register);
This adds support for a standard pci to pci bridge, enabling support for more than 32 PCI devices in the system. To use, specify the device id as a 'bus' option. Example: -device pci-bridge,id=bridge1 \ -netdev user,id=u \ -device ne2k_pci,id=net2,bus=bridge1,netdev=u TODO: device hotplug support. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> --- Makefile.objs | 2 +- hw/pci_bridge_dev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+), 1 deletions(-) create mode 100644 hw/pci_bridge_dev.c