From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEmu3-0006ZW-2y for qemu-devel@nongnu.org; Sun, 10 Mar 2013 16:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEmty-0001w7-CA for qemu-devel@nongnu.org; Sun, 10 Mar 2013 16:31:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEmty-0001vx-3s for qemu-devel@nongnu.org; Sun, 10 Mar 2013 16:31:26 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2AKVPBu017701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 10 Mar 2013 16:31:25 -0400 Date: Sun, 10 Mar 2013 22:31:47 +0200 From: "Michael S. Tsirkin" Message-ID: <20130310203147.GB15481@redhat.com> References: <20130307230844.31144.93342.stgit@bling.home> <20130310161613.GA13315@redhat.com> <1362939207.22132.149.camel@bling.home> <1362939311.22132.151.camel@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1362939311.22132.151.camel@bling.home> Subject: Re: [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org 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