qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq functions
Date: Sun, 10 Mar 2013 22:31:47 +0200	[thread overview]
Message-ID: <20130310203147.GB15481@redhat.com> (raw)
In-Reply-To: <1362939311.22132.151.camel@bling.home>

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	other threads:[~2013-03-10 20:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07 23:16 [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq functions Alex Williamson
2013-03-07 23:16 ` [Qemu-devel] [PATCH 1/2] pci_bridge: Use a default map_irq function Alex Williamson
2013-03-07 23:17 ` [Qemu-devel] [PATCH 2/2] pci_bridge: Remove duplicate IRQ swizzle function Alex Williamson
2013-03-10 16:16 ` [Qemu-devel] [PATCH 0/2] pci_bridge: Fixup/Cleanup bridge map_irq functions Michael S. Tsirkin
2013-03-10 18:13   ` Alex Williamson
2013-03-10 18:15     ` Alex Williamson
2013-03-10 20:31       ` Michael S. Tsirkin [this message]
2013-03-10 20:29     ` Michael S. Tsirkin
2013-03-10 16:17 ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130310203147.GB15481@redhat.com \
    --to=mst@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).