qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq fu


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq functions
Date: Sun, 10 Mar 2013 22:31:47 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]