On Sun, Mar 10, 2013 at 12:15:11PM -0600, Alex Williamson wrote: > On Sun, 2013-03-10 at 12:13 -0600, Alex Williamson wrote: > > On Sun, 2013-03-10 at 18:16 +0200, Michael S. Tsirkin wrote: > > > On Thu, Mar 07, 2013 at 04:16:48PM -0700, Alex Williamson wrote: > > > > Rather than have everyone call pci_bridge_map_irq() themselves and > > > > come up with incorrect mapping functions let's use the default PCI > > > > defined swizzle function unless told otherwise. Then we can also > > > > clean out the duplicate function in pci_bridge_dev. Tested with an > > > > assigned device behind a PCIe switch behind a PCIe root port at > > > > addresses 0-3. Note that Linux requires the pci=pcie_scan_all boot > > > > option to find devices behind PCIe ports if not addr=0.0. Windows > > > > finds them but won't use them (code 10). > > > > > > I'm guessing this only applies to downstream ports right? > > > The spec IIRC says that slot is ignored. > > > The real way is probably by making a device an endpoint > > > integrated into the switch, so it's behind the upstream port. > > > > I think that's wrong. The upstream device of an endpoint behind a > > switch should be the downstream port, followed by the upstream port. > > That's how we model it today and I think it's accurate. Slot is > > undefined for an upstream port, but that's the PCIe slot, not the > > PCI_SLOT(devfn), aka "device", slot. So I'm not sure how that's > > relevant here. > > > > If there's something you want me to change please let me know, otherwise > > I'm at a loss how to incorporate changes based on this feedback. > > D'oh, and now I see you've applied it. If there's any follow-up you're > looking for from the above, let me know. Thanks, > > Alex
No, not as such. We should look at PCI bridges now and see what map function they have and whether it can be removed. For example, hw/dec_pci.c has a different one, and I'm guessing it's just a bug. Need to test and if true, remove it. -- MST
