All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] ioh3420: Add a map_irq function
Date: Wed, 02 Oct 2013 10:30:57 -0700	[thread overview]
Message-ID: <524C5851.80600@intel.com> (raw)
In-Reply-To: <1380733924.14271.92.camel@ul30vt.home>

On 10/02/2013 10:12 AM, Alex Williamson wrote:
> On Fri, 2013-09-27 at 15:10 -0700, Alexander Duyck wrote:
>> On 02/28/2013 10:49 AM, Alex Williamson wrote:
>>> Every bridge needs to know how to map IRQs from it's secondary bus to
>>> the primary bus.  We seem to be direct mapped on ioh3420.  This avoids
>>> segfaults when trying to put assigned devices behind root ports.
>>>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>>
>>> ---
>>> hw/ioh3420.c |    7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/hw/ioh3420.c b/hw/ioh3420.c
>>> index 95bceb5..6ac4fe7 100644
>>> --- a/hw/ioh3420.c
>>> +++ b/hw/ioh3420.c
>>> @@ -90,6 +90,11 @@ static void ioh3420_reset(DeviceState *qdev)
>>>      pci_bridge_disable_base_limit(d);
>>>  }
>>>  
>>> +static int ioh3420_map_irq(PCIDevice *pci_dev, int irq_num)
>>> +{
>>> +    return irq_num;
>>> +}
>>> +
>>>  static int ioh3420_initfn(PCIDevice *d)
>>>  {
>>>      PCIBridge* br = DO_UPCAST(PCIBridge, dev, d);
>>> @@ -97,6 +102,8 @@ static int ioh3420_initfn(PCIDevice *d)
>>>      PCIESlot *s = DO_UPCAST(PCIESlot, port, p);
>>>      int rc;
>>>  
>>> +    pci_bridge_map_irq(br, NULL, ioh3420_map_irq);
>>> +
>>>      rc = pci_bridge_initfn(d);
>>>      if (rc < 0) {
>>>          return rc;
>>>
>> What became of this patch?  I believe I am seeing the issue described
>> when I assign a MSI-X capable virtual device to the secondary bus of an
>> ioh3420, and applying this patch seems to resolve the issue.  Was there
>> an alternate patch proposed and if so where can I find it?
> Hmm, I thought it was no longer necessary with
> pci_device_route_intx_to_irq(), especially if you're assigning a VF that
> doesn't support INTx.  Are you using the latest qemu bits?  pci-assign
> or vfio-pci?  Maybe provide a backtrace?  Thanks,
>
> Alex

I'm seeing it with an emulated interface using MSI-X, not with a VF or
assigned device.

I'll try to get you a backtrack when I have some time.  I'm currently
chasing down another issue and will try to remember to follow up on this
one.

Thanks,

Alex

      reply	other threads:[~2013-10-02 17:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130228184803.23865.84744.stgit@bling.home>
2013-09-27 22:10 ` [Qemu-devel] ioh3420: Add a map_irq function Alexander Duyck
2013-10-02 17:12   ` Alex Williamson
2013-10-02 17:30     ` Alexander Duyck [this message]

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=524C5851.80600@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=mst@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.